Navigating the Library: A Web-Based Library Instruction Tutorial

Michael Kreyche
Kent State University Libraries and Media Services


ABSTRACT

Many library databases such as online catalogs and journal indexes are now delivered via the World Wide Web, in some cases supplanting the dumb terminal interface entirely. This development represents an opportunity to explore new techniques for library instruction using the Web. The nature of Web technology makes it easy to integrate the subject matter and the teaching medium seamlessly.

The Kent State University Libraries have begun using a Web-based tutorial to deliver instruction about some of its Web-based resources. Freshman enrolled in the University's orientation course take the tutorial to familiarize themselves with KentLINK (the KSU online catalog) and the Periodical Abstracts database, two of the library's most heavily utilized information sources. The tutorial leads students through the process of searching the databases, identifying a book and an article, and locating the items. The tutorial creates a controlled environment that reproduces the look and feel of the databases while guiding the students' actions and intercepting any missteps. After the tutorial they are given an assignment to complete that requires them to use the databases covered in the tutorial. Students typically take the tutorial during a class session but can also work on it independently, either to finish up if they ran out of time or to review while working on the assignment.

The tutorial opens a clean browser window (free of the standard menu and toolbar) with three frames: two small ones for navigation and explanatory text, and a large one that contains either instructional material or a modified database page. The database pages (examples copied directly from the "live" databases) preserve the appearance of the actual database environment, but the actions of interactive elements such as links and submit buttons are modified to operate within the context of the tutorial. For example, clicking on the correct link advances the student to the next page while clicking on a link irrelevant to the concept being taught on the current page triggers a warning message with instructions on the next step to take. The tutorial makes extensive use of JavaScript but most of the code is fairly simple, making the tutorial easy to put together and maintain.

The freshman library instruction program has evolved through a number of formats--live lecture, slide show, audiotape tour--but each of these formats had distinct disadvantages which the Web format promises to overcome.

Keywords: javascript tutorial online library databases catalog 



The World Wide Web has become the medium of choice for publishing, searching for, and retrieving information of all sorts. At the same time, the Web browser is becoming a universal client, a sort of skeleton key that can unlock almost any kind of treasure. Libraries have been quick to acknowledge the importance of these twin developments and are adopting Web technology to deliver a wide spectrum of resources and services to their patrons.

Online catalogs and encyclopedias, journal indexes and article delivery services, full text databases, guides to library facilities and collections, reserve materials and requests for interlibrary loans--all these are now routinely available with a Web interface, and are being woven together more and more tightly into virtual libraries.

In Ohio, for example, a state-funded consortium links the online catalogs of nearly fifty institutions to a union catalog--a master catalog of all the individual catalogs--and makes available to these institutions a wide range of commercial databases from OVID, ISI, Wilson, UMI, and other sources.  At my last count, there were 54 such databases, and only seven of them had no HTML-based interface. Of the 47 with Web interfaces, twelve of them had no alternative dumb terminal access.

While the Web has improved access to these resources and services, in part through user-friendly interfaces, the fact remains that many of the databases are sophisticated tools capable of  complex task that are difficult to understand. Consequently the need for instruction in the use of these resources remains a high priority.
 
Just as the Web has become a tremendous tool for doing library research, it is likewise an exciting instructional  medium, and it is only natural to combine the these two uses of the Web. There have been Web-based tutorials that teach how to use online resources (for example, the Library Explorer on the World Wide Web at Iowa State University), relying on screen images of of the online system to show students what to do. But when the online system is Web-based, it's possible to build functional screens right into the tutorial. These screens can be "live," representing HTTP connections to the system, or they can be interactive screens that simulate and demonstrate how the real thing works.
 
A tutorial of this type of type called Navigating the Library (NTL) has been developed at Kent State University for use in an orientation course required of all freshmen entering the university. One session of the course is devoted to an introduction to the libraries, including instruction in the use of KentLINK, the online catalog, and Periodical Abstracts, one of the databases available through the OhioLINK consortium. Traditionally the instruction was delivered in the form of a lecture and demonstration, after which students were given a written assignment to practice the techniques that had been shown in class. The new tutorial provides the same instruction in a hands-on, interactive format. After initial field-testing during the summer with a few groups of students, it is being utilized this semester in 10 sections of the class and will be available as a makeup option to students who miss the lecture class. After further refinements which will be tested in the Spring on a larger number of students, we expect full deployment of the system to approximately 2700 student next Fall 1998 semester.
 
