• Users enter information using a set of fields (also called text boxes) and controls such as checkboxes, radio buttons, and dropdown boxes for selecting items from lists.

• Users act on the information using buttons. Commands (“Save;” for example) are generally handled using buttons, not menu options. This is unlike desktop systems, where all main window options are done using menus, and only dialog boxes (or, occasionally, specific areas of a window with their own very restricted subset of actions) have command buttons.

    Both of these types of activities are described in the next few sections.

Know the Various Field Types

Fields can be protected or unprotected, required or not required or conditionally required. Standard, required, and protected fields overlap: For example, protected fields can change from protected to entry, depending on which business or data-integrity rules are in effect (the conditions).

In general, you want to:

General Design Guidelines

For input forms on public web sites where users may not know how to type, use text-entry areas only for information that can’t be chosen from a list. For example, you can’t expect to select your last name from a list, but you can select your state and the expiration month and year for a credit card.

However, if your input form is used by experienced data-entry personnel or other people who work on their computers all day long, use text-entry fields or text-adapted controls as often as possible (more on this later). People who spend much of their days typing hate switching back and forth between the mouse and the keyboard. Also, data-entry personnel are sometimes paid by their input speed, and you want to avoid slowing them down for any reason.

Entry fields should look like they accept data. Create this effect by:

Don’t Make Users Format Text

Don’t force users to enter leading zeros or to change the text’s case themselves. Also don’t force users to right-justify or left-justify entries: Let the software do it.

However, note that different writing systems have different justification rules. For example, Hebrew and Arabic writing systems are bidirectional—text is entered and displayed from right to left, but numbers (and any Roman-alphabet words) are entered and displayed from left to right.

Provide Keyboard as Well as Mouse Navigation

Try to make it easy for users to move through the form via the keyboard. The minimum requirement is to set up a good tab sequence so that the Tab key moves the user from field to field in a logical order. The HTML attribute is called “tabindex= n,” where n is the order of the control in the tab sequence.

Development systems generally use the control-creation order as the default tab order—in other words, the first field you create is first in the tab order, the second field you create is second, and so on. The order breaks down when the developer changes fields, moving or replacing them. If a screen has suffered many changes, check that the tab order is still in order—from top to bottom, left to right (in left-reading languages).

Mnemonics that let users jump to particular fields using Alt and a letter or number can also be useful (but do some usability testing before investing a lot of development time—if no one will ever use them, there’s no point in doing all that handwork). The HTML attribute is called “accesskey” (“alt” being used for “alternate text”). For example, this code generates the mnemonic in Figure 3-4.

Retain Cut, Copy, and Paste

Data-entry applications should, at a minimum, allow cut, copy, and paste using the browser’s standard toolbar buttons, menu options, and accelerators (Ctrl+X for cut, Ctrl+C for copy, and Ctrl+V for paste).

Also, let users select data via the keyboard (not just the mouse). Shift plus the left and right arrows selects text in Internet Explorer, Opera, and Mozilla.

How to Label Data-Input Forms

If you are creating a data-input form, you need to put as many fields in the same frame as possible, to help the people doing input keep track of where they are. Fields should be organized in columns and groups, not in one long scrollable list down the screen. If there are too many fields to fit on one screen, then provide multiple screens and a method, such as tabs or pop-up windows, to move between them.

Also consider whether the application will be used internationally, especially if you’re starting with English, which is a fairly compact language. An English phrase or sentence translated into German or Russian, say, will become 10–100 percent longer.

If you expect to internationalize your application, put the field labels above the fields, not at the left (or at the right in right - to-left - reading languages) (Figure 3-5). This allows the field labels to expand or contract as needed and lets you put many fields in the same area.

How to Label e-Commerce Forms

If your form is used to collect customer or client information—names addresses, and so on—you can follow the de facto standard for many sales-oriented forms: a long column of fields with labels on the left (or on the right for right-to-left languages).

The labels are sometimes right-justified to keep them close to the fields, as shown in Figure 3-6. However, most forms left-align the labels (see Figure 3-7 for an example). How do you decide between the two styles?

