5.3 ACCESS at the Library of Congress

Transcription

1 Sparks of Innovation in Human-Computer Interaction, 219 B. Shneiderman, Ed., Ablex Publ., Norwood, NJ (1993) 5.3 ACCESS at the Library of Congress Gary Marchionini Maryle Ashley Lois Korzendorfer Supporting patron access to library collections requires significant resources in all types of libraries. Card catalogs and reference librarians have traditionally assisted patrons in locating materials related to their information needs and the development of online public access catalogs (OPACs) has begun to affect both of these patron resources (Hildreth, 1982). Many libraries have invested heavily in OPACs in spite of the many problems they present to library patrons. Patrons have difficulty using the computer workstations, formulating queries appropriate to the OPAC command language, and interpreting feedback from the system (Borgman, 1986). In many libraries, reference staff who hoped that OPACs would allow them to assist patrons with challenging information problems have found themselves spending large amounts of time assisting patrons in the mechanics of using the OPAC. This problem is likely to be an ongoing one since patrons in public and academic libraries are what may be termed casual rather than regular users. The challenges of OPACs are particularly critical at the Library of Congress (LC), a premier library in the world and host to patrons from all walks of life and experience. The Library was a pioneer in automating bibliographic records and has long provided electronic access to its catalog. Patrons to the library are often visitors to Washington, D.C. who spend a short amount of time using the library and do not want to invest time learning to use the system. The existing systems

2 220 Section 5: Public access available to patrons, SCORPIO and MUMS, provide powerful search facilities for the enormous collection of the Library, but require significant skills to use and time to learn. In 1988 Information Technology Services (ITS), the Library s directorate for computer support, began exploring ways to deliver an easy-to-use front-end for the LC OPAC that would allow novice or casual users to quickly conduct searches of the collection without training. Such a system would not only improve patron satisfaction and service, but also relieve some of the training burdens on reference staff. Recognizing that an essential element of the design problem was the humancomputer interface, the Library invited the Human-Computer Interaction Laboratory (HCIL) at the University of Maryland to assist in designing such a system. Over an 18 month period, an HCIL team worked with an LC team first to give background and training in interface development in order to ground the project before it began work, and later to give objective feedback every few months on the interfaces being created. This collaboration took place in three phases. Phase 1. Human-computer interaction principles orientation and training A series of planning meetings were held to discuss the goals and directions for the project. A critical early decision was to include both systems staff in ITS and reference librarians from the reading rooms where ACCESS would be available. These meetings culminated in a series of four human-computer interaction training seminars that served to lay theoretical and practical foundations for the design. In addition to the content addressed, these seminars served the valuable purpose of helping systems staff and reference staff to understand each other s requirements and perspectives. The seminars held in late 1988 were half-day sessions and focused on four specific issues. The first seminar was conducted by Ben Shneiderman and provided an introduction and overview of interface design principles. The second seminar was conducted by Gary Marchionini and was focused on mental models for information retrieval. The third seminar was conducted by Kent Norman and addressed design of menus, icons, and interface evaluation. The final seminar was conducted by Charles Kreitzberg (of Cognetics Corp.) and focused on cognitive principles and project management issues. At the conclusion of the seminars, a cohesive team had formed with a common experience base and language for approaching the design process. Based on what they had learned in the seminars, the group was able to focus on a commonly perceived problem as they began imagining their new system. Also important, the team members had developed personal rapport as they participated in the seminars. Phase 2. Design consultations After the seminar series was completed, HCIL team members met with the LC team to discuss how to get the project started. Touch panel and keyboard input were recommended for the physical user interface and simple non-boolean queries and hypertext-like, usage-sensitive help were recommended for the conceptual user

