Even though I’ve switched to a different area of work, I have still been handling many projects and tasks related to my old job these past several weeks. One project involved the integration of our OpenURL resolver (SFX) into our document delivery service. A few days ago this project work completed and was successfully implemented. I am pretty thrilled with the result!
Basically a team of people met earlier this year to figure out how we could address the following issues:
- Make better use of our SFX linking
- Help our users know, earlier in the process, when we have something available in full text
- Help our users save time and money by avoiding unnecessary document delivery charges
My library has a heavily-used web form that our customers use for inputting document delivery requests, 99% of which are for journal articles. We charge for fulfilling their requests (average charge across all orders including regular charges mixed with higher priced rush orders is between $20-30 per article request). We also know that a fairly significant number of article orders received via this web form on our site are for articles that we already have available in full text, at no additional cost to our users. Our library averages about 100 such requests per day. The typical workflow is that a user inputs citation information into the form, clicks on a Continue button, is presented with a confirmation screen (with the ability for the user to modify or change information in the form), and then a Submit button for completing the order process.
Our idea was to add new functionality between the initial order form input screen and the confirmation screen, such that the article citation information would be used to dynamically look up our holdings in SFX and, if a valid match was found, a new SFX full text link would be presented in the confirmation screen telling the user that full text was available online.
This new functionality sounds simple but involves a lot of complex stuff behind-the-scenes. In particular we were concerned that the SFX link presented to the user needs to work as close to 100% of the time as possible. Anyone who uses any kind of OpenURL service knows that full text links are not as stable and successful as users wish. The last thing we wanted was to present this new option and then give the user a bad experience and turn them off if the link, when clicked on, doesn’t work.
As already stated, I am thrilled with the results. Extensive testing has shown that this new functionality works well. The end result will be significant cost savings for our users. A very conservative estimate puts savings at more than $20,000 per year. One of the things we built into the project is a method for specifically tracking use of the new functionality so we’ll be able to have exact figures rather than estimates over time. Below is a screenshot of the new functionality.
And the really cool thing is that with the coding we’ve done behind-the-scenes, this project is only the start of what we are able to do.
Interesting. Can you provide more information about what you've done to make the SFX link work more of the time? Because, yeah, anyone that works with SFX knows the links don't work as often as we'd like. So what did you do to improve things?
Jonathan,
It's not rocket science or whiz bang stuff unfortunately. We're making two
calls, one to the Journal Subscription API and another to the SFX API. In
addition we are requiring that the user inputs sufficiently complete
metadata. In other words we evaluate the data on-the-fly and will not even
bother with the API lookup if we don't have sufficient metadata to work
with. For instance, if the user neglects to input pages or even just a
start page, then the lookup process won't even proceed.
Steve
Steve: Great post and I think you're spot on in your first-comment reply. link resolvers that are implemented with the controls “to work” are a win-win for the end user, the information center, and the company. The alternative is dissatisfied end users and costly/manual workarounds. Glad to see you spreading the gospel about the benefits for an integrated document delivery-link resolver relationship. In my biased opinion (working for a document delivery provider: Reprints Desk), the two really to form a much stronger union and provide great benefit for delivering access to journal articles; However, the union definitely isn't “right” for every environment.
Steve: Great post and I think you're spot on in your first-comment reply. link resolvers that are implemented with the controls “to work” are a win-win for the end user, the information center, and the company. The alternative is dissatisfied end users and costly/manual workarounds. Glad to see you spreading the gospel about the benefits for an integrated document delivery-link resolver relationship. In my biased opinion (working for a document delivery provider: Reprints Desk), the two really to form a much stronger union and provide great benefit for delivering access to journal articles; However, the union definitely isn't “right” for every environment.