H4: Technology Scouts: How to Keep Your Library and ILS Current in the IT World

Jane Kelsey, Yale University School of Law
Katie Bauer, Yale University
Casey Bisson, Plymouth State University

Jane Kelsey

Library catalogs have changed fast since the 1970s, and even though everything has moved onto the web, the changes are still coming fast. In order to keep up, we must think about ILS in widest view possible, because it's not just for bibliographic information anymore.

Why change? Because library users want change. Because libraries have to change in order to stay viable. And because we can change as ILS's offer new modules.

Young library patrons were born with joysticks in their hands, and they expect everything to be online. Thus expect library services to be online, too. They expect ambient findability, with the least amount of effort. Simply put, they won't use systems that require too much work.

And this drives librarians crazy. Many librarians try to keep viewing things as hierarchical, categorizable, and sequential. But that's not how information is anymore. Now, everything is "intertwingled" (e.g., a mashup of craigslist and Google Maps produces HousingMaps).

Administrators have similar expectations. They want web services that will save time and money and redeploy staff to higher functions. They expect a credible presence, which keeps reliability intact.

ILS vendors are finally beginning to provide products to make these things happen.

Here are a few examples of what Yale's Law Library has done...

• Implementation of an Electronic Resource Management (ERM) module that integrates fully with the ILS
• Using a WebBridge to suggest other resources for patrons to check
• Syndication of incoming RSS feeds into library catalog interface, including library news and legal news from Jurist
• Now producing RSS feeds going out of catalog (e.g., new acquisitions alerts)
• Library can communicate directly with users via portals and feed readers using RSS feeds
• Creation of a MiniCatalog module via AirPAC
• Spellchecking in the OPAC
• Added tables of contents, book jackets, and permalinks to the OPAC
• Creation of Firefox search plug-ins and LibX toolbar
• Place an icon in records on Amazon when the library has the book

Katie Bauer

Users now have a lot of options in searching for information. A recent OCLC survey shows that college students use search engines far more than library websites when performing online research.

This means it's time to start pushing library content out of library website and into places that the patrons already are. What users want is quick, simple, and seamless access. They want it to be easy.

One tool used at Yale to make this happen is John Udell's LibraryLookup, a javascript code that grabs an ISBN from an Amazon URL and plugs it into an OPAC search. This allows users to search for a book in the Yale catalog directly from that book's page on Amazon.

This leads to additional Firefox browser add-ons. The pros of these plug-ins include the ability to put a catalog search box in every browser window a user opens, providing users with complete control over when they can perform a catalog search, and the relative ease with which the plug-ins can be created. However, there are some notable drawbacks. For one, the plug-ins only work with Firefox. Also, to use the plug-ins, users must first download them. Finally, the user must take an extra step to search the catalog.

In addition to plug-ins, libraries can push content out into other realms using RSS.

Yale performed a study to discover where users are on the Yale webspace. The results of this study were then used to determine where the library would push its content. For example, students are using the university's course management system heavily, so Yale is now working on a prototype to push library content into the CMS via RSS. One such piece of content is an automated reserve book list for specific courses in each course's web space.

Yale is also now putting links to library resources into Google Scholar search results using SFX. The user doesn't need to configure anything in order for this to work. This same functionality can be added to Open WorldCat as well. The only drawback is that Google Scholar is very picky about what links it will include.

Casey Bisson

Library catalogs have been criticized a lot this year. The challenges that have generated these criticisms involve usability, findability, and remixability.

Recently, the Ann Arbor District Library (AADL) and the North Carolina State University (NCSU) Library have done things with library catalogs that everybody immediately wanted for their own institutions. AADL it inexpensively using open-source software, while NCSU spent a lot of money to develop a commercial solution. To attempt some of these same things, Bisson developed WPopac, a library catalog built using open-source blogging software (WordPress).

Usability is important, as is findability. How do libraries serve people who start their research with internet search engines? How do you increase the functionality of the OPAC for your users? You can improve findability by making content indexable by search engines and linkable. With linkable content, can much more easily track citations to your content and resources.

What about remixability? Flickr, an online photo sharing site, is an excellent example of content that is remixable. Flickr provides the content, and others build tools to manipulate that content for new uses. The tool builders don't have to invent Flickr, and Flickr doesn't have to invent the tools.

An excellent example of a tool built by someone outside of flickr to make use of flickr's content is the Crayon Box Colr Pickr.

In this new world, to make this kind of innovation occur in libraries, we must similarly separate the data and the data manipulation. Then the possible manipulations are endless because it's not limited by the interface of the data system.