The object of the tutorial is to lead the student through the process of searching the two databases, identifying a book and an article on a specific topic, and then learning how to locate the items physically or have them sent from another library or perhaps, in the case of the article, printed out from a full text database. The tutorial uses canned examples chosen to illustrate certain points, but requires the student's interaction in order to proceed from one step to the next. This motivates the student to study the material being presented and provides the student with an opportunity to exercise judgment during the learning process.

Since the tutorial uses essentially the same HTML that is used in the actual database, the screens that the student sees and interacts with are identical in appearance with those in the database, though the functionality has been modified to serve the instructional purposes of the tutorial, and only simulates the operation of the database engines. When the student understands the point being made and performs the desired action, the tutorial proceeds to the next step; if the student makes mistake, the tutorial provides corrective feedback instead of permitting the student to wander off on a tangent.

At the end of the tutorial the students are given the written assignment that requires them to search for a book and an article on a topic of their choice. If they have enough time during the class session they can begin work on the assignment right away; if not, they can finish it at another workstation in the library or elsewhere. Since the tutorial is on the Web, they can easily return to it while doing the assignment if they need to review the lesson. During the class, the instructors are available to give individual assistance that they would not have time for if they were also trying to lecture. Future versions of the tutorial may permit students to submit the assignment online.

 
One of the original assumptions behind Navigating the Library was that it should be server-independent and as browser-independent as possible. Server independence was a goal because Kent State University has eight campuses whose libraries all work closely together, and share in the use of OhioLINK resources. The tutorial was designed from the start to be  generic enough to be used at all campuses, with some customizable elements, and operated from local servers.

The interactive nature of the tutorial and the need to accomodate different server platforms pointed clearly to browser scripting as the simplest and most appropriate technology for the tutorial. Scripting poses a real problem for browser independence, though; Netscape's JavaScript is the most universal script available, but is not well-supported on Microsoft browsers. Another dilemma arose when comparing different releases of JavaScript; version 1.1 (implemented in Navigator 3.x) turned out to have some very useful features that preclude the use of Navigator 2.x and Internet Explorer. Still another compatiblity issue arose when I discovered a feature that worka on the Windows version of Navigator 3.x but doesn't work on the Macintosh version. For the current semester, given the limited deployment of NTL on campus, Netscape Navigator for Windows 3.x is the only targeted browser, but the compatibility issue will have to be revisited.

Although even a brief description of the JavaScript language is beyond the scope of this paper, a few comments on its capabilities may be useful. JavaScipt is a language that can be inserted within an HTML document.  The browser and various HTML elements (such as windows, documents, forms, buttons and images) are envisioned as hierarchical organizations of objects with properties that JavaScript code may read, manipulate, and change. Besides having properties, these objects also have methods and events associated with them. The methods are actions that the JavaScript code can initiate, and the events are actions (for example, mouse clicks and URL changes) that JavaScript code can respond to. Like any programming language, JavaScript also comes with an assortment of operators and functions for manipulating data, as well as constructs such as variables, arrays, and user defined functions.

JavaScript can be inserted in a document in several different ways, three of which will be used here:

These techniqes are demonstrated in the following HTML document which features a hyperlink that has been programmed to behave in a non-standard manner. Instead of loading a new URL it will display a message box with the name and version of the browser viewing the page
<HEAD>

<SCRIPT>

var theBrowser = navigator.appName

var theVersion = navigator.appVersion

function showBrowser() {

  yourBrowser  = theBrowser

  yourBrowser += ", "

  yourBrowser += theVersion

  alert(yourBrowser)

}

</SCRIPT>

</HEAD>

<BODY>

<P>What is your <A HREF="javascript:void(0)" onClick="showBrowser()">browser</A>?</P>