In general, experts recommend left-aligned labels when users might be expected to scan a form—left alignment makes it easier to find one label in a set of labels and reduces the visual complexity of the form (it is harder to find the beginning of a word along a jagged left edge). They sometimes recommend right alignment when users are tabbing from field to field and/or the labels are of very different lengths—keeping the labels near the fields reinforces the visual association between label and entry area.

Also, use a colon to end the label—in the absence of other cues (such as the “Label for” attribute described in “Make Sure Labels are Correctly Tied to Their Fields”), screen-reading software uses colons to recognize labels.

Accommodate Less Experienced Users

If your audience is not computer savvy, a long, scrolling form might not be the best approach, since these users may not notice the scroll bars and may try to exit from the window prematurely.

Here are two alternative approaches:

In either case, carefully test the form with the target audience before deciding and state explicitly when a new window will open or when the user should click the “Next window” button (Chadwick-Dias 2002, p. 1).

Use Different Labeling Strategies for International Forms

If the form will be internationalized, you have two options: Put the labels, left-aligned, above the fields, as described above, or create a table with resizable columns.

In the second strategy, the labels go in the first column and the fields in the second. Then whatever language you use, the columns will resize to accommodate the text. For example, compare Figure 3-7, the English version, to Figure 3-8, the Spanish version: same form, different language, no problem.

Make Sure Labels Are Correctly Tied to Their Fields

Screen readers like Jaws can associate a label with its field, no matter where the label might appear, provided you explicitly associate the two. In HTML, for

example, you can use the <label for=“id”> attribute. For example, this code creates the label and field shown in Figure 3-9:⁵

Note that, although you can put the label anywhere if you associate it correctly, people using screen magnification software (and the rest of us, as a matter of fact) need the label to be near its field.

I measured the speed and accuracy with which users could find various target items on the screens. They were encouraged to be highly accurate, so error rates were very low and the main analyses were done on the time data ….

For the search time data, the best predictors were the two measures related to the grouping of characters on the screen. As either the number of visual groups increased or the average size of those groups increased, the search time increased. Overall density and local density were also significant predictors, but less so than the grouping measures. Interestingly, the layout complexity measure (i.e., alignment) was not a significant predictor of search time.

Complexity Is Not Necessarily Bad

Another aspect to grouping fields is the “decision complexity advantage,” which, although designers don’t often address it explicitly, can be important to user satisfaction. Research indicates that it is often more efficient to show users a small set of complex decisions rather than a large set of simple decisions. In other words, making one six-step decision is faster than making six one-step decisions.

So, for example, a financial trader is likely to be happier with many small frames on one screen than one big frame containing only one type of information at a time. Pharmaceutical researchers will prefer a window with many inputs and outputs rather than a window that forces them to make one choice at a time. Experienced data-input personnel will be more satisfied with a window crammed with fields (as long as it’s organized well) than one that makes them move from screen to screen.

• If users cannot change the contents of a field temporarily, turn the contents lighter (gray or a pastel version of the dominant color on the window), but do not change the background color of the entry area or the color of the label.

• If the entire field is inactive, gray out the label and background of the entry area.

• In database applications, to make sure that records contain complete or necessary information.

• In interactive analyses, to make sure that the entries are complete and valid.

• On e-commerce sites, in forms that collect information necessary to ship a product or open a claim, for example.

Use Required Fields Sparingly

On e-commerce sites, required fields have gotten a bad name. The problem is that, on too many sites, users are asked for too much information.

For example, if you just wanted to try an online software demonstration, why should you have to fill in your entire name, mailing address, email address, phone and fax numbers, pet’s name, mother’s maiden name, and so on, before you can download the demo? It would make more sense to send in some of that information at the end of the demo, when you’ve decided you can’t live without the software.

And whether or not all fields are actually required, many people believe that they are, so they will bail out of the form, angry about the violation of their privacy.

