One use of ‘link resolver’ software is for a journal title-level page: Show me all the sources of fulltext for a given journal title, and let me know what the coverage is of each source. (One may only contain fulltext before 1990, another only after 1985, etc).
Users may or may not care about the vendor or platform name for the link. I’m sure some users know which vendor UI’s they prefer and do care. But I’m also sure many other users have no idea what those vendor platform names mean (“EBSCOHost what?”).
But one thing I’m pretty sure does matter to all users is the dates of coverage. If you’re looking for the last couple issues to browse em, you’re not going to want a fulltext source that only has old issues. For instance.
Yet most link resolver interfaces I’ve seen do not make the dates of coverage as prominent or as easy to scan as they could be.
Here’s an excerpt SFX out of the box UI menu for Science, an example with a particular voluminous list of fulltext links:
And here’s the way Umlaut, up until now, displayed a list of fulltext links with coverage (with info coming from underlying SFX KB). Slightly cleaned up, but with the significant dates of coverage still kind of hard to scan for:
New Umlaut default display: prominent dates of coverage
The full narrative ‘coverage statement’ is still there, because it may include additional information such as issues/volumes, or embargoes. (If a package is listed with an embargo of recent one year’s worth of contents, the summary dates will show up as to “2012”, since this year is 2013, as a summary.)
But pulled out front and center (well, er, left) are the dates of coverage the user actually cares about.
I think this is a much improved UI. Oddly, I don’t think any commercial/proprietary link resolver products do this with their default out-of-the-box UI.
I’m not sure why it took me this long to do it. It is possible using Umlaut as a front-end for SFX, becuase SFX includes machine-actionable coverage info (including embargo info) in it’s API response. I think other link resolver products with API’s include machine-actionable coverage info too, they would of course need to for Umlaut to provide this same UI with an alternative KB back-end.
Wondering about title-level displays in link resolvers
This improvement is really only relevant to the “title-level” display — when the user has looked at a link resolver screen for a journal title as a whole.
For the ‘article level’ display, Umlaut simply doesn’t include dates of coverage at all. Since, if the link resolver is working properly, only links for platforms that include that article are included, and those links will take the user directly to the specified article — the dates of coverage are just irrelvant.
It’s really this article-level use that justifies our purchase of the link resolver KB in the first place. The link resolver KB is what keeps track of package coverage, determines whether a given specified article falls in a given packages coverage, and then provides a link that goes directly to the specified article where possible (just just a journal home page). This is all non-trivial stuff (and it goes wrong more than we’d like), and it’s what justifies the purchase of a commercial link resolver in the first place, to try and track all this stuff. If we only were going to use title-level pages, we’d probably just use our catalog that we already had, or at any rate some alternative to current link resolver products that is simpler and cheaper.
Yet… it seems as if users are using the link resolver for “title level” displays too. And/or looking up journal titles in the catalog (which in our infrastructure, still uses Umlaut to come up with the proper fulltext links, if any). Because I’ve gotten many requests to clean up this title-level full text display, for title-level uses. Which is why I spent time on this UI change, of course. (It took a bit more time than you might think, because first we had to get the machine-actionable coverage info out of the SFX API response to begin with!).
I am very curious what users are using the title-level display for, and am not really sure.
- Do they actually have a specific article in mind, but are trying to get to it by first clicking on a title-level vendor platform link, then trying to ‘drill down’ to their article? If so, are they doing this because they don’t know of the other ways to get directly to the article, or because they find this way more convenient than the other ways? (Depending on the vendor platform, trying to get to an individual article this way could be decent, or disastrous).
- Are they interested in the ToC from the most recent issue or two, for current awareness, and that’s why they’re going in through journal title?
- Something else I can’t even think of?
In general, while I’m trying to improve the experience at the title-level display, depending on what the user is trying to do, it still might end up a very inconvenient interface. Sometimes for reasons out of our control, like vendor platform ‘title level’ screens which do not offer ‘search inside this journal’, and/or offer terrible UIs for drilling down by volume/issue. If I knew more about what people were actually trying to do here, it’s possible there are other things we could do to improve their experience.
Bibliographic Wilderness 
From asking user services librarians, a couple more reasons people may use title-level fulltext links:
* Professor’s may tell students “find articles from journal X, it’s a good journal in this field”
* Do not trust link resolver’s article-level linking abiltiies, due to errors in original citation (taken from a bibliography) or errors in link resolver, too often trying to go directly to article level fails, easiest thing to do is start at journal-level and drill down.