If you're new here, you may want to subscribe to my RSS feed. So that you can read the latest updates about Web2.0 tools, Making Money Online, Tips in SEO, Ajax and many more. Thanks for visiting ProgramimiCOM!

Email newsletters continue to be one of the most important ways to communicate with customers on the Internet. Newsletters build relationships with users, and also offer users an added social benefit in that they can forward relevant newsletters to friends and colleagues. Still, users are highly critical of newsletters that waste their time, and often ignore or delete newsletters that have insufficient usability.

User Research

Our first study of newsletter usability was in 2002. This is very recent, considering that user behavior doesn’t typically change much from year to year. Normally, I wouldn’t retest a particular design domain so soon, but newsletters are different than other media for several reasons. First, the email user experience has actually changed substantially, especially concerning spam. Second, we wanted to focus our new study more on the user experience of receiving and reading newsletters; the first study mainly tested the usability of newsletters’ subscribing, unsubscribing, and account maintenance processes.We conducted the new study remotely using a diary methodology, which allowed a wide geographical distribution of participants. We tested participants from twelve states across the U.S., along with users in Australia, Hong Kong, Japan, Sweden, and the United Kingdom. We studied 101 of the 345 newsletters that participants were already subscribed to on their own initiative, testing users’ newsletter experiences over a four-week period in most cases, and a two-week period in a few cases.

This longitudinal approach allowed more emphasis on how people deal with incoming newsletters during their workday. It also let us test many more B2B and intranet newsletters than we could cover in the first study, which mainly tested B2C newsletters. Of the newsletters received by users in our second study, 65% were for personal purposes and 40% were for business purposes (users viewed 5% of newsletters as both personal and business, so we counted them twice).

Combining the data from the two studies, we identified 127 design guidelines for email newsletter usability. This compares with 79 guidelines identified in the first study. The old guidelines continue to be valid: after all, two years is a short time period and best practices don’t change that quickly. However, our new study’s focus on different aspects of the newsletter user experience let us add 48 new guidelines and slightly refine some of the existing ones.

Spam Is a Fact of Life

Although there is a little good news about the impact of spam on email newsletters, the news is mostly bad. The good news is that, compared to past study participants, users in our most recent study were better able to differentiate legitimate opt-in newsletters from unsolicited messages. Spam now has a very prominent profile in terms of popular awareness, press coverage, and the sheer amount of it that’s hitting inboxes. Users have thus developed a reasonable understanding of the phenomenon, rather than simply being baffled about unexpected messages.The bad news is that increased spam has made people even more stressed and impatient when processing their inboxes. Users have less tolerance than ever for newsletters that waste their time.

We’ve also found that users often employ their spam filters to avoid newsletters that they no longer want. Instead of unsubscribing, which users often view as too cumbersome, they simply tell their spam-blocker that the newsletter is spam. Voila: the newsletter no longer arrives in the inbox.

The fact that many users will declare a newsletter to be spam when they tire of it has terrifying implications: legitimate newsletters might get blacklisted and thus ISPs might block their delivery to other subscribers. This is a compelling reason to increase the usability of the unsubscribe process: better to lose a subscriber than to be listed as spam.

Scannability

In our study, users’ most frequent complaint was about newsletters that arrived too often. And, when we let them vent, the most frequent advice our study participants had for newsletter editors was to “keep it brief.” Newsletters must be designed to facilitate scanning. In our first study, participants read 23% of the newsletters thoroughly. In our second study, two years later, only 11% of the newsletters were read thoroughly. This drop in percentage of thoroughly read newsletters is a good indication of the increased volume of email users have to process.

Users’ dominant mode of dealing with email newsletters is to skim them: that’s what happened to 57% of the newsletters in our second study. The remaining newsletters were either never read (22%) or saved for later reading (10%). Of course, many of the newsletters that users “save” will never actually be read: once they scroll below the visible area of the inbox, they may never be seen again.

Sometimes, users simply skim the headlines to get an update or overview of what’s going on in the newsletter’s target area. As one user said, “I like to keep up to date in the industry, but rarely delve deeper than the cover page.” Other times, users deliberately pick out a few elements that they deem most important and ignore the rest. As another user said, “I review the contents by company and only read the companies of interest to me.”

Designing for users who scan rather than read is essential for a newsletter’s survival. Scannability is important for websites as well, but it’s about 50% more important for newsletters. The implications? Layouts must be designed to let users quickly grasp each issue’s content and zero in on specifics. Content and writing styles must support users who read only part of the material.

Immediate Utility

Newsletters must be current and timely, as indicated by three of the four main reasons that users listed for why a certain newsletter was the most valuable they received. Each of the following reasons were given by more than 40% of users:

• Work-related news and/or activities in their own company or other companies (mentioned by 2/3 of users)
• Prices and sales
• Personal interests and hobbies
• Events, deadlines, and important dates

As demonstrated by this list, there’s pretty much a “what have you done for me lately” phenomenon at play, where newsletters must justify their inbox space on a daily basis. Having been relevant in the past is not enough. Because of the medium’s immediacy, newsletters must be relevant today and address the user’s specific needs in the moment.

However, because newsletters build relationships with readers, and because it’s so easy for readers to ignore individual editions, newsletters do have some leeway here. The key is for a newsletter to be predictably relevant at particular times. During periods in which a newsletter isn’t relevant to users, they can simply ignore it rather than unsubscribing.

For example, a speech pathologist at an elementary school said that she could only purchase new products at the end of the school year and that she ignored product-related newsletters the rest of the year. Still, she didn’t unsubscribe; thus she would still be getting the newsletters when her budget arrived and reading them could help inform her purchases.

Future of E-Newsletters

In our 2002 newsletter usability report, I said about the future of email newsletters: “There may be none. Legitimate use of email is at war with spam, and spam may be winning.”Although two years is a very short period in which to assess big trends, I now believe that this assessment was too negative. Email newsletters are so powerful that the best of them do have a future, despite increasingly adverse conditions.

Ever-increasing information overload is certainly making users reluctant to sign up for more email. And, once newsletters arrive in the user’s inbox, they might simply be deleted as part of a ruthless mass deletion procedure aimed at the morning’s spam. Finally, as discussed above, fear of spam and other email abuse is keeping users from dealing rationally with newsletter subscriptions.