Required fields can be problematic in database and analysis applications as well. If the people inputting data don’t have, or can’t find, the right data to put in a field, they sometimes put in anything that the field will accept, whether or not it makes sense: “You have a pet Komodo dragon? Hmm. It won’t take ‘Komodo dragon.’ I’ll just put in ‘ferret’ for now.”

To solve these problems, conduct usability tests with the target users to make sure that they can easily get all the information they need to fill in the required fields or, if they cannot, that they can save an unfinished window. Although much of the constraint information (logical or because of business rules) should be in your task analysis, subtle difficulties may appear when you put the windows in front of actual users.

On commercial sites, consider picking up the minimum amount of information you need and let users add more as they get deeper into your site and have a better idea of what you are offering them. Novartis Pharmaceuticals, for example, picks up the minimum amount of information they need at each point. The Lamisil site, for example, gives away plenty of good information for free without registration. If you want a $10 coupon toward the cost of a prescription, then you have to fill in your name and address (Figure 3-16), but the trade-off is clearly reasonable.

Once you start taking the drug, the site offers email reminders for refills (Figure 3-17) and helps you track your progress online. Each option asks for only the minimum required information.

How to Indicate a Required Field

In desktop applications, there are many ways to indicate that a field is required: changing the background color of the required fields, making the labels bold, or putting a symbol (asterisk, arrow) in front of the field.

Different indicators have taken hold on the Internet. Many public and e-commerce sites put a statement at the top of an input form that says something like “Fields marked with asterisks are required.” Then each required field has an asterisk in front of the label or the field. See Figure 3-18, for example.

On web applications, however, you can be more subtle. Users who access the system daily don’t need to be reminded of the rules on every page. If the

web application is just another version of a desktop application and this application already has a well-known standard for indicating required fields (bold labels, blue backgrounds, etc.), then feel free to use it. In Figure 3-19, for example, required fields are indicated with bold text.

Offer Defaults Whenever Possible

Use a default whenever there is a likely one.

As Jeff Johnson says in Web Bloopers, if you’re Stanford University and you’re asking students for their state, it’s going to be “California,” not “Alabama,” which was used as the default on the Stanford web site only because it was the first state alphabetically (2003, p. 136).

How can you decide on a good default? Johnson offers an excellent source of information: your site’s logs. What do people enter or choose most often?

He also suggests offering a default based on what you already know about the user. If users must log on to the site, you may be able to tell where they are (2003, p. 138). For example, a multinational company’s web application can fill in a Canadian user’s province automatically based on his or her address in the corporate database. Or if a group of insurance agents is based in the Appenzell canton of Switzerland, odds are that the customer addresses they enter will also be in Appenzell.

How Not to Indicate a Required Field

Don’t use color alone to indicate a required field. Sometimes designers put the “required” label in a different color. For the 8 percent of men who are red-green color-blind, the change in color may be invisible. Also, since colors have less contrast than black and white, colored text is not as visible as black unless you bold it or use a larger type size.

Don’t use just boldface to indicate a required field. Screen-reading software can’t read the change in color or style—there’s nothing to read—so the change won’t be recognized. Instead, usability experts suggest, either use a graphic with ALT text saying “Required” or put “Required” in the label (you can make “Required” the same color as the background so that it will be invisible to people not using screen readers).

How to Provide Feedback for Required Fields

In spite of all your cues, say that the user has skipped a required field. In public web forms, the de facto standard is to wait until the user clicks the Submit, Continue, or other button and then show an error message. Here’s where things get tricky:

On a public web form, option 1 isn’t enough because you’re asking the users to do something they have come to believe that the program should do automatically—put them back on the offending page. In fact, this approach has become very rare.

Thad Allen (2001, personal email)), a web application designer, recommends option 2 for public forms:

also a waste of web traffic and highly annoying for the user in some situations, especially when the missed field was an oversight versus a misunderstanding.

Another suggestion comes from web design expert Chris Kania (2002, personal email): Validation when leaving a field “is very irritating. You may not fill out a form in the ‘approved’ order, and [having to cancel a series of] JavaScript popups before you are finished with the whole form is really annoying.”

