Vol. 20, No. 4 • April 2000

Introducing the Home Team
The Rochester Public Library (RPL) is the largest public library in an 11-county consortium in southeastern Minnesota, and it serves a dynamic community of 112,000. The consortium runs a Data Research Associates (DRA) Classic system for public, school, and special libraries in the region. The network at RPL for all the public PCs runs in a Windows NT environment. Two full-time computer center staff members (Jean Jahn and Steve Mosing) and one part-time staff person run all computer-related operations.

Not only is there a large demand for Internet services from our regular patrons, but the library is two blocks from the Mayo Clinic. A constant stream of visitors uses the Internet primarily to check e-mail. All users are limited to 1 hour of Internet access per day.
 

Starting Out in Little League
To control public access to the Internet, our first plan was putting a manual sign-in sheet at the Information Services desk and asking patrons to sign up before using the Internet PCs.

Advantages—Very inexpensive solution.

Disadvantages—Very staff intensive. We were not ready for the lengths that people would go to get on the Internet and stay on as long as possible. Staff members needed to handle the sign-up sheet or patrons would cross off other patrons’ names. Staff members had to become involved often to keep patrons to their allotted hour. There were no electronic limitations on the PCs. Patrons could get on the Internet without signing up.

So in this first time at bat, we struck out.
 

Managing to Move Up to Minor League Status
Our first attempt to automate the process called for staff members to assign stations and passwords at the Information Services desk. We ran the WinU software by Bardon Data Systems. Both the Internet stations and an administrative PC at the Information Services desk had the software loaded. The patron would come to the desk, request the Internet, and a staff person would assign a password good for 1 hour. The patron would walk to the Internet PC, enter the password, and the WinU software would knock him off after an hour. The password was only good for that one-time use.

Advantages—The software kept the patron to the hour limit. The sign-up was orderly.

Disadvantages—Very staff intensive. Staff members needed to be involved in every login. There was no built-in history file, so patrons could easily get on more than once per day. Also, enquiring patrons assumed that the clerical person assigning passwords from behind the desk was a reference librarian.

This was strike two.
 

Breaking into the Majors
DRA has a program that we could pass information through to validate patrons. Steve Mosing learned JavaScript so we could pass information from the opening script to the computer that held the patron data. A consortium staff member downloaded the Cern server software to the same computer that housed the patron database. (The Cern server software is an http server that allowed our script to talk to the patron data.) We used WinU running on the Internet PCs to kick patrons off after an hour. (I had a great deal of help with the script on the server side from Tim Kambitsch from the Dayton and Montgomery County Public Library.)

I added a log file to the system so that a patron could get on only once per day. The program checked the date of the log file. If the date was not today’s date, a new log file was created. The program also checked to make sure the patron’s card number was not already in the history file. If the number was already in the file, the patron could not log in again. As patrons logged in successfully, their bar codes were written to the log file. This log file not only prevented patrons from logging in more than once per day, but it also provided statistics.

“We were not ready for the lengths that people would go to get on the Internet and stay on as long as possible.”

In this scenario, a patron would walk up to any available Internet station. He entered his library card number and his PIN number. The JavaScript passed commands to the DRA program to validate the patron information. The patron had to be a person in good standing to use the Internet (no previous IDs, no expired cards, no excessive fines).

Advantages—The system worked directly with our patron database; it was always working with the most up-to-date information on the patron. We liked the PIN number addition because it was more secure. Many patrons paid their fines. The system was primarily self serve.

Disadvantages—If a patron got hung up on the Internet computer, he could not reboot it and log back in because his card number was in the history file. So we had to keep a set of cards at the desk to be used to log people back in.

When the people in the consortium office upgraded to a different computer, they chose not to load the Cern server software on it, so we could no longer verify patron information. We were back to square one. This was the big strike three—we were out.
 

We Were in a Slump
Since we no longer had access to the patron database, I wrote a script to validate the bar codes. Then, the patron entered the bar code from his library card, and the program ran the math calculations to verify the bar code length and check digits. The system still used WinU to kick the patron off after an hour, and a history file was maintained so that a bar code could only be used once per day. This seemed like a serious step backward for us, and though we ran the system this way for over a year, it always felt like a stopgap measure.

Advantages—Better than the paper sign-up.