</BODY>
First there are several lines of JavaScript code enclosed by <SCRIPT> and </SCRIPT> tags in the head of the document. This is a good place to put code, especially when functions are defined as in this case. This bit of code first reads the name and version properties of the "navigator" or browser.  It then defines a function, showBrowser() that joins the text of these two properties, separated by a comma and a space, and displays the resulting string of characters in a message box using the alert() method. Note that defining a function does not execute the code in it; for the code to be executed the function must be called. That's done in the <A> tag in the body of the document. A mouse click on the hypertext link (the word "browser" enclosed by the <A> and </A> tags) triggers the onClick event which executes the showBrowser() function. Finally, the URL specified in the HREF= attribute is a little piece of JavaScript trickery, to be discussed later, that disables the usual hyperlink action. On the browser I'm using as I write this, this code displays the following message: See what results yours produces by loading a page with this code and selecting the link.

Once the technology for Navigating the Library was selected, it was time to think about specific design considerations. One of these was the window size. Most monitors in the libraries on the Kent campus are at least 15" and the screen resolution is generally 800 x 600. Nevertheless, if NTL was to be used in a variety of labs, in dorm rooms, and on the other campuses, it seemed prudent to design for 640 x 480 screen resolution. The window size established for NTL was set at 600 x 480 pixels, thus allowing for a little unoccupied space on a 640 x 480 screen. To make the best use of the confines of this area, Navigating the Library opens a new window for itself without menus, toolbar, or location bar, and provides its own navigational tools. This customized window simplifies the user interface and at the same time helps define NTL as a tutorial rather an ordinary Web site.

The fact that the subject of the tutorial is a series of Web pages intended to fill an entire browser window imposed some severe restrictions on the design of the user interface. It was pretty clear from start that there was a need  to have instructional material placed adjacent to the database screens, and the most obvious solution to this problem was to use frames.

As common as frames are on the Web, their implementation is frequently clumsy and the results are often awkward to work with, so the decision to use them for Navigating the Library was not made lightly. Two factors made the argument for frames pretty compelling. In the first place, the only other alternative was to use a separate window for the instructional material, and this seemed even more awkward and fraught with usability problems than frames. Secondly, since the intent was to create a simulated Web page, faithful in appearance to the genuine one, putting it in the context of a frameset seemed like a good idea since that would help distinguish the simulation from the real thing. In the end a frameset with three frames was settled on, one large frame with two narrow ones, one across the top and another down the side. The frames are non-resizable, have no borders, and the content of the small frames is kept to a minimum to avoid scroll bars. The result of these measures is a fairly clean interface, free of the clutter that often accompanies frames.

