I have a simple settings dialog

Some setting: [     ]

[Update] [Cancel]

When the user clicks on "Update", the app will send a request to the server to update the user's settings.

Should the dialog close before or after this request is acknowledged? I can think of three different behaviors here, and I'm not sure what's best:

  1. The dialog stays open until the server responds with success (in which case the dialog closes) or failure (in which case the error is reported). During this time, perhaps the "Update" button turns into a spinner, or some other indication that something's happening.

  2. The dialog immediately closes, and the settings displayed in the main app page are immediately updated client-side. When the server returns, if it returns with a failure, then some notification (popup? error message underneath the settings?) tells the user it failed.

  3. The dialog immediately closes, but the settings on the main app page turn into a spinner, which resolves when the server returns.

  • 1
    If you are having notifications section in your application, then you can move the update progress inside notifications as like in azure portal and close the dialog immediately.
    – Praveen
    Commented Feb 25, 2019 at 5:48

2 Answers 2


I feel that it depends. To be as unobtrusive as possible, if the settings that you are referring to, does not impact the immediate usage/experience for the user, we could just use option 3 - Immediately close the dialog + spinner on the settings

However, if the experience of the user depends on the settings that he has invoked, I would generally prefer to use option 1. If it is taking longer than expected eg after 10 sec, you could also inform the user that he will know the status of that transaction later, and fall-back to option 3.

Option 2 in my personal experience tends to confuse the user and lead to a poorer experience. eg He has assumed that the settings change was successful and is later informed that it was not, despite having seen that it was reflected at the client side.

  • I ended up going with option 1, with the notification if it fails. Commented Mar 5, 2019 at 1:08

I recommend using an optimistic UI approach which would sort of be option 2.

What is an optimistic UI

A UI that updates immediately and can be used without having received a confirmation from the server.

The idea is simple, most of the time the updates works and keeping users waiting is unnecessary. Waiting means that users perceive the system to be slow, cumbersome and hinders efficient work.

For low importance actions there is no progress indicator (liking a tweet) and for more important actions some indication is included next to the updated information. If the update fails then this is handled as an exception. This is a very common pattern and this article has several examples of how it's used in different services:


Optimistic ui generally acknowledges that operations succeed and speed/flow is more efficient if the user perceives the UI to act fast. The doherty threshold and RAIL model both point to that smooth interfaces require lightning quick feedback (400ms-100ms).


Smashing Magazine: True Lies of optimistic UI

RAIL model

Laws of UX: Doherty Threshold

UX planet: Optimistic UI

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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