Option 3 is widely used, but it doesn’t always work well, especially if the form is long and the user can’t see all of the highlighted fields at once. Also, highlighting with red text, which is common, doesn’t work well for the 8 percent of males who are red-green color-blind.

However, options 2 and 3 both accommodate the standard required-field behavior seen by usability professionals: The users fill in the fields and then click Save, fix the errors, and repeat as needed until all the fields pass the validation tests.

When to Use Dropdown Lists

Having dropdown lists is one way to maintain data consistency—if users can only pick items off a list, you don’t run the risk of saving invalid entries in your databases.

However, dropdowns can get in the way of expert users and power users. As Micky Liu says (2002, personal email), “When I am filling out a form, I prefer NO dropdown lists. If I am typing every field, it is annoying to have to take my hands off the keyboard to use the mouse to make a selection for the STATE, which would have been accomplished far faster just by typing.” He adds, “The lists that I believe are implemented well are those that make intelligent guesses about your response and place those guesses at the top of the dropdown list rather than have you scroll through potentially hundreds of choices.”

For example, if you know that a user has signed on from somewhere in the United States, “United States” should be entered automatically. Similarly, if the user has signed on from France, then “France” should be entered automatically.

Currently, in most web applications the best you can do is to type the first letter of the entry you want and then arrow down or keep pressing the same first letter until you reach the item you want. For example, if you’re trying to select “New York” from a list of states, you can press “N” six times (Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, New York).

If your users are touch-typists or people who do heavy-duty data entry, a better method would be to let them type the entire entry. The users could then move through fields quickly by typing and tabbing rather than typing and arrow-keying or mousing.

However, some developers have published code for type-ahead dropdown lists, as shown in Figures 3-21 and 3-22 (this is a JavaScript version). See Resources for sources.

Note: Don’t confuse this “auto-complete” with the browser-level auto-complete, which is described in “Offer Automated Entry Fields.”

Also, don’t confuse dropdown menus (Figure 3-23) with dropdown lists (Figure 3-24). They are two different types of controls and are programmed differently. Menus, and navigation in general, are discussed in Chapter 2, “The Browser Framework.”

Check Your Lists for Typos and Other Errors

Dropdown lists are either hard-coded or called from database tables as needed. The quality of those lists depends on the attention that the developers, testers, designers, and technical communicators paid to them before releasing the application to the public.

Someone needs to check whether items are misspelled, out of numeric or alphabetical order, missing, repeated, and so on, before the application is put online.

Put Lists in Order

According to Kent Norman (1991, pp. 133–134), there are eight ways to organize information, as shown in Table 3-2. Random order will not be appropriate for web applications, but the rest may be useful for dropdown lists and for default sort orders for list views (described in Chapter 4).

• In groups, to toggle a small number of independent attributes or states on and off.

• Singly, to toggle one setting on and off.

Checkbox Groups: Doing the Numbers

How many checkboxes are too many? Here are three rules of thumb.

Be Careful How You Toggle

Every checkbox is a toggle—the setting is either on or off. When you have a group of checkboxes, you have a group of independent and mutually inclusive toggles.

When you have a single-button toggle, on the other hand, you are taking advantage of the fact that a checkbox’s two states or settings are mutually exclusive—either yes or no, on or off—in a Boolean sort of way. For example:

Problems occur, however, when either the two states are not opposites or the check-button label contains negatives.

Use Opposites Only

Make sure that the two states are opposites. For example, what is the opposite of “full duplex”?

To the uninitiated, probably “empty duplex” (or a single-floor apartment, depending on the context). For modem connections, however, the right answer is “half duplex.”

One solution is to change the label depending on the setting, but that becomes confusing for two reasons:

It’s confusing to describe and worse to specify and program. Here are some better ideas.

Don’t Use Negatives (You‘ll Create a Double Negative by Mistake)

Never use negatives in the labels. The rule is, if the box is checked (true), then the answer to the question (actual or implied) is yes. Otherwise, the answer is no.

