The OPAC Debate Continues. . .

John Blyberg over at blyberg.net put together a wrap up of recent blog conversations about the state of the library ILS/OPAC. This is a great post and worthy of a perusal or two - there are some good comments too. On the first subject regarding difficulty with ILS vendors, I feel compelled to keep silent. I do work in systems in an academic library - with a vendor supplied ILS. However, this blog is not associated with my place of work - and my opinions on the matter are only my own. Decisions about our ILS and our OPAC are made by a larger group of which I am but a small part (I may have more influence as the sys admin, but I do not work in a bubble). I do believe it is not fair for me to discuss my opinions of our vendor in this particular forum. I will say that blogs are revolutionizing the ways in which customers can do research about companies and their products. Vendors (as well as customers) need to be aware of the implications of their actions - especially those actions that deal with trying to stifle or intimidate people's right to free speech (or for customers - actions that may unfairly malign a company name).

As for OPACs, John's summation of Peter Murray's Is the Writing on the Wall for the Integrated Library System? got me thinking about several things. Like John, I agree with Peter that the "ILS/OPAC" is an an asset management system tool - one which the library needs in order to operate. I would also agree that OPACs do get used - and add that this is the case in academic libraries as well. Students do tend to gravitate towards database aggregators to find full-text articles first, but they do use OPACs to search for materials with remarkable frequency (remarkable given that recent debates often give the impression that OPACs are unusable). In the library where I work, we could not survive without our OPAC (sucky or not). This does make the OPAC a useful tool as an interface into our ILS. It may not be the best interface and it may not even be the right solution to meet the needs of our users, but right now it is really the only window into the ILS that we have.

Additionally, this post really made me think about the tendency to lump our criticisms of ILSs and OPACs into one bundle. I wonder if this is a mistake. The user doesn't care one bit about our ILS and what it does (or doesn't do). It cares about the interface and the ease of finding information. Users don't want to restrict their search to just our asset management system. As such, I think it would be helpful to separate the two discussions. What we want from our ILS vendor or open-source systems is very different from what our users want/need in our interface into that system. I also think that by lumping the ILS/OPAC together, people tend to focus on the problems with the OPAC rather than on the back end of the interface. To build a better system, I really believe that we need to think of these two entities independently - because they both need revamping. Determine what the user needs. Determine what the library needs. Then, make sure your ILS the information required by both. Anyway, it helps me tremendously to think of the ILS and the OPAC as separate entities.

I do also like John's take on my post Are We Really Ready to Say Goodbye to the Sucky OPAC? From my perspective in a small academic library, we are only just starting to develop the "vision, passion, and courage" that is necessary for change. Right now, I feel like the most important thing that I can do is to help get those I work with to develop a vision, a plan and a purpose. I've said before that without buy in from those with whom we work, we would only be imposing change - which I can only see as hurting the end user. Meanwhile, we work on small change within our current infrastructure - and this is the best thing that we can do for our users at the moment. Some have suggested that spending time on broken systems may be a waste. However, I can't agree. Current OPACs can be made more usable. And I think this is also an important step in this whole process. If nothing else, it helps us define and refine the user experience.