The Contextual Nature of Logging In

In my previous post, I discussed how the status of the user may play a role in their inability to log in to a library resource or service. In this post, I’d like to dig deeper into the topic of how the actual experience for the user can vary depending on a complex set of factors. At the most superficial level of analysis of use, a person has a task that they are trying to complete. With the task of logging in to something, the user either completes the task or they don’t. Delving in the context of that ask is what I hope to explore here. My aim is consider the interplay between the practical aspects of the task and the mental state of users as they undertake the task.

This exploration seems important to me as part of my effort as a user experience librarian who works with a team of people to design, redesign, or simply maintain online library systems and services. A key principle for me in my work, and for anyone who is engaged user-centered design, is to cultivate a deep empathy for the user or, more to the point, users, in all their variety and complexity. At Baruch College, where I am a librarian, the core audience for our library website includes:

  • 19,740 students (80% are undergraduate students, 20% graduate students)1 that collectively speak 111 languages and represent 168 countries2
  • 493 full-time and 607 part-time faculty3
  • Administrators and staff
  • 4,000 students from the CUNY School of Professional Studies with 97% of them in fully online courses4 and their faculty

While our user base is clearly diverse, maybe more so than the average American college or university community, I’d argue that for any college or university there is a diversity of contexts of use that are also important to recognize during the design process. In the library environment, designers can develop that sense of empathy by drawing on insights gathered in many different ways, such as formal user research (usability testing, ethnographic field studies, focus groups, etc.) as well as from the countless interactions we have in reference settings and in the classroom. While I’ve learned quite a bit from user research and from reference and classroom settings over the years, I have to also mention the fascinating insights I’ve gained from fellow CUNY colleagues, Maura Smale at the New York City College of Technology and Mariana Regalado at Brooklyn College, who have conducted multiple ethnographic research projects to document the scholarly habits of undergraduate students at a handful of CUNY colleges.

Compounding the diversity of users that we have to design for, there are countless variables related to the context of the user’s task that are going to effect how successful any one of those users are when presented with a login page. All of these variables are considerations that a designer must be aware of and weigh in their mind as they make design decisions). In the remainder of this post, I’ll lay out each of these variables and unpack them.

What Is the Task That the User Is Trying To Accomplish

A user may encounter a login page from the library while engaged in a range of common tasks, such as:

  • Searching for a known item (for a specific article, book, video, etc.)
  • Searching by subject for sources on a topic they are interested in)
  • Checking he status of something they have borrowed or requested or would like to request (due dates, fines, delivery dates, study room availability, etc.)

Why Are They Doing That Particular Task

If you can envision the range of reasons why a user may be engaged with these common tasks, then you can be more responsive to user needs in your design efforts. A related question to why a user is trying to complete a task is how important that task is to them at that moment. The issue of importance of the task connects with how persistent a user may be with an effort to log in to something and be willing to find a solution when their login efforts failed. The importance of the task to them (its personal significance to the user) may determine just how frustrated they are when they’re unable to login. Consider the difference between users each trying to log into a database to find articles on a topic who have different reasons for trying to accomplish that task.

A student might heard that the library has such-and-such database and wants to see what kinds of things are in it. Or maybe the student is in a workshop led by a librarian who has been invited into the student’s classroom by the professor. It’s likely the frustration levels will be lower in these kinds of casual uses than in more high-stakes use scenarios, such as a student who is under a tight deadline to finish a research paper with only hours to go before their deadline or a student who is stressed about and somewhat bewildered as they are working on their first-ever research paper. It seems a reasonable assumption that a casual user will be less frustrated by a login page that is confusing or even a dead-end for them than a user who is working on a project that is very important to them or challenging to them.

How the user reacts to the challenge of a login page will be shaped to a certain extent by reason why their task has brought them to this point. It’s reasonable to assume that the higher the stakes the context of the task is, the more likely it is that the user’s stress will undercut their ability to solve the puzzle of how to get past the login page, a process that often requires the user to slow down and think carefully and with some persistence about what credentials are being asked for. In short, stress can short-circuit the user’s ability to successfully log in to something.

Where Is the User When They Are Trying to Login

Consider all the places a user might be when they are trying to log into something:

  • They are at home, which may be quiet or very busy and distracting
  • They are at work where their efforts to log in take place during a break or maybe they’re trying to sneak in some schoolwork
  • They are using public wifi in some location where they may be worried about how much time they can be there or they be working hard to tune out distractions around them
  • They are on the go (e.g, using a phone while riding in a car, bus, train, etc.)