The entry page to Navigating the Library is essentially a "splash screen" with a "Continue" graphic that starts the tutorial by opening the new 600 x 480 window, displaying some instructions on moving and resizing the window. This proved necessary because the window opens in unpredictable places on the screen, and is not alway entirely visible. JavaScript 1.2 (implemented in Navigator 4.0, part of Netscape's Communicator suite) is able to control window placement as well as size, but this is a step down the path of incompatibility that I'm not quite ready to take.

Clicking the "Continue" graphic calls a JavaScript function that rewrites the splash screen with new JavaScript code in the <BODY> tag. The script that accomplishes this is about the most complicated of all the code used in NTL, but except for a series of escaped quotes it's actually fairly simple:

<SCRIPT LANGUAGE="JavaScript">

// rewrite this window, opening the NTL window and making it stay "on top"

   function ntlWindow() {

     document.writeln('<HTML><HEAD><TITLE>Navigating the Library</TITLE></HEAD>')



     document.write('<BODY BGCOLOR="#FFFFFF" ')

     document.write('onLoad="theWindow=')

     document.write('window.open(\'win.htm\',\'NTL\',')

     document.write('\'height=480,width=600,toolbar=no,location=no,')

     document.write('status=yes,menubar=no,scrollbars=yes,resizable=yes\')" ')

     document.writeln('onFocus="theWindow.focus()">')



     document.writeln('<TABLE WIDTH="100%" HEIGHT="100%" VALIGN=CENTER>')

     document.writeln('<TR>')

     document.writeln('<TD ALIGN=CENTER>')

     document.writeln('<IMG SRC="homeimag.gif" HEIGHT=153 WIDTH=425>')

     document.writeln('</TD>')

     document.writeln('</TR>')

     document.writeln('</TABLE>')



     document.write('</BODY></HTML>')

     document.close()

     return false

   }

</SCRIPT>
The resulting rewritten page has two event handlers in the BODY tag:
  <body BGCOLOR="#FFFFFF" 

  onLoad="theWindow=window.open('win.htm','NTL','height=480,width=600,toolbar=no,location=no,status=yes,menubar=no,scrollbars=yes,resizable=yes')"

  onFocus="theWindow.focus()">
The onLoad handler creates the new window when this one finishes reloading, and the onFocus handler makes the new window "always on top" with respect to the splash screen window. In other words, anytime the splash screen receives the focus (is clicked on or otherwise brought to the foreground) it immediately returns the focus to the new window (puts it in the foreground). The reason for this feature grew out of experience with the initial group of students that tried out the tutorial. If the initial browser window covered most of the screen or was maximized, sometimes a student would accidentally click on it and the NTL window would disappear behind it. Further experience will tell if implementing this feature is worth the compatibility tradeoff; the onFocus event in the <BODY> tag is a JavaScript 1.1 innovation, so it is unsupported in Navigator 2.x and Internet Explorer. I also discovered that it does not work on the Macintosh version of Navigator 3.x.

Clicking the "Continue" graphic in the new window displays the frameset that will be used throughout the remainder of the tutorial, and the first order of business is a sort of tutorial on the tutorial. The main frame has text in it that explains what that area will be used for, and prompts the student to click the blue area. That frame reloads with text explaining how it will be used, and the student is prompted to click the gold area for an explanation of how it is used. These actions are likewise triggered by the onFocus even in the <BODY> tag. Finally, navigation icons appear, and the student learns how they are used. At this point one of the fundamental techniques used in NTL makes its debut. What if a student clicks on a hyperlink other than the intended one? In this example, clicking on the "Back" icon instead of the "Home" icon causes a message box to pop up using JavaScript's alert() function, though other more sophisticated actions are possible. This could be accomplished with an onClick event handler in the <A> tag, the same technique used in code for displaying the browser name and version, but here is an abbreviated version:

   <A HREF="javascript:void(wrongLink())">
The javascript: protocol expects the code that follows it to evaluate to a URL that will be used for the hyperlink. In this case, though, the void() operator executes the wrongLink() function but does not return a value, so the hyperlink is effectively disabled. The void() operator is new to JavaScript 1.1, and so is not compatible with Navigator 2.x and Internet Explorer, but another technique can be used that is compatible:
   <A HREF="page.htm" onClick="wronglink">
In this case, "page.htm" is the name of the page already displayed in the frame; this simply causes the page to reload. The only disadvantage to this method is that there is an annoying flash when this happens. A newsgroup posting that I discovered recently discusses the question of disabling hyperlinks pretty thoroughly, and suggests yet another method that I haven't tested. It sheds a lot of light on the void operator and the javascript: protocol, which Netscape covers very spottily in its documentation.

The disabling of the "Back" icon only occurs one, in the "tutorial on the tutorial". Its normal function is to return the student to the preceding page in the sequence, and the HREF= attribute is hardcoded with that page's URL. The only case where this strict sequence is not enforced is on the "Home" page, designed for students who want to review specific sections of the tutorial instead of following the entire sequence. Since the "Home" page can be accessed from anywhere, the URL for its "Back" icon can't be hard coded. Instead it uses the browser's history to go back one step. This is an example the javascript: protocol with an expression that does evaluate to a URL:

    <A HREF="javascript:parent.history.back()">
Here the back() method returns the most  recent URL from the parent frame's history.

A few pages farther along, the first simulated database page from KentLINK, the online catalog based on Innovative Interfaces, Inc.'s INNOPAC software, appears in the main frame. It has some disabled hyperlinks near the bottom of the page, but the element of most interest is the textbox. The instructions for the database searcher are "Click in the box, type some Word(s), then press ENTER," but within the tutorial, the idea is to demonstrate the principle with a pre-arranged example. So the student is instructed to "click in the box" and "press ENTER," but the typing part is done automatically. This accomplished by a function called by the onFocus handler in the <FORM> tag:

var typeText = "cyberspace"

// auto-type a string in an input field

function autoType() {

    document.forms[0].wsearch.value = typeText

    document.forms[0].wsearch.focus()

    document.forms[0].wsearch.select()

}
...
<INPUT TYPE=text NAME="wsearch" onFocus="autoType()">
The HTML of the actual database page uses the <ISINDEX PROMPT=...> tag to create the input box; in NTL I substituted a form with a text input field but no submit button, which duplicates both the appearance and function of ISINDEX but allows JavaScript event handlers. JavaScript has full access to form elements, and here modfies the value of an <INPUT> element called "wsearch". When the student presses the Enter key, the onSubmit handler instructs the browser to load a new page:
    <FORM onSubmit="parent.location.href='klwb.htm'">
Of the numerous hyperlinks the student could select on this page, only one is acceptable in in the context of the tutorial, so the others need to be intercepted using the technique described above for the "Back" icon. There is also a form near the bottom of the page, and its submit action likewise needs to be intercepted. A single function will suffice for both:

// display error message for clicking wrong link
function wrongLink() {
    alert("This is simply an example. Click on line 6 to advance.");
}

In the case of the hyperlinks, the function is called by the onClick handler:

    <A HREF="klwb-m.htm" onClick="wrongLink()">
and in the case of the form, it is called by the onSubmit handler:
    <FORM onSubmit="wrongLink()">
Notice that the form's ACTION= attribute can be removed since this form will not be submitted to a server. In both cases, after the student acknowledges the message box there is a brief flash as the page reloads.

So far we've seen how the submission of  a form can be simulated and how it can be intercepted. It's also possible to evaluate the contents of a form and choose whether or not to allow the submission. The next example shows a form with student input that requires validation, and unlike the previous example of a form, this one contains a submit button. This is a page from the UMI Periodical Abstracts database, also running under the INNOPAC software. At this point a specific article identified and the student is being shown how to have a copy printed on demand at the library. The first step in the authentication process requires the student to indicate institutional affiliation using a list box. A function checks the selection to make sure it corresponds to Kent State University, and displays a message if not. Otherwise the browser loads a new page:

function checkKSU() {

    if (document.forms[0].campus.options[13].selected != true){

        alert('Select Kent State University')

        return

    }

    parent.location.href='paln.htm'

}
Again, the function is called by the onSubmit handler in the <FORM> tag:
    <FORM onSubmit="checkKSU()">
Again, the form has no ACTION= attribute because it is not being submitted to a server.

The final example shows highlighting that was added to a database page by setting a background color for a table cell. Of course this assumes that the page uses tables for formatting or can be rewritten with a table without disturbing the original layout too much. A few other modifications to the original HTML of the database pages were made for cosmetic reasons, when excessive wrapping was occurring. Under ordinary circumstances the pages look fine, but when viewed within the confines of the NTL frame, the wrapping was sometimes distracting or unattractive. It also pushed other content off the bottom of the frame and made it more likely that the student would have to use the scroll bar.

Over during the current year one of the important tasks will be to resolve the Internet Explorer and Macintosh compatibility issues. As new browser versions are released some of these problems may go away, but it seems likely that automatic branching needs to be added to the code to accomodate less compatible browsers. Other enhancements may include virtual tours of the libraries utilizing photos or possibly digital video, and putting the assignment online.

This Web-based version of Navigating the Library is the latest in a series of formats used for delivery of freshman library instruction. At one point it took the form of a slide show, and then for a number of years became a part of English 10001, the freshman English course, with librarians taking one class session to give a lecture. This developed into an audio taped walking tour of the library outside of class time, relieving the librarians of the heavy lecture load and restoring the class period to the English course. A couple of years ago the program was moved to the Orientation class, which is team taught by a member of the faculty and a student peer instructor. The lecture format was restored, with a librarian developing the course content and training the Orientation instructors.

The hope for Navigating the Library in its Web-based incarnation is that it will improve both the quality and consistency of library instruction. The interactivity of the program should engage the students more than a lecture would, and the ability of the students to work at their own pace should reduce frustrations among those who would find the pace of the lecture too fast or too slow. The program will allow the instructors to make better use of their time by allowing them to give individualized help for students requiring it. Since NTL is not limited to use in class, it is available at any hour, on campus or off, for students needing to review or for those who missed the class session. Some form of the tutorial not connected with the assignment will probably be made available to the general campus population as well.


Michael Kreyche
Assistant Professor
Libraries and Media Services
Kent State University
PO Box 5190
Kent OH 44242-0001
mkreyche@kent.edu
http://www.library.kent.edu/~mkreyche


© Copyright 1997. The author, Michael Kreyche, assigns to the University of New Brunswick and other educational and non-profit institutions a non-exclusive license to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author also grants a non-exclusive license to the University of New Brunswick to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the author.