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?

Answer 1

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.

Answer 2

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.

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.

Answer 4

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" :)

Answer 5

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.

Answer 6

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.

Answer 7

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

Answer 8

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?

Answer 9

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

Answer 10

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...

Answer 11

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.

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.