by Lauren Magnuson, Karl Stutzman, Roger Peters, Noah Brubaker

Introduction

When the Private Academic Library Network of Indiana (PALNI) migrated to OCLC’s WorldShare Management Services (WMS) in 2014, it was a key opportunity to increase PALNI’s collaboration around resource sharing. Although PALNI had offered a shared catalog and reciprocal borrowing agreement since its inception in 1992, patrons could not request delivery of materials between PALNI locations except via the traditional InterLibrary Loan (ILL) system. This reliance on ILL codes and practices as the mechanism for resource sharing stymied efforts to build collaboration within the PALNI consortium on collection development because libraries had no guarantee of being able to rely on PALNI partners for faster fulfillment or consistent, generous lending policies. This reliance on traditional ILL for delivery also limited PALNI’s ability to distinctively brand its services for faculty and staff at its member institutions and brought into question the value of a catalog search that retrieved items across the PALNI consortium. PALNI libraries noticed a strategic opportunity in moving to a resource sharing system that would integrate closely with its discovery and circulation systems to deliver physical materials with fewer procedural hurdles than traditional ILL. An integrated consortial resource sharing system offered options for limiting requests to available copies and implementing consistent loan periods among partner libraries.

The PALShare system was born as PALNI’s implementation of the OCLC WMS group circulation features. In addition to improving turnaround time for resources held within the PALNI consortium, PALShare has become the “face” of PALNI to faculty and students at PALNI’s 22+ supported institutions spread across the state of Indiana. Because of the resource sharing policy guarantees in PALShare, PALNI libraries have begun making purchasing and retention decisions based on whether other libraries in PALNI already hold a copy of an item, freeing up critical space and funds for the libraries to extend their services and realizing a long-held vision of collaborative collection development.

Still, even as it solved some long-standing issues for PALNI’s libraries, the successful implementation of PALShare created new problems. Of those issues, the most significant was that a new resource sharing option introduced potential user confusion: should they request an item from PALShare or the traditional ILL network? Multiple request buttons appeared on the PALNI libraries’ search interfaces of WorldCat Local and WorldCat Discovery [see Figure 1]. At the same time, other partnerships across the state of Indiana began to emerge to increase resource sharing beyond traditional ILL, including a separate direct borrowing system that was largely designed to serve smaller public libraries. Complex user interfaces and multiple incompatible systems threatened to hinder the progress the PALNI libraries were making on resource sharing. Expanding the resource sharing options was leading to button confusion.

Figure 1. Multiple request buttons appear in an item record in the discovery system. The first Get It button, if clicked, directs users to a consortial request form; the second Get It button directs users to traditional ILL (ILLiad or WorldShare ILL, depending on the institution). End users may not know why there are multiple request buttons, or which button would be the optimal request button to click.

From this context of improved resource sharing options and the attendant button confusion, PALNI librarians began to dream of “one button” that would sensibly navigate the various resource sharing options for patrons. A single button that would intelligently direct users to their best resource sharing option was tempting because it offered some flexibility for integrating a variety of emerging resource sharing options without thoroughly confusing the user.

Application Design

The end goal of the application was to build an OpenURL resolving tool that handled user requests for material by choosing the best fulfillment option for a user without the user having to think about which fulfillment option would be best [see Figure 2].

Figure 2. OneButton concept. Given data from an OpenURL string, OneButton takes available metadata about an item, such as the OCLC number, looks up its availability in multiple fulfillment scenarios, and directs the user to the option that will get their material to them the fastest and easiest way possible.

The application is configured as an OpenURL resolver for WorldCat Local or WorldCat Discovery. Configuration options for the display of OpenURL resolver and place hold buttons for WorldCat Local and Discovery are available in OCLC Service Configuration, which enables libraries to choose OpenURL resolver links to display based on item format (e.g., book, article) and availability (held by PALNI, held by libraries worldwide, etc.). This enabled the application to be built with the understanding that OneButton would only display for monographs that have consortial holdings (in print), as all other resource sharing for other formats (articles, media, etc.) is currently handled only through traditional ILL and never by consortial resource sharing.

