Blyberg and Barr: Solving the OPAC problem

John Blyberg
Solving the OPAC problem

Walked in a few moments late to hear Blyberg saying…

How many people here can customize their OPACs?  (A few hands go up), “No, I mean in some meaningful or significant way” (all hands go down and much laughter spreads through the room.)  Customizable sites (unlike our OPACs) allow the user to customize and repurpose their sites and content without needing to remember a 14 digit barcode number.  Which is what we do.  (Because we always have.)

Brief history of SOPAC.  Lots of tinkering and attempts involving a variety of different softwares and goals and features, and the first version was released in 2007.  Much more customizable and feature-robust than many commercial OPACs.  But there were some problems that center around critical mass, much like all social networking technologies. Without critical mass, the tagging and other community features only reflect the interests of early adopters, and hit only a narrow slice of the overall audience.

SOPAC 2 is completely rewritten to accommodate a new architecture.  Locum is the abstraction/discovery layer independent of SOPAC and anything else; it can be used without anything else as a development layer if wanted.  Ostensibly, Locum will work with any ILS so long as you write a connector that works with the ILS in question. III is done, someone’s working on Sirsi, hackfest for Evergreen at Access.  SOPAC is built on top of Locum, which sits on top of the ILS.

Insurge is additive — a collective base of social data from other SOPAC libraries which you can then index and include in your SOPAC install.  Fixes the critical mass problem inherent in other systems.

SOPAC has a feature for creating “Staff picks” and the like; “They’re like those book carts you put in your lobby.  And the thing about them is that you can put anything there, and people will take it.”  Features like this allow you to do that better. And then he gives us a tour.  (And the patron dashboard is better than anything I’ve seen before, with features that patrons might actually want and use — their tags, their transactions, their fines, their reviews… it’s a product that makes library services work like everything else on the web, instead of being 94 light years behind user expectations.)  Admin side allows near-complete customization of results displays, forms, searching, available features, etc.

Way more detail (and more accuracy than my notes!) available at http://www.blyberg.net/2008/08/16/sopac-20-what-to-expect/ and http://www.thesocialopac.net/.

Chris Barr
Interface Designer at Villanova, working on VuFind

“I’m basically going to repeat John’s presentation and insert VuFind at appropriate times” because what htey’re working on is very similar because we all have a problem with our OPACs. “Raise your hand if your OPAC sucks…” (ALL hands go up) “There are a lot of people in this room who need Open Source.”

The problem with OPACs is that they’re created for librarians, for people who know how to front-load a search, and the Google generation does not know how to do that.  Our current systems use top-secret syntax — like last name, first name for author — certainly we’re not going to search Google for “Barr, Chris to figure out who the heck I am”, and it’s 2008.  Surely we can do better.  And the customization available is terribly limited in our current systems, without the capacity for the web 2.0 bells and whistles that we’d like to add.

So two guys, a computer programmer and a performance artist, who both happen to work with libraries now, put their heads together.  The Big Idea:  Searching a huge oracle database is not fast ore easy, so VuFind takes all the data and searches it outside the system.  Step one: Suck down the data from the catalog to an index system.    Then, it doesn’t matter what you run on the back end, because the front end remains the same.

“When I got started in LibraryLand, I was horrified that you can’t bookmark a page from the catalog.  That’s, like, internet rule #1, that URLs don’t change.  So we fixed that.”

And then they integrated the library website with the catalog.  There’s a search bar everywhere you go on their website, linking to the catalog, digital services, and help sites.  Provides an integrated and federated searching capacity.

VuFind allows for faceted browsing “which is how we’re tricking people into using advanced search features, like refining and combining searches.”

Working on more WordPress-like templates for libraries to use, because “it breaks my heart to see libraries use VuFind but never touch the template”, since the beauty of a customizable system is to allow libraries to integrate the software into a library-wide discovery and delivery system.

Assessment from both John and Chris, upon being asked “How long do you think traditional ILS vendors will be around?”:  The ones that embrace open source innovations will survive.  The ones that learn to stop nickel-and-diming libraries on features will survive.  And when Evergreen gets its’ Acquisitions Module up and running, those traditional vendors had better look out.

(I continue to be stunned by the questions people ask.  Librarians are freakin’ obsessed with moderating community contributions, and with making sure that things are backed up and preserved.  PEOPLE:  We have best practices as a community.  Just because someone did not mention the detail you are obsessed with (which no one in your user community cares about) does not mean that the thing has been ignored.  If preserving data with regular backups is a best practice, you can bet that the application being developed will have that practice available.  If moderating comments and reviews matters to you, you can do it.  Why you would is a mystery to me, but… go for it.)

Aaron Schmidt:  These two gentlemen have showed us OPACs that look like normal websites.  They’ve given us all great hope.  (Huge applause.)

2 thoughts on “Blyberg and Barr: Solving the OPAC problem

Leave a Reply

%d bloggers like this: