Why is the save button needed?

Question

Software like OneNote has shown that auto-save can be implemented, and it works just as well (or better) as the manual save button / CTRL+S.

Anyways everything that you work on you want saved. Its just if you're trying out something destructive that you would close without saving.

So from a programmers/usability perspective, why is the manual "save" feature still seen in virtually all software today? Is it because everyone is too lazy to implement "auto-save" whenever data gets modified?

And is it a good idea for us implement auto-save, at least to start some traction in our specific industry and amongst our competitors?

Jugal

When I think about how many times I accidentally type characters into the wrong window because I incorrectly assumed the window I was looking at had focus, I realise an autosave without some way of reverting is not good. And not even that, sometimes I open files and know that I haven't made any changes (for example a reference document) yet the program claims I did. It frightens me to think I might be saving something I don't want, so I don't save when prompted. With autosave, how would I be assured that these types of "changes" will not be autosaved? – Mandiemandingo

You have to be able to tell a user when something is saved. A good application will implement both an auto save feature and a manual save feature. Look at MS Word, it implements an autosave feature as well as a manual save feature. However, sometimes autosaving is bad because it doesn't allow users to control when something is saved. For example in an ordering software, you can make mistakes, and you don't want it to be committed or processed all the time. – Harsho

One Note kind of cheeses me on this point. I would like to be able to explicitly save things, the auto save should be an emergency recovery option. – Leena

Autosave should be a third party save file. If a user wants to save multiple documents, that automatically means that your'e going to need a manual-save, and if you need that, the auto-save becomes added functionality anyway. – Dayfly

Answer 1

The save button is a well-known, comfortable UI feature that everyone from Jon Skeet to grandma is familiar with. If you got rid of it, it would be like removing the close button on a window for some people. Granted, they would eventually get used to it, but some people would not understand that their data has been saved automatically.

Also, if you're autosaving on the web, not only are you taking up a lot of space on your server with all those instances, you're also using up a lot of bandwidth with periodical saves. At least with manual save, you are only using the space and bandwidth when the user intends, which can be more infrequent, thus saving bandwidth. The advantage, of course, to autosaving is the retention of work should something go awry.

Check the definition of "skeuomorph" :)

Casemate

I believe that Jon Skeet's programs only auto save when Jon wants them to. – Enki

"more infrequent"... also known as "less frequent"? – Streeto

they have slightly different shades of connotation, despite meaning nearly exactly the same thing. "more infrequent" implies something doesn't happen a lot, and now it happens less, whereas "less frequent" means it does happen a lot, but now less. In the big picture, it means that it is happening less. – Casemate

Answer 2

autosave normally saves on a defined interval. What happens if you want to save in between intervals?

You should implement a manual save to stay consisent with other applications in the environment as well.

People expect file -> save, or CTRL + S to exist.

Taryn

Couldn't autosave be triggered whenever data beyond a particular limit is added/edited? That way you will always recover any significant changes. – Jugal

@Jeremy Rudd: "significant" changes are not necessarily large changes. – Mozarab

+1 for "People expect file -> save to exist". IME this is the single most important reason for including any seemingly redundant operation, including save. – Significance

Answer 3

Additionally with a "save" there is commonly "save as.." as well. Both give the user the feeling of control and security. Knowing that they clicked save lets them know at what state they can expect their data to be in when reloading it.

Bratton

Answer 4

It really comes down to this: a Save button is cheaper to implement and maintain than Undo.

Puppet

+1 I think that this ties in with simplicity. If you need a manual save option (you probably do) then adding auto-save becomes an -extra- feature, and may not have enough added value to warrant having both manual save and auto-save and the necessary communication between them. – Dayfly

Answer 5

It is not hard to implement auto-save - just implement a normal save and call it when ever needed or just in a timer (if you are lazy).

Save buttons are common because of the common pattern learned by the users for decades.

1. Load data or files from a persistent storage into main memory.
2. Modify the data in main memory.
3. Save the modified data back to a persistent storage.

This pattern comes from the old distinction between harde drive and main memory. If you think about it in another way (as some experimental operating systems do), there is no need for loading and saving files - just think about a hard drive as your main memory and and the main memory as another cache level for the hard drive. In consequence all files (not on removeable medias) are always in memory and you will never again need to load or save files.

