ACRL College & Research Libraries News

Association of College & Research Libraries

Large-scale application of a Web browser

By Ann Koopman and Sharon Hay

Designing an interface for the ultimate workstation

The University Library at Indiana University- Purdue University Indianapolis (IUPUI) has built a multiplatform, multimedia, integrated workstation using a World Wide Web browser as an interface. Providing access to multiple Internet sites, online catalogs, networked ap- plications, indexes/abstracts, video resources, personal storage space, and communications, the Library Information System (LIS) has be- come the primary tool through which informa- tion is both delivered to and manipulated by students at IUPUI. The intent of the system is to provide, at a single station, everything a re- searcher may need for project work from start to finish. Since the introduction of the LIS in early 1994, librarians have learned many les- sons about the design, delivery, management, and use of technology.

The campus environment

As its name implies, IUPUI is a collaborative venture between two Big Ten universities— Indiana (IU) and Purdue (PU). The two merged their Indianapolis programs in 1969, combining IU’s focus on the liberal arts and professions with Purdue’s emphasis on engineering, technology, and the sciences. Over 170 programs, from associate through doctoral levels, are available to more than 27,000 students on this commuter campus. The university’s primary mission is to meet the needs of the diverse urban population of Indiana’s largest city. These needs include classes and services geared toward the commuting student, appreciation of the ethnic and international diversity of the population, and recognition of the impact computer technology has had on education, especially for returning, nontraditional students.

The library environment

As part of its mission, IUPUI recently built a new University Library, a $32 million state-of- the-art structure designed with the electronic age in mind. Before construction began, the administration articulated some key directives for the new building. Among these directives were commitments to deliver information regardless of format, and to deliver that information to virtually every seat in the building. This meant that the library building had to be constructed to provide delivery of text, video, audio, and graphics to individual sites throughout the facility. To meet this goal, the design included the installation of both twisted pair and fiber optics cables to more than 1,700 work sites—more than 125 miles of optical fiber. Recognizing that patrons work with a variety of operating systems, the library provides a mixture of platforms. More than 75 public workstations currently in place provide access to in- house resources and unrestricted access to the Internet. Network connections are also available throughout the building to patrons who bring their own computers or check out one of the library’s supply of 20 public laptops.

Development of the Library Information System

Planning for what was to become the Library Information System began in 1989, assisted first by Ameritech and later by IBM as a joint appli- cation development program. In the process the library also developed a fruitful partner- ship with Integrated Technologies (IT), the computing services arm of the campus. Every segment of the IUPUI community was involved in the development of the LIS through partici- pation in focus groups. This resulted in com- munity acceptance and ownership of the final product.

Ann Koopman is coordinator of electronic information resources at Thomas Jefferson University in Philadelphia, e-mail: koopman@jeflin.tju.edu. Previously she was science and engineering librarian at Indiana University-Purdue University Indianapolis (IUPUI). Sharon Hay is reference librarian at IUPUI, e- mail: shay@library.iupui.edu

Originally programmed in HyperCard and Visual Basic, the LIS was always intended to have a graphical user interface and to provide audio and video components. Extensive design and programming work had already been com- pleted when the first graphical World Wide Web browsers appeared. It was immediately appar- ent that a graphical browser offered several advantages over in-house programming:

• Involvement of the librarians in the con- trol of their own information environment. Web sites are easy to maintain, as opposed to using programmers to code every addition or change. Cost issues are implicit here as well.

• Multimedia capacities of the system. The ability to deliver audio and graphics, and to launch external software from within the inter- face were very attractive.* Virtually all previ- ously developed icons and images could still be used.

• The hypermedia freedom of the Web environment. The original system had been designed rigidly, using hierarchies and di- rected paths—very like gophers. Use of the Web preserved the hierarchies as an option, but also opened horizons for more flexible movement.

