Monospace and the Feeling of Order

My AI orchestrator started as a terminal client. I switched to a web UI to iterate faster and to escape a class of issues that kept coming up in the TUI: rendering quirks, layouts breaking on resize, every widget hand-built. The browser also offers a wider design space, with any font at any size, icons, thin borders, subtle color. So the TUI is on hold, and switching back stays an option once the design choices are stable.

Then came the observation this post is about: the web UI was no fun to read, and the terminal client had been, even though the content was nearly the same. Same log lines, same agent replies, same cost figures. But "no fun to read" is a symptom, and you cannot act on a symptom until you find its cause.

So we chased it down, in two steps, and the second one turned into a small theory about typography that I wanted to write up.

Step one: the boring diagnosis

The first pass found something unglamorous: the text that carries most of the information in that UI (log rows, card subtitles, cost figures) was set at 10 and 11 pixels in a standard proportional system font, across sixty style rules. The prose sizes were fine; the console chrome was what strained.

So the fix was ordinary: Fira Code for the console parts, every small size bumped one notch, line-height from 1.4 to 1.55. That helped, and it also exposed a second thing.

Step two: the theory

After the fix, the UI mixed two worlds: monospace for the console parts, a system sans for sentences. And the parts I kept enjoying were the monospace parts. My theory: a monospaced font imposes a character grid, columns of glyphs align vertically across lines, and that grid reads as order. Proportional text next to it looks slightly unkempt, even when it is objectively easier to read.

Familiarity stacks on top of that. I spend most of my day in a terminal, so the grid is also simply what working text looks like to me. We made the whole UI monospace to test the theory.

What the research says

The satisfying part is that the feeling has a mechanism, and the literature splits it cleanly into two questions.

On perceived order, the theory holds. Gestalt work on regularity and alignment says elements on a predictable grid are perceived as grouped and organized. The processing fluency line of research (Reber, Schwarz and Winkielman) shows that stimuli which are easy to process are experienced as more pleasing, and a character grid is about as predictable as visual structure gets. Grid layouts parse easily because the structure does the organizing before your brain has to. This is also just why code, logs, and tables have been set in monospace forever: alignment carries information.

On reading performance, the theory pays a small tax. Classic legibility studies find proportional fonts read roughly 5% faster for continuous prose at normal sizes, because more text fits into each eye fixation. Typographers add that monospace texture is, strictly speaking, less even: wide gaps around narrow letters like i and l. There is a genuinely interesting exception. A study on screen readability for people with dyslexia (Rello and Baeza-Yates) found monospaced fonts improved reading performance for dyslexic readers. The same regularity that feels orderly is functionally helpful for some people.

Why a console gets to ignore the 5%

The prose penalty applies to paragraphs. An orchestrator cockpit is fragments: log lines, step titles, cost columns, two-sentence agent replies. The longest continuous text on screen is a short chat bubble.

Meanwhile the alignment does real work. Timestamps stack under each other, cost figures line up because Fira Code's numerals are tabular, and step IDs form a column you can scan. In a proportional font all of that dissolves into ragged edges.

And there is the blunter argument: this is a tool I look at every day. The aesthetic-usability effect is well documented; interfaces that feel pleasant get used more willingly and judged more usable. For a daily instrument, "I want to look at it" beats a lab-measured 5% on text that is rarely longer than a sentence.

The takeaway

A feeling is a valid spec. "No fun to read" decomposed into a measurable problem (tiny type) and a preference with an actual mechanism behind it (grids process fluently, and fluency feels good). The tiny type got fixed outright; the grid preference is now running as an experiment.

And it is a preference, not a general rule. I am the primary user of this tool, I spend my day in terminals, and the grid reads as familiar to me. For another app or another audience, a proportional font takes less horizontal space and looks less like a developer tool, and it might well be the right call there. The luxury of building your own instruments is that "the primary user likes it" counts as a complete argument.

The experiment also ended up making the case for the web UI. Trying a new font across the whole interface was one prompt and a page reload. Cheap experiments were the reason to build in the browser.

Written by Martin Sigloch with Tachikoma.