3 5.3 ACCESS 221 interface. HCIL suggested that each team member try to imagine the system installed in the Library s reading room displaying its logo screen; then to imagine a patron walking up to it and touching the opening screen: What happens next? The first design meeting thus began with sharing each team member s image of what the system could be like. From this imaginary start, the LC team, or subgroups from the team formed around a specific task or area, began creating and discarding many paper versions of how their ideal screens would appear. After enough consistency developed to chart out the opening screens and some search paths, the HCIL team was asked to examine and critique them. By this point, technical processing staff had joined the team to help in determining the most productive search strategies. Their knowledge of the underlying data structures of the bibliographic data and its intent assisted in selecting which behind-the-scenes retrieval commands were best to use to answer patrons' search requests. The selection of a name for the new system also took place during the design phase. The beginning of each team meeting devoted about 10 minutes to brainstorming candidate names, which came and went as quickly as the paper screen designs. When the name ACCESS began to catch on, definitions of what the acronym could stand for resulted in a landmark decision: the acronym ACCESS means what it says ACCESS. Once ideas about the opening screen displays began to converge, the system staff converted them into prototype computer displays and met regularly with the reference and technical processing staff to discuss and modify them. The reference staff and technical processing staff soon gained appreciation for the constraints of system implementation and management, and the system staff gained appreciation for the types of problems and concerns patrons had as they used the Library and existing systems. After several iterations, the prototypes were discussed in a meeting of the full LC and HCIL teams. After additional revisions and the addition of a fail-safe code to intercept system errors and shield the patron from any awareness of error messages, the ACCESS system was ready for testing with users. Phase 3. Evaluation and feedback The system was first tested with reference librarians not involved with the project. Based on their positive response and after incorporation of some 30 suggested improvements, the system was tested with the public in the Adams Building beginning in November of Feedback from reference librarians and patrons was gathered from observations, interviews, and an optional online questionnaire where patrons recorded their opinions via the touch panel. These reports illustrated that patron acceptance was high and that patrons could quickly and easily learn to conduct searches with ACCESS. Based on these results, the system was ready for implementation in the refurbished Main Reading Room of the Library when it reopened in June of 1991.

4 222 Section 5: Public access The ACCESS system The ACCESS system was built on an MS-DOS platform using 386SX and 386 machines, a touch panel, and EASEL software. The ACCESS system software was written primarily in EASEL language which is a fourth generation language. The EASEL software provides a graphical user interface for communication with the patron, and then translates the patron s choice into the appropriate command for the LC mainframe database software. When the mainframe returns the result set, the EASEL software again handles the information and reformats it for the patron. EASEL is a hybrid language having some characteristics of object-oriented languages but still retaining some features of procedural code. As such it offered a faster startup for the system staff than undertaking an orientation to object-oriented paradigms. Subsequent design iterations have capitalized on the more modular approach available through EASEL s constructs such as class and hierarchy. To use ACCESS, patrons make selections via the touch panel by pressing buttons that are shadowed to give a three-dimensional effect (see Figure 1). Authors, titles, or subject headings are entered via a keyboard. Results of searches are displayed in a brief record format to facilitate browsing within the retrieved set (see Figure 2). When users select a record, the full bibliographic record is displayed (see Figure 3). All screens are titled and consistent wording is used throughout. Context-sensitive help is always available by touching the Help button which is consistently located at the bottom of all screens (see Figure 4 for an Figure 1. ACCESS search screen

5 5.3 ACCESS 223 Figure 2. ACCESS brief record screen example of a help screen). Help screens offer embedded menus (highlighted terms/ phrases) that allow users to get additional or related information with a simple touch. The reopening of the newly renovated and refurbished Main Reading Room and Computer Catalog Center (CCC) in the Library s Jefferson Building coincided with the full production release of ACCESS. Eighteen ACCESS workstations were installed in three bays of the CCC, along with 36 other terminals of varying types. All terminals communicate with the LC mainframe over a token ring connection. The construction of the workspace around the ACCESS workstations had been designed and finalized long before ACCESS was conceived. However, at installation, ergonomic considerations were made that resulted in adjustable chairs at each workspace, recessed incandescent lighting overhead, and table space for books and patron belongings. The touch panel is placed on the system unit and the printer is alongside. Because only six ACCESS workstations are installed per bay, there is a sense of space between them. Also, the placement of the ACCESS workstations closest to the entrance and the continual display of the colorful ACCESS logo were intended to attract patrons who may enter the CCC for the first time, thus allowing them to try using ACCESS on their own before asking a reference librarian for assistance.

