Last week a user reported that he was asked for a login while trying to access a specific full text via a link provided by the MPG/SFX server. "A typical IP access problem", I hear you say, but the issue became more complicated soon. Further debugging indicated that
- the full text was available on Elsevier’s ScienceDirect platform and the user was able to access it by browsing to the article directly.
- the local librarian was correctly guided to the full text as she entered the same OpenURL and followed the steps taken by the user.
- the doi link created by the MPG/SFX link resolver was redirected to Elsevier’s Article Locator, but the intermediate page was displayed to the librarian only.
- the website selection screen enables users to "learn" which websites they use by setting a browser cookie:
… and that was exactly what happened to our user. Arriving to Elsevier’s Article Locator for the first time, he accidentally selected the "wrong" website and by doing so he removed the ScienceDirect platform from his preferences. Afterwards, he was not able to return to the intermediate page because he was automatically redirected to the article in his "preferred" Elsevier website.
Allowing users to set preferences is a commendable idea in general, but this implementation falls a bit short. While trying to access a full text, scientists do not read instructions very carefully, but attempt to click through as fast as possible. With setting cookies by default, they may unintentionally been pushed into a dead end.
After clarifying the problem, it was easy to provide a solution: The user could either open Elsevier’s preference page to update his website selections or delete the cookies stored by his browser.
But this issue was an important lesson for us SFX administrators as well. We need to avoid intermediate screens whenever possible, e.g. by configuring institutional preferences. Elsevier offers a cookie pusher for this task. The MPG/SFX link resolver already use it under certain conditions, but the implementation needs to be extended.
This implementation has seriously seriously bothered me since I first saw it.
My users are definitely NOT going to know which of those databases they are ‘supposed’ to check. How would they?
The whole point of the link resolver is to avoid screens like that. It’s just awful.
I am sorry the user is having troubles with the self-learning mechanism. We are certainly taking notes of the type of problems users encounter to see how to streamline the process. I suspect that what the user encountered was a temporary glitch. The self-learning mechanism of the Article Locator was designed to observe patterns, so normally one visit would not make changes to the preferences. The user would need to make the same choices several times for the preference to be modified.
In step 3 of your post above you show a link to the Article Locator. The user can follow that link and manually modify the preferences using the “Update your website selections” link on the bottom of the page. Clearing browser cookies would also clear his/her preferences.
I do hope you give this a chance. Our ultimate goal is to make the Article Locator as transparent as possible for the user and the self-learning mechanism is just one option. This can, of course, be disabled by the user. You can also set Article Locator preferences for your users on institution-level via cookie-pusher mechanism if your environment allows that. The institution-level preferences can also be set in ScienceDirect online product if you are ScienceDirect subscriber and have admin access.
@Jozef Paulik: It’s good to hear that ONE visit shouldn’t fix the preference because it’s not very obvious that selecting a site implicitly decides about future visits. In fact, the user was not able to relate his experience (“no access”) to a choice he took before, but assumed this to be a regular access problem which can only be solved by his library. I wouldn’t blame him for this misinterpretation and it took me a while to find the solution myself. We agree that it’s our responsibility to avoid these kind of traps – so let’s start to search for the “institution-level preferences” in the ScienceDirect admin ;)
Some additional information regarding the institution-level preference for Elsevier’s Article Locator: It’s not exactly a setting, but a combination of the branding options and the cookie-pusher mechanism provided by ScienceDirect.
Local administrators can place a logo in some predefined areas of the user interface. By adding the cookie-pusher syntax to the image URL it’s possible to utilize ScienceDirect to set the appropriate preference, e.g. by specifying
instead of
More information about the cookie-pusher mechanism is available via http://info.sciencedirect.com/implementation/linking/articlelocator/
@Inga: Yes, that is exactly how the setup works. Just to remind everyone, this will work from any website/webpage your user may be visiting. So if you have some type of institution home page or login page that all users go through, you can add this functionality on that page if you wrap it in <img> tag. You can even use a blank 1×1 pixes gif image if desired. So using your example, the following should work on your own page:
<img src="http://linkinghub.elsevier.com/retrieve/cookie?Redirect=http%3A%2F%2Fwww.mpg.de%2Fimages%2Fminerva_logo.gif&PrefSite=sd">
I am mentioning this because although the mechanism Inga described works, it relies on the existing header/footer functionality in ScienceDirect to display custom image (that is what it was designed to do). Unfortunately this currently doesn’t work for all users and ScienceDirect will be fixing that in the next release.