Undo is the king of interface idioms

Undo is is the king of interface idioms.

Undo is so important that they built a hard button for it into the Apple Newton. It enables strong actions with a single gesture throughout the interface. It makes users more willing to explore and experiment. It enables users to get into flow because they can act with confidence. Jonathan Baker-Bates wisely reminds us:

Remember that the worst problem that can ever affect somebody using a computer is lost work. No other usability issue comes close. Design to prevent or at least minimise that, or face the rage that will ensue when it happens.

Simon Pitt has a beautiful ode to the magic of Undo.

In many ways, I regard the undo button as the computer’s most creative feature. It is a digital do-over, an ever-present safety blanket, reducing the cost of failure. We are free to experiment and play, knowing that a single keypress can restore the current state. Our fear of losing our precious work is lessened, if not appeased entirely. There is no need to freeze or choke at a pivotal moment. Our hand doesn’t need to shake or sweat as we make a key mark. Less hampered by the luck of individual actions, we can try each step over and over until we get it right. I sometimes wonder at the years of healthy life undo may have saved by lessening our collective stress.

It is not a v2.0 feature, or even a v1.1 feature. Build it in from the beginning.

John Gruber of Daring Fireball calls Undo support the key sniff test for whether an application is good.

There’s nothing cosmetic about Undo support. It’s a red flag. You open a container of food and it smells foul, you throw it out. You try a new app and it doesn’t support Undo, you throw it out. And you empty the trash immediately in both cases. Get it out of the house.

Fake Undo is the queen of interface idioms. Too many defenses of counterproductive confirmation dialogs come down to an inability to see that even Fake Undo is worth building. If you cannot “really” undo a delete, you can cache the entity and re-create it, which achieves what your user wants ...

But you should build strong real Undo.The event model that supports Undo is going to have so many useful applications. Retrofitting it later will be brutal or impossible. Build it from Day One.

Dorian Taylor reflects on ideal version control and imagines a glorious re-framing of all software architecture and user experience lurking in the promise of Undo.

What would a future look like, in which everything had an undo button that went back arbitrarily far? In which the act of creating new digital content did not mean destroying what was there before? Something like Google Docs offers us a glimpse. Changes are transmitted over HTTP requests, as messages that only express the content of each individual change itself. On the server side, what would otherwise be encapsulated as a file — in Rich Hickey parlance, a mutable and therefore volatile place for data — could instead be represented non-destructively, as a time-stamped log of accumulating changes, which could be projected into a snapshot at any stage along the way.

To bring about that future, we would likely have to move away from files — at least as anything other than bulk payloads of instantaneous freeze-frames of the state of a system. It would, ironically, mean going back to a client-server model. But who controls the servers? Well, you could, I mean, it’s not that outlandish a proposition.

---

Capturing a Twitter thread I started in 2015