6 224 Section 5: Public access Figure 3. ACCESS full bibliographic record screen Status and outcomes Patron response has been very positive. Comments are often made on the user friendliness and design of the system. Patrons who struggled with commanddriven SCORPIO and MUMS also comment about the ease of using ACCESS. ACCESS is a front-end for a large, existing system. In order to test the concept and feasibility of ACCESS, the more difficult implementation of Boolean searches was deferred in favor of single concept searches (e.g., a single author, a single subject heading, a single title, etc.). Since between 30% and 50% of all searches with online bibliographic systems (e.g., OPACs, Medline, etc.) result in no hits, and many of these are due to overspecification, the decision to defer Boolean may have unwittingly contributed to the system s success. From an implementation point of view, providing only single concept query support was easier and made query translation to the underlying system more direct, but reduced the searching power of the system. From the user s point of view, however, this approach has increased the user s chance of getting some hits in subject searches because over-specification is avoided. Furthermore, Library of Congress Subject headings were incorporated into the browse list of subject searches so that users see cross references that offer useful alternatives in subject searching. Users are given a button to select specific subject headings or to "Fast Forward" through records. To further assist users in

7 5.3 ACCESS 225 Figure 4. ACCESS subject headings screen specifying LC subject headings appropriate to their searches, the system offers alternatives from the LC thesaurus. (see Figure 6). ACCESS has dramatically changed the work at the LC for the reference staff on duty there. More time is available to develop search strategies for patrons and the mind-numbing days of repeating navigational commands over and over are only a memory. The staff is hoping to implement the ACCESS front end for other files in the library s SCORPIO system in early Work is progressing on adding other search capabilities for the book files, including the ability to request books directly through ACCESS. Many of the more specialized reading rooms at the library have recognized the success of ACCESS and work is progressing on a Spanish language prototype for the Hispanic Reading Room. The Newspaper and Current Periodical Reading Room is planning to install ACCESS soon. Summary and discussion The success of the ACCESS project was based on three principles. First, this was a team effort. Systems staff, reference staff, technical processing staff, and the HCIL team invested time to understand their respective perspectives. This team effort was made possible by strong yet supportive leadership in the LC teams and the shared experience of the seminars and meetings.

8 226 Section 5: Public access Figure 5. ACCESS alternative subject headings screen Second, success is due to attention to solid human-computer interaction design principles. Specific to this project were: 1. user needs were considered from the start; 2. a direct manipulation interface was used; 3. consistency was maintained in screen displays, wording, selection mechanisms, and system feedback; 4. help was context-sensitive and under user control; and 5. design proceeded in an iterative fashion with systematic and constructive feedback. Third, the institution took the risk of implementing an innovative system and providing it as an alternative to the existing system. Providing an easy to use touchpanel interface met the needs of the many novice and casual users who visit the Library. Advanced users are still able to use the SCORPIO and MUMS systems that support Boolean queries, field specifications, and set combinations. This twosystem strategy has proven to be a prudent way to meet the needs of various users of the Library and freeing reference staff from many of the system assistance demands of the past.

9 227 References Borgman, C.L. (1986) Why are online catalogs hard to use? Lessons learned from information retrieval studies, Journal of the American Society for Information Science, Vol. 37, No. 6, Botafogo, R. (1990) Structural Analysis of Hypertexts, Masters Thesis, Department of Computer Science, University of Maryland, College Park, MD Brown, C. Marlin (1988). Human-Computer Interface Design Guidelines, Ablex, Norwood, NJ. Chin, J.P., Diehl, V.A., and Norman, K. (1988) Development of an instrument measuring user satisfaction of the human-computer Iinterface, Proceedings of the Conference on Human Factors in Computing Systems, CHI 90. Association for Computing Machinery, New York, Conklin, J. (1987) Hypertext: An introduction and survey, IEEE Computer Vol. 20, No. 9, Converse, S., et al. (1987) Where can I find? An evaluation of a computerized directory information system, (Unpublished), Department of Psychology, Old Dominion University, Norfolk, VA Grudin, J. (Oct. 1989) The Case Against User Interface Consistency, Communications of the ACM, Vol. 32, No. 10, Grudin, J. (Jan. 1992) Consistency, Standards, and Formal Approaches to Interface Development and Evaluation: A Note on Wiecha, Bennett, Boies, Gould, and Greene, ACM Transactions of Information Systems, Vol. 10, No. 1, Hildreth, C. (1982) Online Public Access Catalogs: The User Interface, Dublin, OH: OCLC. Hoadley, E. (Feb. 1990) Investigating the Effects of Color, Communications of the ACM, Vol. 33, No. 2, Holum, K. (1988) Reliving King s Herod s Dream, Archaeology, May/June 88, Holum, K., Hohlfelder, R., Bull, R., Raban, A. (1988) King Herod s Dream - Caesarea on the sea, W.W. Norton & Company, New York. Kearsley, G. (1993). Public Access Computer Systems, Ablex, Norwood, NJ. Kellogg, W. (1989) The Dimensions of Consistency, in Nielsen, Jakob (editor) Coordinating User Interfaces for Consistency, Academic Press, San Diego, Lewis, C., Polson, P., Wharton, C., and Rieman, J. (1990) Testing a Walkthrough Methodology for Theory-Based Design of Walk-Up-and-Use Interfaces, Proc. of the Conference on Human Factors in Computing Systems, CHI 90. Association for Computing Machinery,

