Storyboarding Rich Internet Applications with Visio

by:   |  Posted on

With the recent rise in popularity of web technologies such as Flash and AJAX, it has become possible to create richer user experiences on the web. Even though these technologies are not actually new, we are now seeing their widespread adoption. Within the last six months, we have seen the christening of the term “AJAX” and its broad acceptance. Most major websites are adding rich interaction to their existing features.

What has changed?

The traditional paged Internet application (PIA—part of what is sometimes referred to as Web 1.0 or classic web) has these characteristics:

  • The user enters information at the page level or clicks on a link to go to another page.
  • The page refreshes to show the result of the user's request.
  • Everything is framed in the context of a document content model.

A rich Internet application (RIA—part of what is now called Web 2.0) behaves like this:

  • The user interacts directly with items within the page and the feedback is immediate.
  • The page does not have to refresh to complete the user's interaction (data flows seamlessly in the background, allowing for instant feedback).
  • The interface can be thought of as an application model containing interface objects.

Moving from designing primarily for PIAs to RIAs presents us with a specific challenge: how do we document these richer interactions?


Wireframes capture the structure and relevance of information for a given screen or page. Wireframes and PIAs are a match made in heaven. Each wireframe corresponds directly to a page. The interactions typically move from wireframe to wireframe (page to page), making the interaction model simple to understand.

In the world of RIAs, wireframes are still a very powerful tool. Information still must be structured and its relative importance must be presented. However, with the deepening of the interaction dimension, it becomes more challenging to illustrate to clients, developers, and users how the intended interface will behave. This is due in part to the wireframe's static nature. It also becomes more challenging to test early designs with users since wireframes do not naturally simulate the more complex interactions of an RIA.

Enter Visio

At my previous company, Sabre, I led the user experience team for Airline Solutions. I built Visio stencil libraries that contained shapes simulating all of our web and desktop components (see figure 1). This simplified the creation of wireframes. The stencil libraries incorporated things like:

  • Intelligent layout using Visio connectors (Lego-like snapping)
  • Simulation of component states with right-click menus (select/deselect checkbox; show/hide borders)
  • User interface code-generation for both JSP (Java Server Pages, web) and Java Swing (desktop)
  • Requirements generation

Wireframe Stencils

Figure 1. Wireframe Stencil Library

However, one thing was lacking—the ability to simulate rich in-page interactions. I addressed this by creating a new stencil library that could simulate user interactions within a page. I used a storyboard metaphor for the stencil library (see figure 2).

Storyboard Stencil

Figure 2. Tools Provided in the Storyboard Stencil Library


Storyboards were originally conceived at Disney Studios about seventy years ago. They are a sequential series of illustrations or rough sketches, sometimes including captions of events. Storyboards provide a synopsis for a proposed story (or a complex scene) involving its action and characters (see “storyboard” at ).

Storyboards transfer well into the world of the user interface. With a storyboard we can present as frames each step in a sequence of user interactions. Viewing the interaction in a story format helps to refine the interaction and provide feedback for user testing.

The Visio storyboard stencil library

The storyboard stencil library contains four basic tools:

  1. Storyboard Name. Describes the storyboard scenario and is used to reset the interaction animation.
  2. Storyboard Step. Describes a step in the animation and shows or hides interface elements as needed.
  3. Click. Used to document the user interaction with the mouse.
  4. Drag & Drop. Used to document a drag and drop interaction.

Underpinning the Storyboard library is the layer feature in Visio. Layers can contain shapes and be shown or hidden. Showing a layer causes all of the shapes that are within the layer to be made visible. Hiding a layer hides the shapes it contains; however, if the shapes are part of another layer that is visible, they will still appear. Any number of layers can be created on a page, and shapes may be associated with a single layer or with multiple layers.

