Oceanside Public Library Home Delivery System

_______________

A Capstone Report

Presented to the

Faculty of CST 499 at California State University, Monterey Bay

_______________

In Partial Fulfillment

of the Requirements for the Degree

Bachelor of Science

in Computer Science

_______________

By

Marcus Gonzalez

Adam Houser

Jason Pettit

Fall 2020
 EXECUTIVE SUMMARY OF REPORT

Oceanside Library Home Delivery System

by

Marcus Gonzalez, Adam Houser, Jason Pettit

Bachelor of Science in Computer Science California State University Monterey Bay, 2020

The purpose of this project is to help our community library in updating their tools and

processes in order to better serve the patrons. Because of the COVID-19 pandemic and social

distancing guidelines, the library is not open for normal business and is expanding to deliver

goods to patrons’ homes.

Our goal is to help eliminate waste and make the work of delivering patrons’ books more

efficient. We plan to accomplish this utilizing the existing library functions and create a tool that

integrates the multiple system outputs into a user friendly experience which allows the

employees to perform their tasks easier and more efficiently.

The expected outcome is a website site that will allow library staff to walk the shelves

and pick books for patrons then send them to the next step with a single click - be that step

checkout, set for curbside pickup, or in location pickup (with a thought towards when the library

reopens for regular business).

 TABLE OF CONTENTS

EXECUTIVE SUMMARY OF REPORT 2

TABLE OF CONTENTS 3
PART I 4
BACKGROUND AND APPROACH 4
INTRODUCTION 4
Project Name And Description 4
Problem And/Or Issue With Technology 5
Solution To The Problem 5
Project Goals and Objectives 6
Community and Stakeholders 7
Evidence Of Need 8
Feasibility Report 9
PART II 11
DESIGN REQUIREMENTS 11
Functional decomposition of the project 11
Selection of design criterion 12
Final deliverables 13
Approach/Methodology 14
Ethical considerations 15
Legal considerations 16
PART III 17
PROJECT SCOPE 17
Timeline/Budget 17
Usability Testing/Evaluation 19
Final Implementation 20
Discussion 25
Conclusion 25
REFERENCES 26
APPENDIX A 27
TEAM MEMBERS 27
Marcus Gonzalez 27
Adam Houser 27
Jason Pettit 27
 PART I

BACKGROUND AND APPROACH

INTRODUCTION

Project Name And Description

With the COVID-19 pandemic hitting the US in full force in early 2020, many businesses

have had to take a hard look at how they operate. We’ve seen many try a work from home

approach, and those that offer services try to work in delivery or pickup. Public libraries aren’t

exempt from this either. With new social distancing rules and indoor locations being

closed/restricted, one of our local libraries has taken to delivering books to patrons. This was not

the intended setup for the library, and the system, software, and procedures in place don’t make

for efficient work. Our project looks to address these concerns and allow the employees of the

library to more easily and more efficiently pull patron holds, and deliver them with a “work

smarter, not harder” approach.

The Oceanside Public Library needed a way to address the added work with reduced

staff. Given the pandemic situation, hourly staff was cut, so the number of workers to shelve,

check-in, check-out, and retrieve books was reduced. Granted there were fewer in person tasks

to do with the library being closed, but with the added task to deliver books to the home, that was

more time out of the library as well. Additionally, as a look to the future, the library will be

implementing a curbside pickup option to try and find a middle ground where patrons can pick

books up while being compliant with pandemic social distancing rules and guidelines. Our

project planned for this option as well by providing library staff with easy identification of books
for patron pickup (for the future when the library reopens fully), curbside pickup, and home

delivery.

Problem And/Or Issue With Technology

Libraries are, at their core, a place where people come to get information. The biggest

problem this presents in a COVID-19 world is people gathering together in close proximity. The

Oceanside Library has shifted to bringing information to its patrons. However, that's not how the

library was set up, nor how the tools and programs in the organization were planned to be used.

Previously, employees were using multiple systems and tools, with manual input and output, to

do their best to get books and information to patrons’ homes in the best way possible.

Essentially, the library and it’s employees were trying to continue performing their jobs and

functions, but in an entirely different way, and were not equipped with the best tools for the job.

