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!

Several issues have been discovered since publication which, depending on your requirements, can cause severe problems when using the equal height technique.

1. Linking to anchors in elements within the containing block
2. Selecting and scrolling in Gecko-derived browsers
3. Printing in Internet Explorer

Linking to anchors in elements within the containing block

Linking to an anchor in any of the columns within the element that has been set to overflow: hidden causes the content of that column to shift upwards. In IE and Firefox, that is.

Example of anchors in the equal height method

ie. it’s not the large padding that’s casuing the problem (though obviously it is the trigger of the behaviour)

A fix for IE

Fix for anchor problem in IE

IEs 6 and under are easy. Simply suppress the overflow: hidden on the containing wrapper element.

IE7b thought doesn’t work since overflow:visible makes the overflow of the columns, well, visible. So we use an expression instead, making the columns the height of the column container.

However, there are dragons here…

1. If we use the exact height of the wrapper, things can explode on first load or, absolutely without fail, when refreshing the page using F5. We can be worked around by taking a pixel off. Then the shorter columns are still shorter requiring the footer to be shifted up a pixel for good measure.
2. Of course, it will fail utterly if the security level is such that expressions don’t get evaluated or at the very least annoy the hell out of users with a prompt to allow the expressions to be evaluated…

So if you don’t like those dragons, you might prefer to force IE7 into Quirks mode. ^[1]

No cure for Cancer

…or rather, there appears to be no fix for Gecko-based agents. I had thought shifting the padding and negative margin to the top (like for the Opera 8 fix) would sort things out, but once Gecko knows that the box is larger than what’s displayed the anchor shifting occurs.

Half a cure for Geckos

Half fix for anchor problem in Gecko

Ingo Chao has come up with a solution that works as long as certain conditions are met - the trick is to apply position:absolute to the target.

For anchors of the form <a name="target"></a>, this presents no problems. If the target element can stand being absolutely positioned, everything will be ok. Obviously though, attempts to apply the same technique to an anchor which is actually an id on an element enveloping content will result in dismal failure. And for many off-the-peg blogs and CMSes, that’s probably going to be the case.

Furthermore, the parent element of the target must not have position:relative applied to it, which also somewhat reduces the usefullness of the technique.

What the hell is going on?

Weirdly, just to add spice to the whole over-egged pudding, when used in equal heights mode, Opera 9 doesn’t shift. But with the following reduced test case, it does.

Two distinct behaviours can be seen in the previous reduced testcase.

Behaviour A

the content shifts within the element to reveal the triggered anchor
Mozilla since 1.6a, IEs 5.01 through 6 and Opera 9b

Behaviour B

nothing happens
as seen in Safari, IE Mac 5, Mozilla 1.5 and earlier, and Operas pre v 9

The question is, are current Geckos, IE and Opera 9 correct in their handling of the above example? What do the specs say?

This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region.

CSS 2.1, 11.1.1 Overflow: the ‘overflow’ property

So does that mean that the content can be scrolled (though no interface should be provided) which is what Firefox and IE are doing, or does it mean that no scrolling should occur? But how would the latter jive with scrolling the content via scripting (which is surely meant to be allowed)?

Sorry. Not fair. It’s a bogus question. In the words of the editor of the CSS specs, Ian Hickson, “The spec doesn’t define what happens with anchors.” So, let’s play detective and figure out when (and hopefully why) the behaviour changed in Mozilla and Opera.

For Opera, the answer is fairly easy to track down thanks to a note in the changes log, under the heading “Acid2 Fixes”…

Elements with overflow:hidden; can scroll to anchors within them.

…which was done presumably (remember the specs say nothing about how an agent should handle anchors) because unless they scrolled to the anchor on the test page, nothing would show at all and so they would fail the test at the first hurdle.

Safari has taken a different route to passing the test - by making the html element scrollable when overflow property is set to hidden, but not doing so for any other element.

Of course there’s nothing to say which of these paths (if either) is correct. There’s nothing in the Acid2 guide reference that mentions testing for such behaviour and the only comment about the use of overflow:hidden; on the html element is:

/* page setup */
  html { font: 12px sans-serif;
  	margin: 0; padding: 0; overflow: hidden;
  /* hides scrollbars on viewport, see 11.1.1:3 */

The Second Acid Test

…which leads us back to that section of the CSS specs which, er, has nothing to say about the treatment of anchors.

So how did the test get into Acid 2? What is its purpose? Fortunately a little bird was able to tell me that Ian Hickson was the lead in constructing the Acid2 test. So I asked him why it was set up that way, with the content hidden and being scrolled to, and whether this was an intentional part of the test, or it just happened that way because that’s how Mozilla and IE handled it

Hmm. I didn’t think about how anchors interacted with the overflow:hidden text and just assumed it would work. :-)

The reason I used overflow:hidden at all was to test make one of the browsers implement overflow:hidden on the root element, because authors were complaining it wasn’t supported (I don’t remember which one any more, probably Opera). Also, I needed to have scrolling to test fixed positioning, but I didn’t want to show the scrollbar.

via personal correspondence

Incredibly dull downloading of many many copies of old versions, followed up by combing through the bug tracking system eventually gave up the point where Mozilla had begun to scroll overflow:hidden, which in turn pointed to bug 221140 which gets us towards the heart of the matter.

The basic problem here is that ’scroll’ and ‘auto’ have never worked on table cells, and the working group decided to make ‘hidden’ work like ’scroll’ and ‘auto’, so now ‘hidden’ doesn’t work either.

Bug 221140 - ‘overflow: hidden’ on table cells broken, comment #4

Of course, the question of exactly what and where the working group had decided is moot. Let’s have another look at our old friend 11.1.1, the overflow:hidden definition (remembering that it says nothing about how user agents should deal with anchors):

This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region.

CSS 2.1, 11.1.1 Overflow: the ‘overflow’ property

Previously the same section had been:

This value indicates that the content is clipped and that no scrolling mechanism should be provided to view the content outside the clipping region; users will not have access to clipped content. The size and shape of the clipping region is specified by the ‘clip’ property.

CSS 2, 11.1.1 Overflow: the ‘overflow’ property

Do these changes to 2.1 mean that Behaviour A is correct and were they introduced for exactly such a situation?

Prodding Ian Hickson again, I got the following explanation:

It was changed in issue 1-16, around July-September 2003. But it was made in response to an W3c-internal-only comment, so that won’t help you…

… I imagine the reasoning was “to make CSS compatible with the Web”, which already behaved that way.

… It was probably more “browsers won’t change their behaviour to match the spec because doing so would break Web pages, so we’ll change the spec to match the browsers instead”. (This reasoning is the thinking behind much of the changes to CSS2.1. Pragmatism is an important factor in the development of the CSS2.1 and HTML5 specifications.)

via personal correspondence

A bit of a mess…

So to sum up, the situation is happenstance yet quasi-official. That’s how IE did it, so the W3 working group and Mozilla followed suit. And Opera followed along later to pass a test that reflected that status quo.

Consequently there’s nothing to say that Safari’s divergent behaviour (scroll on html element, no scroll on any other) isn’t correct. Or what the behaviour should be if a box that overflow: hidden is applied to is tall enough to show all the content within it, but there is additional padding-bottom beneath it…

La Chatte Noire example 1

La Chatte Noire example 2

And Bug 259615 - ‘overflow: hidden’ elements shouldn’t be scrollable by the user probably shouldn’t really be a bug. But Bug 325942 shows that some of the Mozilla team think it should.

Recommendations

Sorry, I don’t have any recommendations. Really. It’s up to you to decide what works for you, just like you should decide what browsers you should support. That said:

• Use of the method in situations like the Tucows example where the technique is used just for a component of the page will be solid. (ie. just place any anchors you might need before or after the columns)
• Use for whole page layouts will be solid if you can guarantee that you won’t need to use named anchors within the columns.^[2]

If you can’t guarantee the absence of anchors, then you’re probably going to be better off going with faux columns or a javascript-based solution.

Of course, if Mozilla supported multiple background images this would all be irrelevant… Or if Mozilla could apply position: absolute to generated content properly…

Selecting and scrolling in Gecko-derived browsers

Drag to select content within the longest column and keep dragging downwards - if the bottom of column is above the bottom of the viewport there is no problem. If it’s below the bottom of the viewport then it keeps scrolling, shunting the content of all the columns upwards and very rapidly at that so that in all likelihood it just vanishes. (It is possible to scroll it back if some of the content is still visible and selectable - but that’s an academic point since in reality the average user is going to be just as foobarred as if all the content had dissapeared)