There were difficulties, of course, with the selection of and migration to Mosaic, the browser initially selected. Most notable was that user authen- tication had to be shifted from opening screen to server level—that is, to the point of login for each application. Dif- ferences between early Mosaic interfaces for the multiplatform environment, such as different button bars, were disturbing. Finally, along with their empowerment in the area of interface control, librarians had to accept the responsibility to learn and handle technology. Impact on staff time was significant as the librarians entered the partnership.

The site

Key features of the homepage (URL: http:// www-lib.iupui.edu) include:

• A bitmapped image homepage, with alternate line mode access for remote users.

• An express bar of high-demand services, such as word processors and the local online catalog.

• Division of resources by major type or category, such as campuswide information, online catalogs, communications, and a special “reference department.”

Under the icons lie hierarchies of menu screens, further breaking down categories. Layers are no more than four screens deep. Help screens are interposed between each item listed on a menu and the actual site and are intended to assist the novice or the remote user. Experienced patrons can’t “turn off” the help, but can move rapidly through it to reach the site described—the initial heading of each help screen is a large target anchor. Other applications, such as bibliographic databases and word processors, provide help online.

Choice of sites and organization

The original 100 Internet sites loaded for the April 1994 public unveiling of the system were assembled rapidly by a small team of librarians. All types of sites were included, from finite documents to gateways and bulletin boards, as well as every type of protocol. Sites were judged, as with any collection development program, by certain criteria for inclusion:

The homepage of the IUPUI University Library is a bitmapped image with an alternate line-mode option for remote users.

… save radical changes for between semesters. . . . Think twice before changing a major icon, pathway, or browser during term paper season.

• The source, reliability, and completeness of information.

• Frequency of update and commitment of the host to maintenance and stability.

• The relative value of the information to local clients.

• The workability of the site, i.e., its ease of connection and ease of use.

At first, maintenance of links was extremely demanding. Constant review and update were required. Within the first six months of operation, 20 percent of the original Internet sites either disappeared or changed enough to require rewrite of the help screens. As the Web has matured, substantive sites have become more stable, and programs like MOMspider are available to automate the link-checking process.

Long-term maintenance issues have also forced organizational changes in the library. A team of librarians now works on the system as a collection development project. Team members write html files and develop expertise in certain types of resources. They also teach html to faculty and students, and consult with faculty or other librarians who wish to mount their materials on the system.

Lessons learned

As one of the first library sites to appear on the Web, IUPUI has had time to listen to patron and staff feedback. Some of the issues raised address content, others address process. What have we learned?

1) Design for long-term flexibility, assuming changes in technology will be the norm. Browser capabilities and refinements have grown, as have html standards. IUPUI now uses Netscape and continues to review other browser products. The dangers of designing to a single browser or set of equipment quickly became apparent after Netscape was introduced in early 1995. Many files had to be rewritten not just because of instruction differences, but because of display differences. As another example, the homepage image was designed as a single-screen image for the SVGA monitors in the library building. Remote patrons using VGA monitors, however, cannot see the full image on one screen. They have to scroll around to use many of the icons, thereby defeating much of the purpose of the design.

2) Graphics aren’t necessarily better than text. Use of the bitmapped homepage inhibits the indexing capabilities of some Web search agents. The icons selected for the homepage area are not as intuitive as originally hoped, and patrons complain about the large number of them. The use of visual metaphor has become far more sophisticated since the early days of the Web. At the same time, simple words tell patrons what they need to know without a lot of distraction, and without overwhelming their modems.

3) Lack of an internal search engine option on the homepage frustrates patrons who remember a resource by name but not the hierarchical path to get there. Alphabetical lists by site title become too cumbersome to use after the site grows beyond a certain point. Given the variety of search engines available today, this needs to be considered a basic necessity for any large site.

4) It is possible to try to help users too much, and thereby make them dislike or resent the interface. The original concept of help screens, instructing patrons on how to click and navigate the Web, were appropriate at first because of the newness of the concept. By now, however, patrons are much more sophisticated. Unless there are login instructions or other special circumstances, routine help may not be worth the resources required to create and maintain it.

