Have a question on the most efficient way to tackle a project. I have a long questionnaire for users to enter data into - it's a big questionnaire - probably 20 pages long. Here's what I'm looking for: 1) I would prefer that the user work through the questionnaire without having to hit submit or save anytime they enter something into my php based forms. As soon as the user inputs something, the form retains the information. The information would also be submitted to a mysql db. Obviously, you don't want to do a call on the DB everytime the user hits a key, so what is the most efficient means of doing this? I've just started looking into AJAX, but wasn't sure if that would be the best way to handle it? 2) What would be the best way to ensure data integrity? I don't want users spending an hour entering information into the questionnaire and then losing all their data, so what's the best way to protect against this? TIA!
Break up the form into smaller sections and save their work when they press next? That's how I've always seen long questionnaires handled. The user is already trained to use that type of form. Why reinvent the wheel?
Page the form and do a DB write when moving between pages, forward or back. If your environment will allow you to write cookies using JS, save user input using the onblur() event on each form control. Store the data in cookies until the DB write between pages so you have a copy outside the form. After the DB write, delete the cookies. That way, even if the user didn't manually save, you could repopulate the form page the next time they came in.
Hey BJ, I thought that might be a good idea. I don't envision a ton of users, but I read that php is limited to only 20 cookies. Do you know if that's client side (per user) or server side (so you can only assign up to 20 cookies total)? I think the book I was reading from was on php4 though, so maybe that's been updated. There's 7 sections in the questionnaire, so maybe I could use the cookies between sections. They move into a new section, it deletes the old cookie - downloads any relevant info on the new section from the database - forms a new cookie with the information. Would that run into any issues scalability wise?
Break the page into sections/tabs and store/pull/push the data to the DB via Ajax when the user jumps from one section to the next. Put a button on each section/tab, or just one at the end, if it needs to be sequential, to confirm the user is done. You could use localstorage over cookies, to save the info temporarily if the user left the page for some reason and came back, populating back the data they already entered. You can store more that way, than what cookies allow.
I predict no one makes it past the first 20 items on the form. No one in the US has that kind of attention span any longer. The first thing I would tackle is to how to get rid of 18 pages worth of questions.
BAs are always trying to take the fun out of solving technical problems. The actual value of the solution is totally irrelevant.
Great point. If you apply for car insurance now they can prepopulate all the info including what cars you have registered with some simple ID verification. Only takes a few minutes vs, 20-30+ per quote a few years back. Most signup forms for services also have eliminated the "confirm password" field to make it easier and increase conversions. Right now for a B2B site I'm developing we are using Yelp and Yellow Pages data to populate the signup forms. The user expects shit to be simple these days.
Don't use cookies. Use local storage (http://www.w3schools.com/html/html5_webstorage.asp). combine it with onblur or focus or something along those lines. Get really tricky and write it in something like AngularJS, React/Flux, Backbone or one of those things and turn it into a single page app that only submits at the end while using local storage to save the data in the users browser. Or just use something like SurveyMonkey or FormStack that has already done this sort of thing and grab all the data out after the end of the survey. -steve