In each location, there may be greater or lower levels of frustration or stress for the user as they work on a task that may in turn effect how successful they are when presented with login requests.

What Device and Network Is the User On

The size of the user’s screen, how well a site is designed for accessibility, and the available input tools (keyboards, touchscreens, touchpads, mice, styluses, etc.) can all dramatically effect the user’s experience on any website. When designing a set of login pages, the designer needs to consider the range of devices users might have and make sure their login system performs equally for all of them.

The expectations for what users think they can do easily on a device may not line up with reality. It might be, for example, the case that when the user on a phone has entered the wrong login credentials, the error messages that are then displayed don’t convey as clearly as on a big screen how to get help for this error (i.e., systems to confirm your credentials, to reset them, or link to chat, email, or phone help options). Even the input devices that the user’s device has may also be harder or easier to use for the text input boxes where the user name and password are entered (for me, I am much more prone to typing errors on mobile devices than on a full-sized keyboard, which is especially apparent when I’m typing in passwords that are filled with numbers, symbols, random letters that may be capitalized).

Another variable is whose device someone is using when trying to log into something. It’s fair to assume that a person’s comfort level when encountering login requests and their success rate in getting past them goes up when they are using their own device that they regularly use, one that may have user names and passwords stored already in the browser or a password manager. On a device not our own, we can’t count on having those stored login credentials readily at hand, and our overall comfort and skill level with that device is likely to be lower than when it’s own our device. If the device is one shared in a household, there may be increased pressure on the user to complete their tasks quickly so that others can have their turn to use the device (I’m thinking here of the way my two sons used to battle and bicker over the family desktop computer in our living room).

The network that a user is on is yet another factor. Think of all the possibilities and how they shape the user experience:

  • A strong broadband connection on your home network vs. a weak one at home that cuts out intermittently
  • A work network where you may be worried about your employer being alerted to what you’re doing on work time
  • A mobile network that cuts out as you are on the go

How Savvy Is the User with Managing Logins

Is the system the user relies to keep track of logins sufficient or a source of ongoing frustration for them? Do they have no system for this, do they rely on scraps of paper, a notebook, browser storage, or a password manager? Do they find themselves always having to use the “forgot your user name” or “forgot your password” features? Are they surprised and annoyed when their efforts to find sources for a paper are leading to logins? Can they recognize the difference between a login system that the library has set up from a login system from the vendor that will only work for individual subscribers to that service or database?

When designing login systems, we should be making systems that are intelligible and usable for the least experienced user and that are as forgiving as possible.

What’s Next

As I’m thinking aloud here in these blog posts about the UX of logging in, I hope to be working toward some recommendations about design options for login systems that take into consideration the variability of user experience of library systems and services. I’m hoping to remind myself of what I’ve learned over the years and, more importantly, to recognize what I know I don’t know. The first thing I want to design is a better help page for users at my library who are having trouble logging in to something that my library is responsible for. I’m also interested in exploring whether some sort of troubleshooting guide for users might be worth the effort. Before I get to that, though, I want to write a post about how one moves from recognizing and understanding all the contextual variability of logging in to deciding what use scenarios are the ones to focus on in design efforts. This is always a problematic issue, this leap from UX research to UX design that requires you to limit the number of problems you hope to solve. Knowing which problems matter the most is always the most difficult part of the process. Following that post, I want to look at what sorts of help pages and troubleshooting systems libraries and other institutions have designed to assist users with the login process. I also think I need to do a post on what I wish our vendors would do to help us make the login process easier and what things we in libraries can be doing now.

Notes

1 Baruch College, “Fact Sheet,” 2020.

2 Baruch College, “Facts at a Glance,” 2020.

3 Baruch College, “Baruch College Self Study 2020,” 2020.

4 CUNY School of Professional Studies, “About,” 2021.

Other Posts in This Series

“The User Experience of Logging In: An Introduction,” 29 January 2021

The User Experience of Logging In: An Introduction

I’m trying to work through some ideas pinging around in my brain about how to improve the user experience of logging in to library services and resources at a college or university. I’ve been thinking of a series of posts to help me pull together a bunch of ideas, insights, and quandaries around the problems users encounter as they try to access library stuff online. I’m hoping this initial post will get me started in writing all the posts I have in mind.

As much as possible, I’m trying to develop a wide perspective on the problem. As someone who does UX research and UX design at my library, I’ve found it essential to understand all the systems at play before trying to do any design work. If I don’t have a moderately informed understanding of how our services and resources interconnect with each other and with the ICTs (information and communication technologies) that our users are working with, my design efforts may miss some key component. In other words, the more you know about the systems and services, the better your designs can be. And I’d argue that every single thing we in libraries design must be perpetually improved and tweaked. No design is perfect. Furthermore, not only is technology ever changing, but society’s values and norms that affect our use of those ICTs are also evolving regularly in a socio-technical system of mutual shaping.

