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.
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.
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 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.
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.
Nonstandard scrollbars are almost always a bad idea, but our user testing has revealed a few nonstandard designs that work well. The small gray triangles on the Tiffany site work because the site is so sparse and elegant that these GUI controls stand out despite their size.
Despite such good intentions, however, most of the Flash that we encounter on the Web today is still bad, with no discernible purpose beyond annoying people. The one bright point is that Flash intros are almost extinct. They are held in such low esteem that even the most clueless Web designers won't recommend them, although a few (even more clueless) clients continue to request them.
Flash should not be used to jazz up a page. If your content is boring, rewrite it and hire a professional photographer to shoot better photos. Don't make your pages move.
Flash is a programming environment and should be used to offer users additional power and features that are unavailable on a static page. It should not be used to jazz up a page. If your content is boring, rewrite it and hire a professional photographer to shoot better photos. Don't make your pages move. It doesn't grab users' attention; it drives them away. Using Flash for navigation is not a good idea either. People prefer predictable navigation and static menus.
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.
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.
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.
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.
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.