I have a closable modal dialog with primary action "Add". Dialog can be closed without applying of changes by clicking on "Cancel" button, or by clicking on icon "close", or by pressing the Esc button.

enter image description here

When user clicks on primary button "Add" the request is sending on server. In this moment I disable primary button and display loader, because it requires some time to receive response from server.

enter image description here

My question is should I disable also button "Cancel" while waiting for response from server?

Disable Cancel

If I disable "Cancel" user still have ability to close modal dialog by clicking on Close icon or by pressing Esc button.

Maybe I should made dialog fully not closable (by removing close icon and ignoring Esc button) during of sending request?

Don't disable Cancel

But if I don't disable "Cancel" user can close modal dialog and when server returns some error message, user won't see it, because error will be displayed inside modal dialog.

Or maybe I should use toast notification instead of error message inside of dialog, to guarantee that user will be informed about server error?

  • 1
    Is there actually something to be cancelled when the add button hasn't been clicked yet? And when it has been clicked, is the process actually being cancelled when you click on cancel?
    – jazZRo
    Commented Aug 10, 2023 at 15:34
  • No, in fact "Cancel" button don't revert any changes, it is behavior the same as close dialog by clicking icon "close" or by pressing Esc. Commented Aug 10, 2023 at 16:34

3 Answers 3


Can users cancel the process? I mean, suppose I added a host and then realize I made a mistake or need to check something first, so I quickly try to cancel. Will it cancel the process, or will the process continue working in the background? This question makes all the difference because the system response is entirely different, and so will the user experience.

Now, if users can't cancel or stop the running process and the reason for the button is just to close the modal, then I'd get rid of the cancel button and add a simple "Close" text link. If you can't cancel anything, then the cancel button shouldn't be there at all.

Just in case, your use case can be seen under the light of Shneiderman's 8 golden rules of UI, specifically Rules 4 to 7 (included):

4. Design dialogs to yield closure.

Sequences of actions should be organized into groups with a beginning, middle, and end. Informative feedback at the completion of a group of actions gives users the satisfaction of accomplishment, a sense of relief, a signal to drop contingency plans from their minds, and an indicator to prepare for the next group of actions. For example, e-commerce websites move users from selecting products to the checkout, ending with a clear confirmation page that completes the transaction.

5. Prevent errors.

As much as possible, design the interface so that users cannot make serious errors; for example, gray out menu items that are not appropriate and do not allow alphabetic characters in numeric entry fields (Section 3.3.5). If users make an error, the interface should offer simple, constructive, and specific instructions for recovery. For example, users should not have to retype an entire name-address form if they enter an invalid zip code but rather should be guided to repair only the faulty part. Erroneous actions should leave the interface state unchanged, or the interface should give instructions about restoring the state.

6. Permit easy reversal of actions.

As much as possible, actions should be reversible. This feature relieves anxiety, since users know that errors can be undone, and encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data-entry task, or a complete group of actions, such as entry of a name-address block.

7. Keep users in control.

Experienced users strongly desire the sense that they are in charge of the interface and that the interface responds to their actions. They don’t want surprises or changes in familiar behavior, and they are annoyed by tedious data-entry sequences, difficulty in obtaining necessary information, and inability to produce their desired result.

EDIT: Answering comment

If the user wants to cancel the host-adding process, they can simply close the dialog.

To be clearer and cater to more generic scenarios than your specific one:

Ideally, actions should have two parts: a DO and an UNDO (hence why I mentioned the UI rules above).

In this particular case, there are two actions: the first one is user-driven and denotes the intentionality of the user to add a host (this is the DO), for which the user starts a flow that begins by opening a dialog. This action is interrupted by Close (the opposite or counterpart of open). That would be the UNDO.

Then there is a second action, which is initiated by the user when clicking the "add" button. This second user-driven action starts a system-driven action (adding the record to a DB or whatever). This action could be canceled or not (in your case it can't). But assuming that you could, the label would be "Cancel" (or "Stop" if it's a slow process, or similar wording as needed), because you're canceling the process that is occurring in the background.

Then again, since it's not possible to stop this process, the cancel button shouldn't be there; this secondary system-driven action has no possible counterpart. However, I assume the user can recover from a possible error by editing the host again.

  • What if the user opened a dialog box to add a host, and then changed his mind about adding it? I think Cancel is still useful in this case and reflect action. But I agree with you, what Cancel should be disabled or hidden after user clicks on Add, because this action is not cancellable in my case. Commented Aug 10, 2023 at 17:48
  • I edited my post to reflect your comment
    – Devin
    Commented Aug 10, 2023 at 18:22
  • 1
    Thank you for detailed answer Commented Aug 11, 2023 at 10:26

I think the problem is in the redundancy of actions, I would opt for a cleaning that gives greater clarity to the process:

  • One action for each button/icon
  • A single window close button: X
  • Keep the Add button as the only action of the window
  • Replace the Add button with Stop while the action is running
  • Replace the Stop button with Add when the user clicks on it

enter image description here


I believe it depends on context of a modal and strategy(positive/negative) in general. Usually an add dialog is needed in list-like elements and all statuses can be reflected there.


  1. Make the dialog lighter removing loading status
  2. Add an item to a list on the frontend side only with loading status
  3. Update status of the item: in case Success - make possible to manipulate with it, in case Error - make possible to change the submitting data and read the error reason

This way does not prevent a user to proceed with his/her work and keeps him/her calm

  • can you expand a bit? right now it looks like just an opinion
    – Devin
    Commented Aug 10, 2023 at 16:15
  • Do you mean to display possible error message above of items list? Commented Aug 10, 2023 at 16:36

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.