Undo
TLDR: Utopian computers have undo at the OS level, as well as having a separate system of versioning within apps/documents.
Prerequisites: None
Note: In this essay I’ll be indicating keyboard shortcuts with {key}+{key} or {key}+{key}+{key}. I’ll be using an uppercase C to indicate the command key on mac keyboards or the ctrl key on windows/linux keyboards, ⇧ for the shift key, and lowercase letters for the letter keys.
Computers are discrete state machines. At a given time they can be thought of as having some specific set of binary digits in memory and on disk. An extremely common operation when using computers is the “undo” command, which rolls back the state of some program to an earlier one, essentially reversing some action or set of actions.
Everyone with experience creating images or other art on a computer, or simply done serious text editing knows the importance of undo. Mistakes happen, and undo is an important lifeline to avoid disasters.
But undo isn’t perfect. There are three major ways in which I think we’ve found ourselves in a world with a sub-par undo strategy.
Problem 1: Inconsistent Interface
Once upon a time there wasn’t a standard command for undo. The feature was a fancy addition to early text-processors and the like, and it took a while to catch on and become commonplace. Nowadays nearly every program on a laptop/desktop computer uses they keyboard shortcut C+z to undo, with an alternate method by clicking on the “Edit” menu. Only oldschool/hardcore text editors like Emacs (C+/) and Vim (:u) have stuck to their original conventions.
But what about redo? Performing an undo command is exactly the sort of thing a user might want to revert, so a redo command is an important part of allowing users to reverse their actions. Once upon a time the story was that if one did an undo and then another undo, the second undo would undo the first undo. Or in other words, the command for redo was just a second undo. This, however, sucked, because it prevented people from doing multiple undo commands in a row.
Nowadays most software with an undo command has the ability to roll-back multiple things, with a separate a redo command to roll-forward again. But what’s the keyboard shortcut for redo? On half the programs it seems to be C+y, while on the other half it’s C+⇧+z. Apple tries to keep things consistent by telling developers to use the second one, but in a world where most of the applications are running on the web, it’s anyone’s guess as to what keys need to be pressed.
And the whole keyboard-based convention goes out the window when it comes to devices with touchscreens. Sometimes there’s an undo button, while other times there’s a swipe gesture, while other times one can shake the device. But very awkwardly there’s no consistent command across apps, and most of the consistency comes when the user is putting in text using a third-party keyboard app. (Hmmm… I wonder if there are any principles to be learned, there.)
Problem 2: Linearity
Imagine that you’re using an unfamiliar text editor for the first time. You type a paragraph, then decide it’s no good, and delete it. You go on to write more, then realize that there was something in that deleted paragraph that would be good to have in your document. So you undo for a while, going back in time until the deleted paragraph re-emerges. You copy the relevant piece of text to your clipboard and hit C+⇧+z to go back to your most recent document version. Unfortunately, the text editor uses C+y to redo, and worse, your C+⇧+z command is interpreted as just wanting to type the letter “z”. So now you have a “z” in your document, and… your entire redo path has been erased, because you’ve changed the document. All that work is down the drain, thanks to shooting yourself in the foot with undo.
I’ve done this multiple times, and it feels really bad. It’s so bad that I now have a kind of skin-crawling feeling when I go too far back in an undo history and don’t have the changes that I’m undoing saved. When any change to the document erases a redo-“history” then undo/redo becomes a subtle way to delete information by accident, which is kinda the whole problem that undo/redo set out to solve!
Problem 3: Unclear Effects
This problem could alternately be called “lack of principles,” or simply “what exactly does an undo command do?” If I type a word, will hitting undo get rid of the word, the last letter, or a whole bunch of text that includes that word? If it’s not obvious to you, I suggest you open up a text-editor and try it.
Most text editors will actually get rid of a whole bunch of text with each undo action. This is pretty sensible, in that it would be annoying to undo each letter, one-by-one. But try doing an undo while typing in the search field on Google or Amazon and you’ll find that it undoes each letter separately. Try it on another webpage field and you may get another behavior entirely.
It’s kinda awful how random it is. Like, there’s an arbitrary piece of software in the application that’s tracking changes and making unprincipled decisions about where to put the undo checkpoints. And it’s not like there’s even a single piece of software that’s at least consistent with itself — each piece of software is making different decisions, even in the realm of text!
What do you do if you you copy something to clipboard, then realize you don’t want that thing in the clipboard. Can you undo that? Nope! You just have to copy over it, because undo doesn’t apply to the clipboard. Why doesn’t it apply? Perhaps because undo only applies at the level of applications, not the operating system, and copy/paste is an operating system command. But this is really arbitrary and I doubt most computer users could tell you why. Perhaps a better reason is that if copying to clipboard counted as a change that could be undone, then a lot of the value of undo would be lost because then one couldn’t undo+copy+redo.
What if you move a file on your computer (perhaps to the trash)? Can you undo that with C+z? Probably! It depends on how you moved the file. Clearly not all OS actions are forbidden to be undone.
What happens if you click a link on a webpage and then hit undo? Do you go back? Nope! Why not? ¯\_(ツ)_/¯
What if you’re collaborating on a document on Google docs with a friend. If your friend types some text and you hit undo, what happens? What happens if you write some text, your friend makes it and some of the surrounding text bold, then you hit undo? Does the surrounding text stay bold? What if you have a web-document open on multiple machines, but the same account? Does the behavior change, compared to the multi-user version?
What principle is behind the behavior of software, such that if we knew the principle we could predict what it’ll do when we hit undo? I claim there is no principle. It’s just random.
Utopian Undo
I think in Utopia these problems are solved. I claim Utopia has battle-tested various principles and decided on a consistent story for how undo works, such that it has a consistent interface that never serves as an accidental source of misery. I haven’t done the testing required to be sure I’ve found the Utopian solution, but here’s my best guess…
Utopian software takes input through standard channels, but (with rare exception) not from specific devices. For instance, Utopian software doesn’t take keyboard keys and mouse movements — but it might take a symbol channel and a planar-motion channel. An easy way to input symbols might be through a keyboard, and planar-motion might be easy to provide with a mouse or trackpad, but these things could alternately be provided with a game controller. Users then configure their computer to link up devices to provide the inputs they want on the channels that the software expects.
In addition to immensely helping with accessibility, this allows for a cleaner story about what commands are being sent where. A person listening to music while playing a game might put in a keyboard command, but since keyboard commands only get routed to application software once they’re “complete” in a sense (according to the user’s preferences), there’s never a time when that command gets accidentally sent to both the music app and the game.
There are also “reverse commands” in Utopia, that are kinda like providing negative-input. For example, a Utopian might type out a sentence and send that whole sentence to some app as a single text-command. Then the Utopian might hit “undo” which sends that sentence as a reverse command. Good software handles reverse commands elegantly, inverting the relevant action. If the user clicks a hyperlink, reverse-clicking the link will take the user back to the page they were just on. If the user scrolls down, the reverse-scroll will take them back up. If the user moves a file, the reverse-move will bring it back.
For added clarity, the default behavior when a user puts in a reverse command is to bring up a timeline of commands, so the user can see what they’ve been doing and what hitting undo again will send to their current application. Reversing moves back in the timeline, of course, but doing a forward command won’t erase the alternate-future command timeline. Instead, after a reverse, a different forward command will produce a branch in the undo history, which can be seen by the user when they’re viewing the command tree. Special commands (i.e. keyboard shortcuts) will allow pivoting between paths in the undo history tree.
Of course, reverse-commands don’t always work. For instance, when typing text into a collaborative document online it might not be possible to undo typing that text, as someone else may have changed the text in the meantime. The principle of a reverse-command is that it should attempt to take the program state back if possible, but there’s a recognition that this sometimes doesn’t make sense.
Still, Utopian software often supports versioning, which is a second, entirely different form of undo. A document is versioned if there is a stored record of the document’s state that is distinct from the actions taken by the user at the OS-level. Text documents, images, and anything else the user might want to edit will almost always have versioning supported. Apps that edit these documents will have commands that roll-back the version, and thus the reverse-command of version-rollback is version-rollforward (a.k.a. redo). Like the command-history, version histories are trees that don’t run the risk of accidental erasure. An editor of an online document can rollback the document to an earlier version, which is akin to performing an undo command on other user’s actions.
Oh, and thanks to clever techniques of storing versions and commands in real-time, if a computer ever spontaneously runs out of power or otherwise crashes (which is rarer in Utopia), then both undo-histories are safe.
As a result of these distinct principles, Utopian computer users are empowered to do more and have a more consistent experience, regardless of whether they’re using a keyboard or not.
