The Web has changed drastically since it started as a collection of physics papers in 1991. The first two years, it was a small type-only hypertext system used by a bunch of researchers, but in 1993 the first major GUI to the Web was introduced with the Mosaic browser. Our research into users' interaction with Web sites and intranets has continued as the Web has evolved through generations of technologyfrom the gray pages in Mosaic through the colorful pages with table-based layout in Netscape to the multilayered, functionality-rich pages in Microsoft's Internet Explorer (IE), which uses JavaScript and ever-growing Cascading Style Sheets (CSS).

When we began our research in 1994, home users accessed the Internet primarily by dial-up modems with 28.8 kilobits per second (Kbps) throughput, while today most home users in the United States and many other countries have so-called broadband connections running at a few megabits per second (Mbps). (We refer to current cable modems and Digital Subscriber Lines, or DSL, as "so-called broadband" because they are still not as fast as we would ideally like in order to offer an optimal user experience. Fiber-to-the-home service will eventually give us hundreds of Mbps, and that's when we will be able to talk about a truly broadband Internet.)

Haven't these substantial technological advances caused radical changes in usability issues as well? Mainly, the answer is "no." Usability guidelines remain remarkably steady through generations of technology because usability is a matter of human behavior, and people don't change much from one decade to the next. In fact, the great majority of users today are the people who were using the Web ten years ago. Their characteristics are about the same, as are their behaviors. Human short-term memory holds only about seven (plus or minus two) chunks of information, and the last time this design constraint changed was probably at the time of the Neanderthals.


Seven of the 34 original usability problems have become less important today because of changes in browsers, bandwidth, or other Internet technology.




Still, seven of the 34 original usability problems we named have become less important today because of changes in browsers, bandwidth, or other Internet technology. These improvements have somewhat reduced problems with

In this section we look at those problem areas that lost skulls due to improved technology. Remember that skulls indicate the amount of trouble a usability problem causes. Fewer skulls imply less trouble, and that's indeed a happy side effect of some of the technological advances that have been made since we started developing usability guidelines in 1994.



1986 Air Force Guidelines Stand the Test of Time



From 1984 to 1986, the U.S. Air Force compiled existing usability knowledge into a single, well-organized set of guidelines for its user interface designers called Guidelines for Designing User Interface Software, ESD-TR-86-278. Jakob Nielsen was one of several people who advised the undertaking. The project identified 944 guidelines, most of them related to military command and control systems built in the 1970s and early 1980s, which used mainframe technology.

You might think that these old findings would be irrelevant to today's designers. If so, you'd be wrong. As an experiment, we retested 60 of the 1986 guidelines in 2005. Of these, 54 continue to be valid today. Of the total 944 guidelines, we deduced that 10 percent are no longer valid and 20 percent are irrelevant because they relate to rarely used interface technologies. But nearly 70 percent of the original guidelines continue to be both correct and relevant 20 years later.







Slow Download Time



Download times used to be one of the most important issues in Web usability: In every study we ran, users complained about waiting for pages to download. They rarely praised sites for being snappy.


Most of the sites that grew big in the 1990s featured bare-bones designs with few graphics and fast-downloading pages. Graphic designers complained, but users loved them.




Most of the sites that grew big in the 1990s featured bare-bones designs with few graphics and fast-downloading pages. Graphic designers complained that Yahoo! (1994), Amazon (1995), eBay (1995), and Google (1998) looked primitiveor outright uglybut users loved these sites and gave them ever-more business because it felt good to get the next page immediately after each click.

On a smaller scale, our site www.useit.com grew to become the world's dominating usability site while deliberately sporting an ugly, nondesign look. In the beginning, we felt this was necessary for quick downloading, but today we have retained it as a branding approach because of its strong positive connotations for users. This is an example of how people relate to design on the reflective level outlined in Don Norman's model of emotional design.



Don Norman's Three Levels of Emotional Design



In his book Emotional Design: Why We Love (Or Hate) Everyday Things, our colleague Donald A. Norman describes three levels at which people relate to design:

The visceral level is the most immediate and is dominated by appearance. Smooth or round objects have cuddly or pleasant connotations; sharp or pointed objects connote feelings of fear or danger. Spiders give you the shakes when you spot them, and babies make you feel protective. Most visceral emotions are hardwired and triggered immediately because they are based on evolutionary advantages and survival principles. Most graphic design attempts to operate at the visceral level, evoking positive emotions as soon as we look at something.

The behavioral level is based on use of the object. How does it feel to operate it? Is it annoying or pleasant to use? Most usability issues relate to the behavioral level. Response times are a classic example of an issue that affects behavioral emotions: It simply feels bad to sit and wait, and wait, and wait.

The reflective level is based on how we think about, or reflect on, an object. Does it have positive or prestigious connotations? Does it evoke a happy memory? Branding often works at the reflective level by making people think in advance that a certain product or vendor is special.






A Crash Diet for Web Sites?



Today, it's less important for Web pages to slim down to a design that eschews all graphics. When most users have broadband connections, pages with pictures download reasonably fast. At the 3 Mbps that's typical of cable modems, the browser can download about 300 kilobytes (KB) within the one-second limit that's required for pleasant hypertext navigation. In practice, data download can't fill the entire second because there's some latency in communicating requests back and forth across the Internet. But 100 KB is certainly a reasonable page weight for fast downloads.

This means that a Web page can easily combine a fair amount of text with some formatting markup, a style sheet, and even a few small photos or other images. Initial pages still can't include a lot of big graphics. But if users click a thumbnail photo and request a bigger image, they can receive a huge 200 KB enlargement within a good response time.

Still, slow downloads have been reduced to one skull instead of zero for a few reasons. People who live in rural areas, use mobile connections, or are connecting from a hotel room that hasn't been upgraded to broadband are still restricted to dial-up. Second, even broadband users can only download so much within a second, so there's still reason to watch page weights. Finally, response times are determined by server speed just as much as they are by the number of kilobytes being transmitted. There are still too many sites running on overloaded servers that don't send out the next page view immediately.



Frames




Frames were one of the most incompetently designed "advances" in Web technology. They were bolted onto the very clean page model that was the foundation of original Web browsers and broke many interface conventions that users had grown to rely on, such as being able to bookmark a piece of information or email its URL to a friend. In early browsers, printing pages that used frames was extremely difficult, and they interfered with search engines as well.

Worst of all, frames broke the Back button in Netscape, version 2. (As discussed earlier in this chapter, breaking the Back button is a three-skull usability problem to this day, and any technology that does so can only be described as a usability disaster.) It is still best to avoid frames most of the time, but they are not nearly as serious a problem with modern browsers. The Back button works now, and printing pages with them is easier.



Flash



In the early years, we deemed Macromedia Flash "99 percent bad" because it broke the Back button, didn't work with bookmarks, and caused accessibility problems for users with disabilities.

Flash introduced several serious usability problems in its early versions. First, it encouraged gratuitous animation. ("Since we can make things move, why not make things move?") Animation clearly has its place in online communication, but that place is limited.

Second, it stopped users from controlling their own destiny. One of the most powerful aspects of the Web is that users can go where they want when they want. This is what makes the Web so usable, despite its many usability problems. Unfortunately, many Flash designers violated this principle by employing television-style presentations rather than interactive media. Regardless of how cool a presentation looks, when users are required to sit through it with nothing to do, they become bored and lose their enthusiastic for the site.

Third, many Flash designers introduced their own nonstandard GUI controls. How many scrollbar designs do we need? The world's best interaction designers worked for years testing numerous design alternatives to come up with the current Macintosh and Windows scrollbars. A new scrollbar designed over the weekend is likely to get many details wrong. And even if the new design is workable, it still reduces a site's overall usability because users must figure out how it works. They already know how to operate the standard widget.

None of these usability problems are inherent in Flash. You can design usable multimedia objects that comply with the guidelines and are easy to use. The problem is simply that early Flash design tended to encourage abuse.

After we campaigned incessantly against bad Flash, Macromedia began promoting Flash's ability to add functionality and advanced features to Web sites over the product's glitz. In 2002 a new version was launched that improved Flash accessibility and corrected most of its other usability problems, such as breaking the Back button and using nonstandard GUI controls. Flash seemed well on its way to become a positive contributor to increased Web usability.




Flash: The Good, the Bad, and the Usable




In 2002 we conducted user testing of 46 Flash designs and summarized our findings in a report that includes 117 usability guidelines for Flash. Conducting these sessions with Flash applications reminded us of our tests with the first crop of Macintosh applications in the 1980s. Many of the Flash usability issues we identified related to basic GUI concepts such as making controls obvious and easy to grab.

One of our Flash guidelines is a virtual copy of a guideline from the 1980s: You must provide generous click zones around active screen areas or users will think that they clicked something even when the computer's strict definition of clickable pixels says they didn't. We also repeated a finding from early tests of MacDraw and Lotus Freelance Graphics: When you create new objects on a drawing canvas, they should be staggered relative to other objects so that they're all visible.

Other Flash guidelines are new and irrelevant to traditional software. For example, we discovered many usability issues relating to sound and animated objects, both positivethey can indicate change and directionand negativethey can be distracting, annoying, and difficult for users with disabilities. Some Flash applications have apparently inherited bad habits from Web design.

One particular usability problem is worth emphasizing: In several applications, users missed options because of nonstandard scrollbars. A scrolling control is a standard user interface element in application design, and it should be designed in accordance with users' expectations. We did see a few nonstandard scrollbars that workednotably on Tiffany's site, which is so simplified that users couldn't miss the scroll controls even though they were fairly small and violated GUI recommendations. (These deviations caused other usability problems, but at least people used the scrollbar.) In general, users often overlooked nonstandard scrolling controls and couldn't scroll the lists to see all their options.



The welcome decline in Flash means it doesn't deserve three skulls any more. Many designers are learning to relegate Flash to when it serves a user purpose and not use it purely for show. In fact, Flash technology itself doesn't even deserve two skulls. However, we still give it two skulls because of the way other Web designers implement it. Some designers continue to ignore usability guidelines for Flash, so some new Flash actually degrades the user experience by creating obstacles that prevent people from obtaining what they need quickly.




Low-Relevancy Search Listings



Next to navigating, Search is the most common way that people find what they're looking for on Web sites. Until recently, most sites had miserable Search capabilities that didn't prioritize page hits intelligently.

Early Search software was ineffective in retrieving useful hits because it sorted listings according to how frequently users' query terms occurred on each Web page, not by their relevance. Who cares how often a term appears on a page? It's much better to place the most relevant pages on top.

For example, when a product name is searched, the core product page for that item should be a top hit, not seemingly arbitrary press releases and papers. The product page acts as the central place to get information about that product and is a springboard from which users can access to other relevant information.

Even today, few Web sites have smooth, efficient Search, and many sites return such irrelevant Search results that they ought to get three skulls for bad Search usability. However, Search on many bigger sites is useful enough to be a single-skull issue. On average, across the Web, we now give low-relevancy search listings two skulls.



Multimedia and Long Videos


Three developments have made multimedia and video clips more acceptable on the Web today. First, bandwidth has increased sufficiently to make it much faster to download videos and other media presentations. Second, the technical quality of videos has improved so that viewing them is no longer like watching jerky postage stamp-sized movies. (This is partly due to more bandwidth and partly to better media player software.) Third, Web producers have become better at creating videos and other multimedia presentations for the Web instead of using repurposed television programs.

Multimedia usability is still a problem, but much less so than in the days when we had only one guideline for Internet video: Don't do it. We still need to design multimedia that really works well in the online medium, where users tend to be very impatient. And most video clips need to be shorter than a minute, to keep their attention. Until then, this is still a two-skull problem.



Frozen Layouts



To say that a Web page has a "frozen layout" means that the information displayed on it is fixed in width, no matter what window it's displayed inside. If the window is too narrow, part of the information will be cut off and only visible after horizontal scrolling.




Teenagers: Masters of Technology?




Teens are often stereotyped as being much more comfortable and adept with new technology than are adults. While this is sometimes true, it is an oversimplification. Believing those teens are masters of technology can lead to disastrous outcomes for sites aimed at them. Teens are much more apprehensive about technology than it might seem. In fact, we have found that most teens veer away from downloading plug-ins and clicking the unknown because teachers or parents have instructed them to avoid all downloads for fear of viruses.

In addition, when online multimedia doesn't work the way young people expect it tofor example, when a video doesn't play automatically or requires complex user inputthey lose patience and blame the Web site. In our tests with teenagers, we found that they will give up rather than try to figure out how to overcome technical difficulties. Young audiences have less success with Web sites than adults do because they have less patience. And while teenagers appreciate some graphics and multimedia, they often don't have the computer setup to support them. Most of the teenagers we visited at home and school had outdated, older computers that ran slowly and lacked current software, plug-ins, and speakers.





We know from our testing that users hate horizontal scrolling and always disparage when they encounter it. That is surely reason enough to avoid horizontal scrolling, but there are two other reasons to as well. First, users expect vertical scrolling on the Web. As with all standard design elements, it's better to meet user expectations than to deviate from them. Second, when pages feature both vertical and horizontal scrolling, users must move their view port in two dimensions, which makes it difficult to cover the entire space. For people with poor spatial visualization skills, it's especially challenging to plan movements along two axes across an invisible plane. (Typically, users score lower than designers on spatial reasoning and visualization tests.) In contrast, one-dimensional vertical scrolling is a simple way to traverse content without advance planning: You just keep moving down or up.

The risk of inducing horizontal scrolling is an obvious reason not to freeze layoutsor at least not to freeze page widths to a size that's wider than most users' windows. How do you know how big your users' browser windows are? If people maximize their windows, then browser width can be derived from monitor width, and most people currently have screens that are 1024-pixels wide. In the future, bigger monitors will be more common, and many users already have monitors that are 1600-pixels wide or wider. People tend to utilize the space on these big screens to show multiple narrower windows, however, instead of enlarging one window to fill the entire screen. But frozen layouts are undesirable even if the page is narrower than the user's window. The user loses the benefit of having a big monitor because the page doesn't expand even when more space is available.

Frozen layouts cause usability problems, but they have dropped in severity from three to two skulls because of the increased prevalence of big screens. It's very rare for a site to have frozen pages wider than the 1024 pixels of most users' monitors. As an alternative, however, we recommended a "liquid layout"a Web page that expands and contracts with windows so that it's always exactly as wide as the browser, neither more nor less. Users with sufficiently big monitors who want longer lines of information can have them, and those who prefer reading shorter lines get those.



Cross-Platform Incompatibility



Worldwide sales of PCs reached 183 million in 2004. Of these, only three million were Macintoshes, leaving the Mac with two percent of the market. Going forward, the Mac will probably continue its decline because most of the growth in Web use will come in countries where Apple has little or no presence. (Apple's market share is 3 percent in the United States, 1.5 percent in Europe, and about 1 percent in the rest of the worldwhere the growth is.)

Is it worth testing your Web site on the Mac in order to cater to that two percent of the market (three percent if you are a United States-only site)? We would probably still say "yes," at least for bigger Web sites for which a two percent increase in business is worth more than a few tests and easy fixes. Smaller sites, on the other hand, might decide that the financial return is insufficient to bother testing on the Mac. As always, with a limited budget, you must choose your battles.

For Web sites, cross-platform compatibility means the ability to work on different browsers, not just on different computers.

Cross-platform design is still of some importance, which is why we give it two skulls. We had reduced this guideline to one skull in presentations we gave in 2005, but it's been bounced back up because of the success of the Firefox browser. For Web sites, cross-platform compatibility means the ability to work on different browsers, not just on different computers. After Microsoft wiped out Netscape in the original browser wars of 1997 to 2002, almost all users employed Internet Explorer, version 5, drastically reducing the need for a site to work across browsers. With little competition, Microsoft reduced the pace of new browser releases, so there was also not much need to test across browser versions. As of 2003, only two percent of Internet users were on version 4 browsers, so it was getting to be reasonably safe to ignore them. By 2006 even these last holdouts had abandoned version 4at least as far as can be measured reasonably. In 2006, Internet Explorer, version 5 had become the minority browser, with five percent of users. Such is the cycle of life.

It saddens us to state that the Mac is approximating insignificance because of its tiny market share. Our company was cofounded by a former vice-president at Apple Computer, Don Norman, and one of our other colleagues, Bruce "Tog" Tognazzini, wrote Apple's first human interface guidelines. We were happy and loyal Macintosh users for 12 years; Nielsen got his first Mac in 1986 and even used a Lisa in earlier years. Still, business is business, and you gotta go with the numbers, not with your memories.

Our general advice is to wait five to six years after the launch of a new browser version before you stop caring about the previous one. For example, IE 5 was launched in 1999, so you could safely ignore version 4 in 2004. IE 6 was launched in 2001, so you can probably start ignoring IE 5 in 2007. IE 7 was introduced in 2006, so you probably will need to support IE 6 until 2012. (The five-to-six years rule is useful for long-term planning; to actually make the decision to stop supporting a browser, check your server logs to see what percentage of your current customers employs that version.)

More recently, new browsers such as Firefox, Apple's Safari, and Opera have gained some market share, and Microsoft has resumed development of Internet Explorer and is launching new versions. This means that at any given time, a Web site will be visited by users on several different versions of IE, as well as by people using third-party browsers, including earlier versions of these browsers.

Given this renewed diversity in the browser space, you might imagine that cross-platform incompatibility would remain a three-skull problem. Not so. Advances in technology came to our rescue and reduced the status of the cross-platform problem. New browsers are more standards-compliant than the browsers in the 1990s, so it's more rare for a Web site to work in one browser and break in another. Breakage still happens, so you should test your site in several browsers and several versions, but the problem is not nearly as bad as it used to be.

Even though we credit technological developments for the reduced skull rating, designer restraint is also partially responsible. Heavy-duty cutting-edge design is rare these days, which is good because such it is more likely to fail in minority browsers.



Mobile Devices: A New Argument for Cross-Platform Design?


We used to think that the growing prevalence of mobile devices with Internet access would be a strong argument in favor of cross-platform Web design. After all, cellular phones, Blackberries, PocketPCs, and other handhelds are very different from PCs and won't display sites that are coded too narrowly for a big-screen environment. Our studies of users accessing mobile content and services have convinced us otherwise. Mobile is so different from PC that it really requires a separate Web site with a much simplified user experience.

Cross-platform really only means "across fairly similar platforms." Mac vs. PC vs. Linux? Yes, they are similar enough that one design should work for all three. IE vs. Firefox? Same thing. Fourteen-inch monitor vs. 28-inch monitor? Again, the same site ought to work when there's only a factor-four difference in available pixels, especially since users with huge monitors tend not to maximize windows and spend all their pixels on just one.

On the other hand, there's a factor-eight difference in screen size between a Treo smartphone and a smallish 1024-by-768 PC monitor, and that's simply too much for the same user interface to scale nicely. A more traditional cell phone display is 31 times smaller than the desktop monitor. This gap is so huge that a single user interface simply can't scale and provide good service to both classes of users.