x

The PLA Blog | Official Blog of the Public Library Association

Not Your Dad’s Interface

Yesterday, Saturday, January 20, I attended the “Not Your Dad’s Interface: Next Generation OPACs and Search Engines” Hot Topics session sponsored by MARS ( Machine Assisted Reference Section of RUSA). And the joint was standing room only, a fact that didn’t surprise me, but did surprise the moderator.

The purpose of the 3-presentation session was to show, to paraphrase the moderator, the next step in the evolutionary cycle of search in libraries, and how the applications implemented by the presenting libraries serve to “reduce siloization” of services and offerings. In my observation, it also shows that libraries are actively looking for improvements on the library catalog interfaces to make them easier to figure out and use, more pleasant to look at, and faster to search.

Tito Sierra from North Carolina State University spoke about their implementation of Endeca as a search interface for their library public catalog. As Endeca’s first library client, NCSU spent a lot of time helping to create an interface and decide what metadata from the catalog records to highlight through the search. The 1.6 million catalog records are exported from the catalog nightly and imported into Endeca on a nightly basis, so that the results are always fresh and clean.

On top of standard keyword searching, Endeca affords such usable features a a true browse using LC classification categories, a nifty link to a new titles search, and relevance ranking (which took some tweaking to perfect), an area that Tito believes is a huge area to be explored and improved in library catalogs. All searches, can be narrowed by “facets,” subject and information type categories, a feature now seen on Amazon.com, Open WorldCat, Koha, and a slew of retail sites. Other “search comforts” include the “Did you mean…” search feature, automated spell correction, stemming, sorting.

David Wasserman with the King County Public Libraries presented on their implementation of AquaBrowser as a visual search “discovery method”. AquaBrowser, produced by MediaLab and distributed by TLC, uses associations, context, spelling alternatives in the metadata to make connections when you look for stuff. The application is *very* visually oriented, stands alone on a separate server and ILS independent, and offers RSS feeds, to name a few cool things. Much like Endeca, the catalog records are exported nightly and imported into AquaBrowser (which lives on a separate server), keeping the search fresh and accurate.

King County set relevance as the default filter in their aquabrowser interface, which is by far the most popular search filter with users. The Additional Resources section tab on the lower right offers a federated search inclusion of databases and local library systems, passed along to those services as a basic keyword search. The Discover cloud, were the search terms are in the center and related terms branch out from the center on the ends of straight lins, is a great visual tool for the wanderer, the uncertain, the visually oriented, and some librarians hate it because it’s not for us, it’s for patrons.

While Grokker (too graphic) and Vivisimo (too texty) were considered as contenders, it was determined that AquaBrowser was just the right combination of both, and it (and the developers) really understands MARC data and how to use it. And, the cool factor totally matters, and OPACs, well, are just not cool. To paraphrase David, we owe it to our patrons to make access usable. The patron feedback reflects this view, where many statements were very positive, even so far as noting that the new AquaBrowser was “more pleasant psychologically,” and usage is at 4,000 sessions a day and growing. While some complaints were voiced about the fact that the OPAC had just been replaced, you know, it needed changing to create better access service, so they did it.

Jody Condit Fagan from James Madison University discussed usability studies she conducted on the EBSCO’s Grokker. The testing was centered around supporting student research, and the problems the visual search can potentially solve. Morae software was used to record everything happening on the screen, as well as a video recording of the student testees. Eight 1-hour sessions were conducted, including 4 groups of two because students often do research in groups, and it’s a more natural search behavior.

The Grokker Map View, which is used in EBSCO, is a nested visual interface, and within the EBSCO interface, you see Grokker on the left and the more traditional corresponding text interface on the right. Clicking on smaller circles of narrower topics within larger circles of broader topics, you can continue to refine your search. Clicking on squares will bring up the EBSCO record in the right pane.

The consensus among the testees was that the Grokker interface was best for general searching, getting to know a topic, and best to use when there was time to play and explore. The more basic text search was used most often when a student knew what they were looking for, needed more direct guidance (the faceted narrowing search topics on the left side help with this) and needed something quickly, because the interface was more familiar.

In her testing, Jody found that many people actually went beyond the first page of results when using the visual search, and they did make use of other options on the screens. The students felt like they received more options for results through the basic search, and that the visual search was not as thorough, which is actually pretty accurate, because the visual search is limited to 250 results. EBSCO is working on making Grokker use the EBSCO taxonomy, instead of allowing Grokker to generate the general topics in the big circles itself (which is what it’s doing now). Currently, 2% of EBSCO search interfaces are visual, and the visual search trend is growing, so Jody encourages showing the visual search to patrons, if you have it available.

If you have EBSCOHost, you click on the “Visual Search” tab at the top and play with this search for yourself, unless you’re one of the few libraries that have disabled this feature. To read the testing results report, you can find it in in the September 2006 issue of Information and Technology Libraries.

Alisia McManus from the University of Binghamton presented a last-minute, quick and dirty presentation on Grokker and Aleph (I love on-the-fly presentations!). She showed off the the combination as an alternative federated search tool to regular opac. There are a few quirks and qualms to the search tool, but given that it’s a work in progress, it’s to be expected. There are bits still being cleaned up, like the way that the Grokker plugin tries to pull in the metadata from the Aleph records, and her department is still working on tweaking it to be just right. They also have no full-time cataloger on the project, which would make things easier, a staffing decision they plan to revisit.

There is an obvious theme here. Catalogs and online resource sharing capabilities in libraries needs to improve, which is something that was a hot button topic in the library blog world last year. These libraries are actually making the effort to go outside of the OPAC vendor family of products to find answers, and while many other libraries would like to do the same, that requires time, money, and resources that smaller libraries and networks may not have.

Also interesting, these were fairly web 1.0 and library 1.0 options. In the Q&A session, this was questioned, and the priority was getting the information to the patrons *before* making it interactive.

The other striking theme is that the trend is to make it external. The original OPAC stays intact, but the metadata is exported to another server, and another application fixes how it presents to the patron, offering a second search option. These are libraries thinking about making an interface for users, going away from having to learn to use an OPAC (while keeping it around for those who really prefer it) to meeting the web searcher’s expectations with more usable options. Someday, everyone will need to answer the question “why have two search boxes when you can have one?” and figure out how to move over.

Write a Comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

Subscribe        

Meta

Pages

Categories

  • Libraries & Librarians

    IMG_20120207_105712IMG_20120207_105648IMG_20120207_105305DSC01428d