Specifically, employees printed a paper of all holds that were supposed to be in stock. They then

walked the shelves, pulled these books, and brought them to a checkout station. The employee

still needed to check out the book to the patron as if the patron was picking up the book in

person, and now they have the added task to label the book or place it in a bag/bin for home

delivery sorting. After the books were checked out, a list of patron addresses was compiled and

fed into a routing software to calculate the optimum delivery route. Each of these steps required

either movement to a specific location, or logging into a different application.

Solution To The Problem

Our solution to the library’s problem has multiple steps.

 1. Create a web based interface that will take the place of the physical paper they print,

pulling all hold information from their database. This will allow staff to have access to

the list of holds on demand and not tie them to a computer station. The library has tablets

and bluetooth barcode scanners that can be used by staff walking around the facility

already, so no new hardware was needed.

2. With the web form completed, we will attach buttons to the form to allow the employees

to perform tasks real time as they pull books. We implemented a “missing item” button,

which is a status in the library’s database system, as well as a checkout option. With our

plan to future proof the design, we have not yet decided on whether or not to implement

multiple options, such as “hold”, “curbside pickup”, “home delivery” buttons, or one

button to then look back at a status and perform the appropriate task. That will be

detailed in design discussions.

3. After the form is providing the data based on the employee button clicks, we can tie in

with the routing program to provide the employee automatic sorting based on delivery

stop or customer name so that it happens as checkouts occur.

Project Goals and Objectives

Goals

● Develop a web based application that performs functions the Oceanside Public Library

currently uses in a less efficient manner using a combination of paper and computers.

● Improve current workflow of the Oceanside Library by reducing time spent repeating

tasks on paper. Additionally, provide more accurate tracking of books after they leave the

shelf.
 ● Interface application with site’s database and source JSON for use by the library.

● Improve the use of notifications employed by the current system as books are checked in

and out of the library.

● Improve the user experience of the Oceanside library community as well as the library

staff.

Objectives

● Assess the current library system and derive an application for use by library staff that

utilizes all information currently in place.

● After developing the base program according to specification, examine any further

improvements that can be made to improve upon the workflow that the newly developed

application brings to the library.

● Examine the current use of notifications received by patrons picking up library books. No

more than one notification is needed, but it has been stated that timing of notifications

aren’t accurate.

Community and Stakeholders

There are a couple of layers of stakeholders for this project. Immediately, the library

employees and patrons come to mind. The library employees will be the one to directly benefit

from the increased efficiency should the project go according to plan. They will find their shifts

not burdened with extra non-Lean steps, and should have input on the user interface and user

experience of the solution. We worked through our library technology liaison, Sam, to get this

information. Additionally, the greater efficiency here will allow those employees that are

working on developing other programs, more time to work on that development, which will
hopefully lead to better programs. The patrons are another stakeholder, they benefit from having

library materials delivered quicker and better notifications once we get into the future state where

the library is doing both curbside pickup and home delivery. The current system does not

support the notifications, so it is on the employees to do that manually.

From a scholastic standpoint, both us students pursuing a degree, and the university

bestowing the degree are stakeholders of this project. If everything goes to plan, we pass our

class and earn our degree. This is a gain for the students either entering the workforce, looking

to bridge into a new field, or complementing a prior degree. Similarly, the university adds more

numbers to the list of successful graduates, which helps attract more students and professors in

the terms to come.

As for community, a library is an important location where people can come for learning

and resources that may not be available elsewhere. By helping the library succeed, especially in

this difficult time, we help position the library as a successful enterprise. Hopefully this will lead

to a positive outlook from the community and elected officials, which will translate into funds to

keep the library running and allow them to build more programs.

Evidence Of Need

Our liaison at the library, Samuel Liston, asked for a project like this to help their

employees. The need to help them “work smarter not harder” was evident in our visit to the

library where we walked the process. By reducing the time employees are spending on gathering

books and information for home delivery, we can free them up to work on other projects and

programs for community enrichment and learning. While much has changed given the closing

for in-person visits, employees are still trying to engage the public in reading and community
programs where they can. This involves retooling any existing programs, and creating new ones

