More Thoughts on Language Usage and Design

Building on what I wrote about in yesterday’s post, “Watching the Language Parade of Our Users,” I want to add some miscellaneous thoughts I’ve had since that complicate the stance I took about the need to pay attention to what words our students and faculty use (especially the ones that relate to tasks that might bring them to the library website). One of the words that I mentioned in yesterday’s post, “loan,” is notable mostly because students sometimes use it in a way that I’d consider incorrect. When a student says that they’d like to “loan something from the library” or that they have “loaned a book and want to know how to return it,” I understand of course that they really mean “borrow.” I suspect that if I were to correct a student in person (and they weren’t too annoyed with me for doing that), they’d quickly recognize their error. Typically, when I hear a student make a mistake like that in a reference or classroom interaction, I try to gently introduce the correct usage without being overly obnoxious or direct about it (“If you’ve borrowed a book and want to return it, here is how to do it.”)

When it comes to writing for the website, there’s often (but not always) an opportunity to write in a way that discretely introduces users to jargon and usage that is essential or useful. But when you’ve got a button or link you need to add a label to, your options are more limited. You’ve got to choose just one word or phrase that fits in the allotted space, is likely to be meaningful to the least sophisticated user but still recognizable to the most advanced one, and that strikes the conversational tone that you aim for in all your writing for the site. The challenge with language, though, is that it is ever evolving, and your choice today for that button may not work too many years down the road.

The word “rent” offers a notable challenge for library websites. Increasingly, I hear students say they’d like to “rent a book,” a phrase that I still find jarring. I also find it a bit upsetting, too, because to my ear it connotes a commercial interaction even though our borrowing services are free (unless you want to get technical and figure on how tuition and taxes figure into the cost to the user of borrowing books). I think it’s safe to assume that most (if not all) of our students get that there is no cost to borrow books, and yet they increasingly use a term that carries the whiff of money being exchanged. At what point will I need to seriously consider using the word “rent” in some way on the website? How common a usage does it have to become before I give in? I don’t have an answer, but I do think I need sit with these usage questions and not forget about them.

I should note that well before I transitioned from being a reference and instruction librarian to a UX librarian in 2010, I was fascinated by “Library Terms That Users Understand,” a website maintained by a librarian, John Kupersmith, who was formerly at UC Berkeley. Kupersmith’s site reviewed usability studies that answered questions about terminology and labeling and then tried to boil down the findings to best practices. Although the site is long gone, much of the content can be found in the eScholarship repository at UC Berkeley.

I’d like to mention two other sources that notably deepened my appreciation for the importance of user-centered language. First, a classic UX book by Steve Krug has a title that says it all: Don’t Make Me Think. Users are often task-driven, and if they have to pause too long to figure out what an ambiguously worded label or link means on a site, their satisfaction with that site starts to dip, sometimes precipitously. The other source is a terrific blog post from 2013 by librarian Barbara Fister, “Tacit Knowledge and the Student Researcher,” which “identifies the tacit knowledge many of us [librarians and faculty] have about information and how it works based on experiences that our students haven’t had.” Although the post isn’t directly about language use, it speaks to a familiarity with concepts that we can’t assume all of our users have; for me, learning to recognize these mistaken assumptions about what students already know helps me keep in check my tendency to fall back on library jargon when writing for the web.

One idea I’d like to learn more about and apply to my work as a UX librarian are “mental models” and how those may guide interactions users have with our site as they work on a task. There’s a rich literature in the social sciences about mental models that I need to dip into. I’m thinking it also connects up with the research being done by librarians into the issue of “container collapse,” as a student who doesn’t even know what a scholarly source is and how it can be recognized in part by the container it comes in will have a hard time navigating our websites when they’ve got a task assigned by a professor to find scholarly sources for their research paper. As we design for our websites things like custom search boxes, research guides, help documentation, instruction videos, etc., our work can be strengthened if we have a deeper appreciation for how our students understand the information landscape and what terms they are currently using to label its landmarks.

