Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?
share|improve this question
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
    
@phillipw try closing a document. Clicking cancel on the dialog or close on the dialog does the same thing. –  Joseph the Dreamer 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
add comment

7 Answers

up vote 11 down vote accepted

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 casual vs. business.)


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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
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 at 14:12
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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