[OPEN-ILS-GENERAL] What are your requirements for Evergreen?

[Deanna Frazee]

I agree that the ability to suspend holds is critical.  Having that
ability creates a win-win situation for the library and the patrons and,
generally, keeping people on both sides of the equation much happier.

Another thing I would like to see involves the process of placing holds
on materials.  Our current ILS (Horizon) allows item-level holds, but
when we turn that feature on, it makes item-level holds available on all
materials.  Unfortunately, this means that our users frequently choose
an item-level hold when what they really wanted was to reserve the next
available copy (a bib-level hold).  It would be wonderful if, during
cataloging, there was a way to designate whether or not item-level holds
were allowed on that particular record.  This way, when the record is
for a multi-volume title, the patron could indeed choose volume 3 and
know they were getting volume 3.  But if the record is for the latest
James Patterson (and there seems to be a new one every 2-3 months!),
then item-level holds could be turned off to make sure patrons would get
the next available copy.

Deanna Frazee
Killeen City Library System
(254) 501-8995
(254) 501-7704 (fax)
dfrazee at ci.killeen.tx.us
 
> -----Original Message-----
> From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-
> general-bounces at list.georgialibraries.org] On Behalf Of Mark Ellis
> Sent: Friday, February 01, 2008 1:23 PM
> To: open-ils-general at list.georgialibraries.org
> Subject: RE: [OPEN-ILS-GENERAL] What are your requirements for
Evergreen?
> 
> Dan,
> 
> Here are a few things we need:
> 
> 1. The ability to support Chinese (both simplfied and traditional) in
> the data and interface.  Your i18n efforts may make the latter just a
> matter of translation. Getting result sets sorted properly might not
be
> as straightforward.
> 
> 2. Shelf locations - (e.g. New Books Shelf)  Items with the same call
> number may be shelved in different locations within a branch--often
> temporarily.  This would appear as part of the item location where
> additional specificity is required. (e.g. MacDonald Branch - New Books
> Shelf)
> 
> 3. Hold postponement.  We didn't fully appreciate the utility of this
> feature until we lost it as a result of a migration and began to hear
> from patrons.  Not only do they use it to prevent holds from being
> trapped while they're on vacation, but it also allows them to manage
the
> rate at which they receive holds.  They can float on top of the hold
> queue until they've finished reading whatever they have in hand.  This
> contributes to faster turnarounds and more efficient use of the
> collection.
> 
> Mark Ellis
> Manager, Information Technology
> Richmond Public Library
> Richmond, BC
> (604) 231-6410
> www.yourlibrary.ca
> 
> -----Original Message-----
> From: open-ils-general-bounces at list.georgialibraries.org
> [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf
Of
> Dan Scott
> Sent: Tuesday, January 29, 2008 6:12 PM
> To: open-ils-general at list.georgialibraries.org
> Subject: [OPEN-ILS-GENERAL] What are your requirements for Evergreen?
> 
> I would like to start a discussion thread on the following subject, as
I
> believe it's incredibly important to the success of the project and I
> don't think we've had much discussion about it yet. Perhaps this
> discussion will also be able to feed into the Duke initiative to write
a
> design requirements document for an academic library system.
> 
> (Note that "Project Conifer" refers to the project to implement a
> consortial install of Evergreen for Laurentian University, McMaster
> University, and the University of Windsor.)
> 
> "What are the base requirements that have to be in place before we, as
> an academic library, or consortium of academic libraries, can migrate
to
> Evergreen?"
> 
> I'll kick off the discussion by giving an overview of the basic parts
of
> the library system (both functionality and "soft requirements" like
docs
> and training) and my understanding of where things are. Please feel
free
> to broaden beyond what I provide here, as I will undoubtedly forget or
> mangle some of these! I believe that the answers may differ for
> different institutions, of course.
> 
> An acquisitions system is a given for everyone, and we're currently
> working on that in the acq-experiment branch, as documented in
> http://open-ils.org/blog/?p=101 http://open-ils.org/blog/?p=108 and
> http://open-ils.org/blog/?p=115, as well as in the wiki at
> http://open-ils.org/dokuwiki/doku.php?id=scratchpad:acq_serials
> 
> A serials module is also a base requirement for everyone. On top of
the
> acquisitions portion (subscription support, vs. basic one-time
> purchases), at a basic level we need basic patterns (overlay calendars
> with exceptions), a helpful check-in interface, and claiming.
> 
> Academic reserves are another base requirement for each site.
> Essentially, give the system the ability to associate one or more
items
> with one or more courses (instructor, course name, course code) and,
by
> doing so, temporarily override the physical location of the item.
Longer
> term it would be nice to have integration with courseware (WebCT /
> Blackboard / Moodle / Sakai) so that the reserve items would
> automatically be displayed as part of the course list, and it would
also
> be nice if Evergreen could integrate with the campus academic system
to
> know what courses a student was registered in and display those
courses
> & reserve lists from the catalogue.
> 
> Internationalization (i18n). One facet of this (internationalization
of
> addresses to allow Canadian / American / arbitrary address formats
from
> around the world) affects everyone. BC has already been able to
> customize Evergreen to support Canadian addresses, so a basic level of
> support is there. However, Laurentian in particular requires pervasive
> bilingual support - which is one of the development pieces I'm
actively
> working towards. We hope to have this completed in the next few weeks;
> after that, we simply need to send off the strings to translation and
> our needs will be met. The new acquisitions system is being built to
be
> i18n-ready from the ground up.
> 
> Circulation: Are there circulation requirements beyond what Evergreen
> already offers today?
> 
> Cataloguing:
>   * We have added infrastructural support for being able to search
> multiple Z39.50 sources at once, which was one of the requirements
> voiced at the Conifer Acquisitions session.
>   * Equinox has stated a number of times that they would like to
rewrite
> the existing cataloguing client knowing what they do now. If our staff
> do not like the current cataloguing client, it might be possible to
use
> a third-party cataloguing client (OCLC Connexion Client, for example)
> instead.
>   * Authority control: there is some rudimentary authority control
built
> into Evergreen today.
>   * Bulk import of MARC records and authority records: the current
> interface for bulk imports of MARC records is the command line, which
is
> not particularly friendly when you face the need to import, say,
12,000
> records for a new set of Springer e-books.
> 
> Catalogue: Do we have requirements beyond surfacing new functionality
> like academic reserves, acquisition requests, etc in the catalogue?
> 
> Reporting: The current reporting module is extremely powerful, but it
> comes with no standard report templates. With that power comes a
certain
> amount of complexity (it is essentially a nice GUI wrapper around the
> relational schema of the database, so understanding relational
databases
> helps a lot) that means that our best approach for moving forward will
> probably be to define what standard report templates we want out of
the
> box, then assign someone or some people to create those templates.
> 
> Documentation and training: There is currently not much in the way of
> official (staff and librarian-oriented) documentation available for
> Evergreen. I started an effort to write "The Book of Evergreen", but
> that faltered when I turned my attention towards more basic
> infrastructure.
> 
> Data partitions: in a consortial environment, what is necessary in
terms
> of separating one Library's data from another's yet? For
> example: should a Laurentian acquisitions person be able to see
> McMaster's acquisition accounts and individual funds?
> 
> Migration of existing data: Apart from bib records / holdings / patron
> records / authority records and open transactions (for example, books
> that are currently checked out), what other data do we want to migrate
> - complete transaction records dating back as far as our existing
> systems allow? Or would we be satisfied just exporting a static set of
> statistics so that we can combine data from the live system with the
> statistics from the old system (for example: circ counts by barcode by
> year)? Either way, we will have to define what data we want to
migrate,
> then figure out how to migrate that into the new system.
> 
> --
> Dan Scott
> Laurentian University