blink design library

A single-page multi-step form

Rather than using a multi-page wizard, ebay uses a single-page form, divided visually into separate steps, for posting items for sale (click to see full-sized image):

The strong visual weight given to each section effectively breaks the form into separate steps.

A risk with long, scrolling forms is that users can find them overwhelming.  The single-form approach (vs. a wizard approach) is most suitable where:

• There is little or no conditional logic to the flow
• The overall flow is short
• Each step is relatively easy (both in terms of interaction time and cognition required)

Constraints or flexibility?

Google Calendar and Yahoo! Calendar use very different mechanisms for the "quick entry" of events.

Yahoo uses separate fields for each component of the event:

Google on the other hand uses a single text field:

Both approaches have advantages and disadvantages.

The Yahoo approach--using separate, specified fields--is probably more suitable to novice users because it ensures entries are in exactly the right format. But, it is likely slower than entering information as a single text string.

The Google approach reflects how people might quickly jot down events in an off-line context. But this also requires more system logic to properly interpret user's entries--and this approach runs the risk that users may not use  syntax that the system can interpret, resulting in errors.

For example, consider this quick entry in Google Calendar:

breakfast w/Tracy at 7

With this entry, Google incorrectly schedules the breakfast with Tracy 7:00 pm rather than 7:00 in the morning (which was the user's intention).

Button, Button, Where Goes the Button?

Clients often ask us about button placement on forms. Button placement sometimes causes confusion because on the Web a variety of conventions are used. And there are also different button placement conventions between the Mac and Windows.

The standard Windows dialog box places the buttons on the right side of the dialog, with the primary action (OK) on the left.

Windows XP wizards place the primary action (Next) as the middle button, between Previous and Cancel.

Wizard layout in Vista is slightly different, with the Previous button placed at the top of the dialog--essentially in the same position as a browser back button.

In the standard Mac OS X dialog, the primary action (OK) is on the right.

The  Mac OS X wizard also places the primary action (Next) is on the right.

Web forms tend to place the primary action on the right, as shown in the examples below.

But application-like functionality on the Web sometimes follows the Windows convention of putting the primary action on the left.

But, then again, sometimes the primary action is placed on the right.

For web-based system, we generally place the primary action on the right because this seems to be more of a convention on the web than left placement. Of course, for Windows or Mac applications, we follow the appropriate OS standard.

Entry Suggestions

When there are a relatively small number of entry options for a field, a simple drop-down will do. But for some fields, there can be hundreds or thousands of entry options. People may or may not know the exact spelling or format required.

One option is a generating a drop-down dynamically based on the first few letters typed. In the example below, I've typed the letters "Ar"; in response, the system displays options that contain words starting with "Ar."

From: Facebook

Another approach is to wait until the user has completed their entry and then display a set of suggested entries. In the example below, the system was smart enough to see that I had misspelled "merino" and makes suggestions for the correct spelling:

 

From: Ravelry

Editable Fields

In forms that let users change previously-created information, a question that can arise about whether fields should be displayed initially in an editable state (running the risk that one or more might be accidentally changed) or in "locked" state with the option to edit.

This form uses a hybrid approach, locking the fields where accidental edits could have the most serious consequences:

From: Vox

This form also correctly displays the fields as inactive (vs. non-editable, which would display as plain text minus the field border). When a user clicks the associated "change" button the field becomes active.

More Radio Buttons Driving Form Behavior

This example, from Virb, is via Signal vs. Noise. It is a similar idea to what's shown in this previous post, where radio buttons at the top of the page (with strong visual emphasis) drive the form behavior.

In this case, each option has an associated "details" button, which displays help content below:

It's a small detail, but I wanted to see the triangle on the far right move to the "point down" position when the help content is open. This would help indicate that this works as a toggle (clicking again closes the help content) and is a common visual cue found not only on the Web but also in Mac OS X.

Using Radio Buttons to Drive Form Behavior

In a form, it's often handy to ask users an up-front question that will dynamically change what fields are displayed. And, often, radio buttons would seem the ideal control for presenting the options.

The problem is that radio buttons at the top of a form are often overlooked by users, who instead jump right into entering data in the fields.

This form uses a background color to highlight the currently-selected option.  The highlighting helps draw the eye to the radio button selection, making it much less likely to be overlooked.

From: Wetpaint

Dynamic Field Help

When the user's cursor in is a field, the related field help displays on the right. The appearance of caught my eye, bringing my attention to it (this type of text tends to be overlooked, which can lead to errors). This solution also eliminates the clutter of exposing all the field help on the form.

From: Multiply

Effective Button Treatment

This form has buttons that are in the right position and with the right visual emphasis. Cancel is gray to give it the least visual emphasis; the larger blue Continue button has the most visual emphasis. Small arrows on the Back and Continue buttons further clarify their function.

From: Princess Cruises

Dangerous 'Clear Fields' Button

The positioning and visual weight of this button makes it looks like "Submit" or "Continue" - but, alas, it's a "Clear Fields" button. How many users to you think accidently clicked this and wiped out all their shipping info? There is usually no reason to provide a "Clear" button on a form - the risks outweigh the advantages.