Does a form with continuous save need a "Save" button?

Question

I am designing a web-app with a lot of forms and i was wondering how to improve the filling. The classical pattern is : fill, fill, fill, Save

Have you experimented a form which auto-save each field once you unfocused it ? In that case the Save button is no longer needed but maybe the user is reassured by it.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 1

As a user I don't like this idea at all.

There are 2 scenarios:

1. Creating an entity
2. Editing an entity

If I am in the create mode for say... a contact... as soon as I type "Dave" in a first name field it would have to create an entity... if I decide nah... I'm not going to add Dave after all, normally I just leave the screen and all is fine but in this case you're got a partial, and undesired entry in the system that the user didn't want.

If I am in the edit mode, I may start making some changes... then whoops wait... I entered the wrong data (or entered it in the wrong field)... no problem, just discard my changes and reload the form!... wait no, can't do that as it has overridden automatically.

The great thing about a Save button is that the user is giving explicit instructions to you to save the data up until that point the user expects that they haven't committed to anything.

Answer 2

I posted an answer here that I think addresses this concern in some detail.

Auto-save is a great feature where the user's work may take some time (like long forms and document editing). You spare them the mental overhead of remembering to save as they go.

Don't send the wrong message

If your system is saving incrementally as work is completed, but you also provide a Save button, the user is left to wonder what that auto-save is really doing.

Is it really saved?
Do I need to click this button too?
If I click Save will I leave the form?

Why put your users through such anxiety? Make up your mind and decide on the right pattern: manual or automatic save.

Clear visual cues

Because forms are often manually saved (for better or worse) you need to make it very clear to your users if you decide to go against that. Here are some visual cues I've used and have performed well.

Provide a way out

Users occasionally (often?) change their minds. If you've been saving their work along the way, you need to provide an easy way to reverse that work. There are several features that make this work well, especially in data-critical applications.

• Field-level undo
• Cancel and discard all changes
• Change log with ability to revert (for admins)

Answer 3

I feel there needs to be a single point where I can confirm ALL my input has correctly saved. Your auto-save example does not have that - imagine a longer, more complicated form, and you put some invalid value in one of the fields, you correct it, there is a small delay between typing and saving, etc... Maybe the connection is unreliable and saves randomly fail, etc... How do I know for certain everything is correctly saved?

I think you should consider how Google Docs and Office 365 does it. In the toolbar they have labels which shows the status (e.g. "Saved 2 minutes ago", "Saving...", "Not saved - no connection to server lost, trying to reconnect" (or something like that).

For your form, you could put this at the bottom of the form near where you would have put the Save button. The information could be:

• "Saving changes..."
• "All values have been saved automatically X minutes ago"
• "Some values have not been saved because they have not been properly filled, please check the form."
• "Some values have not been saved because (error)"

I think this should be at least as prominent as a Save button would have been - maybe a large green tick, bright read X if it failed, some spinner graphic if it's progressing (next to the text description)

Answer 4

I've tried it in an auto save form but found that having a button at the bottom of a form was logical and expected for most users. In my case it would be a 'publish and close' button. Users might feel insecure about their content being saved without approval. That's why it is a good idea to have the save button. It gives users a feeling of control over their content.

It's like the "I'm feeling lucky button" from Google. People expect it to be there even though it does not show different results than when you use the 'normal search button'. In fact, if you have javascript enabled you don't even get the chance to press it because Google shows results when you start typing.

See this question for more on that.

Sometimes things exist not because they still make sense, but because their presence is an affordance -- i.e. it works not because it's good, but because the visitor understands what it is, what it does, and how to use it, because they've been inculcated over years with this knowledge.

Answer 5

Forms without a save button have become more common recently based on my personal experience.

I have observed more companies using such forms that don't have save buttons. One area that this seems common is with 'settings'.

Initially I found these forms very confusing - basically "where's the save button" anxiety. Initially I would go to other tabs, log out, log in, make sure the data stayed Over time, now I've experienced this a bunch of time, I've got used to it and am no longer confused.
Similarly for the ajax feedback messages for changes as they are made - initially I needed and wanted this feedback. Over time I've got used to newer forms not giving me that feedback. I still prefer the feedback myself but I have got used to forms where I don't get it

This is one example of an interesting category - user input that doesn't work well for folks because of their existing mental model but once they get used to it their mental model changes and the change becomes acceptable - even desirable !

Answer 6

If you really think auto-save is the way to go, I would say do not put a save button. But make sure you indicate in some way that the data is saved.

As scunliffe pointed out, for the use case that you showed, automatic saving is a bad idea. If someone backs out, a partial will be saved, potentially forever. To avoid this, you could ask the user whether or not to save the partial before they exit the page, but in my opinion that would degrade the user experience more than having a save button.

Answer 7

Besides of user experience issues shown in other answers, you must consider performance and security issues here:

1. Every time your auto save event trigs, your form executes the save to database command. Now if you have 10 fields in your form, then you should expect your server to run this command at least 10 times more than having a Save button. Since you have a web page, you have the potential to reach for millions of users making this not a trivial thing.
2. Since your page is always requesting for send/receive little packages of data, user’s system may allocate an unnecessary amount of data communication resources to you page/form.
3. Since you almost gave away the control to save to database event, you could not, at least in an easy way, check if the sender is a human or an automated peace of code. Therefore, your page may be in higher risk of denial of service attacks.
4. As pointed by scunliffe you database may have thousands of partial scrap data, reducing data quality and database overall performance.

At last but not least: “... up until that point the user expects that they haven't committed to anything.” (scunlife)

Answer 8

Use both. Except auto save should not directly go to new/edited entry, but to its draft version. If user closes form for whatever reason (or in case of crash) and then decides that he wants those changes after all - you pull out saved draft and let user continue from where he left.

Buttons below the form should let user finalize the changes - i.e. commit to base, publish, send, whatever, and revert to last committed version where applicable.

This might be different in some scenarios, but often incomplete data isn't useful and can even be confusing, especially if user publishes it in some way for other people to see as opposed to editing some personal database, so it's better to still have some way for editor to signal "it's ready for consumption" instead of pushing every little thing to outside world automatically.

That's, IMO, is most intuitive approach. That's how GMail works with autosaving your drafts all the time, but sending only when you directly instruct it to. Even the comment form where I write this answer right now works this way - whatever I type is continuously saved as draft and never lost, but I need to explicitly push "post your answer" when I'm done.

Answer 9

Yes, Please! I work with a program that autosaves when I press enter. Even knowing this, I often will reopen the page to check that it saved what I entered/changed. This creates more work. The lack of a clear, concise answer and not wanting to screw it up makes me do so. If they would put a saved up or offer a button it would make me happy. So there ya go, a real life example of why you should.