A description of time travel as a feature in computer applications: motivations, precursors, barriers.
programming, technology
2021-08-23 – 2021-09-22 finished

The Problem

Most applications that a typical user interacts with on their computing device will give them the ability to Undo (and Redo) their actions. This is a feature that is commonplace and most people know how to use it. Most programs don't document the feature (why document the obvious?) but some do, such as the image editor GIMP, which states:

Almost anything you do to an image in GIMP can be undone. You can undo the most recent action by choosing Edit → Undo from the image menu, but this is done so frequently that you really should memorize the keyboard shortcut, Ctrl+Z.

But the documentation also warns of the limitations of Undo:

Caution
If you undo one or more actions and then operate on the image in any way except by using Undo or Redo, it will no longer be possible to redo those actions: they are lost forever. The solution to this, if it creates a problem for you, is to duplicate the image and then [edit] the copy.

This problem is not unique to image editors; it's probably present in all applications you've ever used. Unless you save every edit as a separate file or use version-control software and automate periodic commits, you'll eventually reach a situation where you've lost something by Undo-ing. But it doesn't have to be this way. This problem is not present in applications because of inevitability, or incompetence, but because of laziness and a lack of imagination. It could be solved. And the good news is that this problem's already been solved.

The Solution

One way to solve this is by implementing what I like to call Time Travel — the act of saving every previous state that's occured and adding two new actions: Go Backward which would be used to go backwards in time, restoring the application to any state it had previously been in. This would act just like Undo in many cases but wouldn't have the problem of unreachable states. You would then also have to add Go Forward which would be the inverse, like Redo is to Undo.

Time Travel wouldn't interfere with users who didn't use it. Undo and Redo would still act like normal, there would just exist an escape hatch for those situations where you can't reach previous states. Our problem would be solved.

Internally, the changes to the application would be to stop saving previous actions as a stack and instead use some kind of tree-structure. In the tree-structure, each node would be a state of the application and each edge an action. Undo and Redo would move you around on the tree just like normal while Time Travel would move you depending on the time each node was added. It would be a little complicated for things like image editors (which often put a limit on the number of saved states because of memory limitations) but implementing this in a text editor would be easy.

In fact, it's already been implemented in some of the best text editors the world has to offer: terminal-based text editors. Vim added the feature in 2006 and a plugin for Emacs was created in 2009. Interestingly, Emacs default behaviour solves the problem in a different way by making it possible to "Undo Undo". Unfortunately, with that solution Undo/Redo won't act like people are used to.

The Rest

So if the problem's already been solved, why hasn't Time Travel been implemented in other applications? Why hasn't for example VSCode (which is a competitor of Vim and Emacs, with millions of users) implemented it? Well, some people did open an issue about it called "[Feature Request] Undo branches" but I would say that people are focusing on the wrong thing. Take for example VSCode developer Steven Clarke who voiced his concerns in a comment:

I do believe that [Time Travel] could live alongside regular undo. However, we would need to spend time carefully designing the UX for [Time Travel]. For example, how should [the tree] be made visible (in a document/a viewlet/an overlay/a panel/something else)? How can we integrate them in a way that is consistent with other UI in the product? Additionally, we would need to spend time designing the UX for [Time Travel] so that the user is always very clear about the changes that will be made as they navigate the undo tree.
[...]
It's just that we do not have resources to do this work as we are focused on other tasks.

Designing a way to visualize the underlying data structure (the tree) may be useful sometimes but it is not a requirement for Time Travel. I believe there are two main reasons people feel the need to add a visualization of the tree

The Name. I've been calling the feature Time Travel to emphasize the important part, the ability to return to states that were lost. Meanwhile, other implementations call it either Undo Tree or Undo branches. Both make it seem like the underlying data structure is the important part or that you need to see the multiverse of all timelines, but what we actually care about is the ability to go back in time.
Previous implementations did it. The fact that both Vim and Emacs have the ability to visualize the tree may cause some to see it as a needed requirement. But they are both text-based editors so their visualizations aren't very interactive or informative. You don't need to see it to use Time Travel in either application.

Both of these reasons are pretty frivolous and should be ignored — they miss the forest for the tree. Using Time Travel is intuitive, you just go forwards or backwards, so there's no real need to see the tree. How often do you look at a list of your actions while using Undo?

It's obvious in my mind that Time Travel is a useful feature. There's no reason why a user should have to fear loss of progress, deletion of content or in any other way be afraid of using Undo. They should feel free to Edit/Undo/Redo however they want, whenever they want.