Understanding Web Usability

One of the great things about the Web has always been its democratic nature. Anyone can participate. But once you do, your contributions are wide open to public scrutiny. Good or bad, someone will evaluate your Web content.

People Recognize Poor Design
In the Web's early days, when people were adjusting to this new medium, most online critiques applied to a site's design. If you created a really ugly site, before long your handiwork would end being featured on a site dedicated to bad design, or even included on someone's all-time list of bad sites. Today, the collaborative features of the Web 2.0 environment such as blogs, forums, and widely used folksonomies practically guarantee that truly awful design will receive the recognition it deserves. Such criticism can be constructive; people can learn from good examples of what NOT to do.

Today, blogs and wikis extend their democratic and educational influences beyond site design to site content. This can be tough on the writer who wants to explore new ideas. But as Wikipedia, one of the best example of online collaboration, advises all contributors:

If you don't want your writing to be edited mercilessly or redistributed by others, do not submit it.

This is excellent advice, because the collaborative search for truth online is not subject to parliamentary or academic niceties. If someone advances a weak argument, people will be quick to point out its flaws. And an unpopular opinion can produce flaming responses.

Is Web Usability a Sham?
For example, last week Ryan Stewart, who has his own blog, and also writes a ZDNet blog about Rich Internet Applications (RIAs), wrote that Usability on the web is a sham, arguing that ...

While accessibility and standards are great for the Web, the concept of usability has been overblown. Usability as we define it is basically the rules for how the Web should behave while in the confines of the Web browser. But Web applications don't have to exist inside the browser and relegating them to these antiquated notions of usability is bad for progress.

To support this argument, he used the Back button as an example of a browser usability problem that RIA developers could eliminate altogether.

I think the central idea behind his argument was that the RIA technologies -- because they offer the developer more options -- can be applied to deliver usability improvements in Web-based applications. But I'm afraid he expressed it very poorly, first by over-generalizing in his criticisms of the concept of Web usability, and second by trying to use the Back button -- one of the most intuitive and widely-understood browser conventions -- as an example of poor usability.

Naturally, his post has been generating a small firestorm of responses ranging in tone from expletive-laden outrage to carefully-argued disagreement. In their different ways, both those examples (along with other responses) argue that Stewart's post is full of opinions and assertions that are not supported by any evidence, and that (to put it bluntly) Stewart doesn't really know what he's talking about.

Marshaling the Right Skills
Unfortunately, this is a common problem in the field of Web design. An effective online application must be available, responsive, easy to navigate, and deliver value to its user. This demands a wide array of skills rarely found in a single individual. As a result many sites are designed and built by people who are aware of only a small subset of the issues they should be considering. And all too often, someone in the site development process -- a business manager, someone in marketing, a Web designer, or a site developer -- makes key design decisions without understanding the consequences. And the challenges are even greater when developing a Rich Internet Application.

Simply getting more people involved isn't the solution. Some really bad Web site designs have been the result of design by committee. Even if you follow a good checklist, like this one by Vitaly Friedman, you will overlook some important aspect -- often site performance. The problem is the sheer breadth of knowledge required to do a good job. For evidence, read the Wikipedia entry on Web Design. It's an unbalanced, poorly organized, collection of information that offers little help with the process of creating an effective site.

The only answer is to get better, more knowledgeable, people involved. Start with a good overview of the process, like Usability for the Web: Designing Web Sites that Work by Tom Brinck, Darren Gergle, and Scott D. Wood. As they say in the book's introduction:

To ensure high usability on our own Web projects, we defined a development process that incorporates proven techniques from software and usability engineering, graphic design, project management, and other disciplines. The process had to be practical and lean. It had to allow us to work on multiple projects of varying sizes with fixed budgets. It had to help us keep track of the details that can kill usability and destroy profitability. This book is about that process.

Then find people who understand what the book is talking about to do the work -- and don't interfere!

