Fog Creek Software
Discussion Board




OK Cancel Apply

I am working on the Options form of an app and most changes take effect immediately.  i.e.  Toolbar\Pane Visibility, etc.

It occured to me that Cancel may be redundant.  What is the conventional wisdon re:  allowing a Cancel?

Thanks,

OTOP

Our team of programmer
Tuesday, July 08, 2003


How is it redundant?  What if the user makes several changes, then changes his mind?  If there's no Cancel, he must manually revert to the original state, then click OK.

Jason
Tuesday, July 08, 2003

Take a look at the display properties in Windows. If you change something and Apply, this does not disable the Cancel button. You could still make more changes and choose Cancel, however Cancel does not cancel changes already applied.

I have seen applications that change the caption of the Cancel button to Close after Apply. It would have to change back to Cancel if further changes were made but not applied, though. It's still not obvious what's going on, and I generally don't like the idea of changing button captions around like that.

I don't think it's too hard for the users to figure out. As long as there is nothing in the dialog that is irreversible, leaving Cancel enabled all the time is fine.

Another option is a Preview button which applies updates temporarily, but still requires the user to choose OK to permanently apply the changes, and reverts to the pre-dialog state if Cancel is chosen. That wouldn't break the OK/Cancel paradigm. Yet another variant of that is a Preview checkbox that updates the application immediately when options are changed.

Big B
Tuesday, July 08, 2003

But if the changes are visible and immediate, Toolbar visibility for example, why is that a bad thing?

No need to confirm the changes, i.e. click OK, they already happened.

Our team of programmer
Tuesday, July 08, 2003

BB

Preview is interesting.

I guess I'm questioning the reason for the confirmation in the first place.  How often do users change more than one thing at a time and why would they not like to see the changes occur?

This would allow any not so obvious options to be seen (learned) immediately.

I guess I could add a:

      Do you want to save the changes?

dialog.  J/K <g>

Thanks

Our team of programmer
Tuesday, July 08, 2003

If you're going to get rid of one button, get rid of apply. I've never understood that for modal dialogs, and almost never use it. Better to have changes take effect immediately, allow the user to say 'ok' that's what I want or 'cancel' I didn't mean that.

mb
Tuesday, July 08, 2003

If we're really talking about trivial user interface preferences, I agree that simply applying updates immediately is fine. A standard for such dialog boxes is to have just one button called Close.

I think you must have been joking about the confirmation dialog box. Just making sure.

Big B
Tuesday, July 08, 2003

Yeah, J/K == just kidding, but you knew that.

I'm going to test Close and see what happens.

Thanks

Our team of programmer
Tuesday, July 08, 2003

mb - regarding getting rid of "Apply" - think of a font setting dialog. In my experience, even on modern machines changing the font takes a moment to apply. So if I want Arial, 10 point, italic for something:
1) I can't arrow through the font list, because "insta-effect" means each time I change the font I have to wait for it to take effect.
2) I have to sit through at least two complete refreshes (Arial, then 10 point) before I can be done with the dialog.

Ditto any options dialog where I may make several changes at once...

Philo

Philo
Tuesday, July 08, 2003

When I have an Options box in which changes take place immediately, I have two buttons, Revert and Default. I don't have Cancel, Apply, or OK. Closing the Options dialog is done by pressing the close button. I suppose you could have a close button too but then the user might wonder if the close button meant Cancel.

The distinction here is that you're not cancelling but reverting when the changes have already been made. You can cancel an order before its been fulfilled, but not after.

X. J. Scott
Tuesday, July 08, 2003

Oh the other distinction is that cancel should close the window, but revert leaves it open.

X. J. Scott
Tuesday, July 08, 2003

Ack, I am being confusing with my use of the term close button. What is the iconic close button in the window bar called? A close box? I mean to say that I always have the close box available, but not close button with a text label in the body of the window.

X. J. Scott
Tuesday, July 08, 2003

XJ - The (X) close button, whatever it is called, maps to the Cancel action by convention (same as the Esc key should.) I would assume that hitting that button would not apply my changes.

What you're doing will work, but is very un-Windowsish. If I needed a way to restore the default settings, I'd add a button saying "Restore Default Settings." The Windows way to "revert" is to Cancel, then re-open the dialog.

Big B
Tuesday, July 08, 2003

I think Apply mildly sucks. I think Apply and Cancel together really sucks


I would

1. Stick to OK and Cancel. They meaning is obvious: close the dialog and either OK and cancel the changes

or

2. Use Close if changes occur immediately on making them. 

or

3. use Close and Apply (or Close and OK) if the user must do some action to implement a change

AND

Wherever possible/reasonable regardless of input type, type to offer an Undo option.

Wherever possible, I'd try to do type 1 or type 2, and avoid type 3. 


**BUT**

Never combine Apply with Cancel.  The problem is it is not obvious whether Cancel backs out all the changes, the last Apply's changes etc.

S. Tanna
Tuesday, July 08, 2003

> use Close and Apply (or Close and OK)

should be

use Close and Apply (or OK and Apply)

S. Tanna
Tuesday, July 08, 2003

I think you guys are thinking about this too much. All I know is that for dialogs where a user might want to "fiddle" (usually things that govern appearance, like colors or font) you really should have an "Apply" button, so the user can "try and see" - Windows colors dialog has this (nice), VB/VS.Net font setup doesn't (which has always sucked)

Other than that, go with the Windows guidelines and move on to coding something else.

Philo

Philo
Tuesday, July 08, 2003

The changes take place immediately. We can therefore get rid of Apply, since its functionality is nil.

If Cancel will reset the environment to their pre-dialog settings. it's not really a "cancel" -- it's a "revert". So change the caption to Revert. If Cancel will NOT reset the environment, then its functionality is nil as well.

Lastly, if OK doesn't confirm the changes, but merely closes the dialog, it is a Close button.

Bottom line: You want only a Close, or perhaps a Close and a Revert.

Zahid
Tuesday, July 08, 2003

OK = Accept changes, close dialog
Cancel = Reject changes, close dialog

As the changes are instant, you are right in not having Apply. It wouldn't have any functionality. But typically it should be:

Apply = Accept changes, don't close dialog

As for Cancel post-apply, there is no standard here. Personally, I think it should reject any changes made since the dialog was opened (ie. Undo any changes, including those applied). But others might see it differently. Maybe Joel comment on this someplace in the past.

Marc
Wednesday, July 09, 2003

Microsoft introduced the Apply button in Window 95 but from observation I think that the majority of users have never understood its purpose. They click Apply and then OK.

John Topley (www.johntopley.com)
Wednesday, July 09, 2003

I only use Apply for multi-tabbed dialogs where you want to be able to save as you go along, or see the effect immediately but still have the ability to change, ie not Save and Close.

I don't use Ok at all now, its use is frequently ambiguous to the user, instead I use the verb appropriate for the dialog.  Most commonly that's Save, or Save and Close, but it might also be Add in the sense of actually adding this record, or it might be Send, or Email or whatever else is appropriate.

Simon Lucy
Wednesday, July 09, 2003

John,

Precisely right! My wife is a programmer, yet as many times as I've told her she doesn't need to hit "Apply" before "OK", she does it anyway. It was a TERRIBLE UI decision.

If they'd wanted to have the changes made visible while the dialog was up, they should've done them in real-time.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, July 09, 2003

Apply is for when you need the dialog box to stay open. Miss it out and you have to bring up the dialog box again to make another change. So work out how often that is likely to happen in single tabbed forms.

Stephen Jones
Friday, July 11, 2003

*  Recent Topics

*  Fog Creek Home