OPAC Manifesto

What We Want: An OPAC Manifesto

by Jessamyn West and friends

The relationship between OPAC vendors and libraries has been getting skewed over time. Online catalogs are becoming more and more like web sites while not employing the nifty tools and interoperability that typifies the web. At the same time, basic functionalities like browser compatibility and web standards compliance are being ignored or slated for some nebulous future rollout. Terms like bookmarklet and RSS and API are a foreign language to many of our OPAC vendors. Patrons and librarians have been creating some of the more innovative OPAC tricks and hacks of recent months. We’d like to restore co-operation to the vendor/client relationship and offer you some well thought out ideas of how your products could, with small alterations, actually resemble what we want, not just what you are willing to give us.

What Library Staff Wants

– We want the OPAC to come with out-of-the-box help files that make sense, or at least point to more information online. We want the help files to be relevant to our install, not a generic install.
– We want our customizations to the OPAC to not be overwritten by the next OPAC release when we install it.
– We want to be able to change the colors and other minor style points of our OPAC without having to edit cgi files. We want solid documentation for how to customize our OPAC at the minimum, and would prefer a web interface.
– We want Easy icons for distinguishing materials. Ones that can be based on 008 or 300 or 6XXv or location in the holding record or…
– We want the option to pick citation format of search results. Like RedLightGreen.
– We want you to map keywords to subject headings. (See again RedLightGreen)
– We want an option to turn the graphics off so that we can use the OPAC in “quick mode” and possibly look at more than ten records at a time.
– We want to be able to put URLs in fields other than just 856 (for instance in contents notes, TOCs, etc.)
– We want our vendors to implement FRBR structures (so patrons won’t have to know anything about Uniform Titles!).
– We want classification access, something like Windows explorer, or an outliner.
– We want to be able to move around the OPAC screens easily using either the keyboard or the mouse, depending on our preferences.

What Geeks Want

– We want to be able to access the OPAC server securely via ssh. We don’t want to have to use telnet and we don’t want you to recommend that we use telnet.
– We want REST, or even better, SOAP access. Then everybody with a good idea can easily create and distribute it.
– We want XML CSS display of search results. That way we could fix and change the results to best suit our patrons.
– We want an easy RSS feed generator. So I can decide what would serve best my patrons. New releases. New releases in QB. New releases with Mars in 6XX.
– We want complete and thorough documentation of every technical aspect of the product – including full database structure and notes on non-apparent data associations – on your website. We want this to be searchable and updated regularly.
– We want all standard library functions (including customizable report generation, periodicals management, home delivery tracking, direct SQL access, etc.) to be included with the basic product, rather than sold as overpriced modules.
– We want the ability to design our own modules in a standard programming or scripting language (C++, PERL, PHP, etc.).
– We want a fully documented API to be made available to help with this process.

What Users Want

– We want the OPAC to be in our language. We don’t understand words like xrefs, serials, or the difference between keywords and subjects.
– We want the OPAC to be in our language; meaning, we want everything on the screen (not just a few words or the words that aren’t in images) to be in Spanish or Russian or Vietnamese when we ask for that option.
– We want easy to download search results to Palm.
– We want the OPAC to be a part of the library’s web site, not an entirely new destination.
– We want the online version and the in-the-library version to look and act the same.
– We want help files that are helpful and make sense. We want the error pages to make sense and help us figure out what we did wrong.
– We want an interface that is customizable so we can see more results, turn images on or off or make the type bigger or smaller
– We want the OPAC to work on our browser, whatever it is.
– We want the option of cookies so that we don’t have to type our library card in each time we see what we have checked out from home.
– We want to be able to right-click links and open them in new windows. No javascripting links, thank you.
– We want the back button to work when we use the OPAC.
– We want to be able to limit and sort _before_ we search.
– When we do a title search, give us exact matches first, Alt Titles second.
– We want the item location to be in English, not library code.
– Help us when we make spelling errors. Google does.
– We want keyword searching by default. The OPAC should recognize authors, subjects and other terms and automatically translate them for us. PubMed and Amazon do that, why can’t the OPAC?
– We don’t understand author authority records or why libraries care about pseudonyms. We want to be able to search by an author and see a list of titles, not be told to search under a different name.

We know that a lot of OPAC vendors have been taking steps towards our dream of a glorious federated searching standards-compliant feed-enabled extensible library OPAC future and for that we thank you. Think of this as a mid-course correction along that path. Join us!