Interface Modes

Key ideas#

Gestures and chunking#

Raskin calls a sequence of actions that runs automatically once started a gesture. For a skilled typist, typing a short word is one gesture; for a beginner, it is several. Merging steps into one mental unit is called chunking.

What a mode is#

As a first approximation, an interface stays in one mode as long as a given gesture keeps the same meaning. If the same gesture now means something else, you are in a different mode. Raskin then sharpens this with attention. A gesture is modal when:

1. the state that decides its effect is not where the user’s attention is, and
2. that state can make the same gesture trigger different actions.

Feedback is not enough#

Donald Norman explained mode errors as a lack of feedback about the system’s state. Raskin disagrees: even a clear indicator fails if it isn’t in the user’s locus of attention. His case is a CAD program where the cursor shape signaled a drawing mode, right where the user was looking. Yet a user for whom selecting objects had become automatic kept missing the change for years.

Experience doesn’t protect you#

Beginners make mode errors because they don’t know the mode; experts make them because the action has become automatic. Raskin’s example: in most programs one shortcut creates a new document, but in a particular mail program a different shortcut creates a new message. Beginners (by false generalization) and experts (by habit) make the same mistake.

Measuring modality#

Raskin proposes a degree of modality from 0 (fully modal) to 1 (fully modeless). You classify each gesture as modal or modeless and weight it by how often it is used. This turns “this feels modal” into a number for comparing alternatives. A subtle point: Backspace is formally modal, because it deletes whatever was typed last. It causes no trouble, though, because what it deletes is in the user’s attention.

Three ways to prevent mode errors#

Raskin assesses three remedies proposed by Norman:

1. Don’t have modes. This is the only way to eliminate mode errors.
2. Make modes clearly distinct. This often fails, as the CAD case shows.
3. Don’t use the same command in different modes. This doesn’t reduce errors, but it reduces their damage.

Lock and Unlock: state, not action#

A button labeled “Lock” that changes to “Unlock” when pressed confuses many users. They read the label as the current state, not as the action. Raskin’s fix is to change the control: a checkbox, or a set of options labeled with adjectives that describe the object’s state (“Locked” / “Unlocked”). A single toggle is acceptable only when the state it controls is visible and in the user’s attention or short-term memory. Otherwise, show all options explicitly.