One of the first challenges facing the designer of any application is answering the ubiquitous question, “How do I __________?” In the case of a web application examples might include, “How do I register for a class?”, “How do I pay my bills?”, or perhaps “How do I make sure that gets to my mom on the Friday before Mother’s Day?”
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.
An example of a relatively sophisticated view is shown in Figure 1. This page not only provides for the simple presentation of content and data, it also includes controls for navigating the data or the application — changing the sort order, specifying the type of information to be displayed, or paging through long lists of items. What distinguishes these operations, however, is that they do not result in permanent changes to stored information.
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.
The division of an application into explicit views and forms is what I call the “view/form” construct —
Of course the best way to understand the value and implementation of these concepts is to look at some real-life examples.
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.
In Figure 2, it’s obvious that this is a well-crafted, intelligent design. There is however, one confusing and ambiguous aspect of the interaction design that highlights the importance of clearly distinguishing between the modes of viewing and editing.
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.
Figure 3 illustrates a second point of confusion that can arise when views and forms are merged into a single page. In this example from the TiVo account management application, the user has successfully submitted changes to their account and those changes have been saved. However, because the application doesn’t follow the view/form construct there is not a logical place to confirm the result of the user’s action. As a result, the confirmation message is reported at the top of the form that has just been saved.
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.
The structure of a hub is one of the most common task flows used in HTML-based Web applications. As it’s name implies, a hub is constructed from a single view page and a collection of forms. The view serves as a launching pad to each of the forms with a successful submit from any of the forms returning back to the view (Figure 4).
This example, from the Options area of the web-based mail service Mailblocks, features a view page as a launching pad to the various forms containing user-defined options for mail accounts and other preferences. Unlike the designs shown in the two preceding examples, Figure 5 solves the same problem using a hub.
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.
One spoke of this hub, the Add/Edit External Account form is shown in Figure 6. The important thing to notice about this form is the elimination of all extraneous navigation. As a result, the only way the user can readily exit the form is by explicitly clicking the Submit or Cancel buttons located at the bottom of the form. Although the utility navigation links still appear in the upper-right corner, only the Sign Out button would abandon the user’s changes since the Help links opens a secondary browser window.
Compared to the earlier examples, this approach has the following advantages:
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.
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.
This article was originally published on May 12, 2003 in the online journal Boxes and Arrows. I encourage you to read the comments posted by their readers.