Tips and Guidelines Why Your Application should not have a Save Button

by Matthew Ford (updated 24^th May 2014)
© Forward Computing and Control Pty. Ltd. NSW Australia
All rights reserved.

Introduction:

The place holder for this page was created about 10 years ago, but never fleshed out until now. However I recently saw an article about how GoogleDocs does NOT have a Save Button. This page notes “Since Google Docs, Sheets, and Slides continuously save your work, there's no Save button. The last updated time shows near the menu bar.” It has take a while, but at last applications are becoming actually user friendly.

Microsoft Office (and other wordprocessors) had previously introduced Auto recover options which periodically save you work for you. However Microsoft still prompts you to save when you exit and so does not satisfy the “No Save Button” criteria.

There are other partial applications of this design criteria:-

When you download files with your browser, the browser automatically renames the files (without prompting you) so that you don't loose any previously downloaded file of the same name. However it is the latest download that is renamed. It should be the previous download loads that were renamed.

When you delete a file it is move to the Recycle/Trash bin so you can recover it later. However in Windows you are still prompted (unnecessary) to confirm the delete. This should be replace with status bar message telling you the file is not in the Recycle bin and with an Undo button so you can easily get it back immediately. Mac OS X does a much better job and does not annoy the user asking for an unnecessary confirmation but just moves the file to Trash as you asked.

Why No Save Button?

The simple answer is the the user has put effort into editing the work so the application should by default save the changes. “He asked the application to make the changes. Don't annoy him by asking for a second confirmation,”

What about Unintentional Changes?

The general rule here is that “The user never makes mistakes (even when they do). They just change their mind.”

Your application cannot tell if this is an unintentional change or not. Since the user took the effort to type the changes then “most likely” they meant to make the change. HOWEVER a user friendly application should always allow for the user “changing their mind” That is there should always be a way to undo changes and recover to a previous version.

The page on “What's Wrong with Undo/Redo and How to fix it.” describes an undo/redo system that keeps ALL the changes and allows the user to backtrack any previous edit. This solves the in-application recovery to a previous version.

With “auto-save”, either periodically or on exit, where the user is not prompted to save, there needs to be a way for the user to recover earlier versions. GoogleDocs seems to provide the means. In general it is as easy as renaming the previous file and then saving the latest version. More advanced implementations would just save the deltas between the files.

A full implementation would also save the undo/redo data with each version so the user could recover to a previous edit exactly.

Conclusion:

When the availability of large amounts of disk space and faster processor speeds there is no longer any reason for not saving ALL the user's changes and providing a means of letting the user recovery to a any previous state.

Contact Forward Computing and Control by
©Copyright 1996-2020 Forward Computing and Control Pty. Ltd. ACN 003 669 994