Pattern 66: Avoid pre-emption
AKA:

Back to Diagram 1 - Getting started Back to Diagram 2 - Useability Back to Diagram 3 - Adding detail Back to Diagram 4 - Workflow/security

View sensitizing image - tbd

You are trying to ensure that there are NO MODES (40).

The specific problem is pre-emptive modes. You should be able to do anything anywhere (e.g. there should be no Y/N questions or immovable dialogue boxes), but sometimes there is no choice but to restrict the user for his own safety or yours.

Therefore

Avoid pre-emption where possible but balance the principle with one of safety first. Allow forms to be filled in in any order.

This pattern is terminal within this language.


Discussion - forces - known uses

Modes are bad because the restrict the user’s sense of being in control. Pre-emptive modes are no exception and should be avoided. However, There are situation where the user needs to be protected from and rash and damaging action for which an undo facility cannot be provided or not guaranteed to work – when there is a crash for example.

Non-pre-emption is a good principle because it restricts the flexibility of the interface and the range of tasks to which it can be applied. On the other hand, there is sometimes a real need for pre-emption to prevent catastrophic, inadvertent errors. The user might erase several pages by accident, delete or overwrite files unintentionally, forget to save some important work, lock the keyboard or system inadvertently or fill memory and abort the session by accident. Such dangerous moves are candidates for pre-emptive prompts.

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