How to handle undo when the change is not on screen

Question

In user interfaces with any kind of toggleable or overlapping views, what is a good way to handle undo when the effect of undoing is not visible?

For instance, in OS X Finder, if a user renames a file or folder, then close the window, they can still press cmd+Z to undo, without any feedback that the filename was reverted. This is possible even days after the item was renamed, if no other action was performed in between. This behaviour seems very error prone.

What strategies exist to show the user the effect of undo in such cases?

Answer 1

Ideally, a user should be either aware of what will be undone, or reminded of what will be undone.

If the user has changed the context of their work (i.e. scrolled out of view or changed views) or a significant amount of time has passed, they might no longer remember what the last action was.

At the same time, it could be frustrating to be reminded unnecessarily.

It is not standard, but a better UX would be to attempt to make a reasonable estimate of whether the user requires reminding of the last action before undoing.

At the least, however, if reminding is impractical, the reverted area (such as text) could be scrolled back into view.

Answer 2

Another option to consider is to forbid the undo operation once the user closes / dismisses the affected window. Closing the window is quite a strong signal of "I'm done here, all good" from the user.

I remember being struck by this once. After manually sorting a bunch of files in the project folder I closed it and then accidentally hit CTRL+Z in another explorer window, and by the time I realized which action I reverted I already performed another change, so Redo was not possible. I really hate this system-wide undo feature since that day.