Web Techniques Magazine
June 1997
Volume 2, Issue 6

Building a Quality Web Site
Part 2

By Paul Helinski
paulh@world-media.com

In the first installment of this article, I discussed the concept of usability with regard to quality, and addressed its various components; see "Web-Site Usability Engineering, Part 1," Web Techniques, April 1997. This time, I'll demonstrate how to test for usability and avoid common pitfalls.

Jared Spool, founder of User Interface Engineering and a frequent lecturer on usability engineering, is fond of pointing out that: "...the cost of making a change or fixing a mistake rises tenfold on the day you write the first line of code. Starting on that day, any bug you fix is most likely to produce another one." For Web-site production, that tenfold increase takes place even earlier, when you map the navigation, so it's important not to skip the introductory steps I'll outline here.

Concept Prototyping

The first usability test usually occurs within your own organization. This "concept prototyping" involves three groups: the Web team, company employees who are less than Internet savvy, and customers (or in the case of an intranet, a well-distributed set of employees).

The first step, after the decision to create a Web site, is to have the department heads brainstorm a list of resources for inclusion in the project and print each one on a separate index card. The human-resources department, for example, would have cards like "job listings" and "benefits packages," while the sales department might submit "product descriptions" and "ordering information."

Now, eliminate redundant or inappropriate cards. As you do so, get input from the group of employees who are not on the Web team. Then, ask five customers whose knowledge of the product and Internet experience varies to sort the cards into piles and categorize them. Repeat the process with the Web team and the other employee group, and compare. (For more on card sorting, see Jakob Nielsen's "Interface Design for Sun's WWW Site," www.sun.com/sun-on-net/uidesign/).

The final categories are the main structural nodes and will be the labels for the top level of navigation on the home page and the button bar. Examples might include Company History, Product Info, Support, Sales, and Human Resources. Don't worry if a few index cards defy categorization; they can be left as separate entities.

Now ask the participants to sketch icons for each category (the uncomfortable artists among them can just list a few items or concepts). This will clarify their conceptions of the category names and help out the graphic designer.

Next, divide the main categories into second- and third-tier nodes, but no deeper. Most people won't click more than three levels into a site unless they are extremely interested, so save the fourth hop for lengthy content pages meant for bookmarking and printing.

When the information is well divided and clear to the whole team, flowchart or create a site map of the entire project.

Paper Prototyping

To determine whether the preliminary site map will actually work, define the navigation paths on paper. Sketch the home page and subsequent links exactly as they will appear on screen, including navigational button bars, and lay out the text in a realistic, scrolling fashion. Draw the scroll bars and hide areas that won't fit in the top 640480 pixel of a normal display.

As you prototype, put yourself in the customer's shoes: Does the site make sense? What common tasks will customers want to perform?

Now let users navigate the paper "site." Record their reactions and level of success at task completion and note any fatal design flaws or other necessary changes. If you have the resources, test more than one interface-different concepts work for different people.

Interface Design

In his book Usability Engineering (Boston, MA: AP Professional Press, 1993, ISBN 0-12-518405-0), Jakob Nielsen, Sun's usability guru, lists several requirements for a good interface:

Easy to learn.
Efficient.
Easy to remember.
Contains few errors.
Satisfying and pleasing.

Addressing each of these in turn will help avoid common pitfalls and provide a clear and consistent navigational structure.

Learnability. The most learnable sites keep important content at the top of the screen so that users can see what they're looking for as the page loads. To determine what elements should be on top, brainstorm with your customers as to why they might hit the site. Would five common questions be beneficial? What about tours for potential and existing customers?

Avoid elements that detract from learnability, like splash META REFRESH screens and fade-in colors. My first encounter with Hotwired, for example, was confusing: JavaScript boxes were exploding all over the place; mini-browser windows-meant for navigation-actually interrupted my ability to navigate; animated icons flashed angrily. As a result, I was intimidated, not drawn in.

Don't depend on icons-always print a text description so the customer won't have to guess their meaning. Icons should enhance single-dimensional concepts that might not be expressed fully in text alone. For example, at Duffer's Paradise (www.golftoo.com), a site we recently installed, the icon for men's apparel is a tuxedo shirt as opposed to a golf shirt, telegraphing the message that not all the merchandise is golf-related.

Efficiency. An efficient Web site delivers valuable information in as few clicks as possible-every link on your Web site should be scrutinized for necessity to eliminate distractions from the main message. Keep hotlinks to a minimum, and only link between documents or sections when necessary. If, for example, your company president attended Stanford, the last thing you want to do is send visitors to www.Stanford.edu. Other inefficiencies to avoid are home-page screens that say "Welcome to XYZ Corp. Click HERE to Enter" and useless links that lead to "Under Construction" pages.

Besides the absolutes I mentioned in Part 1-height, width, and alt attributes in your img tags, and the absence of frames and JavaScript status bars-there are several items that can greatly enhance efficiency:

Button bars. When users need to juggle more than one task, a central, repeated, browser-cached navigation system is crucial. Don't bother with pressed or highlighted buttons-people know where they are, and different bars for different pages disable the caching advantage. (One exception is NASDAQ, where a nifty tab that positions itself next to the current location and jumps as you jump.)

Accelerators. These provide quick results when users know exactly what they are looking for. The most effective accelerators are search boxes on the home page. We just picked up a new client who got frustrated with Rent.net because it took too many clicks to reach their property. A search form on the Rent.net home page would avoid this.

Site maps. Some people like to browse a directory hierarchy like Yahoo!'s; others prefer a CNN-style outline-like system mapping. If you're going to use site maps, don't include all of the site's contents; limit the links to two or three deep to facilitate easy administration.

Memorability. Memorability is touchy-it's important to provide a fresh look once in a while, but it's a pain to figure out a new navigational structure just to appear cutting edge. Several months ago, my favorite Web site, PCWeek Online (www.pcweek.com) "upgraded" the interface (replete with Javascript status bar that they removed, surprisingly, when I emailed them) to a snazzy, magazine-like design. The breaking stories, once at the top of the page in bold text, were now in smaller text, lower on the page, forcing me to scroll and squint. The new interface is memorable, but took some getting used to.

Errors. With freeware tools that automatically check links, like Randal Schwartz's hverify (see page 30), there are no excuses for broken links on your static pages. Set up a system of accountability for adding and removing pages, index your page links, and reflect changes in indexed entries.

With dynamic pages, it's not that simple. Accessing the correct page may depend on the variable passed to a CGI. A user may have logged in on the first visit with a user name. He or she may have come from another dynamic page, or you may have assigned a unique ID for a shopping cart. If a user returns via a bookmark without those variables, your CGI could break.

You can avoid this problem using GET rather than POST for all your form data. Be aware, however, that GET has certain limitations that POST does not. On the positive side, GET requests send the query string as part of the URL, which can be bookmarked. Also, in your CGI program, test for missing variables and redirect the user to a login page if the username variable is undefined. Add error handling to your code when you write to or open a file, for example; see the sample Perl program and a subroutine in Example 1. Note that the $sendmail location and $adminaddress must be set correctly for it to work.

#!/usr/bin/perl

## This is the file open that could break.
open(FILE, "file.txt") || &error_message($!)
## The || &error_message sends it to the subroutine.
## And this next line executes if the file opened ok.
print(FILE) "$results_of_database query";

## This subroutine sends the admin an email 
## and delivers a nice error message to the user. 

sub error_message {
        local($line) = @_;
        open(SENDMAIL, "|$sendmail $adminaddress");
        select(SENDMAIL);
print<<ADMINMAIL;
To:
From:
Subject: Error in $0

An error occurred in $0 at $line
ADMINEMAIL
        close(SENDMAIL);
        select(STDOUT);
print<<RETURNPAGE;
Content-type: text/html

<HTML>
<HEAD>
<TITLE>Sorry, server's broke</TITLE>
<BODY>
<h1>We're Sorry, the Server Broke.</h1>

An email has been sent to the administrator.  
If you'd like to be notified when the problem 
is fixed, please <a HREF="mailto:$adminaddress">
email</a> us and we'll get back to you. 
<p>
Again, sorry for the inconvenience.
</BODY>
</HTML>
RETURNPAGE
}
Example 1: A sample Perl program that includes exceptions.
A broken site is a broken site-clients and bosses don't care that it's not the administrator's fault. If you must host your site on an external ISP, check its references. Frequent crashes force a backup and can sometimes wipe out UNIX directory permissions. This is especially imperative with a realtime database administered from CGI automation systems (see my series on Web site automation, October-December '96).