Fixed as of Firefox 1.5 and Camino 1.0, so this is basically a non-issue.

Printing in Internet Explorer

A less serious problem (unless you’re being bitten by it) is that it can cause printing problems for IE. Depending on the exact values used for padding-bottom and margin-bottom, the content in the columns can shift upwards and even disappear entirely. The answer to this problem is to suppress the negative margin-bottom (and consequently the padding-bottom too) in a print style sheet. You shouldn’t be printing the backgrounds in any case ;)

Do not ask for whom the bell tolls

So, the end result may be that the actual usefulness of the equal heights technique is in exposing flaws in certain rendering engines (whether it’s Safari and Opera or Explorer and Gecko that get it wrong I leave for others to decide).

Fortunately for me, it’s the technique that I’m least concerned about since there’s always Faux Columns to fall back on. And even more fortunately I covered myself in the article by saying that Faux Columns would probably remain the weapon of choice ;)

Browser	Shifts on anchor trigger	Scrolls on select drag
Firefox 1.5	Yes	No
Firefox 1.07 NS 7.2	Yes	Yes
IE 6	Yes	No
IE 5.01 (+ 5.5 ?)	Yes	No
Opera 9b	Yes	No
Opera 8.5, 8.0, 7.54, 7.23, 7.1, 6.06, 5.11	No	No
Safari 2.0, 1.03	No	No
iCab 3.01	No	No
IE 5.23 (Mac)	No	No
NS 7.1, 6.23, 6.1	No	No

 

1. Alternatively there’s an equally trivial fix for IE 5.01 and 5.5. Give the column wrapper a height and then set the columns to be 100% high. IE 6 would obviously be the same in Quirks mode, but in Standards mode that doesn’t work. So we’d need to use the same type of expression as for IE7 instead, making the columns the height of the column container, with all the same caveats mentioned above. along with an additonal one that changing the font size can cause IE6 to go screwy. Of course, I don’t recommend this over the above-mentioned method, but just so you know. There might be a situation where you can’t rely on expressions and don’t mind being in Quirks mode…?
2. Incidentally, a certain celebrated ascetic mad monk, er, usability expert, has decreed use of anchors considered harmful.?

 

 

(Position is Everything)

• 0 Comments

Within-Page Links Violate Users’ Mental Model

On websites, within-page links are bad for the same reason that PDF files are bad entered without warning in the top-ten design mistakes. Users have developed a strong mental model for link following, which has several elements:

1. Clicking a link navigates you to a new place.
2. After you click, the old page goes away.
3. A new page loads into the window, replacing the old page.
4. You first see the top of the new page.
5. The Back button returns you to the old page.

Because almost all clicks work this way, users have very strong expectations that the Web will work this way. It’s a simple model that makes sense. Within-page links violate all five points in users’ mental model of links:

1. A within-page link scrolls the window rather than navigating you to a new location. This confuses users: they assume they’ll get new information, but if they’ve scrolled through the page before clicking, they’ll get stuff they’ve already seen.
2. The old page doesn’t go away; it’s still in the window. However, because users think they’re on a new page, they’ll try to figure out how the “new” information differs from what they’ve seen — obviously, a futile task.
3. No new page is loaded into the browser window: it displays the same data, just scrolled differently.
4. Rather than land at the top of the page, you typically find yourself somewhere in the middle with no navbar or other expected top-of-page design elements.
5. Clicking Back doesn’t take you to the previous page; it takes you to the previous scroll state of the same page. This can doubly confuse users who’ve scrolled to the top of the page before clicking Back.

After experiencing a few within-page links and Back button clicks, most users are completely confused about where they are on a site. Our studies also show that such links typically waste far more time than they save because users click back and forth multiple times and repeatedly review the same material.

When Within-Page Links Are OK

To avoid confusing users, you must communicate exceptions to their expectations in advance. It’s okay, for example, to use mailto links, as long as you clearly indicate that the links will activate an email program rather than navigate users to a new page. You can signal this through link format (”donald@duck.com“) or wording (”send an email to customer support“). Similarly, if you absolutely must use within-page links, say so. For example, add a short statement that says something like: “Clicking a link will scroll the page to the relevant section.”

