An email list I’m on had a message come through today that was asking for advice on displaying holdings in the catalog when an item has more than one piece in more than one location. It closed with “Our librarians early on thought that having all the holdings locations appear in the brief display was confusing to our users. Now they are complaining that what we do now is misleading our users.”
My own library is looking to implement LibGuides, and to do it fast, as we’re under deadline pressure from the campus-wide revamp of the website, and anything we move to LibGuides (or intend to move) doesn’t have to be transferred to the new CMS. We’re having discussions about format, consistency, guidelines, and individuality, and we’re building a LibGuides framework as we discuss during each work session.
Both of these discussions speak to me about the ways that libraries have and have not — in my experience, mostly ‘have not’ — adopted a model of beta release. The institutions I’ve worked at have had a long history of not releasing a service out into the public view until it was ‘ready’, in which ‘ready’ meant ‘perfect’, and ‘perfect’ meant it’d been discussed, tested, discussed, tested more, modified, discussed, and tweaked within an inch of its life until it reached what the librarians felt was ‘perfect’, but without ever having the rubber hit the road with users.
I’m inferring that the catalog referenced in this morning’s email fits that scenario — it’s likely that they discussed, tested, decided, discussed, and then implemented, and now, several years later, having seen users interacting with the decisions they made, they’re looking to make changes.
Our LibGuides implementation, I hope, will be more of a modern beta-test rollout. We’re making some basic decisions, setting up the framework, and then we’re going to go live on our website for fall semester. We’ll adjust it as we go, learning about the system and our users and how the two interact and making changes as appropriate. We’re not going to wait several years to identify all the problems and change them all at once in a big ‘we’re changing our guides; look out!’ project. Instead, what we’re proposing to each other is to observe, discuss, and act on perceived needs in a fluid workflow that I hope will be more responsive, more agile, and more user-focused, much like the changes made by many modern online services providers.
Academia changes slowly, and academic libraries are no different. But I think we’re starting to dip our toes into the beta pool, and I think that’s fantastic.