328 ATL A 2018 PROCEEDINGS Building Library Web Apps By Steve Jamieson, Covenant Theological Seminary ABSTR ACT Previous conferences have included workshops encour- aging librarians to learn computer programming skills in order to develop efficient software solutions for problems they face in their work. This poster presentation highlighted two web apps developed by Covenant’s library staff: a reference e-book meta-search engine and an interac- tive ILL request form supporting inbound OpenURL linking. The poster described motivations for developing these apps, reviewed the tech- nology used and the development process, summarized the impact on library service, and identified directions for future development. E-REFERENCE METASEARCH Background & Challenges The Covenant Library had acquired a small collection of online refer- ence titles on the Gale Virtual Reference Library platform. Wanting to grow the availability of online reference content for our patrons, particularly in areas not as well served by Gale, we also added content on the Credo Reference platform (and still later added content from Oxford Reference and De Gruyter). However, by moving to having content distributed across multiple online reference platforms, there was no longer a single search interface for that content. If a patron was interested in a specific title, they could locate that through the library catalog, but there was no single place to search within all available online reference content. We wanted to provide our patrons with a single search interface that would surface relevant online reference material across all our online reference platforms. Design & Implementation MODULAR STRUCTURE Each platform provides its own unique API or interface for searching, so the search results are not provided in any consistent format. Therefore, we needed a modular design that Posters 329 https://www.covenantlibrary.org/reference-search/?q=inner-biblical+interpretation would allow us to drop in a custom connector script for each platform that would pass the user query to the appropriate endpoint, parse the response data according to the platform’s chosen format (XML, HTML, JSON, etc.), and return the data to our app in a standardized format and structure. 330 ATL A 2018 PROCEEDINGS ASYNCHRONOUS Response times for each platform vary, so rather than waiting for all responses to arrive before displaying results to the user, we run the searches of each platform asynchronously and dynamically update the search page as results come in. RANKING VS. GROUPING Results from each platform are returned in relevancy ranked order, but on what basis could we compare them against results from other platforms in order to interfile them? Would we even want to dynamically interfile results, as that would often cause items to move as the user was beginning to examine them? Implementing our own relevancy ranking algorithm seemed to be a more complicated task than we wanted to take on, so we instead grouped results by platform, displaying just the top five from each platform (in the order provided by the platform) followed by a link to continue searching on that platform. TECHNOLOGY When the user executes a search, our JavaScript web app uses the jQuery library to asynchronously call each of our connec- tor modules. The connector modules, written in PHP, query the refer- ence provider’s search API or interface; parse the response for the top five results, selecting the data we want to display to the user; and return that data to the app in JSON format. Our app processes the JSON from each connector as it arrives and dynamically adds the results to the page. Impact Our Online Reference Search tool met our objective of creating a one- stop search for all our online reference content. As we’ve grown from having two e-reference providers to four, the modular system design Library Server Search Results Area Connector A Pass query to provider Parse response Return JSON Connector B, etc AJAX Online Reference Platform AXML, HTTP, JSON, etc HTTP Get/post Posters 331 accommodated the new data sources easily. The hardest part was coding the new connector modules to communicate with the new platforms. Future Development As we add new platforms, we may have to reduce the number of results displayed from each platform, or rethink how we group and/or rank results, in order to ensure that content from all platforms is given sufficient prominence. ILL REQUEST FORM Background Covenant Seminary offers patron-initiated interlibrary loan service. Since the library does not have a patron-facing ILL system, the staff had configured the basic ILL request form function supplied by each of our major database platforms, where available. The library staff had also worked with the institution’s IT department to offer a basic web form for submitting ILL requests for items discovered in other contexts. Requests submitted through these systems produced an email with the submitted information to the library’s designated ILL contact. Challenges IDENTITY The ILL request systems built into the database platforms could generate requests based on the information on the record from which the patron initiated the request; however, the patron still had to enter his or her own identity and contact information for each request. The vendors provided few customization options, which meant that much of the information required by these forms was unnecessary for our needs or redundant with patron information already on file, and the information required by each vendor was different. We wanted a unified patron experience that minimized the need for patrons to repeatedly enter personal information that was unnec- essary or already available to the library staff. UNCLEAR PATRON WORKFLOW The inclusion of the ILL request link on the search results screen of our databases allowed patrons to initiate ILL without first using the library’s OpenURL link resolver service to check for availability in other library resources, so requests could be made for content already accessible to the patron. 332 ATL A 2018 PROCEEDINGS We wanted the patron to initiate the ILL request from the OpenURL resolver screen, creating a standard sequence of actions for our patrons, and for the OpenURL resolver to pass the item data into the ILL request form for accuracy. STAFF WORKFLOW ILL requests were coming from multiple inter- faces, with each providing data in a slightly different format. Adjust- ing to inconsistencies from one request to the next made transferring the data into the OCLC ILL system less efficient. We wanted the data in the ILL request notification email to be presented in a predictable format, and in a way that made it easy for staff to copy and paste into OCLC resource sharing. https://www.covenantlibrary.org/ill/ Posters 333 Design & Implementation PATRON DATA API INTEGRATION We used the API for accessing patron data provided by our ILS to create a login mechanism that allows us to automatically verify eligibility for ILL service, to include the neces- sary patron information in the notification to the ILL staff, and to offer online students the option of requesting copies of articles from our print periodicals. OPENURL SUPPORT In order to ensure accuracy, and for the conve- nience of the patron, it was vital that we be able to pass information about the desired item from our OpenURL link resolver into the ILL request form. Therefore, we programmed our form to parse OpenURL encoded information and to use that data to pre-fill the request form. OPTIMIZED EMAIL TO STAFF The email sent to the ILL staff notify- ing them of a new request was designed so that the information is presented in an order that is sensible to their workflow and formatted so that it is easy to select and copy. System-generated email from covenantlibrary.org 334 ATL A 2018 PROCEEDINGS RESPONSIVE WEB DESIGN With mobile device usage increasing, we made sure that the ILL request form looked and worked great on small and large screens alike. TECHNOLOGY The request form is implemented in PHP for managing the login session, parsing OpenURL data into the form, performing data validation after submission, and sending the staff a notification email. The form also makes use of JavaScript and the jQuery library to customize the form fields and options offered based on the requested material type. IMPACT We configured our OpenURL link resolver to display the new OpenURL-enabled ILL request form as a fulfillment option, and we removed the ILL request links from all of our databases. That created a clean, guided workflow for our patrons as they sought to access materials discovered in their searches. The clean, unified, optimized staff notification emails enhanced staff workflows. FUTURE DEVELOPMENT The ILL request form currently supports the original OpenURL 0.1 standard, which is still in wide use. For future compatibility, we will need to add support for the OpenURL 1.0 stan- dard.