





































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.