As someone who also helps manage e-resources and does troubleshooting at least several times a week to help someone who is reporting that they “can’t log in” to something, I’ve built up some standard questions to ask the user. I may not be a master of all the technologies at work behind the scenes, but I’ve learned enough to make reasonable guesses about what has gone wrong and ask the user questions that help narrow down the list of possible causes. This post is my attempt to categorize the places where problems arise and detail some specific issues: the status of the user, the user’s device, the library’s systems and resources, and a vendor’s systems or resources.

The Status of the User

Many access problems are connected to who the user is and what their status is at the moment the problem occurred. At a college campus like mine, someone’s status may evolve over time, as in the case of a student who just graduated and is now an alum. Here are other statuses that may be preventing access:

  • A student who is registered but classes haven’t started yet
  • A student who is taking a semester off
  • A student enrolled elsewhere who is only taking one class
  • A student in a continuing education program, not the degree programs at the school and not in one of the certificate-bearing continuing ed programs
  • A student who just graduated and is within the window where they still have student access
  • A student who graduated and now officially has alumni status
  • A staff or faculty member who has been hired but not fully set up with network credentials at the school
  • A staff or faculty member who just retired
  • A “friend of the library” or local community user who may have limited access privileges

The User’s Device

By device, I am thinking not just of the computer, phone, or tablet they are using but also the way they are connected to the internet. Some of the problems that arise in this area can be caused by:

  • A browser that is out-of-date
  • A recently updated browser that is creating previously unknown conflicts due to new security features
  • A browser that isn’t compatible with the resource or service the user is trying to connect to
  • Browser plugins or extensions
  • Security settings in the browser or device
  • Security software installed on the device
  • Network settings on the device
  • Settings on the network itself (e.g., ports that have been closed, firewalls, etc.)
  • A weak network or one that goes in and out
  • VPN software that needs to be updated
  • Cached files in the browser from previous sessions with that service or resource

The Library’s Services and Systems

In many cases, the problem a user reports is caused by a system or service that the library is entirely or mostly responsible for. When I say “library,” I’m including the larger institution that the library is a part of; for example, while a college library typically has no control over what ports on the network campus IT has shut off, someone in the library has to be aware of this and able to work with IT when a problem seems to be connected to that. Below is a representative list of the kinds of things that the library has some or full responsibility and that may relate to login problems:

  • A key part of the library’s or campus user authentication system (e.g., EZproxy, Shibboleth, active directory, etc.) is down or malfunctioning
  • Campus IP addresses have changed but the library wasn’t notified
  • The campus VPN service is down
  • Subscription problems (the vendor has cut off access unexpectedly due to a payment issue, although some of these problems start with misunderstandings or overly punitive responses by the vendor)
  • The library and/or the campus provide the user with a bewildering variety of login credentials for various systems, services, and resources
  • The login system we control (such as EZproxy) doesn’t provide the user with enough information about which login credentials are needed and how to get help when the user isn’t sure or is mistaken about those credentials
  • The library has fallen behind in work to keep e-resource holdings up to date (e.g., a database subscription that has been cancelled still has its holdings listed as active in the catalog or library services platform)
  • The settings in the proxy server for a specific resource (e.g., a database) are out-of-date
  • The resource is only available to a subset of the campus community or has a limited number of simultaneous users but the library hasn’t adequately indicated that on its website, catalog, library services platform, etc.
  • A e-reserves collection for a class from a previous semester.

The Vendor’s Systems or Resources

Probably the biggest frustration for libraries regarding the login problem is that we have a limited ability to effect changes in the systems we buy or license. While we may be able to do a reasonable amount of configuration of a library services platform that is hosted on the vendor’s network, there’s not much we can do about the ScienceDirect interface short of complaining through various official and unofficial channels or threaten to cancel when the situation becomes dire (frustrated users avoid the resource, which leads to low usage stats, which then makes the resource a contender for cancellation when its up for a renewal decision). The most common login problems users report are:

  • The resource requires the user to create their own set of login credentials but the interface doesn’t make that clear enough to the user the first time they encounter it or on later visits when they’ve forgotten this to be the case.
  • Although a campus-provided set of login credentials is required to get to the resource initially, once in, the user is encouraged to create a personal login (so they can save results, personalize the interface, etc.)
  • The user has found content in the resource that isn’t part of the library’s license (this is very much a design problem that could be solved by vendors if they cared enough about it).
  • The user has gone directly to the resource via links or a web search (you could argue that this is the fault of the user, but I’d say it’s the fault of vendors who have yet to recognize this very old problem and design WAYF [where are you from] functionality in the interface that can guide unrecognized users back to their campus login systems).
  • The vendor’s system is down.
  • The vendor has changed the URLs for a resource but hasn’t notified the library or the vendor for the library services platform (or the library services platform vendor hasn’t gotten to changing those URLs yet).
  • The vendor has rolled out a new platform that no longer works with your library’s current proxy settings.