from scratch, which takes time - time that is eaten up with the less efficient home delivery

process currently deployed.

Feasibility Report

From the environmental scan during our proposal, we briefly analyzed the library's use of

Sierra DNA and the RESTful API associated with it during the checkout process (Innovative

Interfaces Inc.). Additionally, we found a program in use by Purdue University’s Interlibrary

loan department, which allows for books and media to be loaned between libraries (Purdue,

2020). The RESTFUL API employed by the library has proven to be an important aspect in the

communication process, as hold status updates can only be done through a call to the API. Also,

book checkouts are done through Standard Interchange Protocol (SIP), which is similar to REST

in its use for data transfer.

After analyzing the library checkout process, which had been using paper to pick books

before taking them to a computer for hold updates in the system, it was clear that a website was

needed. The versatility of a website is that it can be accessed using on site computers, and with

our implementation of the Bootstrap framework, on a tablet with no discrepancies between the

two devices as books are picked. In our web page design, we have conformed to a similar look

and feel that was in use with the library’s original hold print out, with the addition of two buttons

for declaring a book on hold or missing. The use of these buttons are tied directly to the RESTful

API, with item checkout through SIP coming in our next sprint.

The SIP versus RESTful protocol used in our application was a design question brought

up in the initial phase of development, as RESTful is better documented and already in use with

the current system. However, our point of contact stated that SIP is the current method of the
actual checkout process, which would not be feasible for us to change given the extent of the

library system. Likewise, we have identified a class in Java that allows for SIP communication,

which should not pose problems in implementing our current system. Furthermore, research into

the library’s use of SIP shows that it is a system used around the globe.

The Standard Interchange Protocol (SIP) employed by the library was a method of

checkout that was presented as a system that happened to be in place for the checkout process,

but upon further research showed to be a global standard developed by 3M Library Systems. The

most interesting part of the SIP protocol developed by 3M is that it “paved the way for

self-service devices” (Finley, 2012). In our applications interaction with SIP, it was important to

know know only how to communicate with the protocol, but also why we are communicating

with it. With 3M having built library Selfcheck systems as far back as 1992 (Finley, 2012), it

makes sense that we are now interfacing with those systems in our work with the library given

their use of these systems.

The overall design and development of the library home delivery system has been

deliberate in collaboration with our point of contact. From our design choice of Java in

conjunction with the Spring framework, to our interaction with the SIP and Restful services, the

website should prove future proof for a decent period of time following completion.

Additionally, as our team moves into testing the product on site with scanners, our use of the

Bootstrap framework should prove versatile in the sites compatibility with both desktop and

tablet devices. Most importantly, our applications interface with the SIP protocol, a nationally if

not globally accepted protocol among library systems, will keep our application working with a

system that shows no sign of declining.

 PART II

DESIGN REQUIREMENTS

Functional decomposition of the project

After our initial walkthrough of the Oceanside Library, we gathered necessary

information for the needs and design of the required project. The library had been using a paper

printout to gather books for patrons that needed to be checked out. The printout provided by the

client would then be taken to a desk where the data was then entered to place books on hold.

Furthermore, the library’s processes for checkout and demand influx of book deliveries brought

cause for a more fluid system. Given the paper format in use, and our teammates previous work

with the library building the associated query, the logical solution was a website to simplify the

existing process.

With all the information from the library printout already being brought in through a SQL

query, our next step was to decide on a suitable backend that would be practical and efficient for

a website. Given our team's previous work with Java and the Spring framework, it made the most

sense to continue using these technologies for our backend development. Additionally, given the

library’s use of the Standard Interchange Protocol (SIP) for library procedures, the Java open

source library for SIP was a requirement for our project to successfully checkout an item through

the application. For our frontend we used the mobile friendly bootstrap framework, with

datatables plug-in allowing us to present hold information in a format similar to the one already

in use.

The cohesiveness of the webpage and its use of datatables in conjunction with the Java

backend provided the necessary tools to the library in order to move away from a monotonous

process. The ability of the Java backend to pull data from the libraries Sierra database and
communicate with the Sierra API allowed for a system that both compressed and simplified the

previous process.

Selection of design criterion