From the user’s perspective, no matter how many fulfillment options are technically available to them (retrieve the item from the shelf, place a PALShare request, or place ILL request) they will only see “one button” for requesting items [see Figure 3]. The button also appears on items that are held by the user’s home institution. It was determined that the button should appear on items that are held by the user’s home institution so that users can potentially request items through consortial borrowing that are held by the home institution but not available there (checked out or non-circulating). Some libraries in the consortia also enable users to place ‘on-shelf holds,’ effectively paging the item and triggering a workflow in WMS to retrieve the item from the shelf and place it on hold for the user.

It was theorized that some users, when looking at a print book held and available by the user’s own institution, may not know what the next step is in order to borrow the item – they may not know enough about how libraries usually work to know that they can go up to the item’s shelving location to retrieve the item themselves.

Figure 3. WorldCat Discovery interface showing OneButton link resolver in action as a button labeled “Get It”. In this particular case, as the item is held and available through the consortium (“PALNI Partner Libraries”), if the button is clicked, the user will be automatically directed to a consortial place hold screen (provided the consortially-held items are available and lendable).

The application is written in PHP and leverages the OCLC WMS Availability API (available for libraries using the OCLC WorldShare Management System (WMS)), but the underlying conceptual design behind the application could be adapted for any library management system that has an API or another programmatic way to retrieve availability information about items from metadata available in an OpenURL. For example, Ex Libris’ Alma library management system features Search and Retrieve via URL (SRU) integration that includes real-time availability information about items. Work is currently underway to adapt OneButton for use with Alma and Primo.

The conceptual design of OneButton was partially inspired by Umlaut, which is a Ruby on Rails application that is also designed to route users to optimal fulfillment options by supplying “links that take the user in as few clicks as possible to the service listed, without ever listing ‘blind links’ that you first have to click on to find out whether they are available.” It was determined that Umlaut had more functionality that was needed, as it features functionality to improve article-level fulfillment by querying catalog holdings and electronic resource knowledge bases (i.e., SFX). Our use case was limited to evaluating monograph holdings held locally or across the consortium, and it was determined that a custom solution would be simpler to build and maintain for the OneButton use case. Umlaut could have been adapted for our use case, and OneButton and Umlaut have the same goal: to make it easier for users to get to the resources they need.

Development

OneButton utilizes the OCLC PHP authorization library (available on GitHub) to send authorized queries to the OCLC WorldShare Management System (WMS)  Availability API. Libraries that use OCLC’s WMS library management system can request API key credentials from the OCLC Developer Network. The OCLC PHP authorization library and Guzzle are invoked by OneButton (installed using Composer) and are used to build and send authorized requests to the API.

Because OneButton is implemented in WorldCat Local or WorldCat Discovery as an OpenURL 1.0 resolver, well-formatted OpenURL data is appended to the URL sent to the OneButton script when the OneButton link is clicked from the discovery interface. OneButton stores the complete OpenURL data (for use if the end user is ultimately routed to a traditional ILL form that utilizes OpenURL data, such as an ILLiad request form) and also specifically retrieves the OCLC number for the title from the OpenURL string. The OCLC number is used as the primary identifier of the item and is included in the request sent to the WMS Availability API. An instance of the OneButton application is set up for each institution in the consortium with its own configuration settings, so each institution can determine which forms they want users to see for ILL (e.g., ILLiad or WorldShare ILL forms). Each institution configures their own local instance of OneButton in OCLC’s service configuration as an OpenURL resolver baseURL and configures the button to display only for monographs. When a user clicks OneButton from a given institution’s discovery system, the user is routed to that institution’s specific instance of OneButton, which evaluates holdings and fulfillment options accordingly.

The request URL built for OneButton also includes a parameter (x-return-group-availability) to return holdings data for all members of the consortia (which is organized like a group circulation network). A complete URL sent to the WMS Availability API looks like this:

https://worldcat.org/circ/availability/sru/service?x-registryId=128807&query=no:ocm319501305