Tags: Usability, Web design, Worst website, Ryan Stewart, Rich Internet Application, RIA, performance.

Web Design and Mouse Rage Syndrome

Have you ever been frustrated at a Web site that downloads with the speed of an Alaskan glacier? Or become angry when a favorite site, or your Internet connection, is down. Have you experienced any of these symptoms:

• Faster heart rate?
  
• Increased sweating?
  
• Furious clicking of the mouse?
  
• Simultaneous clicking and cursing the screen?
  
• Bashing the mouse?

Come on now -- admit it! Maybe some of them, just once or twice? Because if any of this sounds familiar, you're not alone.

Mouse Rage Syndrome
The consequences of poor Web site performance don't usually make news, unless there's a big outage on Black Friday or Cyber Monday. Then the story invariably focuses on the business lost by companies whose sites were overloaded or down. But what about the effects of poor performance on customers? A recent study by the Social Issues Research Centre (SIRC), an independent, not-for-profit organisation based in Oxford, UK., provides this perspective.

Researchers found that badly designed and hosted websites cause stress and anger, and coined the term "Mouse Rage Syndrome" (or MRS). They concluded that five key IT flaws in the way websites are designed and hosted may lead to harmful health effects.

Those five problems will come as no surprise to any regular user of the Web: slowly loading pages, confusing layouts, excessive pop-ups, unnecessary advertising, and site unavailability. But as I was saying in my previous post, it is not fair to blame IT for these problems, when most of them are the result of poor design choices by Web site designers and developers.

Damaging Customers' Health
The study combined data from a YouGov poll of 2,500 people with physiological tests on a separate sample of Internet users, who were asked to find information from a number of different websites. Tests measured physical and physiological reactions to website experiences, looking at brainwaves, heart-rate fluctuations, muscle tension and skin conductivity. According to the report:

When the test participants came to the 'problem' sites that we had deliberately chosen as comparisons for the 'Perfect Website' evaluation exercise [a prior study], responses changed quite dramatically in most, but not all, cases. While a few managed to stay calm and simply 'rise above' the problems presented by crazy graphics and slow-loading pages, others showed very distinct signs of stress and anxiety.

Some changes in muscle tension were quite dramatic...While this was happening, the participant's faces also tensed visibly, with the teeth clenched together and the muscles around the mouth becoming taught. These are physically uncomfortable situations that reduce concentration and increase feelings of anger.

These reactions, if not managed, can eventually lead to other, more serious, health problems.

Poor Designs Can Kill
According to the SIRC report, "users want Google-style speed, function and accuracy from all of the websites they visit, and they want it now. Unfortunately, many websites and their servers cannot deliver this". The result is consumers seeking alternative websites in a bid to avoid undue stress and Mouse Rage.

Jacques Greyling, managing director of Rackspace Managed Hosting, who commissioned the study, commented:

We believe that businesses that are selling online have a duty to their customers to ensure that the experience is as stress free as possible. The public has shown that it wants to buy online, ... (so) businesses need to provide simple and easy to navigate layouts, whilst focusing on speed and uptime.

If more studies confirm these findings, which will probably seem obvious to anyone who spends a lot of time online, maybe more Web designers will get the message that their poor designs are not just killing the business. They could be killing people -- really.

Performance Matters!

Tags: Social Issues Research Centre, SIRC, YouGov, mouse rage, Web design, performance, Web performance management, health.

Yahoo! on Web Page Performance

A recent post by Tenni Theurer, who works in a performance team at Yahoo!, appeared in the Yahoo! User Interface Blog. The post begins with the claim that ...

... most of web page performance is affected by front-end engineering, that is, the user interface design and development.

Theurer introduces the Pareto Principle, commonly known as the 80/20 rule, which states that 80% of the consequences come from 20% of the causes. In the case of Web page download time, she argues that the backend systems which generate an HTML document -- apache, C++, databases, etc. -- should be regarded as the 80% of causes that account for only 20% of download time. The other 80% of download time is spent fetching the elements that make up the page, such as images, scripts, and stylesheets.

