Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Prior to widespread AJAX use and DHTML a form was submitted and the browser would refresh by loading the response to that POST HTTP request which replaced the previous (form) page in the viewport. Now, with AJAX being in common use, there are two ways to go about it.

I am trying to come up with some general guidelines of when it's better to use each particular approach. Here's what I came up with. I'd love to see if there is an existing set of use cases that is better than my rough attempt, or if there are other general use cases I haven't considered.

use AJAX submission when:

  • form submits 'to itself' (we show the same form after submission)
  • form is only a part of a larger view (such as a search form where search results may be dynamically added to an area on the page, such as a table or thumbnail grid)

use regular form submission when:

  • following submission we intend to have the user end up at a different page
  • form data submitted will change the data in the db or the application state in such a significant manner that the page should be 're-run' rather than attempting to submit via AJAX and then do an inordinate amount of work on the client to make the existing page reflect the changes (though I think in many cases changes may be simple enough that client-side view manipulation to reflect the new data/state will be appropriate)

Also be good to know if there are reasons why these guesses might produce a sub-optimal UX.

share|improve this question

2 Answers 2

From a UX standpoint I think AJAX is going to be better 100% of the time IF you can provide ALL of the proper visual cues that the form is processing and not just giving the illusion of being broken.

Some things to consider are:

  • Provide a visual spinner within the <button>Submit <img src="spinner.gif"></button> and make sure to remove it once processing is complete

  • Upon submission disable the button programmatically, and visually and programmatically prevent double-submission of the form

  • Provide an easily identifiable message box with clear error vs success vs further action required messages

  • Take into account network and server errors which can cause unexpected results to occur, make sure to catch them

  • If you need to display a different page upon success then JS can certainly handle that


From a programming standpoint it makes your life easier because you do not have to worry about carrying through the POST value of a field especially since that field could have been dynamically generated through user interaction.

If you are doing a very large POST then the user has to sit and wait until the browser can send all of those bytes to your server before the page changes and I assume your users are not anymore patient than mine.

share|improve this answer
    
+1 for your first list item –  Mark Bubel May 20 at 20:38

Overall your list of assumptions are heading in the right direction, though I wouldn't exclude yourself from the possibility of using both when it makes sense. Here are a couple other ideas:

  • Use AJAX to validate a form as a user moves along so they can see errors (or successes) more quickly.
  • Consider using AJAX for input fields which could help you make smarter defaults/assumptions about other areas. For example, ask for a zip/postal code first to pull back the city and state/province or even the telephone area code.
  • Use AJAX to temporarily (or actually) save content the user has written so far. Things happen. Browsers freeze. Computers lock up. Internet connections drop. Keeping track of drafts will help a user feel not so deflated when something interrupts what they were trying to do. You could still provide a "Save Draft" button. Clicking the button would just re-send the AJAX call.
  • Use a typical submit method when creating content that requires a refresh of the page or redirection to another page.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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