The Human Factor: The Top 10 Windows 95 User Interface Design Errors

Tandy Trower

September 12, 1995

Now from the home office in Sioux City, Iowa er...Redmond, Washington, here are the top 10 common UI (user interface) design errors to avoid for applications for Windows 95.

10. Properties...crimes

In a previous Human Factor column ("Menu, Please!", Developer Network News, September 1994), I mentioned that an ellipsis (...) should be used only for commands that require further parameters from the user. These are typically gathered by means of a dialog box, such as the Open command on the File menu, in which a user must specify which file to open.

This means that you shouldn't include an ellipsis for every command that results in a window. In a typical application, an Open command includes an ellipsis because the user must specify a file to open. But the Open command on folders in Windows 95 does not, because a user specifies (through selection) the file before selecting the command.

So the fact that you display a window when the user selects a command is not the key criteria for determining whether to include an ellipsis. Neither is whether a user can change something in the resulting window. A Properties command, for example, displays the properties of a selected object, but the command shouldn't be accompanied by an ellipsis. While a user can use the window and change property values, the user doesn't have to specify which object or which property before the command to "display the properties" can be completed. Similarly, commands such as Settings, Preferences, or Help Topics should not include an ellipsis. While all these commands result in a secondary window and may accept some type of user input, the command does not require additional information to process the command, which is typically just to display the current options.

The right test for determining whether to include an ellipsis is, "Does this command require a user to specify or confirm a set of parameters to complete its action?" If yes (for example, Print), use an ellipsis. For commands where the user has already specified the object or parameters before selecting the command (for example, What's This?) or there are no parameters (for example, About), don't include one.

9. Secondary windows appearing in the taskbar

Taskbar entries (excluding the status area) are only for primary windows. The titles of secondary windows such as dialog boxes, property sheets, and message boxes should NEVER have entries in the taskbar.

A primary window serves as an object's main viewer and is characterized by its function and its appearance. It usually results from opening an icon and is generally independent from other windows. A primary window also includes an icon in its title bar, as well as a Minimize (and often a Maximize) button. Secondary windows are dependent, supplemental windows, such as dialog boxes, property sheets, and message boxes.

That said, you may design primary windows that resemble secondary ones. For example, although it is a primary window, the Windows 95 Find File query window may look very much like a dialog box. However, it fits the test for a primary window, so it is included as an entry (button) in the taskbar.

8. Using Ok instead of OK

Always capitalize both letters. This is the correct English spelling. OK?

7. Including icons in title bars of secondary windows

Icons should appear only in the title bar of primary windows. This means icons should not appear in the title bars of dialog boxes, property sheets, or message boxes.

6. Read-only information displayed as static text or disabled text

Read-only text is typically information that you want users to be able to read, select, and copy, but not change. Present it in normal text boxes (typically with an inset border), but with the background matching a secondary window's background. It should also include support for a pop-up menu (with commands such as Copy or Select All).

Static text is intended for labels and descriptive text in a window. The text appears on the surface of a window (without a frame or border, although it can be included in a group box with other controls).

Disabled (engraved or grayed) appearance is intended only to represent items not currently accessible or available. It should not be used when representing read-only information.

5. Using Exit instead of Close

The Exit and Close commands may sometimes seem synonymous, but they are different. Exit implies quitting a process. Close means removing a window.

Don't assume you should include an Exit command for every window in which you include a Close command. A printer window in Windows 95 includes a Close command, but not an Exit, because you don't want to quit any pending print jobs when you close its (queue) window. Similarly, folders don't include an Exit command. As you evolve your software to be data-oriented, Close is the appropriate command. For example, you Open and Close documents or files, but you don't Exit them.

Similarly, be cautious in assuming that Close is always the equivalent of Cancel. Cancel and Close can sometimes have similar results. However, Close can also have results similar to OK when used in a message box where it is the only button. In addition, if there are pending changes in a dialog box, selecting the Close command should prompt the user whether to apply or discard the pending changes.

A final note about using the Close command. Nothing is more confusing to a user than finding a Close button in the body of a dialog box that operates differently from the Close button in the title bar; for example, if the title bar's Close button operates as Cancel, while the Close button inside the window simply removes the window.

4. Incorrect title bar icon and text

What are you supposed to put in the title bar of your primary window? First, you have to define what that window represents. If it is a data object, you should be using the icon you've defined for the data file type and not your application's icon. For example, when you open WordPad or Paint documents, you find the document file's icon in the title bar.

However, for an application that has no data files, you use the application's icon. Similarly, for objects that represent tools that operate on other files, you also use the application's icon. For example, Windows Explorer and Quick View are both special tools that afford secondary views of other objects. So their icons, rather than the data file's icon, appear in the title bar. Similarly, in multiple-document interface (MDI) applications, an application's icon typically appears in the parent window's title bar, while the data file's icon appears in the child window's title bar.

If the Windows flag logo is showing up on your title bar, you haven't defined or set your icon correctly. Windows displays this icon when it doesn't have the correct information for the title bar.

When you have determined the title bar icon, the title text is easy—the first name in the title bar should correspond with the icon you used. In other words, if you decided that a data file icon fits the model for your application, the name of the data file should be adjacent to the icon, optionally followed by the application's name.

3. Supporting multiple instances

Many users may be confused when opening an already open object and getting a new instance. Therefore, it's better to design your application so that it checks to see if an instance (window) is already open and activates that window (which brings it to the top of the z-order) rather than creating another instance.

If your design requires supporting multiple (primary) windows of the same object, consider warning users that an open instance already exists, and give them the choice of either switching to that instance or creating a new one.

2. Failing to include pop-up menus for title bar icons

The inclusion of the icon in the title bar is not intended as a more attractive replacement for the former Windows 3.1 System menu box. It is intended as an access point to the commands of that icon.

While left-clicking the icon brings up the pop-up menu for the window (formerly known as the System menu), your application should support right-clicking the icon to bring up a pop-up menu that contains commands that apply to the object represented by that icon. (Of course, right-clicking anywhere else in the title bar should bring up the pop-up menu for the window.) Typically, this will be a subset of the commands (such as Copy, Create Shortcut, Properties) found on the pop-up menu of the icon that a user opened, but it may also include commands such as Save, which apply to the object's open state but which may not apply to the closed state. For example, your application may not be able to support a Cut command on an open document file, so while the command may appear on the file icon's pop-up menu, you would not include it on the title bar icon's pop-up menu.

And the Number 1 design error to avoid is...failing to register

Last issue's Human Factor column ("Lemme See Your Registration," Developer Network News, July/August 1995) covered the registry, but I want to reiterate that failure to register your file types, primary verbs, OLE information, and icons will certainly make your application's UI seem poorly integrated with Windows. It typically isn't an issue of whether your application will run or not, nor is it intended to enforce some rigid standard. It is a matter of taking advantage of the system's facilities to operate compatibly with the conventions users will expect.

Shameless promotion

Everything I've covered here is detailed in the new UI guide, The Windows Interface Guidelines for Software Design. This latest, greatest set of UI recommendations for designing applications targeted for Windows 95 is now available from Microsoft Press.

Tandy Trower is the director of UI design at Microsoft. Having finished The Windows Interface Guidelines for Software Design, he's hoping to promote the book on Oprah and Letterman soon, but they keep ignoring his calls.