Every library’s needs are different when it comes to what they want to display to users in their OPAC – beyond the basic bibliographic information that is. Although I must admit that I’ve been a few mind numbing meetings over the years about the ‘most appropriate’ way to display a record on screen.
Scattered around the web you will find many examples of how OPACs have been extended to enable the user link in to other services such as Amazon, or AbeBoooks, or LibraryThing, or Google Scholar, or Yahoo images, or Google Book Search, or del.icio.us, or … [insert you favourite 3rd party service here]. For most developers in the library code community, adding these extensions to their OPAC is a comparatively simple exercise.
I believe that in the wider world, most of the folks responsible for an individual library’s OPAC would not consider themselves as coders, and would at most only be comfortable copying and pasting small bits of html in to their interface. So how do they get these features in to their systems. It is unlikely that you would get much help from the system vendors, as it would be difficult for them to build a product roadmap around the ever changing multiplicity of extensions and combinations of thereof. The coding community are good at sharing code with other coders, but not necessarily in a form that is either consistent between extensions or OPACs.
I’m working on a way that will hopefully make it easy for innovators to share what they are doing not only with others in their community, but most importantly with those less code-aware OPAC managers, who may even be using different systems.
The screen shot above shows Google Book Search preview service embedded in a Talis Prism OPAC. What is not obvious is the simple way that it was added. I will be going more in to depth on this open source sharing approach to OPAC extension at Code4Lib 2009 at the end of the month.