Solutions to the challenges of usability and findability are imminent. Therefore, it's time we began focusing on remixability in our systems. To do this, we should look at the OpenSearch API, follow the development of WPopac, and ask our ILS vendors to keep the door open for experimentation (i.e., ask for APIs).

Casey's slides are now online at his blog, MaisonBisson.

Part three in Karen Schneider's excellent series How OPACs Suck is now up over at the ALA TechSource blog, and, as usual, she's raising some pretty heavy issues:

In the pre-digital era, every library maintained its own card catalog. That was absolutely logical: how else would users find a book in the library? But in the digital era, every library still maintains its own card catalog—at least in the sense of having a unique database with a unique record for each bibliographic entity. Step back and ponder how really odd that it is. It would be as if Amazon created a local data set for each customer, with a separate installation of Amazon as well.

Prominent Library 2.0 advocates are already arguing on both sides of this debate, and there's no easy answer in sight. Many librarians view the centralization of the OPAC as the first step in surrendering our services (and eventually our existences) to a "universal" online library like Google. Others, however, see a central database for bibliographic records as a liberating option that will free up local librarians to devote their energies to truly local endeavors. With the data maintained elsewhere, the interface (and, hence, accessibility) becomes the central concern for the library.

In conversations on this issue, I usually fall on the side of centralization (though I'd hardly describe my position as rock solid). I can't even begin to predict whether that central database would be Library Thing or Open WorldCat or something else entirely, but given how much local cataloging consists of simply copying OCLC (or other consortia) records, there is a certain beautiful logic to eliminating the copying stage altogether and allowing local OPACs to directly query central records.

For this to work, however, that storehouse of bibliographic data must include a robust set of APIs that allow local libraries full access and manipulation of the data for OPAC display. Anything less would be little improvement over the current situation in which ILS vendors dictate what features are available. If my patrons want an interface that allows them to search by book publication city or DVD running time, I should have the ability to do just that.

This brings to mind one of the most eye-opening experiences of my career. When I attended my first OPAC design meeting, the committee chairperson had to break the news to everyone that we didn't even have the ability to change the look of the navigation buttons in the OPAC. The navigation buttons. Perhaps not the most integral component of the user experience, but certainly indicative of the trust ILS vendor have for local librarians and systems people. And this for a localized OPAC with localized data. It may seem paradoxical to say this, but centralization may be one way to gain more local control over our own information.

[ALA TechSource] How OPACs Suck, Part 3: The Big Picture

Over the coming months, a major topic of discussion here at LibraryLaws.org will be the challenges faced by law libraries in creating usable online catalogs (the artists hopefully eventually formerly known as OPACs). The catalog problem is an extremely popular subject of debate throughout the Library 2.0 blogosphere. To see just one example of the excellent questions being raised, take a look at Karen Schneider's ongoing series over at ALA TechSource, "How OPACS Suck" (Part 1 and Part 2).

In recent months, many new tools have been developed that raise the bar for online catalogs and force ILS vendors to reconsider their current offerings. The most impressive is the new Endeca powered catalog at North Carolina State University. By completely bypassing their ILS feature package and using tools developed in the world of e-commerce, NC State and Endeca have created a catalog the actually returns usable search results and provides patrons with easy to use features that make searching the catalog a surprisingly brainless endeavor.

Unfortunately, the vast majority of law libraries will be unable to follow NC State's lead. Most academic law libraries are either members of a much larger consortium of university libraries or simply "piggyback" onto whatever ILS that consortium uses (even if the law library isn't technically a member of the consortium). This leaves the law library with little or no control over which ILS it uses or what specific features of that ILS are activated. As for public, court, and firm libraries, the funds simply don't exist to invest in a high end integrated library system. With few exceptions, the cheaper solutions adopted by these institutions translate into fewer available features for their online catalog (if they even have one). This also holds true for many independent law school libraries that are not affiliated with a larger university.

Truth is, most law libraries simply have to make do with what they're given. This leaves little opportunity for improvements to the library's online catalog. That is why direct access to the underlying data is so important. Innovative Interfaces, for example, provides libraries with the option of using an Oracle database to store all of the data used by the ILS. But it costs extra. And unless you work for an academic law library whose university library system has opted to purchase the Oracle (or equivalent) feature, the odds of getting direct access to your library's data are steep, to say the least.

But in those instances where direct access is possible, the sky is the limit, provided you have systems personnel capable of building tools to make use of the data. Your library is no longer limited to the features available on the ILS or to the limited number of features actually activated by your university library system. With direct data access, you can build any search interface you want. ANY search interface.

Of course, then you have to have to "roll your own" relevance ranking algorithm that will bring back meaningful search results. Then again, it can't be that hard to improve on the algorithm built in to a typical ILS...