SUBSCRIBE NOW!

Vol. 23 No. 9 — October 2004

The Galter Library's vision is to be "anywhere the user wants it to be." This means that access to the library must extend beyond the building's walls through its Web site, http://www.galter.northwestern.edu. A resident on duty at a hospital cannot leave the building, so at times she can't get to the physical library even though she may be just across the street. Treating patients requires information at the bedside, regardless of the library's hours.

To aid our off-site patrons, we wanted to create a system where a user logged in once and had access to all of the library's electronic resources and online services. Whether we wrote the code ourselves or used commercially available products or open source software, we were shooting for a single interface. We wanted a system that not only authenticated users, but also saved their personal information, allowed for customization, and was easy for the user to update or change.

The system, known in-house as "online services," was developed as different modules. In early 2000, members of the information systems and the interlibrary loan (ILL) departments, along with the head of user services, started designing the user database and the ILL module. Next, we added modules for desktop delivery, billing, proxy server, and, finally, a customizable Web site. These modules are explained in greater detail in the following sections.

Verifying Identification

We developed the user database first because it is the system's backbone. The library staff determined what user information we needed and created a table in Microsoft Access to store it. Users input their personal information through a Web-based form that serves as the front end.

Authenticating and categorizing users presented a number of challenges. First, we needed to identify a data source that we could use for authentication. Since the six hospitals are administratively separate from the university, no single, all-inclusive data source existed. Second, we needed a method of classifying users' affiliations, since this determines which resources and services they can access. Third, we wanted to keep unaffiliated individuals from registering. Finally, library staff wanted to automatically populate the fields of our local records and minimize re-keying of information.

Fortunately, the user tables of our integrated library system, Endeavor's Voyager, proved to be excellent medicine for our concerns. Since each patron receives a unique bar code and a user category, we were able to adapt these for authentication and classification. Library staff can create user records on the fly in Voyager, so we can easily add staff from the hospitals along with others who do not have a university ID card.

