I · Meaning
The Physics
What the old screens knew about moving
There's one more thing the old screens had, and it isn't visual at all. They had physics: how you moved, and how you got things done.
The journeys were recipes. They were written on a sheet taped to the monitor, or they lived in someone's hands. At the library desk, F3 opened the book search and F2 opened lending, on every screen, every day. In a terminal editor, everyone who used it knew how to save and how to get out, because the bottom of the screen said so, the same way, all the time. On a lighting console, storing a cue was a sentence your fingers learned: F1 for the menu, F2 to record to disk, type the number, F10 to store. Nobody looked for it. They did it.
The menus were built under the same limit as everything else. There was one row at the bottom of the screen, and twelve function keys, so a screen could offer at most twelve things, each one sitting over the key that did it. The row changed with the screen, so the options were always the ones that made sense here, but the row itself never moved. The shell was consistent. You always knew where the menu was, even when you didn't know what was in it.
And it did one more thing, quietly. The row told you where you were. If it offered to add a contact, find one, or delete one, you were in the list. Open a record and the row changed: edit this one, print it, go back. You didn't need to look up at the title to know what kind of screen you were on. The row at the bottom had already said it: not only what you could do here, but what here was.
That's what made the recipes possible. A sequence of keys can only be remembered if the ground under it doesn't shift. Today the menu is a hamburger here, a row of icons there, a button that appears on hover somewhere else, and every journey has to be found again by looking. Some of that is a fair price for screens that do far more. But the old screens show what a journey is when the shell holds still: something the person stops thinking about, because their hands already know it.
Why was I fast?
The first lighting console I learned was a Spark 4D, and it ran on DOS. I learned its sequences until I stopped thinking about them, and I got fast. Not the fastest cue programmer there ever was, but fast. Fast enough to fix a cue in the middle of a running show, in the seconds before the next go.
Why could I be? Not talent. The console made it possible, in a few ways that are easy to miss because none of them is visible.
The screen never moved. Every key did the same thing, in the same place, every time, so my hands could learn it the way they learn a word you type a thousand times. There was nothing to aim at. A key is found by feel; a target on a screen has to be found by eye first and then hit, and Fitts (1954) measured what that costs, every single time. The sequence was a sentence: what to do, to what, which number, done. And I could type the whole sentence ahead of the screen. The machine caught up; I didn't wait for it. Ah, the days before the internet made us wait.
What did the mouse give, and what did it take?
Then the same kind of work moved to screens you point at, and it got slower, and harder to get good at.
That isn't because the new screens were worse. They made a different trade. A screen you can point at shows you everything you can do: menus you can open, buttons you can see, things that light up when you come near them. The first day is far easier. Nobody needs the sheet taped to the monitor. Shneiderman's direct manipulation, the object right there and acted on, is a real gift, and plenty of people who would never have memorized a recipe can do real work because of it.
But the hundredth day isn't much faster than the first. A keyboard system starts steep and keeps getting faster for years; a pointing system starts gentle and flattens early. Cockburn and colleagues (2014) call this the problem of the novice-to-expert transition: interfaces that are easy to start with often give the person no path to becoming fast, so they stay a beginner who happens to be experienced.
And the screen that can change shape, color and layout, that reacts to you, that animates, took something else. It took the ground. When the layout reflows, the menu moves, a button only appears on hover, and a panel slides in at its own pace, position stops meaning anything for long. The hands can't learn a place that isn't there tomorrow. Every visit becomes a little bit of a first visit.
Why did the web forget?
My guess, and it's only a guess, is that the web started as pages to read, not tools to operate. A page you read once doesn't need physics. It needs to be clear the first time, and the first time is what most of the web is still measured by: the visit, the signup, the conversion. The person who uses a tool eight hours a day is rarely in the room when it's designed, and nothing on a first-visit chart shows what they lose.
There's a reason closer to home, too, and it's ours. Open most design systems and you'll find the colors, the type, the spacing, the components, every state of a button drawn out. You'll rarely find the physics: which keys do what, where focus goes when a dialog closes, the order the cursor moves through a screen, how a journey can be done without the mouse at all. Keyboard shortcuts, when a product has them, are usually a developer's idea, added late, because nobody designed them. Designers own what can be seen. The physics can't be seen, so it falls to whoever happens to build that screen, and it gets decided one screen at a time, or not at all. The one thing that dragged some of it back into the room is accessibility. The guidelines ask that everything can be done from a keyboard, that focus is always visible, and that it moves through a screen in an order that makes sense (W3C, 2023): the old screens' physics, written down again as a requirement. It took a compliance checklist to make us think about how a screen is moved through, and even now it tends to arrive late, as a checklist, not as design. A design system is a promise about how a product behaves, not only how it looks, and the behaving is the part we keep leaving out.
It isn't completely forgotten. Professional tools kept their shortcuts. The command palette, a box you type into to do anything, is the function-key row coming back in a modern shape. But mostly, the physics is what we left behind when we gained the mouse, and we didn't notice, because what we gained was so visible and what we lost wasn't visible at all.
What I take from it
The same thing I take from print: not the medium, the discipline.
What I try for now is a shell that holds still: one place for the menu, and it stays there. A position that means something, and still means it next week. Journeys that can be learned as sequences, the same keys in the same order, landing in the same place. No animation the person has to wait out before their next step registers. And one journey for the mouse and the keyboard, so the person who finds a command by pointing at it sees the keys beside it, and can be fast the next time, if they want to be.
Design for the first visit, of course. But also for the hundredth, the one where the person isn't looking anymore, because they don't need to.
Where this bends
The older systems were built for people who used them all day and could be trained to. A screen a stranger meets once, a signup, a shop, a form from the government, has a different person on the other end, and the keys-and-recipes physics that makes an expert fast can leave a newcomer lost. What the old screens teach is underneath the physics: what comes first, what belongs with what, where the person is. That part travels anywhere.