Where 128807 is the institutionRegistry ID for the WMS Library and 3820802 is the OCLC number of the item pulled from the OpenURL string when OneButton is clicked. Note that this URL will only retrieve results if wrapped in a complete header request including valid API credentials, but it can be tested with the WMS Availability API using OCLC’s API Explorer.

Bibliographic data, holdings, and availability information is returned in MARCXML. An example of holdings data returned for an item by the WMS Availability API is shown below:

<holdings>
 <holding>
  <typeOfRecord>x</typeOfRecord>
  <encodingLevel>z</encodingLevel>
  <format>zu</format>
  <receiptAcqStatus>0</receiptAcqStatus>
  <generalRetention>8</generalRetention>
  <completeness>4</completeness>
  <dateOfReport>160421</dateOfReport>
  <nucCode>OCPSB</nucCode>
  <localLocation>WEST</localLocation>
  <shelvingLocation>WEST-STACKS</shelvingLocation>
  <callNumber>PR9199.4.J336 K55 2009</callNumber>
  <copyNumber>2</copyNumber>
  <volumes>
   <volume/>
  </volumes>
  <circulations>
   <circulation>
    <availableNow value="0"/>
    <itemId>3456789988</itemId>
    <renewable value="0"/>
    <onHold value="0"/>
    <reasonUnavailable>DISPATCHED</reasonUnavailable>
   </circulation>
  </circulations>
 </holding>
</holdings>

The OneButton script retrieves each holding entry and builds an array[1] for each holding that includes the institution (stored as a coded value in the nucCode, which is the Location from the MARC Holdings 852 $a), shelving location of the item, the call number, and the number of available items. The number of available items is stored in the value parameter in the availableNow element and represents whether the item is actually on the shelf (not checked out, withdrawn or otherwise unavailable). If an item is available, the value of the availableNow element will be 1; unavailable items have a value of 0. The barcode and the holding library (represented in the localLocation element) is also included in the array. From the example shown above, the array generated by OneButton would look something like this:

$line = array(
"inst"=>”OCPSB”,
"loc"=>”WEST-STACKS”,
"callnum"=>”PR9199.4.J336 K55 2009”, 
"avail"=>0, 
"barcode"=>”3456789988”, 
"localloc"=>”WEST”);

OneButton then loops through each array and evaluates the number of available items across all libraries. If the item is available at the user’s home institution and the home institution allows on-shelf holds (set in OneButton’s configuration file)[2], the user is automatically redirected to authenticate and place an on-shelf hold for the item. If on-shelf holds are not allowed but the item is available, the user is shown a screen indicating the holdings available for the item and directing the user to find the item on the shelf [see Figure 4].[3]

Figure 4. Screen shown to users when they click a request button for an item already held and available by the user’s home institution, and on-shelf holds are not configured in OneButton’s options.

If institutional items are not available but consortial holdings exist, OneButton compares the shelving locations of each held item against a list of non-lendable locations in the consortia.[4] The list of non-lendable locations was obtained by examining lending rules for consortial borrowing in OCLC Service Configuration and recording the locations that cannot be requested by any members of the consortia.

Including this evaluation of shelving locations into OneButton’s processing resolved a significant point of frustration for end users when requesting items through PALShare, as the default behavior for placing consortial holds in WorldCat Discovery and Local allowed users to place requests for items that didn’t lend consortially due to policies. Those requests would never be filled and would ultimately be canceled, requiring users to place a second request in the ILL system. Instead of directing users to place a consortial request that cannot be filled, with OneButton the user is now automatically directed to an ILL request form for a much better chance of receiving their requested item quickly.

After evaluating each holding array, if there is at least one item held across the consortium that shows as available and is NOT in the list of non-lending locations, the user is directed to a consortial place hold screen (which requires authentication). In the example above, the item has an availability value of 0, indicating the item is not available; if that particular item was the only item held by the consortia, a user attempting to request the item would be automatically redirected to an ILL request form. The ILL request URL would be constructed using the base URL of the ILL form indicated in OneButton configuration[5] and the full OpenURL string generated by the original OneButton request in WorldCat Local or Discovery.

Implementation