What’s Next in This Blog Post Series

I’ve been working various efforts to improve the user experience of logging in at my library but I have a long way to go (and will never be done, as change in our systems, users, and society is eternal). One of the things that helps me come with design ideas is looking around on the web for inspiration. I’ll probably share some of what I found recently and how I might be able to borrow or build on designs (small and large) that others have put in place.

Other Posts in This Series

“The Contextual Nature of Logging In,” 22 February 2021.

Implications of Default Search Options in Ejournal Platforms

In my last post, I reviewed a handful of ejournal platforms (and one ebook platform) to see what default options were available that affected whether the search results would show all content or only the content the library had licensed or purchased. I also wanted to see which platforms let the user change the settings for available content. There were some platforms that I think did this the right way by letting the subscribing library choose what the default search mode would be and by also giving users the option to override that default at the search page and on the results pages. Only JSTOR and Project MUSE offer this kind of flexibility. At the other end of the spectrum of flexibility and usability were platforms where neither the library nor the user could change the default settings that were set to show all content (Wiley Online Library is like that).

There are a range of platforms in the middle where the user can change the search mode to include only licensed content. A few vendors like this have communicated by various means (on posts in the ERIL mailing list or in support tickets back to me) that users tell them they want to see all the content or that some subscribing libraries prefer it to be that way. I find it a bit galling that some vendors disdain letting their customers choose what’s best for their own community (i.e., letting the subscribing library make that decision about search defaults based on what is known about the users in that community). User preferences at a large research institution (especially the preferences of the faculty and graduate students) are unlikely to be same as those of students at a community college or a small 4-year school. If anyone is going to have an understanding of those local user preferences, it’s going to be the subscribing library, not the vendor.

It’s worth taking a moment to consider the pros and cons for making all the content visible on these platforms. If the default setting shows users everything, they can avail themselves of the link resolver in the interface to track down full text (on the off chance the library has it elsewhere). If the link resolver fails to find the full text elsewhere, it should present the user with an interlibrary loan option, which would likely satisfy many users (except those who are in too much of a rush or can’t be bothered with the process). On the other hand, link resolvers can be unreliable and fail to lead users to content that the library may actually have. Furthermore, some platforms won’t even let you integrate your link resolver into the interface or they way that they let you do that is poorly done. In the article record view on some platforms, the link resolver button or link is minimized at the expense of the publisher’s own set of buttons and options to purchase the article (one can wonder about the intentions of vendors in making some of these design decisions that prioritize purchase options). No librarian is happy when a reference interaction starts off with the user saying, “I found an article on your database and now it’s asking me to pay $55 for it.”

At this point, some of you may be wondering why I’m making such a big deal out of platforms that most users only find themselves on temporarily. Users will find a record for the article in a discovery service or in an aggregator database and then wind up on the ejournal platform after a series of clicks on a link resolver (or a direct link if they’re lucky). After the user has found the full text and acted on it (read it, downloaded it, decided it wasn’t worth bothering with, etc.), they are more likely to go back to the discovery service or the aggregator database to continue their searching. It is far less likely that a user who has gone that last mile to get to the full text would then start new searches there.

With respect to the array of database options that an academic library can display on their website via an A-Z databases page, it is not uncommon for that library to skip listing all of the ejournal platforms, especially if the number of journals they actually have on a given platform is small (ejournal holding are likely to be accessible via A-Z journals pages, link resolvers, and catalog records). So it’s not like the users are going directly to these ejournal platforms in droves to begin the search process (some exceptions to this are JSTOR and ScienceDirect, which are well known by users and commonly featured on A-Z database lists on the library website).

Despite the fact that our users may not be spending that much time on these ejournal platforms, let alone consciously deciding to go there after viewing a list of database options on a A-Z list, these platforms really should offer more customization to the user and to the subscribing library.

Options and Defaults for Showing Only Licensed Content in Ejournal Platforms

