Don t Surprise the User
While you want to minimize the effort required of the user, make sure you do so in a way that the user expects. The Print Setup common dialog box is a good example of when not to change the default settings to the last selection. Although you certainly want to use the last printer selected and the last page orientation, you should never change the default number of copies to print or the default page range. Your typical user will want to print one copy of all pages unless he explicitly selects otherwise. While he may have printed 47 copies of a document last time, this is almost certain to have been an anomaly. Also, safety should be a consideration. Defaulting to a single copy is risk free, but defaulting to 47 copies is not.
TIP
Consider safety when selecting default values. Never use a default value that would surprise the user.
For another example, suppose you are designing a stock-trading system where the user enters trades and then submits them. A trade action command allows the user to either buy or sell, and it has a simple dialog box that might look like this:
You could argue that once an initial selection is made, the only thing the user can do with this dialog box is toggle between the buy and sell options. Instead of setting the default to the current option, you could set the default to the opposite of the current option. That way if the user had initially entered a trade to sell 1000 shares, the next time the dialog box is used you could select the buy option by default. Then the user could select OK to change the trade action or Cancel to leave it as is. If the default setting were set to the current option, the user would always have to explicitly change the selection, requiring extra effort.
While this technique would save the user a little effort, it definitely isn't what the user expects. The user expects that clicking the OK button without explicitly making any changes is the same as clicking Cancel. During a panic sell, the user might display this dialog box accidentally and press OK to dismiss it. Now instead of selling 1000 shares, the user has bought 1000 shares. Surprise! Furthermore, if the user really did want to buy, the user expects that clicking the Cancel button in an unmodified dialog box should result in the state indicated by the dialog box. Since the dialog box is initialized to a buy, the user expects clicking Cancel to result in a buy, not a sell. Handling a dialog box this way will completely confuse the user.
TIP
Dismissing an unchanged dialog box with the OK button should have the same effect as dismissing it with the Cancel button.
Make sure that an activity that has significant consequences requires explicit selection from the user. While this might require extra work, an explicit selection makes the change obvious. Potentially destructive or disastrous actions should never result from the default. The default command button on a dialog box or message box should never result in an action that is irreversible or destructive. Such defaults are neither cool nor appropriate.
TIP
Make sure that an activity that has significant consequences requires explicit selection from the user. Disastrous actions should never result from the default.
This same concept also applies to property sheets. Property sheets, as well as dialog boxes that are effectively property sheets in that they show the state of an object, should always reflect the actual state of an object, not what you expect the user to want to change it to. While it is appropriate to save the user effort by creating a new object with default values that are based on previous input, dialog boxes and property sheets that show the existing state of an object must always be initialized to its actual state—regardless of the user's previous behavior. This is what the user expects.
TIP
Property sheets should always reflect the actual state of an object.
