Forcing Users To Learn The Catalog
I’ve taken a couple of weeks to mull over a comment I heard recently. Earlier this month, I spoke to a group of academic librarians, mostly non-techies, about how well we deliver our search services to a user population that has literally grown up with Google, Yahoo, and Amazon.
Typically, the most illustrative part of the meeting was a question and answer session. Part of what it illustrated to me was the intransigence of some strongly held opinions: that simplifying user interfaces necessarily equates to “dumbing them down”; that keyword searching is inherently untrustworthy; and that adapting search interfaces to meet user expectations requires loss of functionality.
And this was the comment that I keep chewing on: “Students are in college to learn, so what’s so bad about forcing them to learn the catalog?” I’m still not sure how best to respond to this (although, “Isn’t that what we do now? And why we’re having day-long conferences on why our users are migrating to Google?” is high on the list).
I have to conclude that the persistence of these biases is a damning indictment – of library technologists. Too often, we fail to communicate to others in our organizations, in language that’s meaningful them, about what we’re really trying to accomplish; we tend to assume that all our colleagues are interested in, and keep up with, technology trends; and then we’re astonished when we find librarians with only a hazy image of what we’re trying to accomplish.
Here a couple of points I hope I communicated to this group of librarians.
First, a library web site--when and if users can find it--has to accomodate users who are scanning quickly to find any likely path to rich content, and many of these users expect and prefer to jump into a large body of content via a search box. Despite this, in a group of 82 library home pages I surveyed recently, 30% had no clearly labelled visible link to the catalog. Fewer than 20% provided a search box for the catalog on their home page, and only one provided a search box for a metasearch service on the home page, although both of these options are available to all of the libraries I surveyed.
Second, we work with data that the Googles and Yahoos of the world would give their right arms for, but don’t take advantage of it. We can trust that the abstract for an article in Nature isn’t deliberately misrepresenting the article’s content. We can look at a citation like Jane Eyre by Charlotte Brontë, published by Charles Scribner, and unambiguously tell which name means what. And while we worry that our controlled vocabularies are fuddy-duddy relics, collocating items in an information space by “what they’re about” is an amazing ability; the sort of faceting and clustering that Internet search engines have to work so hard at ought to be simple for our search services. And the notion of traversing a subject tree from the general to the specific – or vice versa – blows the doors off what Internet search engines can do. So we just need to make all this fantastic data structure usable and engaging for searchers (simple, no?).
Third, meeting user expectations, no matter how quickly they change, is not only a Good Thing, but an absolute necessity.
While there may be an expectation that students are there to learn at an academic institution and therefore can be expected to learn how to use the library as part of their education, public libraries also make users learn how to use their services.
Wouldn't it be nice if there were simple google-style search boxes on the library's main page? Perhaps one could be labeled "books" and search the catalog. Another could be labeled "magazine articles" and search online databases. Of course, one box that would cross search all available resources would be even better. And have prominent help buttons so individuals could get assistance if they can't find what they're looking for quickly and easily.
Suzanne Reymer
Montana State Library - Billings Office
Part of the issue is that doing this stuff is HARD. Is keyword search inherently untrustworthy? Google proves not neccesarily, but the thing is, the _genius_ of Google is that it made keyword search actually work! This is not an easy thing to do, and they did it, actually, not just with a straight keyword search, but by recognizing that incoming link text is a kind of descriptive metadata. We don't have the same kind of metadata in a library catalog.
So I get frustrated when people think, gee, Google works, Google is keyword search, so if we just do keyword search in our catalog, then it will work, and be as good as Google, cause that's what we need to do to compete with Google. There are so many misconceptions there.
So yeah, we should figure out how to make the catalog easier to use, part of that is figuring out how to get a 'single box' seach that works (for SOME purposes), but it's not easy to do, and won't come just from trying to ape Google.
Secondly, the point about having all this cool structured metadata: Yes! This is an important point! So much of what Google (et al) do is a clever (very clever) way around the fact that they _don't_ have rich trustworthy metadata. We do! We should be able to do a lot MORE than Google, in fact. However---this too is hard. Partially becuase, sadly, our descriptive metadata is not made for an online world, not always suitable for doing the kinds of things we want to do with them. LCSH, for instance, the fact that it inconsistently uses subdivisions, BT/NT thesaural relationships, alphabetic term order (including sometimes inverted order, sometimes direct order)---uses all of these mechanisms (and more) in an inconsistent way to indicate relationships between classes----this makes it hard to let people traverse a subject tree in a comprehensible way. It's (technically) hard (but not impossible) to do this with the present LCSH; and it's (socially) hard to change LCSH.
But, this is indeed the task we have before us. We (the library community, and library technologists), without a doubt, do need to make the catalog easier to use. We need to figure out how to do this _without_ dumbing it down. We need to, in fact, figure out how to add more advanced "smarting up" features that we theoretically should be able to be providing with our rich and trustworthy metadata. But to do this is both a technical and a social challenge, and the social aspect might be the most difficult.
Ideally, there would be all sorts of research in academia on these things going on, supplementing our professional experimentation. But sadly, I think that we, as a profession, aren't supported as supported as we could be in this area by an academia to serve as our R&D wing, to the extent that other professions and sectors are with analagous problems. This is problematic too, that should be the role of academia. [One possible exciting exception is Jennifer Bowen's incipient XC project].
Jonathan,
I couldn't agree more, and I've said as much many times in talks before library groups. We can't simply dumb down our interface by reducing our search box to Google-like simplicity -- that would be idiotic. No, in order to be simple on the front-end we need to be complicated on the back-end -- and there's the rub.
Libraries have not been good (historically) about pushing the technical envelope. But that may be changing. Between the RedLightGreen.com project of RLG (now part of OCLC), NCSU's new catalog, and the University of Rochester project that you reference, we now have a number of good models from which to learn.
A tale I often tell is putting the intelligence of a reference librarian into the system. For example, a common trick of reference librarians is to do a title keyword search, find a useful record, look at the subject headings, then reperform the search using one of those subject headings. From the perspective of our users, the interface of RedLightGreen.com or NCSU's catalog provide this same "trick", but simply through surfacing those headings in a way that makes them much more useable.
This is the kind of "intelligence" that is required in order to "dumb down" the interface. I will continue to hit on these points, and I hope you do as well. We can do better -- much better -- and we should.
I agree with much of what Jonathan says as well. As a practicing cataloger, I work very hard at trying to catalog things in such a way as to make them easier to find and access later. And, I would absolutely love to be able to make it easier for people to take advantage of all of the work I've put into organizing things for later retrieval. A few barriers as I see them:
1. There seems to be little interest in investing in developing systems that support cataloging work. Catalogers spend an inordinate amount of time looking up codes, classification numbers, and subject headings; verifying the accuracy of data between printed piece (TV screen, computer monitor, etc.) and online record; checking spelling and other descrptive elements in catalog records, and similar mundane tasks. Many of these tasks are critical for retrieval, so they must be done. Many of them are also done better by technology than they are by people; unfortunately, a typical "cataloger's desktop" in this day and age is a hodgepodge of websites and software applications that don't allow for seamless interaction, and certainly don't do things like helping catalogers to see relationships between records based on statistical analysis or any of the fancy things that proprietary search engines like Google can do. If catalogers were supported by better systems, they could spend more time on important tasks like subject analysis that only humans can really do well, and they would get higher quality work done faster. I am envious of the systems that professional indexers (who work for all of those database vendors) have ... Instead, catalogers' work is equated with simple data entry and seriously undervalued by many managers in the profession.
2. Catalogers (and librarians in general) have very little control over the design of the systems that house all of the data we meticulously maintain. Hopefully, with the development of open-source library systems and the advancement of web design functionality, this is changing. But the fact remains that few libraries have professional programmers or even web designers on staff to develop or even just implement the latest and greatest features. And very few of us have the time to develop "professional" grade programming skills while we're busy trying to run our operations day to day. Again, in many libraries, just like with cataloging, the "technical" work required to develop and maintain slick web interfaces is undervalued in comparison with "face-to-face" tasks such as providing personal reference service.
There. I don't know if it will do any good, but it feels good to get a few frustrations out there.
Great points and insights, lincis, thanks.
I too, as someone just entering the field, am somewhat astounded by the primitiveness of software supporting cataloging. (Just the simple fact that so many catalogers are entering coded fields by hand is astounding! Coded fields are meant for machines, not people! This sort of thing seems like it must play a role in the much talked about expense and inefficiency of the cataloging community, and is probably worth paying at least as much attention to as proposals to scale back the work cataloger's do instead!)
Anyway. One step toward addressing this stuff would be some kind of a regular round-table opportunity/organization including catalogers and systems developers (both commercial and open source). Does anything like that currently exist?
Many good comments, though I keep circling back to “Students are in college to learn, so what’s so bad about forcing them to learn the catalog?” It's so descriptive of the skewed perspectives and fantasies that hold us back. OCLC's latest remix on their Perceptions report made that clear.
To lead in the arena of optimal discovery, we need to find the sweet spot between the expensive, artisanal metadata creation methods versus slapping a search box on top of full-text-gorp. But then, if you've seen various screen captures, even Google seems to be recognizing that as well.