Should we be optimistic or pessimistic with UI updates on AJAX requests?

Question

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?

Answer 1

@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.

Answer 2

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.

Answer 3

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.

Answer 4

Depends how your UI is structured. If you use optimistic updating, whereby something disappears from the UI after the user hits save without the app knowing if it has saved on the server, can lead to a bad UX if the user continues to use another part of the page if 10 seconds later your app pipes up that the save wasn't successful.

Best to be honest with the users about the state and try and factor in some localised indicator on the page that something is happening. This way it doesn't prevent them from continuing to work on the page and allows for the localized area of the UI to be reversed if the save doesn't happen.

Answer 5

I would say keep the information stored locally and update the page with the new content. In case anything goes wrong server side, alert them and allow them to resend the stored local information again, as many times as needed.

And ALWAYS indicate if the information has yet to be received or processed by the server. This keeps the end user properly informed and not clueless.

This way the UI does not give improper feedback, and can prevent the loss of user imputed data. There is nothing worse than filling something out and loading it because a server lost it, or the networks between kicked it under a file cabinet. (Haha)

So to answer: do all 3!

You should definitely update as progress changes:

1. save the info
2. display the saved local
3. Send to server
4. Display progress bar (or spinning indicator of progress not applicable)
5. Alert if failure, prompting resubmission. Hide progress upon success, notify momentarily then hide success.

Answer 6

A bit late to the party, but the answer to this question is found by looking at the use-case, not by hyper focusing in the user-interface and the technicalities.

Big tasks or storing crucial information that has a big impact, or a high change of failure

For instance:

• bills will be send,
• healthcare will be initiated
• communication is send to 1000's of people.

Show the response before the user moves on with their tasks.

A lot of small tasks

For instance

• entering information in a form
• creating a drawing
• playing a game

Show a status bar somewhere with more information about connection status etc.

Small actions with little impact and little change of failing

For instance

• leaving a like
• leaving a comment
• sending an e-mail

An optimistic UI is perfect.

Think about your user and what kind of feedback is best for the action!