Provide a mailto reply in the standard footer of the site so that visitors will be able to contact you if CGI is broken (the MIME type was altered or CGI disabled in your virtual directory).

Satisfaction. The site should be pleasing to use. Users should be able to find things quickly, download them quickly, know when they've finished a task, and want to tell a friend about the site.

Figure 1: Sun's usability-testing lab.
Involving the Customer

Figure 1 shows Sun's observation lab, where the entire Web team can watch users as they interact with the site, without injecting any stimulus into the navigation process. The lab, of course, is a luxury most of us don't have, but it's possible to mimic its functionality with two connecting rooms. Just remember not to interfere with users as they walk through the paper mock-ups.

Give your testers a task based on common customer concerns and needs, and observe them as they complete it. Time their responses and success rates with different interfaces, make improvements, and retest. Watch for fatal errors or mistakes that upset and discourage users as they navigate. Then give them a questionnaire using the Likert scale, where answers range from 1 (strongly disagree), to 5 (strongly agree). Following are some sample statements adapted from Usability Engineering:

It was very easy to learn to use this system.
Using this system was frustrating.
My time using this system was productive.
I made mistakes using this system.
This system can do all the things I need.
This system is very pleasant to work with.

Iteration is the Key

The beauty of the paper mock-up phase is that you needn't fear throwing something out-you can always start from scratch. Once it's coded, you're in too deep.

And about that coding...you may want to first set up the link structure with unformatted pages and try the interface on your test users before coding the HTML. Retest every task, with a larger group of customers if possible, make sure their needs are met, and encourage users to come up with their own tasks.

From this point, your next step is a completed Web site, hopefully a usable and successful one. When you're done and the site's online, check the server log files to validate that people are finding their way around. Tweak the icons or buttons if large gaps appear in the click trails, and interview random users from time to time. Their needs, or their expectations of what a Web site should contain will evolve with the technology and culture of cyberspace.


Paul owns World Media Services, a Web-site production company (www.world-media.com). He is a frequent contributor to Web Techniques and is publishing a book on Web-site automation (John Wiley & Sons). He can be reached at paulh@world-media.com.

Copyright Web Techniques. All rights reserved.
Web Techniques Magazine


Last modified: 2/5/97