Depending on the interface and system you’re talking about and depending on the user type you’re talking about (the casual searcher who needs just one or two sources quickly or the dogged searcher who needs an expansive search set), it’s an interesting question about how to handle default search options that control whether results show all possible results or just those your library has immediate access to (via subscriptions and purchases). In time that I’ve been a librarian (since 1999), academic libraries typically offer their users:

  • a catalog that only shows the library’s collections (or maybe a union collection where materials can easily be requested and quickly delivered)
  • A&I databases that rely on link resolvers to get to full text where possible and ILL services where access is not available
  • aggregator databases that pull together full text content from lots of different publishers and may also include records where only abstracts are available
  • ejournal collections from various publishers where all or part of the collection has been subscribed to or purchased

Added to that mix are discovery services that try to bring together records from the catalog and records for articles that the library has full text access to. Commonly, those discovery services will also let the user change the search mode to find article records for which the library has no full-text access. In most cases, libraries can go into administrative options for their discovery services and aggregator databases and set default search settings that control whether search results show all content or just the content the user has full-text access to. Typically, the search interfaces give the user a way to override the defaults at the search box (sometimes at the basic search box, more often only at the advanced search box) or on the search results pages.

The search systems used by ejournal collections, though, seem to offer libraries and their users far less control over default search setting or the ability to refine search to only available content. In this post, I want to review some of the ejournal platforms (and some ebook platforms) we have at Baruch College and spotlight the ones that give librarians who administer these systems and searchers who use them a measure of control over what should appear in the search results.

Cambridge Core

Admin options: Subscribing libraries have no way in the admin options or by submission of a support request to change the default search to show only results for available content.

User options: Checkbox main search page to limit to “Only content I have access to.” Same checkbox also shown at top of facets on search results pages.

Cambridge Core search screen showing checkbox

Cambridge Core search screen showing checkbox

Emerald Insight

Admin options: No way to change default search behavior.

User options: Only the advanced search page and the search results pages offer a way to “Include” “only content I have access to.”

Emerald Insight advanced search screen showing "Include" option

Emerald Insight advanced search screen showing “Include” option

JSTOR

Admin options: I don’t recall how we set this up (maybe via a support ticket) but we were able to set defaults to only show available content.

User options: Advanced search page and search results pages let you change the “Access type” from the default “Read and download” option to “All content.”

JSTOR "access type" options on the advanced search page

JSTOR “access type” options on the advanced search page

Oxford Handbooks Online

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: The search results page is the only way to change from the default of showing all content to just the “unlocked” content.

Oxford Handbooks Online search results page with availability options

Oxford Handbooks Online search results page with availability options

Oxford Journals

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: No way to just see content the library has.

Oxford Reference

Admin options: Same interface as Oxford Handbooks Online (but different URL). By default, search results limited “By Availability” to “Unlocked” and “Free” content. I don’t know how this get set up (it’s not an admin option).

User options: The search results page is the only way to change from the default of showing all content to just the “unlocked” content.

Oxford Reference checkboxes to "Narrow Your Choices" "By Availability"

Oxford Reference checkboxes to “Narrow Your Choices” “By Availability”

Project MUSE

Admin options: By default, we have it set to show “Access” to “Only content I have full access to.” We had to submit a support request to get this set up.

User options: The advanced search screen and the search results page give the user the checkbox to change the default setting and show all content.

Project MUSE search screen showing "Access" option

Project MUSE search screen showing “Access” option

ScienceDirect

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: The advanced search screen offers a checkbox to “Refine your search” to “Subscribed publications.”

ScienceDirect advanced search screen showing limiter for "subscribed publications"

ScienceDirect advanced search screen showing limiter for “subscribed publications”

SpringerLink

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: Advanced search screen and search results page offer a checkbox where you can turn the choice to “Include Preview-Only content.”

SpringerLink option to deselect checkbox to "Include Preview-Only content"

SpringerLink option to deselect checkbox to “Include Preview-Only content”

Wiley Online Library

Admin options: There isn’t a way in the admin options or by means of a support request to change the default, which shows all content.

User options: None.

What’s Next

In my next post, I’ll summarize what I found from this quick survey of ejournal platforms and talk about the pros and cons of making all content visible.

Selecting All Results on a Page of Search Results

I’ve been wondering about the pros and cons of having a search results page that lets the user select all the items on the page (so they can be saved, exported, etc.) A quick survey of some major database platforms, discovery services, and our catalog shows that this feature is not available in every interface:

Interfaces that have it:

  • EBSCOhost
  • Factiva
  • LexisNexis Academic
  • Primo (current UI)
  • ProQuest
  • Web of Science

