More and more academic libraries have invested in discovery layers, the centralized “Google-like” search tool that returns results from different services and providers by searching a centralized index. The move to discovery has been driven by the ascendence of Google as well as libraries’ increasing focus on user experience. Unlike the vendor-specific search tools or federated searches of the previous decade, discovery presents a simplified picture of the library research process. It has the familiar single search box, and the results are not broken out by provider or format but are all shown together in a list, aping the Google model for search results.
A year and a half ago, I announced that some colleagues and I had started an Open Access, Peer-reviewed journal dedicated to Library User Experience. WeaveUX was born out of the frustration of not having a place for library user experience practitioners to have rigorous discussions about the theory and practice of our work. Of course, UX articles have appeared in many of library literature’s pantheon, but because the venue is never UX related, the articles always spent a lot of time just trying to explain what user experience is, and rarely seemed to get beyond usability testing.
For the past few years I’ve lamented the lack of professional literature for folks doing user experience work in libraries. While UX-focused articles will turn up from time-to-time in publications aimed at serials catalogers, reference librarians, or systems folks, there hasn’t been a single place for Library UX professionals to share and learn from each other.
In the past few weeks I’ve been in several library meetings because the organizers recognized the role design would play in shaping their project. This is a huge leap forward compared to my first library web committee 5 years ago, where design was a four-letter word.
Getting useful quantitative data for how library users search online is difficult. The vendors who make our catalogs and discovery services often provide search logs, but that information isn’t useful for knowing how people behave after the search has been performed. After all, what someone searches for doesn’t tell us whether they found any of the results worth looking at or used the sources in their research.
Every now and then, I make the mistake of reading a library article about the “mobile web.” It’s usually an article with a title like “I am competent at my job, and I have time to tell you about it.” They start by telling you some facts about how mobile Internet use is growing, and that goes for libraries as well. And then they lose me because they start asserting things about mobile users that are crazy.
At GVSU we don’t have single sign-on. We use Active Directory/LDAP authentication, but users need to log in to each service individually. For a library user, that might mean logging into the catalog to renew a book, then logging in again to check course reserves, and then logging in a third time to place an ILL request1. This only gets worse as we develop new tools that require user accounts.
A few days ago, my pal Eric Rumsey retweeted an article on designing “for the fold.” “The fold” refers to a print metaphor for the content that appears on the top half of the front page of a newspaper when it is folded. It’s that content that everyone sees, whether or not they open the paper. In web design, the fold refers to the content that is visible on the screen on the homepage before the user scrolls.
Nicholas Felton’s annual reports are a thing of beauty. He meticulously tracks data about his daily life throughout the year and then collates and designs a report about the year. I could see a great benefit in having this kind of data about my work life at the end of the year for my annual and tenure reviews (especially if it looked like his).
Too often libraries forget to see their websites in a holistic way, and instead approach each page as a new design challenge1. Add to this a lack of consistency across hosted vendor platforms and you’ll be lucky if anyone even realizes they are on your library’s website. That’s why we created a User Interface Pattern Library. Instead of thinking of each page as a new design project, our pattern library shows our design solutions as a set of patterns, which we can use and reuse.
I’m preparing for a talk next week at the Library Technology Conference in St. Paul, and this has me looking at a lot of library websites. And they STINK. Of course, this isn’t really news. People have written about bad library Web design before, and many have defended it because of staff limitations, budgets, etc. But simply designing a “good” website isn’t going to solve the problem. It’s like moving into a rickety old barn, finding it is a bit cold, and installing a programmable thermostat instead of looking at the gaping holes between the clapboards. You see, poorly-designed library websites are a symptom of a much larger problem that technology can’t fix. The problem is a library culture that gives lip service to user needs while really catering to librarians.
Although I’ve worked in academic libraries for the past 8 years, my web development experience is from running my own shop, outside of the University world1. This is a land where results matter more than statistics and reports, and everything you do has a price tag attached to it. As such, usability testing is frequently done on the cheap without a committee to write questions and do recruiting. I’ve kept it that way here at GVSU. The basic tenets of my usability test plan are:
Link resolvers are the backbone of any robust electronic resource collection, connecting users with the full-text items or abstracts that they need for their research. They are often the last piece of the library-controlled Web that users see before being shuttled off to a vendor database. Yet they are consistently the least user-friendly, ugliest, most neglected part of the eResource toolkit.
What strikes me most about the visual identity of libraries is how little attention is paid to the actual identity of the institution when aesthetic design choices are made. This is most evident in choosing a typeface1. Let me explain.
I’ve long been a fan of OpenSearch, the XML format that allows you to add custom search engines to many browsers. Although most users are unaware that they can change the default search in Firefox, Chrome1, Opera, and even Internet Explorer, I still find these tools useful, especially for power users. I created a few OpenSearch plugins for our heaviest users (subject librarians and desk staff) that search both Summon and our library’s catalog.
This afternoon, I’m giving a talk at work about Information Architecture (IA). I’ve long thought that IA (and User Centered Design techniques in general) shouldn’t be hidden under the Web professional’s bushel. IA helps content creators make their stuff easier to find, and nearly everyone is a content creator. Have a Facebook account? Twitter account? Flickr photostream? You’re a content creator.
Libraries used to have a monopoly on information, but the Internet changed that. Libraries are only now starting to notice this change. For the past decade we’ve tried to convince our users that searching the library is often a better solution than searching Google. There is nothing wrong with this, since it’s often true. But all of our energy went into making these arguments instead of genuinely improving our user’s experiences. We ignored our clunky, complicated online catalogs, quickly tossed up long, convoluted help pages filled with library jargon, and tried to convince users that on the other side of these unpleasant Web pages lay the research promised land. Every question answered, every need satisfied. It was easy, we said:
It is no secret that libraries have embraced technology over the past few decades. We moved our card catalogs online in the eighties, began offering public access to Internet-connected computers in the nineties, and continue to bring users into the library by harnessing new and varied technologies. Yet libraries are still running as fast as they can to keep up with five years ago. Why is that?
Most people think that design is just one part in any creative process, something you use to change the look of your creation after you’ve already put in all the working bits. On a website, design means changing the typeface to something sexy, or adding a big photo to give a splash of color. In this way of thinking, design doesn’t have to do anything except look good, like Marilyn Monroe in Gentlemen Prefer Blondes. But this view of design is misguided (and perhaps a little dangerous)1.
It’s no surprise that our users prefer discovery systems like Summon and EDS. They offer a more Google-like interface, and get users closer to finding what they need, and further from searching for it. But sometimes the everything bucket can overwhelm with results. Sure, facets can narrow down the results into a more manageable number, but we know that most users never do this. So how do we help our users find what they need in the everything bucket?
For years, I’ve listened whenever a colleague lamented students’ preference for Google over the expensive, subject-specific databases the library provided. “They just don’t care about their research,” was the common assumption by librarians, frustrated that students didn’t seem interested in advanced search training. “They don’t want to do the work.”