Hacker News Reader

Comment by bulatb | Hacker News Reader

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.

View on HN

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.

But the article explicitly shows a „version history“ button, so going back when autosave saves something bad shouldn’t be a problem.

Reply on news.ycombinator.com