Internet Librarian 2008: Implementing the Next-Gen OPAC

Internet Librarian 2008: Implementing the Next-Gen OPAC
Jeff Wisniewski

We should not be calling these next gen OPACs or catalogs, but next gen discovery system or search engines.  Their library uses Voyager because of the locked-down nature of their system, the user expectations that the catalog look and function like Amazon and other similar sites.  Their new catalog is in beta: PittCat (running AquaBrowser) and offers a tag cloud, faceted searching, and a clean look and feel.  They were almost ready to go live in late August but rolled the new catalog out in beta and found some data and display issues through a lengthy beta that they would not have discovered otherwise.  Having real users hit and bang on the system uncovers some of the minor problems that aren’t otherwise found without a public beta.  The hard launch will occur after 4 months of beta where the old catalog will no longer be linked to from the library website.  They will monitor usage logs to see how much the old catalog is being used by the public and at some point discontinue the public interface entirely and keep only the back-end which is required (AquaBrowser is only a search overlay).

Their project goals were to have an intuitive interface that didn’t require user instruction, a forgiving interface that didn’t chastise or punish for misspellings, etc., something that exposed more of their collection (both traditional and e- materials).  They also wanted to integrate various silos of information that they had with the Voyager system (local digital collections, ejournals, etc.).  They also wanted something implementable quickly.

They chose AquaBrowser and were able to sign a contract in April and be in beta four months later (with a 5 million MARC record collection).

Selection Process: They put together feature matrices to compare different products that were out there – trying to consolidate that information.  If you can avoid an RFP, Jeff recommends doing so because of the bogged down bureaucratic process that entails.  Be flexible in your requirements – focus on the goals you have not the way to achieve them necessarily.  Realize that there is probably not a product that will do everything you want.  Remember that you are doing it for your users, not your staff. 

When talked to users about what to call the catalog, they preferred keeping the same name and adding a “Plus” and the traditional/old catalog was re-named “Classic.”  AquaBrowser offered them a project implementation wiki that was very helpful to them – this let the staff communicate with each other and with the AB staff.  They also kept an ongoing known issues list as well.

Jeff noted that using next-gen OPAC systems provides an opportunity for libraries to re-examine the usability of their catalogs.  Look at nomenclature and choose plain language, focus on ease of use, finally having the ability to add hyperlinks wherever you want (like a location link to a page with the location hours).  Most next-gen OPACs are overlays that still require the underlying system to remain in place.  Keep that in mind – it won’t fix underlying data errors.  It may expose them more, but won’t fix them. 

Some final tips – stand on the shoulders of others by finding a configuration you like and working from it.  Use onsite set-up assistance.  It is a bargain and helps get things done faster and better.  Decide early on if you’re going to try to tackle all possible changes (data inconsistency, wording, etc.) as part of implementation or to tackle those after launch.  Make sure your catalog has pointers throughout your web presence: a Facebook search application, a search blar plug-in, am embeddable search box, and iGoogle widget, one-click export options, and linked throughout your institution’s webpage. 

IL2008