Jumbled Thoughts: My OPAC Online Catalogue Sucks…

Life as I Know It has a very useful list of various blog postings on the issue of OPACs. And I think Jennifer is on to something when she states:

The function of OPACs is not clear to average library users.

Only, I would go further and say, the OPACs function may not only be unclear to the user, but also to the librarian.

And this is why: I think one of the inherent problems contributing to the suckiness of catalogues is that the systems they are based on, were (I’m presuming here), used primarily by librarians in a “technical services” capacity to catalogue and manage their stock. They were not solely devised as public systems that facilitated the findability of library stock, let alone the findability of documents or information that the library didn’t physically own or have access to. Nor were they designed for the non-professional – it was the librarians that were using these sytems, often on the behalf of clients, so their search functions and interfaces were designed for the informational professional, not the general public.

As a librarian I know I have asked myself: is our catalogue simply a tool for cataloguing and managing our stock? How do we want to use the catalogue to provide access to electronic items? What about items we don’t hold but know users would be interested in, should these be included in our catalogue?

Not so long ago a situation arose at an old workplace: Our manager wanted us to start cataloguing (indexing) key articles from the journals we subscribed to (both hard copy and electronic) so our users would find these when searching our catalogue. And I can see where she was coming from with this – using the catalogue as the primary finding tool for key information on our key topic areas, but conceptually I had a few issues with us doing this:

  1. we had subscribed to a number of full-text and abstract databases – in essence we would be duplicating content (and effort) already available to our users via these specialist databases.
  2. the majority of our journals were circulated, and issues of journals often spent months and months on circulation; as it would be unlikely we would have access to the physical articles we had catalogued, and our budgets were too tight for much of an increase in our document delivery requests, it was decided that we would only catalogue articles we had access to electronically. Which to me contradicted the original concept of why we were cataloguing these articles inthe first place; just because we couldn’t supply the full text of an article didn’t diminish it’s importance our users, but these would not be available via our catalogue anyway.

What I’m trying to say here is more eloquently mirrored in a couple of articles from D-Lib:

And by Karen Schneider:

When we are talking about the suckiness of OPACs, the systems we are comparing our catalogues to and using as a comparison to lament the suckiness of our catalogues (the Amazons and social networking sites) we need to remember that these were built in a completely different era for completely different purposes to the library catalogue of the 1980s (and from what I can tell, most of the big integrated library systems of today are just patched up versions of these.. with the obvious exception on things like Koha). I couldn’t agree with the Creative Librarian more when they say:

Personally, I think the only thing needed in common is the database. Make the database open and write however many different pieces of software you need for what you need to do. Throwing all of the functions needed into one piece of software is part of what’s made it so hard to deal with already. We need to strip out the unnecessary first, then add in all the cool Web 2.0 stuff as it looks useful. And if it turns out not to be used, strip it out again.

I’m thinking a modern library system could be a number of separate (SQL?) databases linked together and run over web interfaces (both the front-end for the user, and the admin-end for the librarian). We need our library systems to reconsider or reinvent the use of MARC and Z39.50, and start thinking about building open systems that utilise XML that can integrate with other web applications easily.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: