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.