The fight for inbox survival might therefore leave room for only the most useful, targeted newsletters, leaving less valued newsletters in the dust. But good newsletters have a future because they establish relationships with users and continually deliver benefits.

When we asked users to describe the benefits of email newsletters, three reasons stood out, each being highlighted by more than one-third of users:

• Informative: They keep users up to date (mentioned by two-thirds of the users).
• Convenient: They’re delivered straight to the user’s information central and require no further action beyond a simple click.
• Timely: They offer current information and real-time delivery.

Newsletters that leverage these advantages (and other points that users mentioned) have a stable future. To survive, newsletters need only give users specific benefits that help them with life or work issues in the here and now. Comparing email newsletters with other media, one user said: “Bottom line, I’d rather have it in an email newsletter than in the regular mail. I can click Delete if I don’t want it; I don’t have to throw anything away; and it is usually easier to unsubscribe if you don’t want to get anymore.” Convenience rules.

In fact, this is one of the few times that we’ve found the virtual world to be better and more convenient than the physical world. Websites, for example, typically have such poor usability that they compare very unfavorably with real-world stores or in-person services and communities. In contrast, email newsletters have a very strong position.

To capitalize on their potential, email newsletters must be carefully targeted, not just at narrow readership segments, but also at particular problems or situations that each segment faces. Broad-based, chatty, or generic information is less appropriate for email newsletters.

The Wall Street Journal recently noted the poor prospects of a newsletter “targeted at women.” But 50% of the population is not exactly a narrow target, and generic information that’s not situation-specific doesn’t benefit from email’s special characteristic. Not all media forms are good for all purposes. The Internet has never been a mass medium; newsletters are even less suited for mass audiences. But they shine for narrowcast services, which can be exceptionally lucrative.

• 0 Comments

Microcontent needs to be pearls of clarity: you get 40-60 characters to explain your macrocontent. Unless the title or subject make it absolutely clear what the page or email is about, users will never open it. The requirements for online headlines are very different from printed headlines because they are used differently. The two main differences in headline use are:

• Online headlines are often displayed out of context: as part of a list of articles, in an email program’s list of incoming messages, in a search engine hitlist, or in a browser’s bookmark menu or other navigation aid. Some of these situations are very out of context: search engine hits can relate to any random topic, so users don’t get the benefit of applying background understanding to the interpretation of the headline. The same goes for email subjects.
• Even when a headline is displayed together with related content, the difficulty of reading online and the reduced amount of information that can be seen in a glance make it harder for users to learn enough from the surrounding data. In print, a headline is tightly associated with photos, decks, subheads, and the full body of the article, all of which can be interpreted in a single glance. Online, a much smaller amount of information will be visible in the window, and even that information is harder and more unpleasant to read, so people often don’t do so. While scanning the list of stories on a site like news.com, users often only look at the highlighted headlines and skip most of the summaries.

Because of these differences, the headline text has to stand on its own and make sense when the rest of the content is not available. Sure, users can click on the headline to get the full article, but they are too busy to do so for every single headline they see on the Web. I predict that users will soon be so deluged with email that they will delete messages unseen if the subject line doesn’t make sense to them.

If you create listings of other people’s content, it is almost always best to rewrite their headlines. Very few people currently understand the art of writing online microcontent that works when placed elsewhere on the Web. Thus, to serve your users better, you have to do the work yourself.

Guidelines for Microcontent

• Clearly explain what the article (or email) is about in terms that relate to the user. Microcontent should be an ultra-short abstract of its associated macrocontent.
• Written in plain language: no puns, no “cute” or “clever” headlines.
• No teasers that try to entice people to click to find out what the story is about. Users have been burned too often on the Web to have time to wait for a page to download unless they have clear expectations for what they will get. In print, curiosity can get people to turn the page or start reading an article. Online, it’s simply too painful for people to do so.
• Skip leading articles like “the” and “a” in email subjects and page titles (but do include them in headlines that are embedded within a page). Shorter microcontent is more scannable, and since lists are often alphabetized, you don’t want your content to be listed under “T” in a confused mess with many other pages starting with “the”.
• Make the first word an important, information-carrying one. Results in better position in alphabetized lists and facilitates scanning. For example, start with the name of the company, person, or concept discussed in an article.
• Do not make all page titles start with the same word: they will be hard to differentiate when scanning a list. Move common markers toward the end of the line. For example, the title of this page is Microcontent: Headlines and Subject Lines (Alertbox).
• In email sent from your website, make the “From” field clarify the customer relationship and reduce the appearance of spam or anonymous intrusion (but don’t use the name of the customer service rep. unless the user has actually established a relationship with that person: mail from unknown people also has a tendency to be deleted and will be harder for users to find in a search).

Examples

Email subject: Opportunity

Makes the message seem like spam. A sure way to be deleted unread.

Email subject: Web Design Conference in Norway

Sounds like a conference announcement: would be deleted unread by somebody who doesn’t plan to travel to Norway any time soon. Better subject line: Invitation: Keynote speaker at Norwegian Web Design Conference.

Email from line: musicblvd@musicblvd.com
Email subject: Your Music Boulevard Order

Not a horrible subject, but it would have been better to say Music Boulevard Order Shipped to You Today (starting with an information-carrying word and being more precise than the original). The from line should have included a human-readable name like Music Boulevard Customer Service

Page title: Big Blue and Wall Street too

Probably has something to do with investing in IBM, but people who don’t know that nickname would be at a complete loss and would never be attracted to clicking on this headline. Even people who do realize that the story will be about IBM don’t get told what’s new or interesting in the article.

Page title: Reading your PC

Say again? What can this possibly be about? This is a real example (as are all the others) from a major U.S. newspaper. It probably worked fine in print, but not in a listing of headlines on a third-party website.

Page title: Sound Card Competition Heats Up

When shown on a computer-related site, this is a great headline. When placed out of context it may be better to add a qualifier: Sound Card Competition Increases in PC Market. Note that the page title will still work if the last part is chopped off in some listings.

• 1 Comment

