Printer Friendly

Going the third way: developing custom software solutions for your library.

It is not uncommon for librarians to find themselves trapped between two options when seeking to create a new online service or extension of an existing service. The first involves appealing to a communications department or to central IT, most often to modify or build out the institutionwide CMS to satisfy some library need. The second involves seeking a solution from an outside vendor--most often a library-oriented vendor--or making due with a free consumer-targeted service such as Google apps.

While both options are workable and represent areas in which librarians have forged important relationships with central IT and vendors, there is a third way. It provides librarians with ultimate control and the opportunity for professional and departmental development. In practice, the third way involves librarians engaging in internal software development to create a custom software application that sits somewhere between a larger centralized effort within the institution's CMS and the purchase of an off-the-shelf or custom solution from a vendor.

The Problem We Faced

The concept of the third way came out of needing to replace the listings of reserve items held at the circulation desk of my current institution, a private university in New York. The library has historically maintained print binders containing subject-categorized lists of reserve materials at each circulation desk, allowing students to find their course's materials for checkout. The lists were maintained in a spreadsheet, with all modifications needing to be made to the master file before being printed for display.

The traditional setup presented several problems, which were targeted for fixing. The first and most obvious problem was the poor user experience of flipping through binders when searching for an item. Needless to say, among college-aged patrons, there is an expectation for library services to be online and easily browsable in a manner that mimics consumer-oriented applications, as well as being usable from any device. The second issue for library staffers was that maintaining the list within a local master file was needlessly cumbersome and allowed only a single user to update the sheets at a time. With times of high activity clustered at the beginning of the semester, simultaneous editing capability would greatly improve the process.

While it's true that all reserves information exists in the library catalog, the need for something easily browsable for students who may not readily have course numbers or professor names on hand created the need for something more closely resembling our existing binder lists. After evaluating a number of different options, including solutions from existing third-party products and using the institutional CMS site, a third way of building a small custom application emerged as the best solution.

Engineering Our Solution

A discussion of our experience with going the third way illustrates the general process of software development, detailing some considerations and decisions that allowed for the efficient build-out of the application.

Requirements Specification

The process began with determining the requirements to be satisfied by the proposed application. Evaluating the current system in use, by both patrons and staff members, was instructive in identifying our most common use-case scenarios. Additional functionality and feature enhancements were elicited through an evaluation of the landscape of popular apps and websites, both library-oriented and commercial.

The first stage of the process helped determine that our solution would need to offer the following: online availability, app-like behavior (appear as a native app on iOS), extensibility, easy host-ability, the use of existing data, adequate security, and an improved user experience.

More generally, the primary requirement for the initial rollout was to be functionally equivalent to a binder of lists, while providing the benefits inherent in being online. Designing around the need to work well with a touch interface was targeted with the goal of having iPads in kiosk mode at the circulation desk for patron use, providing a complete replacement for the existing solution.

Design and Implementation

The design and implementation stage involved an evaluation of software languages, existing code libraries, target deployment platforms, and a determination of how best to use existing data and systems. Abrief examination of popular applications provided a basic interface to target that would be reasonably familiar and consistent with user expectations. Prototyping involved building out user interfaces with limited functionality as proof-of-concept, further informing the design.

As there are many options for creating web applications, the following choices were made toward satisfying the previously mentioned goals: the Python language was chosen for its ease of development, wide availability of software libraries, web application frameworks, and portability to host on many different server platforms; the PostgreSQL database was chosen as the data back end for its ease of use and wide availability of community supported documentation; the Flask web framework was chosen based on its ease of setup, URL handling capabilities, and templating features that allow for fast interface design and integration; and the Bootstrap framework was chosen for its capabilities in building responsive and mobile-friendly user interfaces. Tight iOS integration was implemented with HTML along with various CSS and JavaScript tweaks to polish the front end.

A design decision that exemplifies keeping it small and simple was how to handle the input and maintenance of the reserves information by staffers. While it would have been reasonable to create a staff-member portal to enter new or updated items into the application's database, it would have greatly increased the complexity of the project. Direct input would have necessitated authentication, created potential multitenancy issues, and made available a public interface with the ability to modify what is visible to users. All of these items increase the attack surface of the application, making it potentially vulnerable, and would increase the resources needed for longterm maintenance. The solution was to use our institutional Google Sheets access to store and modify the holdings information. When it comes to updating listings, this solution uses Google to authenticate authorized staff users and handles the storage of the spreadsheet. It is accessible from any computer and can be collaboratively edited.

The app makes use of an existing open source library to access the Google spreadsheet in read-only mode and import it to the application database. After making changes to the Google spreadsheet, staff members simply visit a URL that triggers the update of listings.

Validation and Testing

The validation and testing process was largely interleaved with design and implementation. Each feature was tested after implementation and evaluated against the identified needs. Once the first milestone was reached, the full application was tested with our production data and used by various staffers on different devices and platforms before being released for public use. At this point, the circulation desk's iPad kiosk was set up for use as our main point of access by patrons.

Evolution

The evolution stage includes the ongoing maintenance of the application and the creation of additional functionality in future iterations. In our case, there are plans for additional features based on feedback from patrons and staff members that will enhance usability and overall utility.

