Virginia Libraries Logo

Virginia Libraries

Current editors:
Beth DeFrancis defrancb@georgetown.edu, Editor
John Connolly jconnolly@nsl.org, Assistant Editor

Winter, 2001
Volume 47, Number 4

DLA Ejournal Home | VALib Home | Table of Contents for this issue | Search VALib and other ejournals

Stop Clinging to Those Static Pages

by Ken Winter

Most library Web pages are easier to create than they are to maintain. That observation used to strike me while updating some of my library's Web based "study guides." Creating and maintaining such guides just comes with the territory for most of us. After all, a current, concise list of resources can do wonders to help patrons when we're not around.

The theory is good, but even for small libraries maintaining such guides can be a real hassle. There are links to add, links to remove, descriptions to update, dead links, and changed URLs. To confuse matters, there are usually multiple subject experts working on various guides. All the while the number of potential information sources keeps growing. What's the best way to handle this kind of maintenance problem?

Static Vs. Dynamic: What's the Difference?

We stumbled upon the concept of dynamic Web pages in the Fall of 1999, when we saw the "MyLibrary" personalization project implemented at Virginia Commonwealth University. Created by librarians Jimmy Ghaphery and Dan Ream, the MyLibrary project helps VCU's patrons create shortcuts to their favorite online resources. We also discovered "The Data Genie," a tool created at California Polytechnic State University, San Luis Obispo.

At VMI we decided to emulate the Data Genie by scrapping our old system of 18 "static" link lists for The SourceFinder, a single "dynamic" search tool that allows students to create custom study guides.

To understand how SourceFinder works it helps to understand the difference between a "static" Web page and one created "dynamically." Static pages are built and posted onto a Web server, where they sit until they are requested by a browser. When that happens, the static page appears on screen exactly as it was originally created (or last modified).

Patrons cannot request "parts" of a Web page in this arrangement. Therefore, we usually avoid overwhelming users with long lists of sources by breaking large pages into several smaller pages. Sometimes we refine our organizational scheme along the way, creating categories and sub-categories. The logic is as follows: As the categories get more specific, lists get more specific, and thus shorter. Therefore the odds increase that patrons will find what they need without having to scroll through excessively longs lists.

In our case that meant instead of creating one study guide called "Humanities" we had one for English, one for History, etc. It is not unheard of for larger college or university libraries to create and maintain more than 100 such guides using this model! Unfortunately, more pages means more maintenance, especially when links begin to change, when multiple pages list some of the same links, and when several librarians must maintain the pages for their subject disciplines.

In complete contrast is the "dynamic" web page, a concept that has been widely adopted by e-commerce sites. It is seen in subscription databases and is one of the driving forces behind Web search engines.

Dynamic Web pages do not exist until they are requested. In the case of SourceFinder, here's what happens: First, a patron goes to the resource's main page, where he specifies exactly what he wants by selecting from pre-set categories and setting the appropriate "limits." When he clicks the "Search" button, his request is sent as a query to a database of sources that is organized into searchable "fields." The requested data is identified, collected, poured into a pre-formatted HTML template and displayed on the patron's computer screen. The patron's customized Web page is thus built "on the fly."

If the concept seems vaguely familiar there's a good reason. Whenever you use JSTOR, Amazon, or Google you benefit from the power of dynamic web-page creation. The same is true when you use your library's online catalog or place a bid at an online auction site like eBay.

SourceFinder's Main Page: The "Front End"

We call the main user interface to the SourceFinder the "Front End." Readers may want to test the SourceFinder's Front End by going to: http://www.vmi.edu/sourcefinder/ (See figure 1-FRONTEND.)

The Front End allows a library patron to search for library sources in three ways. The first way is to specify a subject, source, and any limits you wish to place on those sources. By clicking the "Search" button a list of sources and source descriptions matching your criteria appears on the screen.

The second way to search is to simply click on one of the links on the left-hand side of the screen under the heading "Take me to…" aOne might assume that all eight links in this category connect to "static" Web pages. In fact, three of the eight links do connect to static pages. Those links are: the "Online Catalogs" link (which we rarely need to change), the VIVA "Journal Locator" link (which goes to a resource outside the VMI domain), and a "Help" page that goes to generic help file.

Finally, we created a link called "Quick Search," which allows users to go to a third search interface that lets them conduct keyword searches in multiple fields or keyword searches in title or subject fields.

Having a mix of static and dynamic pages, and links that run queries automatically, as well as the main SourceFinder search page and the "Quick Search" feature, gives patrons a number of ways to locate library resources.

SourceFinder's Secret Page: The "Back End"

