The greatest amount of action happening today regarding library user services is the separation of the user interface from the integrated library system (ILS). This seems odd, perhaps, since only two decades ago the integration of all of the functions of library systems was seen as a real step forward. Until then, one system had handled acquisitions, another circulation, and another cataloging. Many functions, such as serials check-in and bindery management, were not managed through automation. This situation had a number of problems: different data about the same book were stored in multiple databases or in card files, leading to inconsistencies throughout the system; the data had to be keyed or copied multiple times; system-wide updates were nearly impossible. The "integration" of the integrated library system was the creation of a single database for bibliographic and management data, where all of the information about an item would be stored once and only once. This also was the first time that the full bibliographic record was linked to the library management functions. Independent systems like acquisitions and circulation systems primarily used brief records only. At best, these brief records contained an identifier (such as the item's barcode or call number) that could connect it to other records in other systems. Sometimes even that wasn't possible.
In theory, this database integration is a dandy way to organize your data and the activities that use your data. In reality, the user interface suffered in this design. Not that anyone purposely shorted the user interface, but in a world of scarcity, there are things that just have to get done; and then there are other things. In the have to category, libraries have to make purchases, manage accounts, receive and check-in serials, perform interlibrary loans, and check items out to borrowers. These are clear, quantitative, auditable library functions, and ones that library administrators focus on. These are the functions that can have dollar amounts attached to them in terms of staff time. These functions are the inside view of the library, the library being a library.
User success, on the other hand, is qualitative, hard to define, and does not have a direct effect on the library's bottom line. We count the countables, like numbers of bibliographic records, items circulated, and online database accesses, but there appears to be no penalty for a lousy user interface and no premium for the creation of a good one. If at any point there is a conflict between quantitative library management and qualitative user service, my gut feeling is that the latter loses out.
Users have everything to gain from the separation of the user interface from the library management system. Libraries, however, are in a bit of a bind. The new "user interface on top of the ILS" adds features for users but it doesn't result in any less work in the ILS. Libraries are still hanging all of their management functions off of full bibliographic records in the catalog (which the users no longer see). Librarians still see the data creation functions in the early management steps of acquisitions and receipt to be a direct line to the standard bibliographic record that in the end will appear on the users' screens. They are still storing the full bibliographic records in a local database, although these records are siphoned off nightly to the "real" user interface.
Much of the objection to using more EDI (electronic data interchange) functions with our vendors is that their data doesn't conform to library cataloging. Yet our library management systems are getting further from the user interface. We may need to rethink the library management workflow as well as the basis of our cataloging activity. What could we achieve if we move cataloging and catalogs out of our individual library databases to the network level? Could this provide the basis for increased sharing of the cataloging effort? Are there other efficiencies that could be gained in the "back room" functions of purchasing and managing the library inventory?
4 comments:
Your use of the pronoun "we" is offensive. There's no "we" here. It's just you. You want to kill information access in libraries. You want to kill high-quality metadata in libraries. Instead of promoting improved information discovery tools, you wail about how much you hate MARC and scheme to slander and kill it. The real "we" is those of us who actually work in libraries and observe the day-to-day interactions of information seekers. We are not in a dark room in the East Bay somewhere, mad that we were laid off from Melvyl. We are trying to build; you are trying to destroy.
Jeffrey,
Perhaps you can console yourself with the thought that I am just one person and people are free to ignore me. (BTW, the room is bright, west-facing and looking out onto a garden. It's actually quite nice.)
I think it was Bates who made the observation that many in the profession became 'fused' with the information retrieval model that emerged at the onset of wide-scale library automation, i.e., mid to late seventies. I must say that I found that a penetrating insight.
Many (most?) public interfaces grew directly out of RFP requirements which were articulated (in the OPAC section, anyway) by public services staff in the first place. I doubt that many technical/systems oriented staff in that formative period of ILS development were given much chance to influence the OPAC (aka user) design, frankly, even though many had a firm knowledge base and were keeping pace with search studies/research being carried out (e.g., Markey, Mandel, etc.)
Many professionals in the "back room" are in a far better position to recognize, influence, and capitalize on infrastructure trends (such as decoupling parts of the ILS). Most interesting stuff that is going on, is surely taking place in those back rooms (e.g., EDI, ONIX), etc.
I find that those on the front lines (as opposed to in the back rooms) need far more convincing to move away from the 'integrated system' and towards the 'integrated experience'.
Mia Massicotte
As someone who has worked with library systems, standalone and integrated, for almost twenty-five years I'm surprised at Jeffrey's reaction. Karen is raising valid questions, ones that we continue to revisit in order to make our services, systems, and communications formats meet the evolving needs of our patrons. I teach my students about the evolution of library systems and try to impress upon them the importance of not becoming too wedded to one approach in this rapidly changing environment.
Post a Comment