Form

Problem

Communication isn’t a one-way street.

Solution

Design an interface that resembles a form to allow people to communicate information to a computer system.

Context

• The information that people need to communicate cannot be better supplied in some other way, such as inferring it from known context, importing it from other sources, more interactively and gradually, or though approaches such as Edit-in-Place.
• Your target audience may expect and actually prefer a form-based dialog and/or have to do lots of data entry.

Rationale

Forms are very familiar communication tools that predate computers. It was only natural that they be carried forward into computing as the primary means for enabling people to communicate information to computers, and if designed well, they can be a very efficient means for doing so.

That said, with the explosion of the internet came a corresponding explosion of forms. It often seems you can’t do anything online without filling in a form, so you need to put effort into making them as painless as possible because people’s goals are almost never to fill out a form—forms are just enablers to help them achieve their goals. This holds true for both Web and desktop-based forms because it is the cumulative effect of forms that is wearying to people.

Implementation

The first step to designing a good form is to minimize the amount of information you are asking people to communicate. In fact, one might go so far as to say if you can eliminate the need for a form altogether, that is generally the preferred approach. For each field (piece of information) determine if you really do need it and if you can, eliminate it. Even optional fields add a burden to people filling out forms.

Once you have winnowed down the information you really need, probably the best next step is to look for patterns in the information, that is, are there natural associations between the individual fields? This is often already thought through for you thanks to early domain analysis, so you can use your entity definitions/schemas as a good starting point.

But don’t just blindly surface the fields as they are mapped in your system. Think about the current goals that your target audience has when using the form you are designing. If there is correlation between your entities and those goals, great; if not, err on the side of designing in favor of their goals. And by all means, use the terminology they think in and not your system terminology (unless, again, there is correlation).

One effective way to minimize form pain is to help people to gradually and incrementally communicate information as it is needed. You may have, for instance, a complete profile you would like people to supply, but on initial sign up, you only need a few pieces of information to effectively authenticate them, so only ask for those up front and let people supply more information as it makes sense given what they want to accomplish with your software.

Once you have groupings, the next step is to lay out the form. If you have a lot of information, it may help to break them up into separate chunks as part of a Wizard-like interface. This is also where you need to think about your overall alignment scheme. It seems that for most purposes Top Aligned Labels is best, but Right Aligned Labels and Left Aligned Labels are also an option. Probably the most important thing is to ensure there is a clear path to completion.

Other high-level concerns when designing forms are creating a coherent approach to validation exception messages and helps/tips. For validation, consider using Inline Validation and when possible Same Page Error Messages. For helps/tip, consider an Input Prompt or Input Hints. You should generally be consistent in both of these, that is, using the same affordances.

You should also consider keyboard, especially in forms designed for high-frequency use. Keyboard shortcuts, appropriate tab order, and mapping of commands (such as the Enter key to a “commit” action). And providing good defaults where possible can ease the burden on people.

Once you have your overall form scheme, you need to consider each field individually and choose both the best input affordance (control). There are many possible patterns to consider for particular kinds of input that you can explore in this catalogue, which should be under the Form tag.

This implementation guidance is just a quick overview. For a good, in-depth treatment of designing forms, consider reading Web Form Design: Filling in the Blanks by Luke Wroblewski.

Help Me Get There

Infragistics has some tools that can jumpstart your efforts to implement this pattern. Broken down by technology, they are as follows.

ASP.NET

Form pattern can be implemented using combination of the following ASP.NET controls: WebEditors, WebImageButtons. Check out the samples browser to see it in action.

Sources

Jennifer Tidwell, Designing Interfaces

Patterns in Interaction Design, Form

Luke Wroblewski, Forms

Tags

Data Entry, Form.