The Code4Lib Journal – Patron-Driven Expedited Cataloging Enhancement to WebPAC Pro Mission Editorial Committee Process and Structure Code4Lib Issue 18, 2012-10-03 Patron-Driven Expedited Cataloging Enhancement to WebPAC Pro This article outlines the development of an integrated patron-driven expedited cataloging feature in the catalog of the Connecticut State University Library System (CONSULS). The proposed enhancement to the library’s Innovative Millennium ILS provides users with a direct method for obtaining newly-arrived library materials and allows the Cataloging & Metadata Services Departments at the four Connecticut State University campuses a way to better identify priority materials in their queues. While the project was developed with a single ILS in mind, the idea behind it can easily be implemented on most any other integrated library system. Two versions of the enhancement are covered: one for standalone libraries and one for libraries that share a union catalog. The source-codes for both versions of the enhancement are provided, as are instructions for implementing the enhancement on any Millennium installation. By Steven Jay Bernstein Backlogs, Frontlogs, and Patron Driven Expedited Cataloging In the world of catalog librarianship, backlogs are an unfortunate fact of life. As Solomon so eloquently stated three thousand years ago, “of making many books there is no end” (Eccles. 12:12; JPS). And of those with the Solomonic wisdom to catalog and classify those hoards of books there is practically no beginning. In libraries across the world a not-so-insignificant fraction of recently and formerly acquired materials lies dormant, waiting for their overburdened stewards to provide the description and access that will connect them with their readers. Allowing for those connections to be made means reducing the backlog, a task for which there are many approaches. One popular approach is the transformation of the backlog into a “frontlog”, or a backlog in which quick-and-dirty minimal-level bibliographic records have been created for the as yet to be fully cataloged materials (Nof 2011). Records for frontlog materials often consist solely of descriptive data relating to the book’s author, title, imprint, edition, and International Standard Book Number as well as a sequential accession number and/or barcode for inventory purposes. More often than not, these brief records—colloquially referred to as “Baby Bibs”—are created at the time of purchase or receipt by acquisitions staff and require no further effort on the part of the cataloging department until they are retrieved from the frontlog for full-level cataloging. Although Baby Bibs often lack—among other things—subject analysis and authorized access points, they are still accessible through keyword searching provided that a) the book’s title adequately describes the book’s subject matter; or b) the user has foreknowledge of the author, title, or ISBN she is seeking. This is perhaps the greatest benefit of the frontlog model: the ability of the library user to find uncataloged materials in the catalog and the ability of the cataloging department to then rush-catalog those materials upon request. Jumping on the bandwagon of the recent buzz surrounding PDA (Patron Driven Acquisitions), we call this benefit Patron Driven Expedited Cataloging. The benefit of PDEC has one missing link, however: the disconnect for the user between finding the item in the catalog and being able to access the item itself in the real world. Whereas records for fully cataloged items contain classification numbers for locating the item in the stacks, records for frontlog items often contain nothing more than a note indicating that the item is in processing. There is no signpost for the user telling her how to retrieve such an item. And let’s face it, she’s not going to ask; she’s just going to give up. In the off chance that she does not give up she may discover a feature in the catalog for requesting a hold or a recall on the item in question. This function would fall short of providing her with prompt access to the item, however, since the request feature would not generate an alert to library staff when her request was placed. Such items would only be identifiable through happenstance upon retrieval from the frontlog by a cataloger. Without an alert, the user’s request might not be acted upon until long after she no longer needed the item. In an effort to bypass this dead end, Central Connecticut State University developed a Rush Cataloging Request Form that would notify the cataloging staff when a user needed an item from the frontlog. The form was placed on the Cataloging Department page of the library website. However, since no direction was provided to the library user as to how to get to the form from within the catalog it was seldom used. This project began as a response to that problem. Background of the Library Environment at CCSU Central Connecticut State University is a regional, comprehensive public university dedicated to learning in the liberal arts and sciences and to education for the professions.  It is one of four universities in the Connecticut State University System.  CCSU’s Elihu Burritt Library shares a union catalog with the libraries at its three sister schools (Eastern, Southern, and Western) as well as the Connecticut State Library.  The CONnecticut State University Library System, (CONSULS) uses the Millennium ILS by Innovative Interfaces Incorporated, release 2009B 1.2. Project Development Stage One: Appending a Link In its early stages, the aim of the project was merely to append to CCSU’s in-processing notes a link to the rush cataloging request form so that the notes would read: 1 copy being processed for CCSU. Click Here to Expedite Processing To accomplish this we first needed to assign a unique identifier to the element in the HTML of the record display that contained the in-processing notes.  The element happened to be a table element with a class attribute having the value of “bibOrder”.  We modified the element by going into the Web Options tab of the Administration module of Millennium and altering the “Record Displays > TABLEPARAM_BIB_ORDER” parameter so that it would include the following: ID=”bibOrder” Assigning a unique identifier to this element allowed us to access and modify its contents using the following JavaScript which we included in the “toplogo.html” file: Like the cataloging done for frontlog materials, this solution was quick-and-dirty. While it got the job done, it was inelegant. The style of the page on which the rush cataloging form appeared did not match the style of the catalog itself. More importantly, linking to the form on a separate page required the user to remember the details about the item she was requesting. Having to navigate back and forth between the record and the form was an exercise in user unfriendliness. These perceived shortcomings gave rise to the second stage of the project in which the form was integrated into the catalog itself as a popup. Stage Two: Integrating the Form into the Catalog In order to integrate the form into the catalog as a popup, the requisite HTML for the form was added to the toplogo.html file.  This HTML was placed inside an absolutely positioned DIV element whose display was set to ‘none’ and modified so that the style of the form would fit with the style of the OPAC.  As we were making these changes, we also replaced the underlying script that controlled the e-mail submission of the form with the freely available Huggins’ Email Form Script by James S. Huggins.  This PHP script file, which—due to the Millennium server’s inability to process PHP—was placed on CCSU’s webserver, provided a much more robust set of options for securing and customizing the form than the original script.  This customizability came in quite handy in the final stage of the project when the enhancement was modified for use by all four Connecticut State University libraries. One of the features of Huggins’ E-mail Form Script was the ability to specify a landing page for the user to serve as a confirmation that the form has been successfully submitted. We created such a page as follows and placed the HTML file for the page in the screens directory of the WebPAC server: Figure 1. The Landing Page. We next had to add a function to the JavaScript that would toggle the display property of the DIV element in which the form was contained. function showhide(divid, state){ // Function to show or hide the form. document.getElementById(divid).style.display=state } Finally, the rushCcsu() function was modified so that the link that was to be appended to the in-processing notes would call the showhide() function for displaying the form rather than linking to the original form.