Moving back to desktop land after being drunk with mobile interfaces, desktop dialogs almost always have these three buttons:

  • OK
  • Apply
  • Cancel
  • A close button.

This pattern seems to occur on both Windows and Linux-based UIs. Never tried other OSes. May have existed in Macs, but maybe I just can't remember.

It never occurred to me before that they were redundant until just now. The Cancel button is the same as the close button. Why was it placed there in the first place if both things do the same? They both close the dialog.

Also applies to the OK and Apply buttons as well. I tend to click either. Both do the same thing. Sure, Apply will apply changes without closing the dialog. But most of the time, you have already set all the preferences you needed, and just needs the OK to confirm.

  • What was the logic for such design?
  • Why a Close when there's a Cancel?
  • What makes Apply differ from OK?
  • 1
    Cancel's not the same as Close. Try closing an unsaved document. Cancel cancels you trying to Close the document without saving it. – PhillipW Oct 18 '12 at 10:33
  • 1
    @phillipw try closing a document. Clicking cancel on the dialog or close on the dialog does the same thing. – Joseph Oct 18 '12 at 12:41
  • Fair point. I've never actually noticed the close cross on the dialog... On the Mac 'Classic' environment which I grew up with it doesn't exist. I suspect the duplicate buttons came in with Windows 95, which was 'inspired' by the Mac interface. – PhillipW Oct 18 '12 at 19:14
  • There's also the ESC key, which should behave the same as clicking the close button if there is one or the "Cancel" button if there is one. – Sildoreth Sep 23 '14 at 14:48

They are distinct:

  • OK: Applies the changes and closes the dialog (or goes back to the previous location / one level up)
  • Apply: Applies the changes so the user can see / work with the results, but keeps the dialog open, ready for further modifications
  • Cancel: closes the dialog without applying any changes.
    The "Close button" in the window title usually acts as cancel, but can be considered "good redundancy".
  • Close: closes the dialog, but also indicates there are no changes to apply. Close should not be available if there are any changes pending

Start with two distinct user models:

The "traditional desktop model" of confirming changes before making them permanent sits well iwth the initial use of computers for science, engineering and business: there is an official state, someone is responsible for that.

For the casual, entertainment-centric environment of mobile, a more casual, "do whatever you like, you can undo anytime (within reason)" fits much better.