The application was available for beta implementation in November 2017, and one PALNI institution (Concordia Theological Seminary in Fort Wayne, Indiana) has been using the code since its beta release. Each time OneButton is clicked, the result of the holdings evaluation (PALShare request, ILL request, or Show Institutional Holdings / Place Hold on Institutional holdings) and the resulting URL to which the user is redirected are recorded in a log file for troubleshooting and usage analysis. Usage of OneButton by Concordia Theological Seminary since November 2017 to August 2018 is shown in Figure 5. 1,471 OneButton clicks have been handled by OneButton since November 2017 at Concordia.

Figure 5. Data from the first institution to go live with OneButton from November 2017 to August 2018.

As shown in figure 5, since the implementation of OneButton, PALShare requests (consortial resource sharing requests) have made up the majority of those 1471 requests, while ILL requests represent approximately 34% of all OneButton clicks. 4.3% of clicks were on items that were held and available by the user’s home institution (so the user was shown the availability screen indicating the item’s availability and instructions to retrieve the item from the shelf).  While that number is low, it is interesting that a not insignificant number of users clicked a button to request an item that displays as held and available, indicating that at least some users were either confused by the availability display in WorldCat Discovery, or that they simply needed more guidance to retrieve the item themselves from the shelf. Only three requests (.2% of all requests) during this timeframe were routed to ILL automatically due to the WMS Availability API being down (not responding).

While we do not yet have sufficient data to determine whether the number of PALShare requests has gone up since the implementation of OneButton, several more PALNI institutions have implemented OneButton since its beta release, and analysis is underway to assess the extent of the impact of OneButton implementation on resource sharing use. It is worth noting that prior to the development of OneButton, Concordia was not participating in the PALShare resource sharing network due to concerns about potential usability issues and button confusion; but since implementing OneButton, PALShare now fulfills more user requests than ILL at Concordia.

Future Development

OneButton is available for any OCLC WorldShare Management System (WMS) and WorldCat Discovery or Local library to implement, and development is currently underway to adapt the application design for use by Alma / Primo libraries. Work is also underway to automate the aggregation and reporting of analytics from OneButton clicks and integrate those statistics into a dashboard that would enable libraries to compare OneButton click activity with resource sharing and ILL statistics.

Development is also in progress to display detailed stack maps to users when they click OneButton for an item that is held and available for their institution. The stack map would display on the availability screen shown in Figure 4 above and will include detailed directions regarding how to navigate to the item in the library.

Although OneButton is currently designed to work only with print monographic resource sharing, there is interest in exploring the development of functionality that would direct users to open access options where those options are available. For example, it may be possible to identify whether open access options are available by looking up a requested item using the Open Access Button API. This possibility may also lead to further development adapting OneButton to handle article requests, particularly in order to help users who encounter problems accessing the full-text of an article through traditional OpenURL resolving. Other future development possibilities including routing users to purchase request or copyright clearance options if items meet certain criteria. While these potential improvements are in the early stages of research and development, we are ultimately hopeful that OneButton will continue to resolve many problems users encounter when accessing and requesting library materials.

Endnotes

[1] See https://github.com/PALNI/onebutton/blob/master/link.php#L115

[2] See https://github.com/PALNI/onebutton/blob/master/config.php.sample#L14

[3] The design and display of the page showing institutionally available items is configured in the ShowPage function in OneButton: https://github.com/PALNI/onebutton/blob/master/link.php#L202

[4] An example of this configuration file is available at: https://github.com/PALNI/onebutton/blob/master/nonlending.php.sample< [5] The ILL form URL is specified in OneButton configuration here: https://github.com/PALNI/onebutton/blob/master/config.php.sample#L18

About the Authors

Lauren Magnuson is the Development Coordinator for the Private Academic Library Network of Indiana and the Head of Collections, Delivery and Access at California State University, San Marcos in San Marcos, California.

Karl Stutzman is Director of Library Services at Anabaptist Mennonite Biblical Seminary in Elkhart, Indiana.

Rev. Roger Peters is Assistant to the Director of Library and Information Services at Concordia Theological Seminary in Fort Wayne, Indiana.

Noah Brubaker is Associate Director of the Private Academic Library Network of Indiana.