user behavior

The report basically analyzes the research-acquiring behavior of their users (and academic library users in general via the literature), and comes up with some trends and suggestions for library strategic directions to meet their needs. I recommend it highly, it’s got a nice executive summary (which is pretty much all I’ve made it through so far, but I plan to read more). (Incidentally, why does cut and paste from the PDF result in gibberish? Very annoying. Speaking of usability.)

Somewhere I forget recently I read a piece of science journalism that had a quote from a scientist along these lines: “There are two kinds of interesting research findings. Sometimes you discover something you did not expect at all, and sometimes you verify something you suspected but didn’t yet have sufficient evidence for.”

Most (but not all) of what’s in the report is in the second category for me, but of course that doesn’t impeded it’s use, the evidence-based findings is important.

Much of what’s in the report resonate with existing ideas I had for intermediate term development of library digital services, with implementation ideas often made possible by Umlaut.

Use of non-library discovery interfaces

[Suggestion:] …We need to ensure that items in our collection are and licensed resources are discoverable in non-library environments.

I’d on to this “ensure that library services for making use of items are accessible even when the user starts from a non-library environment.” (Eric Lease Morgan has talked a bit about this).

One of my long-standing goals for Umlaut I think resonates with this. Umlaut is designed from the start to be a ‘landing page’ for library services for a known item. No matter where you find an item, if you want to find out how you can get it from the library or what library services exist from it, Umlaut will do that for you.

Umlaut, like any link resolver, traditionally does this by working with licensed vendor discovery services that send an OpenURL link to Umlaut. But the problem is that users are using many discovery interfaces that don’t this, and are unlikely to do this in the near term (for various reasons, including business interests of the operators of those services). So what can we do?

Well, one thing I really want to do is customize LibX to work optimally with Umlaut, adding links to the Umlaut page to the third party discovery interface. (or even Umlaut-provided services directly on the third party page). Find a book in Amazon, Google Books, or a variety of other places? No problem, we can still connect you to Library availability and services in one click (or zero clicks if the info is inserted directly on the page!).

It’s unfortunate that a browser plugin (which works only with IE or FF, not Safari, not custom smartphone web browser, etc) is required for this, but I can’t think of much other way around. Another possible ‘fallback’ interface could be providing the URL of the page you are looking at to a server-side application, which does LibX-style processing on the server, and then tells you what the library can do for you for items found on that page. This might be the best ‘fallback’ option for users who can’t install a LibX style plugin.

Delivery

Trend 2: Users expect discovery and delivery to coincide. Searchers do not distinguish between discovery and delivery in their web searches…

[Suggestion] …systems, data, and information should be optimized for fulfillment.

This gets to another long standing desire I’ve had — to unify my libraries various delivery mechanisms in one simple interface with as few clicks as possible.

We offer a variety of pretty useful delivery mechanisms. Sure, sometimes there’s immediately available electronic text. When there’s not, there’s ILL. For some combinations of user type and material type, we’ll also deliver physical copies in our stacks directly to your office; or make a scan of a chapter or article from a volume in our stacks and email it to you. But other materials are in-library use only — some of these you can pull of the stacks yourself, and others of these you need to request a pull and view it in a special office (eg special collections; also some AV materials).

Pretty darn useful, but we have a variety of different forms and interfaces (at least 6 different ones, if not more) to make a variety of different requests. You’ve got to know they exist, find em, fill em out.

Instead, I’m imagining a ‘delivery menu’ (brand it like a chinese takeaway menu if you want to be cute) that figures out, based on who you are, whether the item is in our stacks or not, and what type of material it is, tell you exactly what you can do with this. You can view this in the library. You can check this out. You can have it pulled for you and waiting at the circ desk to check out. You can have it delivered to your office. You can get a photocopy of a specific article emailed to you. Etc. And present all this information — and provide actions to choose an option — in as few clicks as possible.

Combined with the prior note, we can imagine that a user finds an item of interest on Amazon, and then in as few clicks as possible (0-3) finds out what delivery options are available to her, and chooses one of them, knowing how long we approximate it will take to get to her depending on her choice. Of course, this ‘delivery menu’ would be available in library discovery interfaces too, but the real power is in combining this with acknoledgement of the “using non library discovery services” trend.

This is totally do-able, especially on the Umlaut platform. The real challenge is on the business process end, not the technical end. (Consolidating and rationalizing all our delivery options, potentially requiring changes in staff workflow or policies to make everything make sense).

Mobile