Interfaces that don’t have it:

  • Ex Libris Aleph
  • EBSCOhost
  • JSTOR
  • Gale
  • Primo (including new UI)
  • ScienceDirect
  • Summon

I’m not sure if this is necessarily a bad thing for an interface to be missing the “select all items” function. I suspect that usage of this feature might vary by tool (article databases vs. discovery layers vs. traditional catalog interfaces). Should we be clamoring for this function across all tools? Some of them? None of them? Is it too much of an expert searcher tool to bother with (or to bother with in some tools?)

I realize that to answer these questions conclusively would require access to usage data we don’t necessarily have (how many users clicked on the feature in the interfaces where it’s an option) and observational data (from interviews, usability testing, etc.). I’m curious about what others think about this feature.

UPDATE 12 October 2016: Thanks to folks on the Primo mailing list, I realized I was wrong about Primo not offering the feature. The current UI does but the new one doesn’t. A librarian on the ERIL list pointed out that EBSCOhost lets you add all items on the page if you first go to the “Share” button. I’ve updated the post to reflect these corrections.

Advice for UX Shops of One in Libraries

On Twitter recently, I was asked for advice about setting up a new one-person UX shop in a library. I’ve only recently emerged from the UX-shop-of-one world, thanks to the addition of a part-time UX designer to my “team” and am not entirely sure how much my experience yields universal insights. So consider the following caveats about how institutional differences will affect the usefulness of any thoughts I have about how to get started.
  • How many people work in your library? Size of the library staff matters. If you are one of dozen or less people staffing the library, then your UX work is likely bundled in with other job responsibilities. Some libraries are large enough to support a whole unit or division devoted to UX (or at least web services, web oversight, etc.)
  • How directly can you make changes to the website (and its attendant ecosystem services and resources, such as the link resolver, the discovery layer, subscription databases, catalog records, proxy server, ejournals knowledgebase, etc.) or to physical locations in the library where you want to work your magic?
  • What is the culture of change in your library? Do proposed changes and new initiatives tend to get debated to death? Does everyone have to weigh in on decisions?
With those considerations, here are some suggestions for someone just getting started as the sole person with UX responsibilities (or a UX job title).
  • Find your tribe inside and outside the library. In the library, look for people who are open to user-centered services or user-centered design so that you can have someone to bounce ideas off of. If that person happens to run a service or manage a resource that you’d like to do some design work on, all the better. Outside the library, you’ll want to find communities of people in libraryland who are interested in talking about UX work and communities that serve a broader UX professional audience. For me, this includes:
  • Dive into “the literature” (I’ll only mention a few books, as there are dozens worth reading)
    • Useful, Usable, Desirable. A great book about UX in libraries by Aaron Schmidt and Amanda Etches to get started with. Especially useful is the way the book is organized to help you assess all aspects of your library to help you identify where you might want to begin your design work.
    • Rocket Surgery Made Easy. UX expert Steve Krug’s book about usability testing and design work.
    • Don’t Make Me Think. A revised edition of a classic book by Steve Krug about UX and web design.
    • Weave: Journal of Library User Experience. Open access FTW!!!
    • LibUX. Check out the archives of this podcast and make sure you subscribe to it.
  • Carefully gather evidence from user research and save it in a mindful fashion as you work on projects. It is essential to draw on this evidence when making formal proposals for some change you’d like to make. The more you can show your colleagues that design decisions can be driven by evidence and not whim, the more likely they’ll listen to you.
  • Do usability tests on existing systems and services to identify and properly document problems.
  • Learn as much as you can about project management, as a lot of UX design work is a multi-step process that usually involves your collaboration with colleagues who may not always see the big picture of the project.
 I’m sure there is more to add here (for example, take a look at this nice guide about library UX from Carli Spina at Harvard University for more ideas). If I’ve forgotten something important, or gotten something wrong, please share your comments!

No Longer a UX Shop of One

Last fall, I was given the OK to hire a part-time user experience designer, which meant that my library’s user experience team was no longer a one-person operation. For the past four years, I’ve been working mostly on my own, although I frequently did projects that paired me up with others in the library (such as the time I worked with the head of access services to set up our new online reservation system for group study rooms).

One of the issues I’ve been working through over the past four months since I gained a part-time colleague is communication. Since it is no longer just me here, I need to be more intentional in sharing information. Although there are services to help you with project management in a team setting–things like Asana and Trello–I’ve found so far that a more low-key technology seems to be pretty good far: an internal wiki.

I’ve been using our campus’ wiki system from Confluence for many years now and feel pretty comfortable creating a new space there for the UX work my colleague and I are engaged in. In case it is useful to anyone else, I’ll share the set up.

First, there is a main page that lists all the projects in the pipeline. The project list is organized into high, medium, and low priority groups. Each project gets its own page. Each project page has these sections:

  • The Problem. A quick statement of what problem we are trying to solve with our UX design approach. For example, on the project page for “Databases by Subject,” the problem is that the current page requires too much scrolling.
  • Research Questions. As we start to dig into each project, we try our best to consider what it is we really don’t know but probably should if we hope to do the project in a way that aligns closely with user expectations. We want to make sure that we are questioning as many of our assumptions as possible. These questions will guide our efforts to understand our users before we get to the stage of producing high fidelity mockups. With the “Databases by Subject” page, the questions we have include things like:
    • Which is better for users: an alphabetical list of subjects or chunking the subjects within broad categories?
    • If we do use categories, what are the best category labels?\
    • If we do use categories, should we still have an A-Z drop down menu on the page that simply lists databases by name?
  • Design Ideas. At all stages of the project, we’re finding we have lots of ideas, both big and small, that may help us when we get to the mockup stage. This is a place to quickly note those. For some projects where it’s likely there is more than one distinct direction to go in, we’ll have a subsection of “General Design Principles” that apply to different options and a subsection for each specific option. For example, we are working on a redesign of the central search box on our home page. We’ve got a general principles subsection to specify things we should include and we’ve got subsections for the two main design options we have: a box with a drop down menu or a box with tabs on top.
  • Milestones. This is a list of the main tasks we’ll need to accomplish. In Confluence, these can be styled as a proper to-do list, which I like because of the satisfaction I get from ticking off a check box once some milestone has been reach. I probably need to read up more on project management techniques to see if it makes sense to break this section out from the Project Timeline section that we also create.
  • Project Timeline. This helps me get a rough sense of the flow of the project and think about how the deadlines align with the academic calendar, which is important as some changes we’d like to make are so major they really shouldn’t go live until the end the semester.
  • Project Documents and Files. We’ve been using a shared Google Drive for mockups, usability test recordings, screenshots of other websites, etc. It’s easier to use Google Drive for this than to go to the trouble of uploading it all to the Confluence wiki.
  • Sources of Evidence Used. This lists the evidence of user behavior that we will use throughout the design process. For a project we’re doing now to redesign  the central search box on the library’s home page, the list includes Google Analytics event tracking data on use of the tabs on the existing search box; usability tests; and query log analysis. The items on the list may link to a new page just about that item if it is a big enough thing. That’s the case with usability tests, which are usually big enough endeavors to merit their own pages in the wiki; so, for example, we have a page just about the details of the initial usability test run last December on the central search box.

I’m hoping all of this project management work will help me when the time comes to make the case to various stakeholders in the library about the design change I’d like to make. Depending on the scope of the change being suggested, I may need to write a report detailing the research that went into the recommended design.

This system of using a wiki for project management has really helped us organize the work better. I suspect, though, that the “to do” aspects of it need some more work. I’d rather not use a separate system to manage that and hope to figure out more ways to use Confluence (for example, I haven’t taken advantage yet of the ability to tag people in Confluence with an @ symbol to assign them tasks). For now, though, I feel like we’re in a better place with this kind  of shared documentation.

Goodbye, Old FriendFeed

In the past month, I haven’t really made any effort to archive my posts on the soon-to-be-gone FriendFeed. Instead I’ve been focused on lending a hand in finding a new home for my go-to place for professional support, advice, and gossip: the Library Society of the World (LSW). Yesterday, some of us helped launch an instance of the open-source forum software, Discourse, on a server administered by a few folks long part of the LSW community. Our online barn raising has been a whirlwind of great ideas, debate about needed functionality, and worry about features in FriendFeed that can’t be replicated on the new platform. You can check out our work so far, and, even better, sign up now and join in.

Today, I took a breather from the discussions about how to make Discourse more useful and fun for the LSW community and decided to click back in time through page after page of my FriendFeed posts. I may yet archive all my posts in the remaining hours. But for now, I’d like to use this post to offer a few snapshots, and document my time at FriendFeed. I joined FriendFeed on April 8, 2008, with no clue that seven years and one day later, FriendFeed would be gone. Some anniversary.

Here’s my first real post on FriendFeed, which is from May 16, 2007:

FriendFeed--my first real post--16 May 2007