Therefore, to avoid double negatives when the boxes are empty, always label the buttons with positive statements. For example, “Disable sound card” (negative) means, if unchecked, “Don’t disable sound card,” which really means, “Do enable sound card” (positive). Eliminate the negative dis- and use “Enable sound card.”

“/ Want Nothing!”

Here’s a problem that has both users and designers pulling out their hair and gnashing their teeth: Once you select a radio button from a set that starts out with none selected, how can you get back to “none selected” again? (The same problem can occur with dropdown lists, which are the same as a set of radio buttons, just formatted differently.)

Developers and designers don’t usually preselect a radio button if there is no default. (What, for instance, would be the default for gender?) So when users open a page or frame for the first time, some radio buttons will be unset. Once the users select a button, however, they’re stuck with a choice—“neither” is no longer an option.

There are at least two solutions to this problem. One is to get an exhaustive set of criteria from the end-users. Figure 3-27, a mocked-up screen from a veterinary office application, is an example of a bad set of radio buttons. What if the patient is a squirrel? An iguana? What if the owner simply came in for information? Clearly, this set of options was not specified correctly. (In situations like these, the front-desk people will choose any button just to get through the screen.)

The second is simply to add another button or list item called “None,” “Not Relevant,” “Not Applicable,” or “Other” (Figure 3-28).

Guidelines for Tabs

The three guidelines for tabbed interfaces are: use a single row of tabs; fix them in place; and display them always. (Also see “Be Careful Where You Put the Buttons on Tabs and Frames.” For page guidelines, see “Interactions on the Page and Application Levels.”)

Amazon uses tabs correctly (Figure 3-33): It sticks to one row and doesn’t use tabs for everything. Rather, the major categories appear in the single row at the top; the secondary categories are hidden in the dropdown list under Search.

Following the second guideline—don’t move them—is automatic if you follow the first guideline. When you select a tab, it comes to the front of the pile and changes color or focus so that you know which tab you selected. If you stick with one row of tabs, the only “movement” is in the content area, as one set of fields is replaced by another. If you use two or more rows of tabs,

however, the entire row of tabs has to come forward, replacing the original front row. This is remarkably confusing.

Finally, don’t let tabs appear and disappear dynamically. If they do, users will regard your application as unstable, at a minimum, and possibly insane. If someone on your development team suggests it as a strategy, be sure to test for usability with your target audience and make the development team watch the tests.

1. Collecting secondary information and settings for an object or record—landlord information for a mortgage application (Figures 3-34 and 3-35), a percentage setting for a bond analysis, and so on.

2. Holding tools such as calendars, toolbars, and palettes.

3. Delivering messages and providing feedback.

Use Popups to Offer Information

Text popups are used to ask questions, confirm actions, and warn of problems (like message boxes in desktop applications—see Figure 3-35) and also to display background information, such as warranties and license agreements (Figure 3-36).

For informational popups like the one in Figure 3-36 to be really useful, they have to be printable. Remember to include a “Print” button—many users won’t know about the shortcut menu with the Print option that you get by right-clicking the mouse.

Follow These Popup Guidelines

Here are some guidelines for all types of popups.

Here are some additional guidelines for data-collection popups.

For informational popups, also remember to provide a Print button as well as a Close (not Cancel) button.

Three Traditional Popup Buttons

OK, Cancel, and Apply have come to have particular meanings in desktop-application dialog boxes. The three buttons can be used the same way in web popup boxes, tabs, and frames acting as dialog-box equivalents. See Table 3-3.

Use Standard Button Order

Show the buttons in this order: OK (or OK equivalent), Cancel or Clear (or equivalent), all other buttons, and Help if you offer help for the form. This is the traditional button order according to the Microsoft and Java standards, and as such, will feel familiar to most users.

Dates: Use Calendar Popups and a Day-Month-Year Format

Usability researchers have evaluated methods for entering dates on public web forms, and the results indicate that people prefer to choose dates from an interactive calendar and, secondarily, from dropdowns (Caldwell 2000, pp. 1–4; Bainbridge 2002, pp. 24–25).