(Note that the distinction isn't desktop vs. mobile, it is mainly business vs. casual.)

Now, why those buttons?

The "Apply" is an extension of the OK/Cancel model, you could see it as hack to get some "manual preview" within the limits of the OK/Cancel API.

Consider an alternate design:

  • Changing any setting on the dialog immediately makes the changes visible "as if applied"
  • OK makes the changes permanent, and closes the dialog
  • Cancel undoes the changes and closes the dialog.

This requires all changes to be reversible - even in the case of errors, failed connections etc. You need real transactions - or something close to that, a simple Get/SetProperty API is not sufficient for that. It also creates much tighter coupling between the object and the dialog, the updates must be fast enough to be considered instant. In addition, concurrent changes become harder to manage.

The "OK / Apply" model provides a workaround that can be put on top of the existing API with little extra cost and often tangible benefits.

So what's "right"?

Keep in mind there are two dependent but distinct aspects here: one is the (business) requirement of "taking responsibility for changes", the other is improved discoverability and comfort of "undo".

The traditional OK/Cancel model puts them at odds. The "casual" model prominent in mobile prefers the comfort, falling back to the "confirmation required" only for important irreversible actions.

This model is preferrable in business environments as well, but often requires adding change tracking (when who what), role management and comparison/diffing.

  • 2
    In general, when one opens up a property dialog box, if one doesn't hit "apply" or "OK", one may expect to be able to cancel any one has made and leave the object in its original state. "Apply" is often useful in cases where one knows that one wants all the changes one has made to that point; hitting "Cancel" at some later time should revert to the last "Applied" state. Without "Apply", the only way to set a checkpoint would be to close and re-open the dialog. – supercat Apr 21 '14 at 21:43

Firstly, you should never use OK when you could use a verb instead. The meaning of OK is too easy to misinterpret, it's much better to use a descriptive button name so users understand what action they're undertaking. The only time I think an OK button is acceptable is in a purely informational dialog.

Why a Close when there's a Cancel?

The redundancy of a Cancel button and the Close widget is a good thing. Although they both have the same result most of the time, they signify two distinct tasks. The Close widget means "get rid of this window and don't do anything" and the Cancel button means "I've changed my mind and don't want to do this task".

OS X neatly sidesteps this issue by using "Sheets" (Document-Modal Dialogs). The dialog is attached to the top window title. The document itself still retains its close widget, but it's disabled if a Sheet is active. Therefore the user knows they still have a decision to make.

OS X Sheets

What makes Apply differ from OK?

Apply is useful especially in a non-Modal dialog box. You can apply changes to a document, for example, and then see how the changes affect the document while keeping the dialog open, and then make further changes until the result you desire is achieved.

In a modal dialog, Apply is the same as OK and in some contexts would simply replace an OK button. (See above, use action verbs instead of OK whenever possible.)


I believe the OK-Apply policy comes from a time where forms with multiple tabs (or similar) couldn't retain the changes between tab switches. Thus the apply had the advantage of allowing the user to apply a subset of the changes that they intended to do.

Definitely not supporting OK-Apply approach, but I must admit, the apply has helped me cautiously save my way through a long form without the fear of saving all or nothing!

Semantically Cancel may mean something different than Close, which might explain it's initial existence. Although over the years, as you mention, there hasn't been any difference observed between them.


See "When to include an Apply button?" One of the takeaways from the answers is that the apply button is inherited from those times when making real-time/on-demand changes (like Mac often does) would be expensive, in terms of time and/or processing power.

If you take a look, dialogs in phones and mobile operative systems don't tend to have the close/cancel combo, rather they have only a cancel button when a dialog pops up. I would assume that the cancel/close redundancy comes from an user interface framework, where the dialog box would have the close button by default, becoming a standard (think about the alert() function in JavaScript for example).

  • 1
    Even when instant preview is available, it can be helpful to have an "apply" button set the state to which "cancel" will revert. – supercat Apr 21 '14 at 21:40

In many Windows dialogs, there are multiple tabs. The point of the apply button, in my opinion, is to make changes in one tab and apply them before moving to the next tab.

Suppose user was sure they've made the changes in the current tab. They would Apply those changes, and then move on to the next tab to make changes.

The dialogs are at times very setting-intensive, so I'm guessing that's where the Apply button came from.

From what I've observed, a lot of the users are under the impression that they need to click Apply to apply changes and OK to exit. So, for very little changes like 'Lock the taskbar', they would click Apply and OK, instead of just OK. I think the Apply pattern is a bit misleading for many users. It is also redundant in most cases. Most users don't make a lot of changes. In fact, it'd be best to tone down on many of the settings, and break complex UIs into simpler ones.

enter image description here


Redundancy in interfaces isn't always a bad thing.

Different users may find one or the other. Some are more comfortable hitting the Close box. Others like seeing the button and knowing what it does. Some users will hit Escape, another redundant operation. This is all good, as long as it doesn't clutter the interface too much.

You could remove one of these, but in this case it wouldn't really improve the usability of the dialog box.


The way I see "Apply" and "OK", "Apply" is more like a preview, which allows the user to make changes without the risk of blowing things up.

"OK" is more of things.

  • 2
    Hi sri85, This answer does not seem to add anything that is not mentioned in the existing answers. Could you add more detail and extra information to differentiate it from the existing answers? – Pesikar Apr 3 '14 at 14:12

protected by Community Feb 21 '18 at 9:16

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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