I was in the middle of writing a long text in one online web application (made in Silverlight) when my FireFox crashed (Firefox is doing a great job in restoring your work, but in case of silverlight or desktop apps, you just can’t count on your browser). I lost the most of what I wrote just because the Silverlight application didn’t have one simple function – autosave. This functionality periodically saves user’s work and thus prevents data loss, or at least minimizes it – in case of software crash, only changes that are made after the last save will be lost. Although it seems as if it is quite simple function, there are some issues that need to be considered.
Software crash doesn’t have to be the only reason for data loss. Sometimes the internet connection breaks or user simply presses the wrong button – she closes Firefox window instead of one tab. This means that autosave should happen often enough to minimize the effect of unpredictable events. Alan Cooper suggests that, if possible, autosave should be performed after each keystroke or, in other case, when user stops interacting with the interface. When choosing autosave frequency one should always consider application performance and responsiveness, though.
Enable autosave by default
If an application implements autosave, it should be enabled by default. If autosave isn’t enabled, chances are that beginners and perpetual intermediaries will never discover it. I believe I fall into intermediaries when it comes to Inkscape and I didn’t even know it has autosave. But it has autosave functionality which is disabled by default. And since it crashes quite often, it happens that I lose hours of work. Although I am trigger-happy when it comes to saving, I tend to be carried away with design work and simply forget to save.
Besides this, autosave should be unobtrusive, which means that it should be performed in background without interrupting user’s work. Here’s an example of how things can go wrong for users when autosave isn’t unobtrusive. I was typing an extremely important email in my webmail client when suddenly a green message box appeared – the same message box which appears after email is successfully sent. I instantly started to look for cancel/discard action and pressed it once I found it. Only seconds after I realized that was an autosave message. But the draft was deleted and I was quite frustrated.
Among many others, Google Docs is another example of obtrusiveness – after each autosave the cursor moves to the top of the text. I am sure this is a bug that will be solved but currently it is obviously more than annoying. Besides this bug, Google docs is a good example of how autosave should be done.
When document isn’t saved there is information about the last save and enabled Save button next to it. After autosave the message changes and Save button become disabled. Also, autosave is being performed after each keystroke which eliminates the need for “Do you want to save changes?” popups.
However, autosave raises one important question – with each save, all previous versions of the same document become unavailable (undo can sometimes be helpful but not enough). Autosave overwrites the same document over and over again. For instance, user might want to edit some template and just print it without saving it at any moment, but autosave might overwrite the template. Some applications use versioning to fix this issue (by adding timestamp to a file name for example). Some, on the other hand, keeps the history of actions where each action refers to one of the previous document versions. But those solutions tends to be complicated and seems as if there’s no definite solution to this problem.
In any case, if you are not sure about autosave functionality, don’t think anymore and implement it – and keep the common save functionality and unavoidable keyboard support.
* * *
Remember RSS? You can subscribe to my blog here.