Modal interfaces

(need definition of modal interfaces here)

Some modal features (like our secondary/auxilary toolbar) are appropriate, as long as they are simple conveniences, or the features they provide access to are completely inappropriate outside a specific setting (e.g. node operations in the node tool).

However, in general usability studies have shown that modal interfaces are harmful for usability.

There are at least two reasons for this:

1. Modality requires the user to build and maintain a mental model of the application's internal state, to which they must refer to determine what a specific action or keypress will do. Visual indications of the current mode mitigate this burden a little, but they do not remove it entirely.

2. The user also needs to maintain a mental map of state transitions necessary to reach a particular feature they want to use; performing a complex series of actions to traverse those states may be very inconvenient in its own right.

A key goal for our user interface design is to reduce the amount of "modality" in the interface.

In practice, any sufficiently complex interface will need to have modal elements, but it's important to minimize them, and avoid making modes too fine-grained.

1. Only a very small set of actions should change the application's mode. 2. For most tasks, a user should not be required to change modes very often. 3. The current mode should be clearly indicated visually.