Also, although most travel sites don’t seem to do this, the best date format is DD Month YYYY—for example, 01 May 2004. Date formats differ between countries: The United States shows dates in MM-DD-YY order, while most of Europe uses DD-MM-YY. May 1,2004, for example, could be written as 05–01-04 or 01–05-04, depending on the user or the location (an American traveler on a German web site might easily put the date in wrong). Spelling out the month makes the date unambiguous. See Figure 3-37 for a site that follows the recommendations.

These research results may be transferable to web applications as well, even though people doing large amounts of data entry might prefer typing dates. However, people like the popup calendar because:

However, remember that Netscape and Mozilla don’t handle certain controls the same way (or at all). Test calendar popups on various browsers. If they don’t work, rewrite your home page to check for browser type and version. You can then present a popup-free version of the page (use the second runner-up, dropdowns, for example) on the browsers that don’t accept popups.

What Are the Standard Elements of Names and Addresses?

If your web application is used by people in multiple cultures (which may or may not cross political boundaries), you will have to address the issue of names. For example, in many Asian cultures, the last, family, or surname is given first and the first, given, or forename is given second. In Spanish cultures, many people have multiple middle names and/or surnames, and deciding which pieces to put in which fields can be difficult.

Addresses are also different from country to country. For example, U.S. ZIP codes are all numbers; Canadian and U.K. postal codes are mixtures of letter and numbers. Street addresses in Japanese cities tend to be more like a set of directions than the Western style of house number and street name.

However, there is hope: The Organization for the Advancement of Structured Information Standards (OASIS) offers “Customer Information

Quality Standards,” including names (“xNL”) and addresses (“xAL”). See Resources for details.

Numbers Are Handled Differently in Different Cultures

Numbers—currency formats, names, separators, even rounding conventions—differ between cultures and countries and also between disciplines (biology, engineering, and physics, for example). Here are some examples—not an exhaustive list, by any means—of differences you can expect to find in number handling.

Credit Card Numbers Are the Same, Except When They’re Different

Here are some of the issues you need to address when designing credit card number fields.

Use Buttons to Do Things, Use Links to Jump to Other Web Pages

One of the ways a web application is different from a desktop application is that you may be tempted to use links for everything.

Do not give in to temptation. Use underlined links when you want to show information (“Go To” or “Read This”) and buttons when you want to do something (“Save” or “Search”).

The reason is based on the idea of affordance—the behavior users expect from an item. For example, the affordance of a doorknob is turning; the affordance of a handle or plate on a door is pushing. The affordance of the door itself is that it opens and closes.

Similarly, the affordance of a button is that it can be pressed; and when it is pressed, it does something. The affordance of a link, on the other hand, is that it goes to another web page.

Although you can use a link to open or close a popup or switch to a different input page, these types of actions don’t match the affordance for links. Similarly, using a button to jump to a new informational page doesn’t match the affordance for button.

Yes, it’s all in the user’s head. But why be confusing if you don’t have to be?

Note: There are exceptions to this rule when you’re working with list views. See Chapter 4 for more information.

How to Size Buttons

In general, use the same size for every button in a related group of buttons. For example, if the button labels are “OK,” “Cancel,” and “Find Flights …,” make all three buttons as wide as “Find Flights ….”

If there are many buttons and their sizes vary dramatically—for example, “OK,” “Set,” “Fly,” “Cancel,” “Find Flights …,” and “Register Flights…”—create two sizes. This gives you approximately the right size for all buttons without creating too many sizes.

Set Buttons Off from Fields

Keep all the buttons in their own restricted area of the frame. In other words, don’t run data-entry controls and command buttons together. Compare Figure 3-38 to Figure 3-39. In Figure 3-38, you run a risk of “hiding” the commands from the user.

