When Michelle Mach arrived in 1998 as the first Web librarian at Colorado State University (CSU) Libraries, the process of getting something put on the Web meant calling, e-mailing, or more likely, dropping by her office or that of the one graduate student who worked part time on the site. While several people suggested or created content for the library Web site, only two created most of the HTML. By late 2000, the number of pages on the site had tripled from 750 in 1998 to 2,500, but the number of people who maintained the site had not kept pace. With the addition of another staff person and an undergraduate student, who together worked a total of 20 hours per week, the site was being maintained by the equivalent of two full-time people.

The CSU Libraries serve 23,000 undergraduate and graduate students and 4,500 faculty and staff, all of whom have high expectations of finding information on the library Web site. Our library staff is continuously adding more content, creating new pages, and digitizing handouts and other printed materials.

Recognizing Early Symptoms of the 'Webmaster Blues'

By early 2001, many library staff members were learning to create Web pages and often needed help. In addition, Web server access was restricted, meaning that Michelle or another Web staff person had to review and upload all pages. The huge number of requests, combined with the random ways in which they were being made and processed, was taking its toll. Luckily, we discovered that Michelle's Webmaster Blues, a common ailment suffered by many librarian Webmasters, was not only curable, but it had a quick recovery time once it was correctly diagnosed and treated. To manage requests, we (Michelle Mach and Kevin Cullen) implemented an automated task management system to go from an ad-hoc "everything's an emergency" chaos to an orderly first-come, first-served process. Along the way, we discovered some unexpected benefits to this new system.

So how did we distribute the Web responsibilities and cure Michelle's Webmaster Blues? Like many organizations, CSU Libraries went through a trial-and-error process in figuring out how to handle the growing number of Web-related requests from its staff. In order to mainstream the Web maintenance activities, the libraries formed a Web Implementation Team (WIT) in November 2000 composed of two faculty members, two students, and two paraprofessionals. Michelle, as Web librarian, chaired the group. WIT members trained library staff to create and edit Web pages using FrontPage or Dreamweaver. By 2002, nearly 40 of the more than 100 faculty and staff members employed at the libraries maintained two or more of the approximately 5,500 total library Web pages. (This number includes 1,500 automatically generated pages such as Web statistics, link checking reports, and automated indexes.¹) The problem with this new system was not the starting point (creating a Web page) or ending point (loading it onto the Web server), but rather creating a bridge between the two.

Patient Medical History

When mainstreaming activities began in early 2001, the WITs started encouraging staff members to e-mail them when they needed Web pages uploaded. A few library staff members, used to just dropping by or slipping handwritten notes under Michelle's door, found this change difficult. Michelle would either complete these informal requests herself or e-mail the WITs for assistance. While this was a little frustrating, it was the e-mail messages, our preferred system, which caused even bigger problems. E-mails that simply read "Please update my page" were not unusual and caused team members to wonder if ESP was a job requirement. Each vague request meant that team members had to contact the person for more information: Which page? Where is it? Is this an updated page or a new one? It quickly became apparent that the Webmaster Blues was highly contagious and had infected the entire team.

As their first step in seeking a cure, the WITs created an online form that asked for basic information: name, department, e-mail, filename of new page or URL of existing page, and notes/instructions about the page. By moving from an e-mail address to a simple Web form, WITs addressed the problem of missing information. However, other problems arose. With no tracking system, WIT members were tempted to prioritize "fun" requests like creating graphics and designing new sites over the more mundane updates. Not having a tracking system also made it difficult to know whether a request had been completed. WIT members sent each other a steady stream of "Is anybody working on this yet?" e-mails.

The Diagnosis and Cure

In April 2001, Michelle approached Kevin with the idea of creating a task management system to handle requests for work on the libraries' Web site. Kevin is digital projects librarian, with Web programming, computer-based training, interface modification, and reference duties. We agreed that a task management system might cure Michelle's "blues." By storing Web requests in a database, WIT members would be able to look in one place for information about each task, including the person handling the task, its current status, and notes about in-progress work. Unlike passing around e-mail, a database would create one record for each task and allow several people to view and update the same information during its lifetime.

