10

I am pondering of two approachs to work with my form:

  1. Send all data to the server when user has completed all steps.
  2. Save data to the server each time user has completed a single step.

Specificly, my wizard consists of three step: basic info, addresses, upload image. Each of these step consists of many manipulations that deserve a screen of their own.

In option 1, I worry there would be accidents during the steps that users lose all data they spend time inputing.

In option 2, I worry there would be accidents during the steps that would cause trash data.

Is there any things else I should worry about for each option? Supposingly the two options cause no technical problem, which approach should I take?

Appreciate all your help!

Improve this question
2
  • Is this a webapplication?
    – Uooo
    Oct 16, 2013 at 6:14
  • @Uooo yes, this is a web application. The wizard form is for entering new product data.
    – tiengtinh
    Oct 16, 2013 at 9:14

2 Answers 2

Reset to default
6

It is based on your requirement.

Send all data to the server when user has completed all steps.

If all the information(basic info, addresses, upload image) of the user are needed according to your requirement, then this is the best option.

Just think for yourself, You are going to send a three set of data to your server. Then which of the following is optimal ? a) send the first set , send the second set , send the third set (totally three server calls) b) store all the data temporarily till the end of the wizard and send all the three sets of data to the server (one server call)

Obviously option (b) will be the best one to choose.

Even if some accidents (unexpected error) happens in the middle, it wouldn't make sense if you just store incomplete or half data in your db (because you need all the info). It is better to let the user continue entering them just by retaining the info on the fields(maintain viewstate) and then save the info in the end of the wizard by sending them to the server.

Save data to the server each time user has completed a single step.

If all of the information are not mandatory and a specific set of data (any of the data sets) then you can send them to the server at the end of each step.

If some accidents happens in the middle, then you will probably have an one or two sets of data stored in your database, So depending on that you give the options to the user when he attempts to do the process again. I know it is tedious but definitely better than asking him all the info all over again. This is actually not a good practice, since the performance could be affected drastically with so much server calls which can easily optimized with your first approach.

Conclusion: As i mentioned earlier, the answer is based on your requirement. So if you just take care of the viewstate (maintaining the user inputs on all fields) it would be perfectly fine". Based on performance i would recommend the first choice "Sending all data to the server when user has completed all steps.

Improve this answer
1
6

I think the risk of your backend having some trash data (which you can get rid of) is much more acceptable than the risk that your user might lose some of her data from a catastrophic crash.

Furthermore, having data can be useful enough to help the user experience with pre-filling previously filled inputs.

Additionally, if you can get partial data on a user (such as a customer's email address) you can still take actions with this information (like emailing a newsletter, or a plea to "come finish your signup").

Improve this answer
5
  • 1
    I couldn't agree more on the last point. I would add that you could not only save the data after every step but also after every field is completed. So if the process starts asking for name and email address, eventually phone number, the business could get a lot of valuable information to push for process competition even if the "next step" button is not clicked.
    – Alexis Brion
    Oct 16, 2013 at 7:55
  • 2
    I am not sure if I would be happy when i started a registration, canceled it and afterwards getting emails (aka spam) from this website.
    – Uooo
    Oct 16, 2013 at 9:21
  • What about is your computer crashed and you forgot what site you were on? (Assume that the browser's history and cache were corrupted too). The point is, there's still helpful use cases for this practice
    – Bryce
    Oct 17, 2013 at 5:54
  • I'd like to disagree with the above, except for the spam, I really don't want email when I didn't opt-in for it. It sounds handy to keep state in the backend, but how would you handle this cleanly? When do you actually remove trash data? There will be times that you will remove someones partial data who was counting on it to come back later. How hard can a browser crash so that it wont maintain any local storage the next time the browser starts? Also incomplete data will probably have nullable columns in the database, when normalising the database how would you get these tables in 1NF?
    – Alex
    May 1, 2020 at 12:27
  • ad: obviously implementing all this logic (sending email and removing trash data, when!?, etc...) takes up time and adds logic/loc to the backend while they don't really add any business value (it are nice-to-have's). I guess what I'm saying is; why not keep the code simple and clean (read; stateless) in the backend? This will save a lot of headaches in the future. I know this is UX exchange, I guess what I trying to say is that anno 2020* you can have both a clean backend and reliable maintain viewstate in modern browsers. *I'm responding to a 7 year old discussion
    – Alex
    May 1, 2020 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.