As a returning student in a master’s program, I was excited at the prospect of accessing the wealth of resources a modern research library affords. But the reality has been more frustrating than I could have imagined. Whether logging in from off-site, navigating from ToC alerts or social media, or reading on my phone, I run into stumbling blocks that prevent me from accessing resources that should be available to me. The user experience of working with e-journals and ebooks in an academic setting has failed to keep up with changing practices and preferences for how researchers now expect to access the scholarly literature.
I called attention to some of these limitations in an Ithaka S+R issue brief earlier this year, and the STM Association invited me to present on this topic at their annual conference in October. The publisher community there expressed a real commitment to addressing these stumbling blocks. Several of the organizations spotlighted in my presentation have already begun to take steps to address some of the issues I highlighted, but as I emphasized in my talk the issues are community-wide and affect essentially all publishers, platforms, and intermediaries to one degree or another.
Ithaka S+R has subsequently been asked by several publishers to conduct assessments of how their users, working in an academic library setting, experience their products and services, with the objective of identifying bottlenecks that can be addressed. Such an assessment is one of the services that we can offer to help publishers address these needs. Our goal is not only to identify stumbling blocks for legitimate access but to help architect broad solutions to expedite research. We are also planning to convene several discussions among publishers about how to develop broader solutions to sticking points in areas such as authentication and discoverability.
The video of my talk at STM is now available. I hope you enjoy the presentation, and please feel free to reach out to me about these issues at any time.
Discussion
3 Thoughts on "Dismantling the Stumbling Blocks that Impede Researcher Access to E-Resources"
As you point out, there are several failure points in this, but I’m focusing on two.
One is the proxy server. It’s problematic for workflow, and EZproxy is also straining under the current web development environment which often includes a lot of scripting. Shibboleth, unfortunately, also presents a kind of clunky workflow, as users often need to scroll through a bunch of stuff and access multiple dropdowns before they get where they need to be. A cross-platform single sign on would be great for convenience, but would be difficult to implement, particularly with librarians’ privacy concerns.
I also find myself thinking about the OpenURL standard. That link to EBSCOhost likely failed because the date information in the request to EBSCO was either incorrect or insufficient to determine access (happens often when embargoes are in place). Vendors can all implement OpenURL request receipt differently. Even in cases where rich metadata is passed along (authors, article title, etc) the full text platform may only be gathering the ISSN and page number. Differences in OpenURL interpretation (particularly date info) cause a lot of errors. In the end though, OpenURL will just prove inadequate as we transition to a world of journals without volume and issues, and hybrid journals with article level restrictions.
I agree entirely on the pain-point of Shibboleth being getting to the point of logging in – it’s particularly annoying for users whose “institution” (to Shibboleth) is a larger consortium rather than the one on their business cards.
However, I think it’s the best way forward that we have. Proxies don’t scale, and I haven’t met many people keen on openURL, though I haven’t used it myself.
Shibboleth *almost* manages to be a single sign-on system; it would be interesting to see whether it could develop into one. There’s no obvious reason, for example, that we couldn’t try and identify a user’s institution from their email address, which is usually either the same as, or directly linked to, the institutional login they’d use to authenticate.
Consider, say, a signon screen that simply says “email address, click [continue] to enter password”; it then does a lookup on the email domain and redirects to local signin page, password, direct back; with an option to fall back on a list if it can’t identify you. Separate username/password screens are becoming a bit more common now anyway, so this might not even seem too strange.
If I might suggest one additional step in the analysis that you mention conducting – analysis of how well the citation and PDF export from the database into Mendeley, zotero, etc. The case you present ends with doing a quick check of something in the PDF but still on the publisher platform. Reasonable. But, of course, sometimes we want to actually read the whole thing and annotate it. Maybe even cite it!
Often, after wrestling my way into the platform, I find myself then wrestling to export the information that I want in order to then wrestle it into (in my case) Mendeley. Surely the filename could be something beside publishname.pdf (particularly annoying because one can accidentally over-write a previously saved PDF from the same publisher) or 348987943271894.pdf (unique but of limited value)? And, please – full meta-data with the PDF? I spend so much time typing (or copy-pasting) citation information into Mendeley – when I was just looking at it on the screen a minute previously on the publisher platform.
