Many web applications adopt the 'autosave' design pattern for a number of different reasons. One of them is so that changes are not lost when users have completed a number of tasks or actions and forgets to save, another is when the connection is not stable and sometimes the application runs in offline mode so it keeps the states of the application consistent.

I am wondering how these types of applications allow for the user to undo actions, because the triggers for autosaving may not correspond to the logical chunks of actions that the user has performed, and it may not be obvious to the user what the actions are that they want to undo.

  • You have an example of sort of features that auto save? Because so far many things in my mind that auto save are reversible. – Majo0od Sep 29 '16 at 12:55
  • @Majo0od the first example I can think of in my head is Google Docs, but Microsoft OneNote also has an autosave feature and so it doesn't have a 'save' button. Both are for saving updates to documents as part of word processing functionality. – Michael Lai Sep 29 '16 at 13:18
  • True, but you also have to know that you can undo the work you do then and there. Usually in documents you don't wait days to undo work you do. You usually undo it when a mistake or problem arises. – Majo0od Sep 29 '16 at 13:22

I get the impression that you think auto-save saves a complete snapshot of the document. If this were true, then it is indeed hard to see how undo will work.

Here's what really happens: each time the user performs an action, that action is saved locally (on the person's machine). You referred to this as a logical chunk. When the auto-save kicks in, all of these logical chunks are saved in the cloud. Each logical chunk is reversible, allowing you to undo the action from the cloud.

  • I'm not totally agreeing. it also has to do with implementation. You could do local storage but also implement with Ajax-calls; when an event has been triggered (and after timespan X) an Ajax-call will be fired towards a web server. – myradon Sep 29 '16 at 11:25

Autosave is popular for Web apps because for various reasons, but one important one is the unreliability of the client-server interface. HTTP request responses may time out, websockets may disconnect, or the user may simply hit a button and navigate off the page or close the browser by accident.

Engineering for autosave is non trivial. Often, enterprise apps need to maintain an undo stack anyway (for usability) so that is one way to do autosave without adding to much additional code.

Another different but complementary way of doing it is to save document or application state in snapshots and store the differences. This provides a stack of previous states without consuming a lot of data.

Frankly this is more of an implementation question than a UX question, but since autosave is a popular and current UX trend, I found the question interesting


You could Undo by storing previous changes. So you should keep track of the history. When you have a multi-user Web-app this could potentially become a nightmare. Because you could have a cascade of user actions among different users. So data-integrity is at stake. Maybe some altered your change. Then what? You have to keep in mind how system will be used.


I'm not very familiar with web application development, but I can tell you that most desktop applications use the command design pattern.

This actually means that every user action is saved in such a way that it can be executed and reverted at any time. Applying these actions in a sequence gives you the state of the application.

I would assume web applications do the same thing, with part of the actions queue being persisted at fixed intervals.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.