The success of our application was dependent on the ability to incorporate many

functions performed by the library during the hold to checkout process. Our checkout system

will run on the Spring framework which will be configured with the Oceanside Library server.

Deploying our application on the library server will give the library constant access on the ipads

and computers used for the checkout process. Additionally, it will provide a layer of security that

the library can manage.

Because our application used the library’s Sierra database, we needed to be security

conscious both in writing the code, and in how the code would be used at the library. When

writing our SQL queries, we made sure to use placeholders to prevent SQL injection. From an

access to data perspective, since the application was targeted solely for use by the library staff,

security of the data itself was not a major concern. Additionally, the application will not be

accessible by the general public since it will be hosted on the library’s server, behind user

authentication.

While security of the application was important, since the library is a public organization,

and costs are always tight, the cost to bring the system to the library was equally as important.

Thankfully, with our system interfacing with their existing database, the major cost of setting up

a new database for the library was avoided. This made for a very practical solution to the library

with no overhead costs to them. Also, it maintained the reliability of their existing partnership

with Sierra. They may see some future costs in more tablets, barcode scanners, and/or printers,
but nothing additional was required from a hardware or software standpoint that added cost to

the project.

Final deliverables

We have created a website for internal library use that automates many of the steps

library employees were manually running. The process flow is as follows:

1. The library employee uses a tablet and our site to pull the list of patron holds where the

books are in stock. The list can be sorted by library location, for example Civic versus

Mission branch, and the books are presented in shelf location order to best minimize

waste in pulling books (no repeat visits to shelves).

2. As the employee pulls books from the shelf, they click a button on the corresponding row

they are filling. A popup for barcode scan is presented, and the employee scans the

barcode in with a bluetooth wireless barcode scanner. The site then performs a lookup to

make sure the book pulled matches the book in the hold. There is logic for both a bib

hold, where the patron wants any version of a title, and an item hold, where the patron

wants a specific book. If the scan is a match, the hold and item is updated and the row

“moves” to the second page. If not, it is flagged as a mismatch or invalid barcode on the

page so the employee can try again.

3. Once done pulling all books, the employee or another employee will utilize the second

page for sorting and checkout. This page presents all the items and holds filled, and

applies the sort; flagging items going to another branch for “in transit”, items for pickup

for “on holdshelf”, and items for delivery as “for delivery.”

Approach/Methodology

Our plan for solving this problem began with a visit to the library to see what was

possible and available. We believed that the data was already there, and it was just a matter of

getting it and presenting it efficiently. The library had a backbone library system in place

already, Sierra by Innovative. We used this system to get the required information. Once we

understood the current state and, most importantly, the data flow of that current state, we looked

to see how best that could be improved. Our library liaison, Sam, gave us a lot of freedom in

design, so we did some discussion and high level design as a team, then took that back to Sam to

get the impression and requirements from the library side for the path we’d started down. This

iterated a couple of times through our 2 week sprints.

The particular license the library has with Sierra does not allow creation of new tables, so

we had to utilize multiple SQL queries to gather the needed information to pass back and forth.

We knew we would need: patron, book, hold, and address information at a minimum. Once we

had the data identified, we built the intranet site to better present hold data that needed to be

picked, and developed javascript and java queries to communicate directly with the database to

allow the employees to work more efficiently. A big help in this was Datatables, an addin to

create and manipulate tables (SpryMedia). The starting point for us was to follow the physical

process and align the data and system processes to that, including a physical printout that

employees were using as their “pick list” as a reference for format/fields.

Sam, our liaison, provided us with some documentation on the other programs used:

Routific (used to create the route for delivery), the restful API for Sierra (documented on Sierra’s
website), and SIP (the exchange protocol library systems use). We were requested to keep as

much client side as we can, so we kept much of our development in javascript.

Ethical considerations

For this project, we adapted a current paper system to a mobile application. The library

staff are the primary beneficiaries of our work, and likewise, our ethical considerations were

mostly due to library staff during the course of our project. In regards to the general public, our

program will solely be used over the libraries intranet, which means we won’t be at a major risk

of information security breaches. Our team’s primary ethical obligation to both the library and its