The storyboard stencil library provides a way to associate a storyboard frame (or step) with a given set of layers that can be turned on or off. In this manner we can create a crude animation (much like a children's flip-book) that walks through the steps of an interaction.

The purpose of the storyboard stencil is to simplify animating the interaction steps with Visio layers.

Example: inline editing

So let’s imagine we have a photo sharing site and we would like to like to be able to edit the title of a photo directly (inline content editing an RIA concept) without having to go to a different page for editing the title (separate page editing a PIA concept.)

See figure 3 for the wireframe for this simple page. It consists of a title and a photo.

Photo Site Wireframe

Figure 3. Photo Site Wireframe

What we would like to simulate in our storyboard are the following interactions:

  1. Show that the title can be edited. Hovering over the title uses highlighting to indicate that the title is editable.
    Start editing the title:
    a. Clicking in the title allows direct editing of the text string “My Photo”. The text is surrounded by a rectangle, indicating the field is editable. Save and Cancel buttons are displayed next to the field.
    b. The entire text of the title is selected.

  2. Type in a new title. New text will replace the selected text “My Photo” with the new text “Rain Forest”
  3. Save the title. Hitting the Save button saves the title.
  4. Show the new title as no longer editable, but a simple part of the page content. The Save, Cancel. and text edit rectangle disappear on a successful edit. The new title appears as part of the normal content of the page.

See figures 4-8 for how this looks, frame by frame.

Step 1

Figure 4. Title Available for Editing

Step 2

Figure 5. Title Being Edited

Step 3

Figure 6. Title Has Been Changed

Step 4

Figure 7. Title About to Be Saved

Step 5

Figure 8. New Title: part of the page content

Notice that a number of additional shapes appear and disappear during the sequence of interactions. These are the additional interface elements that are needed to simulate the user interaction. In this example, we need eight shapes:

  1. Highlight
  2. Tool tip with cursor
  3. Text edit rectangle
  4. Text selection rectangle
  5. Save button
  6. Cancel button
  7. ‘Rain forest’ text
  8. Mouse click for the save button

See figure 9.
Interaction Shapes

Figure 9. Interaction shapes needed for storyboarding inline edit

In order for us to hide and show interaction shapes as needed, we have to associate them with layers that we can turn on and off at each interaction step. It is important to remember that the layers in Visio—not the individual shapes—are what get hidden or shown.

You might be tempted to think that if you have five interaction steps then you will always have five layers to manage. But that really depends on how fine-grained the interaction will be. Since an interaction step can turn on or off one or more layers, there is not always a one-to-one correspondence between the number of steps and the number of layers.

In our example, we need to show the text as selected in step 2b but remove the selection during step 3. This requires us to control the selection individually. To do this, we create a layer that only contains the selection—allowing us to control its visibility in turn.

OK, so here are the five layers we need to control the individual shapes:

  1. showTitleIsEditable. Contains the highlight and the tool tip.
  2. startEditing. Contains the text edit rectangle, Save, and Cancel buttons.
  3. selectEdit. Contains text selection rectangle.
  4. changeTitle. Contains the new title text.
  5. saveTitle. Contains the mouse click for the Save button.

The five interaction steps described earlier are modeled with five storyboard steps. The storyboard name will reset the animation. Each storyboard step will hide and show layers to simulate the user interaction. See figure 10.

Storyboard Steps

Figure 10. Complete Set of Storyboard Steps for Inline Editing

In order to drive the animation, we need to configure the storyboard name and each of the storyboard steps to control the hiding and showing of the correct layers.

What we need now is a way to tell the storyboard name and each storyboard step which layer or layers they will control. Fortunately, Visio provides a feature called custom properties that allows us to provide this additional information. Custom properties are a way to associate named data with a Visio shape. The storyboard name and storyboard steps come packaged with a custom property named Target Layers. The storyboard name’s Target Layers property will control which layers get turned on or off when resetting the storyboard animation. Each step’s Target Layers property will control what gets turned on or off at that particular step in the interaction.

Valid values for this property can be:

•  The name of a single layer
The layer will be made visible when the step is activated.

•  The name of a single layer preceded by the minus (‘−’) character
The layer will be hidden when the step is activated

•  A comma separated list of layers (each of which may optionally be preceded with a minus character)
Multiple layers will be hidden or shown. If the minus character precedes a layer it will be hidden. Otherwise it will be shown.

Double-clicking the storyboard name willThe storyboard animation is reset by double-clicking the Storyboard Name.

So for our example, let’s see how the Storyboard Name and the five Storyboard Steps have their Target Layers property configured.

Storyboard Name – Inline Edit of Photo Title
-showTitleIsEditable, -startEditing, -selectEdit, -changeTitle, -saveTitle
All interaction layers are hidden to start with (acts like a reset).

Step 1 – Show Title is Editable
The layer showTitleIsEditable is turned on. This shows the highlight and the tool tip instruction.

Step 2 – Start Editing
We get rid of the highlight and tool tip and show the text edit rectangle, Save button, Cancel button, and the text selection rectangle.

Step 3 – Type New Title
We get rid of the selection for the old title and show the new title text

Step 4 – Save Title
We show the mouse pointer and hint that the user will be clicking the Save button to save the title

Step 5 – Title Saved
We turn off the save the title hint as well as all of the editing affordances.

To view custom properties, make sure the View:Custom Properties Window menu option has been turned on. See figure 11.

Custom Properties

Figure 11. Target Layers Property Value for Step 3 – Type New Title Step

Stepping Through a Storyboard

To review we have

•  Five storyboard steps

•  Each step configured to hide/show individual layers

•  The correct user interface shapes mapped to each layer

We can now use the storyboard name and storyboard steps to simulate a user editing the photo title inline.

Double-clicking the storyboard name will reset the interaction. See figure 3.

To step through the inline edit interaction, double-click each storyboard step in sequence. See figures 4-8.

While this example is fairly trivial, more complex interactions can be built. In addition multiple storyboards can be used to represent different use cases. This is important for showing error conditions as well as different edge-cases.

Managing Layers in Visio

In the interest of getting you into storyboarding as early as possible in this article, I skipped some very important details on how to manage and manipulate layers directly in Visio. Let’s look at how to manage Visio layers.

Layers are managed using the View:Layer Properties menu command. The Layer Properties Window that pops up allows you to add, delete, rename and manage the visibility of layers. Note that without the Storyboard stencil library you would have to use this window to turn layers on and off for each step. Obviously this would make animating an interface very tedious as well as distracting because you would have to set each one yourself.

While you will not normally use the Layer Properties Window to manage layer visibility (this is handled by the storyboard steps), this will be the way that you create, delete and rename your layers.

In the in-line editing example, you would create each of the five layers by clicking the New button for each layer and naming them individually. See figure 12 for what the Layer Properties window should look like after adding these five layers. (Storyboard is automatically created and used by the stencil library.)

Layer Properties Window

Figure 12. Visio Layer Properties Window

The other important thing you need to know is how to associate shapes with a Visio layer. Select the shape or shapes you want to add into a layer. Then right click and from the popup context menu choose the Format:Layer command. This will allow you to add the shapes to a specific layer or to multiple layers. See figure 13.

Format Layer Window

Figure 13. Shape Layer Formatting Window

Two important toolbar shortcuts

Since the View:Layer Properties and the Format:Layer tools are used constantly when animating an interface, a good shortcut is to add both of these commands to one of the Visio toolbars.

Let’s add the View:Layer Properties command to a Visio toolbar. You can do this by selecting the Tools:Customize menu command and selecting the Commands Tab from the Customize dialog that pops up. You can find the Layer Properties command under the View category. Drag this command to the toolbar − any spot will do.

Now let’s add the Format:Layer tool to a Visio toolbar − the best place is beside the Layer Properties tool you just added. The Format:Layer tool is under the Format Shape category; there are two different Layer tools listed, so pick the one that has a drop-down box beside it. Drag this command to your toolbar.

Now you have one-click access for adding layers (View:Layer tool) and changing the layer with which a shape or shapes is associated (Format:Layer tool). See figure 14.


Figure 14. View Layer and Format Layer tools added to Visio toolbar

Now that the Format:Layer tool is located on the toolbar, you will find that the drop-down list of layers provides a nice way for viewing on which layer a currently selected shape resides. In addition, by selecting a new layer from the drop-down list, it will change the selected shape’s associated layer.


First, you will need to have Microsoft Visio 2003 installed on your machine. Second, you will need to download the file. Third, unzip this into your My DocumentsMy Shapes folder. (My Shapes should have been created by Visio when you installed it.) Now that it is installed, you can navigate to this directory and double-click inlineEditWireframeExample.vsd to experiment with the photo editing example or you can start your own wireframe by double-clicking the Wireframe.vst file.


These tools provide a way to extend a common wireframe design tool, Visio, to support a technique for storyboarding wireframes. The storyboard metaphor is a simple concept to grasp. As we demonstrated designs to our Product Marketing teams at Sabre we received complimentary remarks about how much easier it was to understand interactions documented with storyboards; this made it simple to spot issues very early in the design phases.

A nice touch is to walk through the storyboard scenarios recording the animation with a video capture tool. The video can then be distributed to other groups and customers for early feedback on the interaction design with no instructions needed for walking through scenarios.

At Sabre, we were able to demonstrate for an important customer very complex application interfaces simulating in-page process flows, drag and drop, and rich data interaction. The interface we demonstrated had actually gone through several rewrites in previous years with less than satisfactory results.

Using the Visio storyboarding techniques outlined here we were able to present three iterations of the interface in a span of a few weeks. The final walkthrough was a success, with the client very happy with the new proposed interface. Additionally, their comments were extremely positive about being able to see and participate in the design at the earliest phases.

Wizards and Guides

by:   |  Posted on

“…the seeming simplicity of these structures belies their versatility and broad applicability to a wide range of situations…”

In part one of this article the discussion was one of views, forms, and the manner in which they could be combined into a particular type of task structure known as a hub. The purpose of this installment is to expand on those themes by exploring two other types of task structures commonly employed in web applications. Known as wizards and guides, these additional structures are useful for presenting complex transactions and multipart processes in smaller and more manageable sequences of individual steps.

As shown in Figure 1, all three of these structures—hubs, wizards, and guides—are not only conceptually simple; their basic forms are also easily diagramed and understood. Like many primitive patterns, however, the seeming simplicity of these structures belies their versatility and broad applicability to a wide range of situations, from the simplest consumer applications to the most robust enterprise management tools.

As unlikely as it may seem, taken together, hubs, wizards, and guides comprise the full universe of task flows applicable to web applications and form the basis of all web-based processes and transactions. Although this closely parallels the world of information architecture and its similarly small universe of organizational structures—indexes, webs, and hierarchies—whether such a parallel results from an artificial coincidence, debatable definitions, or some sort of universal truth, is a subject I’ll leave to the comment boards. For now, however, let’s shift the focus to the subject of wizards: what they are and what they can do.

Problem: How to structure rigid procedures
Solution: Wizards

With a predilection for precision and a fondness for exacting input, computers are unavoidably creatures of habit. Try as we might to curb their natural tendencies, disguise their demands, or inject flexibility into their routines, there remain situations that require users to follow specific and prescribed paths in order to complete particular operations or procedures. Such situations call for the task flow known as a wizard.

A staple of desktop applications, wizards are also found in a variety of web-based applications. Essentially predetermined sequences of forms, wizards provide a mechanism for guiding users through complex operations that can be completed in one and only one sequence. One of the most common uses of a wizard, as shown in Figure 2, is found in applications used to reserve limited resources—a seat on an airplane, a ticket to a sporting event, or the increasingly-scarce conference room, for example.

Reservation wizards are a particularly useful case in point because they illustrate, in a concise manner, the defining characteristics of a wizard: a multi-step procedure where the interdependence between steps dictates a specific sequence. That last bit is the crucial part.

Wizards are not simply chains of dialog boxes strung together to make life easier for the user. Rather, they are a particular interface pattern for expressing a precise and rigid procedure that has to unfold in a known and specific sequence. Although wizards can contain any number of required or optional steps, that does not mean users can randomly navigate between those steps.

I know what you’re thinking: “But aren’t there any reservation systems where the user can browse availability without having to frame such a specific request?” Well, such systems do exist, and one example is at the site for British Airways. Shown in Figure 3, the BA design is an interesting and innovative approach because it exposes a significant portion of the fare structure in a clear and concise calendar format rather than leaving the user to fumble around, testing dates for pricing and availability.

There are two important things to note about this example. First, although this design doesn’t necessarily escape the tyranny of the wizard, it does enhance the interaction by recognizing that users will make more satisfying and efficient choices if they are given sufficient information. Second, because this wizard ultimately results in a transaction, it terminates with a page that summarizes the user’s choices and provides the relevant interface elements for either completing the transaction or discarding it and starting over.

Although not the case in this particular situation, wizards can also be used in the context of an operation where a terminating summary view isn’t necessarily relevant. Software installation and image uploading are two such examples of wizard-based operations that don’t terminate in an editable end state. In both cases, although the user specifies various options before initiating the operation, once the operation is underway it cannot be edited or abandoned in the same manner as a transaction. In these cases, rather than a transaction summary, the end state is either an alert confirming the success of the operation, or the return to an appropriate location in the application. A software installer typically terminates with an “All Done” message, for example, while an image upload operation naturally ends by displaying a page containing the uploaded images.

Although wizards are a common feature of the interface landscape, their rigidity clearly runs counter to one of the basic tenets of user-centered design: providing the user with appropriate control over the interaction. Therefore, like the pointy-hat mystics for whom they’re named, wizards should generally be treated with suspicion and skepticism, and ideally avoided whenever possible. Fortunately guides, a third type of task flow, can often be used in place of a wizard.

Problem: How to structure complex transactions and flexible procedures
Solution: Guides

Combining the structured sequence of a wizard with the navigational flexibility of a hub, guides are another type of task flow commonly used in web applications. Unlike wizards, guides do not assume any sort of strict interdependence between steps. As a result, guides can incorporate the navigational flexibility needed for users to access, process, and edit the forms in any order. And unlike hubs, guides also provide the requisite structure and sequencing needed to ensure users can successfully create and manage lengthy or complex transactions.

In the simplest, though admittedly abstract, terms, guides are effectively wizards that terminate in the view page of a hub. This view page allows the user to return to any part of the guide, modify data, and directly return to the terminating page without having to go through any of the intervening steps. Typically, the terminating page of the guide also includes a submit button, enabling the user to indicate that the transaction is complete and ready for processing. One of the most frequent uses of a guide is the checkout process common to ecommerce sites. A case in point can be found at, an online learning alliance. Like similar processes elsewhere, AllLearn collects billing, shipping, and payment information by logically breaking the task into multiple forms. Unlike the reservation wizard from British Airways, however, there is not a strict requirement affecting either the grouping of the information or the order in which the information is collected. For example, although AllLearn collects the user’s shipping address before their credit card information, that sequencing is by convention rather than necessity. As a result, because the steps are not dependent on one other, once the user has made their initial pass through the steps, they can randomly access and edit any of the previous steps without having to pass back through the entire sequence.

In fact, as shown in Figure 4, the final page of AllLearn’s guide effectively functions as the center of a hub task flow but with the addition of a master submit button that enables the user to finalize the transaction. (For more on the hub task flow, please see part 1 of this article.)

Because so many web applications are designed to facilitate lengthy or complex transactions, the guide’s ability to combine the navigational flexibility of a hub with the simplicity of a wizard renders it an extremely useful and versatile taskflow.

Guidelines for Usage

For designers, proper usage of wizards and guides not only requires an understanding of their relative advantages, disadvantages, and utility, but also an understanding of various conventions and best practices. These include the following:

  • Communicate purpose- It’s an obvious point that bears repeating: it is important to not only be clear about how to use a guide or a wizard, but also to be clear on why you’re using it, and to communicate that purpose to the user.
  • Minimize the number of steps- One of the more challenging aspects of designing these taskflows is to strike the appropriate balance between too many steps and too many options within any given step. While there’s no golden rule about this balance, suffice it to say that the optimal solution requires a conscious consideration of the tradeoffs.
  • Provide an exit path- Guides and wizards are not inescapable hallways; they are rooms. And like all rooms, they should include an accessible door so users can easily get out of them. Of course, if there are consequences to an untimely exit, those consequences should be communicated.
  • Limit navigation options- While a wizard or a guide is analogous to a room, we should limit the analogy to a museum gallery, rather than a concert hall. While it’s important to have an exit, if you’re trying to corral users down a particular path, it’s also wise to not have too many exits. Therefore pages that are part of guides or wizards should have limited navigation options. (For a more detailed explanation, please see part 1 of this article.)
  • Inform users of their progress- Because these taskflows embody discrete procedures and operations, users understandably enter them with a sort of “are we there yet?” mentality. Therefore, it’s important to keep users informed of their progress by clearly displaying both the number of steps in the sequence and users’ progress through them.
  • Do your homework- This isn’t really a guideline so much as a reminder that wizards and guides are merely one more interface convention: another arrow for your quiver, another tool for your toolbox. As such, they are simply a reflection of the care with which you analyze, understand, and address the unique needs of both the task and the users expected to complete it.

In Conclusion

Although this discussion has covered a lot of ground, it would somehow fail to be complete without the obligatory collection of summarizing sound bites. To wit:

  • Embrace the medium- The natural behavior of a web application features two modes: viewing and editing. Design accordingly by removing extraneous navigation options from forms and inappropriate interface controls from views.
  • Hubs- You go, you come back. Hubs are ideal for situations that use multiple, discreet, single-page forms.
  • Wizards- Step one, two, three. Wizards are appropriate for multi-page procedures or operations that must be completed in a prescribed order.
  • Guides- This way please. Guides are useful for complex, multi-part sequences that seek to combine the navigational guidance of a wizard with the navigational flexibility of a hub.

So there you go: hubs, wizards, and guides in all their glorious detail. I look forward to reading your comments soon.

Next up, my model for dissecting and describing a user interface.

Bob Baxley is a practicing designer who specializes in interaction design for Web applications and desktop products. An independent consultant in Silicon Valley, he is also the author of “Making the Web Work: Designing Effective Web Applications.” Bob writes about design at and a host of other things at

Usability Heuristics for Rich Internet Applications

by:   |  Posted on
“The key difference between a typical Flash site and an RIA is that RIAs possess the functionality to interact with and manipulate data, rather than simply visualize or present it.”Heuristics, or “rules of thumb,” can be useful in both usability evaluations and as guidelines during design. Jakob Nielsen’s 1994 set of usability heuristics were developed with a focus on desktop applications. In 1997, Keith Instone shared his thoughts on how these heuristics apply to what was a relatively new area: websites. Today, in 2003, with Flash-enabled Rich Internet Applications (RIAs) becoming more popular, Nielsen’s heuristics still offer valuable guidelines for RIA designers and developers.

In this article, we focus on Flash because it currently dominates the RIA landscape. However, many of the lessons for Flash apply to other technologies as well.

Rich Internet Applications offer the benefits of distributed, server-based Internet applications with the rich interface and interaction capabilities of desktop applications. The key difference between a typical Flash site and an RIA is that RIAs possess the functionality to interact with and manipulate data, rather than simply visualize or present it. While RIAs hold significant promise, many in the Flash community don’t have the opportunity to work with interaction designers, information architects, or other user experience professionals. As well, user experience professionals often decry Flash or other rich technologies as “bells and whistles” that detract from user goals. We hope this article provides some common ground for discussion between the two communities.

The list below includes Nielsen’s heuristics in bold; our comments about how they apply to RIAs follow each heuristic. Since RIAs cover a broad range of applications, we know we haven’t covered everything. We’d love to hear your own thoughts and experiences in the comments.

1. Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
RIAs should leverage the rich display capabilities to provide real-time status indicators whenever background processing requires the user to wait. While progress indicators are frequently used during an extensive preload when launching an application, they should also be used throughout a user’s interaction with data. This may be monitoring backend data processing time or preloading time.

When dealing with sequential task steps, RIAs should indicate progress through the task (e.g., “Step 4 of 6”). This helps users understand the investment required to complete the activity and helps them stay oriented during the activity. Labeling task steps will provide a clearer understanding of system status than simply using numbers to indicate progress. RIAs’ ability to store client-side data can be used to allow the user to skip optional steps or to return to a previous step.

System status should relate to the user’s goals, and not to the technical status of the application, which brings us to our next heuristic.

2. Match between system and the real world

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
Understanding the user’s vocabulary, context and expectations is key to presenting a system that matches their world. While RIAs are made possible by the functionality of Flash and other technologies, users are usually not familiar with terms like rollover, timeline, actionscript, remoting, or CFCs – such technology-based terms should be avoided in the application. (See our sidebar for definitions if you’re not sure of them yourself).

While RIAs can offer novel metaphors, novelty often slows usefulness and usability. When using metaphors, ensure that they act consistently with their real-world counterparts. If application functions cause the metaphor to behave in ways that don’t match the real world, the metaphor has lost its usefulness and should be discarded in favor of a different concept.

Both information and functionality should be organized to reflect the user’s primary goals and tasks supported by the application. This supports a user’s feeling of competence and confidence in the task – a key need that is also supported by letting the user stay in control.

3. User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Users are familiar with browser-based controls, including the Back button and Location field. However, using browser commands within an RIA may result in data loss.

The RIA should include code that is aware and responsive to browser history. For applications that contain complex functionality that is the focus of user attention, creating a full-screen version that hides the browser controls can be appropriate as long as there is a clearly marked exit to return to the browser.

While “undo” and “redo” are not yet well-developed in the Flash toolkit, changes to data can be stored as separate copies, allowing the application to revert to a previous version of the data. However, this becomes quite complex in multi-user environments and requires strong data modeling to support.

Many Flash projects include splash screens or other scripted presentations. These non-interactive exhibitions of technical prowess reduce the user’s feeling of control. The ubiquitous “Skip Intro” link offers little help – instead, consider how any scripted presentation benefits the user. If a scripted sequence doesn’t support user goals, skip the development time in favor of something that does. One area that may be a better investment is working to ensure consistency in the application.

4. Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
All applications require consistency within their features, including terminology, layout, color, and behavior. Complying with interface standards can help maintain consistency. However, since RIAs are a new category of applications, standards are still being developed. The Microsoft Windows User Experience guidelines, Apple Human Interface guidelines, and Macromedia’s developing guidelines provide some alternatives starting points for RIA standards.

Branding guidelines also often require consistency that RIA teams need to consider. RIAs are often deployed as branded solutions for a variety of customers. The application needs to be flexible in implementing custom copy, color, and logos. However, branding should not compromise good design. RIA teams may need to show that the brand will gain equity through applying useful and usable standards as well as beautiful visual design. A gorgeous, cutting edge, award-winning presentation won’t help the brand if it’s easy for users to make disastrous mistakes that prevent them from reaching their goals.

5. Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
In forms, indicate required fields and formats with examples. Design the system so that it recognizes various input options (780.555.1212 vs. 780-555-1212) rather than requiring the user to comply with an arbitrary format. Also consider limiting the amount of data entry required and reducing input errors by saving repetitious data and auto-filling fields throughout the application.

Avoid system functions with disastrous potential, such as “Delete All Records.” When functions with significant impact are necessary, isolate them from regular controls. Consider an “Advanced Options” area only accessible to administrators or superusers, rather than exposing dangerous functionality to all users.

With RIAs, when problems do occur, network connectivity allows for the capture and transmission of error details. Similarly, the distributed model of RIAs empowers developers to provide minor updates that are nearly immediately available to the user. These immediate updates can provide correction to issues that repeatedly cause user errors. Beyond the technology, another way to prevent errors is to make currently needed information available to the user instead of making them remember things from previous screens.

6. Recognition rather than recall

Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Too often, the rich presentation possibilities of Flash are used to play hide-and-seek with important interface elements. Don’t hide controls that are key to user tasks. Revealing application controls on rollover or with a click can create exciting visual transitions, but will slow user tasks and create significant frustration.

Since people who are engaged in a task decide where to click based on what they see, rollovers or other revealed elements can only provide secondary cues about what actions are appropriate. The interface should provide visible primary cues to guide user expectations and help users predict which controls will help them achieve their goals. While some of these cues will be basic functionality, cues should also be available for frequent users to show functions that save them time or let them work more flexibly.

7. Flexibility and efficiency of use

Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
RIAs can leverage the advanced functionality of the platform to provide accelerators such as keyboard shortcuts, type-ahead auto-completion, and automatic population of fields based on previously entered data or popularity of response.

Less technically sophisticated accelerators should also be available—particularly bookmarks—either by allowing bookmarking in the browser, or creating a bookmark utility within the application itself. Another option for giving quick access to a specific screen is assigning each screen a code which a user can enter in a text field to immediately access the screen without navigating to it.

RIAs also offer the opportunity allow for personalization of the application through dynamic response to popularity or frequency of use, or through user customization of functionality.

Established usability metrics, such as time spent carrying out various tasks and sub-tasks, as well as the popularity of certain actions, can be logged automatically, analyzed, and acted on in a nearly real-time fashion. For example, if a user repeatedly carries out a task without using accelerators, the application could provide the option of creating a shortcut or highlight existing accelerated options for completing the same task. However, providing these options should be an exercise in elegance, instead of a display of technical prowess.

8. Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
For any given feature, style, or branding element, ask two key questions: “What is the return on investment for the business?” and “What is the return on experience for the user?” What value does the element contribute? If a feature can be removed without seriously impacting ROI or ROE, the application will be better without it.

RIA design is often a balancing act between application functionality and brand awareness for the business. Limit user frustration by reducing branding emphasis in favor of functionality. While branding can and often should play an important role, the brand will best be supported by a positive user experience. Rather than creating a complicated visual style with an excess of interface “chrome,” work for simplicity and elegance.

Animation and transitions should also be used sparingly. While animation and transition can make a great demo in the boardroom, gratuitous animation will provoke user frustration. The time to animate an element interrupts a user’s concentration and engagement in their task. Disrupting task flow significantly impacts usability and user satisfaction.

Sound can also disrupt task flow – use subtle audio cues for system actions, rather than gratuitous soundtracks that are irrelevant to the task at hand.

A further advantage of maintaining clean, minimalist design is that it generally results in decreased file size, and lessened load times, which is essential given the limited patience of many internet users. Another advantage is that a clean interface makes it easier for the user to recognize when things are going right, and when things are going wrong.

9. Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Changing the visual appearance of an interface element when the mouse “rolls over” it. A rollover may also trigger changes to other interface elements.

The Flash development environment shows a timeline to organize screen elements and their interaction over time, and along with ActionScript is the primary way of creating interactivity in Flash applications.

A JavaScript-based scripting language built into Flash. Used to program interface actions and behaviors.

Server technology called Flash Remoting allows the Flash client to interact with software components on a server that can contain business logic or other code. Flash Remoting can allow connections between Flash and server programming environments like ColdFusion, .NET, Java, and PHP. This provides for a cleaner division of labor and better security, with the server-side components doing the heavy computational lifting and the Flash client focusing on user interaction.

Acronym for ColdFusion Components – server-based software components written in Macromedia’s ColdFusion language. CFCs natively support remoting.

Error messages should hide technical information in favor of explaining in everyday language that an error occurred. References to “missing objects” or other development jargon will only frustrate users.

RIA error messages can explain complicated interactions using animation. However, animation should be used sparingly in favor of clear textual explanations. Explanations should focus on solutions as much as causes of error. Display error messages along with the appropriate application controls or entry field sot that the user can take appropriate corrective action when reading the message. The ability to overlay help messages or illustrations directly over the interface can be useful in explaining task flow between related screen elements.

When errors are not easily diagnosed, make solution suggestions based on probability – ask what things is the user most likely to want to accomplish right now, and present those options.

RIAs also provide the opportunity to immediately connect a user experiencing major difficulties with support personnel who can guide them to a solution through text chat, video chat, or remote manipulation. These live support channels are just some of the help options available to RIA teams.

10. Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
RIAs should contain simple and concise instructions, prompts, and cues embedded in the application itself. More extensive help should be available from within the RIA.
Using animation or video tutorials with concise narration can often guide a user through complex tasks, while engaging individuals who learn better from visual or audio instruction rather than text. Showing the required steps is often easier for the user to understand than mentally translating a text description of the steps to the appropriate interface elements. Providing immediate contextual help through the use of tool tips and contextual help buttons allows the user to complete their tasks without having to shift focus to a help system.

This take on how Jakob Nielsen’s heuristics apply to RIAs are far from definitive. Rather than accepting these examples as unquestioned rules, we hope it sparks your own thinking about how to apply the heuristics in your work, whether you’re a Flash developer or an interaction designer (or both). RIAs hold considerable promise for both Flash developers and user experience practitioners. Usability best practices like Nielsen’s heuristics are essential for realizing that promise.

The key takeaway for the Flash community: RIAs aren’t about grabbing attention, they’re about getting things done. This is a different mindset than many marketing-driven Flash sites, where bells and whistles are often encouraged in an effort to hold short attention spans. With RIAs, there’s no need to shout – the user is already engaged in accomplishing a goal. The best way to rise above the crowd is to cultivate a deep understanding of who your users are, what their goals are, and then design to meet those goals as quickly and elegantly as possible.

The key takeaway for the user experience community: Flash has matured beyond bells and whistles to provide a platform that enables a far better user experience for complex interactions than regular browser technology. While it isn’t perfect, it can open new possibilities for you as a user advocate. You’ll hear less “we can’t do that” from engineering teams, and be able to create interfaces and interactions closer to your vision. Getting to know the potential of Flash and other RIA platforms will help user experience professionals take advantage of the rich interaction available.

Over the coming months and years, RIAs will move from cutting edge to mainstream. That transformation will accelerate with the Flash and user experience communities working together to understand and develop best practices and shared knowledge. We’re looking forward to great new things— if you’re already doing them, drop us a line in the comments.

Jess McMullin is a user experience consultant who helps companies innovate products and services. Through value-centered design, Jess works to maximize return on investment for his clients and return on experience for their users. A founder of the Asilomar Institute for Information Architecture, he runs the popular IA news site iaslash. He is based in Edmonton, Alberta, Canada.

Grant Skinner On the cutting edge of Rich Internet Application conceptualization and development, Grant fuses coding prowess with interface design, marketing and business logic. Grant is internationally recognized for his work on, FlashOS2 and gModeler. As a freelance consultant, Grant works with corporate clients and leading web agencies to deliver online solutions that generate value. A frequent conference speaker, he will be speaking on usability issues specific to RIAs in SIGGRAPH at the end of July. Grant is based in Edmonton, Alberta, Canada.

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

by:   |  Posted on
“Creating web applications that support the full and valid completion of specific tasks, operations, and database transactions, require some understanding of how to manipulate the medium to that purpose. ”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—the benefits of which include:

  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.

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.

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

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.

Solution: The Hub Structure
Example: Mailblocks Preferences Forms

The structure of a hub is one of the most common task flows used in HTML-based Web applications. As its 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:

  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.

(Editor’s note): I’m happy to announce the beginning of Boxes and Arrow’s first discussion list. Dedicated to the topic of interaction design, <“Interaction”> awaits your participation. Please come join the conversation.Bob Baxley is a practicing designer who specializes in interaction design for Web applications and desktop products. He currently runs the Design and Usability teams at The Harris-myCFO and recently published his first book, “Making the Web Work: Designing Effective Web Applications.” He looks forward to hearing from you at .

What is a Web Application?

by:   |  Posted on
“The fundamental purpose of all web applications is to facilitate the completion of one or more tasks.”To reiterate the themes of dance and conversation introduced in my last column, truly superior interaction design strikes a delicate balance between the needs and expectations of users and the capabilities and limitations of technology. The ability to consistently find solutions that achieve this balance in a manner appropriate to the medium is a hallmark of an experienced interaction designer.

The purpose of this article is to improve your ability to find that balance by adding to your understanding of web applications as an interactive medium. What distinguishes a web application from a traditional, content-based website and what are some of the unique design challenges associated with web applications? A reasonable launching point is the more fundamental question, “What is an application?”

What is an application?
The first step toward differentiating web applications from traditional content-centric websites is to focus on the “application” part of the equation. According to the American Heritage Dictionary, an application is (among other things), “…a computer program designed for a specific task or use.” That last phrase, “specific task,” is perhaps the most important.

The fundamental purpose of all web applications is to facilitate the completion of one or more tasks. Unlike visitors to traditional, content-centric websites, users of web applications invariably arrive with specific goals, tasks, and expectations in mind. Of course, that’s not to say that visitors to content-based websites don’t also arrive with certain goals and expectations, but rather that the motivations for using a web application are almost always explicit and precise.

One of the most important implications of this task-based orientation is the degree to which the application should call attention to itself. Compared to content-centric websites, video games, and various forms of entertainment media, application design succeeds not when it draws attention to itself but when it recedes into the background. This requires the designer to find solutions fundamentally natural to both the user and the medium, allowing the application itself to become transparent. The paradox of application design is that the perfect solution is invariably the one that goes unnoticed.

While this does not mean that an application’s design shouldn’t be enjoyable and aesthetically pleasing, it does mean that the design should play a subservient role to the user’s work.

A second implication of their task-based orientation is that web applications have to provide users with various milestones informing them when tasks are complete. In other words, web applications have to support an end-state in a way that content-based sites typically don’t.

In addition to the challenges resulting from their focus on task completion, the manner in which web applications function and connect with users highlights other issues affecting web application design.

When is a website a web application?
Without being overly concerned about semantics or classification (if that’s actually possible on a site like Boxes and Arrows ), it is important to establish an objective means of differentiating between a web application and a traditional website. To wit, in contrast to content-based websites, a web application possesses both of the following observable properties:

  • One-to-one relationship – Web applications establish a unique session and relationship with each and every visitor. Although this behavior is fundamental to Web applications it is not present in either content-based websites or desktop applications. A web application such as Hotmail knows who you are in a way that Cnet or even Photoshop doesn’t.
  • Ability to permanently change data – Web applications allow users to create, manipulate, and permanently store data. Such data can take the form of completed sales transactions, human resources records, or email messages to name but a few. This contrasts with web services like Google that allow users to submit information but do not allow them to permanently store or alter information.

Although these two characteristics alone result in a fairly broad definition of web applications, websites that possess both of them necessarily contain a degree of application behavior, logic, and state lacking in traditional content-based sites. In addition, they require a significantly more sophisticated level of user interactivity and interaction design than what is associated with content sites.

This distinction between websites and web applications is most obvious in situations where a given site is almost exclusively composed of either content OR functionality. (a website) and Ofoto (a web application) are two such cases. However, even popular web destinations such as Amazon, and myYahoo!, sites that combine both content AND functionality, should be considered web applications because they meet these two criteria and therefore exhibit the interactive complexities and behaviors associated with applications.

In the case of Amazon, this takes the obvious form of personalized content and complex transactions, as well as a variety of other functions including the creation and storage of , the uploading and ordering of digital photographs, the editing and tracking of orders, and many others. That’s not to say that all online stores qualify as web applications; in fact most don’t. But Amazon and other stores of similar sophistication have the same characteristics and design considerations as more traditional applications such as email and contact management.

Granted, consumer sites like Amazon and myYahoo! typically lack the level of complexity found in licensed enterprise applications such as Siebel, PeopleSoft, or Documentum, but as a tool for classification, complexity is both inadequate and subjective.

Whether any particular application has sufficient complexity to require a highly skilled interaction designer is a question that can only be answered on a case-by-case basis. The point remains, however, that if a web property establishes a one-to-one relationship with its users and allows those users to edit, manipulate, and permanently store data, then it possess certain capabilities and complexities that distinguish it from traditional content-centric websites.

So what? “The point remains, however, that if a web property establishes a one-to-one relationship with its users and allows those users to edit, manipulate, and permanently store data, then it possess certain capabilities and complexities that distinguish it from traditional content-centric websites.”If the point of all this definition stuff was simply to provide a consistent method for classifying web properties, the whole exercise could be dismissed as little more than academic rhetoric. What’s useful about this definition, however, is not so much its utility as a classification scheme, but rather its ability to highlight some of the unique design challenges and functional benefits associated with web applications.

One of the most significant challenges and benefits results from the one-to-one relationship web applications form with their users.

Because a web application requires each user to uniquely identify themselves to the system, typically through a username and password pair, the application can be dynamically altered from one user to the next. This can take both the obvious form of personalized content and the more subtle and complex form form of personalized functionality based on roles and privileges. This type of dynamic behavior allows a complex corporate accounting application, for example, to provide different functionality to account managers, regional directors, corporate executives, etc.

Although this type of capability has been a mainstay of enterprise applications for some time, many less sophisticated or expensive applications now employ this behavior. For example, consumer-based online services can add and remove features or advertising based on whether or not a particular user has paid a subscription fee.

More so than any other interactive medium, a web application has the ability to adapt itself to each user, providing them with a personalized and unique experience. Accommodating the full range of permutations afforded by this capability is a unique and significant design challenge. Because various functions, interface controls, and data can dynamically come and go from the interface, designers are forced to think in terms of modular components that are simultaneously harmonious and autonomous.

In the same way that it is practically impossible for a visual designer to fully anticipate how a given web page will look in every situation, the designers of large-scale applications also struggle to fully document and consider every possible permutation of functionality and data.

Another unique design challenge associated with web applications results from their ability to allow users to make permanent changes to stored data. Because web applications are fundamentally database applications–that is, they store and present information contained in a defined database structure—the user’s information almost always has to fit within a predetermined format. Certain fields are present; some fields are required, others are not; some require a specific type of value; and still others require a value within a precise range. The result of all this is a level of data validation and error recovery unseen in either content-based websites or most desktop applications.

Accommodating this behavior requires the designer to carefully consider the task flow from one operation to the next, the full scope of potential errors, the most expedient way to recover from errors, and of course the holy grail of it all, the ideal solution for avoiding errors altogether.

All this points to one critical conclusion: web applications are a new form of interactive media, distinct from both content-based websites and traditional desktop applications. Therefore, the creation of truly useful and usable web applications requires the designer to understand, appreciate, and exploit the unique capabilities, limitations, and conventions of this new medium rather than simply approaching the design problem from the perspective of more established interactive mediums.

Next Up
Next time around we’ll continue to explore web applications as an interactive medium by comparing their advantages, disadvantages, and uses to traditional desktop applications.

Bob Baxley is a practicing designer who specializes in interaction design for Web applications and desktop products. He currently runs the Design and Usability teams at The Harris-myCFO and recently published his first book, “Making the Web Work: Designing Effective Web Applications.” He looks forward to hearing from you at .