Well-designed B2C sites can easily explain their products and services in text that is short enough that users will actually read it online. AutoTrader.com, for example, tells us to “Search the largest inventory of cars and trucks on the Internet. More than 1.5 million listings, updated daily.” Given this information, most people can figure out what the site does.

Relative to B2C, most B2B sites sell products or services that are much more complex and have less connection to everyday experience. Summarizing a website’s purpose is thus much harder in B2B than in B2C. That’s why they pay copywriters the big bucks, or so you would think. On closer examination, it seems that most sites pay their copywriters to obscure the site’s purpose rather than state it clearly.

Obscurity in action

Here are the taglines from four websites: Angara, Calico, CSG Systems, and E.piphany:

• Creating customers online
• eBusiness for leaders: Enabling corporations to control the key elements of eBusiness selling
• Harness the power of convergence with (company’s name)
• Software for the customer economy: next-generation CRM software

Can you match the taglines with the company they describe? Can you tell which company does what? Is there a difference between these companies? Do you care?Regarding the first question: I listed the taglines in the same order as I listed the companies above them. But the real point here, as you no doubt discovered, is that these taglines are basically content-free word count. They do nothing more than clutter up their respective home pages.

Getting it (half) right

I collected the above taglines a few months ago. As I prepared to write this column, I revisited the sites and found that CSG Systems had dropped the tagline “Harness the power of convergence.” The company is now wisely willing to tell us what they actually sell: “customer care and billing solutions.” Much more specific, and thus more likely to harness the attention of stressed-out business executives looking at the homepage in search of products.The new CSG Systems website actually does several things right. The home page is reasonably simple, despite an annoying Flash animation that will likely distract visitors. The main text looks like it’s written based on my guidelines for online content: Short paragraphs, scannable layout, a bulleted list:

Unfortunately, when you read the words, you realize that the company is still paying copywriters to avoid communicating with prospective customers. Note how the “solutions” are robust, integrated, efficient, and cost-effective. As opposed to what? A product that was buggy, fragmented, inefficient, and expensive? Given that a website would never advertise such a product, stating the opposite has zero informative value.

Tagline guidelines

Users decide quickly whether to stay or leave a site. To assess whether your homepage communicates effectively to visitors in the crucial first 10 seconds, follow two simple guidelines.

• First, collect the taglines from your own site and your three strongest competitors. Print them in a bulleted list without identifying the company names. Ask yourself whether you can tell which company does what. More important, ask a handful of people outside your company the same question.
• Second, look at how you present the company in the main copy on the home page. Rewrite the text to say exactly the opposite. Would any company ever say that? If not, you’re not saying much with your copy, either.

When I’m attempting to build a shortlist of potential vendors, the experience of looking at home pages reminds me of the frustration I usually feel walking a tradeshow floor. I recently attended an intranet conference that had booths from at least 20 different search engine providers. I simply could not tell the difference between these companies. Who did what? Which technologies would make sense for which type of problem? Which products would fit the budget for which projects? The booths were essentially random designs. While they clearly cost huge amounts of money, they failed to communicate anything distinct to a tired tradeshow visitor pacing up and down the aisles.Think about your home page as analogous to a tradeshow booth. Why do you stop at some booths and skip others? And, no: having a live magician is not the answer for your home page. Clearly saying what you do and why users should care is the way to go.

• 0 Comments

Sometimes technological progress backfires, and the “better” technology turns out to be worse for users. The Web is no stranger to this problem, and has experienced many innovations that would have been best avoided. Examples include frames, changing the color of browser scrollbars, and scrolling text.

Another example of harmful Web technology comes with the increasing use of style sheets, which let web designers specify the exact size of text down to the pixel. Unfortunately, many designers are using this ability, leading to reduced readability of an increasing number of websites.

The State of Font Control

I’m hereby launching a campaign to get Microsoft to make user preferences override any fixed font size specification in Web designs. It may be okay for the browser to initially render the page with the designer’s text size, but users should be able to easily enlarge text, no matter what the style sheet says. After all, it’s my screen, my computer, and my software, and they should do what I say.

Granted, some web browsers have a geeky feature that lets users specify their own style sheets. Fine for experts, but 99% of users simply want to make text bigger if it’s too small to read. The Mac-only iCab browser gives users this simple control; let’s make Internet Explorer equally friendly to users’ needs.

So, why is so much website text so hard to read in the first place? Two theories:

• Most web designers are young, and so have perfect vision. Tiny text doesn’t bother them as much as it bothers people on the other side of 40. Designers also tend to own expensive, high-quality monitors that are easier on the eyes.
• While creating a website, designers don’t actually read the information on the pages. They simply glance at the text to make sure it looks great. In fact, many designs are approved with “lorem ipsum” standing in the place of real copy. When you don’t have to read the words, it doesn’t matter that the characters are small.

Because so many sites have made bad decisions regarding font size, users commonly need to change it. Early IE versions supported this need, offering users two standard toolbar buttons: one that made text bigger, and the other that made it smaller. That’s the way things should be. Mr. Gates, please give us back the good design you shipped in IE4 for the Mac.

Simplifying Browser Font Control

Unfortunately, recent versions of IE have eliminated IE4’s good design, replacing it with an approach that has two serious usability problems:

• The text size button is no longer visible by default. Only the minuscule percentage of users who customize their toolbars will get this highly useful button. Most users see instead the default toolbar, which is polluted with buttons that have much less utility. Because the feature is hidden, few users realize that their browser can change text size.
• Separate buttons no longer exist for text-bigger and text-smaller. If users can find it at all, they’ll get a single button to control both directions of text change.

For those few experienced users who do prevail and restore the missing button to their customized toolbar, actually changing the text size in IE6 requires several steps:

1. Acquire the button by moving the mouse pointer over it. Since buttons are reasonably big in IE, this step is fairly quick according to Fitts’s Law.
2. Press down the mouse button.
3. This causes a pull-down menu to appear, with five possible font sizes. Scan this menu, making a mental note of which font size is currently selected.
4. Mentally compute which new font size you want. This is typically one size bigger (or smaller) than the current selection.
5. While you continue to press the mouse button, move the pointer down the menu until it points to the desired new font size.
6. Let go of the mouse button.