Assuming you warn users, within-page links have three acceptable uses. First, with long alphabetized lists, you can show the letters of the alphabet across the top of the page and have each letter link to the appropriate place in the list. Second, in frequently asked questions lists (FAQs), you can list the questions at the top of the page and make each question a link that scrolls the page to the associated answer. Third, there are a few other cases where you can start a page with a table of contents that links to the appropriate sections further down the page.

All three exceptions share a common format: a long list of items summarized at the top of the page, with links taking users directly to the desired items.

Even with this scenario, it’s best to avoid within-page links if possible. You might, for example, make the lists short enough that users can easily scroll them. Only for very long pages will the time saved be worth the confusion that within-page links can cause.

For example, we recently tested a website that listed information for each of the fifty US states on a single page. Above the fold, the page displayed a map of the US with instructions that told users to click on their state.

First off, it’s usually a bad idea to ask users to select their state or country by clicking on a map. While it works well for those of us in big states like California, take pity on folks from Rhode Island or Connecticut. (The same argument applies, for example, when asking users to pick their country from a map of Europe: fine for German users, less ideal for Belgians.)

Assuming users have sufficiently steady mouse hands to click their particular state, our example page scrolls accordingly. If users click a state in the middle of the alphabet (say, New York), the state appears at the top of the window and users can easily find their information. Unfortunately, if they click, say, Wisconsin, they’ll typically find Tennessee on top of the screen, because that’s as far down as the page will scroll. This causes confusion: “I clicked Wisconsin, but it says Tennessee?”

In this case, because each state has only a few data items, it would be better to simply let users scroll through the page to find their state. Sure, that’s annoying if you’re from Wyoming, but it actually requires less time to simply scroll than to read and understand the non-standard instructions for clicking the map. After all, people arrived at such pages by clicking links like “Information about foo by state“; they expect to see a list of states, and know where to find their own state in the list.

Linking to Named Anchors Across Pages

Using named anchors to link to a specific place on a different page is not as bad as using within-page links on a single page. When you link to a named anchor on a different page, you retain four of the five expectations in users’ mental model: they navigate, the old page disappears, a new page loads, and they click Back to return to the old page. The remaining expectation is the only problem: instead of going to the top of the new page, users are typically dumped into the middle.

While it’s certainly better to violate only 20% of the mental model, violating user expectations is still a bad idea. Dumping users in the middle of a page causes usability problems because users need to situate themselves when they land on a new page. A page’s headline, introduction, and navigational apparatus provide essential context to that end.

Nonetheless, named anchors are tempting. At the top of this page, for example, I have links to various articles because I refer to points made within them. I refer to those mistakes in the Top Ten Web-Design Mistakes article. While it could be advantageous to directly link to these two sections, direct links also have disadvantages.

Say, for example, I linked to a named anchor for #6, which is about JavaScript in links. Sure, you’d see this point first, but further down your screen you’d see #7, which is about adding infrequently asked questions to a FAQ. That’s an odd continuation of a JavaScript discussion, don’t you think? That’s the penalty of starting users in the middle of a page when they don’t understand what the page is about.

The best solution in such cases is to create separate pages for everything that serves as a link destination.

So: you should avoid named anchors and within-page links because they violate users’ expectations for hypertext linking on the Web. A link should bring up a new page. Deviating from this model requires an explanation; you should only deviate if it will save users significantly more time than they’ll waste pondering the non-standard interaction technique.

• 1 Comment

The ten most egregious offenses against users. Web design disasters and HTML horrors are legion, though many usability atrocities are less common than they used to be. This article presents the highlights: the very worst mistakes of Web design. (Updated 2007.)

1. Bad Search

Overly literal search engines reduce usability in that they’re unable to handle typos, plurals, hyphens, and other variants of the query terms. Such search engines are particularly difficult for elderly users, but they hurt everybody. A related problem is when search engines prioritize results purely on the basis of how many query terms they contain, rather than on each document’s importance. Much better if your search engine calls out “best bets” at the top of the list — especially for important queries, such as the names of your products.

Search is the user’s lifeline when navigation fails. Even though advanced search can sometimes help, simple search usually works best, and search should be presented as a simple box, since that’s what users are looking for.

2. PDF Files for Online Reading

Users hate coming across a PDF file while browsing, because it breaks their flow. Even simple things like printing or saving documents are difficult because standard browser commands don’t work. 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. Worst of all, PDF is an undifferentiated blob of content that’s hard to navigate.