Long-term considerations for system maintenance include the need for in-house skills to keep the application functional. Changes in the various interacting platforms (web browser, server platform, and connected services) must be monitored and evaluated over time for their effect on the application.

Status Report

After realizing the need to improve our original system, our evaluation of potential solutions began. The project design started in September and was quickly followed with iterations of the working system, each implementing additional features and functionality.

The December 2015 iteration of the project provides all of the functionality of the original binders along with the additional benefits of being globally accessible and app-like in operation. The reserves app, displayed on an iPad, is now used at the circulation desk for students to browse and request items from staff members. Both students and staffers have had a positive response.

The ability for the app to grow and evolve with new features iteratively, without the need to appeal to external people or commit to additional purchases, is an added benefit already being realized, with new features being prototyped for inclusion in future versions.

Going the third way allowed for a rapid development and rollout, exploiting existing resources, and provided the ability to prototype and modify the design along the way. By making use of different off-the-shelf products, such as Google Sheets and iPads for display, the project did not require a high level of expertise, time, or cost to implement.

Benefits and Conclusions

In our experience with going the third way, patrons benefit from having a more accessible reserves listing, patrons and staffers benefit from an improved user experience with the iPad kiosk, and librarians benefit from a more flexible and distributed process for updating holdings.

While perhaps small or trivial in size and complexity, the example represents the type of problems that are common within libraries. As we evolve in our practices and offered services, there are incremental changes that can be made with low effort and low cost, which have a large impact on user interaction and perhaps patron perception of the library.

Avoiding high costs and long buildout times, going the third way of small in-house development provides a way to stay modern and agile, while exploiting larger systems such as Google Docs and iPad displays to do the heavy lifting. A small amount of in-house development allows larger services to be glued together into a better user experience without the high cost, long build times, or the close-but-not-perfect outcomes of other options.

Beyond the direct benefit to patrons and staffers over our original solution, going the third way provides librarians with some amount of autonomy and can serve as a jumping-off point for larger projects. While many of our needs are beyond the abilities of non-developer librarians and may be best handled by full-time developers, there is no one who knows our users better than we do. Entertaining the possibility of going the third way to directly develop tailor-made services may be the best option.

THINKING THE THIRD WAY

While small in scale, the problem described in this case study belongs in a category that includes many of the problems librarians are faced with. As we continuously seek to extend services and improve user experience in the face of rapid consumer technology advancement and frozen or shrinking budgets, there is an opportunity for librarians to create small applications to act as glue between our chief operational offerings.

Targeting a limited problem, such as the listing of reserves items, represents the type of task common in many libraries, in which larger solutions--whether out-of-the-box or custom-made--involve a lengthy process, require funding, or do not satisfy needs closely enough.

The third way is an alternative path for librarians to dig into coding and create in-house solutions tailored to our needs. While software development within libraries has a long and rich history, small-scale projects that target a very specific need, rather than replacing large and complex existing infrastructure, represents a low barrier of entry into the world of development.

For the purpose of our discussion, the third way presents itself whereby the problem to be solved is small in scope Idoes not require the type of planning, funding, or expertise involved with large projects), is not easily addressed by existing options (due to time frame, cost, or specialized need), and would benefit from the ability to evolve and improve over time.

It can also initiate those unfamiliar with software engineering practices toward approaching a problem with development as a potential solution. Borrowing from software engineering practices, a custom development project may include the following steps: specification of requirements, design and implementation, validation and testing, and ongoing evolution and upkeep.

RESOURCES

Sommerville, I. (2010). Software

Engineering, Ninth Edition. Boston: Pearson.

Learn Python the Hard Way

learnpythonthehardway.org

PostgreSQL Database

postgresql.org

Flask Web Application Framework

flask.pocoo.org

Bootstrap--Responsive HTML, CSS, and JavaScript Framework getbootstrap.com

Apple's iOS Guide for Configuring Web Applications developer.apple.conyiibrary/ioVdocumentation/ AppleApplications/Reference/SafariWeb Content/ConfiguringWebApplications/ ConfiguringWebApplications.htm!

Google Spreadsheets Python API github.com/burnash/gspread

David Cirelta is an instruction and user service librarian at the Manhattan campus of the New York Institute of Technology (NYIT), a private university in New York. Cirella's professional interests include user instruction, web services, and programming. He is currently pursuing a graduate degree in computer science. Cirella can be reached at decirella@gmail.com.

Technology Stack

Web Front-End Interface       Bootstrap, HTML, CSS, JavaScript
Web App Framework             Flask
Data Processing and Storage   Python, Postgres, Google Sheets
Web Server                    Apache Web Server mod_wsgi
Server, Operating System      Third-party web host, Linux

Choices affected the web app
COPYRIGHT 2016 Information Today, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2016 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Cirella, David
Publication:Computers in Libraries
Geographic Code:1USA
Date:Mar 1, 2016
Words:2098
Previous Article:'Rescuing' websites from themselves: another library skill?
Next Article:DIY FAQs: bringing your web content home.
Topics:

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters