desktop application - The logic behind having an OK button and Apply button

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

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.