Summertime is usually a quiet time in an academic library – except when during the year in which it’s been deemed that the library website needs a major overhaul. Then there is a team of library staff frantically hacking away as the September deadline lurches closer and closer.
I have been involved in such three library web redesign projects at MPOW over the years and have been meaning to write down some of the things that I think I have learned from the work before it becomes irrelevant. I want to qualify these statements as things I think I know because I can’t back up these statements with proper user testing. I am a huge advocate of re-iterative user testing but that’s not something that the web teams that I have belonged to have done enough of. I once received an email from a librarian who asked me what was the process by which our web team came up with the final design. I told her that we had frequent meetings and we argued a lot. She didn’t write me back. So much for honesty.
Since most academic libraries are more alike than different – they all tend to do the same things but just at different scales – it’s not surprising that most academic library websites tend to resemble each other. We are all trying to ‘solve’ the same problems and so it should not be surprising that we come up with similar solutions. I’ve come to believe that there are only a small number of academic library website archetypes that result from the answers to some simple questions.
How Do We Fit Everything We Do On the Front Page?
Libraries do lots of things and, in general, they want all of the things that they do represented somewhere on the library’s front page (along with a sizable real estate dedicated to ‘library news’). If you want all your offerings represented on the front page, you have one of two choices: you have drop down or fly-out menus or you create categories where each service goes. If you opt for drop-down menus, the site tends to be made up of two or three columns of the most important text with the less important stuff in the menus. If you don't want these menus, then your site tends to run to four or five columns of text broken down into categories such as 'services' and 'resources'.
At MPOW, we also did something slightly different. We knew that we were restrained to two columns of text because of the web template of our university but we didn’t want to use drop-down or flyaway menus. So instead, we developed a philosophy that the main body of text on our website would be dedicated to services that we could foresee a student or researcher use every day: the library catalogue, our indexes, online journals, citation management, interlibrary loan (which, in an ideal world, would appear as a link in an index or library catalogue when a failed search occurred), booking a library computer, and book renewal (which admittedly doesn’t exactly fit the criteria of daily). Most everything else is found in the groups “About the Library”, “Research Help”, “Computer Help”, and “Writing Help”. The benefit of using this approach is that you are less likely to screw up the major deliverables that your website is supposed to provide. But there is a cost – some things do become lost.
The Search for Search
When we designed our library’s website, we thought that our sitemap would be the answer to the problem of our hidden content. But since then I have come to realize that the average user doesn’t look for a site map and have noticed that site maps are now becoming scarce in the rest of the online world. We have a link to a ‘search this site’ page but even though it has prime real estate on the front page – it is rarely used. Why? My hunch is that is that if users don’t see a search box on a web page, they will assume that no search function exists and won’t look elsewhere on the page for this. At the time of the re-design, we didn’t want to put a search box on our front page because we knew from experience that user will gravitate to it and automatically search what are looking for (title of a book, journal article, journal name, library hours) completely undaunted by whatever the search box is labeled.
Beyond The Question of Language
And yet we know that the choice of words is very important to the success of a web site. I think it’s now commonly understood that users will understand ‘books’ more than ‘library catalogue’ and understand either of those terms much more than a brand name such as ‘Infobridge’ or ‘Voyager’. What still not been excised from our way of thinking about academic library web sites is the word and the notion of ‘database’. As librarians, we tend to think of ourselves as a database supplier for our users. But the word ‘database’ means nothing to students. The same goes for the words ‘Resources’ or ‘E-Resources’. That’s because in the rest of our users’ online experiences, they are never asked to visit different ‘databases’ of a particular site. The solution is not just to find other words that make more sense (we use ‘Research Tools’) but to create a web experience in which the parts of a library’s online services come together as an integrated whole to make such labels unnecessary. I’m also hoping that our future academic website will resemble the non-scholarly world and present customized services and information about services through an ‘Account’ section.
An Aside
One of the reasons why I write is because I find it’s a helpful exercise for me to clear the fog and figure out what I know and what I don’t know. And as I have been writing this, I have again come to the realization that I don’t know as much as I thought when I started putting fingers to keyboard. That’s as good as a conclusion I can make at the moment : I think it’s a useful exercise for academic libraries to figure out and articulate what we know and what we don’t know about academic library web design. There’s so much to being honest.
No comments:
Post a Comment