OPAC-O-Matic, what can we ask an online catalog to be?
The short history of the OPAC (Online Public Access Catalog) has seen their early manifestations satisfy the needs of a card catalog being translated into a digital form. As the technologies surrounding cataloging, searching, accessing, and communicating with each other, have increased the OPAC has often been about 6 months behind the changes. This is to be expected, as development of new technologies takes some time, the inordinate amount of time taken for development of library technologies often leaves libraries a number of years behind.
In a recent survey on what librarians wanted from OPACS, Dave Pattern highlights some interesting comments. One of the most obvious, but not unexpected, results was the desire for efficient federated searching. Most libraries have multiple database subscriptions, numerous special collections, countless full-text services, and perhaps even a set of consortial borrowing partners. To search all these resources the user may need to have several browser windows open, be juggling how to maintain a remote connection, and figuring out whether or not they can actually obtain the complete article or not. Though there are many new systems available for executing satisfactory federated searching, there countless factors which may limit whether a library can implement them into the OPAC, let alone actually buy them.
The comment regarding “being able to customize the OPAC” is still rather questionable in my eyes. I think the main concept within this comment is not that the user wants to be able to choose from multiple CSS skins (a leopard print OPAC anyone?) but instead would rather like to collect resources they use most frequently. From this centered point of research a user would be able to search in the manner they prefer, locate the items and articles more easily, and possibly be assured of authenticated access through the library.
Relevancy ranking was also high on the list and as a fan of the new Sirsi/Dynix EPS Rooms product, I am anxious to see how they implement the new clustered search module from FAST . Sirsi/Dynix also utilizes several other interesting features in this product which may begin to breach the divide between merely an online catalog and a research portal for each individual user. Such things as Open URL support, federated searching, librarian selected favorite sites (for different groups of users), and RSS based catalog searches (to which you can subscribe).
The most glaring critique was of the slow development and implementation times, coupled with the broken promises regarding what the library paid for and what was delivered. Again in the realm of software development, the initial product may often go through multiple evolutions before reaching the hands of the end user. Though this is not always a terrible occurrence, the necessity of a vendor to secure the financial commitments from libraries, often leaves the vendor with free rein when it comes to what libraries actually get from the deals.
One final note showed that those who commented felt that the Web 2.0 features currently in development, could become less of a necessity and more of a distraction The long and the short of it is that the OPAC should be there to connect the user and the resource with as little frustration and failure as possible. As long as the user can access that hard to find conference proceeding on fluid mechanics, they may not truly notice if it can slice, dice, and julienne. Then again if those features aren’t bogging down development and making the OPAC unmanageable by the systems librarians, maybe a group of users will enjoy tagging their saved records while reading their RSS alerts from the catalog. But the real question is can an OPAC ever challenge the utility of the Bass-O-Matic?