Not a hero's journey

Years ago, I read this blog post decrying how painful it is to sit through conference presentations about library websites because - like Joseph Campbell's archetypal hero's journey - they are all the same. 

A library team, faced with recalcitrant adminstrators and skeptical colleagues, sets off, after producing the requisite usability studies that always seem to correspond magically to the team’s vision, to bring back the boon for the library.  In this genre of presentation, the boon can be found in Open Sourceville, on the other side of Scylla and Charybdis, and just to the right of Careeristan.

So yeah, after reading that, I've always found it difficult writing about my work on library web development without visions of Monty Python going through my head.

And yet.

After about a year of development, the Leddy Library's website launched on June 29, 2012. I'm the chair of the Leddy Library Web Team and I built much of the site's architecture using Drupal 7. Uh-oh, flashback! A quote from that post again...

The question remains: Do we need to hear the Drupal story again, or the one about a library redesign team’s victories over the forces of evil and technophobia?

Um, mebby?

These are the parts of my story that I think you might be useful to you, the reader. I will try not to write myself as the hero of this story, but I warn you that the archetype is strong and flattering and I am human and I need to be loved validated. You, dear reader, can judge me.

Building in stages

Our website is being built in stages. The first stage was just the A to Z list of our online resources. Months later, most of the rest the site was built upon that original list.

Building in stages was very good from a web development standpoint because it gave us the opportunity to build up our skills as we built our site. For example,  my colleague had the time to work on server responsiveness issues that cropped up with our A to Z list. Because she had the time to properly investigate our options and find an optimal solution,  we are now better prepared for the larger migration of stage two (our site is still slow now, but it will be hooked up to Varnish next week and so I'm confident that the pokeyness will be resolved).

Our third stage will involve increased complexity to our project and those planned features just wouldn't have been possible had we built everything as quickly as possible in one swell floop simply because they wouldn't have been in our skill set.

Oh, but there is a downside to this approach. Our second stage of our site doesn't current offer librarian subject guides because we haven't gotten our server permissions and workflow issues fully established yet for various technical reasons. If we could have had them ready by the deadline we were given, we would have done so. We hope to have them become available as soon as possible.

To say that my some of my librarian colleagues are concerned by their temporary absence would be an understatement. That's just of one problems behind the 'minimal viable product' mindset: there are different opinions of what makes up a 'minimal viable product'.

Autonomy v. Reliability

There is another archetype of librarian website presentations. Those are the "library websites suck and it's because librarians want to our users to be librarians" talks. I don't disagree with the sentiment, but I do think it's more complicated than that.

Establishing and enforcing usability guidelines means restricting the autonomy of the author (I prefer this term over 'content provider') to a certain extent. Workplace autonomy is incredibly important and so I think it's wrong to simply dismiss concerns about the terms of creation of work.

But...

Our previous website (b. 2005. d. 2012), was a collection of WYSIWYG pages running on Lotus Notes Domino. Whenever a library database's address changed, it was a member of the library web team (and many times that person was me), who had to manually change every instance of that url on the site to make it work again. Once, we had to change every link by hand because the address of our ez proxy resolver changed. Pages grew out of date. We had link rot.

Our new web site has one page for each online resource with a shortened url associated with a location that be changed once, off-site, using a YOURLs link server which captures traffic to each link as well.  The cost of this reliability is that pages need to constructed from lists of these pages in a formal way. Furthermore, the Web Team has decreed that such lists shall not exceed seven items.

In this case, I think that in this case usability concerns trump autonomy concerns. There is not a single study that suggests that long, undifferentiated lists of unfamiliar tradenames is good for our users.

But maybe that's because I am the hero of this story.

Good luck for your own quest for the Holy Grail. I'm still looking for ours.