11 minute read
Where’s my stuff? A First Attempt at a Multi-supplier “My Account” Area
By Allen Jones (Director, Digital Library and Technical Services, The New School) <jonesa@newschool.edu>
When library discovery systems directly link to materials, the user experience can facilitate research in some truly amazing ways — whether it’s owned material or material housed in evidence-based or demand-driven collections. However, when materials are not readily available or library intervention is required, the discovery service can launch patrons into a myriad of acquisition, interlibrary lending, and fulfillment web forms that are difficult to navigate at best. If you want a book or a physical item, check our consortial lending service (usually with some ironic name like EZBorrow, BorrowDirect, UBorrow, TexShare, etc.). If an available copy isn’t in that system, users may recommend an item for purchase in the collection or search a union catalog such as WorldCat to make the request in the library’s interlibrary lending service. Unfortunately, the experience of requesting articles and book chapters is no better. If the required citation or content is not in the full-text subscriptions of the library, patrons may be directed to an external web form to fill out a page for their article/book chapter of interest. If they are lucky, an OpenURL will populate the fields of that form so users do not have to cut and paste values into the search form. If such a link does not exist, users must resort to manually entering citation information into the fields of the request form, frequently leaving out identifying information such as serial and book identifiers like ISSN and ISBNs. At The New School libraries, five different web forms exist to request materials: recommend a purchase, the Relais D2D EZBorrow catalog (later ReShare), the ILLiad-based interlibrary loan request forms, links or widgets from libguides, and links from WorldCat. Having too many different methods to perform the same website task has been found to increase cognitive load, make your site harder to learn, and ultimately lead to user frustration (Wong, E., https://www.interaction-design.org/ literature/article/user-interface-design-guidelines-10-rulesof-thumb). In Jakob Nielsen’s seminal article on the ten usability heuristics, the author emphasizes two key heuristics that highlight major sources of frustration for website users. First, our patrons use other Internet sites more than they use our discovery service. To the extent that library systems follow navigational conventions and outcomes followed by other online services (called natural mapping), it’s easier for users to have a positive, consistent experience with the interface because it matches their preexisting understanding of how websites work (Nielsen, 2020). To the extent that these conventions are not followed, users will spend more time focusing on the interface itself than engaging with content. The second heuristic focuses on efficiency and the need to hide complexity/advanced functionality from the newly visiting user, offering services and shortcuts to more advanced users, but hiding complexity until a user’s experience with the website becomes more advanced. This may include strategies such as keyboard shortcuts or hidden features that bundle a number of actions together (such as pre-selected filters when a user logs in, etc.) for advanced users. Having too many of these services upfront makes for even more complicated navigation for undergraduate, and even graduate-level users because it may not be clear which service/function to use when. One area where this is particularly the case is in the requesting of materials. Because of the different systems that libraries employ, it can be increasingly difficult for patrons to find out how complete their request for content is. Similar to Amazon, patrons do not care about the seller of the goods within their marketplace. Rather, they want to know four basic elements about their order: how long they will have to wait, what format the item will arrive in (electronic or print), where to go to retrieve their order (physical location or link), and where to check the status of their order when there is a delay (and there will be delays). This type of progress tracking and status updating, particularly by incorporating direct communications for exceptional situations like delays, ultimately increases the engagement of the platform with web visitors (Rosala, M., 2019, https://www.nngroup.com/articles/status-tracker-progressupdate/).
The Evolution of Acquisition and Delivery Services
Below is a graphic of a typical journey of a user request in a discovery system looking for a particular citation. Depending on the user’s entry point, they would have to know whether to request a book in the correct requesting service. If it was a book, the user would be directed to the consortial returnables network. If it was an article, book chapter, or scan, they could be directed to ILLiad. While there might be different iterations of this within local institutions, the basic structure remains the same — the user had to use a system, not find the item, then make a decision about where to place the request next. Depending on where they placed the request, the information necessary at point of order — how long to wait, what format it will arrive in, where to go to pick it up, and the order’s current status, could live in different systems. (See Figure 1 on page 25.)
Because each of these suppliers has their own status messaging application, it’s difficult to ascertain how a user might track the status of their request without advanced knowledge.
At The New School, we reconfigured our request workflows to travel through Atlas System’s ILLiad software to consolidate requests into a single queue (course reserves still have their own interface because of the link to the learning management system). Whether the item is a book, book chapter, or article request, all requests are submitted from the discovery layer or an openURL link to ILLiad. Using addons for suppliers, ILLiad moves the request from supply network to supply network in order to minimize the user’s confusion of navigating error screens to move to the next borrowing network. Users are notified via email when their material arrives with instructions on how to pick up their material. (See Figure 2 on page 26.) Regarding the check on request status, with a single point to check, we have begun building and testing an eshelf application that checks the status of transactions within ILLiad. This application offers the ability to download completed requests, filter active, canceled and historical requests and sort by title, date submitted and request type. (See Figure 3 below.) While the current application states the request status, a subsequent version will include the request state within the larger completion process. The next iteration will have the following flow for each request to illustrate to patrons how far off their request is to completion. While any ILL librarian can tell you the location of a particular item is far from linear, the basic steps of receiving an order, sourcing, shipping and available for pickup mirror stages users might experience within ecommerce platforms they use on a daily basis: This type of customization would not be possible without the infrastructure of ILLiad to “normalize” all of the different request suppliers into common workflows and taxonomies. Collocating all of these services into a single platform is not a substitute for interoperability and library choice of request processing platform. We are thankful to Atlas Systems to provide these APIs and addons as a method of communication with their system. However, by relying on their webAPIs for this functionality, a different customization would have to be written for each request service platform (if vendors were open to communicating request information via an API). In a 2021 paper on data portability, interoperability and digital platform competition, the OECD defines three different approaches that libraries and library vendors might take to gain this level of interoperability. This framework is helpful in understanding approaches that library technology vendors have typically undertaken. They offer a third approach, a standardsbased interoperability scenario, that may address some of the entrenchment and hyper consolidation prevalent within the library technology sector. First, vertical interoperability. In this scenario, one vendor owns the entire set of tools that interact as well as the interfaces (APIs) that exchange input and output from each component. The advantage here is that the solution is proprietary and allows for development between the components to be tightly governed by a single vendor. This allows for the fastest pace of development of product to market, but at the loss of transparency and interoperability with systems potentially hosted or developed by competitors. Second, there is horizontal interoperability. Horizontal interoperability allows systems provided by third parties, such as commercial vendors and open-source communities to build
Figure 3
connections between components. Within the open-source community, this is achieved because code for the system is openly shared and transparent. Within vendor-based solutions, code for systems is seen as intellectual property and connections to external systems can be managed through business relationships. Within this interoperability model, the vendor or developer has the choice around who, and how, to perform information exchange between systems. Either the code is completely available and the burden is on the implementer to perform interoperability, or it is on the vendor to manage the information exchange through a business relationship of agreedupon terms. These types of relationships tend to be under scope/ control/governance of each vendor OR they can be offered to open-source projects as a potential alternative to the vendor’s vertical services. Again, the issue is about the disclosure of the business relationship and not just the information exchange standards.
A third form of interoperability exists between these two polar opposite approaches — a standards-based interoperability where vendors and open-source projects conform to an external format and practice governed by a standards organization. Many countries have national information standards organizations such as NISO (https://www.niso.org). NISO is a network of standards organizations working globally between the regional and national standards organizations to define appropriate architectures and protocols for information exchange between systems. This model of interoperability is “open enough.”
This model potentially limits vendors to develop software between their own components at their own speed, but they can also provide standards-based interfaces for external partners. For libraries, this approach offers the widest array of vendor partners to choose when looking for a software that delivers a particular type of service. For vendors concerned about a fully open architecture, keys or other forms of authorization can be used to communicate between vended solutions, as long as the license terms are clear between the partners and the library employing the system. In this sense, the business relationship and license terms of API Keys are disclosed to the customer and vendors do not have to create proprietary interfaces for each competitor software. Housing our transactions and workflows within a single system ensures institutions are less likely to migrate away from that platform (sometimes called “vendor or technology lock-in”). However, having a standard, secure way to communicate between the systems could go a long way towards reducing the complexity that users have to navigate in order to answer the seemingly simple question of “Where’s my stuff.” Moving to a standards-based interoperability approach means our library has the choice of components within our technology ecosystem and there would be minimal development if we changed under-lying platforms. In a similar way, the Open Discovery Initiative (http:// www.niso.org/standards-committees/odi) seeks to foster transparency between discovery aggregators, content providers and libraries. In this set of recommended practices, content within discovery aggregators can be viewed just as “standardscompliant” as the software we use to search it. When renewing software subscriptions, or even content provider licenses, libraries should ask the vendor to provide their statements on best practice conformance (for example, do you offer COUNTER5 statistics?) or Open Discovery conformance. These types of recommended practices support transparency and awareness of business relationships between vendors, their competitors and libraries. By asking for and insisting on conformance statements for discovery services or standards support for software, libraries are exercising their economic power to choose which components they wish to employ in their content/ technology ecosystems.
As we demonstrated with the ILLiad-based status application example within our Ex Libris Primo discovery environment, interoperability can ease the complexity that users have to navigate and provide libraries with the widest choice of features and options for their patrons. I hope there are others within the vendor and library community open to authoring a work item for NISO to consider standardizing status messages between supplier networks using web-based protocols. Such an endeavor would empower patrons to check the status of their material requests from vended platforms or consolidated “My Account” areas, empower libraries to develop single web applications where patron content orders can be consolidated, and allow vendors and suppliers to communicate with one another in new ways. If this is a project you are interested in participating in, please contact the author to begin discussing library and vendor requirements to exchange this information.
Bibliography
OECD (2021), Data portability, interoperability and digital platform competition, OECD Competition Committee Discussion Paper, http://oe.cd/dpic.