patrons is to maintain data integrity as we mostly worked remotely with the library, meaning we

were given remote access to work with their database. From an information security standpoint,

our project was fairly straightforward. However there were considerations related to the building

of the project itself that our team had to keep in mind.

The timeline of this project was important for both the library and the group members,

which presents our ethical consideration to the library. During the build of our project for the

library, it was our responsibility to effectively communicate the progress of our project. In

addition to effective communication, we needed to ensure that we were implementing the major

features requested by the library, as well as minor features such as notification functionality. In

summary, our primary ethical focuses were open and effective communication with the library

and the safe keeping of data we were entrusted with.

Legal considerations

This project creates a new web interface for existing Oceanside Public Library systems to

facilitate the materials delivery program implemented in response to COVID-19 restrictions. As

such, our project does not establish new patron records containing personal information that is

not already available in Oceanside Public Library systems. This project needed to consider

maintaining the data privacy of patron data in accordance with existing library policies. As we

developed our interface we needed to ensure that any personal information was not transmitted in

plain text to avoid interception. Furthermore we worked with library staff as we developed the

application interface to remove any information that should not be part of the book retrieval

process.

The project application may also be interfacing with third party routing software,

Routific, used by the library to determine efficient delivery routes. Again, we followed existing

library practices regarding what information is transmitted to the third party for this purpose. Of

concern was personal information, including potentially gate codes to access a patron’s

residence, as requested on the Oceanside Public Library card application form (Oceanside Public

Library).

Throughout the project we used existing library policies, as well as, proper handling of

data when our application transmits it to guide us. We also planned to advise the library on any

security issues that may need to be addressed in our application or in the library’s existing

policies, but none came up due to us following existing practices.

 PART III

PROJECT SCOPE

Timeline/Budget

The timeline for this project started July 25, 2020, when we made our initial visit to the

Oceanside Library. It was completed at the end of the Capstone class, when we presented our

project. Our goal for builds was a three-sprint approach: two weeks each for sprint 1, 2, and 3.

We tried, and were able to get our initial visit in a little early because we knew we had a good

amount of work ahead, and were overlapping our prior class, so we left some extra time on the

front end to get the project started with less time per week. We planned for weeks 2 and 3, weeks

4 and 5, and weeks 6 and 7 of our actual Capstone class as our sprints. Week 1 and 8 were left

for putting together the design and presentation respectively. Overall, we met our milestones,

though there was some concern in the middle. Bullet points of our plan and what was

accomplished in each sprint are:

● Initial visit and data gathering, July 25, 2020 - We made our initial visit to the library to

walk the process and see what was being done. We took notes to review as a team to

understand what the pain points of the process were and what the most important

requirements (MIRs) of a new tool were as well.

● Mapping of current state and design of future state, August 1 - August 30, 2020 - Using

artifacts from our visit, as well as some additional pieces provided by the client, we put

together a flow of the current state, and then worked from there to design a future state.

This timeframe was longer than other sections because we were overlapping with another
 class, so we had to split out attention between them. This was the main reason we

wanted to get our visit in early since we knew this would take time.

● Sprint 1, August 30 - September 12, 2020 - Our initial design was done on a server we

setup ourselves with data we staged. We used Heroku to host a database and worked

through implementing our initial design. Security to the library’s actual data was being

worked from the client side, so this allowed us to develop without that security and get a

prototype product the client could review.

● Sprint 2, September 13 - 26, 2020 - We met with the client on September 12 to review

our first sprint. The client was very pleased overall, and had a few suggestions/requests

on changes. The overall design was kept the same, but we used these next two weeks to

make those client requested updates, and to adapt our code for the library’s real database.

This sprint was the only one that did not stick to our plan. There were some struggles

getting a finished sprint 2 product due to some remaining security issues, but those were

resolved in the beginning of sprint 3.

● Sprint 3, Implementation and testing, September 27 - October 10, 2020 - We reviewed

with the client again on October 2, and they were very excited to see the product. There

were two minor changes requested, and during testing we found a bit of data

manipulation the library’s system was doing we weren’t aware of, so this last sprint was

used to finalize everything into a deliverable package.