Compare this awkward, six-step process with the interaction technique required by a design that includes separate buttons for “make text larger” and “make text smaller”:

1. Click the desired button.

Of course, I am cheating a little: You would still have the initial step of deciding whether you want the text larger or smaller, thus determining which button you’d click. Still, since the entire change-font-size procedure is triggered by your annoyance at trying to read unpleasantly sized text, you already know that you want bigger (or smaller) text by the time you decide to change the size. (The average user doesn’t have a mental model of a single “change size” command that is parameterized with the desired direction of change; the user’s model includes two actions: “bigger” and “smaller.” How the code is implemented is irrelevant for the user illusion which should be designed to match the users’ mental model.) The two-button approach frees users from the cognitive overhead of calculating how big they want the text to be. Just make it bigger. Users don’t want to specify exactly how big. They can easily keep clicking the “bigger” button if the initial click doesn’t make the text big enough.

Usability is enhanced by single action buttons that move along a uni-dimensional axis in simple steps, as long as each step’s result is immediately clear after each click. That’s also why the Back button is so precious to users, and why it’s used much more frequently than history list navigation.

Improving Future Browsers

Reverting to IE4’s design for the Mac would be a great step forward for font size usability. Still, we can do better.Instead of having users manually change the text size every time they come across a user-hostile design, let’s take advantage of the Internet and track font size preferences: Every time your browser loaded a page from a new website, it would first check a database for information about your predicted font size preference:

• If it’s a site you had visited before, a database on your local machine would keep a record of whether you had clicked the text-larger or text-smaller buttons during your previous visits. If so, it would automatically adjust the text accordingly.
• If this were your first visit to the site, your browser would contact a central database for information about the actions of users similar to you who’d visited the site. It would then apply these users’ average adjustment to the first page you see from the site. If you make any additional changes, your local database would note a revised preference and log the modification with the central database.

To expedite response time, your browser might pre-fetch the preference settings for all websites that the current page linked to before you even clicked a link.The central database itself would be a straightforward case of collaborative filtering, since it would be easy to find other users with the same text-size preferences. For any given web page, most users would either leave it alone or request text that’s one or two sizes larger or smaller. Because a total of five options would account for the vast majority of users, font size preferences would be much easier to model than, say, taste in books or films.

Auto-adjusting font sizes based on collaborative filtering is a simple example of the benefits that could accrue from more network-aware browsers. It would also be possible to auto-repair many broken links, auto-remove annoying ads or pop-ups, and make many other improvements to individual users’ experience based on feedback from prior site visitors.

We must stop thinking of browsers as trivial pieces of free software that aim at nothing more than rendering web page pictures on the screen. We need user-supportive environments that facilitate navigation and protect users from the excesses of bad websites.

Readability Guidelines for Websites

We can’t wait for Microsoft to ship a good browser, though that has to be the ultimate solution to the font size problem. For now, websites can increase readability by following these guidelines:

• Do not use absolute font sizes in your style sheets. Code font sizes in relative terms, typically using percentages such as 120% for big text and 90% for small text.
• Make your default font size reasonably big (at least 10 point) so that very few users have to resort to manual overrides.
• If your site targets senior citizens, use bigger default font sizes (at least 12 point).
• If possible, avoid text that’s embedded within a graphic, since style sheets and font size buttons don’t have any effect on graphics. If you must use pictures of text, make sure the font size is especially large (at least 12 point) and that you use high-contrast colors.
• Consider adding a button that loads an alternate style sheet with really big font sizes if most of your site’s visitors are senior citizens or low-vision users. Few users know how to find or use the built-in font size feature in current browsers, and adding such a button within your pages will help users easily increase text size. However, because every extra feature takes away from the rest of the page, I don’t recommend such a button for mainstream websites.
• Maximize the color contrast between the text and the background (and do not use busy or watermarked background patterns). Despite the fact that low-contrast text further reduces readability, the Web is plagued by gray text these days.

• 0 Comments

The oldest usability guideline for any type of navigational design is to help users understand where they’ve been, where they are, and where they can go (past, present, and future). The three are somewhat interrelated: a good grasp of past navigation helps you understand your current location, since it’s the culmination of your journey. Knowing your past and present locations in turn makes it easier to decide where to go next.

On the Web, links are a key factor in this navigation process. Users can exclude links that proved fruitless in their earlier visits. Conversely, they might revisit links they found helpful in the past.

Most important, knowing which pages they’ve already visited frees users from unintentionally revisiting the same pages over and over again.

The Price of Uniform Link Color

Generally, Web browsers are severely deficient in supporting user navigation. However, they do provide one feature that helps users orient themselves: browsers let designers display links in different colors, depending on whether the links lead to new pages or pages that users have seen before. Changing the color of visited links has been part of Web browsing since Mosaic arrived in 1993, so it’s completely standard; almost all users understand it. Currently, 74% of websites use different colors for visited and unvisited links, making this design approach a strong convention that people have come to expect.

Hypertext theory, the Web’s history, and current design conventions all indicate the need to change the color of visited links. Further, empirical observations from user testing have identified several severe usability problems on sites that violate this convention. When sites use the same color for visited and unvisited links, users:

• unintentionally revisit the same pages repeatedly;
• get lost more easily because their understanding of each link’s meaning is reduced;
• often misinterpret or overlook the difference between two similar links if they’re unsure about which one they’ve already visited; and
• give up faster because they have a reduced sense of mastery when the site fails to reflect their actions and thus help them navigate.

Such usability problems are particularly damaging to users with weak short-term memory, who often have trouble remembering what they’ve clicked without a visual representation. Of course, “weak short-term memory” is an inherent shortcoming of all humans, which is why all users are harmed by unchanging link colors. But this definitely impacts some people more than others, so it’s particularly important to change link colors if you have many older users.Given the extensive theoretical and empirical support for using different link colors, it’s astounding that a quarter of all websites continues to inflict extra usability problems on people by choosing a uniform link color.

Why the Problem Persists

