I found this via the LibrarianInBlack’s FeedBlitz (which is the only reason I manage to keep up with her postings) and it is so cool, I had to pass it along. She says:
David Lee King wrote about adding the MeeboMe Widget to his library’s catalog. It shows up whenever there is an unsuccessful keyword search. This way your users have on-screen access to live help from library staff when and where they often need it–while using our confusing and multi-layered catalogs.
LiB points out that the the catalog is the primary point of contact for our customers/users so this little widget ensures that they have access to a real human being whenever they need it. I love it.
The only glitch I found with how it has been implemented at Topeka & Shawnee is that very few searches result in 0 hits because they convert your query to a browse query and display titles that are maybe close to what you were going for. I had a hard time coming up with a search that gave me nada so I could see the MeeboMe widget pop up. With such a resource at the ready, maybe it isn’t necessary to convert all the searches to browse mode….
In her 1996 article entitled Why Are Online Catalogs Still Hard to Use? (Journal of the American Society for Information Science 47(7):493-503, 1996), Christine Borgman discusses the fact that OPACs are used for “querying” when in fact what the public needs is a tool that facilitates the complete process of “information seeking.” She explains that researchers have found that “users formulate questions in stages, gradually coming to the point where they can begin to articulate a query.” She goes on to say that the search process should be iterative so that “searching may serve to refine the question rather than build a set of documents that matches an explicit query.”
When catalogs were computerized, they were developed for information professionals. Back then, the librarian served as the intermediary between the catalog and the user and the librarian’s job was to conduct the reference interview and then, having identified the information need, construct a query responsive to that need.
But somewhere along the way, we have moved away from that model of librarian as intermediary and the tools originally designed for professionals are now in the hands of “perpetual novices” (Borgman, 1996). You see, vendors know how to leverage their products. They took the interface designed for professionals, added some neat new graphical elements like buttons and dropdown menus, labelled it an OPAC, put a big fat pricetag on it and bingo the public interface was delivered. [Addendum...one vendor is actually trying to do something completely different that is more responsive to user seeking behavior...checkout TLC's AquaBrowser.]
So, what happened to that all important step of the reference interview in this new OPAC world? Hmmmm, bye-bye.
But at what point is it the responsibility of the information professionals to demand that the vendors actually design an OPAC for users. An OPAC that doesn’t presume that our users are information professionals. That doesn’t presume that our users are English speakers with a college education. That doesn’t presume that our users have perfect vision and use of all their limbs. That doesn’t presume that people understand Boolean logic or authority lists or how the author field is populated. And my personal favorite…doesn’t presume that people understand the difference between a keyword and subject heading.
We need an OPAC that is designed for our users. An OPAC that is intuitive and easy-to-use, based on universal design principles and which doesn’t disregard information seeking behaviors. But if librarians don’t demand it, it ain’t gonna happen. Let’s stop letting the vendors determine what products libraries use and start demanding what we want.
Here’s some ideas:
- Include details of what we want in our system in RFPs rather than using RFPs to describe existing products.
- Conduct user testing of interfaces and publicize the results.
- Encourage librarians to become system designers.
- Write Help Documentation for users that addresses the design shortfalls of the OPAC.
- Train users whenever you can.
In the December, 2004 issue of Information Technology and Libraries, Holly Yu and Margo Young report that web searching is changing our user’s expectation of how the OPAC works. Specifically, they report that users typically type two terms in the search box, have an average of two queries per session, don’t use complex query syntax and don’t want to view more than ten documents in a result list.
The article, entitled “The Impact of Web Search Engines on Subject Searching in OPAC” suggests some changes we can make to our OPAC interfaces that our users will appreciate:
1. Menu Sequence Matters: users are much more likely to choose the first option on a dropdown menu. Make sure you put the choice they prefer in that position.
2. Users don’t understand what’s in the catalog. Get that metasearch interface rolling!
3. Users don’t know the difference between keywords and subject headings. Start users off with a keyword search. If you offer a subject heading search, make sure you specify “LC Subject Headings” and provide instruction about what that means.
4. User searches fail…a lot. If possible, devise a search interface that helps them succeed. Some ILS vendors are offering this now (Innovative’s Advanced Keyword Search feature, for example). If your vendor doesn’t have it yet, demand it. Provide spellcheck and some kind of mapping to your controlled vocabulary when possible.
There’s lots more in the article. These are just some of my personal favorites. For more info, visit Holly Yu’s website where you can view several papers she’s published on this topic.