I am planning adding an undo/recover mechanism to an existing application, and I am looking for ideas hwo to present it to the user under pretty ugly restrictions. I've found a few particular hints, this post standing out, but nothing that gives me ideas hwo to approach this.
The application is basically a hierarchy of nodes, each with some insignificant metadata (name, comment, ...) and large data objects that are opaque to the undo/redo mechanism.
Typical operations are
- create / copy / move / delete nodes
- edit metadata
- change / replace node data (some times a few dozen times in a row)
Problems:
- Existing application with no undo; it does already autosave and thus provides pretty heavy blocking dialogs for destructive actions
- You can - and are encouraged to - generate tangible amounts of data (a typical spike would be ~1MB/s for 30 seconds)
- Even though it was never "officially recommended", users are used to concurrent access to the database (no server, via file sharing). Currently, it's "last one wins" and weird errors (and lost data) when someone else deletes the node you are working on.
We are in the process of migrating to a different data store (already decided to be SQLite), I want to get at least "a plan" for undo and understand the necessary changes to data structure.
My thoughts: Due to some nodes being highly volatile, others being "virtually sacred", I don't feel global Ctrl+Z/Ctrl+Y will work well for this. E.g. one small change blocks redoing all your undo's, making an accidental undo possibly fatal.
I am unsure about how to present to user, how to limit the amount of data in a way the user understands, where to store it, etc.
Related ideas are a "trash bin" metaphor for the large data, and/or allowing to mark items read-only, preventing modification.
Ideas? Recommendations? War stories? A link to the canonical "12 different ways how to implement undo, and how to pick yours" that I happen to not find?