Save Button Usability Issues
The other day I noted that the Restart button in Windows probably appeared because of buggy software.
It was a frequent task that people used often, hence there was a value in combining the two steps (shut down, then start) into one Restart action.
This is a lot like the “save” button, where I heard the argument that it’s invented by engineers to move data memory to disk back in the days where tape and disk space was incredibly expensive (and time consuming): Many computers didn’t even have disk or tape. There was an extra need to actively decide to get that delay it took to save stuff. Nowadays, some smart web applications offer automatic save (for example GMail and Writely).
The next step will be invisible save, and we’ll probably end up with no save button as implemented by Palm Pilot.
(if only I could remember who said it… I’m very uncertain here, but I think I might have heard it from Tog back in 2000 on a web usability seminar in Amsterdam. Any comments to help me refresh my memory will be greatly appreciated)
Screenshots from GMail and Google Documents (former known as Writely)
Technorati Tags: usability, gmail, writely, save, save button, tog
November 28th, 2006 at 00:05 (GMT-1)
IntelliJ IDEA [1] “auto-saves” files for years now, and it’s a shame (and characteristic for our industry …) that it has not been broadly adopted yet. Really a shame. (And this auto-save is definitely one of the reasons why most people just love IDEA. Manually saving files is absolutely unnecessary, it’s an application task; it must protect our work.)
[1] http://www.jetbrains.com/idea/
November 28th, 2006 at 10:47 (GMT-1)
A complete lack of “Save” button raises some fundamental questions:
* File naming. At present time we still have a file system visible to the end user (hello to a good old Palm) and there’s a need for meaningful file names unless we completely deal with metadata which is another thing… Possible solution: save file once and then auto-save to it.
* Having a need for draft/document division. I.e. if I just type few words to keep for a couple of minutes I won’t necessarily need them in the future. Without “save” we may end up dividing text processors to “notepads” and “more serious” solutions.
* Undos. I.e. the “endless editing” paradigm may need to envolve having a big enough (ideally – endless) number of undos even if you have saved the doc. I.e. you may open the document and undo the previous action.
I’d say there’re much more questions on this topic but the direction towards “no need to hit Save unless it’s really needful” is visibleindeed.
November 28th, 2006 at 11:25 (GMT-1)
Every time I start a new project I always try to press this issue. Developers that whip up a fast interface just to see things happen always place that pesky save button there. Mostly it’s not needed when you dig deeper.
As for Taras comment on filename. You wouldn’t want to start the application, you start by creating your document. Naming will come natural that way. But i agree and have came across the problem regarding draft/document version.
November 28th, 2006 at 11:34 (GMT-1)
Greets, Håkan.
Unfortunately many people prefer Program>Document, not Document>Program approach of launching applications.
And yes, it’s easy to find applications where a lack of “Save” is painless but in some cases getting completely rid of it requires changing a mechanism of document management.
Possible solution for a draft: a kind of Accept/decline changes question on initial saving although this is not the best possible idea too…
January 4th, 2007 at 11:13 (GMT-1)
I think a “Save” button is in place just to comfort the user. Sometimes you need to press a save button to get a confirmation that you have actually saved. With GMail, there’s both autosave and a save button. The save button is merely to let me know it’s really saved. I do not think users are ready for a non save button world.
August 30th, 2007 at 02:25 (GMT-1)
Where oh where is the save button, anyway? -B.O’L.
July 3rd, 2008 at 07:24 (GMT-1)
I agree with Martin that the Save button is a comfort to the user, it would be a hard sell to take it out at most of my client sites. For networked applications you also need to consider network performance, do you really want to send data to the database every time the user enters a field? In some systems you also need to consider the “logical unit of work”. A user may want an all or nothing result when saving certain types of data like that found in a master detail relationship, or the implicit save in a Pay Now button. Having said all that, there certainly are some applications where auto save makes alot of sense as some of the ones mentioned above. Still, considering all the different kinds of applications out there I don’t see the Save button disappearing completely.
November 5th, 2009 at 17:22 (GMT-1)
Jef Raskin, in The Humane Interface, argued strongly against save buttons. There’s an interesting discussion of his approach at http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=005Leg