For example, when a doctor registers, she enters her last name and bar code into the preregistration page on the library's Web site. A search is run against the Voyager server. If her bar code is not found in Voyager, a Web page would appear instructing her to contact the library for assistance. If the doctor's record is found, fields (including the registrant's category) are copied to our local user database. So when she registers, she can add additional personal information, choose a specialty, set communication preferences, enter a preferred e-mail address, and set a password in the registration form. After clicking the Register button, she instantly has access to all of the library's resources and services. If she wants to make changes in the future, she can update her information simply by logging in and clicking on the "edit personal information" link.

Writing a Script

Early on, the library's information systems department decided to use ColdFusion. We are running ColdFusion MX on a Windows 2000 server. Currently the data is stored in an Access database, but we are in the process of migrating to an SQL server. The database houses all of our user information, electronic resources, user profiles, etc. We query the database using SQL commands and display the information using the ColdFusion scripting language.

Session variables are used to remember information queried from the database that will be needed while the user is logged into the system. If a user navigates to a page that requires a login, the session variable will redirect him to that page once he has signed on. This facilitates a more seamless navigation from the user's perspective. Session variables are also used to time out people who forgot to log out. When patrons log in, they have the option to save this personal information so they do not have to type their username and password every time they visit our Web site. The "save login" feature uses cookies that are stored locally. We have also added a feature that allows users to easily delete their cookies if they wish. We store users' personal Ovid account information in our database if they choose to have a personal account. This means that logged-in users can access Ovid simply by clicking on the Ovid link. Our system remembers their information and automatically authenticates them into Ovid when they start a session. This is one less password for borrowers to remember.

Treating the ILL

We developed the interlibrary loan module first since it was part of our plan to introduce paperless ILL. This module consists of a form for users to submit requests and a staff section for processing ILLs. Since users frequently ask about the status of their ILL requests, we designed the module to provide frequent feedback. For example, when a student submits a request, he will get a confirmation e-mail. A second e-mail lets him know that the item has been received and is available. The e-mails are tailored to the type of item requested. E-mails for books differ from those for journal articles. Users can check the status of their requests at any time by logging in, clicking the "check request status" button, and reviewing the results. They can see when a request was submitted to OCLC. (Users can click on the word "OCLC" to get a description of that processing method.) We wanted a process that was transparent to the user, yet informative.

We also wanted to avoid retyping data as much as possible for both the staff and users. Saving login information in the user table means that when someone completes an ILL request, all she needs to do is enter the citation information. This has proved very popular with frequent ILL users, as has the "quick submit" function. (This is where a borrower enters the PubMed ID number from our primary database, MEDLINE, and all the fields in the request form are populated automatically.)

We chose Prospero as the desktop delivery system for ILL and implemented it in early 2001. In Prospero, a user enters an e-mail address and a four-digit PIN to retrieve ordered items. To avoid introducing additional passwords or PINs, we wrote a script to strip the users' e-mail addresses and online services passwords from our user table and copy them into the Prospero user file. Doing this allowed us to preserve our single login system.

Making House Calls

One way we accomplished remote access was by making sure our services are available through our Web site. We also needed to make sure that our e-resources are available from anywhere too. We did this by purchasing and implementing EZproxy, a program that provides our users with remote access to our Web-based licensed databases. We configured EZproxy to use the authentication process we currently had in place for all of our other online services.

In addition to verifying login information, we have created an application template that checks for the user's IP address. If a borrower accesses our Web site from an unrecognized IP address and the user type, stored in the user table, is one of the types with remote access privileges, we then create a proxy session. If a user type is prohibited, the person will not be able to access our resources. We export information from the user table into EZproxy to make sure valid users can have a single sign on for both services and remote access. We also use information stored in our electronic resources table to create the list of resources we want to proxy. For the most part, this list requires little human effort to function. We use a ColdFusion script created locally to export the necessary information and to format it according to the EZproxy specifications. This script runs nightly as an automated task to ensure that recently added resources will work in EZproxy.

Increasing the Dosage: The Health SmartLibrary

In 2003 we launched a new Web site called Health SmartLibrary (HSL). This site incorporated all of the existing services, as well as new tools for users to customize and personalize their own online library.

To help users manage their information needs, we created four tools:

• My E-Resources: a select list of e-journals, e-books, databases, and
  Web sites
• My File Cabinet: a place to store and organize favorite Web links
• Stay Current: a current journal literature search
• Quick Search: a function that allows the user to enter a search on the home page and search a resource

When a user logs into HSL, My E-Resources, Stay Current, and Quick Search are populated with preselected resources derived from the specialty interest selected when he first registered to use our Web site. Our librarians created the profiles for each specialty by choosing the best locally available electronic resources in each discipline. Currently, we have more than 50 profiles available for our users to choose from, and each specialty profile contains six to 15 resources including databases, journals, reference resources, and e-books. If a student or resident does not like the resources associated with his profile, he can easily customize each tool and create his own personal profile.

HSL was built on the existing system. When users register, we ask them to identify their respective disciplines. The discipline determines an association with a specialty profile. We continued to use ColdFusion to do the majority of the work, but we also make the rounds with other tools such as Perl, Cascading Style Sheets, and JavaScript.

HSL was made possible through information systems grant #5G08LM07051-
02 from the National Library of Medicine. As part of this grant, we have created a Web site to share the code and the database we used to create the HSL tools. You can find it at http://www.hsl.northwestern.edu.

Maintaining the System

Now that we had a system in place, we needed to make sure that only our valid users could access our resources. (We work in an academic setting, after all.) Purging users who are no longer affiliated with the university is not as simple as we would like. We use Voyager to populate the database, so it was only natural to use Voyager to delete departing users. We use a script with two facets. First, it checks Voyager for accounts expired for more than 6 months and flags these accounts in our local database for purging. We then check this database for additional users who have not logged in for more than 6 months and flag these records as well. We send e-mails to the users marked for deletion, notifying them that they will be purged in a month. The e-mail tells them what to do if they feel that they have received this message by mistake. Two weeks prior to the purge, we rerun the script against those flagged users to reassess their status. Users who still have not updated their Voyager records or logged in will receive a final e-mail warning them that they will be purged in 2 weeks. When the time is up, we delete their record. We do this every fall and spring.

Training and Assessment

Library staff at all of the service desks received training on the different modules as each one was introduced. The staff also tested the new modules prior to release.

Since the system was introduced more than 4 years ago, it has become central to the provision of library services. Management needed to ensure that the library staff could use the system, explain it to users, and troubleshoot their problems.¹ So all new staff members are trained on the system during orientation. Two quizzes were developed and administered to ensure that staff members could answer the most common types of questions. New staff members completed the first quiz as part of their 90-day evaluations, and current staff completed the first quiz in a reference team meeting. The second quiz is used after additional training or as a refresher.

The system has become an increasingly important part of our services. We conducted a number of studies to determine if we were able to "keep it simple for the users." Our assessments included usability tests, surveys, focus groups, and a study of all system-related questions asked at the reference desk in a year. We found that 27 percent of our reference questions involved the system in some way. By analyzing the results of these assessments, we were able to diagnose the most common ailments, such as interruption of service on the publishers' end, forgotten passwords, and confusing e-mail messages. We have instituted changes to alleviate this suffering.

Surviving and Thriving

We have many enhancements we want to make to the library's Web site. One request asked for further customization of HSL: Users want to choose what to display and where. They also want the ability to delete particular sections from their personalized HSLs.

One thing we are working on is incorporating third-party information into the HSL interface. We do this with the "In the News" feature, which is created from an RSS feed. We are experimenting with different RSS feeds to see which one we like best. We are also working with Doody Enterprises, Inc. to incorporate its book reviews into our "Stay Current" section.

Keeping it simple for the users was key, as was setting up a single login to everything. We developed a system stitched together from homegrown code (ILL system), commercial products (EZproxy), and open source software (Prospero) that presents users with a single, uniform interface. By making an interface easy for people to use, we achieved our goal—we were able to dissolve the blockages between services, resources, vendors, and providers to create a remote service point that is usable from everywhere the user needs it to be.

Reference

1. Munson, Kurt I. and Walton, Linda J. "Assessing Reference Staff Competency in the Electronic Environment." Medical Reference Services Quarterly, vol. 23, no. 2 (Summer 2004): pp. 33­40.