Disadvantages—One of the software programs had a problem where it would hang up the PC periodically, so we spent a great deal of time logging people back onto the Internet. (Since the patron ID was already in the history file, a different ID was required.) The verification was not against an active patron file, so people who brought friends’ cards or previous cards could park themselves at a PC for multiple-hour sessions. Staff had to monitor that manually. Also, since we only checked our style patron bar codes (13 digit), patrons from other library systems who had valid bar codes of different lengths had to stop at the desk every time they visited.

So, in our second time at bat, we weren’t starting out very well.
 

More Ideas on Deck
We had problems with the waiting systems of all the solutions described above. We tried to keep lists at the desk, but the task was overwhelming. Paging patrons for the Internet was annoying the users and was time consuming for us. So Information Services staff members developed a waiting card system instead. If all the PCs were full, a patron would come to the desk and a staff member would issue a small pre-printed piece of paper that had the date and a number on it. When a PC opened up, people with waiting cards would go to the PC. The patron who had the lowest-numbered card would have priority. A date was printed on the waiting cards because patrons would bring low-numbered cards back on subsequent days trying to get quicker access to the Internet.

Strike two—again.
 

Scouting for a Ringer
We were still muddling through when planning started for the biggest change to our library since automation in 1983—the Web catalog. People from all departments participated on teams: Functionality Team, Training Team, PR/Marketing Team, and the Steering Team. The Functionality Team assigned the Computer Center staff the task of finding a way to provide a coin-op system for networked printing in our NT environment. Previously, we’d used an honor system for Internet printing, with very limited success. The printer was at the Information Services desk, so patrons would have to print and then go to the desk to pay for their printouts. Many pages were printed and never picked up. Some sneaky patrons would wait for the reference librarians to be away from the desk, then they would reach around and take their printouts without paying for them.

To remedy these problems, the Computer Center staff members selected the UnipriNT software system from Pharos Systems. During the installation process I picked up the documentation and started reading about another product Pharos had called ReserveIT. I was intrigued. It had features we really wanted:

• It allowed for self-service for the patrons, even the waiting list.
• We could still set the time limit to 1 hour per patron.
• The software allowed the patron to reboot and still get back in with no staff intervention.
• The patron could use the hour at different times of the day (e.g., 15 minutes in the morning and 45 in the evening)
• Patrons could not get on the PCs without going through the reservation process first.
• The system used passwords/PINs that made it more secure.

There’s another PC called the Queue Station that’s dedicated to giving information about the current status of the Internet stations (e.g., when a PC will open up, how many people are on the waiting list, etc.).
 

Training for the Big Game
I loaded the software in a test environment. What was obvious from the start was that the biggest challenge would be getting the patron database to the Pharos system and keeping it up-to-date. I talked at great length to Jahn and Mosing, and we seriously debated whether the work needed to bring the system up would be worth the benefits. In the end, we decided to proceed.

Pharos software has a standard user load program using a comma-delimited input file. Jahn began working with staff at the consortium office to use report-writing software to create the initial patron load files as well as the daily patron updates.

DRA has a log file that contains all adds, changes, and deletes, including patron updates. So we ended up with three daily update programs. The first one adds new borrowers and modifies patrons in Pharos who had updated their information on the DRA system the previous day. The second deletes IDs on the Pharos system that have become old IDs on the DRA system. The third deletes patrons in Pharos who have been deleted from the DRA patron database.

Once it became clear that the patron database could be maintained on the Pharos system with almost no staff intervention, we started planning in earnest. Jahn, Mosing, and I talked about loading all the borrowers from the regional automated system, since many people from the region work in Rochester and use the library, but eventually we decided to load only the patrons registered at RPL. Patrons from other libraries could be added as needed.

Early in the planning I demonstrated the test system to all Information Services staff members and key staff members who handle circulation to get feedback and buy-in. We mapped out several measures to give patrons good service while not causing extra headaches for our employees.

Since the patron data updates run the day after changes are made on the DRA system, we still needed to create procedures for new registrants who wanted to use the Internet the same day. Jahn and I met with staff members from both the Children’s area and the Adult area to discuss changes. The registration form was modified to ask “Do you plan to use the library Internet today?” Procedures were planned and documented.

Because we have so many one-time-use visitors, we do not automatically register all visitors on the DRA system or on Pharos. We have a 1-day-use Internet card that is available from either the registration desk or the Information Services desk for $2. We’ve entered a number of special cards into the Pharos system, so we won’t have to fully register every visitor who comes in only to check e-mail.

