Chapter 1. Overcoming Preconceptions of the Perfect Library Website: Anecdotes versus Research

There’s No Such Thing as a Perfect Website

Strive for continuous improvement, instead of perfection.

—Kim Collins

Perhaps the most common question I get from webinar attendees is, “Can you recommend a website that we should try to emulate?” This makes sense: I’ve probably spent an hour going on about library website dos and don’ts, so that logically raises the question “Do you have an example of the perfect library website?” Not only is this the most common question I get, it’s also the hardest one for me to answer. Here’s why:

• I’ve never seen a site that is, in its entirety, “perfect.” And I bet you haven’t, either. Aside from the fact that some factors can be subjective, I tend to assess individual elements on their own merits. The navigation may be excellent, but the listings of upcoming events may have potential usability issues. The search function may be terrible, but the footer is well organized. When I talk to clients, I’ve noticed that they tend to evaluate sites in the same way. They’ll look at my portfolio and tell me they like one thing from Site A and another from Site B. Some will tell me they specifically despise that thing from Site C and can’t understand why anyone would have done what Site C did. Even though it’s unconscious, many of us parse sites apart into their component parts when forming our opinions.
• The needs of one library do not necessarily completely overlap the needs of another. Especially if you’re comparing, say, the needs of a large metro system with those serving a small rural community. While that cool feature you saw on the big city website might be nifty, it may not solve any problems for rural patrons. Even libraries of similar size may have needs for specific functions.
• Even if a library needs it, it may not be able to maintain it. When it comes to website features, library staff tend to have eyes bigger than their stomachs, so to speak. They load up their sites with extra functions and features, not calculating the cost in staff time those things might require. Countless newsletters, blogs, and photo albums, just as examples, have languished after installation: they seemed like a great idea during the build process, but staff didn’t have time to keep them up.
• Politics play a bigger part than most people suspect. There’s a significant amount of internal politics that can become part of the web design process. Perhaps it’s the involvement of the library’s board, preferences of the library administrators, or territorial behavior by various staff members. While many of these battles are fought behind the scenes, they do impact a designer’s work and the progress of a library’s site. It’s not unusual for libraries to tell me that they want things that are terrible ideas, simply because “the director said so.” Despite my best efforts to convince them otherwise, the director’s choice may still stand. To this day, there are some sites I’ve done that I don’t show to anyone because the internal politics of the library made them into hodgepodges of bad practice.

When we look at a library website, there are a multitude of decisions that likely went into its creation, and it’s not always easy to discern why or how those decisions were made. While many parts of web design are not subjective (and a good number of those will be covered in this book), “perfect” can still be very subjective in the eyes of the library staff members who are emotionally invested in their website.

Website Work Begins with Education

Though art may be subjective, Web design is not. In Web design, there is a right way and a wrong way to approach layout, navigation, copy, white space, and other critical website components.

—Andrew Follett

A lot of my job comes down to education.

Sure, I spend a good chunk of my time designing websites and writing code. A lot of that work wouldn’t happen, though, without me paving the way with information. This is a little-known truth for most web designers: educating the client is often one of the first—and most important—steps of the design process.

Back in the early days of the web, a lot of design work happened in a vacuum, lacking real guidelines and data. Fortunately, the medium has matured, and rules can now be objectively applied. The maturity of data and existence of standards are often news to many clients whom web designers and developers work with. I’ve heard web myths spouted by library clients often, including the following:

• “Nothing should be more than three clicks from the home page.” (Not true.)
• “Carousels are awesome!” (Spoiler alert: Au contraire, they’re often bad for users.)
• “We know what our users think/how they use our website.” (Statements like this are almost always based only on staff anecdotes.)
• “We need graphics to jazz up the website.” (Don’t even get me started on the problems in this one.)

If the idea is circa 1999, I’ve probably heard it touted as gospel more than once in the recent past.

Why do these myths continue to be perpetuated in libraries? Perhaps because so many of us grew up alongside the web. We were initiated in the very early days when it was truly a Wild West–type environment. Not everyone realizes that those days are long gone and there are real sheriffs in town.

Another reason? Some truths are hard. The fact that carousels actively turn off users doesn’t jibe with the love affair many libraries have with them. The fact that users often don’t need or even like graphics takes much of the fun out of web work. Mythology persists, even in an industry devoted to the dissemination of information, because it can be hard to give up what’s comfortable.