Also, developers creating reusable frames may want to keep a clear zone for these buttons. If this is the case, design the frame with two zones: the field zone, which may vary from window to window, and the button zone, which won’t. When the window is actually coded, the developers can just drop the appropriate fields into the field zone and the command buttons will appear automatically.

Repeat Command Buttons at Top and Bottom

If you create an input form that may be larger than the window (in other words, that will have scroll bars on some people’s windows), consider putting the same command buttons on the top and the bottom of the form.

The researchers at User Interface Engineering discovered an interesting problem—button gravity (Spool 1999, pp, 79–81):

Also, some people, if they happen to be at the top or bottom of the form when they decide they’re done, may miss the buttons if you’ve put them in only one location. For an example, see Figure 3-40.

Be Careful Where You Put the Buttons on Tabs and Frames

Keep in mind, when you’re designing tabs and frames, that you need to be very clear about what the buttons are saving, canceling, or applying—only what’s on the tab or frame, or the entire input form? (In a popup, it’s clear that you’re saving what’s in that box.)

If the user is saving only the tab input, for example, then put the buttons inside the tabbed area—visually group the tab fields with the buttons.

For example, in the Internet Options dialog box (Figure 3-41), the buttons “Use Current,” “Use Default,” “Use Blank;” which are related to a section of the tab, are inside the tab frame. The buttons “OK,” “Cancel,” and “Apply” are outside the tab frame and clearly relate to the dialog box as a whole.

Also label the buttons correctly: If a button changes something on the tab, not on the entire form, say something like, ‘’Apply tabname Settings” or “Reset tabname Colors.”

Capture Multiple Button Presses

Here is a common situation: Users fill out a form and press Submit or Order. The connection is slow and they don’t see anything happen, so they press the button again. And again. Finally, they see a message, “Your application has been accepted” or “Your order has been placed,” and they walk away, satisfied that they have finished the transaction correctly. Unfortunately, what they have done is create multiple forms, one for each press of the button.

Some sites put messages near the Submit or Order button telling users not to press the button more than once (see Figure 3-42, for example).

You can warn people to click only once, but a better method is to catch and throwaway the extra button presses.

In JavaScript, you can fix the problem as follows. Put this code into the head section:

You then include this code in the HTML for the Submit button:

When the form is first loaded, its state is blank by default. When a user clicks Submit, it calls the function “subrnitCurrentl-Form( ).” If the form’s state is still blank, the system gathers the form’s information, performs the “action” specified, and sets the form’s state to “True.” Otherwise, if the form’s state is already “True,” the system takes no action.

In Java, this code will capture extra presses:

You Don’t Really Need “Reset,” Do You?

Some sites provide a “Reset” button at the bottom of their forms. Reset buttons generally wipe out all of the user’s input and return the form to blanks or defaults.

Most usability experts, as well as nearly everyone who has pressed one by mistake, think they’re a bad idea as well as unnecessary.

In neither case do they need a Reset button. Reset buttons do get pressed, however, either by mistake, because of a slip of the mouse, or out of curiosity, to find out what they do (which usually turns out to be a mistake as well).

The only time that a Reset button might be useful is in a public library, say, when you don’t want the next person in line to see your search.

If you want to give people the opportunity to return a complicated form or set of preferences to its initial values, a reset operation is fine. Just call it “Return to Initial Values” so that users know exactly what is going to happen, and place it far away from all the other buttons on the page.

Include a “Find” Button

In natural language, find and search are synonyms. In software, however, they are beginning to be seen as two different operations. Find means “look only on this page” and Search means “look in the underlying table, database, or file system or on the entire web.” In other words, Find is local and Search is global.

Don’t remove the browser’s own Find operation (Figure 3-43) unless you replace it with something better—and the replacement must still do local, not global, searches. Always use Ctrl+F as the keyboard shortcut.

You can add a special Find operation if you define local differently, as Adobe Acrobat does. “Find” in Acrobat looks through the entire document, not just the current page (Figure 3-44). (Acrobat has a separate Search operation as well, which lets users search through specially indexed collections of PDF documents.)

When Losing Input Is Dangerous, Strip Out the Browser Controls