● Customer sign-off, week of October 11 - 17, 2020 - We met with the client for final

approval after work.

● Preparation of Capstone report, week of October 11 - 17, 2020

● Presentation of Capstone project, October 17, 2020

 As stated in our proposal, we did not have a budget for this project. Servers and

hardware to support the initial plan are already owned by the Oceanside Library, so it was only a

matter of software development. Future enhancements may include some wireless printers to

open up the second page to a non-workstation setup, but that was not part of our scope.

Usability Testing/Evaluation

Since we started with our own environment and staged data to represent what the library

data looked like, much of our initial testing was done with this data. We did not have to worry

about poor data influencing a live system, so we conducted positive and negative tests on all of

our buttons and functions within the team. Once we reached the end of Sprint 1, we used this

instance of data to demonstrate to the client. Due to social distance guidelines and the data being

run from a member’s personal computer, we walked the client through the usage and then asked

for other opportunities that we may have missed, edge and corner cases that would cause

problems.

Once we started using the library’s live data, we had to be more careful. We were issued

library cards and given access to the circulation system in the live system. We picked books that

were seldom/never checked out, and would put holds on those using the circulation system, then

we’d process them through our application, always returning them to the state of checked in

before finishing up. During our meets with the client, we’d use this same setup to show the

features of our application: we’d scan incorrect barcodes, correct barcodes, have pickup locations

differ, etc.
Final Implementation

Our final application ended up doing a lot of background information gathering and

processing, and tried to eliminate as many manual steps as possible. We left a few in where it

made sense, such as going to a computer attached to a printer to print labels, but did our best to

institute error checking while minimizing manual tasks.

1. The application starts by querying a list of open holds with stock that supports and

presenting this to the employee for picking. The heart of this is an enormous SQL query

to put the data together. The library’s system, Sierra DNA, consists of only views, so we

were not able to create a new table, or even another view to work with. So, we had to

work with common table expressions (CTEs) and all the SQL tips and tricks we could

find to logically pull and sort the data from the library for the employees. This is

deserialized into a Hold object in our program, and then displayed on a webpage sorted

by location and call number. This allows the employee to walk the shelves and pull

books by area as opposed to hunting or manually sorting through a list. We used a tool

called Datatables to format our data, and presented the fields immediately needed, while

adding some secondary fields inside an expansion button. See figure 1 for an example of

the first page, including with a search field to find a particular book.
 Figure 1

2. When the employee locates a book to pick, they will click the Pick Item button and are

presented with a popup to scan in the book’s barcode. This will then query the database

and validate the barcode is a match. There are two types of holds, bib and item. A bib

hold is a hold for a title, the patron is saying, “I want any copy of this book you have.”

An item hold is a hold for a specific book. The patron is saying, “I want this specific

book, not any other.” Based on the logic of the SQL statement in step 1, the application

knows if it is an item hold of a bib hold, and based on knowing that, we look either for

the specific barcode for that item on hold, or we make sure the barcode scanned matches

the bib of the book placed on hold. If there is a match, the Pick Item button turns green

and changes to On Cart, as seen in Figure 1. We also scanned the library’s barcodes and

found none were shorter than 9 characters, or longer than 16 characters. To avoid

querying the database when it wasn’t needed, we put a length check up front to see if it

was in the valid range. If it is not, the button will turn red and say Invalid Barcode.
 Lastly, if the employee picks a valid book, but just the wrong one, the check will return

false and the button will turn red and say Bib ID Mismatch.

3. When the barcode matches and the book pick is successful, the application does three

things in succession. First, it utilizes the 3M SIP protocol to perform a CheckIn function

with the circulation system. Because of some logic in the Sierra circulation system, this

automatically flags both the hold and the item itself that a match has been found and the

item will be put on the hold shelf. The logic here was originally intended to prevent

newly returned books from being shelved if there was an open hold, but we opted to

utilize it as well for our application. Second, part of that logic actually deletes the

existing hold and creates a new hold with the same information, but new status. Because

of this, we need to run a lookup by patron ID to get that new hold number. Third, we

take that new hold number and attach it, via the RestAPI, to a Varfield element. This

allows us to differentiate between the holds that have had printing and “second stage

processing” done, and those that have not.

4. The library employee may find the book is missing. If this is the case, they will use the

NOS button on the page. NOS is the library’s acronym for not-on-shelf, and it will flag

the book missing. Similar to the barcode check, if it is an item hold that is missing, the

NOS button will take that item and set the status to ‘m’ for missing. We do this through

the RestAPI. If it is a bib hold and the item is missing, that means that all the copies of

the book in that location are missing. When the NOS button is pressed in this case, we

query the database for a list of all items of that bib in the location and flag them all to ‘m’

for missing. The interesting thing about using the RestAPI for this is the security
 requirements for a token. We have to generate a token in the background, then pass that

token with our request to make the update.

5. We used the Datatables extension and SearchPanes to help format the table and allow

searching if needed. One scenario explained to us could be the library is looking to pull

just those books for home delivery in one section of the city. To support this, we pull in

the code they use for that district, and the employee can use that to filter the results.

Figure 2

6. Once the employee is finished picking the books they need, they can click the button to

view the items on the cart. This will represent everything they’ve picked and loaded on
 the wheeled cart as they move around the library. This page is similarly styled, fed by an

SQL query. This query is less complicated though since we are able to tie the hold to the

item through the Varfield mentioned in number 3. The employee is presented with key

information again up front, and secondary information in an expandable field. The intent

of this page is for the employee to print tickets for each item. Much like the first page,

each item has a line and there’s an “action button” for that line. That button will instruct

the employee on what the next step for the book is depending on where the book is being

picked (the fill location) and where the book is needed (the pickup location). If the fill

location and pickup location are the same, that means the patron wants to come into that

particular location and pick the book up. In this case the ticket that prints will have

minimal information (personal information security) to allow the patron to find their book

on the hold shelf. When the pickup location is designated as Home Delivery, the ticket

will print with patron name, address, and phone number, to allow the delivery driver easy

access to information to find the patron’s house. The last option is the pickup location is

at a different branch than where the book is. When this happens, the same information

for patron pickup prints (first initial, last name, book title), but it is flagged as Transit at

the top along with the branch it needs to go to.

7. After the print, the application updates the item Varfield to null. This will keep the hold

from appearing on this page in the future. Holds may exist with tickets printed for days

until the patron picks them up. We don’t want to try and process them again. Also, if the

book is for Home Delivery, the application connects through the 3M SIP protocol to the

Sierra Circulation system and performs a CheckOut to the patron.

 8. Finally, the employee can export information to feed into the routing program, Routific.

We’ve included a button that exports the sorted data to a CSV file. This was something

that they needed to look up and compile one by one in the past, and we’re now able to

compile as a whole through our queries.

Discussion

Like any project, we ran into some problems along the way that had to be overcome. The

biggest was one of access. Throughout the entire project, only one member could access the live

library data from home. This was due to a security requirement on the library’s side requiring a

static IP address to gain access. Local internet companies in our area make that a difficult thing

to obtain on just a residential account. Because of this we either had to be on site and use the

library’s network, or find another way to develop. We handled this problem in multiple ways.

In the early stages of development, we all worked in our own staged environment. We created

tables in a Heroku powered database based on the Sierra DNA documentation. This allowed us

to begin to develop the code to show and manipulate the data. Once one of us was able to get

access from home, we started moving that code that was created in our development branch to a

library development branch. This led to a little extra work, but it allowed all of us to work on

various parts of the project at all times. Additionally, we did arrange to do some work on site

when needed. This was nice because we could be physically in front of the client if needed and

both get feedback and ask questions. It proved key to a couple breakthroughs in our problem

solving.

Another issue we encountered was dealing with other systems/protocols/code. When

third party applications need to be used, one is at the mercy of how they are built. Our original
intent was to interface 100% with the Sierra DNA database using their RestAPI endpoints, but

when we researched our options fully, we found that there were some things not enabled over

RestAPI that we needed to do. This led us to the 3M SIP protocol. It is a standard protocol used

by library self checkout terminals, and can send messages similar to how a RestAPI works.

However, it is a unique protocol consisting of various sending messages and response messages.