Even people who believe in usability sometimes question the need for changing link colors. I think this is because they don’t pick up on the problems caused by unchanging links when they conduct their own user testing. Unfortunately, the symptoms of these problems are among the most difficult to detect when you observe users. User testing is basically easy: we teach it in three days. Most important usability problems are so glaring that anybody can identify them through a simple test. Once you know the basics of how to write good tasks and how to facilitate the session without biasing user behavior, you can clearly see users get into trouble when they encounter poorly designed components of your site.

Say, for example, that a user clicks the wrong button. It’s obvious to any observer that such behavior represents a design error. Listening to users’ comments prior to clicking usually tells you why they misunderstood the design, thus guiding you to make it better in the redesign.

Cases in which users don’t do something are harder to discover. Even so, most usability facilitators can identify many such problems. You might, for example, observe that no one in your test clicked on one of your major features. Users’ thinking-aloud comments will make it clear whether they (a) saw the feature, but didn’t find it relevant; or (b) never considered the feature because it looked too much like an advertisement.

Detecting Distributed Usability Problems

Some usability problems require more detective work and are often overlooked by people relatively new to user testing. This is particularly true for problems that are a composite of multiple individual issues scattered around the site. Identifying these problems is even more difficult when none of the individual issues cause difficulties on their own. A relatively simple example of a multi-location problem is when a homepage link sets certain expectations that cause users to misinterpret the information on the destination page. The link text itself might be clear, and users are unlikely to complain about it. The destination page might also be clear, and users might not complain about it, either, because they think they understand it. The problem is that they understand it wrong because they interpret it in the context of their misguided expectations. This type of usability problem requires test observers to make high-level conclusions based on remembering what happened on the previous page, even though nothing that happened seemed to cause users difficulties.

The damage that unchanging link colors cause is one of the most tricky usability problems to identify in user testing. On any given page, users seem to understand the links just fine. Users almost never complain about link colors, as long as they’re distinct from the rest of the text and reasonably legible. Life is good, or so it seems.

Observe carefully, though, and you’ll notice that users frequently move in circles. They’ll visit the same page multiple times — not because they want to, but because they don’t realize that they’ve already been there. Users will give up when they’ve tried most links in a list, even though there’s one link that they haven’t tried; if the links don’t change colors, users don’t realize that there’s only one unvisited link remaining.

Unchanging link colors also create navigational confusion because users don’t quite understand their different choices or where they are. Of course, this problem could also be a symptom of muddled information architecture or poorly written labels, which is why it requires experience to identify the true root cause of the users’ difficulties.

Even though the downsides of unchanging link colors are easily overlooked in user testing, they’re very real and problematic for users. Many other design strategies for helping users navigate, such as site maps, require a good deal of work. But the browser lets you change link colors for free, so there’s no reason not to take advantage of this simple way to help your users.

Using different colors for visited and unvisited links makes your site easier to navigate and thus increases user satisfaction.

• 0 Comments

Alternate Step One: Using .htaccess to Add your 404 Error Page

If you’d rather not muck with the innards of your httpd.conf file, there’s a sensible and less overwhelming alternative solution, at least if you’re using the Apache web server. Instead, create a file in your Web site’s home directory called .htaccess (yes, that’s a dot or period as the first letter. It’s very important!)

You can accomplish this if you have direct edit capabilities on your server, or you can create a file with the correct name on your PC or Macintosh and upload it to the server. Regardless, the content of the file should be exactly:

ErrorDocument 404 /404-error-page.html

In this instance, you’re defining the name of your error page to be exactly 404-error-page.html and that it’s going to live at the topmost directory of your Web site. If you’d prefer a different name, then modify the contents of this file appropriately.

If you use FTP to upload this file to your server, make sure that you transfer it in “text” or “ascii” mode so that it’s properly parsed by the server.

Step Two: Create the 404 Error Page

There are lots of different error 404 pages you can create, ranging from the succinct and dry to the peculiar, to the witty, to the super-helpful (for example, you can easily add a google search for only pages from your site to your 404 error page ).

Whichever path you choose, you’ll find people appreciate if you at least offer a link to your home page and some method whereby they can contact you if they are insistent that certain material should be present but isn’t.

Also, most people agree that not insulting them is a good strategy, but, perhaps surprisingly, this varies and there are definitely some 404 error pages out there that are quite blunt.

It depends on the style of your site, your sense of humor, and whether you want to err on the side of “useful” or on the side of “amusing”.

Step Three: Restart the Web Server

To get the change to the configuration file accepted, you’ll probably need to restart or otherwise nudge your Apache Web server so it knows that you’ve added a custom 404 error page (otherwise it’ll continue to blithly serve up the generic error page instead).

There are a couple of basic commands to accomplish this task:

1. apachectl is most common,
2. or you might need to revert to a custom script like restart_apache,
3. or tools like Webmin have a restart option,
4. or, if this all seems like too much work, just ask a sysadmin to restart the server.

Regardless of which you choose, it’s always a good idea to also check the log files for the Web server to ensure that everything was accepted and parsed without any errors. On a typical Linux/Unix configuration, the log file would be at

/var/log/messages

because Apache (almost always) is configured to use the standard syslog mechanism.

Step Four: Testing

Once that happens, type in a URL that you know isn’t present on your site and see what happens! If everything is correct, you should see the new 404 error page pop up.

If it doesn’t work, go back to your httpd.conf file, identify where errors are logged (probably an entry ErrorLog) then look in that file to see what’s wrong.

Most likely you have a naming error where it’s called one thing in the configuration file but something else on the actual server.

If everything is working fine, try a second 404 error by requesting a page that’s a few subdirectories into the site, so while for your first test you may have used something like http://www.example.com/badpage this time try something more like http://www.example.com/some/subdir/badpage

If all the graphics are displayed properly and the links to elsewhere on your site are all correct, congratulations! You’ve done it! You’re now the proud owner of a custom 404 error page.

If not, step through this tutorial again, keeping an eye on the error log file, and you should have this figured out in no time.

• 1 Comment

PDF is great for one thing and one thing only: printing documents. Paper is superior to computer screens in many ways, and users often prefer to print documents that are too long to easily read online.

For online reading, however, PDF is the monster from the Black Lagoon. It puts its clammy hands all over people with a cruel grip that doesn’t let go.

