LOGON PLEASE:

The first week back from winter break was a short one. I was unsure about whether to hold my regular Friday morning meeting with my group, but they came prepared and a mini hackathon ensued!

To be clear, I don’t supervise programmers; my group is entirely catalogers.

The Problem

We recently upgraded to Voyager 8.2.0 and were excited about the rumors of finally being able to print item records. This isn’t something that came up often, but I occasionally heard grumbling like “Why can’t I print out this list of item records without taking a bunch of screen shots?” or “Why can’t I resize the window or the font?” Hooray for upgrades!

The Feature

The actual “print items” feature was not exactly what we imagined. From the Get Items screen, you can select (highlight) items from the list and click the Print Selected button:

This does two things that are not ideal: it uses all of the fields in the item record (Price, whether it is magnetic media, etc.) AND sends the data directly to the printer:

With some fancy footwork (setting your printer to Adobe PDF) you could get this data as a PDF instead of a paper copy. This is at least searchable. With some fancier footwork still (editing catalog.ini) you could configure which fields are included and which fonts they are printed in, but this was difficult to test on my system (ini file was read-only), and unlikely to produce exactly what we had in mind: a compact functional version of the item list for a mfhd.

Hackathon!

After the meeting, we re-convened at my desk. We examined the current behavior of Voyager and scribbled on offending printouts. I mocked up a web page that mirrored the Get Items list, which we referred to while deciding which fields to keep and which new ones to add. We printed out drafts, and realized we also needed space to write notes while comparing the item list to the physical collection on the shelf. With these parameters decided, my group went back to their own desks to do their regular work while I fleshed out and documented the code. The whole thing took a few hours, and we have a new tool in our cataloging arsenal. It is available as open source code on github, so others are welcome to use/modify it as well.

The program in action on my catalog: Journal of algebra

A Trend

While browsing the schedule for ALA Midwinter 2013, I noticed the Role of the Professional in Technical Services Interest Group. I will unfortunately miss that session (I am speaking at a concurrent session, Preservation Administrators Interest Group) but the question suggested by its name could in part be answered by the sort of project my group and I did that Friday. Companies writing catalog software are adding new features all the time, but do we really need to wait for a critical mass of customers (or priority from our own Library IT department) to get such a simple thing that improves our workflows? Who better to know the needs of our catalogers than someone actually working in technical services? Who better to abstract and implement them just so than professional librarians with those same needs but a broader perspective?

My plan

I learned in a management class that the job of a manager is to get work done through other people. This means delegating work when possible, and removing obstacles to getting that work done. If I can additionally help speed up that work, and make it more pleasant and less error-prone, all the better.

This year, my plan is to write one short, useful, self-contained program each week that improves tech services processes at my library. I will document it and release it under an open source license (CC-BY-SA). I have already been coding up thingies at this rate, so I am a little behind on the blogging, but I’ll catch up. If JoCo can do a Thing a Week (and a song, even!), why can’t I do it with code?