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.
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
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.1) 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
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 codered
(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.2
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
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
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.
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
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 formDreamweaver,
Graphics, and FrontPagesince 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.
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):2932.
Cullen, Kevin. "PHP: An Open Source Solution for Web Programming
Dynamic Content." Information Technology and Libraries
21 (September 2002).