OPACitude
The library blogsphere has had a fair bit related to OPACs lately, some of it involving me, most of it not. So before I weigh in again, I’m going to send you to these, if you haven’t already read them:
- The Shifted Librarian says some things about OPACs and innovation that I wish I’d said
- TechnoBiblio on a similar theme
- Peter Rukavina on how librarians contribute to the lack of OPAC innovation
- The Shifted Librarian responds, with why librarians are in a cleft stick (read the comments too)
- Laurabelle eviscerates me in the nicest way possible
- TangognaT adds experience with the non-customizability of OPACs
To the stack, I’ll add an email I got from an Extreme friend of mine commenting that OPACs seem remarkably arcane and difficult to use given the relative simplicity and quality of the data they’re searching. This guy, let me say at once, knows his way around difficult and arcane stuff. If he doesn’t find OPACs usable, trust me, they ain’t usable.
Right. Read all that? Good.
The answer to my Extreme friend’s question lurks in various parts of the above blogyssey. OPACs are just the tip of the “integrated library systems” iceberg. The same damn databases are running acquisitions, cataloguing, circulation, and search. You begin to see, I’m sure, why at the UW-Madison the ILS is run on big Oracle iron.
OPACs have gotten the short end of the design stick because—well, all right, let me make myself even more popular with my chosen profession—because librarians have taken care of themselves and their own needs before turning their attention to the patrons. I don’t know much about other ILS modules, but I’ll put any money you like on their being better adapted to their tasks than OPACs.
This isn’t unusual or pernicious. It’s the “scratch own itch” factor, well-known from open-source software. Librarians are closer to the vendors than the patrons are, therefore their itches get scratched first. And let’s be realistic here: if librarian ILS itches don’t get scratched, libraries don’t run. At all.
So OPACs are broken (and nobody in this conversation is saying they’re not, though we differ as to details). How to fix them?
Well, we can lean on our vendors, despite considerable evidence they don’t bloody well listen. We can throw more effort at customizing the OPAC modules—but for that to work, we have to lean on our vendors to build in more flexibility, and there we are back at problem one. We can innovate outside the ILS (one such innovation being what started this thread in the first place), which is fine but limited in scope. Or we can start building our own.
One thing we need the library-research community to do is much more OPAC usability testing. Laurabelle and I can rip out each other’s guts until the cows come home (and I do have some non-evisceratory responses to her, though they probably won’t go in this post), but neither of us knows which approaches work better for which patrons. Likely enough we’re both wrong, and something altogether different would work best—but without the design skull-sweat and the accompanying research, how do we find out?
And if we don’t know, aren’t librarians and vendors alike wandering around in the fog without a compass?
(Sirens. Damn them. I’d start up an OPAC info-architecture/usability fief in a hot minute if I were a library-school professor. Which I’m never going to be, so the sirens can just shut up that bloody song now.)
Anyway, I confess to leaning toward any course of action that gives librarians more and better control over OPACs than we’ve got now. Naturally no one library can build its own ILS. But we’re bundling into consortia to buy stuff anyhow; why aren’t we using those same connections to pool our software-development resources? Or at least to demand better APIs from our vendors?
But playing Oliver Twist in the poorhouse (”please, sir, may we have an API?”) won’t help our patrons, that’s all there is to it. And that seems to be most of what we’ve done so far.