The logic behind having an OK button and Apply button

Question

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?

Answer 1

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.

Answer 2

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.

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.)

Answer 3

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.

Answer 4

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).

Answer 5

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.

Answer 6

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.

Answer 7

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.