views:

443

answers:

3

We are designing a data capture process with many questions (using ASP.NET), which can repeat (e.g. enter all your vehicles). In rare cases this could be over 100 repeating groups.

Therefore I've stated that rather than having one huge form that we split the application into multiple forms, using logical points for page splits (e.g. personal details) in a wizard style.

However, there is debate within the team as to whether we should be using AJAX/Javascript to have a single form. Suggested approaches to this appear to be:

  1. Load in all the steps in one go, and just use Javascript to toggle.
  2. Load in step 1 and load the other steps using AJAX.
  3. Submit the form using AJAX and load the next step using AJAX.

Option 1 to me defeats the entire point, as you'd end up loading a massive HTML tree - some of the pages can be large. This would be more acceptable if there was a small number of steps with very few questions on each.

Option 2 to me seems overly complex, plus if the user clicks the next button, can you guarantee the next page has loaded? Also, what happens if input from page 1 is required for page 2?

Option 3 seems doable, but I'd have though the response time of doing the AJAX processing would actually be slower than doing a standard form submit, as there would be more processing involved by the client browser. Also this approach is more complex than a standard form submit.

Do you think my approach is correct (standard form posts)? I've read that typically AJAX is used to enhance the functionality of a page, rather than trying to emulate multiple pages.

A: 

With regards to performance, this is something you can test. But if you go the AJAX route, you should provide an alternative for those users without Javascript. The extra work required may be enough to push the idea off the board.

MikeB
Agree we want to ensure that a standard form post should work from an accessibility perspective.It just feels that what we'd be doing is posting entire pages via AJAX with the proposals I've mentioned. We'd be replacing everything but the header and footer pretty much.It also means that we break the back button behaviour using AJAX.
spooner
If you are simply looking for people to help you defeat the suggestion to use AJAX, count me in if you like. From what you have described, it seems more like an indulgence than offering anything substantial from a usability point of view in this case.
MikeB
One other thing though - if you load the entrie page and use js to paginate it, you will possibly need a means to keep a session alive. AJAX will help you there - effectively pinging the web server on a timed basis.
MikeB
Generally speaking I'd use AJAX for loading in parts of a page, or submitting small parts - so I'm not against AJAX just the proposed usage of it that I've outlined above.Problem here is that it's multiple pages - as you say you don't get any usability gains here.
spooner
A: 

To my mind, options 2 & 3 lie at ends of a spectrum. You can use AJAX to submit whatever information is required for the next step. Option 2 submits nothing. Submit the entire form, and you have option 3. You'll probably want something in between.

As for performance, there is some processing to be done (collect form data, data transmission, parsing, splicing the result into the document), but the browser will be doing the same tasks with a traditional form; AJAX just makes parts of the process more visible. Since the data is smaller in size (part of a form rather than a full page), performance shouldn't be much worse and may in fact be better. Also, modern javascript engines are very fast.

In any case, listen to MikeB's advice about degrading gracefully when JS isn't supported, unless this is for an internal app where you can depend on browser make & configuration.

outis
The concern is that it isn't lots of small forms in a page, each step will have a large number of question inputs (think about 50+ inputs on some steps) and we'd have to post the results when the user navigates between the steps.Essentially per page the only thing we'd be save with the AJAX route is loading in the header and footer. The other concern is the limitation in ASP.NET where you can only have one server side form, therefore it may add extra complexity to selectively post certain elements.For such large posts I'm not sure I see the benefit of using AJAX vs a full page post.
spooner
+1  A: 

The Single Page Interface Manifesto talks about how you can build SPI web sites without losing bookmarking or SEO.

jmarranz