At the time, I was busy planning with Steven Kaye and Rachel Watstein an unconference, Library Camp NYC, which was held at the college where I worked and remains one of my favorite things I’ve done in fifteen years as a librarian.

Although I often started conversation topics and commented on lots of others, I was equally enamored of the way that you could plug in various other web services you used and have your activity elsewhere be documented/shared in FriendFeed (Flickr images that you favorited, blog posts and tweets that you wrote, etc.) Over the years, I had hooked up dozens of different services (many of which went defunct or stopped being things I actively used). Here’s a screenshot of the services I had connected as of today:

FriendFeed-services

One thing that gave me great pleasure was the way an article or blog post that I’d read and automatically shared in FriendFeed (via the feed of read items from my Google Reader account and then later via my feed from my commonplace book on Tumblr) would then launch a threaded discussion related to the item shared. It happened again and again, and showed me the power of being able to write things once but publish them multiply for greater network effects.

I would say that among the people I interacted with on FriendFeed, I was moderately active, not the most active commenter but also rarely a lurker. This screenshot take today shows how many comments I’d made and how many people I was subscribed to:

FriendFeed--profile

There have been many wonderful blog posts in the past few weeks from FriendFeed fans about what they got out of the site (and a really nice analysis of and commentary on those posts in Walt Crawford‘s May 2015 issue of Cites and Insights). Since so many wonderful things have already been said, I’ll just say thanks to all my good friends there and hope I find them elsewhere online in the days and years to come.

Can We Stop Manually Adding Ebooks to Our Catalog?

This week, I’ve been helping the head of collection management at my library figure out if we can make a change in the way we make our ebook collections discoverable. For many years, when we’ve bought ebook packages, we would go to the vendors website, download the MARC records, tweak them a bit in MarcEdit, and then get them uploaded into our catalog so they could be found along with our print book collections. Now that we have a new discovery service–Primo–we’re wondering if we can just activate those collections in the Primo Central Index. If we go that route, then we will no longer have to manually process all those ebook records in MARC.

I’ve been looking into each of the ebook packages we have and then checking the following in the Primo (and SFX) documentation:

  • is the package something that Primo/SFX has indexed
  • if the package is indexed, can you search not only by subjects and keywords but also the full text of those books

Regarding the first question, it’s interesting but not at all surprising that some ebook collections we get aren’t indexed by Primo/SFX. Examples include Oxford Handbooks Online and EBSCO’s Ebook Collection (that last one should surprise no one). I also don’t know how we’ll handle a PDA collection like the one we have from MyIlibary. It doesn’t seem like we’ll be able to stop all manual uploads of records into the catalog yet, but we might be able to give up doing it for a few. It’d be nice if we could switch over wholly to a new workflow, but I guess as in many other arenas we have to learn to straddle the new and the legacy systems.

Lenses for My Research Project into Search

This year, I hope to embark on a series of interrelated projects that will help me better understand how students at the college where I work understand search with respect to online systems. I’ve got some very practical and pressing needs that this research connects to; specifically, I want to do some design work on the main search box on our library website:

Search box at Baruch College library website
While I could just do some rounds of usability testing, I think I want to dig deeper given that the stakes seem to be so high here. The search boxes connect up to many different resources that taken together represent major investments from our budget and our staff’s time. I do intend to do some testing, but I’m also thinking about analyzing query logs, surveying students, and conducting interviews or focus groups. I hope that out of this work, I’ll find some generalizable results worth publishing.

To see this problem from various perspectives, I’ve started doing some reading, looking for texts that will serve as method sources in any publications I produce. I’ve started reading works by Carol Kuhlthau to learn more about the information seeking process model she identified. Her model seems like an essential one that will ground my observation and analysis.

Another area where I’ve started doing some reading is social informatics. As it turns out, I’ll be teaching the library’s 3-credit course in social informatics this fall and need to get up to speed fast, as it will be the first time I’ve taught the class. I’m hoping that the work of Robert Kling and others will give me a broader perspective on how students conceive of search in a world characterized by rapid changes in information communication technologies. In his 1999 article, “What Is Social Informatics and Why Does It Matter,” Kling defines social informatics as “the interdisciplinary study of the design, uses and consequences of information technologies that takes into account their interaction with institutional and cultural contexts.” While web design typically takes into account common affordances from the web that you can assume your users are familiar with, I think I want to look more broadly at how students’ conception of “search” is shaped by the institutional context of being a CUNY student and the cultural contexts of search (e.g., what aspects of culture connect up with how they conceive of and typically use search systems).

I hope my readers here will indulge me a bit as I use this blog as a space to try out some of these ideas I’d like to bring into my analysis.