PDF Usability Crimes

The usability problems that PDF files cause on websites or intranets are legion:

• Linear exposition. PDF files are typically converted from documents that were intended for print, so the authors wouldn’t have followed the guidelines for Web writing. The result? A long text that takes up many screens and is unpleasant and boring to read.
• Jarring user experience. PDF lives in its own environment with different commands and menus. Even simple things like printing or saving documents are difficult because standard browser commands don’t work.
• Crashes and software problems. While not as bad as in the past, you’re still more likely to crash users’ browsers or computers if you serve them a PDF file rather than an HTML page.
• Breaks flow. You have to wait for the special reader to start before you can see the content. Also, PDF files often take longer time to download because they tend to be stuffed with more fluff than plain Web pages.
• Orphaned location. Because the PDF file is not a Web page, it doesn’t show your standard navigation bars. Typically, users can’t even find a simple way to return to your site’s homepage.
• Content blob. Most PDF files are immense content chunks with no internal navigation. They also lack a decent search, aside from the extremely primitive ability to jump to a text string’s next literal match. If the user’s question is answered on page 75, there’s close to zero probability that he or she will locate it.
• Text fits the printed page, not a computer screen. PDF layouts are often optimized for a sheet of paper, which rarely matches the size of the user’s browser window. Bye-bye smooth scrolling. Hello tiny fonts.

Users Hate PDF

In several recent usability studies, users complained woefully whenever they encountered PDF files. Following are quotes from investors testing the investor relations area on corporate websites:

“It’s a pain that I have to download each PDF. Pain in the ass… I find it to be annoying. It’s slow to load. It’s hard to search within it. I find HTML easier to deal with… This is all PDF instead of a chart. My dream site is to come to a site and get a bar chart for the sales within the last ten years.”

“I hate Adobe Acrobat. If I bring up PDF, I can’t take a section and copy it and move it to Word. There could be stuff like graphics I don’t want. I prefer documents in HTML format so that it’s editable.”

The following user quotes are from journalists testing the PR area on corporate websites:

“They [PDF files] don’t behave like Web pages. It’s not the speed. It is like having a solid thing rather than a fluid thing.”

“What we’ve got is a page of a PDF document which is great when printed out, but on the screen it is hard to read. The print is too small…”

“I am a little frustrated with Acrobat… They made every page a file. So what happens here is when you scroll, it jumps, which is really not helpful.”

This quote is from an employee who was testing an intranet:

“It would have helped if the first page was an index and you could scroll to it. That must be what this side part means. But who am I to say?”

As the last quote shows, even when a PDF file has its own navigation aides, they don’t typically help because they’re nonstandard and based on a paper metaphor rather than hypertext navigation.

We’ve had similar reactions from users in many other studies, including tests of B2B websites where users complained when sites presented product specs or customer success stories in PDF instead of Web pages. Here’s a quote from a customer who shunned those parts of the site that were in PDF:

“It looks like I’m going to have to go to PDF, which I’m dreading.”

• 1 Comment

Users love search for two reasons:

• Search lets users control their own destiny and assert independence from websites’ attempt to direct how they use the Web. Testing situations routinely validate this. A typical comment is: “I don’t want to have to navigate this site the way they want me to. I just want to find the thing I’m looking for.” This is why many users go straight to the home page search function.
• Search is also users’ escape hatch when they are stuck in navigation. When they can’t find a reasonable place to go next, they often turn to the site’s search function. This is why you should make search available from every page on the site; you cannot predict where users will be when they decide they are lost.

Search is a big deal: the usability of the search on intranets we have tested accounted for 43% of the difference in employee productivity between intranets with high and low usability.

Search Should be a Box

Users often move fast and furiously when they’re looking for search. As we’ve seen in recent studies, they typically scan the home page looking for “the little box where I can type.” We’ve long known that users scan, and the implications are clear:

• On home pages, search should be a type-in field and not a link.
• The search input field should be wide enough to contain the typical query; if the box is too small, the query will scroll and diminish usability.

When I changed the useit.com home page to include a search box instead of a link, search engine use increased by 91%. Small change, big effect (as is often the outcome when implementing usability guidelines). (Interior pages may use a search link if they have a very simple design; complex interior pages should use a search box.)

Query Reformulation: Not

Given that search is becoming old hat on the Internet, you might think users would develop advanced search skills. Not so. Typical users are very poor at query reformulation: If they don’t get good results on the first try, later search attempts rarely succeed. In fact, they often give up. We recently studied a large group of people as they shopped on various e-commerce sites. Their search success rate was:

In other words, if users don’t find the result with their first query, they are progressively less and less likely to succeed with additional searches. Many users don’t even bother: In our study, almost half the users whose first search failed gave up immediately.

There is no question that we need to develop methods to help users hone their searches. Probably the only long-term solution is for the school systems to teach kids strategies for query reformulation. In the short term, search interfaces could show users easy ways to extend queries.

Realistically, though, search design should assume that most users won’t be willing or able to refine their queries. Given this, the emphasis should be on increasing users’ success on the first attempt.

Another reason to emphasize early success is that users typically make very quick judgments about a website’s value based on the quality of one or two sets of search results. If the list looks like junk, they may abandon the site completely. At a minimum, they’ll forgo the site’s search in favor of external search engines like Google.

Advanced Search: Not

In our recent search study, the mean query length was 2.0 words. Other studies also show a preponderance of simple searches. Most users cannot use advanced search or Boolean query syntax. This has two implications for search design:

• Emphasize your search engine’s ability to handle single-word queries and very short multi-word queries and still produce high-quality results.
• Do not offer advanced search from the home page. Advanced search leads users into trouble, as they invariably use it wrong. When it makes sense, offer advanced search as an option users can link to from the search results page: “Didn’t find what you were looking for? Try advanced search.”

Scoped Search: Maybe

Scoped search lets users limit the search to results from specific areas of the site (the search scope). In general, this is dangerous. Users often overlook the scope, or they think they are in a different site area than the one they are actually searching.However, as websites continue to grow and offer multiple services in a single site, my attitude toward scoped search is changing. I now believe scoping can be sufficiently useful if you offer it in areas of the site that are both clearly delimitated and address specific problems.