A problem with using an unmodified browser window for web applications (versus web sites) is that users might click Back or close the window and lose all their input up to that point. Or worse, from a data-integrity point of view, they might leave a record partially updated and the underlying database in an uncertain state.

If this is possibility, take away as many of the navigation buttons, shortcut menu options, and keystroke shortcuts (the Backspace key for Back, for example) as you can. Show only the web application’s content area and provide your own navigation as needed (Figure 3-45).

If users must log in and log off, capture the toolbar’s Close button as well. For example, Citibank’s online banking system interrupts if you try to close the browser without first closing the application (Figure 3-46).

Also, if your application moves from informational to transactional, as most e-commerce sites do, remember to strip out all distractions on the transactional pages—for example, ads, links to nice but unnecessary information, even the standard navigation tabs and dropdowns. Inexperienced users will click these other links, especially when they become confused or frustrated, and never find their way back to the original transaction.

However, don’t over-constrain. If users open a best-practices document, for example, leave that page’s browser controls alone. And let users abandon a sales form by closing the browser—don’t trap them in your site. However, if they press “Submit Order” but then click Close just before they receive an acknowledgment of the order, you’ll have to define a corporate policy. For example, you might decide to stop users at that point with a question such as “Did you want to cancel your order?”

Considering Offering Different Levels of Save

The main operation in an input form is saving input. You might want to offer two levels of Save, depending on how complicated or time consuming the task is and the degree of damage that bad data might cause. For example:

In these types of situations, offer two saves. The first saves the unfinished record locally or in a scratchpad section of the server (keyed and protected by user ID). Do very little error checking, since the record is almost guaranteed to be incorrect or incomplete. The second save checks the record for errors and, if it’s okay, commits it to the official database.

Depending on the context, the first Save operation could be called “Temporary Save” or “Add to Shopping Cart” and the second could be called “Commit to Database” or “Buy Now.”

When to Validate Input

Whenever an application has to send information to a server, it takes time and bandwidth. For this reason, most system administrators prefer that applications minimize interactions with the server databases, do most of the error checking on the client (the user’s computer), and send only groups of clean records to the server. Here they may undergo a final round of validation in which the new or changed records are compared to records already in the database.

System administrators do not get all of their wishes, but savvy designers try to accommodate them whenever possible. Designers can make web applications more system-friendly as well as user-friendly by using more dropdown lists, running validation applets in the background on the client computers, and using more popup tools, such as calendars, calculators, and postal-code lookups.

What If Part of Your Application Is Someone Else’s Application?

Sometimes an application uses parts of another application, possibly one that is owned by another company (called syndication). For example, your company offers subscriptions to a magazine but another company does the fulfillment. Or your company offers investment plans but another company manages the plans and collects the information from your employees.

So how do you show the “outside” application? Should you make the other application look the same as the internal application? Or should you provide a link and say, “Click here for that other application. You will leave our application when you do so”?

The answer is “It depends.” If the other application has a strong identity of its own, then you might want to be obvious about your use of the other company, even going so far as to open a new browser window (see Figures 3-47 and 3-48).

If, on the other hand, you think, for example, that employees might be uncomfortable giving their 401K information to an outside company, you would probably want the connection to look as seamless as possible. In this case, you’d open the new application in the same window using your own corporate visual style, with the other company’s logo appearing discreetly in a corner somewhere.

For more information, see the section on syndication in Resources.

When to Warn That a Jump Is Imminent

Linking to an outside informational site from within your site (Figure 3-49) is different from linking to another application. If the context is clear, then you only have to decide whether you should open the new link in another browser window or stay with the current window.

If the context may be unclear, however, or if there are legal considerations (for example, the source site contains FDA-approved pharmaceutical information and the target site contains disease information that may or may not be accurate), consider warning users that they’ll leave your site when they click the link.

In either case, do usability tests with your target audience before deciding how to handle the jump—warning or no warning; new window, same window. Note: Reusing the same window is usually best (C. Snyder 2001, p. 4).