When doing AJAX edit to the database, should I update the interface immediately with the new data

Question

I'm using inline-edit to update text in the database with AJAX. This is basically the process, pretty usual stuff:

• text is not editable
• I click the text, it becomes editable
• I type the new text
• then click to send the updated text to the database
• then return the text to non-editable format

My question is when should I update the interface with the new data? Should I update it immediately before the ajax call, or should I wait for the update response to return from the database?

My concern:

• If I don't update the interface immediately and wait to get the response from the database, then I've lost the asynchronous benefit that comes with ajax.
• But if I update it immediately, then if the database response has an error, I somehow have to track the change I already made, and reverse it, which is a lot more work.

So how is this sort of thing usually done?

Answer 1

I think it is completely reasonable to wait for the response and update as a result of a callback. Doing so does not detract from the async approach. It is still fully async because you are not blocking the entire page or reloading it completely.

Plenty of times in apps, especially in mobile ones where the bandwidth might be limited, I will see a spinner indicating that the field is submitting. This does not hold up any other part of the app. Even stackoverflow does this when I use the mobile view. Rely on the callbacks in order to stay async and still be synced to database return values.

Answer 2

AJAX calls are pretty quick, excepting network issues of course. Personally, I don't think you will lose the benefit of AJAX by waiting for a response from the database. That is, unless you plan on it being slow because of server-side processing, etc...

Now if you were to set the textfield to a non-editable state, the user might think that his change has been accepted and will be confused when the server returns an error and the value is reverted to its original state. I would leave the field editable until the server returns.

Answer 3

If you are using jQuery it's pretty simple, but if you are using your homebrew ajax call script you will have to add some mechanism to see if everything went good or bad.

$.ajax({
 url: '/ajax/doSomething.php',
 type: 'POST',
 dataType: 'json',
 data: {
  'q': $("#editableText").val()
 },
 success: function(json) {
  $("#editableText").html(json.value);
 },
 error: {
  alert('something went wrong!');
 }
})

So when your doSomething.php returns true or false, our ajax calls does something according to it.

Yes the ajax calls are pretty fast, but before changing the data displayed on the page I guess you must be sure that everything went OK, else the user might leave the page without knowing if they have done the editing or not.

Answer 4

The case that you have mentioned is an Optimistic UI update. In this case you are assuming (implictly) that the update will be performed on the server without any error.

The disadvantage to this approach would be with a following scenario

1. User clicks on non-editable text
2. Text becomes editable
3. User types in new text
4. User clicks send
5. The UI changes to the new text and makes it uneditable
6. User closes the browser window (or navigates away from the page) before the reply ever comes back (assuming that the change was performed)
7. Next time the user logs in (or comes back to the page) they are confused as to why the change did not apply!

However you also want to use the asynchronous nature of ajax and make sure that the user can still interact with your app (or the rest of the page) as this change is being performed.

The way we do that (at my work-place) would typically be (using long polling or http push)

1. The user interacts with non-editable text
2. The text becomes editable
3. User types in new text
4. User clicks send
5. Instead of updating the text optimistically we show some kind of spinner (only on the text) that indicates to the user that we are waiting for some kind of response from the server. Note that since we are only disabling just the part of the page that shows this text the user does not have to wait for the ajax call to return in order to interact with the rest of the page. (In fact we have many cases that support updating multiple parts of the page in parallel). Think of gmail where you might be chatting with someone in the browser window and at the same time you get an email. The chat can go on and the email counter is also incremented. Both of them are on the same page but do not depend on each other (or wait for each other in any way)
6. When the update is complete we take away the spinner (which is usually shown using css - toggle class) and replace the element's value with the new text.

Lastly if you are doing something like this make sure that your server also has support for adding a pending class to the text field (that will cause a spinner to appear). This is done for the following reason

1. User updates text and submits
2. User immediately navigates to a different page
3. User then comes back to the original page again (and let us assume that the update is not yet complete)
4. Since your server knows that the field is being updated and can add a pending css class to the label / display field the page comes up loaded with a spinner.(On the other hand if there is no pending request there will be no spinner shown)
5. Finally when the long poller message comes back from the server the spinner is taken off and the current value is displayed