10 228 Section 5: Public access References New York Marcus, A. (Nov. 1986) The Ten Commandments of Color: a Tutorial, Computer Graphics Today, Vol. 3, No. 11, Marchionini, G., Shneiderman, B. (1988) Finding facts vs. browsing knowledge in hypertext systems, IEEE Computer Vol. 21, No. 1, Nielsen, J. (1989) Executive Summary: Coordinating User Interfaces for Consistency, in Nielsen, Jakob (editor), Coordinating User Interfaces for Consistency, Academic Press, San Diego, 1-7. Plaisant, C. (1991) Guide to Opportunities in Volunteer Archaeology: case study of the use of a hypertext system in a museum exhibit, Hypertext/Hypermedia Handbook, Berk, E. & Devlin, J., Eds., McGraw-Hill Publ., New York, NY Potter, R., Shneiderman, B., Weldon, L. (1988) Improving the accuracy of touch-screens: an experimental evaluation of three strategies, Proc. of the Conference on Human Factors in Computing Systems, ACM SIGCHI, New York, Reisner, P (1990) What is Inconsistency? Proceedings of the IFIP Third International Conference on Human-Computer Interaction, Interact 90. Elsevier Science Publishers B.V., North-Holland, Shneiderman, B. (1987) User interface design for the Hyperties electronic encyclopedia, Proc. Hypertext '87 Workshop, University of North Carolina, Department of Computer Science, Raleigh, NC, Shneiderman, B., Kearsley, G. (1989) Hypertext Hands-On!, Addison-Wesley Publ., Reading, MA, 192 pages + 2 PC disks. Shneiderman, B., Brethauer, D., Plaisant, C., Potter, R. (May 1989) Evaluating three museum installations of a hypertext, Journal of the American Society for Information Science, Vol. 40, No. 3, Shneiderman, B. (1992) Designing the User Interface: Strategies for Effective Human- Computer Interaction, second edition, Addison-Wesley, Reading, MA,. Smith, S., and Mosier, J. (1986). Guidelines for Designing User Interface Software. Report ESD-TR Electronic Systems Division, The Mitre Corporation, Bedford, MA. Wang, X., Liebscher, P., Marchionini, G. (1988) Improving information seeking performance in Hypertext: roles of display format and search strategy. Tech. Report No. CAR-TR-353 CS-TR-2006., Human-Computer Interaction Laboratory: University of Maryland, College Park. Wiecha, C., Bennett, W., Boies, S., Gould, J., and Greene, S. (July 1990) ITS: A tool for rapidly developing interactive applications, ACM Transactions of Information Systems, Vol. 8, No. 3, Wiecha, C. (Jan. 1992) ITS and user interface consistency: A response to Grudin ACM Transactions of Information Systems, Vol. 10, No. 1, Young, D., and Shneiderman, B. (July 1989) Guidelines to designing an effective interface for the MicroAnatomy Visual Library System, unpublished research report, Human- Computer Interaction Laboratory, University of Maryland. Young, E., Walker, J. H. (1987) A case study of using a manual online, unpublished manuscript, Symbolics Corp, Cambridge, MA.