Comments on: Update on our Evergreen Migration

By: Jason Etheridge

Jason Etheridge — Fri, 08 Jul 2011 05:59:28 +0000

NP. Speed issues are generally addressable as well, via db tuning, good networking, etc. Though in the case of the Javascript-heavy OPAC (which has a lot to load prior to caching), there’s work on producing a slimmer Javascript-free/light alternative.

By: Brian Herzog

Brian Herzog — Fri, 08 Jul 2011 00:15:49 +0000

@Jason: thanks – it makes sense the volume level would be added on the fly, and any orphans would be cleaned out automatically. I’ve been trying to be better about monitoring the general and development Evergreen listservs, so hopefully more solutions like this are out there already. Thanks again.

By: Jason Etheridge

Jason Etheridge — Wed, 06 Jul 2011 04:29:47 +0000

The screen is optional and controlled by a library setting. Changing the call number in that unified interface will only affect the copies being edited. Behind the scenes it’s finding existing volumes to link to or creating new ones as needed. The downside is that the process can leave behind orphaned volumes which tend to annoy staff (though patrons never see them). There’s another setting in a development branch that will automatically delete such volumes.

By: Brian Herzog

Brian Herzog — Tue, 05 Jul 2011 19:56:14 +0000

@Jason: Thanks for the information. I ran your comment by my cataloger, and it kind of confused her. We do have a screen now (when we click Edit Volumes”) that allows us to edit the call number and barcode (and some other attributes) simultaneously. Perhaps this was written for the MVLC Evergreen and got adopted into the 2.1 code. But what my cataloger wasn’t sure of was if editing the call number at this level cascaded that change to all other copies attached to that volume, or if it was tied only to that barcode. I think it’ll take some testing on our part to really understand what effects different changes have.

By: Brian Herzog

Brian Herzog — Tue, 05 Jul 2011 19:50:33 +0000

@Heather B: I’m happy to hear you have a way to run reports – I don’t know why we don’t yet. I’ll certainly continue to post on our progress, but anything you can share from your year of experience is certainly welcome.

@Marnie: I think Eric was just before my time, and I’ve heard a lot about it. Thanks for your well-wishes – and as always, let us know how things work from the “patron” point of view.

@Ryan: Thank you – of course there’s a lot more besides this, be this post hits most of the major themes. I do hope it is helpful.

By: Ryan

Ryan — Tue, 05 Jul 2011 01:22:52 +0000

Great post on your migration experience Brian. Thanks for sharing…anyone migrating to a new ILS can learn so much from this overview.

By: Marnie

Marnie — Sat, 02 Jul 2011 17:01:41 +0000

Thanks, Brian for the overview of the migration. Just a couple of comments–
The report functions enjoyed by MVLC with Horizon was created by Eric Graham with the participation of staff members from member libraries who suggested and tested the reports over a number of months/years. Eric’s recognition that his customers were member libraries and library users made his work extremely valuable. MVLC also provided the option of having Central Site staff run reports if the local library staff lacked the time or expertise.
Training on a moving target must have been difficult. Since improvements can be made easily with OSS, I can see that training/communication will be a continuing issue.
Best wishes for productive development and contented library users and staff.

By: Heather B

Heather B — Sat, 02 Jul 2011 03:28:01 +0000

My library migrated to Evergreen last summer and I agree with a lot of your comments. The slowness especially we are finding frustrating. There is a reports module but it is pretty clunky; pretty much we have to get our tech services head to set up the reports for us to run because she is the only one who’s really been trained on that. But we have high hopes, as you do, that things will be much improved in a year.

I’ll be interested to hear about your library’s continuing adventures with Evergreen! Perhaps we can trade some tips.

By: Jason Etheridge

Jason Etheridge — Fri, 01 Jul 2011 04:31:03 +0000

Some good news is that EG 2.1 (which has a release candidate out) has a unified volume/item interface that abstracts some of the layers. So you can, for example, edit the call number for an item (or items, in batch) at the same time as other item attributes, instead of using the lovely “mark volume as item transfer destination” and “transfer items to volume” actions.

By: Cari

Cari — Thu, 30 Jun 2011 21:08:31 +0000

Very good post, Brian. Your Salem Press award is well-deserved. Congrats!!

The thing about “the system” – I’ve noticed this here too. We just got an overlay to Sirsi (Bibliocommons) for the public catalog, and our patrons think anything that’s wrong with their account is related to it. We should start calling it “the computer assumption.”

Some of these things look awful, especially the reporting problems. But if it’s open source, can you (or your consortium) fix these things with code? Sirsi has the volume/item level problem too. It’s annoying, but we deal with it. Call number issues are the biggest part of it.