Yet another cause: libraries spend a lot of time looking at the websites of other libraries. Just because XYZ Library did it doesn’t make it right. That library may be operating under the same outdated or mythologically based assumptions you are. If you want to know what really works, look at sites in industries that live or die by whether people buy their services or products online or rely heavily on online donors. Those companies and organizations depend on the science of usability and often have invested a large amount of funds to make sure that users have a frictionless experience.

My hope is that, by the time I eventually retire, whoever comes after me has to do a lot less myth busting in libraries. In the meantime, let’s all be information professionals: let’s put aside our outdated views and our own convenience to create better websites for users.

Modern Web Building Is Far Beyond That Bit of HTML You Learned in Grad School

Pretending to know everything closes the door to finding out what’s really there.

—Neil deGrasse Tyson

It is far from unusual for me to hear something like this, when someone is introduced to their library’s website: “Oh, I know how to program in HTML. I’m sure I’ll have no trouble.” To be brutally honest, I cringe any time I hear this, for a whole host of different reasons. Let me try to sum them up, in no particular order:

• Just the fact that the person used the word “programming” tells me they weren’t paying attention somewhere, because HTML is definitely not a programming language. It’s a markup language. Java, C++, Perl? All programming languages. If the person doesn’t know the difference, that sets off big alarm bells in my head. What else don’t they know that they probably should?
• These days, my work is that of a front-end web developer for a state agency. The last real programming I did was to write a library registration program from scratch in Perl (this was before the advent of commercial systems). Now I do scripting, which is typically done in either PHP or JavaScript. Both are far more complex than HTML, but still not programming.
• Leaving the problematic word “programming” aside, it’s likely that what they learned was HTML 4.x, which is now deprecated. And the differences between 4.x and the current version, 5.x, are not small ones. This puts me, as someone who focuses on current best practices, in the difficult position of trying to verify just what the person knows. Most don’t even realize HTML has version numbers or which version they learned.
• Lastly, there’s the piece of this that requires me to explain to them that they’re working with a content management system (CMS) as their new website. This means that users put in content without needing to know anything technical. In other words, no HTML required. This usually results in the staff person, who had been hoping to show off their alleged prowess, inevitably being disappointed (although the rest of the staff are likely thrilled, and being easy for the layperson is one of the main benefits of a CMS).

Another variant I’ll hear sometimes is along the lines of “Oh, our library is going to build our own site from scratch,” which is then often followed with the same line of “I know HTML.” This one also makes me cringe. Sure, they might be able to maybe build something brochure-like with only HTML. Even if they are familiar with CSS, that’s not going to be enough to make a modern website. Here are two reasons why:

1. Websites are now almost exclusively database-driven. That means that all of the data is stored in a database (e.g., MySQL, PostgreSQL). Then scripting in the code of the website pulls that data as needed.
2. A lot more must be considered now, beyond just the structural code (which is all the HTML is). Is the site optimized for speed? Does it display cleanly across different browsers and devices? Is it accessible? Is it secure from attacks like SQL injections? Back in the 1990s, HTML was enough. It hasn’t been enough since at least the early 2000s.

Most of this could be interpreted as “Laura is pretty grumpy and fussing over semantics.” To be fair, that probably isn’t wrong. However, my point goes further than just those judgments.

One of the luxuries that I have, doing web work for not-for-profit agencies as a not-for-profit agency, is being able to educate clients without dancing around any proverbial bushes. To me, clients being able to understand what’s involved in modern web development helps them to manage expectations about cost, timelines, and maintenance. An educated client is far better to work with, and most libraries seem to appreciate my candid approach, which differs wildly from that of a for-profit web shop operation. I’m not obligated to upsell, for instance. There is no profit, and I get no commission.

There’s nothing wrong with you knowing something about HTML, but that entails a responsibility to understand its limitations. If you’re paying someone to build a site for your library, you’re also paying for their expertise and knowledge. Become an educated client.

When It Comes to the Website, Are You Like a Climate Change Denier?

Without data, you’re just another person with an opinion.

—W. Edwards Deming

