> The thing is, you can only offer this feature if your app's architecture is designed from the ground up to support it.
Perhaps I'm misunderstanding something, but this makes 0 sense to me. The Save button itself must be able to save the current state. So at the very, very least you should be able to just check on a schedule what the current state is and determine if it differs from the previously saved state.
There are much better ways to implement this that take more underlying work, but agree with the other comments, this has nothing to do with people not understanding files, it has to do with people expecting web editors to autosave.
Autosaving means you often save a state the user didn't want to save, sometimes one they wanted not to save, erasing one they probably wanted to keep as a savepoint.
You can give them back the point-in-time or known-state recovery with manual snapshots or history tracking, but now your data system has to support that.
Lots of apps implement this by autosaving to a different location from the manual save. So autosaves overwrite each other, but they don't overwrite the user's explicit choice. On loading a save, if they detect the autosave is more recent than the manual save, they offer the user the choice of which one to use.
Microsoft Word has had this since the 90s (with slightly different presentation from today, and definitely without sophisticated history tracking). Their computers used to fail (blue screen) much more regularly. It's not about web apps vs desktop.
Exactly. The original problem was "people are losing all of their work cause they're not saving." So you autosave every minute or so to a separate "recovery" location, then if the user exits without manually saving, on next startup you give them the option to continue from the last autosave if that autosave is more recent and not identical to the last manual save. Doesn't require full change logging, and only requires one "last autosave" at any given time. IIRC this is how your Word example from the 90s worked.
I think you are exaggerating the importance of undo/redo. Even in google docs, if you restore from a savepoint you can only go backwards. And besides, the complaints OP got were "I'm losing all my work" - I doubt someone who had some recovery point would be in a worse position to recover than someone who had no recovery point at all.
(in other words, it's not necessary at all to support this feature from the ground up - it just might be necessary in order to have a third, even better way than "no saves" and "imperfect saves")
Well, going forward is undefined (i.e., redo history loss), unless you implement "linearized" history [1], which anecdotally is very confusing for most people.
Perhaps I'm misunderstanding something, but this makes 0 sense to me. The Save button itself must be able to save the current state. So at the very, very least you should be able to just check on a schedule what the current state is and determine if it differs from the previously saved state.
There are much better ways to implement this that take more underlying work, but agree with the other comments, this has nothing to do with people not understanding files, it has to do with people expecting web editors to autosave.