Q:

Should a dialog close before a mutating change is accepted?

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:

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.
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.
The dialog immediately closes, but the settings on the main app page turn into a spinner, which resolves when the server returns.

A:

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.