She presents two graphics to illustrate this point. A table summarizing home page measurements of 8 popular Web sites -- Yahoo!, Google, MySpace, MSN, eBay, Amazon, YouTube, and CNN -- shows that retrieving HTML accounts for between 5% and 38% of their download times, and just 12% on average. The other 88% is taken up downloading and rendering other page elements.

Waterfall Charts
To illustrate the reason why HTML accounts for such a small percentage of all page download time, Theurer uses the diagram shown here [click to enlarge]. I call this kind of data visualization a 'waterfall chart', because of its shape, and because it is similar to the way the waterfall model of software development has always been always depicted graphically.

Theurer says (in blog comment #22) she used the IBM Page Detailer tool to get the measurement data shown in this diagram. I have used this tool, and it produces a Chart Panel similar to the one above, which is a graphical representation of all of the component downloads that make up a single page.

I have not seen much documentation online, but if you take the time to register with IBM and download the software, its Help file is quite informative. It explains that the ...

... IBM Page Detailer attaches to the workstation TCP/IP socket stack and monitors all of the HTTP/HTTPS protocol based communications between your Web browser and the network. IBM Page Detailer then displays web activities in a series of color-coded bars.

It also has quite a long section on Results Analysis and other Considerations regarding Web download times.

This kind of analysis is not new. Since 1998, Keynote has offered a similar Web Content Diagnostics feature in its MyKeynote portal -- here's a datasheet describing the newest version of this service, recently released. For example, the figure on the right [click to enlarge] shows a Keynote diagnostic measurement of the Yahoo Search Marketing page.

Unlike the IBM Page Detailer, which always measures from the desktop where it is installed, Keynote's diagnostic measurements can be taken from anywhere on the company's worldwide network of 2500 measurement computers (or "agents"). This example comes from an agent located on the Verizon network in Houston.

The Lesson for Web Designers
Even without looking at the data in any detail, the message of these waterfall charts is evident from their general shape:

Web page download times rise with the number of bytes to be downloaded and with the number of separate content elements comprising a page.

This fact is not news to anyone whose job involves monitoring or managing site performance. Even for a Web page consisting only of a single HTML file, you cannot compute download time simply as page size divided by bandwidth. That's because of the way the TCP slow-start protocol works, sending one or two packets (typically 1.5Kb - 3KKb), then doubling, and doubling again, up to the receive window size of the client.

But most Web pages these days contain many imbedded graphic objects, CSS files, and script files, all of which extend download times. Most of these files are small, requiring just a few TCP packets to transmit. But every transmission requires a separate "Turn", adding another round-trip delay time (RTT) from the client (i.e. browser) to the server(s) and back. This behavior has been widely documented and is well-understood by performance specialists:

• In a previous post here, I described the Web Site Response Time Model and linked to the CMG2000 paper (E-Commerce Response Time: A Reference Model) in which I introduced it.
  
• In 2001, Peter Sevcik and John Bartlett of NetForecast published their paper on Understanding Web Performance, in which they first outlined a formula for computing Web page download times based on total bytes, the number of components, and on round-trip times between browser and server(s).
  
• That formula was simplified and explained in a highly readable paper by Alberto Savoia -- Web Page Response Time 101 -- published in July 2001 in STQE, the magazine of software testing and quality engineering (now Better Software Magazine).

Since then, many articles and papers have reiterated this message. An entire industry segment -- Application Delivery Systems -- has emerged to help organizations offset delays in delivering their Web pages and satisfy customers' expectations of responsiveness. All the same, as is clear from the comments posted to the Yahoo! User Interface Blog, some Web designers and developers still need to learn this lesson.

Tags: Yahoo, Pareto principle, 80/20 Rule, performance, Web performance management, IBM Page Detailer,Keynote, page size, round trip time, RTT, TCP, slow start.