That same month we had worked on a similar project using PHP and MySQL in a PHP programming course. Michelle also knew from talking with the Library Technology Services (LTS) department staff members that they were happy with their program for tracking computer maintenance requests from library staff. Because the technology was new to us, we decided to use the existing LTS source code as a starting point. The LTS system tracked information we did not need, such as operating system and location, but included relevant fields such as name, e-mail, department, phone number, problem type, and description. Kevin reviewed the source code with the LTS staffer who wrote it, and then we both wrote the requirements for our Web Request Management System (WRMS).

To minimize impact on users, we made only minor changes to the old Web request form that library staff used to send messages to the WITs. In addition to the required information about the request and the requestor, we added a drop-down menu for type of request and also automatically generated a report date and time. We decided that as each request entered the WRMS, it would send an e-mail notification to WIT members. The e-mail would contain request information and a hyperlink to a WRMS screen for editing the record.

In the WRMS, each new request would have a resolution code of Open. WIT members would use a form to edit each record and set the Resolver Name, Resolution Code, and an internal notes field. We chose three possible resolution codes: Open, In Progress, and Closed. Once a record was closed, the final field, Resolution Date, would be set automatically.

The WRMS needed to create lists of requests by resolution code, and a list of all requests in the database. List rows were colored by resolution code—red (closed), green (in progress), and white (open). Once a request was closed, it could no longer be edited through the Web interface. Our particular requirements meant editing and adding to much of the existing LTS code, including the reporting functions. The first step, after deciding what information to track, was to design and build the database. Because of the simple nature of the project, we did not choose to normalize the database and create relational tables. Though some text is duplicated, each request has one record in a single table.

We chose MySQL as our database management system (DBMS) because we were somewhat familiar with it and it was already installed on our Web server. (Though our simple database design meant nearly any DBMS would have worked.) We chose PHP as our programming language because it was familiar, practical, and most importantly, used in the LTS task manager. PHP is an HTML-embedded scripting language similar to Active Server Pages or ColdFusion, with a number of advantages. PHP is free, open-source, fast, cross-platform, and compatible with many operating systems and Web servers.²

Once we finished the design, picked the tools, and created the database, Kevin customized and expanded the LTS code to make it suit our purposes. Two or 3 weeks later, he asked Michelle and the WITs for comments. After a few cosmetic changes, we turned on the WRMS on June 20, 2001. Within the first month, 101 requests had been entered into the system.

Adjusting the First Dosage

While the database was a huge improvement over our previous e-mail process, the implementation did not go without problems. Because PHP would not compile on the main AIX-based Web server, we built our task manager on a secondary Linux Web server. (To be fair to PHP, it does work with more operating systems than most, if not all, tools in its class.)

We also had to decide how to handle backups of program code and data. Code backups are simple: Kevin keeps copies on a secure network drive and on the Linux server. We also rely on regular tape backups of the Linux server. Data backups were a bit more problematic. Since this WRMS is for internal use and is not mission-critical, we did not want to maintain daily local backups. After speaking to the WITs, we agreed that weekly tape backups from the MySQL system would suffice in an emergency.

Security was also an issue. Because one script file contains both the request form and the forms for WITs to list and edit requests, securing the back end would have also secured the front end. We did not want to make end-users remember yet another user name and password, so we left the directory open for the first year, hoping nothing would happen. Luckily nothing did, but we finally chose to limit access to library staff IPs.

Ongoing Outpatient Therapy

When dreaming up a piece of customized software, what you picture is not always what you really want. Within 6 weeks, the WITs had recovered sufficiently from their Webmaster Blues to send Kevin their first wish list of changes. They wanted the WRMS to send an automatic e-mail to the requestor each time a job was set to Closed status, rather than having to compose a new message manually each time. Other changes were minor adjustments to wording on the request form and e-mail messages generated by the WRMS.

Eight weeks and 212 requests after the WRMS was turned on, the WITs decided they were sick of getting e-mail notification of each new request, so Kevin turned off this feature. Instead, at the start of their shifts the WIT student workers logged in to the WRMS to check for open requests. Another designated WIT member, usually the Web librarian, checked the system periodically to make sure that the requests were being handled.

