IL 2012: Sensible Library Website Development

Jakob Lodwick
“Jakob Lodwick” by Zach Klein

Speaker: Amanda Etches

Asked some folks on Twitter why their library has a website. A few of the responses: to link to online resources, to allow access to the catalog, to support research needs, to provide access to resources & services, to teach, to help, to provide access to account function, to post events, to post policies & hours, it’s the primary way our patrons interact with us, and as a two-way communication tool between the library and the community they serve. Audience member noted that marketing your library is missing.

While we are all unique little snowflakes, we aren’t all that unique in our motivations for having a library website. So, how can we learn from each other?

Website planning needs to have a clear understanding of scope. Since most of us have a website, this talk will focus more on redesign than from building from scratch. Most people tend to skip the scoping step when doing a redesign because we assume that it will cover the same stuff we already have.

Sadly, most libraries are like a big, messy junk drawer of stuff. We tend to take a “just in case” approach to designing sites. Less is not more, less is actually less, and that’s a good thing. Consider the signal to noise ratio of your website. What users don’t need is too much noise drowning out the signal. Pay attention to how much you are putting on the site that meets your needs rather than your user’s needs. It’s better for half of your website to be amazing than all of it to be bland.

Think about your website like a pyramid, where the bottom half is the basics, followed by destination information, then participatory components, and finally a community portal. Think of it like Maslow’s hierarchy of needs — the basic stuff has to be good or you can’t get to the participatory level.

Etches and some colleagues created a website experiment that is an entire library site on one page called the One-Pager. Freehold Public Library has taken this and ran with it, if you want to see it working in the real world.

Designing for mobility requires you to pare back to what you consider to be essential functionality, and a great way to help scope your website. If you wouldn’t put it on your mobile version, think about why you should put it on your desktop website. Recommend the book Mobile First as an inspiration for scope.

How do you determine critical tasks of a website? As your users. A simple one-page survey, interviews, focus groups, and heat maps. Asking staff is the least useful way to do it.

Web users don’t read content, they skim/scan it. People don’t want to read your website; they want to find information on it. When writing copy for your website, pare it down, and then pare it down again. Your website should be your FAQ, not your junk drawer. Think about your website as bite-sized chunks of information, not documentation. Adopt the inverted pyramid style for writing copy. If you have a lot of text, bold key concepts to catch skimming eyes. Eye-catching headers work well in conjunction with the inverted pyramid and bolded key concepts.

Treat your website like a conversation between you and your users/audience. Pages not be written by passive voiced writers. Write in the active voice, all of the time, every time. Library = we; User = you

It is not easy to redo the navigation on a website. Bad navigation makes you think, good navigation is virtually invisible. Navigation needs to serve the purposes of telling the user: site name, page name, where they are, whey they can go, and how they can search. Salt Lake City Public Library and Vancouver Public Library do this very well, if you want some real-world examples.

It’s very important to match navigation labels to page names. Also keep in mind that your navigation is not your org chart, so don’t design navigation along that. Do not, ever (and I’m surprised we still have to talk about this 15 years after I learned it), use “click here”. Links should be descriptive.

Why test websites at all? A lack of information is at the root of all bad design decisions. Usability testing runs the gamut from short & easy to long & hard. Watch people use your site. It can take just five minutes to do that.

We are not our patrons, so don’t test librarians and library staff. They are also not your primary user group and not the ones you need to worry about the most. Five testers are usually enough for any given test, more than that and you’ll get repetition. No test is too small; don’t test more than three things at once. Make iterative changes as you go along. Test early and often. The best websites do iterative changes over time based on constant testing.

Have a script when you are testing. You want to ensure that all testers receive the same instructions and makes it a little more comfortable for the test giver. Provide testers with an outline of what they will be doing, and also give them a paper list of tasks they will be doing. Remind them that they aren’t the ones being tested, the website is. Don’t tell them where to go and what to do (i.e. “search a library database for an article on x topic”).

From Q&A section:
All of your navigation items should be in one place and consistent across the site.

What do you do when use and usability says that you should remove a page a librarian is keen to keep? One suggestion is to put it in a LibGuide. Then LibGuides become the junk drawer. One way to keep that from happening is to standardizing the look and feel of LibGuides.

For policies, you could put a summary on the website and then link to the full document.

LITA 2008: Web Site Redesign – Perspectives from the Field, Panel Discussion

Panelists: Robin Leech (Oklahoma State University Libraries), Amelia Brunskill (Dickinson College), Edward M. Corrado (Binghamton University), Elizabeth Black (Ohio State University Libraries), Russell Schelby (Ohio State University Libraries)
Moderator: Mary LaMarca (Dartmouth College Library)

Black & Schelby:

When they began the project two years ago, the website was large and maintained by 100 content submitters, most of whom had limited coding expertise. Selected and implemented a Web Content Management System, and created a team of technical experts with both coding and project management skills. Black consciously focused on team development activities in addition to the projects the team worked on.

The team made a commitment to security, usability, maintainability, and data preservation of the website content. As a part of the data preservation, they were careful to document everything from architecture to passwords.

 

Brunskill:

Four years ago, Academic Technology, Library, and Information Services merged to become one division. The website was initially integrated, but then user feedback caused it to be broken out into separate divisions again. After a few years, the library wanted to make some changes, so they did a usability study, which resulted in some menu and vocabulary changes. Then, they began to plan for a much larger redesign.

To solve the communication problem, they set up a blog, charged unit representatives to report back to their units, and circulated usability data among all library staff. The usability studies also served as a buffer for touchy political situations, since the users are a neutral party.

 

Leech:

Developed two teams. The usability team informed the web redesign team, with only the library webmaster serving on both. Suggested that usability team read Don’t Make Me Think by Steve Krug.

 

Note: I had to leave early because I could not stop coughing. The hotel HVAC was not playing nicely with my cold.