PDF is great for printing and for distributing manuals and other big documents that need to be printed. Reserve it for this purpose and convert any information that needs to be browsed or read on the screen into real web pages.

> Detailed discussion of why PDF is bad for online reading

3. Not Changing the Color of Visited Links

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. 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.

These benefits only accrue under one important assumption: that users can tell the difference between visited and unvisited links because the site shows them in different colors. When visited links don’t change color, users exhibit more navigational disorientation in usability testing and unintentionally revisit the same pages repeatedly.

> Usability implications of changing link colors
> Guidelines for showing links

4. Non-Scannable Text

A wall of text is deadly for an interactive experience. Intimidating. Boring. Painful to read. Write for online, not print. To draw users into the text and support scannability, use well-documented tricks:

• subheads
• bulleted lists
• highlighted keywords
• short paragraphs
• the inverted pyramid
• a simple writing style, and
• de-fluffed language devoid of marketese.

5. Fixed Font Size

CSS style sheets unfortunately give websites the power to disable a Web browser’s “change font size” button and specify a fixed font size. About 95% of the time, this fixed size is tiny, reducing readability significantly for most people over the age of 40. Respect the user’s preferences and let them resize text as needed. Also, specify font sizes in relative terms — not as an absolute number of pixels.

6. Page Titles With Low Search Engine Visibility

Search is the most important way users discover websites. Search is also one of the most important ways users find their way around individual websites. The humble page title is your main tool to attract new visitors from search listings and to help your existing users to locate the specific pages that they need.The page title is contained within the HTML <title> tag and is almost always used as the clickable headline for listings on search engine result pages (SERP). Search engines typically show the first 66 characters or so of the title, so it’s truly microcontent.

Page titles are also used as the default entry in the Favorites when users bookmark a site. For your homepage, begin the with the company name, followed by a brief description of the site. Don’t start with words like “The” or “Welcome to” unless you want to be alphabetized under “T” or “W.”

For other pages than the homepage, start the title with a few of the most salient information-carrying words that describe the specifics of what users will find on that page. Since the page title is used as the window title in the browser, it’s also used as the label for that window in the taskbar under Windows, meaning that advanced users will move between multiple windows under the guidance of the first one or two words of each page title. If all your page titles start with the same words, you have severely reduced usability for your multi-windowing users.

Taglines on homepages are a related subject: they also need to be short and quickly communicate the purpose of the site.

7. Anything That Looks Like an Advertisement

Selective attention is very powerful, and Web users have learned to stop paying attention to any ads that get in the way of their goal-driven navigation. (The main exception being text-only search-engine ads.) Unfortunately, users also ignore legitimate design elements that look like prevalent forms of advertising. After all, when you ignore something, you don’t study it in detail to find out what it is.

Therefore, it is best to avoid any designs that look like advertisements. The exact implications of this guideline will vary with new forms of ads; currently follow these rules:

• banner blindness means that users never fixate their eyes on anything that looks like a banner ad due to shape or position on the page
• animation avoidance makes users ignore areas with blinking or flashing text or other aggressive animations
• pop-up purges mean that users close pop-up windoids before they have even fully rendered; sometimes with great viciousness (a sort of getting-back-at-GeoCities triumph).

8. Violating Design Conventions

Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen. Instead, they know what will happen based on earlier experience. Every time you release an apple over Sir Isaac Newton, it will drop on his head. That’s good. The more users’ expectations prove right, the more they will feel in control of the system and the more they will like it. And the more the system breaks users’ expectations, the more they will feel insecure. Oops, maybe if I let go of this apple, it will turn into a tomato and jump a mile into the sky.

Jakob’s Law of the Web User Experience states that “users spend most of their time on other websites.”

This means that they form their expectations for your site based on what’s commonly done on most other sites. If you deviate, your site will be harder to use and users will leave.

9. Opening New Browser Windows

Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer’s carpet. Don’t pollute my screen with any more windows, thanks (particularly since current operating systems have miserable window management). Designers open new browser windows on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user’s machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don’t notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the origin will be confused by a grayed out Back button.

Links that don’t behave as expected undermine users’ understanding of their own system. A link should be a simple hypertext reference that replaces the current page with new content. Users hate unwarranted pop-up windows. When they want the destination to appear in a new page, they can use their browser’s “open in new window” command — assuming, of course, that the link is not a piece of code that interferes with the browser’s standard behavior.

