[497] in Public-Access_Computer_Systems_Forum
OPAC Functionality
daemon@ATHENA.MIT.EDU (Public-Access Computer Systems For)
Wed Jun 17 12:09:12 1992
Date: Wed, 17 Jun 1992 11:04:21 CDT
Reply-To: Public-Access Computer Systems Forum <PACS-L%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
From: Public-Access Computer Systems Forum <LIBPACS%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
To: Multiple recipients of list PACS-L <PACS-L%UHUPVM1.BITNET@RICEVM1.RICE.EDU>
4 Messages, 140 Lines
*-----
From: "Clyde W. Grotophorst" <WALLYG%fen1.gmu.edu@gmuvax2.gmu.edu>
Subject: Re: OPAC Funtionality
I'm usually not one for listserv think pieces but the thread
of the OPAC functionality discussion seemed to be kinda one-
dimensional so I started imagining what I'd like to see...
I'm ready to bet the next generation of OPACs will be virtual--
they'll 'exist' only during a particular use and they won't look
the same to any two users. Instead, an ever expanding collection of
information servers (computers handling local databases) will be
linked by networks to provide the user with the comforting illusion
of a single system.
Most activity on this system will be initiated outside the
library's walls. Freed at last from meetings about where
terminals should be placed and endless debates over the
efficacy of help screen text, library systems staff will
fret instead over whether sufficient local node resources
are available to support the drop-in user and his pocket
interface unit. There may still be a few terminals for public
use, but they'll be like the library's newspaper--there for the
few folks who either didn't buy one or forgot to bring it with
them to the library. Your computer will sign on to this OPAC.
Users will determine the interface. Vendors will offer a variety
of personal information management packages for these little
computers and most users will use a personally designed/customized
interface. Queries, created on the personal unit will be uploaded to
the library's local processor, parsed apart and sent to various
remote hosts. Responses will be collated, and either immediately
(or at some later time--depending on how many people are still using
NREN to write long messages like this) relayed back to the pocket
unit.
After leaving the library, the results of this OPAC session
will be transferred to the home or office workstation for
subsequent work.
We're probably still a generation away from this sort of system
(which would require a more robust networking environment that
the Internet provides, and a marketplace that adheres to at least
some minimum interoperability standards), but there are several
examples around today point the way toward this future.
Consider CompuServe...while certainly not an OPAC, it does today
offer a glimpse of how such an OPAC might work. [Note: if you
haven't used CompuServe in a few years, be advised that it has
evolved into a very information-rich environment. Of course,
you have to be rich to fully explore it but that's another
matter...]
While CompuServe does provide an interactive mode for callers
(where you respond to menus and enter commands--not unlike today's
OPAC), increasingly CIS users are using software packages like
OzCIS to compose their queries, messages, file requests,
and so on offline, then letting that package dial CIS, sweep
automatically through the hundreds of possible destinations
collecting messages, replies, files, listings, or whatever,
then automatically logging off. Take this model, add thousands
of library systems around the world and you can begin to get a
sense of where it might lead.
*================================================================
Clyde W. Grotophorst Library Systems Office Fenwick Library
George Mason Univ 4400 University Drive Fairfax, VA 22030
Voice: (703) 993-2239 wallyg@fen1.gmu.edu BBS:(703) 993-2219
*========
From: "Tim Kambitsch, Butler University Libraries" <KAMBITSCH@BUTLERU.BITNET>
Subject: Re: OPAC Funtionality
On the top of my priorities for the next generation online catalogs is
"choice of desktop platforms". By this I mean I want to make a personal
choice as to the software I use to search my local online catalog, or even
remote catalogs in the same way I can choose what word processor I prefer to
use. I believe the technology and the market are moving in this
direction.
To illustrate, I would like to see Z39.50, WAIS, or some replacement standard
implemented within a searching package I can load onto my Macintosh. I really
don't want to be tied to VT emulation just because my database vendor
developed its software on a VAX.
A cataloger in the office next door might prefer a Windows implementation.
A third person in my office might prefer a Macintosh program different
than the one I choose. Getting away from dumb terminals for Public Access
Catalog stations is a step in this direction.
This means that the local systems/database vendors have either get into the
development of variant client software modules, or follow some standards that
enable others to develop them.
Tim Kambitsch Phone: 317-283-9949
Associate Director for Systems kambitsch@butleru.bitnet
Butler University Libraries "Any sufficiently advanced technology
4600 Sunset Avenue is virtually indistinguishable
Indianapolis IN 46208 from magic." -- A.C. Clarke
*-----
From: jaffe@ucscm.UCSC.EDU (Lee Jaffe, McHenry Library, UC Santa Cruz,
408/459-3297)
Subject: Re: OPAC Funtionality
In terms of customizing/personalizing interfaces, this is the
direction of computing in general, but this is not going to
be taking place at the central host. The move is towards a
client/server model. In this scenario, a smaller, local server
would play the role of agent (a la Knowledge Navigator) and
would hold a lot of personal information about you and would
also know about other information servers. In this way, you
would have a single interface, designed around your needs for
retrieving information from a variety of different sources.
A second tier approach, for people without a client/server
environment, would be to provide a wider range of settings that
could be customized for the session. Ideally, these could be
saved for future sessions. Since these are public access systems,
privacy could be maintained by allowing use of aliases. This
brings up an interesting point. Up till now, the only time you
needed to identify yourself at the library is when you actually
check items out. Our public library's catalog has gone online
and they ask for your card number. I think that librarians would
want to avoid taking identifying information except when abso-
lutely necessary.
-- Lee Jaffe
*-----
From: LYNCH@jade.bucknell.edu
Subject: RE: OPAC Funtionality
>Dirk Herr-Hoyman says:
>We MUST get away from a command line, terminal type of interface. Touch
>screens, like you see in mall kiosks, or light pens come to mind as far
>better interfaces.
Hang on a second, here. I personally hate touch screens and especially
light pens. I much prefer a command line interface. As Millard Johnson
suggested here, why not have the interface be tailored to the user?
Why not have touch screens for some folks, voice activated for others
(e.g. blind or handicapped), point and shoot for gui afficionados,
and command lines for folks like me?
Mike Lynch
LYNCH@BUCKNELL.EDU
