Today was devoted to innovation with academic library users in mind.
At our first stop this morning, we got a chance to dig in to a bit more depth on some of the back end tools used to connect users with electronic resources, while our afternoon included lots of discussion about framing library interface design through the lens of user behavior and analytics (for more on the latter, see videos below from our discussions at the University of Delaware).
One of the first things we heard: we’ve got to do a better job of delivering books and articles to users.
In a nutshell, this is what’s driving Johns Hopkins University (JHU) Sheridan Libraries programmer and analyst Jonathan Rochkind (we had a lengthy chat over lunch, instead of our usual video interviews). As he sees it, the link resolver is the linchpin in the process of delivering electronic resources to users. It presents to users a sketch of how they might go on to acquiring materials found via sites such as Google Scholar. But Rochkind wants to paint a more vivid picture, one that puts all of the available options in context, and gives users as many potential means of access as possible.
The locus of this effort is Umlaut, an “open source front-end for a link resolver,” which Rochkind described more informally as “a ‘front door’ to the library’s services for items identified elsewhere” (Umlaut was originally developed by Ross Singer, though it’s now maintained by Rochkind).
Umlaut doesn’t do search or discovery, and begins only when a user is well down the path in search of a specific resource — the point at which the frustration over a dead end is likely to be highest. Here, according to Rochkind, Umlaut essentially says to users, “not only have I found something, it has machine-readable citation with all the metadata that can be communicated to something else — at this point, what can the library do for you?”
It relies heavily on external APIs to load potential access points such as journal databases or, in the case of books, other sources that can provide additional research context such as Amazon (via its search inside feature), Google Books, The Internet Archive, and the HathiTrust.
What’s most important, however, is that it dynamically seats each of these additional access possibilities in the context of the libraries collections. The ideal is always easy access to full-text, and that’s made prominent if available. But if it’s not, that’s where other sources come into play. Limited excerpts possibilities are included, as are ILL options and details about physical copy manifestations of the same materials as found in the library’s general catalog. For articles DOIs, Scopus and Web of Science citation searches are linked, displaying a hard-to-miss comparison of how the two services return articles that cite the searched-for item.
Rochkind recognized that the software isn’t necessarily simple to set up or customize, even as he’s specifically re-written it to be installed more easily. And he said that he and JHU have spent considerable time and effort developing this tool, more than many schools would be prepared to immediately dedicate to a project like this. But when it’s up and running, it doesn’t just keep all of this API contextualization and aggregation to itself — it feeds the signature improved delivery mechanisms and metadata crunching back into other library systems like the catalog as well, demonstrating something like the reflexive benefits of well-formed APIs and careful attention to the broader possibilities of even the smallest components.
“Before [users had Umlaut as link resolver front-end], clicking on every link was playing blackjack.” Now, says Rochkind, at least tracking down resources is less of a gamble whether users are coming via external sources like Google Scholar or an Umlaut-driven component of the catalog.
See also:
Justin Wing of the University of Delaware speaking with us about the analytics-driven redesign of UD’s library web presence:
About Josh Hadro