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.

We are discussing in our team how best to handle UI updates after a user does something to cause an AJAX request to the server.

Here are options we are considering:

  1. Instantly update the UI and add/update/remove the item that has been changed, even though we don't have a success response from the server yet. We would show an error dialog if the AJAX request failed.
  2. Change the object and show an "updating" state.
  3. Only update the UI when the server actually has returned a success response.

In all 3 cases we would indicate that the application is still busy with the request whilst the AJAX request was still being processed.

Maybe this depends on the action that is being performed and how important it is. How important is it to be consistent with these approaches?

share|improve this question
4  
You could add a third state. 3. Updating. Simply show the user that the system is working on the update and that it has not been completed yet. After the server reports a finish action either remove the item or show a correct error response. –  Barfieldmv Feb 21 '12 at 10:47
1  
Good point - I've added the extra "updating" state. –  andyuk Feb 22 '12 at 13:02

3 Answers 3

@Barfieldmvs response is probably the right way to go about it - show an "updating" state while the ajax call is in progress, and clear this when there is a successfull ( or failed ) response back. The advantage of this is that, should the ajax call die without any form of response, there is a clear indication that something is wrong, as the "updating" state would normally only show for a brief time.

Possibly more important is that you are showing the users the true state of things. Setting a display to "completed" when it is not is dangerous - they might just close down, and never see the error message that returns. Being pessimistic, but indicating the unknown state, means that the user is aware that the request has been sent but it is not completed yet, although they might not express it in quite those terms.

share|improve this answer

At work we had a similar problem to solve. However in our case was a little bit easier a we had more constraints.

In short, if the action was successful, we should have applied a small change in the UI. We did not want to display and updating status as one of the requirements was to be able to edit many elements quickly.

One idea was to go for the optimistic approach and in case of failure notify later the user. However this was not possible because some operations might be depending on the result of the still pending operation. So we had to update the UI only on successful response and displaying an inline "loading" icon, for that specific bucket, while keeping the other bits of UI available to receive inputs from the user.

If there are no dependencies then I think is ok to have an optimistic approach and in case of failure point out to the user what went wrong an why.

If you have dependencies however is probably not a good idea but try, were possible, to confine the problem to the smallest component.

share|improve this answer

I would like to see the optimistic approach, but the result of my action should be shown in a style that indicates it's not yet confirmed (grey text, disabled buttons, etc.). Actions that can be done as a result of the pending action (if there are any) should be disabled until it's confirmed.

Once you know you've had success or failure, you can remove the temporary styling and enable related buttons or links, or in the event of an error, remove it altogether and show the error message.

It's certainly simpler to follow the conclusive route, but the feedback is not as immediate.

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.