3 ms·

For some applications, it's not a big deal if only the latest action can be undone. This already beats warning dialogs, which is the point in the article. Nex

For some applications, it's not a big deal if only the latest action can be undone. This already beats warning dialogs, which is the point in the article. Next step (I'll call this B, below) is keeping a linear undo history, which you can navigate one step at a time, like most text editors today. This doesn't bring any of the complications you mention here. One way to get more sophisticated is exposing a linear undo history a la Photoshop, from which you can remove intermediate old steps. This seems to work for Photoshop, but in general it sounds like a can of worms, for the reasons you mention. Another path up from B is to keep an undo history tree, with the following properties: - You can display the tree explicitly somehow, and navigate it. So, e.g., selecting a node shows you the state of your content at that time. - You never delete nodes or branches. To undo a bad decision, you go back to the last good node and start a new branch from there. - You can still move data between nodes. For example, in a text editor I would be able to cut text in a discarded branch to incorporate it to my current one. Does this make sense to you? I don't understand the problems you mention with subversion, but aren't those implementation issues? Or do you mean that these are inherent limitations in the undo concept?

aston 19y ago
The implementation and user interface presentation of linear undo histories (even if you can only push and pop with no random access) are way more complicated than you're giving them credit for.
- euccastro 19y ago
  User interface for undo/redo is Ctrl+Z, Ctrl+Y on Windows systems (or equivalent menu entries or icons). What's complicated about that? Re: implementation, it of course depends on the application. The key difficulty is having an inverse (undo) for every mutating operation you have. This may get tricky to do efficiently for some applications (video editing comes to mind). An additional complication may come from, e.g., undoing every word rather than every keystroke. So you need some provision for gathering 'small' actions that you don't care for saving separately in history. The history itself is nothing more than a list. Now, I understand how it can be very hard to retrofit this functionality in an app that was made without this in mind. I'm redoing a hobby project from scratch because of this. Anyway, care to give details on the complications you've found? I'm not trying to convince anyone it's easy; I'm trying to help, and maybe gain a better understanding of the problems in the process.
  - aston 19y ago
    You've addressed most of the issues. One thing of note is that having to be able to undo everything is not really that easy for certain types of apps. Take submitting this reply form to the news.yc forum, for example.
    - euccastro 19y ago
      The 'delete' option is an undo. The 'edit' option is a less drastic way to correct your actions. Neither of them seems difficult to implement. The fact that they are only available for a short time is a design decision. If your point is that sometimes it doesn't make sense, design wise, to provide undo, then I agree.
      - aston 19y ago
        Though I think we've argued this enough, I'll at least reply to say that neither delete nor edit are actually undos. They allow me to repair, but they don't (necessarily) return me/the server to the previous state.
euccastro 19y ago
"in a text editor I would be able to cut text in a discarded branch" To copy text, even.

aston 19y ago

The implementation and user interface presentation of linear undo histories (even if you can only push and pop with no random access) are way more complicated than you're giving them credit for.

euccastro 19y ago
User interface for undo/redo is Ctrl+Z, Ctrl+Y on Windows systems (or equivalent menu entries or icons). What's complicated about that? Re: implementation, it of course depends on the application. The key difficulty is having an inverse (undo) for every mutating operation you have. This may get tricky to do efficiently for some applications (video editing comes to mind). An additional complication may come from, e.g., undoing every word rather than every keystroke. So you need some provision for gathering 'small' actions that you don't care for saving separately in history. The history itself is nothing more than a list. Now, I understand how it can be very hard to retrofit this functionality in an app that was made without this in mind. I'm redoing a hobby project from scratch because of this. Anyway, care to give details on the complications you've found? I'm not trying to convince anyone it's easy; I'm trying to help, and maybe gain a better understanding of the problems in the process.
- aston 19y ago
  You've addressed most of the issues. One thing of note is that having to be able to undo everything is not really that easy for certain types of apps. Take submitting this reply form to the news.yc forum, for example.
  - euccastro 19y ago
    The 'delete' option is an undo. The 'edit' option is a less drastic way to correct your actions. Neither of them seems difficult to implement. The fact that they are only available for a short time is a design decision. If your point is that sometimes it doesn't make sense, design wise, to provide undo, then I agree.
    - aston 19y ago
      Though I think we've argued this enough, I'll at least reply to say that neither delete nor edit are actually undos. They allow me to repair, but they don't (necessarily) return me/the server to the previous state.

euccastro 19y ago

"in a text editor I would be able to cut text in a discarded branch" To copy text, even.