Dealing with unsaved form data when user closes the browser

views:

366

answers:

+1 Q:

Dealing with unsaved form data when user closes the browser

I'm having hard time trying to figure out how to auto-save user data in a form when the browser is being closed or user changes the page. The onBeforeUnload event is OK when you want to open a dialog box, but by then it's too late to save the changes (except if you just block the browser in the onBeforeUnload handler long enough for it to pass the request to the server...but I'd rather not do that).

I am sure some of you have had to deal with the unsaved form problem. What do you do? Do you:

let users just lose their changes,
ask them using a modal window if they are sure they did the right thing,
save individual fields on the fly as they change,
or do you have some ultimate method to automagically save the data when it's about to be lost irretrievably?

+3 A:

•ask them using a modal window if they are sure they do the right thing,

Closing a window is an act of cancellation. As the user never actively submitted the form, theres no guarantee that they want the data saved (it may not be correct), and you saving the data could cause problems for the user.

Jaimal Chohan 2009-09-03 20:48:59

Start writing an answer or a comment here on SO and navigate away, it works well enough.

gnarf 2009-09-03 21:42:51

When it comes to webapps in which you edit things most of the time, confirming every change may be tedious. With autosave the problem would arise if you realized you had made a mistake and you wished you hadn't made a change. But, honestly, are you right or wrong with your actions more often? And in a webapp you can always implement rollback/undo for those that hesitate - it would be more usable (though more complicated for a developer).

Omeoe 2009-09-03 22:57:10

You don't need to confirm every change, just every group of changes, as changes are generally made in groups of data (i.e. contact fields, security fields, row of data in a grid etc). And normally this would be done without the user knowing as they would invoke an action (via a continue button to progress to the next group of fields or via a save button to exit edit mode etc) that would cause server postback or javascript event, which is when you would save the data. But thats just regular web-app flow.

Jaimal Chohan 2009-09-03 23:35:33

After filling in the form "Save" button is just one possibility of what to do next and it is not obvious without futher explanation where clicking "Save" button is going to lead user to (it only says the data will be saved). So, unless all links on a page are submitting buttons, two steps are required to go to the next page of user's choice instead of one and accepting changes requires user to do one more action and wait for one more page reload than they would have to with auto-save.

Omeoe 2009-09-04 10:45:48

In any browser I have used it in, onBeforeUnload provides you with a modal window which asks the user to confirm whether they want to leave the page or not. You can added your own text warning them that there is unsaved data, to help them decide. You don't want to explicitly save without the user's request, because a) the user did not attempt to save, and b) if you need to throw any validation errors it will be too late as the page is already in the process of navigating away.

RedFilter 2009-09-03 21:01:57

+1 A:

I like your third option:

save individual fields on the fly as they change.

I'm having to deal with a similar situation, and that's what we are doing. The two main things that sell that to me:

Improved user experience - the user will be impressed by a form that does not lose changes. They are 'committed' once they are validated. E.g., he types in a valid email address, and it is saved instantly, furthermore he is provided some sort of feedback for each field that is successfully been saved (a green tick for example, appears next to the field).
No more 'oh crap my browser crashed and I lost all my info' situations.

Disadvantages: The extra man-hours involved in developing such a solution, and the possibly that it ends up not degrading as nicely as a simpler solution. That said, it is still worth it IMO.

karim79 2009-09-03 21:10:01

With good implementation of this, graceful degradation is possible at almost no extra cost of implementing second no-javascript solution (you can validate a field separately and along with other fields with the same piece of code).

Omeoe 2009-09-03 23:06:36

ansaurus

tags:

views:

answers:

Dealing with unsaved form data when user closes the browser

related questions