NaviStax - A Visual Guide to the Stacks

NaviStax – A Visual Guide to the Stacks

Navigating the stacks has always been intimidating for many library patrons. The labyrinthine structure with different locations, call number ranges, material types, etc. can cause many people to give up before the item they’re looking for is found. I was always one of those self-guided searchers. Many people would rather learn how to find something on their own than ask for help. So how can we offer these patrons help without interfering with their preferred methods of search and discovery?

Many libraries have integrated a “find on a map” feature into their OPACs, allowing patrons to click on an item and then see its location on a map. Usually this consists of an arrow pointing to a group of shelves, but this is often enough to get them heading in the right direction. Years ago I saw this implemented at UT Dallas and developed some similar maps for Illinois State University. I wasn’t able to get them integrated into the catalog, but patrons still seemed to like having these images available on the mobile website, so I looked at other ways to improve the delivery of these maps, similar to the way other libraries had done it.

At Pratt Institute Libraries, I was able to write a couple of simple scripts and allow them to be called from the catalog. We were only able to add static HTML to our basic Millenium configuration, so we just inserted an empty form that calls the first PHP script when a button is clicked. The feature is live in cat.pratt.edu. When viewing any record, just click on the button on the right that says “Find on the Shelf.” This calls a script that scrapes the HTML of the referring page, parses out the call number and location based on attributes in the HTML that surround this information, then displays an image pointing to the shelf or text explaining how to access the item.

A few drawbacks of this current version: because we’re just dealing with HTML, the “Find on the Shelf” button is displayed for every record, whether the item is physical or digital. For digital items, we just display text explaining how to access the digital item. Not ideal. Also, since we can only add static HTML to the template, the button does not correspond to a specific copy and is not displayed next to the item. As a result, all copies of an item are sent to the map function. This is fine for items with one or two copies, but a periodical will bring up a map for every volume that’s cataloged separately. Also not ideal. I’m trying to find a work-around for this. Despite these quirks and the occasional call number that can’t be parsed correctly, the response from patrons has been very positive.

I began looking at ways to implement this feature in different environments and developed some demos for a larger academic library. This library uses the VuFind catalog of their consortium, so we weren’t able to insert anything other than static HTML into the catalog template. This still seemed like it would be fairly straightforward, but their OPAC doesn’t display holdings information in the HTML. For example, pull up any record in CARLI’s VuFind. The holdings information is displayed by a script, so you wont’ find it in the source.  When a record is displayed, it has an id number that is sent to a function in VuFind that returns the holdings information as an AJAX response. No problem. I just tweaked the scripts to pull the id number out of the URL instead of scraping the referring page, then format the request and send it to the service. When the response was received, it was parsed and this sent the request, along with the call number and location, to the PHP mapping function that displays the image. This was presented as a demo, but getting the consortium to add even static HTML to the template wasn’t happening. What now?

I had made simple widgets for chat services to insert into EBSCO’s EDS discovery layer, so I knew scripts were allowed. Cool. I made a simple Javascript/JQuery program that can be embedded in the record display template for the EDS just like any other widget. When the page loads JQuery parses the code and gets the item’s id number. It sends an AJAX request to a PHP script that takes the id number and sends the request to the VuFind function. When the function replies, it parses out the call number, location, availability, and copy number and creates a JSON object that is returned to the calling Javascript. The Javascript takes the object apart and displays the info along with a link next to each item to find the item on a map. When a user clicks on the link, the location and call number are sent to a different PHP script that displays the image based on this information.

So we’ve seen a few ways to implement this feature, but the real issue to resolve is why have so many libraries adopted it and then abandoned it? The answer most of them give is that it takes too much time and effort to keep them updated. Updating code and images can be a repetitive, time-consuming task. This is why computers exist! They’re great at repetitive, time-consuming tasks. So I thought there must be a way to write code that writes code. OK, this has been done before, but not (that I’m aware of) applied in this situation. So NaviStax was born.

NaviStax is a set of tools designed to make creating and updating this feature feasible for librarians without much coding or image editing experience. It’s currently in a very early stage, but the main parts are there: a script that creates the scripts needed for the program and example files that can be customized for each library. The basic implementation involves:

1. Create images of the areas to be mapped. Existing floor plans can be used. Define the areas to be mapped. Will they be groups of shelves, individual shelves, or will the feature just display the same image for everything in a particular location?

2. Enter the names of libraries, locations, call number ranges, and their associated image files into a spreadsheet.

3. Run the program generator. This will pull the needed info from the spreadsheet and output the needed PHP files.

4. Test the program with various call numbers. If all is working, upload everything to the server. If not, a programmer may need to debug the code or librarians may need to verify call numbers and locations.

5. With the working program on a server, add code that will display the link into the OPAC or discovery layer interface.

Updating usually consists of:

1. Update the background image by inserting the correct text into the file.

2. Insert the updated background image into all files via an automated process.

3. Update the call number ranges in the spreadsheet.

4. Run the generator program.

5. Check the new program for accuracy and upload files.

This workflow is far from perfect and there are many kinks that will need to be ironed out during development and testing. As the tools become more robust (and, hopefully, simpler) more libraries will be able to integrate this feature into their OPACs or discovery layers.