Last month, Caroline Jarnett presents a not too uncommon problem of what the Cancel button should do in a tabbed dialog –should it cancel all changes to the dialog box, or just the changes to the current panel? Her answer: the button does what it’s labeled to do:
If the button cancels the window, removing all changes then it should be labeled … “Cancel and remove all changes.” …If the button cancels the changes on the current panel then we should label it: “Cancel the changes on this panel” (or whatever users say when they describe what it does).
Slick. Solving the problem by solving a different problem than the one stated. Rather Normanesque. Longer, more descriptive labels have their place, especially for unusual actions and/or novice users (e.g., a web app, where standards are lacking or cannot be trusted). In some applications, just adding a single word to a label can make all the difference. Take for example this fictional dialog:
If there were a button that said “Default” we may not know what to expect. But if it said “Default Options” or “Default Duck” or even “Default Actions,” ambiguity would be reduced.
Problems with Long Labels
But there is a disadvantage with a longer label. It takes time to read, and even experts better read it because the very fact that it is long tells them that it is doing something non-standard that needs explanation (e.g., maybe it’s going to say “Cancel and email suggestive photos to your boss”). Even worse, when the caption is too long, even new users tend to skip right over it, defeating the entire purpose of a long caption. Loading your UI with lots of documentation is a great way to overwhelm your user. On the other hand if the user sees a “Cancel” button, they know at a glance it means revert-to-what-things-were-and close-window-never-mind. That’s a lot of words effectively communicated by six letters.
If you are going to use longer labels, you are almost certainly using a nonstandard label, so you most definitively need to gather data from users to get the wording. Jarnett’s suggested labels above, for example, may be easily misinterpreted. “Cancel and remove all changes”: define “all.” All changes I made since I opened the window? All changes I ever made in the window? All changes in my document too? “Cancel the changes on this panel”: what’s a “panel”? The only way to know is to test, and there’s no guarantee you’ll find a clear winner.
Communicating by Proximity
Well, if you have to study the users to get the wording, you might as well study the users to look for an alternative that doesn’t have the disadvantage of slowing users down. Often graphics or layout can be employed to more effectively set expectations than words. Among the most powerful means to do this is proximity: associated controls are placed close to together. Graphic borders or frames may also be used to reinforce the association. In this case, I would think user expectations would depend on the placement of the button. A button in the panel or frame affects only the controls in that panel or frame. A button outside the tab control in the window margin affects the entire window. Compare the following placements of a Default button:
The advantage of this approach over long button captions is less visual clutter and reading to slow the user down. At a glance the functionality is indicated without little or no conscious thinking. One picture equals one kiloword.
But What about the Cancel Button?
Well, first of all, a button labeled “cancel” by standard reverts all changes and closes the dialog. By considering the capabilities and principles the UI should support, it’s clear what Cancel does and where it should be placed. If Cancel were to revert only the current panel, how does a user revert another panel in addition to the current panel? They can’t, because the Cancel button closed the window. If you designed the dialog that way, you’d have made an internally inconsistence and intolerant UI: it requires explicit user approval from some changes, but not others; it fails to provide a complete undo capability. Bzzz. I’m sorry, thanks for playing.
So the answer must be that a Cancel button reverts all changes on all panels before closing the window.
But what if user testing indicates you should have a capability to revert changes on an individual panel? Well, first of all, that might be a sign that you should have each panel be a separate dialog, rather than stacking them all in one with a tab control. But if you keep the tab control and need to revert individual panels, then the button is labeled “Reset,” and it should not close the window. You can have a Reset button on each page along with OK-Cancel in the margin. If you have Cancel (“don’t apply anything, whether I changed anything or not”), you have to have OK or equivalent (i.e., “take these (remaining) inputs and apply them”). Or, if this is an “instant apply” dialog box, where changes are immediately represented in the underlying primary window (not a bad idea for Options, by the way), then you can get away with just a Close button.
Cancel or Reset. So I guess Jarnett is right. The button does what it says it does.