But doing this change is not easy because users are used to the old pattern for years. Further the old load and save pattern is an very easy way to get a kind of primitve undo system.

Auto-saving requires an undo system, too, and it is not that trivial to build one. Esspecialy if you perform image, audio or video editing and you are producing a lot of data it is hard to find a good time-memory-trade-off. And there is the risk that user will try to undo things by closing the application and then recognize that this did not work. So it might even be a good idea to persist undo information to protect users from this error or saving unwanted changes in the case of a crash.

So, yes, I would realy like to see the save (and load) buttons to disappear. I would like persisted undo-information or even complete edit histories, too. But I don't think this change can happen in a few years - if ever.

Ezechiel

Answer 6

I work in the medical field and there are situations where you want the user to take responsibility for saving something. If you have an EHR and you are entering a prescription for a patient then you dont necessarily want it autosaving - you want the user to be aware of and take responsibility for their actions. Also, autosaving a value in a critical system like this could be disastrous for obvious reasons...

Include

Answer 7

Should be tagged subjective maybe?

As a developer, I am always a little uneasy around apps like that. I like having control over when my data is saved, though perhaps this is just years of conditioning at work. I get that little "uh oh" feeling whenever I close a window into which I've entered data without explicitly pressing a close button (or shortcut).

That said, I have been "trained" to accept it in certain situations. OneNote, for example, or Tomboy. A great many OS X apps follow this pattern, especially utility apps like DB server GUI tools.

So, in short, different tools for different situations. IMO, most software these days would not benefit from a move from a manual save to an auto-save.

Tardif

Answer 8

I think the answer to this is that 'it depends'!

You should consider not only your user's expectations in terms of consistency with other applications, but also the way in which the user is going to use your application.

A very common use-case for OneNote is that someone opens it up to dump in some information almost as an aside to what they're working on. They need to get in and out quickly. Any prompts about saving would be a nuisance.

Applications like Word, on the other hand, expect users to be spending a concerted amount of time working on a document. In this case, the chore of manually saving and responding to confirmation boxes etc will be seen as a relatively small task.

Vaticinate

As people have noted here, though, their use cases aren't all that much different. People -want- to be able to explicitly save a certain state in OneNote as well sometimes, that option just doesn't happen to be available. – Dayfly

Answer 9

From programmers perspective implementing autosave would not be a huge deal. You just set up a timer and callback would do the saving.

However, from usability point of view autosave is very problematic. First of all users are used to having a manual saving and not offering it to them would confuse a majority of users and take feel of control away.

Even bigger issue would be that autosave overwrites contents of underlaying file whether you wanted it or not. Of course you could have autosave feature saving onto temporary file but the decision to overwrite original document must always come from the user, not from the software. And because you would anyways need the user to initiate at least one manual saving, why not enable manual saving to be available always?

Stauder

Answer 10

An autosave feature is great when you are dealing with a document. What about a business application? If I edit a customer's account, should it update the account as I tab out of the edited fields? If so, what should it do when the account is in an invalid state? When do you enforce business rules and how do you enforce them? How will it perform when you have to take business rules into account on every edit?

You can certainly build an application that will take any of these considerations into account, but will it have been worth the extra effort?

So should we get rid of the Save button? It depends.

Ier

Answer 11

Short answer: "auto save" = "auto destroy" / "auto <expletive>".

Aretino

Nah, Auto-save is fine, as long as it has no effect whatsoever on explicit saves. If the auto-save is a separate save file at all times, then it can ony be added value. – Dayfly

Interesting. That's a bit more subtle, but a good point. Put a recovery buffer elsewhere, but leave me in control of whether or not the current state of my doodle is something that even should be saved. – Aretino

Answer 12

For one project in university, my group and I built an application without explicit saving as an experiment.

We implemented an infinite undo stack and serialized the undo stack with the actual data so that even if you closed the app and re-opened it, you could always undo your last operation. Every operation wrote a new entry to the action list on disk so that the file was always consistent (well, mostly...), even if the power failed. It was a bit of a cross between a version control system and a journaling file system.

There were two problems: one, we didn't have time to get it completely right (ah, youthful hubris); two, everyone (fellow students and, most importantly, the TAs) hated it, because of all of the reasons mentioned already.

Sometimes, for all your best intentions, you just can't ignore ingrained behaviours.

Azrael