Forgive errors

Application failures are only one way that safety failures can happen. The other is often called "user error," which is a misnomer since often the fault lies with a poorly designed application, not the user. Well-designed Flex applications are forgiving of user mistakes and smart enough to prevent safety failures even if the user appears to be requesting them. This section describes how.

The most important safety feature of any application is "undo." A properly implemented undo instantly forgives any mistake, using the computer's powerful memory to immediately revert things back to the way they were before the problem occurred. Undo makes users confident that they can explore the application and try out unknown functionality; if something they didn't desire or expect happens, they can always select the undo option. All applications should provide some means of undoing mistaken operations.

 

Figure 2a. In desktop applications like Adobe Fireworks, the Undo and Redo operations are standard menu items that appear in the Edit menu. Most desktop tools include this feature; users sorely miss it when it is lacking.

Figure 2b. Sadly, Undo is a feature that is missing from most web applications. Fortunately, this is changing; Gmail supports a single level of undo that appears as a link next to the orange notification message that appears after an operation has completed.

However, it isn't always clear how to expose the undo operation to users in a Flex application. In the desktop world, undo is usually the first item in the "edit" menu. For Flex applications that contain menus this works well, but not all do; generally these are limited to creation-focused applications or sufficiently complex information-focused applications. Other information-focused or simpler creation-focused applications should provide an always-available button in the primary control bar. Task-focused applications, on the other hand, should generally think of undo as "cancel." All completed tasks should be represented in the application and should have an associated operation to cancel their effects for as long as this as possible. If this is no longer possible, for instance if an order has already shipped, the cancel command should provide information on what options, if any, remain to the user. Tasks that must be canceled before a certain time limit must clearly communicate to the user how long he has to change his mind after he completes his task.

 

Figure 3. ETrade's bill pay system allows users to view a list of pending payments and cancel payments they no longer wish to send out. In task-focused designs like this, cancellation often takes the place of undo. (Note: This design was modified slightly to remove sensitive information.)

Page 3 of 5

Previous Page

Next Page