Trend 3. Usage of portable Internet-capable devices is expanding. Rather than just supplementing the desktop computer, mobile devices are poised to become the primary means of Internet access for a critical mass of users.

This one is trickier to figure out how to address, especially when combined with this reccommendation from the report:

…we should strive to be end-user device/platform agnostic.

Taking account of that I wouldn’t actually move to “develop an iPhone app” for it, as seems to be a popular trend. We don’t have the resources to develop and maintain custom apps for every possible advanced mobile device in use.

Instead, I’d develop special stylesheets for our core services that divide and format pages appropriately for an iPhone or similar next generation smartphone “high resolution mobie display, significantly smaller than a laptop or desktop.” [Look for an upcoming article in Code4Lib journal adressing how you start doing this.]

Additionally, I’ve thought before about developing some SMS (aka ‘txt message’) interfaces to meet the lowest common denominator of cellphone mobile net access. I would like it if you could text an ISBN (or ISSN, or even DOI) to Umlaut, and Umlaut would text you back with whether the library has it and what you can do. “Reply with the numeral 1 to place an ILL request for this item.” (Or other appropriate options.). Also, if you happen to have a camera cell phone, why type in an ISBN when you can snap a picture of a barcode, and MMS it to Umlaut instead?

Again, totally do-able, especially with Umlaut as a platform.

Recommendation Systems

Trend 4: Discovery increasingly happens through recommending. Facilitating discovery requires us to develop and implement systems that push relevant content to users and allows users to share content with others.

This one is harder.

The study recommends:

We should capture the data necessary to provide targetted suggestions to users and defer to network-level systems where a critical mass already exists.

Umlaut was in fact originally intended by Ross Singer to capture that data to provide those systems, but those features were never really matured, and are not currently present in Umlaut. Umlaut as a platform is still potentially a key point to capture data — but the study’s point that we need to move this data to aggregated systems with a critical mass is key. Just data from my institution is not going to cut it to algorithmically provide useful recommendations.

Perhaps an Umlaut that captures data and then sends it to a cross-institution SOPAC installation? (I’m not sure if the SOPAC infrastructure can handle article, rather than book/title, citation data or not).

Ex Libris’s bX service is designed to do this too, although currently can only take source data from a stock SFX installation (not from Umlaut); it could still be used to provide recommendations in Umlaut, if we wanted to pay for it. I expect more vendors to start adding such services.

As a stop-gap, Umlaut currently does provide links on it’s “landing page” to the recommendation services we were already paying for: Scopus and ISI Web of Knowledge. On a landing page for an item, Umlaut gives you one-click access to Scopus or ISI’s “similar items”. (which are not based on usage, but based on reference and metadata similarity).

Non-traditional objects

Trend 5. Our users increasingly rely on emerging nontraditional information objects. The format of useful and discoverable information is much broader than those traditionally offered through the libraries; users increasingly rely upon multimedia objects, data sets, blogs, and other “grey” objects to meet their information needs.

The issue is that my services, such as Umlaut, really rely on pre-existing databases/knowledge bases the library has of items and what we can do with them. Including both very traditional databases (the catalog) and more recent ones (the link resolver knowledge base).

But almost all of these databases can really only ‘control’ pretty traditional information. If a user comes to my service with a dataset she’s interested in, my software doesnt’ really have any good way to figure out what we can do for her with that dataset, if we have it in the library, if she can get it ILL, where it is on the internet. I’m pretty much at a loss. (If the dataset has a DOI, and that DOI can be provided, I’m in a bit better shape).

I’d note that the study’s recommendations don’t provide much actionable advice on this one either. It’s a toughy, and requires rethinking larger swaths of library operation to address, I can’t identify many intermediate-term ways to address it, although maybe it just needs some more clever thinking.

Umlaut

I remain pleased at how well-positioned Umlaut is as a platform to address most of the trends identified. Umlaut exists as a flexible platform for “known item services” — for making a ‘landing page’ (or inserting services on a foreign page via javascript) for giving the user delivery/access options and other library services for a known item — regardless of where the user found the known item, through a library search service, a licensed vendor search service, or a third party web discovery service.

I am more and more convinced that this is a key piece of library infrastructure for the foreseeable future, and the investments we’ve made in it so far are very worthwhile.

But while the platform is there as an appropriate place to add features, as identified above, actually adding the features takes time and resources. I hope I get the time to work on some of them in the intermediate future. Perhaps this report will help make it more clear to some resource allocators the necessity of some of these directions.