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

[Mike Rylander]

On Feb 1, 2008 2:22 PM, Mark Ellis <mark.ellis at yourlibrary.ca> wrote:
> 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.

Fortunately, we do have a plan for result set sorting.  I know it will
work for simplified Chinese, but I'm not sure about traditional.  The
plan is based on this* and the internationalization work that Dan and
I have been doing.

* http://www.fi.muni.cz/~adelton/l10n/.en

>
> 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)
>

This exists today under the the 'details' link by the call number, in
the column Location.  Perhaps that is not the optimal place for it?

> 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.
>

And this exists today in the 1.2 and development branches, and will be
in the first "official" release as of 1.2.2.

I'm glad we're on the right track (for many things), but it is
becoming obvious to me that we need better "marketing" ;) ... We need
to communicate more effectively what is already in the code and what's
planned.

Thanks, folks, for bringing up these points, and thank you Dan for
starting the thread!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com


> 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
>
>