Message-Id: <5.1.0.14.0.20010621101143.023afbb0@pop.wfu.edu> Date: Thu, 21 Jun 2001 12:50:57 -0400 From: Alan Keely <keely@wfu.edu> Subject: Re: Law-VUG enhancements; time to speak up and act !!!
Regarding the Melody's list:
1) I agree with the need for fuller implementation of the MARC
holdings format, but I think some of the problems we have are not
necessarily related to the Voyager implementation, or lack thereof, but to
the inherent problems with the MARC format itself. For example,
a recent discussion paper 2001-DP07 discusses the relationship between the
844 field and the 654/864 and 855/866 subfield o. It makes for very
interesting reading and does a good job of describing the problems. If we
ask for the subfield "o" to display, one problem that would not be
resolved, as in the Mertens example, is the how to handle situations where
there are two or more "basic" active patterns.
My concern two fold. First, there are two issues that Endeavor must
address-- issues regarding format interpretation and the OPAC display
issues. At present, there appears to be alot of activity surrounding the
MARC format regarding these aforementioned data elements. This puts
Endeavor in a odd situation that if they go ahead and resolve the
issues, the potential exists that the implemented solution would not be
in compliance with the MARC format. As for the display issues, as
suggested by the Serials group problem statement and this proposal, I can
see Endeavor looking at this one a saying all they want is to display the
component title in the OPAC which would be a problem for some libraries
that have resorted to various schemes to get around the field length
limitation. I, for one, would not want the component name to display in
the OPAC. I would much rather see the subfield o display, but even that is
fraught with problems at this point.
Maybe the best course of action would be to add our collective
voice to the "serials enhancement committee" problem statement and
encourage the development of a more detailed specification of what is
needed by Endeavor in close consultation with the User community.
2) Display controls at the component level:
This would be very helpful as everyone who has to deal with
newspapers and other dailies knows. I would like to add to this the
capability of having a default setting for "Do Not display in OPAC." We
check in our replacement volumes, reporter volumes, etc. so we have a
record and we're always having to turn the displays off after we update
the MFHD.
3) Check in call number label without editing. YES! YES! YES! Our
checkin folks have to edit every label they print because Voyager isn't
smart enough to remember how a label should be formatted. Surly, Endeavor
could design the format algorithm that could correctly interpret an LC or
dewey call number and format for printing.
TO this one I'd also like to add the following:
In the 2000.1.3 ACQ client, when the client seems to set a printer
variable when the print label screen that display what is to be printed is
pressed. you then format the label then press another "print label"
button. I suggest that Endeavor have the system set the printer variable
when the second "print label" button is pressed not the first. This same
things seems to occur wen printing route slips.
If you only have one local printer attached it isn't a real problem. If
you have two, as we do-- label printer, route slip printer, it can cause
real problems if the print job is not directed to the right printer.
4) A new item which hasn't surfaced anywhere that I'm aware of, but has
really been bugging me. The other day I received a response from Endeavor
to a help request: I quote part of it below:
>We have an internal severity and data risk rating which helps us
>determine the immediacy of the problem. The severity is based on how
>many sites have reported the problem, and the
>impact that this problem has on your workflow. The data risk is set
>based on the risk of data corruption to the database. These two factors are
>considered when making decisions about whether the bug fix will be
>included in a patch or in the next release.
No where mentioned in this statement is anything regarding the affect the
"bug" might have on users, i.e. the library patron, of the system. While
some bugs have virtually no impact on technical services workflow, they may
have a significant impact on the OPAC user. In this particular instance,
the bug dealt with the display of coded pairs for holdings, many of which
have been rendered unintelligible by this bug. In my opinion, this makes
this bug a major problem. IMHO Endeavor should revisit how it establishes
levels of severity and consider the impact on the end user, as well as
staff and workflow.
5) Webvoyage enhancements: with all the new changes with the interface, I
would like to suggest that Endeavor allow for the hooking in of
additional scripts to provide additional functionality. For example, we
just brought up a new books script by Michael Doran of the University of
Texas at Arlington. The script displays a page that mimics
webvoyage. What would be nice is if the software provided hooks in the
OPAC.ini file for the inclusion of extra tabs. If you wish to see what
our's looks like,
the URL is: http:/pcl.wfu.edu/cgi-bin/newbooks.cgi I can envision
many other ways to use this capability.
I think this is enough for now. I apologize for rambling on. I'm looking
forward to seeing everyone in Minneapolis.
Alan Keely
**************************************
Alan Keely
Technology Services Librarian (Voice) (336) 758-4682
Professional Center Library (FAX) (336) 758-4508
Wake Forest University
P.O. Box 7206, Reynolda Station
Winston-Salem, N.C. 27109-7206 email: keely@wfu.edu
dkeely@law.wfu.edu
GO DEACS! GO DEACS!
.