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.

ER&L: Making Data Work

Speaker: Jamene Brooks-Kieffer

Spreadsheets are not usable information to most everyone else. It is not a communication tool. A textual summary or data story or info graphic conveys the information found in spreadsheets in ways they are easier to understand.

Every audience has diverse needs. Consider the scope appropriate for the story you need to tell.

Data stories are created with the tools you already have. You don’t need special funding or resources — use what you already have.

Example: In order to understand how the link resolver data is different from publisher data, she started a blog to explain it to internal users.

Speaker: John McDonald

Graphics can simplify the telling of complex stories. But make sure your graphic tells the right story.

Know your audience. Showing the drop in library funding compared to market trend to faculty will get them up in arms, but administrators see it as a correction to an out of control market and maybe we don’t need all those resources.

Collaborate with other people to improve your presentation. You might understand the data, but you are not your audience.

Speaker: Michael Levine-Clark

Guess what? You need to know your audience! And spreadsheets don’t tell the story to everyone.

Take the example of moving collections to storage. Faculty need reassurance that the things they browse will remain in the library. Some disciplines want more specifics about what is going and what is staying. Architects need space planning data and they don’t care about the reasons. Administrators need justification for retaining the materials, regardless of where they end up, and the cost of retrieving materials from storage. Board of Trustees need information about the value of paper collections and being a little vague about the specifics (talking about low use rather than no use).