[652] in Public-Access_Computer_Systems_Forum
RE: Third Generation OPAC
daemon@ATHENA.MIT.EDU (Charles Hildreth)
Wed Jul 1 12:35:58 1992
Date: Wed, 1 Jul 1992 11:27:00 CDT
Reply-To: Public-Access Computer Systems Forum <PACS-L%UHUPVM1.BITNET@mitvma.mit.edu>
From: Charles Hildreth <hildreth@eagle.sangamon.edu>
To: Multiple recipients of list PACS-L <PACS-L%UHUPVM1.BITNET@mitvma.mit.edu>
In-Reply-To: from "KINGH%SNYSYRV1.BitNet@pucc.PRINCETON.EDU" at Jun 30,
----------------------------Original message----------------------------
Regarding 3rd generation OPACs, Hannah King writes (30 June 1992):
> Sometimes I feel that it is the hardware and software designers and
> programmers who are directing our attention. They create some new bell and
> whistle and immediately we try to find a use for the bell or whistle. But
> what might be more useful is to direct these designers and programmers with
> information as to the needs, the limitations, the goals, the work of our
users.
I agree with Hannah that OPAC/IR system design should be driven and guided by
knowledge acquired through broad experience and research into user needs,
preferences and behavior. However, I cannot fault the often innovative
designers of bells and whistles. One generation's bells and whistles often
become the next generation's requirements.
Communicating what we have learned about user needs and behavior is a two-way
street. System designers must be willing to read, listen and learn (most are
willing), and those who choose to represent users and their needs must
communicate effectively with the designers, and, yes, even the programmers.
I have found that most systems folk are quite willing to listen if approached
in a supportive manner (not confrontationally) and if the message is based
on research, or at least more than one person's opinion. Actually, most
designers want to learn about the prospective users of their systems, but
not the "user" as filtered to them through some intermediary. In short,
present the data/findings and let the data/findings speak for themselves.
> And we should be certain that our users are not going to be confronted by
> a "gee whiz" system when all they want to know is does this library have
> this book and is it available for circulation.
OK, but we must be aware that a fair amount of research has shown that this
search need/task - the classic specific, known-item search - represents
only a minority of search tasks brought to the online catalog. In retrieval
experiments I have conducted, in the pre-search questionnaire I ask: "When
you use the library's catalog, how often do you know in advance precisely
which books you want?" The response categories are: Always, Most of the time,
Half the time, Seldom, Never. Seldom and Never consistently account for about
75 percent of the replies. When asked, "When using a library's catalog do you
most often look up: a. one or more specific books you know about, or b. any
publication that may have information on a specific topic or subject area?"
Uncannily, response b. is ticked about 75 percent of the time. (Subjects
have been university students, both undergrad and grad., and from a wide
variety of majors.) And we thought one time that univ. students were given
assigned/suggested reading lists!
An OPAC for all users would be a fine accomplishment. But as we proceed
incrementally, and even occasionally make a giant leap forward, we must be
careful of "sub-optimizing" design for the minority case.
A final note: most system designers and programmers would love - in fact
they itch - to do the "right" thing. Those working in the camps of many
vendors simply are not permitted to. All too typically they are taken off
R&D activities and assigned to system maintenance tasks. Money speaks, even
what little we have. Don't buy from such vendors (it's not hard to find out).
Let's help them learn what they need to know and push them forward. Carpe Diem.
Charles Hildreth
READ Ltd.
hildreth@eagle.sangamon.edu
