Is a cancel button necessary in a windows form?

Question

After reading the question "Is a cancel button necessary for a web form?", I still ask myself, whether the same applies to a Windows form/dialog box.

Consider the following dialog box:

Compared to the following mockup:

Although I never did omit the Cancel button until now, I have the feeling, that the user might well enough know that the upper right red "X" is here to cancel any dialog.

So I'll effectively give him 2 identical options to cancel (red "X" and cancel button) whereas he only gets one option to store (the OK button).

My question is:

Do you think it is a good idea to remove the cancel button in order to simplify my dialog boxes?

Update 1

What about omitting the "X" instead?

Answer 1

The top "X" button closes the dialog (according to its tooltip), it doesn't cancel it (necessarily).

Microsoft's UX guidelines say:

Label a button Cancel if canceling returns the environment to its previous state (leaving no side effect); otherwise, label the button Close (if the operation is complete), or Stop (if the operation is in progress) to indicate that it leaves the current changed state intact.

The security that comes from a "Cancel" button is the assurance that there's no side-effect. This is especially true for a dialog whose value is optional, or one shown as part of a longer operation.

I understand that your motive for removing the "Cancel" button is to remove the visual cruft of unnecessary controls, but I think the best way to do so would be to set the OK button as the form's default button to both visually set it apart, and to do your best to prevent the user needing to target the button with the mouse.

Perhaps the most explicit instruction Microsoft provides is the following (from the dialog box UX guidelines):

Provide a Cancel button to let users explicitly abandon changes. Dialog boxes need a clear exit point. Don't depend on users finding the Close button on the title bar. Exception: Don't provide a Cancel button for dialog boxes without settings. The OK and Close buttons have the same effect as Cancel in this case.

Answer 2

Not sure how relevant my contribution is, but for my client's intranet, we replaced the Cancel button with a Cancel link next to the action button. The logic being that no action will happen and the user will be taken back to the page behind the dialogue. Whereas a button is an action element expected to produce some kind of processing.

We debated removing the Cancel button altogether, but decided against just relying on Esc or [X] since many publishers who were not too tech savvy did not realize how to get out of it.

This kinda answers all the concerns mentioned above in the three responses.

Answer 3

I would say it depends on what your dialog box is for. If it's for an action the user can cancel, then you must include a cancel option. If it's a message that the user just needs to acknowledge and the outcome is the same whatever the user does, then just have "OK". But if there is a genuine cancel option, don't get rid of it just because you can also close the window.

Answer 4

The basic advantage of window based software is switching possibility between windows for multitasking. The top control elements such as: minimize, expand and close a window initially for this purpose and intended. The primary goal of modal windows is to continue or cancel a process adding a name for your example above. Elements of window management directly aren't necessary to you and the button to X - close in this case describes process more likely to interrupt, instead of to cancel. Besides it you always have a third possibility to "X - close" window using the keyboard - Esc.

Total at you three possibilities to interrupt action but if to start with the purpose to finish or cancel name addition - more logical variant to keep buttons Add & Cancel for the user and system possibility to interrupt action from the keyboard. I don't see necessity for the X-Close button onto, cause i don't need any window management possibilities in this case.