Jakob Nielsen's Alertbox, September 19, 2005:

Forms vs. Applications

Summary:
Once an online form goes beyond two screenfulls, it's often a sign that the underlying functionality is better supported by an application, which offers a more interactive user experience.

Forms are rarely the best metaphor for complex interactions with computers. Most big companies, however, have a legacy of paper forms. As a result, their intranets are littered with online forms that attempt to meet needs that are often better served by real applications with a real dialogue flow and more of a full-fledged GUI.

We recently got a call from someone who wanted a usability review of a single intranet form. I usually don't like giving feedback on a single page because the project overhead becomes too large and usability insights tend to be too narrow because you lack the context of, say, a full website or a targeted intranet area. In this case, the request came from within a highly respected company that's been a good client of ours, so we owed them extra service and agreed to take on their form. Good we did, because this single form turned out to be a goldmine of usability issues: our final report contained 27 redesign recommendations.

The form contained 57 interaction elements (e.g., groups of radio buttons, text entry fields, and menus) plus a variety of help links. In total, the form was 3350 pixels tall -- that is, it would scroll across about five screenfulls on a standard monitor (1024x768).

Do you have forms like this on your website or intranet? If so, reconceptualize them as applications. The forms metaphor works best for something simple, like entering shipping and billing addresses on an e-commerce site. Even this data is really an element in a bigger workflow consisting of the shopping cart and checkout process that stretches across multiple steps and has thirty-two documented usability guidelines.

When to Use a Form

Forms work when there's not much to do beyond plain data entry. Just stack up the text boxes and have the user type away mindlessly. A few decision points might be acceptable, such as the traditional question as to whether shipping and billing addresses are the same or different. Even here, a small amount of interactivity improves usability. You might, for example, gray out the billing address area unless the user unchecks the box for "billing address is the same as the shipping address."

Interactions that are more complicated suffer when you present them as straight forms. The following criteria can help you decide whether to present a form or a more interactive design:

• Complexity of requested information. If the data request is a no-brainer that people can supply without further ado, use a form. If users need to think and/or refer to supporting materials, use an application (and provide features for accessing the supporting materials).
• Number of steps. If the steps are few, use a form. If they are many, structure them into a natural workflow split across multiple steps.
• Conditional areas. If all questions and options are always the same, use a form. If the users' subsequent entries depend on their actions in previous steps, use an application and present only the options relevant for each step.
• Linearity. Conditional areas are one example of non-linearity, but there are others. If users clearly proceed in a linear sequence and never need to revisit or revise previous steps, use a form. If steps don't depend on each other, use a form. If users need to jump between steps or complete steps in an unpredictable sequence, use an application.

Note that the sheer length of a form is not a sufficient reason to break it up. Yes, it's best to stick to one or two screenfulls: If a form takes up many screens, you should seriously consider eliminating some of the questions and options. Otherwise, you're likely to overwhelm users and reduce your conversion rate. But, if all elements are truly needed, you can certainly place them on one long page -- just ensure that each element is easy and that all users have to do is keep scrolling (and sighing) as they complete each step in the long march to the blessed submit button.

Application Benefits

In the long run, I believe we'll see more stand-alone Internet applications with optimized UIs for handling certain types of tasks and data. The Napster subscription manager, the iTunes music store, and Google Earth are current examples of this trend. Once Windows Vista becomes commonly used, most Internet functionality will likely offer its features to give downloaded code the same look-and-feel as native code (XAML/Avalon). This, of course, will take years. (The usual recommendation is to wait at least two years after a technology's release before using it on your website.)

For now, though, what I call "applications" don't necessarily have to be something downloaded as a stand-alone binary or implemented in the current generation of pre-Vista Internet programming languages like Flash or JavaScript. The type of user tasks I'm referring to here mainly need ephemeral applications that can be implemented as a set of Web pages where all or most of the programming lives on the server.

Even when applications are simply sets of pages embedded within larger websites or intranets, they differ from forms in that they have programmable logic and workflow. Compared to forms, applications have the following potential advantages:

• Focus. By breaking up the workflow into multiple steps, users can focus on one topic at a time. They're thus potentially less distracted and overwhelmed by other screen elements competing for their attention. For this to be a benefit, you obviously have to modularize the application in ways that make sense to users and minimize the need to refer to information contained in other areas.
• In-context help. Because you have fewer items on the screen, you can afford to clearly explain each one. You can supplement buttons and menus with text and examples that illustrate their proper use. Having this information on the main screen is preferable because users dislike going off to separate help screens. When you can't avoid a help screen, applications let you at least make it more helpful by relating the help text to the current step of the user's workflow.
• Avoiding scrunched screen elements. A second advantage of having fewer items on each screen is that your layout is less burdened by space constraints. For example, you can avoid drop-down menus and tiny scrolling list boxes. Instead, present lists of selectable items in a more expansive menu where all items are visible simultaneously. This makes selection faster and less error-prone.
• Eliminating irrelevant steps. Users never need to see questions and options that don't apply to them. If, for example, your business logic requires you to know whether customers are married, don't show single customers questions relating to the spouses they don't have. Forms get both longer and more complicated when users have to read instructions like "If you answered "yes" to Question 25, then complete Question 26. Otherwise skip to Question 27."
• Flexible workflow. With applications, you can let users work on different parts of the problem in a sequence that makes sense to them. You can also let them refer to supporting data sources in this process. If an accounts payable application needs a vendor number to process a payment, for example, you can fire up a search interface so users can locate vendors by name and automatically transfer the numbers and any additional information from one application to the other. (Generally, if you're observing users during field studies and see them write down information from one screen on a note pad, only to retype it on another screen, you've identified an opportunity to improve productivity and reduce errors by automating the data transfer.)
• Providing feedback. Take advantage of programmability and restate users' actions and choices to confirm how the computer will interpret them. For example, if users must enter a vendor number, give them feedback by stating the vendor's name. This will drastically reduce errors from mistyped vendor numbers.
• Customizability. If an application will be used repeatedly, you can let users add shortcuts for common actions. For example, an expense reporting application might require users to enter driving distances to get reimbursement for personal automobile use. If an employee often travels the same routes (say, to the airport or an important customer site), the application could provide one-click access to frequently used distances and list them by name (say, "office to JFK").
• Interaction elements beyond boxes and buttons. Applications let you employ all the GUI innovations, from using slides to asking users to mark areas of interest on an image.

Application Downsides

Applications have two serious drawbacks. First, they involve programming and technology, with the associated cost and risk of bugs. Only develop code if you can afford to debug it to a very high quality level, or you'll hurt users more than you help them.

Second, applications require users to understand new commands in an environment where not everything is visible at once. If done poorly, these two issues can drastically reduce usability compared to a one-page form in which the actions are simple (scrolling) and nothing is hidden (though scrolling may be required to expose below-the-fold elements). In our testing of 46 Web-based applications, one of the most serious problems was users' lack of up-front understanding of each application's task structure and basic goals.

A resulting guideline is to start with a brief overview of the application, its workflow, and the expected outcome. This, of course, adds overhead and is thus an additional downside of ephemeral applications on websites and intranets. On balance, though, many user tasks are sufficiently complex that usability is enhanced when you abandon the old forms metaphor and give users the support of an interactive UI.

Learn More

Two-day course on application usability with guidelines for all types of applications:

• Application Usability 1: Page-Level Building Blocks for Feature Design
• Application Usability 2: Dialogue and Workflow Design

at the Usability Week 2009 conference in Washington DC, San Francisco, London, and Sydney.