The next two sets of changes related to handling new requests. In December 2001, the WITs asked that all new tasks with the request type New Web Page be assigned directly to the Web librarian (Michelle) and have their status set to In Progress. A request to load new pages may signal that a new directory or subdirectory needs to be created or that a new person is creating his or her first Web pages. Kevin made this change and configured the WRMS to e-mail the Web librarian with information about each New Web Page request. By sending these requests straight to the Web librarian, decisions about site structure and page placement could be made immediately, rather than waiting for the WIT member to contact her. It also allowed her to review pages created by new staff and determine whether extra training was required.

In January 2002, Lori Oling took over the duties as Web librarian, freeing Michelle to take on other digital projects at the libraries. In February, Lori asked for a way to take her name off New Web Page requests that did not require her attention. However, the WRMS sets the resolver through a drop-down menu containing names of WITs members, so there was no way to delete the information. Kevin simply added the name "Nobody" to the drop-down. This option sets the resolver to an empty string when the record is updated in the MySQL database, leaving these requests free for anyone to take them.

By March 2002, the WITs were ready for another set of enhancements to the WRMS. All but one were simple and appeared quickly. At prompting from users who wanted records of requests they submitted, Kevin added a routine to send an e-mail to the requestors as each record was input into the MySQL database. The WITs also asked Kevin to remove three of the request types in the submission form—Dreamweaver, Graphics, and FrontPage—since they had almost never been used.

The WITs also wanted to archive old requests, since loading the list of over 900 closed records each time they accessed the system took a long time. Rather than delete older records or move them into a separate table in the database, Kevin changed the administrative screens to display only closed requests less than 90 days old. This sped up page loading and eliminated hassles with keeping data in two places or having to export it to another format.

The Web Implementation Team's final request was a much larger task. With the end of the fiscal year approaching, the team wanted statistics for personnel evaluations and unit reports. The WITs originally just asked for each row of requests to be numbered so they could count records. After a meeting that resembled a reference interview, Kevin and Lori agreed that what the WITs really wanted were formatted reports based on criteria such as date range, requestor's department and/or e-mail address, resolver, and request type. This statistics module had to wait for another project to finish, but Kevin created it during the first week of May 2002.

Kevin designed a search form that lets WITs specify criteria to use and choose values for each. For example, a WIT member can now search for all requests between January and May 2002 that he or she worked on for a specific department. The WRMS creates an SQL search statement from the criteria and displays reports in a table. WITs can click any column heading in the report to sort by that field. Each row is numbered, and the total records found and search criteria are displayed at the top of the report. WITs can view details for any record.

After brainstorming further with Lori, Kevin added a feature that allows users to display the resolution time for each request, as well as the average resolution time for all records found in the search. This allows the WITs to look at their efficiency and workloads.

A Clean Bill of Health

In the first year the system was up, the Web Implementation Team completed 1,500 requests. Clearly, the WRMS supports our team approach to Web site management by allowing library staff members and WITs to communicate efficiently. After an initial adjustment period, staff response to the new system has been generally positive. In particular, staff appreciate the median turnaround time of 2 hours for completed requests. Since the WRMS orders requests by date, it is easy to complete them on a first-come, first-served basis, rather than in random order. When occasional Web "emergencies" do occur, the Web librarian still receives a phone call or an in-person visit, but these are few and far between. Lost or forgotten requests are a thing of the past.

In addition to solving our original problem of managing the daily Web workload, we have discovered unexpected uses for the WRMS. In a time when every library dollar is scrutinized, it is easy to justify the cost of our student workers, as we have clear records of the amazing amount of work they do on our site. We can track common errors that Web authors make and provide written instructions or hands-on classes where appropriate. We can also pull up Web activity statistics for the annual report and other publications like the library staff Web newsletter. Finally, we have a better handle on the larger Web projects. Although Web authors are encouraged to discuss large projects with the Web or digital projects librarians, sometimes we become aware of a project only by the submission of numerous single page requests. This gives us an opportunity early on in the project to discuss options beyond flat HTML pages. Best of all, our severe case of Webmaster Blues has finally been cured.

 

References 1. Mach, Michelle and Kutzik, Jennifer S. "The Web is everyone's business: a distributed system for managing the library Web site." Colorado Libraries 27 (Fall 2001):29­32. 2. Cullen, Kevin. "PHP: An Open Source Solution for Web Programming and Dynamic Content." Information Technology and Libraries 21 (September 2002).