10. Not Answering Users’ Questions

Users are highly goal-driven on the Web. They visit sites because there’s something they want to accomplish — maybe even buy your product. The ultimate failure of a website is to fail to provide the information users are looking for.Sometimes the answer is simply not there and you lose the sale because users have to assume that your product or service doesn’t meet their needs if you don’t tell them the specifics. Other times the specifics are buried under a thick layer of marketese and bland slogans. Since users don’t have time to read everything, such hidden info might almost as well not be there.

The worst example of not answering users’ questions is to avoid listing the price of products and services. No B2C ecommerce site would make this mistake, but it’s rife in B2B, where most “enterprise solutions” are presented so that you can’t tell whether they are suited for 100 people or 100,000 people. Price is the most specific piece of info customers use to understand the nature of an offering, and not providing it makes people feel lost and reduces their understanding of a product line. We have miles of videotape of users asking “Where’s the price?” while tearing their hair out.

Even B2C sites often make the associated mistake of forgetting prices in product lists, such as category pages or search results. Knowing the price is key in both situations; it lets users differentiate among products and click through to the most relevant ones.

• 0 Comments

In general, advertising doesn’t work on the Web, a fact that has been clear to usability researchers since 1997. Users ignore ads because they are contrary to the Web’s basic imperative, which is to let users go where they want and get their information needs instantly gratified.

From the beginning, it was also clear that this indictment of Web advertising had two exceptions:

• Classified ads work because as far as users are concerned, they are content, not advertising: people actively seek out the classifieds when they are looking to buy. This explains the success of eBay, Monster/HotJobs, and many such sites. The superiority of Web classifieds portends dire times ahead for traditional printed newspapers, as their most lucrative income source continues to migrate online.
• Search engine ads work because search engines are the one type of website that people visit with the explicit goal of finding someplace else to go. Thus, if users see an ad for what they’re looking for, there is a high probability that they’ll click that ad. Advertisers can satisfy a user’s immediate needs because they target ads based on the user’s query terms. (This also explains why ads on search engine homepages don’t work: it’s impossible to target the ad to the user’s current quest until the server knows what that quest is.)

Both are examples of request marketing: prospects have explicitly asked for the promotions they are being shown, as opposed to having unwanted messages thrown at them. Text-only ads on search engines have become particularly successful in recent years, and non-search sites are now experimenting with this format in hope of replicating that success. However, it’s doubtful that their efforts will work because non-search sites lack the equation’s crucial element: users’ single-minded goal to leave the site as quickly as possible.

From Banner Blindness to Box Blindness?

Text-only ads might continue to work better than traditional graphics-based ads for some time to come. Web users have long exhibited strong banner blindness and avoid anything that looks like an advertisement. Text-only ads don’t resemble the designs that people have trained themselves to screen out, and the resulting visibility surely contributes to the success of text-only ads. Also, text-only ads benefit from a temporary novelty effect, as does any new advertising format that people have not yet learned to ignore.

Over the long term, however, the novelty effect will obviously fade. Users might also develop box blindness, ignoring little text boxes just as they’ve long ignored banner-shaped areas of the screen. Thus, text-only ads are not guaranteed a bright future outside their native search engine habitat.

Communicative Content

Text-only ads might have one durable advantage: because they’re a low-end media format, users might take them more seriously. Being forced to express a message in a few words concentrates the advertiser’s mind, and probably leads to more communicative ads that are better focused on explaining how users will benefit from the product or service. Although there is no inherent reason that you can’t use text for mindless chatter — like “where do you want to go today?” — there is no way users will click on such ads. Ignoring users’ immediate needs is certain death on the Web.

Companies that run rich-media ads that ignore user needs can delude themselves into thinking that they’re “promoting the brand”; in reality, they’re simply being ignored because they don’t connect with people’s needs. The text-only format more clearly exposes content-free messages as useless, however, and thus might save advertisers from the bad instincts they honed on old media.

After ten years of watching Web users, one clear conclusion is that they are utterly selfish and live in the moment. Giving users exactly what they want, right now, is the road to Web success, and having to write small boxes of text encourages advertisers to travel it.

• 0 Comments

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:

CSG Systems, Inc. is a world-leading provider of customer care and billing solutions for the convergent communications industry — voice, video, and data. Our solutions are: Scaleable and Robust Modular and Integrated Efficient and Cost-effective

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