We needed to learn what messages needed to be sent, and how to interpret and interact with the

response messages. Luckily, there was an open source java implementation of 3M SIP2 protocol

by Ceridwen we were able to harness (Ceridwen). We still had to understand what messages to

send and how to interact with the responses, but the heavy lifting of engineering the classes and

establishing the connections was covered in this implementation. One final struggle, this

communication required being on site for all users, regardless of static IP or not, which drove a

lot of extra time debugging before we figured that out.

When it came to design, we came to a point where we needed to link the Hold with the

Item we were picking off the shelf. Our original intent was to use a field on the Item and update

it with the RestAPI, but that field was not available as part of the RestAPI endpoints. We

requested some guidance from the client, where they’d recommend we store the data to preserve

state, and we did not hear back for two weeks. Over a short project like this, that was a big

amount of time. We debated creating a secondary database just to maintain this link, and got so

far as to establish a project branch with multiple database connections setup and working.

Thankfully one of our team members was able to get an answer during a site visit, and we moved

the data to the Varfield mentioned earlier.

Conclusion

The Oceanside Library faced a problem adapting its existing programs and processes to

the new guidelines with the COVID-19 pandemic. The systems in place were all driven for in

person pickup, and the while the library was closed for months, the employees started to deliver

books to the patrons’ homes. Without tools specifically for this purpose, library employees were

left to manually lookup holds, pick them, check them out as if the patron was there in person,

then lookup patron address information to feed into a routing program.

Our solution to this problem was developing an application that performed much of the

circulation desk work and was usable from a tablet, so the employees could be mobile. We also

introduced error checking on demand, and presented the information in an easy to understand,

user friendly way in order to speed up the process with the number of clicks per process going

down. This way, information is gathered and presented in real time to the employee for both

book picking, and for delivery information. Additionally, we made the task easier on the

employee by performing data lookups in the background to forward to the next step in the

application, so that the employee wasn’t required to do these manually.

As a team, we were very happy to be able to work on a project that would help real

people right away. While we all enjoyed the projects throughout our program, solving an issue

with a cradle to grave design and implementation with live data was very fulfilling. We have

been working together for a couple years now so while we were already familiar with each

other’s strengths and weaknesses, it was good practice to lean on each other in the fields that one

was more comfortable than another. We all ran into issues and used a pair-programming process

to work through them, and the product turned out better for it. When we look to the future, our

client said they saw at minimum a 5 year lifespan for our application, and we hope it will allow
the home delivery aspect to continue once COVID restrictions ease up. Also, the possibility of

being expanded to other libraries with the same system is quite exciting!
 REFERENCES

Ceridwen 3M SIP Circulation Library for Java. Ceridwen.

https://www.ceridwen.com/selfissue/3m-sip/

Education: Home delivery of library books. (July 16, 2020). Purdue University

https://guides.lib.purdue.edu/c.php?g=352127&p=6216213

Finley, Emily (2012, June 7). ​3M Donates Standard Interchange Protocol (SIP) to National

Standards Organization.​

https://www.businesswire.com/news/home/20120607005809/en/

Innovative Interfaces Inc. (2020). Sierra product page https://www.iii.com/products/sierra-ils/

Oceanside Public Library Registration. (n.d.). Retrieved August 11, 2020, from

https://oceanside.lbxrn.com/reg/

SpryMedia Ltd. (n.d.). Datatables.net. Retrieved October 13, 2020, from https://datatables.net/
 APPENDIX A

TEAM MEMBERS

Marcus Gonzalez

Marcus took on the task of running our PivotalTracker process. He also was the key to

getting the application to communicate correctly with the 3M SIP protocol that allowed the

CheckIn and CheckOut functionality. Marcus was able to be on site during the week and

performed some key testing at critical times that moved us to the next phase.

Adam Houser

Adam worked mainly with the library data. The highlights here were developing the

SQL queries and translating the prototype functions using JPA to those that would work with the

library using jdbcTemplate.

Jason Pettit

Jason’s main focus was on the User Interface. Almost all of the html and Datatables

came from him. When we were first prototyping the application and had everything setup in our

own instance, Jason created the Heroku instances and PostgreSQL we used for prototyping.