Pattern 40: No modes [Abstract]
AKA:

How do you give the user a sense of being in control of her own destiny when using your site?

Therefore

Try to avoid modes when you design the site, especially when implementing workflows. Use modes only when you need to stop the user causing damage or when transactions are necessarily irreversible. Warn users before switching modes.

Consider EQUAL OPPORTUNITY (65) and AVOID PRE-EMPTION (66).

Modes in a user interface are defined as ‘variable information in the computer system affecting the meaning of what the user sees and does’. In a modal system the user is required to know what mode the system is in because the same action may have quite different effects in different modes.

It is commonly agreed that modes should be avoided but that they are sometimes necessary. For example, having user and novice modes is widely agreed to be almost a principle in its own right. Certainly the system should inform the user of the current mode and it is good practice to attract attention to the change by a change of colour in the mode indicator, a status bar or some such device. Examples of modes in an interface include: pressing the ON button on a typical calculator, where the mode is either on or off and the effect is different in each case; a ‘Cannot save file – disk not formatted’ message reveals a mode; as does ‘Overwrite existing file?’. Dialogue boxes are usually modal in that the behaviour of other visible options is suspended while they appear; the behaviour of part of the screen has thus changed. The notion of modes is closely related to that of polymorphism; polymorphic interfaces are precisely modal. However, what is useful in a language is not necessarily good in an interface.
It is very helpful to provide users with information about the context within which their actions will be interpreted. This includes information on state dependencies and modes and should explain the current task with its pre-conditions, post-conditions and side effects. Modes should only be used where it is absolutely necessary to restrict the user’s freedom of interaction. Temporal modes can be used to enforce a certain sequence of operations but this implies burdening the user with a heavy load on memory. This should never be done useless out-of-sequence actions are catastrophic. The commonest example of this is the excessive use of cascaded modal dialogue boxes where a simple data entry form would do better. Spatial modes are common when several things are possible but only one can be done at a time. Highlighting icons and changing the mouse pointer are good ways to draw attention to spatial modes. Other contextual information can be given in a status bar, such as the state of the irritatingly-close-to-the-main-keyboard ‘insert’ key on most PCs.

It is generally wise to include undo and redo facilities to encourage exploratory learning and protect users from catastrophic errors. However, undo and modelessness can be incompatible as Thimbleby (1990) demonstrates, though the argument is too intricate to summarize here. It is largely because undoing multiple actions may change the state of the system in other ways. Modern interfaces often respond ‘can’t undo’ when they encounter this situation.

Thimbleby gives the following principles for modes, breaking them down into principles for pre-emptive, inertial, input and output modes along with a general principle of equal opportunity.

• Pre-emptive modes. You should be able to do anything anywhere (e.g. there should be no Y/N questions or immovable dialogue boxes).
• Inertial modes. The layout of successive screens should change as little as possible. When you go back everything should be as you left it. The most [recently|likely|frequently] used menu selection should be highlighted.
• Input modes. The system should be sufficiently consistent to use with the display switched off (e.g. q or Alt-F-X for quit).
• Output modes. WYSIWYG (what you see is what you get).

The last of these of course is inapplicable to web design. The first is a pattern in its own right.

One of the commonest examples of modality on the web is a disabled back button. Another, where there is no option but to switch modes, is the ‘confirm purchase’ button.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites