Default Examples | Developing User Interfaces for Microsoft Windows

Let's look at some examples.

Open and Save As Common Dialog Boxes

The Open and Save As common dialog boxes are notable for how often their default values are handled incorrectly. The Open dialog box ordinarily should use the last folder and file type (that is, file extension) entered by the user in the program as the default values. Some programs use the program path as the default folder for opening and saving files. This default is almost certain to be wrong, since the program's path is a poor choice for saving user files. Defaults like this are clearly chosen for convenience to the programmer, not the user.

Interestingly, my suggestion is in conflict with the Designed for Microsoft Windows logo requirements. Specifically, the logo requirements suggest that all user files should be saved to the My Documents folder or one of its subfolders. (This can be easily programmed by initializing the lpstrInitialDir member of the OPENFILENAME structure to the path returned by calling the SHGetSpecialFolderPath function with the CSIDL_PERSONAL flag. Setting the default folder for the Open dialog is demonstrated later in this chapter in the section titled "Example Code") This way, it is easier for the user to find files, since they can be found in a centralized location regardless of what program created the file; to access files, since a shortcut to the My Documents folder is on the desktop; and to back up files, since they are all stored in one place.

Unfortunately, rigid adherence to this recommendation ignores one small detail—the user. The very first time a program is run, using the My Documents folder as the initial default folder makes perfect sense. But if the user isn't storing his documents in the My Documents folder, why use this folder as the default? If you set the last folder used as the default, you are providing the user a default folder based on his actual behavior, not his ideal behavior. Following the user's actual behavior is always the right thing to do.

TIP
Provide defaults based on the user's actual behavior.

While using the last folder as the default is simple enough, it isn't always the right thing to do. You have to think about how the program is used. Consider the WinDiff utility included with Visual C++, which is used to compare two files. To compare files, you have to open the first file with an Open dialog box and then open the second file with another Open dialog box. But how is such a program typically used? Whenever I use it, I compare files in one folder to files of the same name in another folder. While I sometimes compare two files in the same folder, that situation is rare. Although comparing files in different folders is common, you would never know it from using WinDiff. When selecting the first file to compare in WinDiff, instead of using the previous first file folder, the WinDiff Open dialog box defaults to the previous second file folder, which is never right. Furthermore, it never supplies a default filename, even though the second filename is likely to be the same as the first. Consequently, comparing several files using WinDiff is infuriating—and only because of its poorly chosen defaults. Every time you compare another pair of files, you effectively have to start over completely.

For the Save As common dialog box, programs that save only a single file type can safely use the last folder and file type for default values as well. However, programs that save several file types should save the last folder used for each file type and select the default folder for a new document based on its file type. Why? Because the folder to which a user saves a file can correspond closely to the file type. For example, in a software project, I generally save the .CPP, .H, and .RC files to the project folder; .BMP and .ICO files to the RES subdirectory; .DOC files to the documentation folder; .RTF files to the help folder; and .HTML files to the Web site folder. The fact that I saved my last file to the help folder is irrelevant if my new file is a .CPP file. Again, using this technique is safe for the logo requirements because no harm is done if the user always saves his files to the My Documents folder.

Handling Default Groups

Usually settings can be handled individually, but sometimes it makes more sense to handle them as a group. That is, the value of one setting can determine the default values for several other settings. Consider a personal finance program that helps you write checks, such as Microsoft Money. The check's date should default to the current date (as all date fields should), but the default values for all other fields should depend upon the information in the Payee field. Even though you can't know for sure what the amount field should be set to, it is likely to be close to the amount of the last check to the same payee. For mortgage, auto loan, or insurance payments, the amount is likely to be exactly the same for each check to the same payee. For this type of program, selecting default values individually wouldn't make any sense. The amount of the last check is almost certain not to be the amount of the next check.

Using Defaults to Make Features Visible

An interesting use of defaults is to make certain program features visible when a program is first installed. For example, Word defaults to Page Layout mode instead of Normal mode to help the user discover this mode. Word also defaults to having the Office Assistant on so that new users will know this help facility is available. Similarly, Visual C++ defaults to having the Tip Of The Day feature turned on to help new users learn about the program. Lastly, the Windows Paint utility uses the transparent copy mode by default so that users will be aware of it. All users understand what the opaque copy mode does, so initializing to transparent copy mode is a simple way to make the feature visible.

In all these cases, users would have required much more time to learn that the features were available had they not been operational by default. These defaults make important features visible without getting in the way.

TIP
Make carefully selected features visible by turning them on by default when the program is first installed.

Shut Down Windows Dialog Box

This dialog box always uses the last value selected by the user as the default. I don't think this is necessarily the best choice. It makes sense for the Stand By option, since someone that uses the Stand By option is likely to choose that option often. However, if the user restarts Windows, what is the likelihood that the user will want to restart it the next time? I think the best default for all other modes is the Shut Down option.

Saving Files by Default

Lastly, let's examine a default that doesn't have anything to do with settings in a dialog box. Consider software that allows the user to modify files. Using a program that modifies files is unlike any other life experience. For example, when you fly across the country, you are not presented with a choice like that in the following dialog box:

If commercial aviation worked like software, clicking the No button would instantly return you to where you departed from. But if you use Word to edit a file for eight hours and click the document's close button, you will be presented with the same choices. Why? While this confirmation gives equal weight to the yes and no options, it is almost certain that the user will want to save the changes. After all, if the user didn't want to save the changes, he wouldn't have made them in the first place. If the user accidentally clicks the No button, he is going to be pretty upset. This problem begs the question: is it really necessary to ask?

Of course, software uses this file model for some particular reasons. The first reason is that this is the way software works. All changes are in memory and are not saved until they are saved to disk. Another reason is that requiring an explicit save means that the user can experiment without fear since any disastrous or otherwise unwanted changes can be easily abandoned. But since this file model is so unusual, beginning users have a difficult time with it. Advanced users probably don't care one way or the other.

Some programs do directly save changes. If you accidentally blast a setting in the registry using RegEdit, you are out of luck. This makes major registry changes using RegEdit a bit scary. (Where is the vital Undo command?) Similarly, any changes you make in Microsoft Outlook are saved to disk when the program exits.

If you want your program to use a more natural file-handling model, you can make two simple changes. First, your program should always save files by default. It is essential to eliminate the file save confirmation because the unnecessary confirmation is the problem. Don't bother asking; just do it. Second, your program needs an Abandon All Changes command so that in those rare cases in which the user does want to abandon changes, the program can simply reload the original document. Everything else in the program, including the typical Save and Save As commands, can remain as is.