If you choose to use scoped search, I recommend following a few basic rules:

• Set the default search scope to “all” (search the entire site).
• When the user chooses a narrow search scope, explicitly state the scope at the top of the results page.
• Offer one-click access to enlarge the scope. It is especially important to give users a highly visible way of searching the entire site if their scoped search fails to return any results.
• If a search returns too many results, give users suggestions for limiting the scope.

First Results Page is Golden

Users almost never look beyond the second page of search results. It is thus essential that your search prioritize results in a useful way and that all the most important hits appear on the first page.Also, look through the most common queries in your search engine logs and determine the optimal landing page for each common query. You can then manually tweak the search engine to show these pages as the #1 hit.

• 0 Comments

The Internet enriches many seniors’ lives, but most websites violate usability guidelines, making the sites difficult for seniors to use. Current websites are twice as hard to use for seniors than for non-seniors.Seniors are one of the fastest growing demographics on the Web. The United States alone has an estimated 9 million Internet users over the age of 65 as of September 2004. Indeed, all industrialized countries have huge populations of senior citizens, many of whom have substantial assets. Although they are typically retired, seniors lead very active lives and often have great interest in modern technologies such as the Internet, which gives them another method to communicate and stay informed.

In our study, email was the main Internet application used by seniors. Our participants used the Web mainly for:

• Research
• News
• Tracking investments
• Researching medication and medical conditions
• And, to a lesser extent, to shop and bank online

Indeed, our study participants used the Web to read about and research a wide variety of hobbies and special interests, ranging from genealogy to cooking, war strategy, and musical instruments. Taken together, reading about such hobbies constituted a major use of the Web: The diversity of specialized sites is just as much a killer app for seniors as it is for other users.

Research with Seniors Using Websites

To learn how seniors use the Web, we conducted three series of usability tests:

• A measurement study, using three websites and a Web-wide task, with 20 seniors and a control group of 20 users between the ages of 21 and 55.
• A qualitative study with 20 U.S. seniors using 10 U.S. sites.
• A qualitative study with four seniors in Japan using four Japanese sites (to assess the international applicability of our findings).

We define “seniors” as people over the age of 65. Most of our test users were in their 70s, but we also included some people who were 80 years or older, and several people between 65 and 69.

Usability Metrics Twice as High for Non-Seniors

In the quantitative study, we asked users in both groups to perform the same four tasks:

• Fact-finding
• Buying an item
• Retrieving information
• Comparing and contrasting

The following table shows the measurements of four usability attributes averaged across the four tasks.

The differences between seniors and the control group are all highly significant.

Normalizing the usability metrics so that the seniors’ scores are the baseline value of 100% in all cases leads to an estimated overall usability of 222% for non-seniors. (Averaging computed as the geometric mean.) In other words, overall usability was slightly more than twice as good for non-seniors as it was for seniors.

Why Usability is Lower for Seniors

Websites tend to be produced by young designers, who often assume that all users have perfect vision and motor control, and know everything about the Web. These assumptions rarely hold, even when the users are not seniors. However, as indicated by our usability metrics, seniors are hurt more by usability problems than younger users. Among the obvious physical attributes often affected by the human aging process are eyesight, precision of movement, and memory. Also, many seniors retired without having used computers and the Internet extensively during their working careers. Thus, they have not necessarily learned good conceptual models of how these technologies work, which makes it more difficult to understand their quirks. For example, we observed several users who did not differentiate clearly between a website’s search box and the browser’s URL box. After all, both are input fields that you type in when you want to go elsewhere. The lack of experience with good conceptual models is obviously not fundamental to human biology, and may disappear as the current workforce retires.

Our testing identified many instances of poor design that compounded to make the Web more than twice as hard for seniors to use. Complying with the guidelines for designing for seniors would remove many such usability problems. And, while Web usability might still be slightly better for younger users, the differences could be reduced drastically.

Readability and Clickability

The most widely known principle for supporting seniors’ computer use is to support larger font sizes than those younger users prefer. The principle may be well known, and it was indeed confirmed by our study, but still, it is frequently violated by sites that freeze text at a tiny font size. Sites that target seniors should use at least 12-point type as the default. And all sites, whether or not they specifically target seniors, should let users increase text size as desired — especially if the site opts for a smaller default font size.

For hypertext links, large text is especially important for two main reasons: 1) to ensure readability of these essential design components, and 2) to make them more prominent targets for clicking. You should also avoid tightly clustered links that are not separated by white space. Doing so will decrease erroneous clicks and increase the speed at which users hit the correct link. This rule also applies to command buttons and other interaction objects, all of which need to be reasonably large to be easy to click.

Pull-down menus, hierarchically walking menus, and other moving interface elements cause problems for seniors who are not always steady with the mouse. Better to use static user interface widgets and designs that do not require pixel-perfect pointing.

Supportive and Forgiving Design

When websites violate the guideline to use different colors to clearly distinguish between visited and unvisited links, seniors easily lose track of where they have been. We’ve certainly seen the same problem among all age groups: It’s confusing when websites change the standard link colors, and it’s particularly confusing when the same color is used for all links, whether or not you have visited the destination page. However, seniors have a harder time remembering which parts of a website they have visited before, so they are more likely to waste time repeatedly returning to the same place. Seniors also have a harder time using unforgiving search engines and forms. We saw users thwarted because they typed hyphens in their search queries, and punished because they used hyphens or parentheses in a telephone or credit card number.

Error messages were often hard to read, either because the wording was obscure or imprecise, or the message’s placement on the page was easily overlooked among a profusion of other design elements. Simplicity is even more important than usual when seniors encounter error handling: Your message should focus on the error, explain it clearly, and make it as easy as possible to fix. Also, as much as possible, website tasks should adapt to seniors and their preferred way of doing things. After decades of writing telephone numbers in a certain way, it’s not a very nice experience to come across a form that insists on a different format.

Usability Increases Satisfaction