One of the least comfortable parts of my job as a web developer/designer is to convince library clients that certain things they want are not actually in their best interests. People often have elements in mind that they think “look cool,” but those features or functions may not have anything to do with making the site easier for the library’s patrons. Carousels come to mind: they may “look cool,” but they are well-known obstructions when it comes to site usability. Heck, they’re even part of a UX (user experience) drinking game.1 It has gotten to the point where I now dutifully tell people why they’re a bad idea; then, having done my due diligence, I go build sites with them anyway. Why? Because I’m tired, that’s why. We’ll take a closer look at why to avoid carousels in chapter 5.

Many functions of a library’s site become territorial or political footballs. So-and-so doesn’t want to make their colleague mad by taking something away or changing it. Carousels make it so everybody gets to have their “stuff” on the home page, visitors’ convenience be damned. A singular patron didn’t like it when the link to the catalog moved, so, good heavens, don’t move that.

Carousels are not the only issue where this kind of denial comes up, but this issue is perhaps one of the most egregious in my work. As information professionals, we should seek out studies and evidence on user experience and web design in favor of our own preferences or anecdotes. If we ignore the scientific studies, it’s like denying the reality of climate change despite all growing evidence to the contrary—because it is an inconvenient truth.

These types of battles are ongoing in libraries (and other fields, I suspect). Too many are likely stuck in the mindset of the very early days of the web, when there were no established concrete rules and web professionals were literally guessing how users would behave around certain types of elements or layouts. Whether you want your site to have a carousel or not is irrelevant; the web design and user experience fields are now based on science—there’s not a whole lot of subjective stuff under the hood anymore. Professionals have been studying human behavior online now for the better part of two decades.

Change is hard, but I’ve watched it happen in libraries. We’ve made ourselves relevant in the internet age when many predicted people would stop coming and we would slowly die out. Even suggesting libraries are irrelevant anymore gets you roasted on social media. We’ve adapted and evolved. Why, then, is accepting and applying behavioral data with web design so difficult for us?

The Plural of Anecdote Is NOT Data

Anecdotal evidence leads us to conclusions that we wish to be true, not conclusions that actually are true.

—Barry Beyerstein

Several years ago, I tweeted:

How many times have you heard “But the patrons want . . .” with no real data to back it up? #libux

The response to that, both online and off, was very interesting. It was liked and retweeted a bit, but it also instigated some discussion on Twitter.

Responder A: “In my exp the squeaky wheels get the grease. Policy & design decisions have been reversed based on a single patron’s comment.”

Responder B: “in my experience many senior staff have selective hearing and only hear some squeaks.”

Responder A: “Heh. At my last POW the approach seemed to be to listen to *everyone* & then do what they asked for where poss.”

Responder A: “I suspect this was partly due to receiving patron feedback so infrequently—we really took it to ❤ when it came.”

ME: “The problem, of course, is that anecdotes are not the plural of data.”

Responder B: “nice approach but eventually you end up with opposite requests. That’s what libs don’t deal with well.”

Responder C: “lots of squeaks sounds like the perfect time to go get some data.”

Responder B: “otoh if you wait for ‘data’ before changing things you’ll never experiment.”

Responder C: “there’s still value in checking whether something is an issue for a small group or a large one.”

Responder B: “yes but I’ve seen ‘no data’ used as a conservative roadblock to change.”

Responder D: “anecdotes are certainly used as a roadblock to change.”

Responder A: “By some weird coincidence I was faced w/ this today. Training staff in new ILS & being given anecdotes as ‘proof’ that the new system was no good/couldn’t support their workflows. It was bullshit, & just used as an excuse to reject change. Change that is coming no matter how much they drag their heels. I am still steaming.”

I’m a tech. I like having numbers (although I will be the first to tell you that I am very bad at making them do things mathematically). I always cringe when someone tells me, “But the patrons want . . .” How do they know this? Did they do a survey? Is that what their web metrics show? Can they quote a study?

Storytelling is, without question, a powerful tool when used in conjunction with the conveying of information. When you can tell a story with your statistics, it becomes a very clear picture. But stories, alone, are just that . . . stories.

I don’t think anecdotes should be discarded entirely; rather, they need to serve as a jumping-off point for further research. Consider the story to be the hypothesis behind your next survey or deep dive into metrics. Can you prove it true or false? The story itself cannot reasonably be the data.

Note

1. Patrick Neeman, “UX Drinking Game: If Someone Says Carousel, Drink,” http://www.uxdrinkinggame.com/drink/if-someone-says-carousel-drink/.