5) At the same time, patrons need help with many other activities, such as equipment glitches, paper supply, and word processing commands. Originally designed for completely independent use, workstations on upper floors are now monitored by library staff. A special cluster of stations, attended by a computing services consultant, provides advanced assistance with core programs.

6) Demand for computing always swells to meet and exceed supply. Add to that cynical rule the fact that at IUPUI all workstations perform all functions, and the result is lots of new “appropriate use” policies. Signage is only partially effective at keeping word processing, e-mail, and frivolous Internet use out of the reference area, where legitimate scholarly demand often exceeds the supply of equipment. Use of blocking features available for selective denial of specific resources from specific machines can help staff avoid becoming police.

7) It quickly became clear that all departments in the library were both affected by and interested in the project. The initial team of librarians involved with the project was drawn solely from public services. Later, two interdepartmental groups were formed to deal with policy issues (standards, organization, access) and editorial issues (collection development, resource description). The resulting crossfertilization has been very positive.

8) Patron education was and continues to be paramount. Organized general classes, departmental outreach, and constant marketing of group instruction options are the only economical way for beleaguered library staff to keep up with large-scale patron need. Additional impact on reference encounters has been severe; patrons require not only delivery of information at the point of request, but instruction on use of the system in order to obtain it. This is a familiar problem encountered with the introduction of every new technology. The main problem is getting the patrons who need it most to attend the workshops in anticipation of future need.

9) Evolution is necessary and good, but save radical changes for between semesters. Simple additions of new sites, like adding new books to the shelf, can take place at any time. But think twice before changing a major icon, pathway, or browser during term paper season. As simple-minded as this may seem, competing interests may drive timetables and installation dates without regard for patron needs or staff capacity. The librarians, especially the public service librarians, sometimes need to intercede in the planning process on behalf of the patron.

10) Don’t let perfection get in the way of a good job. This is almost a corollary to the previous lesson learned. Rapid evolution in this medium is a fact, and we can squander both our time and patrons’ tempers by trying to maintain hierarchical relationships, lots of rules, and testing ad infinitum. Sometimes we just have to put material out and see how people react to it before we can progress, knowing it is easy to change and to grow. Rapid-response teamwork based on trust in patrons and colleagues is the most constructive strategy.

11) The library is becoming a publishing medium. While pointing to lots of sites at other locations is like building a collection of books, the development of unique content contributes to the scholarly repertoire. IUPUI’s contributions of its Philanthropic Studies pages and Special Collections pages are the library’s first unique publications. The next step is to collaborate with faculty to produce teaching materials or to publish new scholarly works in the electronic medium.

Conclusion

The LIS is an evolving product; it will never be “finished.” Growth in numbers of sites, numbers of stations, new technologies, and uses must be assumed, and librarians must participate fully at every stage.

The cost of such participation can be high. The LIS project has stretched human resources, sometimes to the breaking point, and has forced major organizational shifts within the library as librarians take on new roles. The challenge faced at IUPUI is to create a distributed system that is as independent as possible of human attendance, conserving this type of staff resource for development of the interface.

Even so, the interface is like the new IUPUI library building, just a shell. What matters is the content—what is on the shelves and how people get to it, or collections and signage, if you will. It also matters how people can interact with what they find. The promise of the electronic environment to bring the patron into a much more interactive context as consumer, manipulator, and contributor of system content is wide open to development by entrepreneurial librarians.

* Author note:Copies of the launcher software, written by Larry Tenny of University Computing Services, IU-Bloomington, are available at: site: ftp.law.indiana.edu; password: yourusemame@host.domain; login: anonymous; directory: /pub/www.

For the Windows launcher, download two files: launcher.zip (set file to binary); launcher.readme (set file to ascii).

For the Macintosh launcher, download one file: Maclauncher.sea.hqx (set file to ascii). ■