Boxes And Arrows : The Design Behind the Design

Views and Forms: Principles of Task Flow for Web Applications Part 1

by Bob Baxley on 2003/05/12 | [41 Comments]

The hypertext environment of the Web presumes a style of unfettered browsing and exploration that is not particularly conducive to the full and valid completion of specific tasks, operations, or database transactions. Creating web applications that support the full and valid completion of specific tasks, operations, and database transactions, therefore requires some understanding of how to manipulate the medium to that purpose. To wit, the following few thousand words serve to describe both the fundamental building blocks of HTML-based web applications as well as the three ways in which those blocks can be arranged to provide various types of task flows.

As previously discussed, one of the defining elements of web applications is their support for the editing and manipulation of stored data. Unlike the typical conversation that goes on between a user and a content-centric Web site however, this additional capability requires a more robust dialog between user and application. For example, a visitor to CNN might see something of interest and click on a link, sending a request to the server to send over the indicated story. In such cases, the vocabulary of the user is reduced to something less than that of a nine-month-old baby. The experience provides the user with specificity in their selection of nouns—get me this versus get me that—but their choice of verbs is conspicuously limited to “fetch.”

By comparison the designer of a bill pay application has to support a broader array of both nouns and verbs so that users can more readily converse with the application, saying things such as, “Create a new vendor with this address and account number” or “Pay these four bills the day before they’re due.” Where the user of a content-centric site is mostly confined to the mode of listening, the user of a web application splits their time between listening and talking. And because the client-server architecture of a web application dictates a serial conversation, these types of operations not only require a broader vocabulary; they also require a separate mode.

Although rich-media applications technologies strive to reduce the division between these modes, when it comes to HTML-based applications, the best strategy is to embrace the nature of the medium. This is accomplished by clearly isolating operations into two types of pages: “views” for viewing and navigating, and “forms” for editing and manipulating stored data.

Figure 1: An example of a relatively sophisticated view. Click to enlarge.

Conversely, the purpose of a form should be the completion of a specific task such as updating an address, recording a stock transaction, or submitting an application. In desktop applications, specific tasks such as these are typically handled through modal dialog boxes. Only by requiring the user to supply complete and valid information, can the application complete the requested operation. Inherently HTML does not provide any ready mechanism for enforcing modality. Although this might initially seem like more of a blessing than a curse, the lack of modality in a web application makes it very difficult to structure tasks in a way that ensures the system is able to do what the user asked.

To help mitigate this problem, it is important to respect the division between views and forms by eliminating virtually all of the navigation options from forms. Global and local navigation links not only serve to distract the user from what they’re doing, they also function as cancel buttons since such navigation links do not typically submit or validate the user’s edits.

It’s worth noting at this juncture that just because something is a ‹FORM› doesn’t necessarily mean it’s a form in this context. As described here, forms result in permanent changes to stored data, necessitating a variety of validation criteria as well as the attendant collection of status, confirmation, and progress alerts. By comparison the forms associated with content-centric sites or web directories, the new Yahoo! Search for example, do not result in changes to stored data and therefore don’t have to validate input or report input errors.

1. A tidy separation of interactions into the two modes of viewing and editing
2. Providing explicit control over when data is submitted and saved
3. Reducing the chances of a user inadvertently abandoning edits by minimizing the navigation options out of forms
4. Reducing the visual complexity of views by moving input controls to dedicated form pages
5. Providing an explicit and predictable moment to validate user input

Of course the best way to understand the value and implementation of these concepts is to look at some real-life examples.

Problem: How Can I Ensure Users Explicitly Save or Cancel Their Changes?
MovableType’s Weblog Configuration Forms
One such example is found in the blogging application, MovableType. Used to specify a variety of parameters about an individual blog, MovableType’s Weblog Configuration area is grouped into four different forms, Core Setup, Preferences, Archiving, and IP Banning.

Figure 2: The main configuration screen in Moveable Type. Click to enlarge.

The issue is this: the only interface element on this page that actually saves the user’s data is the Save button located at the bottom of the form. If the user clicks any of the other links, buttons, or menus, their changes will be abandoned. This is a particular problem with regards to the links to the other configuration forms since a user could reasonably infer that the Save button would save their edits to all four forms at once.

In other words, if the user made changes to the Archives form and then immediately navigated to the Preferences form, any changes they made to the Archives form would be abandoned. In effect, the links to the other configuration options, as well as the navigation controls along the left and top of the page, all function as Cancel buttons and serve to distract the user from completing their task.

Problem: What Happens After a Successful Submit?
Example: TiVo’s Account Management forms

Figure 3: TiVo's Account Management forms. Click to enlarge.

To illustrate the issue we’ll walk through the entire task flow. First the user navigates to this page. Next they change the values for one or both of the available fields and then click either of the Save Preferences buttons. Their browser talks to the server and after some sort of delay, the page redraws with exactly the same page and form elements but with the somewhat subtle addition of the green text reading, “Success!” Unfortunately, it’s quite likely that most users won’t see this message and will be left wondering if anything happened or not.

In addition, the TiVo design itself acknowledges a problem with the approach by including instructional text next to each of the Save buttons. By contrast, if the design followed the view/form construct, the only way out of the form would be an explicit Save or Cancel button. This would eliminate the need for such text and reduce the number of messages and information vying for the user’s attention.

Fortunately, there is a simple solution all of the problems described in these two examples: redesigning the task flow using the view/form construct and a hub.

Solution: The Hub Structure
Example: Mailblocks Preferences Forms

Figure 4: The Hub Structure. Click to enlarge.

Figure 5: The Options area of the web-based service, Mailblocks. Click to enlarge.

The view page includes links to the various forms as well as information explaining the contents and purpose of those forms. In addition, the page contains a collection of vital information about the user’s different accounts as well as different commands for acting on those accounts.

Figure 6: The Add/Edit External Account form of the web-based service, Mailblocks. Click to enlarge.

1. Provides an intuitive task flow by providing clear mechanisms for navigating to the appropriate form, explicitly submitting changes, and returning to the initial starting point.
2. Minimizes the chances of a user inadvertently abandoning changed data by removing extraneous navigation elements.
3. Minimizes the cognitive load and visual clutter of all pages by dividing the task into specific, focused operations.
4. Removes the need for a confirmation alert.

Hubs are one of the most useful structures available in HTML-based applications. They can be found in a variety of applications including online calendars, Web-based email, bill pay applications, server configuration applications, and others.

Up Next
In addition to hubs, there are two other task flows commonly used in HTML-based web applications. Next time around we’ll focus on the other two: wizards and guides. In the meantime, I hope you’ll take the time to join the conversation on our newly created discussion list dedicated to interaction design.