By Meredith Farkas | May 13, 2005
I recently had an interesting discussion with a librarian regarding the usability of OPACs. I, as usual, was arguing that there are lessons to be learned from Google, RedLightGreen, and Amazon in how information retrieval systems should be designed. He replied, “at some point don’t you think the responsibility should rest on the students? How much should we have to dumb things down for them?” Ugh… I have a difficult time dealing with that kind of thinking, particularly because it is so insulting to the students who have trouble using the OPAC. People like that see students having trouble using the OPAC as deficient and don’t consider that perhaps the OPAC is deficient. They see the OPAC as something students should learn — like calculus and the pythagorean theorem. In that conversation, I felt much like Todd Miller who wrote the insightful piece, In Defense of Stupid Users:
At the American Library Association Midwinter Meeting in January, I attended yet another industry program—this one under the aegis of NISO on metasearching—where attendees in a packed room discussed various aspects of searching lots of databases at the same time.
I should have clocked the time it took before someone voiced the obligatory disparaging comment about the ignorant user searching “Britney Spears.” Similar comments came on the heels of the haughty laughter ridiculing the typical unenlightened user’s inability to craft beautiful search strings replete with wildcards, Boolean operators, and appropriate filter selections. It doesn’t seem to matter the intended meeting topic; we just can’t wait to dump on the user.
It then occurred to me that maybe it was not the user who was unenlightened.
I know it’s “crazy”, but I see the OPAC as a tool used for finding material in the library’s collection, and believe therefore that it should be designed so that people can easily find what is in the collection. If it isn’t designed for the patron, who should it be designed for? Perhaps the problem is that there is a large gulf at his library between the systems librarians and the “traditional” librarians, and it’s easier to see the problem as an educational issue than a problem with the middleware. He can teach people about Boolean operators, LCSH, and the differences between subject and keyword searches. But even if he agreed that the OPAC was imperfect, he still wouldn’t know how to make it better. But there are a growing number of librarians who do know how OPACs could be better. People like Ross Singer, who wrote this post that made my heart melt:
We just had a professional usability study done on our web site and services. The results were rather sobering. While not every aspect of our web presence is bad, a great deal of it is, and, worse, the bad parts are generally the most important. Making the situation even more complicated is the fact that a lot of these awkward interfaces are not under our control (the databases, ejournals and opac). Well, not currently under our control.
I’ll skip over the part about our website (we’re able to fix that pretty easily) and write about what they recommended for the catalog. The first screen they gave us was a redesigned search form. An interesting dialogue came out of that:
Usability Expert: Ok, so this is the search form…
Librarian(s): So… is this the simple search form or the advanced search?
Usability Expert: This is the search form.
And it really is as simple as that. It is a text input field that, by default, would do a keyword natural language query on the catalog, or you could add limits and filters (title, author, subject, etc.) or make a more sophisticated boolean search using the exact same form.
It’s sad that the idea of having a usable OPAC is considered revolutionary, but too many librarians reading Singer’s post would be horrified at the idea of a single search box. To me it makes perfect sense, because that’s what our users are accustomed to. I will definitely be reading Singer’s blog from now on.
Ross Singer and other tech-savvy librarians are trying to take control of library middleware, to wrest it out of the hands of vendors who seem to be designing interfaces for librarians (if even), not patrons. Library vendors often seem to be slow to innovate. They are about the bottom line, not your users. So there is little reason for them to innovate unless their competitors are doing it (as was the case with OpenURL and will be the case with RSS feeds). I also spoke this week with a library administrator who had recently dumped the library’s virtual reference software because they’d had so many problems with it and it required so much effort to use (like disabling Java). They’d mentioned their problems to the vendor, but the vendor didn’t lift a finger until they were told that the library was not going to renew their contract — and by then, it was too late. It shouldn’t have to get to that point, but all too often it does. And most librarians don’t know enough about computers to really fight against something they know is not working the way it should, or could. A library that lacks a single tech-savvy librarian is at the mercy of its vendors.
While most of us don’t have amazing systems librarians at our libraries who can design an entire OPAC for us singlehandedly, we needn’t just sit on our hands. We all should pay close attention to what people like Mark Leggott, Ross Singer, Art Rhyno, Kevin Stranack, Dan Chudnov, Roy Tennant, and others are doing and saying. We may not understand everything they write about (I certainly don’t sometimes), but it will help us to understand how our middleware can be better and can empower us to demand more from our vendors. In a perfect world, large library consortia would work together to create better middleware (like what’s happening in Georgia with Evergreen or COPPUL in Canada). No one would be left out in the cold. Sadly, this does not happen enough. Libraries rarely work together to create change. Why can’t a library system develop its own Integrated Library System that addresses their need for real resource integration? The usual objection is “we don’t have the resources”. Well, why couldn’t a bunch of libraries get together and develop their own system? We’re not exactly an antisocial profession, are we? I think this is often caused by a lack of vision on the part of our library leaders — many of whom have lived just fine with imperfect systems for decades — that leads us to accept the status quo. Because, in the end, it’s much less challenging to put a band-aid on a problem (teaching information literacy) than to challenge ourselves to understand and fix the source of the problem.
Hearing from folks like those I mentioned above gives me hope that one day our library middlware will actually be designed for our users. We should all be doing usability testing of our catalogs, our databases, and our websites. And it shouldn’t be just about offering a bunch of students pizza in exchange for them giving their opinions on the middleware. We should all be getting professional usability experts into our libraries. We need someone with professional distance, someone who knows what to look for, and someone who doesn’t think like a librarian. I know many will say, “we can’t afford it”, but is it something you can afford not to do? What’s the point of having these expensive collections of print and online texts, indexes, and journals if no one can find them? If we were doing a library technology hierarchy of needs, usability should be one of the absolute foundational pieces at the bottom of the pyramid.