Seniors strongly prefer those websites that are easiest for them to use. The correlation between the success score for our test tasks and users’ subsequent subjective rating of the sites was very strong: r = 0.78, which is higher than we have found in most other studies, though not as high as the 0.95 we found in our equivalent study of users with disabilities. Usability for seniors is important, and not just so that they can perform a task aimed at a one-time purchase. By focusing on improving usability for seniors, you can increase their satisfaction and the odds of forming a long-term relationship.

Intranets should also cater to seniors. Most companies have employees in their 60s, and many big companies have special extranets for retirees that provide online benefits information and help the company maintain contact with former employees.

Besides the business reasoning, we all have a very personal interest in increasing usability for seniors: It’s the one user category we’re all likely to join one day.

When it works for them, the Internet is already an enriching part of many seniors’ lives. Websites can become much more approachable, however, by following the simple design guidelines in our new report. If you consider these guidelines from the start, implementing them will rarely add to the cost of a Web design or intranet project. Also, many of the guidelines for increasing usability for seniors help other users as well.

• 1 Comment

AJAX-style Within-Page Refreshs

Ole Begemann writes:

While I agree with your assessment, I wonder how AJAX fits into this. AJAX is all about interactivity within the same page. Do you think this does more harm than good because of the confusion it causes (and e.g. the Back button does not work as expected anymore)? Or should AJAX actions be invoked by buttons rather than links?

Jakob’s answer:
Interactivity (i.e., features) and navigation are different. So it should be OK to have things happen within the same page as long as they are not seen by users as representing a movement to a new location. See this screenshot for an example:

Screenshot of the price of a stock over three months from Yahoo! Finance.

This is a stock chart showing the price of Amazon.com’s stock over three months. Click the link marked “1y” to get the price over a year instead. It so happens that the implementation is a link to a new page, instead of a within-page refresh-in-place, but there’s no reason for that, except for the benefit I get from being able to easily copy the URL and link to it in the caption. Anyway, if Yahoo had used a button instead of a link to change the view of that chart, it should have worked well as a within-page refresh.Most likely it should be a guideline to use a different UI widget than a plain-text link for this purpose. For sure, we know that it’s a guideline to use buttons for commands and links for navigation, and changing the view of a chart seems more like a command than it seems like navigation. An alternative, in the example in the screenshot, would be to use tabs to alternate between the views. This would certainly comply with the standard use of tabs in applications, even though there would be a conflict with the way tabs have often been abused on websites (which often use tabs to denote navigation instead of alternate views).

For switching between alternate views of the same data, it’s actually better if the Back button doesn’t work, because it would mainly be used when the user wanted to return to the previous location (say, the list of stocks they’re tracking), not if they want to see the previous data view again.

The operative question is whether the user’s action feels more like a manipulation of the same data or a movement to some new data. If the former, then it’s a command. If the latter, it’s navigation. To really find out, you need to observe users and perform a task analysis, but often you can come up with a good first guess and use for your initial design before it goes to testing.

“Return to Top” Links

Vincent Simard writes:

Should “Return to top” links be avoided? They seem accepted by a lot of developers and users although I have not tested them vs. users scrolling back to the top of a page manually.

Jakob’s answer:
Yes, “return to top” can be avoided, because the exact same functionality is provided by simply dragging the scrollbar to the top of the page. It’s almost always better to rely on a single, generic interaction technique so that users don’t have to ponder the choice between two alternate interaction techniques for the same goal. The time it takes to make the decision is usually more than the time saved by the shortcut. (The exception would be for extremely long pages that would take forever to scroll, but such pages should be avoided in the first place.)

Horizontal Scrolling

J. D. A. Wiseman writes: Internal links are not only for long lists: also wide maps that cannot be less wide.

Jakob’s answer:
Of course, in general, there’s a guideline to avoid horizontal scrolling, but a wide map would be one of the exceptions. For a low-tech solution, within-page links may be an acceptable way to jump to a specific part of this type of map. A more fancy solution would be to have a special map controller, but that would be overkill for a simple site like yours.

Skip Links for Users With Disabilities

Mike Elledge writes:

I would suggest another situation where skip links are both a benefit and meet user expectations: When used to skip navigation (or, alternatively, go to content) for persons using adaptive technology.

This is commonly recommended by persons within the accessibility community to enable AT users to avoid unnecessary tabbing, reducing fatigue and repetition. Screen readers, such as JAWS, identify such links as “in-page” so that users are further informed.

Jakob’s answer:
This is a good point, and may be one of the few cases where the user experience is better for users with disabilities than for non-disabled users. In general, our testing has found that blind and low-vision users suffer three times as bad usability problems as sighted users, so it’s only fair that they get one thing in their favor. When you use a browser that gives special (and appropriate) treatment to within-page links, then they can certainly be helpful. The most common use of “skip links” is a link on the top of the page that moves users directly to the content area of the page, thus bypassing the extensive amount of crud in the form of navigation bars and other utility information. Sighted readers almost always skip this information initially, simply by looking in the content area first. Non-sighted users sometimes (but not always) like to start with the content as well, and skip-links is one way to give them this choice.

A skip-link is usually made invisible to sighted users, and thus it won’t bother people with traditional, visual browsers.

In the long run, I believe that a better solution would be to have a semantic encoding that would denote different parts of a page as content vs. navigation and include a dedicated command in screen reader software for switching between the two. These two different areas of a page need to be accessed in different task modes, and it’s almost as common to need to move from content to navigation as the other way around.

Some specialists in technical accessibility (which is a different discipline than usability for users with disabilities) suggest an alternative: place the content first and the navigation second in the file and then use CSS to reverse this order for sighted users. This is not a good idea:

• Many low-vision users alternate between visual and auditory modes of access, so they would be hurt by an inconsistent placement of the two types of information across their two browsers.
• As just stated, users also need a way of skipping from the content to the navigation, and if the navigation options are at the end of the page, you will sometimes force people to wade through masses of content that they don’t want, just so that they can get to the links to other pages.
• Blind users form mental models of websites, just as sighted users do. Blind users obey Jakob’s Law, just as sighted users do (”users spend most of their time on other sites”) Therefore, blind users have strong expectations for the structure of a website when they first arrive, and these expectations include the convention that the navigation comes first. Swapping the order of navigation and content will confuse many blind users.

• 0 Comments