[890] in ad-lib
Initial Feedback on GeoCat
daemon@ATHENA.MIT.EDU (Jo Lynne Byrd)
Wed Jun 21 08:01:44 1995
To: s.kendall@geac.com
Cc: ganderso@MIT.EDU, fleish@MIT.EDU, owens@MIT.EDU, ad-cat@MIT.EDU,
rschmidt@MIT.EDU, gathomas@MIT.EDU, zxu@MIT.EDU
Date: Wed, 21 Jun 1995 08:01:31 EDT
From: Jo Lynne Byrd <jbyrd@MIT.EDU>
Simon,
For the past three weeks, four members of MIT's cataloging staff
(with the assistance of Tom Owens) have been testing and "playing
intensively" with GeoCat. Greg Anderson had asked us to send you
some initial feedback before ALA.
Our general reaction is that GeoCat represents a dramatic leap
forward over the cataloging and editing capabilities available in
Advance. Navigating in the system, moving around within a
record, ease of editing, and record displays are all radically
improved. We did find it slow getting started (we were
constantly crashing it, and it took us awhile to figure out how
many of the functions worked), but the more we discovered about
how GeoCat works, the more we liked using it.
That being said, our task is to come up with suggestions for
improvement! What follows are our suggestions based on what we
have seen so far:
COMMENTS/SUGGESTIONS FOR IMPROVEMENT
1. Logic of the key combinations used to represent commands.
We feel that more consistency in assigning the key combinations
used for the various commands would greatly assist the cataloger.
For example, if ALT-DEL means "delete line," then we would expect
ALT-INS to mean "insert line"--rather than CTRL-INS. The various
combinations of CTRL, ALT, and the arrow keys to move around with
are extremely difficult to remember. Also, we don't find it
intuitive as to which commands are represented by function keys,
which by CTRL keys, and which by ALT and SHIFT keys.
2. Creating subfield delimiters.
We very much liked the ease of using the F4 key to create
subfield delimiters, but we couldn't figure out how to create a
subfield delimiter within the special boxes (such as when typing
a string in the strings box, or typing text in the search and
replace box). Would it be possible to retain the function key,
but also to define another combination of keys on the keyboard
which the cataloger could use to create subfield delimiters when
working in a box? (Or is there some special trick we didn't
discover that addresses this problem?)
3. Inserting a field.
We suggest using the "Enter" key to insert a field. Inserting a
field is such a common edit that clicking on the icon or using
the CTRL and INS keys seems inefficient. The "Enter" key is used
for this purpose in many other systems and so is intuitive (as
well as far easier to reach on the keyboard).
4. "Reorder."
Although it is convenient to be able to reorder the fields with
one click, "reorder" goes a little too far in that it places all
the 5XX and 6XX field in numerical order, which is contrary to
the cataloging rules. There should be a way to reorder the
fields which allows the cataloger to indicate the correct order
in the notes and subject headings areas.
5. "Copy for new."
We feel that this command might be enhanced if GeoCat reformatted
the record somewhat, taking out data which would be inappropriate
in the new record (e.g. control numbers, dates).
Additionally, it would be helpful to have a "Mark for transfer"
command, which would allow the cataloger to pre-select fields and
data from the existing record to appear in a new record.
6. Fixed data edit box.
The fixed data edit box is a convenient way to enter fixed field
data, but it should allow for entry of all the fixed field data.
Currently, for example, one cannot enter more than one value in
the "Contents" area through the edit box, and one cannot edit the
dates through the edit box.
7. Macros vs. strings.
We don't understand the distinction between macros and strings.
Why would we use one versus the other? We have successfully
created and replayed macros, but strings remain more a mystery to
us. We haven't been able to figure out the purpose of the
extension characters, or the point of creating a "select key" for
the string; the help screens didn't enlighten us. We have been
able to bring one of the previously existing strings into a
record, but the number of steps and clicks involved made the
process seem not worthwhile.
8. Validation/Marc error checking.
Is there a way to validate a bibligraphic record without saving
it? Clicking on "Marc Errors" didn't seem to do anything.
9. Automatic saving of records when the system crashes.
Since we have crashed GeoCat quite often, and always lose our
editing, this strikes us as a good feature to have!
10. Printing the compressed display.
When printing a record shown in compressed display on the screen,
the resulting print is in non-compressed mode. We would like to
be able to retain the compressed display in the print of the
record.
PROBLEMS PROBABLY DUE TO THE TEST NATURE OF GEOCAT
1. As mentioned above, we crash GeoCat a lot. Most often we
receive an "Overflow" error message. GeoCat usually crashes if
we attempt to have sessions with OCLC, the campus network, and
GeoCat running all at the same time.
2. GeoCat has been extremely slow.
3. GeoPac has been quite unstable. We frequently haven't been
able to get into most of the databases, and when we do, the
search results and displays are often faulty. "Push to GeoCat"
often doesn't work.
4. In GeoCat the cursor frequently freezes or disappears.
5. The cursor is often unresponsive to the mouse.
6. Printing a help screen throws one completely out of help.
- ----------------------------------------------------------------
We appreciate having the opportunity to make these comments, and
look forward to meeting with you when you come to MIT.
Jo Lynne Byrd
on behalf of the other Co-Development Group members:
Raymond Schmidt
Gordon Thomas
Amanda Xu
