Hiding Complexity in Library 2.0
One of the benefits of a more open architecture for the OPAC, as discussed earlier, is that it allows you to have as simple or as complex an interface as you need. If your patrons don’t need a specific feature then you can turn it off. It also allows those with other requirements (such as privacy) to tweak it to meet their guidelines. Some libraries may have no problem storing data for personalized searches while others may have a strict privacy guideline forbidding such things. In general extensibility allows you to be more flexible.
Right now, however, it is a bit difficult to do such a task. You can tweak templates but any large changes or integration often takes lots of hacks and is not very elegant. The usability of such a system could also decrease as you try to hack on this feature or that. This is important as more and more libraries begin to look into ways of making the OPAC easier to use and more importantly, information easier to find. A recent quote caught my eye and it may be useful to keep in mind when discussing features for you OPAC and how to implement them.
“Google has the functionality of a really complicated Swiss Army knife, but the home page is our way of approaching it closed. It’s simple, it’s elegant, you can slip it in your pocket, but it’s got the great doodad when you need it. A lot of our competitors are like a Swiss Army knife open–and that can be intimidating and occasionally harmful.” (via Column Two)
Since there are likely some google haters in the crowd here’s a better takeaway from the article:
In a 2002 poll, the Consumer Electronics Association discovered that 87% of people said ease of use is the most important thing when it comes to new technologies.
In the ramp up and discussion for “Library 2.0″ the feature list keeps getting longer and the ideas ever more complex. Can you keep you OPAC from becoming a confusing mess? Can you even implement these features if you wanted to? When someone visits your OPAC are they eased into what’s available or hit head on by the thousand options they have? Can they find a book without knowing boolean constructs?
All of these questions are important as people will demand these features but also demand that they not get in the way. Is there really a reason to have a button to show the MARC record front and center? Can you tell who the OPAC was designed for? With a good URL structure such things could be relegated to the background for advanced users. In Wordpress if you put a /feed/ at the end on any URL you will get the feed for the item be it author, category, item (comments) or site. With a good architecture an OPAC could do similar things with /marc/ showing the MARC record, /feed/ giving the RSS/Atom, /xml/ giving the MARC XML or other XML syntax, etc. This allows you to expose what you want (add links on the page) or just leave it there for those “in the know” (librarians that want MARC). This is another area where Wordpress gives a good example of how it can be done. And it’s extensible so if you wanted /dc/ to give you a Dublin-Core output of the page you could do so if you wanted. There’s already a Wordpress blog that’s COins-PMH compliant, how long would it take you to make your OPAC as well (server-side)?
Does your OPAC allow you the flexibility to integrate, add/remove features or otherwise change as patron demand changes? Shouldn’t it?
Technorati Tags: ILS, libraries, OPAC, library2.0, users, wordpress
Leave a Reply
Comments should show a courteous regard for the presence of other voices in the discussion. We reserve the right to edit or delete comments that do not adhere to this standard.