Modes

Ʌ: Ideas

A lot of ink has been spilled on modal and modeless interfaces, with the former generally being discouraged in modern interfaces:

Modes are often frowned upon in interface design because they are likely to produce mode errors when the user forgets 🌐 what state the interface is in, performs an action that is appropriate to a different mode, and gets an unexpected and undesired response.[6] 🌐[7] 🌐 A mode error can be quite startling and disorienting as the user copes with the sudden violation of his or her user expectations 🌐.

Whereas the latter has remained popular in “power tools” like vim, which retained their modal interfaces by virtue of their age (see Technological Epiphenomena).

Mode Congruence

I think there is a missed underlying point in that the base interaction model is often “modal” in nature. (See Information Diet, redux) Good design of modes is one that mirrors the interaction patterns of the user.

In vim, this is debatable - it does make sense for me to separate actions which operate on text (yanking, pasting, moving, regexing) with simply inputting text, but I would imagine this is not the case for most users, or even use-cases - it certainly doesn’t hold true while I’m writing this note, but it is much more balanced when working on source code.

The wholesale rejection of modes in modern interfaces did wonders for approachability, but I do not think that all modes are created equal, and the attempts to squish all functionality into a single interface might even work in the opposite direction as the interface gets more complex, and its use cases more separate.