Most SourceFinder users do not realize there is a secret "Back End" just for administrators. When librarians click on the SourceFinder logo on the main page they are prompted for their user name and password. A screen then appears with several administrative options: input an entry, edit an existing entry, delete an entry, view all entries, add a new subject category, and view user comments. (See figure 2-BACKEND.)

While selecting each of these categories makes different forms appear on the screen, they all have one thing in common-they allow the administrator to alter the contents of the SourceFinder or the way it functions. The librarian simply types in source titles, checks boxes for criteria that apply, and types in a description. When the "submit" button is selected, the change is added to a Microsoft Access database located on VMI's server, thereby updating the contents of the SourceFinder in real time.

There are a few advantages inherent in this concept. First, since it is Web-based, the contents of the SourceFinder can be modified remotely. Second, because the same options and check boxes are presented for describing every source, descriptions tend to be more consistent. Because the information will flow into an HTML template, on screen appearance is always consistent. When a source's URL changes, we make the change using the Back End and that change instantly and automatically is reflected in any study guide created by a patron from that time on. In addition, none of the administrative forms requires any knowledge of HTML.

Best of all, when librarians need to change a URL in SourceFinder, they change it only once. Whether the link appears on one or a hundred study guides, that change will automatically be made on all guides listing the source. When it is time to run a link check (which we do weekly), our link checking software checks the contents of one database, instead of 18 separate pages.

How We Created the SourceFinder

Dynamic web pages can be created using a variety of hardware, software applications, and hand-written scripts, including CGI (Common Gateway Interface), Perl, or JAVA. In fact, almost any programming language could conceivably be used.

Since VMI's computing infrastructure relies heavily on Microsoft products, we decided to use what we already had in place. On the hardware side, we utilized a server running Microsoft NT and Internet Information Server (IIS). On that server we placed a Microsoft Access database containing descriptions of select library resources. We chose to use Microsoft's Active Server Pages (ASP) as the programming piece between the Front end and the Access Database.

The SourceFinder's main screen (Front End), administrative screens (Back End), and display screens were created using Microsoft's HTML editor FrontPage. Finally, all the components were tied together with several handwritten scripts created by our programmer using the programming language Visual Basic.

The basic SourceFinder interface was created by a single programmer, and was modeled on the Data Genie. We had a working model in about two weeks and library staff tested the prototype by slowly adding content to the Access database. Next came a process of testing the resource over the course of a month. When we were satisfied with the results, we began to enter more and more data into the Access database. With minor modifications the resource was complete in another month.

At this point the Access database contained all the sources and descriptions that had been our 18 study guides, but in a more versatile format. Essentially, we swapped 18 "static" study guides for a tool that could potentially generate thousands of "dynamic" custom guides.

Ultimately SourceFinder has helped ensure that all our guides have a consistent look, structure, and functionality. It has also completely eliminated the need for librarians to know HTML, allowing us to focus on our strongest suit- organizing information sources. uiWe now teach use of the SourceFinder in all introductory bibliographic instruction classes and routinely show it to students in one-on-one consultations. Statistics indicate SourceFinder has become one of the most visited of all library pages.

Plans for the Future

The technology behind SourceFinder is highly flexible. Dynamic Web pages could be used for a variety of purposes in a typical public library branch system or in any academic or special library.

For example, library staff at VMI recently used Active Server Pages to create an online signup page for a series of faculty development workshops. Faculty members register online, filling out a brief survey in the process. Instructors can not only view survey results and see who is registered, they can enter a "Back End" component of the site to change or update workshop descriptions, and even send e-mail that will automatically go to all registrants.

More recently we created an Electronic Reserves system that utilizes Active Server Pages. The site has a Front End for patrons to use and a Back End that allows library staff to add and remove digitized articles, problem sets, practice tests, and even audio files and video clips.

In another creative use of Active Server Pages, the VMI archives just went public with a search tool for finding archived historical images. The search tool and display interface are powered by Active Server Pages, allowing it to tap the contents of an Access database that will eventually house more than 7,000 historical images and their records. Not only does it push archival collections out to the public, it also allows archivists more flexibility and control in cataloging their materials.

These days, VMI uses Active Server Pages to power Web sites for conference registrations, all online calendars, a jobs postings page, and several faculty/student directories. With so many new examples of dynamic Web pages, it suddenly seems like the sky's the limit.

References

Stop the Static: Serve Your Patrons Dynamic Web Pages http://www.vmi.edu/library/kw/vla2000.htm Outlines the author's presentation at the Fall 2000 VLA conference.

My Library http://www.library.vcu.edu/mylibrary/

The Data Genie http://www.lib.calpoly.edu/research/data_genie.html


DLA Ejournal Home | VALib Home | Table of Contents for this issue | Search VALib and other ejournals