The terminal deserves its own UI paradigm.

Terminals have long been stuck in the teletype past. The recent TUI revolution catapulted them to back the mainstream, which brought with it a flood of applications that were born to be websites, forced into a text window. They ignore the natural advantages of the platform, and end up creating an at best equal (though usually worse) experience than the equivalent GUI.

The terminal is now a capable development platform; let's recapture what once made it great.

The lost ideal

Terminal User Interfaces (TUIs, for short) were most popular in the years where Command Line Interfaces (CLIs) were no longer adequate, but Graphical User Interfaces (GUIs) weren't feasible yet. TUIs should occupy this space in between, taking the efficiencies of the CLI, and wrapping them into something more interactive.

I've worked on TUI libraries for 7 years now. There have been a few remarkable attempts at making something of the platform, but none of it really propelled it anywhere - including my own thus far. The platform has evolved greatly

There is a world in which TUIs occupy a space nothing else can. The following are a set of guidelines to steer us into this new world.

The TUI Commandments

1. The program must do few things, but do them exceptionally.

The tiny footprint of TUIs - and the lack of hardware requirements - means unique pieces of software can be written to handle specific tasks. Specialized tools that do one thing well are always to be preferred over jacks of all trade that sacrifice utility and usability for more features.

2. The program must provide a deterministic interface.

The same sets of initial conditions and subsequent input should always result in the same layout appearing. Interfaces may be treated as two parts; the elements that make up the "Inputs", and the "Content" they control. Inputs shouldn't change positions unless necessary. In the case where an interface is loaded dynamically, the Inputs' position should remain consistent between state updates, and only the Content should appear to change.

3. The program must treat the singular keypress as the basic unit of interaction.

Programs in the terminal have the unique assumption that all users have access to a physical* keyboard at all times. A user must be able to access the entire program with only the keyboard. Every action must be considered keyboard-first, and any other forms of access (e.g. mouse input) should explicitly be secondary. Direct inputs (keybinds) always trump relative ones (arrows between menu options), and the latter's necessity should be minimized by design.

*: This assumption is partially broken by terminal emulators running on mobile devices. These usually provide the full on-screen keyboard unless dismissed, but modifier keys and specific placement often varies.

4. The program's ergonomics must be user configurable.

A great TUI should come with a remappable set of ergonomic defaults. It should be expected that some users will not have access to the intended keys due to keyboard layout differences or terminal-level remaps. Every key binding that could be user configured should be user configured, and this configuration should be done in a shareable, human readable & editable format. Visual style can also be configurable, but a cohesive default experience should always be preferred over the "great if you configure it well" approach.

5. The program must make use of command line arguments where possible.

The language of the terminal is spoken through CLI arguments. These should be used as possible to pre-select menus, set one-time configuration values or provide data through pipes. While full interface automation through static commands is often not feasible, programs with such capabilities are to be looked at as inspiration.

6. The program must launch and terminate immediately, with easy state resumption.

TUIs are usually not meant to be long-running processes. Users are expected to come in, complete their tasks and leave immediately afterwards. Startup speeds should be minimized, while "loading skeletons" are to be avoided at all costs. The key metric is time-to-task-completion, which describes the average amount of time it takes to go from the shell command prompt, complete one of the "Intended Tasks", and return back out of the program.

7. The program must avoid reimplementing terminal behaviour.

A program that users are expected to copy text out of should opt out of handling mouse drag inputs, so the native drag-to-select behaviour can take over - a program that primarily displays a single, long document should use the native scrollback instead of implementing its own virtualized scrolling, so it still scrolls correctly and performantly in multiplexers like TMUX - and so on. Always strive to work with the platform, rather than against it.

8. The program must use the TUI with purpose

TUIs are written with the same tooling CLIs are. Efficiency is king - if something can be expressed using a single-line CLI expression it will always be faster, thus a better choice, to interact with than a TUI wrapping the same functionality. Avoid TUIs for single-step processes and non-interactive getters, but feel free to use them when the context becomes more complicated. TUIs should ideally start out as CLIs, only adding new interactive interfaces as necessitated by complexity and interactivity.

The hopeful future

CEL is my first project born of these standards. As an example, the QuickStrike™ system implements points 2, 3 and 4 by deterministically assigning letters to each button on an interface. To "strike" (activate) a button, users can look at the widget, see its highlighted letter, and press ctrl-<bound_key>. These bindings are assigned the same way every time, so all pre-existing buttons will naturally keep their initial shortcut.

All apps made with CEL will follow the standards by default - and hopefully other TUI frameworks eventually follow suit.