For those visitors who plan a longer stay or for those who live in Iowa or Wisconsin and drive to Rochester to work, we have a 30-day nonresident card that we sell for $5; it includes both checkout and Internet privileges. These cards are registered on our DRA system as well as in the Pharos system.

Because the Internet PCs are on a different floor from registration, we also focused on making sure patrons would not be sent up and down the stairs to get service. For example, now Information Services staff will take change-of-address and phone information themselves, rather than sending the patron back to registration.

Another issue that came up was that we did not like the standard Queue Station software. We felt the patron needed more information. The Pharos data is stored in a standard SQL database, so with help from Pharos’ technical support, I wrote a script to display the information we wanted: listing people on the waiting list, listing any PC in use and the sessions’ ending times, and listing which PCs were waiting for someone to log in. The Queue Station PC runs Netscape with the script set as the home page, and the script updates the display every few seconds.

We were concerned about handicapped accessibility as well. Furniture was ADA compliant in only two of the 12 stations. We set up the software to give the patron a choice: He may specify either the first available Internet PC or a handicapped-accessible PC only. (ZoomText software from Ai Squared is also available on the handicapped-access PCs; it magnifies the screen for visually impaired people.)

The demand was so high for Internet stations that we added more PCs during this process. That involved Jahn in some time-consuming physical planning. We also dealt with other logistical issues. Previously, the Internet stations had been positioned just where you’d enter the Information Services area. The data cabling and power were there for expansion of our online catalog, so the Internet PCs started there by default. But the traffic and noise were overwhelming. Patrons congregated around the Internet PCs and hovered, impatient for the next one to open.

Members of the Steering Team for the Web catalog decided that they preferred the Web catalog, not the Internet stations, to be the first thing that people see when they enter Information Services. So Jahn was directed to move the Internet PCs to the back corner of Information Services between two service points. Contractors added data connections and power. Information Services staff members felt the partitions on the existing furniture were too high to allow good visibility to monitor the Internet area, so a woodworker cut down the furniture. He even took an existing index table and modified it for Internet use. (We looked at new furniture, but it was less expensive to modify the existing furniture. And besides, we didn’t have anywhere to store the furniture if we did not use it.)

An Information Services staff member was designated to look over customizable messages in the software and to modify signage at the Internet PCs. Finally, Mosing and I installed the software and loaded the data on the live server. Hands-on staff training on the program and procedures happened over a week to accommodate the many different staff members’ schedules.
 

Finally Hitting a Home Run
The system went up on October 18, 1999. Initially, our staff spent a great deal of time with patrons directing them to the Reservation Station and explaining the new procedures. (A big sign has since been added by the Reservation Station.) Our repeat Internet users were self-service immediately. Because of the number of visitors to the library, staff will always need to spend some time with the patrons getting them started. But overall, this system is working better than any of our previous ones. At last—a home run!
 

The Final Box Score
Because of the patron data issues, this is not an out-of-the box solution, but it is one that has solved numerous problems for us. At some point we hope the library automation system and the Pharos system will “talk” directly to each other.

Implementing this solution has freed our staff members to spend more time helping patrons find information. Our interactions with the patrons who want Internet access are much more positive than in the past. Now we are getting patrons on the Internet, not mediating people waiting in line.
 
 

Audrey Betcher is currently the interim director at the Rochester Public Library in Rochester, Minnesota. Previously, she managed a DRA automation system at the regional consortium in Rochester. She has an M.L.S. from the University of Missouri–Columbia. Her e-mail address is audrey@rochester.lib.mn.us.
 

To Contact the Companies
Ai Squared (ZoomText magnification software) P.O. Box 669 Manchester Center, VT 05255-0669 802/362-3612 http://www.aisquared.com Bardon Data Systems  (WinU timing software) 1164 Solano Ave., #415  Albany, CA 94706  510/526-8470 Fax: 510/526-1271 http://www.bardon.com CERN (Cern server software) CH -1211 Geneva 23 Switzerland http://www.cern.ch	Data Research Associates, Inc. (DRA Classic system) 1276 N. Warson Rd. St. Louis, MO 63132-1806  314/432-1100  800/325-0888  Fax: 314/993-8927 http://www.dra.com   Pharos Systems USA, Inc. (ReserveIT and UnipriNT software) 1110 Nasa Rd. One, Suite 603 Houston, TX 77058 888/864-7768 Fax: 281/333-3049 http://www.pharos.com