+ Page 28 + ----------------------------------------------------------------- Casting the Net ----------------------------------------------------------------- ----------------------------------------------------------------- Caplan, Priscilla. "A User's-eye View of the OPAC." The Public- Access Computer Systems Review 5, no. 7 (1994): 28-33. To retrieve this file, use the following URL: gopher:// info.lib.uh.edu:70/00/articles/e-journals/uhlibrary/pacsreview/ v5/n7/caplan.5n7. Or, send the following e-mail message to listserv@uhupvm1.uh.edu: GET CAPLAN PRV5N7 F=MAIL. ----------------------------------------------------------------- My academic library is in the market for a new integrated library system. As part of this process we've done all the usual things, including drawing up wish lists of desirable OPAC features and using them to evaluate numerous systems. We've also taken two far more interesting steps. First, we actually asked the faculty what they thought were important features to have in an online catalog. (This was suggested by a faculty member.) Second, on three separate occasions we set up "demonstration stations"--terminals in the library connected to two or more of the systems under consideration--for hands-on use by faculty and students. Some of the systems were graphical, some character based. In some cases, we showed two versions of the same system. We provided comment sheets for signed or anonymous remarks, and staff were available nearby to give help or take reactions. We got a lot of input. The results probably won't be turned into a major motion picture anytime soon, but they aren't without interest either. Here are several lessons I've drawn from this experience. And no, I'm not naming names; if you think you can identify a sinning or virtuous system, keep it to yourself. Warp Speed, Mr. Sulu Vendors take note: if the academic community were in charge of selection, the race would go to the swiftest. The most frequently repeated positive comments recorded in six weeks of demonstration stations were in praise of fast response times. The most frequent negative remarks concerned slow response times. Forget the bells and whistles, just grease the wheels. + Page 29 + Eek a Mouse "Prefer keyboard to mouse." "Personally, I hate using a mouse and find it far more trouble than it's worth." There were numerous comments along these lines, including my favorite: "I worry about old profs using the mouse." This leads me to several thoughts. First, it's a mistake to assume that everyone knows how to use the rodent or sees any virtue in becoming mouse-literate. We have DOS-based machines that won't be upgraded for years. We have hundreds of students doing everything from e-mail to serious computation via command-line prompts on central UNIX clusters. We have old profs. Second, mice are troublesome. They have a tendency to walk out the front door if not secured. They take up valuable counter space and work poorly on most surfaces. The obvious solution is to use keyboards with built-in trackballs for in-library OPAC stations. However, this aggravates the first problem: how many of us are handy with a trackball? Third, it is a great step backwards to force patrons to switch from keyboard to mouse with great regularity. A fact of life: you can't type a search string without the keyboard. Why should you be forced to also point-and-click to select an index, to position the cursor for data entry, or to perform any other adjunct to our most common of functions, the OPAC search? Here's the moral of this story: a graphical interface should not require a mouse. It should allow a mouse, and it should be designed to capitalize on those areas where pointing, clicking, and dragging really are superior ways of communicating human intentions to a small square box. But mouse commands should have keyboard equivalents, and basic acts like entering a search should not require hand movement from the keyboard to the mouse pad. They Don't Do Windows One might expect that patrons would prefer any graphical user interface to a terminal-based or character interface, if for no other reason than a GUI seems so much more modern. Not so in our experience. Of all the OPACs we demonstrated, two systems from two different vendors received the largest number of positive responses; one was graphical and the other character-based. What they had in common was the general feeling that they were "easy to use." + Page 30 + The general feeling about Microsoft Windows interfaces is that they can be particularly difficult to use. Developers need to remember that human beings are not born with an innate knowledge of Windows, and that Windows conventions are not intuitively obvious to the uninitiated. An interface that will go to great lengths to explain catalog-related functions ("Author search: enter words from author's name") may assume that patrons know how to use a scroll bar or close a window. Some GUIs let you move and minimize windows, not anticipating the unhappy scenario when one patron minimizes the search window and the next patron walks up to a totally unfamiliar screen. Developers should also remember that icons are memory aids for functions that people are already aware of. They don't substitute for help, mnemonics, or textual explanations of available functions. If words like "search" or "next" can fit on a button, they are likely to be more illuminating to the average patron than the picture of a magnifying glass or a left arrow. Until we have a common command language for icons, let's give the user a break and assume that one word is worth a thousand pictures. Strength of Character As noted above, character-based interfaces were not universally scorned. Nonetheless, our users were quick to differentiate the good from the bad and the ugly. People liked not having to press the Enter key when selecting from limited choices on a menu (a feature possible in UNIX systems that 3270-type transmission doesn't allow). They liked long, clear prompts at the bottom of the screen, such as "Show items with the same subject" and "Limit this search," even if it meant that an "Other options" prompt was needed for additional choices that didn't fit on one page. Users did not like having to move the cursor around the screen to highlight and select menu options. They did not like more than one way of doing something or when it was not clear how to do something (e.g., type first letter of option or move cursor to option and press enter). They did like having all data entry on a single command line. Users did not like having to return to a search options menu by requesting "new search" or "another search" in order to type a new search. They didn't see why they couldn't have a command line on each screen from which they could enter searches. On the other hand, users didn't seem to mind having to go through several layers of menus to do something special, like limit a search result set, while library staff rebelled against those hierarchies. Patrons seemed more concerned that directions for out-of-the-ordinary actions be clear than that they be quick or streamlined. + Page 31 + It's All in a Name Almost every system we evaluated had a feature to allow a user to easily issue searches related to a given work. That is, once users found a relevant catalog record, the system let them search the added entries, tracings, and/or call numbers from that record without rekeying. In most systems, this option was called "related works" or something of that sort, and selecting it would take patrons to a screen listing authors, subjects, series, and call numbers. When the user chose a heading or call number, the system would automatically perform the search. Nobody commented on this capability, positively or negatively, for any of these systems. In one OPAC, an option was limited to call numbers and was called "show items nearby on shelf." More than a dozen people commented. "Browsing what's nearby on the shelf is a very convenient feature." "'Show items nearby on shelf' speeds research and makes this choice number 1." Go figure. Take It to the Limit We sent a questionnaire to faculty and library staff asking them to rate the importance of various OPAC features and tabulated the responses of each group separately. The widest difference in opinion concerned the value of search limits by language, location, and material type, and the value of call number browsing. Library staff rated all these features as highly desirable, while the faculty weren't particularly interested. Search limits by material type ranked lowest of all the features we inquired about. (The ability to limit retrievals by date, on the other hand, was widely desired.) As a general rule, library staff rated almost all features closer to the "very important" end of the scale than the faculty did. The single feature most important to faculty was network access, followed closely by modem access. We have to face it: the faculty's main goal is to stay away from the library. One implication is that we won't be able to provide much personalized instruction and on-the-spot assistance. Perhaps it is no coincidence that the feature the faculty ranked second highest was "adequate online help, both contextual and explicitly requestable." + Page 32 + Power to the Patron Patrons want empowerment--all sorts of empowerment. They want to be able to designate any record or set of records and download it, or print it, or e-mail it to themselves. They want to issue holds and recalls for material that's charged out to others and renew materials charged out to themselves. They want to view their own patron records, fine records, and loan records. They want to be able to request that materials be delivered to them, ordered for them, and put on reserve for them. They want to be able to make comments and suggestions to the library. No negative comment was made about any patron empowerment function, except perhaps that it was not comprehensive enough, or didn't offer enough options. What do you mean I can't route this to my own network printer? That's All Folks Of course, we got a lot of other comments, many very useful, many very specific to the OPACs under consideration. Often people expressed completely opposite opinions. "I love Windows." "I hate Windows." "This system is great." "This system is awful." But behind almost all of the rants and the raves was the concept of ease of use. "I love Windows because it's easy." "This system is awful because it's hard." And even though it's true that to some extent ease of use is in the eye of the beholder, it was clear that all OPACs are not created equal. Since I assume nobody actually sits down to work and says, "Let's make this catalog hard to use," maybe we should all spend more time watching students and faculty at demonstration stations. About the Author Priscilla Caplan, Assistant Director for Library Systems, University of Chicago Library, 1100 E. 57th Street, Chicago, IL 60637. Internet: p-caplan@uchicago.edu. + Page 33 + ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on the Internet and on other computer networks. There is no subscription fee. To subscribe, send an e-mail message to listserv@uhupvm1.uh.edu that says: SUBSCRIBE PACS-P First Name Last Name. This article is Copyright (C) 1994 by Priscilla Caplan. All Rights Reserved. The Public-Access Computer Systems Review is Copyright (C) 1994 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. -----------------------------------------------------------------