‘perfect’ versus beta

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.


  1. I agree. Have you planned how you will learn how the users interact with the system? Usability tests, surveys, or more with data from LibGuides and web logs? I’m frustrated that we can’t see more about how people actually use many of our online resources.


  2. We’re still working that out; we want to see what LibGuides gives in native stats, and then we’ll figure out what we think we’re missing, and go from there. Another part of the process that’s going to evolve, I think. 🙂

    Personally, I would love to do a broad survey about our online resource use, and then some targeted usability studies, but… staffing. funding. priorities. We’ll see.


  3. Live in perpetual beta. The facade of “it’s ready” or “it’s perfect” is something your users see through. Nothing is ever “done”. 80% of Google’s “services” are Beta including Maps, Gmail, etc. – used by bajillions of people daily.

    Live. In. Beta. 🙂


  4. The Google argument sends some librarians all-a-twitchy, but it’s one I use. The commercial services that our users are comfortable with are in perpetual beta — so why can’t we try it, too?

    I’m adding “Live in beta” to the Wall O’ Messages in my office. When I someday have an office again.


  5. I definitely would like to live in beta more. I get so tired of putting things out and getting screamed at because it’s not “perfect”. There are actually people where I work that want to learn how some new product works for the sake of the patrons but without actually having to use it – so heaven forfend if it dares to change!


  6. We’re in the same position at my library — converting to LibGuides in the face of a new CMS. We’ve had LibGuides (http://uiuc.libguides.com/) for almost a year now and the biggest tip I can offer you is about training (http://uiuc-training.libguides.com/libguides): when showing your librarians how to create their LibGuides, make sure they understand the difference between a Rich Text box and a Web Links box! I’m finding now that a lot of our content – full of links – has been put in Rich Text boxes, which don’t track the statistics of links users click on.
    Speaking of statistics, I found it useful to supplement the native LibGuides reports with a little help from SiteMeter – which gave me referring URLs and lets me get a sense of how many visits are on-campus vs. off-campus. Hope this helps!


  7. To clarify — a lot of folks here are using *both* the CMS and LibGuides, with LibGuides primarily serving the purpose of class guide or subject guide and the CMS still serving as the department library webpages. I think as people get more familiar with each system, they’re finding a good balance between the two.


Leave a Reply to GeekChic Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s