Mode-aware tools and mechanisms

2020-03-27 @Blog

I want to see more of these. But let’s first establish some definitions.

Whenever we can adapt the same syntactical features of a mechanism to varying context, we introduce modality.

VIM, for instance, is a modal text editor. In the editing/insert mode, we (mostly) type verbatim. In the normal mode, we type keystrokes to execute different behaviors: navigate/search, manipulate/transform text, define/launch macros/aliases/mappings, interact with external mechanisms, and perform most non-editing operations. In the visual mode we select text. In the execute mode, we limit ourselves to the VIM command-prompt.

VIM being a ‘meta’ editor, we can also redefine most of these behaviors, introduce additional modes and overload the syntax (keystrokes) to carry out radically different functions based on the active mode.

The Penti keyboard is a modal chorded keyboard. The five triggers enable maximally thirty two combinations, although effectively less. This clearly doesn’t cover the expanse of an entire keyboard. It therefore appeals to modes: alpha, digits/operators, punctuation, functional control, alternative characters, plus the control sequences.

Furthermore, the alternative characters can be redefined. This makes Penti loosely meta.

I’ve now mentioned two categories of mechanisms: modal and meta.

To recap:

Ideally, I would prefer that mechanisms feature both characteristics. Why? Because our interactions with those mechanisms yield to:

  1. Greater efficiency. A greater modality factor means less syntax required per mode and less mechanical operations to carry out the same behavior.

  2. Greater intuition/logic. Unless the modal interface is haphazardly designed, the syntax-to-behavior mappings applicable to each mode will usually follow some intuitive structure.

    In addition, the structure often facilitates mnemonic/visual queues, these more natural for the learning process of our visually inclined brain. And with the meta characteristic, we are free to redefine the syntax to incorporate further logic and ease of learning.

    These factors, consequently, further reinforce #1, the efficiency factor.

That’s not to say that a uni/few-modal mechanism lacks these elements. But in general, the lesser the modality factor, the broader range of syntax is necessary to carry out the same range of behavior, which inevitably compromises certain intuition and leans towards abstraction/esoteric definitions.

If I had to choose exclusively between the two properties, I would lean towards modal, hence the title of this writing. Considering we usually spend a significant enough period within a single mode, I prefer operational compactness, in hopes that the statically defined behavior was intuitively enough engineered.

This last point deserves further exploration.

We indeed spend much of our time operating within a single mode, rather than switching between modes in micro time-increments. Some examples of modes:

Each of the above modes demands fairly limited syntax (language) to perform. Only the syntax is not necessarily compact or optimized; the mechanism not necessary mode-aware.

Why not re-engineering many of our mechanisms to leverage mode-aware syntax? Some ideas:

Here I present some existing, as far as trivial cases of modality:

Lastly, I classify a sample of mechanisms on the modality scale:

- Strongly-modal Weakly-modal
Programming Lisp Perl
Spoken languages NA Any featuring overloadable words or ideograms
Constructed languages Speedwords, Shorthand Lojban
Written notations Mathematics, music notation Sign language
Applications VIM, Tmux (terminal multiplexor) MS Power Point, most SaaS (cloud software)

Questions, comments? Connect.