Watching the Language Parade of Our Users

As a former book editor whose wife is a freelance proofreader and copyeditor, I have to work hard to stifle my inner prescriptivist when it comes to language usage. As a UX librarian, though, I have to pay attention to the language our students and faculty use at my college and respect it as much as is possible if I hope to make sure that our site and services align with the way our users speak. Back in 2017, I was struck by this great quote by John McWhorter, a professor of linguistics at Columbia University, from an interview of him on an episode of the ever fascinating podcast, Hidden Brain:

Language is a parade, and nobody sits at a parade wishing that everybody would stand still. If the language stayed the way it was, it would be like a pressed flower in a book, or as I say I think it would be like some inflatable doll rather than a person. I think that it’s better to think of language as a parade that either you’re watching or, frankly, that you’re in, especially because the people are never going to stand still. It’s never happened, it’s never going to. And if you can enjoy it as a parade instead of wondering why people keep walking instead of just sitting on chairs and blowing on their tubas and not moving, then you have more fun. I want everybody to have the fun I’m having.

For anyone who has struggled to tinker with language on a website, you know how hard it can be to balance the demands to be concise, clear, and understandable. As language shifts, we have to be ready to tweak the language we use so that we don’t confuse our users or otherwise put them off (“The library’s facsimile machine can be found next to our laser printers and our ready reference shelves.”)

Here in no particular order are some bits of usage that caught my attention when I first heard them and am wondering when I’ll be ready to use them in some fashion on our site.

  • “loan” used in a reversed manner, as in the student who says, “I loaned a book and was wondering when I have to turn it back in.”
  • “rent”, as in “Can I rent a book?”
  • “journal” used to actually mean “journal articles,” as in “I need to find a journal on how left-handed broccoli farmers have navigated changes in agricultural technology.”
  • “in stock,” as in “Do you have this book in stock?”
  • “search up,” as in “I was trying to search up a book in the catalog but could use some help.”
  • “the library website” used to refer to our discovery service or a database, as in “I was searching the library website for info on the marketing of electric cars in Japan but was having some trouble.”

Where are the Online LibUX Communities?

This is just a quick note to ping the library UX community to see where it is that most folks are gathering online to talk shop. If anyone can fill me in on the state of these communities and how viable they still are, I’d appreciate it greatly. As you will see in my quick review of the sites that I’m familiar with, I’ve got some preferences about spaces where I’d like to be a visitor and others where I’d rather be a resident (see David White’s work on the visitor and residents model for more on that concept).

Library UX on Slack

Home: https://libux.co/slack

Register: https://libux.herokuapp.com/

Until the pandemic set in last March, I used to be quite active here. It was a busy place at times, and then lately not so much. Among the online communities I’ve kept an eye on, this one was usually the busiest. One notable downside about it is that it’s a free Slack space, which means that only the last 10,000 messages can be viewed or searched.

#libux on Twitter

Home: https://twitter.com/hashtag/libux

Although I’ve been posting to Twitter since early 2007, almost all of that activity has been me sharing articles and blog posts that I’d saved in Instapaper and thought to be worth sharing (I’d set up an integration between the two services to auto-tweet any saved item that I’d favorited). Although I am more of a visitor in Twitter, I can envision becoming more of a resident there if the libux hashtag gets used more. There’s also a uxlibs hashtag, but that seems to be used mostly for the annual UXLibs conference in the UK that I’ve heard great things about since its launch.

UXers channel on code4lib Slack

Home: https://code4lib.slack.com/

Register https://code4lib.org/slack

Not a lot of traffic here in a while but it would seem (in theory at least) to benefit by being within the code4lib community, which has long been very lively in various online spaces. This is also a free Slack space, and so has limits on how far back you can view or search messages.

Library UX Community

Home: https://luxcommunity.web.illinois.edu/

Register: https://luxcommunity.web.illinois.edu/registration/

I’ve always been partial to the bulletin board style forum, which this WordPress site offers. It hasn’t had a lot of traction yet but holds promise.

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.