Chapter 1

Sometimes programmers think of user interface design as a purely cosmetic exercise. They believe the real guts of a program is its feature set and performance level. however, creating a good user interface is of the utmost importance. The best features in the world will be ignored by many users if they are difficult to find or cumbersome to use.

The user interface is your primary mode of communication with the user. Like other forms of communication, whether your ideas will be appreciated depends on how well they are presented. With a good interface design, your program can be efficient and user-friendly. This chapter discusses how to design interfaces with the work habits and learning styles of different kinds of users in mind.

Interface design in Visual Basic is largely a matter of dragging and dropping various icons into place and making them work together. The goal of this chapter is to give an overview of good design, rather than explaining in great detail how to set properties and write code for various controls. We will cover the following:

• Designing with the user in mind
• When to be innovative and when to be traditional in interface design
• Standard formats for menus and dialog boxes
• Choosing the right controls for the right tasks
• How to determine if your interface design really works

Understanding a Good User Interface

There are certain elements that good user interfaces share, even in very different environments. Keeping these in mind as general goals will help you empathize with the user and will put the specifics of interface design in Visual Basic into perspective.

The successful interface designer learns to see a program from a very different vantage than the norm: that of the user. It can be difficult to put yourself in the shoes of naive users and try to anticipate their needs and the potential pitfalls they will encounter. This is particularly true since, as a programmer, you are several steps removed from most users in terms of computer expertise.

Compounding this difficulty is the fact that programming is an exercise in explaining things to the computer. Programmers are used to organizing according to the logic of the computer, rather than the logic of a user. Objects that are alike to the computer may not seem so to the user and vice versa.

Consider a typical user's desktop in the Windows 95 environment. Graphical objects representing entirely different types of data and commands are presented side by side. Application shortcuts, folders, documents, the recycle bin, a printer icon for drag/drop printing, and the taskbar can all occupy the desktop simultaneously. From the computer's point of view, these objects are not only unrelated, they aren't even in the same category. Programs, files, folders, commands, and other objects are all presented together on-screen. An icon that launches a program and one designating the Network Neighborhood sit side by side, as if they are in some way equivalent. In terms of the internal organization of the computer, this makes little or no sense. Now, consider it from the user's point of view. The user wants commonly used files, tasks, folders, and commands to be easily accessible. In terms of the user's work patterns, it makes perfect sense.

This philosophy can be transferred to many elements of program design. Examples include choosing items for a toolbar, organizing menus, and designing a dialog box. All aspects should try to reflect the way the user works rather than the way the program was written. Keep in mind, however, that users have become accustomed to finding certain things in certain situations. Relocating standard commands is not a good idea. The Print command belongs on the File menu, regardless of whether it seems more appropriate to include it on another menu. Leave the major interface revisions to the industry giants.

Visual Appeal in the Long Run

There is absolutely no question that the look of a program affects its popularity. When Windows 3.0 was released, most users were thrilled with the three dimensional buttons that looked like they were being pressed. Screen saver programs are a perennial best seller, despite the fact that simple ones come free with Windows. Users are interested in having programs look nice.

On the other hand, programs that employ non-standard graphic elements can work against a user. It is frustrating to learn a program with new and unfamiliar dialog boxes or buttons that don't look like buttons. Also, fancy graphics and animation that slow down the performance or loading time of an application are generally not worth it unless they serve some other purpose.

The design goal, then, is to produce an interface that is attractive, conforms to the standards of the Windows environment, and uses graphics in a way that enhances the usability and appeal of the program.

Learning Ease and Efficiency

For almost any program, there are different types of users to be considered. The new user wants an interface as simple and self explanatory as possible. Ideally, the menu and command names should make it obvious what function they perform, and the interface should mirror other Windows applications so that objects can be found in their expected places. Keep in mind that it is not only the brand-new user, but the experienced, occasional user as well who will need an interface that requires little or no memorization.

On the other hand, the proficient or power user wants to interact quickly with the program. If he is typing and needs to use a command, he doesn't want to have to reach for his mouse. The screen should not be cluttered with icons that reduce his work space too much. Frequently used menu commands should have short-cuts to reduce the number of keystrokes or eliminate the need to use the mouse.

Balancing the needs of both kinds of users can be challenging. However, some of the elements of a good UI design are beneficial to everyone. Good menu and dialog box design allow the beginner to see which aspects of an application are essential while providing the power user with clear routes to take to delve more deeply into the more advanced features. Good organization in your menus and dialog boxes will blaze a trail for the user, making it easy to determine which path to choose to find a feature and how to return to an earlier position without making changes.

Allowing the user to customize the program helps to address different levels of expertise. When you create a highly customizable program, however, you need to create it so that the initial installation is one that is appropriate for the beginning user. Remember, it may be a while before the beginning user learns how to customize a program, while the advanced user will quickly seek out the Options or Preferences menu commands and start changing whatever settings she can to brand the application as hers! Examples of good customization options are: menus that allow items to be added or removed, View options that allow palettes, toolbars, and other windows to be made visible or invisible, and user definable shortcuts.

There are no strict laws to finding the balance between ease of learning and efficiency; your options depend on the particular application. Just remember to keep the needs of your users in mind.

Allowing Users to Make Mistakes

One of the great advantages of the Windows environment is the ability to learn new software by exploring. Rather than being faced with a command line prompt with no idea of what to type, the Windows user can browse through menus and dialog boxes, seeing what commands are available and trying them out. Your programs should both encourage users to take this approach and protect them from damaging data or painting themselves into corners. When users make mistakes, your program should be forgiving enough to allow them to correct themselves.

Some ways to make programs allow for user mistakes are as follows:

• The use of a confirmation dialog box whenever the user invokes a command that involves deleting or overwriting data
• Not providing shortcuts to "dangerous" commands
• Making it clear how to exit a dialog box without making changes, usually with a cancel button
• Providing a full featured Undo command that will reverse the last action taken

Designing Main Application Window

Almost every program has a main application window. It serves as the home base for all actions taken. Visual Basic takes care of some of the more tedious aspects of designing the window. Scroll bars, title bars, and sizing controls are all produced automatically. Your task is to add the features and controls that are specific to your application.

Figure 1.1 shows a simple text editing application. The main portion of the screen is a the area for the user's work. From the top down, you see the title bar, menu bar, and toolbar. On the bottom, is the status bar.

Fig. 1.1 The parts of an application window.

The title and menu bar are necessary features for almost any application. For most applications, you will want the main window to be sizable. If you want to give your user a larger work area than the screen provides, scroll bars can be added. For your main application window, you'll generally want to use the default control menu and max and min buttons. All of these features are shown in figure 1.1.

Toolbars and status bars are an addition to many applications. Frequently used menu and dialog box choices can be included on the Toolbar and information about the current state of the application along with some basic online help can be given on the status bar.

Toolbars

Toolbars are the result of a kind of grass roots software movement. More and more software designers included them in their application. Microsoft finally took the hint and included a Toolbar control in most versions of VB 4. There was nothing to bar the programmer from creating Toolbars from scratch in earlier versions of Visual Basic, but the new Toolbar control provides a standard look and a great deal of built in functionality. For VB versions that do not include the Toolbar control, you can still create them from scratch.

There are many different customization options that you can offer in conjunction with Toolbars. For tool heavy applications, you can create different Toolbars and allow the user to select which ones to display. The individual Toolbars can be made customizable as well.

Note: The Toolbar control also includes Tooltip functionality. Tooltips are the small text boxes that pop up when you leave the mouse pointer on a Toolbar icon for a second. They are an excellent and unobtrusive way to provide context-sensitive help to the user. If you include Tooltips in your application, include an option where they can be disabled as well, since some advanced users may find them distracting.

Status Bars

The status bar is a good place to present helpful, but non-essential, information to the user. In Fig 1.1, for example, the status bar indicates the total number of pages and the current page, as well as whether or not the document has been saved. Avoid putting essential information here because many users don't notice the status bar at all. Never use the status bar as a substitute for alert dialog boxes.

Note: With all of the various bars taking up screen space, allow the user to choose not to display them in order to get a larger working area. Be careful about hiding the menu bar, however, since users may not remember how to get it back.

Exploring Menus

Menus are the roadmap to your application. When looking at a new application, most users will go right for the mouse and start clicking on menus to get a feel for what the software does and how it is organized. Menus can make a program easy to use and efficient, or they can make navigation a chore. Poor menu design will frustrate even the most advanced users. For example, users may remember a command for changing the default directory but must search through the Preferences, Options, and Settings dialog boxes to find it.

Experienced users are conditioned to expect some standard features in menus. You should strive to conform to these standards of menu names, contents, and shortcuts. Menus are not the best place to become creative. You may have extensive user testing to prove that "Write File" is a more descriptive command than "Save" but those familiar with other programs will curse you for such ingenuity. Almost as important as familiarity is conforming to the standard shortcut keys. Keyboard oriented users expect to zoom through options they know (pressing Alt+F then X to leave a program, for instance) without needing to learn new conventions for each program. The most common standards are shown in figures 1.3, 1.4, and 1.5 shown later in this chapter.

For less standard options, including those that are specific to your program, careful thought should be put into menu organization, menu titles and item names. Both the new and experienced users should be considered. Concise, well organized menus can keep the choices from being overwhelming for the novice and provide obvious routes of progression to the user who is ready to explore the more advanced options offered in dialog boxes. On the other hand, making the menus too concise can later trap the user in excessively complicated dialog boxes.

Adding to the complexity but providing excellent functionality in the right situations are additional menu formats: cascaded and pop-up menus. Used correctly, they can be of great benefit to more advanced users who will understand how to use them. However, they have a tendency to be awkward to use or even go unnoticed by novice users.

Creating and Organizing Drop-Down Menus

Menu organization has the following components:

• What menu names to use and where to place them
• Deciding which items to include in menus
• Choosing menu item names
• How to organize the items within a menu

When choosing menu names, first and foremost consider the established standards. All programs, even if they don't write or read files, must have at least one menu with the minimum requirement being an Exit item in this menu. In most applications, this is called the File menu. For applications that do not involve files, this menu is often given another name, such as Game or the name of the program. Whenever possible, use the name File for this menu, even if it means "cheating" a little for applications that don't use files, since most users will expect to use the Alt+F mnemonic to access the first menu.

Any program with Cut, Copy, and Paste commands or an Undo command needs an Edit menu. MDI programs should have a Window menu, and every program should have a Help menu. Even if you do not provide online help, the Help menu should contain an About... item leading to an About dialog box.

Note: When creating a Window menu for an MDI application, just check the Window List box in the Menu Editor dialog box. Visual Basic will automatically add a separator bar and a list of the open documents to the bottom of the Window menu. Giving a menu the name "Window" automatically activates this feature.

There are also standards for menu positions. The control menu is placed on the far left of the title bar by the system. Visual Basic takes care of this automatically. The first named menu should be File, then Edit and View if used. The last menu is always the Help menu. The Help menu used to be placed to the far right of the screen, but now should placed like the other menus as the rightmost one. In a MDI application, the Window menu should immediately precede the Help menu. There is leeway for the placement of other menu names but some rough guidelines can be obtained by looking at a few of software best-sellers. Figure 1.2 shows a MDI application with a maximized child window (note the two control menu icons). The figure displays good menu names and placement.

Fig. 1.2 Standard menu placement and menu names.

Some menu items have become standard in name and placement. Figures 1.3, 1.4, and 1.5 show typical File, Edit, and Help menus.

Note: A menu item that leads to a dialog box must be followed by an ellipsis ("..."), as seen in the Open and Save As items in figure 1.3.

Fig. 1.3 The typical File menu.

The underlined mnemonic characters and shortcut keystrokes are discussed later in this chapter in the "Shortcuts" section.

Fig. 1.4 The typical Edit menu.

Grouping similar menu items together and then using a horizontal separator line helps the user in a number of ways. First, it makes it easier to assimilate a large amount of data at once if it is organized into smaller sections. Second, the user will be able to better understand less familiar commands by analogy if they are grouped with more familiar ones. Note the placement of the separator bars in figures 1.3 through 1.5.

Fig. 1.5 The typical Help menu.

Naming original menu items is an art. What seems to be a completely self explanatory name to a developer can mystify a user. Strive for names that are descriptive and unambiguous. Having different items in the same menu called Options and Preferences is sure to confuse.

Note: When presented with a situation of too many similar sounding names or several items that belong together but seem to make a menu too long or confusing, consider the option of a tabbed dialog box. One menu item can lead to a dialog box with several different tabbed pages. This design also allows the user to browse the different options much more easily than having to back out of a dialog box and choose another menu option.

Using Cascaded and Pop-up Menus

Cascaded menus appear adjacent to a standard drop-down menu when items marked with a right pointing triangle are selected. Pop-up menus appear when the user clicks the right mouse button (for right-handed users) over an area that has a pop-up menu associated with it. Both add versatility and can be time-savers for the advanced user, but neither is without its drawbacks.

To create a cascaded menu, create the main menu item in the menu editor. Then, list the items you wish to appear on the cascaded menu indented a level. Figure 1.6 shows a cascaded menu being defined in the menu editor.

Fig. 1.6 Defining a cascaded menu with the menu editor.

Cascaded menus are considered a standard interface feature and their extensive use in the Start Menu on the Windows 95 taskbar has made users more comfortable with them. They are, however, more awkward to manipulate than drop-down menus, both for mouse and keyboard users. Multiple layers of cascaded menus are generally not a good idea. Users will find themselves running out of mouse space making it difficult to navigate back and forth between levels. When having a hierarchy of commands is desirable, consider using a tabbed dialog box or creating an additional menu to group commands. Cascaded menus can be very useful if kept manageable and short and are good for picking tools, colors, and fonts. Figure 1.7 shows a well-implemented, single-level cascaded menu. It is the one that was defined in figure 1.6.

Fig. 1.7 A single level cascaded menu.

Pop-up menus are useful as a supplemental way to get to features offered elsewhere. Because of the infrequent use of the right mouse button, many users will never realize that pop-up menus are available so it is important that they only duplicate functionality available in other menus, command buttons or dialog boxes. Windows 95 uses the right mouse button far more than any previous version of the operating system, however, so your pop-up menus will be found and appreciated by many users.

Because of their context sensitivity, pop-up devices are wonderful for frequently used commands on certain objects. A pop-up menu that gives formatting options for selected text is a good example of an effective use. Figure 1.8 shows such a pop-up menu. Notice the position of the pointer; the menu appears at the pointer when the right mouse button is clicked.

Fig. 1.8 A pop-up menu.

Visual Basic includes several standard pop-up menus for different controls. The one shown in figure 1.8 is automatically generated for text boxes. Check to see what VB has included for a control before creating a pop-up menu of your own.

Pop-up menus should be kept short: around eight items or fewer. The most useful implementations provide shortcut to commands that are used immediately following a mouse operation such as selection. Then, rather than having to move the mouse to the menu or switch to the keyboard, the user can keep the mouse stationary and simply click the right mouse button to access the desired command.

Note: Most pop-up menus don't appear as drop-down menus. When this is the case, create a menu in the menu editor with the Visible property unchecked. The menu title will not appear in the pop-up menu, but the items of that menu will appear when the menu is called as a pop-up in your code.

Both pop-up and cascaded menu items can lead to dialog boxes. Remember that these menu items should be followed by an ellipsis, just as in drop-down menus.

Changing Menus at Runtime

There are several ways that menus can change while an application is running. Menu items or even entire menus can appear or disappear, items can become grayed, indicating they are not currently available, or a check mark can appear alongside menu a item to show it is selected or active. These changes can occur in response to a user action, or they may be induced deliberately when the user customizes a program.

Menus can disappear when their context is not relevant. Many MDI applications will drop-down to just a File and Help menu when all documents are closed. Some applications will use one window for very different modes and have different menus as appropriate. For example, a game might use the same window for playing and later to display the high scores. While the high scores are being displayed, the Weapons menu could disappear. Only cause menus to vanish when the reason for their absence is wholly apparent by the current circumstances. If nothing is in your Clipboard and nothing is selected, don't make the Edit menu disappear just because none of its commands are currently useful. Frustrated users will remember a menu title or menu item and go hunting for it.

An alternative to removing menus or reducing their contents is to disable choices when they are not available. The user will see that the choice exists but is not currently available. Figure 1.9 shows an Edit menu with the Cut and Copy items disabled. When options are not available, they should be dimmed to avoid the confusion of selecting an item and seeing no results.

Fig. 1.9 Dimmed menu items indicate commands that are not currently available

It has become nearly mandatory for MDI applications to include the four most recently used documents in the File menu. The File menu in figure 1.3 gives an example of this. The application must recall these documents after it is closed, so this data must be stored in a separate file. If your application has an *.ini file, this is a good place for it. This is a different feature than the Window menu which will list all currently open documents, as opposed to the most recently used ones, and which can be implemented automatically by checking the Window List box in the Menu Editor.

Many applications allow users to customize menus. Being able to add commonly used fonts or remove infrequently used commands can help the user become more efficient with the program. Be careful not to give the user too much control, though. Imagine a user removing all useful menu items and then also removing the menu item that leads to the customization!

Note: To allow the user to add menu items at runtime, create the menu items in their proper places with the visible property set to false. When the user invokes the command to add the menu items, change the visible property to true.

Finally, menus can change by modifying names or putting check marks next to options to reflect the current status. For example, "Undo" can change to "Redo" immediately after the Undo command is selected, or formatting commands like Bold can be checked to indicate they are currently selected.

Keep in mind that the object is to provide helpful information to the user and then ask yourself, or better yet ask a user, if these changes in the menus are helpful and not disorienting.

Dialog Boxes

Dialog boxes are the primary way an application presents information and solicits feedback from the user. The very name "Dialog" suggests an ongoing conversation, and in the familiar context of the Windows environment, the user expects dialog boxes to be where most information exchanges take place. If the menu structure is the roadmap of your application, the dialog boxes are the primary destinations.

Dialog boxes appear in a variety of circumstances. Menus do not provide enough space to list all possible alternatives, and a dialog box can be presented upon selecting a menu item. To indicate that further options follow a particular menu selection, the item command must be followed by an ellipsis. Thus, selecting a menu item entitled "Print" will cause the print job to start immediately. Selecting an item called "Print..." will bring up a Print dialog box.

Note: When a dialog box is called through a menu item, give the dialog box the same name as the menu item. When necessary for clarity, the menu name can precede the name of the menu item. For example, the dialog box called by the Page... item of the Format menu can be titled Page or Format Page.

The simplest dialog boxes are ones that solely provide feedback to the user. These appear when the application wishes to alert the user of some status change (such as a file transfer completed). Other dialog boxes can ask the user to make a simple choice in response to a command. For instance, clicking Close without having saved the latest revisions of a document should always produce the familiar "Do you want to save changes to..." dialog box.

Visual Basic provides you with several ways to implement dialog boxes. The easiest is to use the MsgBox or InputBox functions. Although limited in scope, they are extremely handy and can be used to keep the user informed or solicit simple decisions or information. Often, much more is required in the way of user input. A File Open dialog box, for instance, requires many controls and quite a bit of code to implement. Fortunately, the Common Dialog control allows a quick way to create five commonly used dialog boxes: Open, Save As, Print, Font and Color.

Modality

Some dialog boxes require you to take action within the dialog box before returning to the rest of the program. Some allow you to have the dialog box open while performing other tasks. This attribute is called modality.

A modeless dialog box allows the user to perform other actions while the dialog box is present. Typically, the dialog box remains on the top layer, though, so that it is not obscured by other parts of the application. A good example of this type of dialog box is a Search/Replace dialog box in a word processing application. It allows the user to edit the text without first closing the dialog box.

An application modal dialog box requires that the dialog box be closed before any action can be taken within the application. A system modal dialog box requires that the dialog box be closed before any other action can be taken at all.

The order of preference for choice of modality is: modeless, application modal, system modal. Use the least degree of modality whenever practical. System modal dialog boxes should be saved for data or system stability endangering situations.

MsgBox and InputBox

There are a host of situations for which the InputBox and especially the MsgBox functions provide a quick and easy way to give information to or request information from the user. MsgBox can be called as a function or a statement. Use it as a function when you need to get a response from the user. InputBox is always used as a function and the value it returns is the text entered by the user into its text box.

MsgBox can be used simply to display information such as warnings, alerts, simple "About this Application..." information, and error messages. These typically contain a single OK button and it is implied that no action is being taken; pressing OK acknowledges that the user has read the message.

The MsgBox function is far more versatile than this, however. It can be used to solicit information from the user. Upon selecting Close, the MsgBox function can generate a confirmation dialog box like the one shown in figure 1.10. It will return a numeric value to indicate which button the user pressed. Appropriate action can be taken based on the user's choice.

Fig. 1.10 A confirmation dialog box created with MsgBox.

Message boxes have several options that can be specified when the function is called. You can define which buttons to include and which to use as the default, what icon to use, and the level of modality.

The options for MsgBox each have a numeric value. To use several of the options, simply add the values together. For instance, to call the message box displayed in figure 1.10, use the statement:

UserAnswer = MsgBox("Do you wish to save changes before_ 
closing?", 51)

The 51 is equal to the sum of 3 and 48 where the 3 indicates you wish to use Yes, No, and Cancel Buttons and the 48 produces the exclamation icon. The default button is the first and the dialog box is application modal because higher values weren't added. If no value is specified, the message box defaults to 0, which produces an application modal dialog box with an OK button and no icon.

The various options for MsgBox are listed in Table 1.1.

Table 1.1 Table 1.1 Various Options for MsgBox

Option             Type           Number Use

Buttons             0                 OK
                        1                 OK and Cancel
                        2                 Abort, Retry and Ignore (especially useful for error trapping)
                        3                 Yes, No and Cancel
                        4                 Yes and No (forces a decision from the user)
                        5                 Retry and Cancel

                        16               Stop (for critical problems)

32 Question (can often use exclamation instead)

[EXCLAMICON] 48 Exclamation

[INFORMICON] 64 Information (accompanied by an OK button only)

Default Buttons 0 Makes the first button the default
256 Makes the second button the default

Modality 0 Application modal
4096 System modal (use very sparingly!)

For more readable code, you may wish to use constants rather than numbers for the MsgBox options. These constants are included as part of the Visual Basic language. Using constants, your statement would read as follows:

UserAnswer = MsgBox("Do you wish to save changes_ 
before closing?", vbYesNoCancel + vbQuestion)

There are four icons that can accompany a message box: the information, question, exclamation, and stop icons. Using them appropriately will help the user understand the significance of the information. The information icon should be used when the message box only contains an OK button and no changes will result from any action the user takes with respect to the message box. It should give information about some status but not require further action. If the message box contains only an OK button but requires further action on the part of the user, the exclamation icon should be used instead. An example of such a situation could be: "Please insert the Setup disk before continuing."

Intuitively, the question icon is to alert the user that a question is being posed, but some interface designers prefer to reserve the question mark to denote online help. The exclamation and question icon are sometimes used interchangeably for situations such as the message box shown in figure 1.10. It is acceptable to avoid the use of the question icon and use the exclamation icon whenever posing a question to the user. Make sure you are consistent throughout your application, whatever you decide.

The Stop icon alerts the user that a critical problem has occurred. If something has gone wrong and it is too late to be corrected, the Stop icon is appropriate. It can also be used to warn the user that continuing an action will cause such a problem to occur. An accepted but less obvious use is to alert the user that a problem (usually hardware related) must be corrected before work can continue. Some designers prefer to use the exclamation icon for this purpose, but again consistency is the key.

Message boxes also allow several options for the buttons you wish to display. Information boxes should include the OK button only and make it clear that no action will be taken. Use the Yes/No option when its meaning is clearer than OK/Cancel.

Finally the MsgBox function allows you to choose a level of modality. Message boxes are all modal to some degree but you may choose between application and system modality. Application modality requires the user to respond to the message box before taking other actions in the application, but allows the user to switch to other applications before dealing with the message box. System modal message boxes require a response to the message box before any other action at all can be taken. Application modality is sufficient for almost all situations. There should be a very good reason for a system modal dialog box: one which threatens data or system stability.

The InputBox function is a quick and dirty way to get simple information from the user such as a login name or a password. Although easy to implement, it is not the most aesthetically pleasing of dialog boxes and its range of uses are limited.

Common Dialog boxes

If you've ever designed a File Open dialog box (see fig. 1.11) from scratch, you know what an involved process it is. A multitude of controls are required to sort through the file system on the computer. Code must be written to update the status of one control based on selections made in the others. The dialog box needs to look nice, too, and lining up the various list boxes, combo boxes, command buttons, and other controls can be a headache.

Fortunately, the wheel need not be reinvented. Some of the most used and most useful dialog boxes can be generated automatically within Visual Basic by using the Common Dialog control. A moderate amount of customization can be specified when displaying the dialog box, and all of the grunt work of laying out the controls and making them work together properly is already handled.

Fig. 1.11 The Open common dialog box.

The common dialog boxes are a boon to programmers and should be used whenever practical. Not only do they save development time, they are also the dialog boxes with which users are already comfortable. In fact, if your program demands that you write an Open dialog box from scratch, due to some special ways in which your program can open files, it is best to try to copy the physical layout of the common Open dialog box as closely as possible.

Note: When creating filters for your common dialog boxes, be sure to include an option for All Files *.* along with whatever other extension types are appropriate. Often, the file the user is looking for will not have the correct extension.

(c)Designing Original Dialog Boxes

When an original dialog box is needed, one can be created from scratch from a form. Although they can vary from simple windows with only one or two controls to large ones with many different controls, all dialog boxes share some common properties.

• They do not take up entire screen; if the application is maximized, it should be visible behind the dialog box.
• They are not sizable and lack the maximize and minimize buttons. Set the Border property of the form to Fixed Dialog and the Max Button and Min Button properties to False.
• The dialog box may or may not include a control menu. If a control menu is included, it contains only the move and close options.
• Dialog boxes should have a title bar. If the dialog is the result of a menu selection, the title should be that of the menu item minus the ellipsis ("..."). If it is an alert or information dialog box, use the name of the application for the dialog box title.

A dialog box generally includes a minimum of one button. Except in the case of unrecoverable errors, one button must show the user how to get rid of the dialog box without changing the status of the program. (Some objects such as Toolbars or palettes can be thought of as modeless dialog boxes and do not necessarily contain a "go away" button.

Visual Basic makes a wide range of dialog box controls available. The user can issue a command by pressing a command button or selecting a menu item. Options can be selected with check boxes, option buttons, or by selecting menu items. Which control you choose to use will affect the functionality and ease of use of your program.

Note: Visual Basic 4 allows you to create an automatic 3D style for your dialog boxes. Most Windows 95 applications use this 3D style and it is fast becoming standard.

Maneuvering Through Dialog Boxes

When a dialog box appears on the screen, the user must switch to working in a different window. To keep the user from becoming lost, make it easy to enter, exit, move within, and go between your various dialog boxes.

Dialog boxes can have buttons that lead to other dialog boxes. This is particularly useful for more in-depth or advanced features. When implementing this, make sure the original dialog box can be seen when the new one comes up. Then the user will understand the hierarchy of the two boxes.

Buttons can also lead laterally to other dialog boxes which are not merely extended options of the first one. This tends to lose users in a maze of dialog boxes. A better design is to include the two or more dialog boxes as tabbed pages under one heading.

Command buttons should be lined up along the bottom or right side of the dialog box. They should read in a natural order from left to right or top to bottom. The OK button should be first, and the Cancel button last. Set the default button to the OK button in most cases, but for particularly dangerous options, make the Cancel button the default.

To allow users to tab to the various parts of the dialog box, set the TabIndex properties for each of the controls on the dialog box that the user will wish to access. The tab order should follow some logical progression, usually based on the location of the controls: generally moving from left to right, then top to bottom.

Note: The tab order of controls usually reflects the orientation of written language. When creating software for use in a country where the language reads from right to left, you may want to adjust the tab order to move from right to left as well.

Tabbed Dialog Boxes

Tabbed dialog boxes provide a solution to the problem of overcrowded and bewildering dialog boxes. Rather than cluttering one dialog box with too many options or creating chains of dialog boxes that can access each other, the tabbed dialog box allows you to roll several dialog boxes into one. Moreover, they are visually appealing and correspond to real life objects with which the user is familiar.

Any time you need a dialog box to contain more than one category of controls, consider using a tabbed dialog box. Don't worry if one of the pages on such a dialog box seems sparse. Figure 1.12 shows a page with only four text boxes. It is also acceptable to create a page with fewer controls: even a single check box! The question to ask is whether or not breaking these controls down into small categories will help the user.

Fig. 1.12 A tabbed dialog box.

The time to combine controls onto one page is when they affect each other or when knowledge of one is required to make decisions about another. So, if you have a check box indicating whether or not a password is required and a control button for changing the password, these belong together.

Tabbed dialog boxes have not yet become standardized. In figure 1.12, the OK and Cancel buttons appear outside of the tab pages. This approach is recommended because the buttons apply to all three pages. You might notice that many of the major software releases put these buttons on the tabbed pages themselves. Instead, save this area for buttons that are specific to the page.

Dialog Box Controls

An entire book could be written about the various kind of dialog box controls and their uses. In addition to the standard and custom controls that come with Visual Basic, many third-party developers have created controls of their own.

Some controls are found in virtually every program: command buttons, list boxes, option buttons, etc. Others are essential for some programs, useful in others, and extraneous in most. There's nothing wrong with using a control because it looks great, as long as it doesn't hinder the user. Just be judicious in selecting your controls, especially in productivity applications.

Command Buttons

Command buttons are perhaps the most versatile control. The most obvious home for command buttons is in a dialog box. Dialog boxes rely on command buttons for all user directives since they lack menus (other than the control menu). However, they can also appear on the main application form itself and on Toolbars.

Smaller programs, particularly non-MDI applications, will often use a variety of command buttons in the main application window. Usually these buttons duplicate commands found on the menus. This may seem like an unnecessary waste of resources but in a utility program which only has a few commands, this lets the user see all the available options. Access to button commands is simplified for both the keyboard and mouse user as well. The keyboard user will be able to use the accelerator keys to go directly to the command without having to use the menu accelerator key combination. The button can also be reached by tabbing to highlight it, then pressing enter. The mouse user will be able to press the button directly, without having to maneuver through menus.

Note: Command button names are much like menu items. They should include an accelerator key, indicated by an underlined letter (except for Cancel buttons, which are activated by the Esc key).

In larger programs or any program for which screen real estate is an issue, it becomes impractical to litter the screen with command buttons. Their usefulness led to the compromise of the Toolbar, where some of the most popular command buttons are given in miniature form. Toolbars are discussed in their own section earlier in this chapter.

check boxes and option buttons

Usually found in dialog boxes, check boxes and option buttons (also called "Radio Buttons") both allow the user to specify options (see fig. 1.13). The purpose for which they are intended should determine which of the two is used.

Fig. 1.13 check boxes and option buttons.

check boxes can exist alone or in groups. Each one, however, is an independent entity representing an On/Off status. A good example would be check boxes for Bold, Italic, and Underline. Any or all could be checked and changing one would not affect the others.

option buttons always occur in a group and operate as mutually exclusive. If one is selected, the others are not. Selecting one will change the status of the others. An example of where this would be used is often found in word processors in choosing a kind of tab stop, such as Left, Right, or Center. The tab stop would have to be exactly one of those. option buttons should be grouped together in a frame whose title reflects their function.

Note: The simplest way to handle a group of option buttons in your code is to create a control array. Then, when one is selected it is easy check the state of all the others with a for/next loop on the array index.

With check boxes and option buttons, the question of which one will work for a certain purpose is automatically determined by the nature of the use. However, whether such a control should be used at all is a more complicated decision facing the programmer. For example, option button groups can be replaced by list boxes. check boxes can be replaced or supplemented by menu items.

Use a group of option buttons over a list box when the number of options is fairly small. Choose between check boxes, menu items, or a combination based on the organization of your program, the available menu space and the amount of clutter in your dialog boxes.

There are no hard and fast rules about choosing one kind of control over another. Try to anticipate the needs of different kinds of users and design accordingly.

List and Combo Boxes

The different types of combo boxes can be a confusing aspect of Visual Basic interface design. The first two styles of combo box, Drop-down and Simple, are very similar. The third style of combo box, drop-down list, is actually not a combo box at all but a kind of list box.

Drop-down and Simple combo boxes are combination text and list boxes. They present the user with a list of suggested choices but allow the user to type an entry that is not on the list. Simple combo boxes always have their list displayed. Drop-down combo boxes wait until the user clicks on the attached arrow before displaying the list. Since any displayed list should show at least 3 items, the simple combo box takes up significantly more space on a form than the drop-down combo. However, the simple combo has the advantage of showing more information at first glance.

Combo boxes have a tendency to confuse users. If space permits, the most user-friendly way to implement a combo box is to use a simple combo with instructions above it, such as: "Type a name or select one from the list."

To make the user choose from a predetermined list of choices, you can use a list box or a drop-down list combo box. The purpose of a list box is more immediately obvious to the user but takes up more space.

List boxes and simple combo boxes should be sized so that between three and eight items can be seen. Drop-down boxes will automatically size themselves and will even drop up if positioned too close to the bottom of the screen.

Using Controls to Represent Numeric Data

A variety of controls exist for inputting and displaying numeric data. How do you choose among spin buttons, sliders, gauges, text boxes, scroll bars and other possibilities?

Often, although a value is really numerical to the computer, its meaning to the user may be less so. A program that plays music may use a numerical setting for volume. Thus, it could be represented as a number alone. However, a scroll bar in its rightmost position will tell the user that the volume is turned up high better than a text box showing the number 11.

Use graphical controls to supplement or replace numeric displays when it will help the user to better understand or better manipulate values. Avoid using them to be cute or just for looks, except when simulation is the point, as in game programming.

Spin buttons allow the user to click up and down buttons to increase or decrease a setting. Spin buttons are input only controls, and thus are usually used together with some kind of display that indicates the value that they control: generally a text box. The spin button itself has no value property, that must be stored elsewhere. In figure 1.14, the SpinUp and SpinDown events control the value property of the text box.

Fig. 1.14 Spin buttons used in conjunction with a text box.

Spin buttons are often used for date or time settings. Often the value affected by the spin buttons can vary depending on what value is selected. For example, the spin buttons in figure 1.14 can change the hour, minutes or AM/PM settings of the clock depending on which is selected.

Because spin buttons only allow you to change a value one unit at a time, some other method of changing the value should be used as well. Trying to change the minutes setting of a clock from 00 to 30 by clicking on spin buttons is not a good design feature. For this situation, let the user choose between using the spin button and typing the value directly into the text box.

Spin buttons are good to use for "wraparound" values: where you wish the top value to be followed by the bottom one. For example, in using spin buttons to set the minutes of a clock, make 00 follow 59.

Sliders (see fig. 1.15) and scroll bars (see fig. 1.16) both can accept and display values to the user.

Fig. 1.15 A slider can accept and display values to the user.

They also have the advantage of presenting a visual idea of how big a value is relative to a maximum value.

ig. 1.16 A scroll bar also can accept and display values to the user.

Scroll bars are often used for setting values along a continuum. Volume controls and brightness level are good uses. A slider can be used the same way by removing its tick marks and setting its maximum value to a high number. Sliders can be used to good effect when emulating physical controls with which the user is familiar. They have a nice "real world" look to them.

Sliders with tick marks are best used with a limited number of values: around 15 or fewer. For choosing among discrete values, like channel settings or lines per inch, a slider can be used where a scroll bar cannot.

Progress Bars

Another control worth mentioning is the progress bar (see fig. 1.17) available in most versions of VB 4. Any operation that requires more than a second or two for the computer to complete can leave the user wondering if things are progressing as they should. If your program saves or loads lengthy files, or performs calculations that can take a while, you will want to include feedback on the progress of these operations.

Fig. 1.17 A progress bar should be used to provide the user with feedback about time-consuming tasks.

The progress bar is best used alone in a dialog box, as shown in figure 1.17. Although it is sometimes impossible to gauge what percentage of an operation is completed, it is still helpful to give the user the impression that progress is being made.

Shortcuts

The following are several categories of shortcuts for Windows applications:

• Mnemonic letters that provide keyboard routes to all menu items and command buttons (used with the Alt key)
• Shortcut keystrokes for commonly used commands (usually used with the Ctrl key)
• Alternate ways of accepting choices in dialog boxes (indicated by double-clicking on the choice)

Some of these shortcuts are mandatory and some are optional. It is important to follow the standards and de facto standards that have evolved both for where to provide a shortcut and which one to use.

Applying Menu and Command Button Mnemonics

Theoretically, a user should be able to negotiate a Windows application without touching a mouse. In reality, this is usually impractical, if not impossible, but keyboard access to every menu item is a necessary part of a well-designed interface. The Visual Basic implementation is very simple. When entering the caption in the menu editor, precede the mnemonic character with an ampersand. Thus, entering a caption of "&File" will produce the menu name File.

Each menu name and menu item must have an underlined letter which, when typed with the Alt key, will have the same effect as clicking on that item. These are called mnemonic or access characters. Generally, the first letter of the name is used when possible. Duplication of first letters sometimes makes it impossible to use the first letter. There are also some cases where a different letter will provide a better mnemonic, such as the "x" in Exit.

Each menu must have a unique mnemonic character. Within a menu, each item must have a mnemonic character unique to that menu. When the first letter is unavailable, try to pick a significant consonant in the name. When that isn't possible, use any consonant or a vowel.

Similar mnemonic characters can be used for command buttons as well. Remember to check that the mnemonic character used does not duplicate one used on any of the menu names. The cancel button does not receive a mnemonic character. Instead, it is activated by pressing the Esc key. To implement this in Visual Basic, set the Cancel Button property to True.

Implementing Shortcut Keystrokes

In addition to the mnemonic character, certain menu commands should have a shortcut keystroke. These are usually implemented as Ctrl key combinations but the function keys (Del and Esc) are also used. Shortcut keystrokes differ from mnemonics in that they do not require negotiation through menu or dialog boxes to use. To use a mnemonic character, you must be able to see the title or menu item it is associated with. Shortcut keystrokes do not have this limitation.

Shortcut keystrokes are listed on the menu itself, providing a on-line reference for the user. Visual Basic implements the functionality of the keystroke and puts it on the menu for you when you enter the keystroke in the Menu Editor.

Some commands, Cut and Copy for instance, must have a shortcut keystroke. You may wish to provide shortcuts for other ones, especially those that the user will use frequently especially if the command will immediately precede or follow typing. There are, however, some commands which should not have a shortcut keystroke. Consider the possible consequences of setting Ctrl+S as a shortcut for Save. After cutting out a large section of a document and repositioning the cursor, the user could mistakenly type Ctrl+B instead of Ctrl+V to paste. Now the document has been saved minus the cut text. In general, avoid creating shortcut keystrokes for commands that cannot be revoked with the Undo command.

The standards and recommended standards for some commonly used shortcut keystrokes are listed in Table 1.2.

Using Double-Clicks

Instead of selecting an item in a list box or on an option button and then clicking an OK command button, most designers choose to implement the shortcut of double-clicking on the desired item to both select and then approve the choice. This is considered to be an optional shortcut but most major programs utilize it and users have come to expect it.

This shortcut is useful on Option buttons, list boxes and Simple combo boxes. Drop-down list and combo boxes do not support a double-click event since the first click makes the drop-down section disappear.

If the dialog box in question has several different controls, using this shortcut should accept all changes that were made in the dialog box, not just the one that is double-clicked. This is easy to implement by simply running the click event of the OK button when the option button or list item is double-clicked.

Helping the User at Runtime

Many users, including some real computer novices, consider paper documentation to be a last resort. They learn new programs by exploration and experimentation with occasional dips into the online help system.

A well designed interface facilitates this kind of learning. A liberal use of message boxes for information, alerts and error trapping makes a program both forgiving and more comprehensible. Providing useful online help, while not a quick or easy job, should be given as much, if not more, attention as more traditional written documentation.

Message boxes are a useful way to communicate with the user at runtime. They can be used to provide context sensitive help and information, alerts and error traps. A program with too few message boxes leaves the user wondering what is going on: How long is this sort going to take? What does "Device Error" mean? Did I remember to save that file? On the other hand, too many message boxes can frustrate the experienced user.

Try to anticipate any runtime error that the user could generate. The most common one is the user selecting a drive that is not available in drive list box. Create informative message boxes that explain to the user in clear language what is wrong and what steps need to be taken to correct it.

Any time the user is going to perform a task that will result in permanent loss of data, an alert dialog box should appear giving the user an explanation of what will happen and the option to cancel the operation. Make sure that the command button names on the alert dialog box reflect what will happen. In a message box with the text: "Installing this program will erase the file GERBIL.DOC. Do you wish to continue?" the labels "Yes" and "No" are more informative than using "OK" and "Cancel." Users sometimes associate OK buttons in message boxes as merely the button that makes the box go away.

Sometimes it is necessary to include a way to skip alert messages. In a database program that confirms whether the user wants to delete a record, it is impractical for the user to respond to this dialog box for each of 100 records being deleted. In such a case, the option to turn off the feature altogether could be included. The disadvantage is that the user will probably neglect to turn it back on, or the next user may not even realize that such an option exists. An alternative is to include an additional "Yes to All" button on the confirmation dialog box that accepts the deletion for all the chosen records. This provides a kind of one time exemption from the confirmation dialog box but it is effective the next time the user chooses to delete.

Usability Testing

Once scorned by most major software companies, usability testing has finally come of age. In rooms with one way mirrors, users are videotaped as they work their way through beta versions of software programs. Clearly, this approach is unfeasible for smaller companies and individuals writing software, but the goals of the large companies in usability testing are shared by all programmers who want their software to be used and appreciated.

Usability testing can take a very simple form. Perhaps one of the easiest and most effective ways to test a new piece of software is to sit down with an inexperienced user, and ask him to perform certain tasks. Watching where he looks for certain functions may be telling. If you instruct him to create a title and center it on the page and he tries out all of the options in the Format menu, never noticing the Alignment menu, then you may have an indication that the menu titles are not as informative as you had hoped.

A more extensive method of usability testing involves a technique called "metering." Special code is added to the beta version of your application to record the different actions taken by the user, writing it to a log file. This allows you to track wrong turnings and dead ends that the user encounters. It also allows the user to work without being observed, something that often affects user behavior.

When using this technique, you will usually want to come up with a script of tasks for the user to perform. This allows you to compare the actions of several users and also keeps the data you accumulate within manageable levels. Remember, by writing a script of actions to follow, you may overlook something that users find puzzling. Use a variety of testing methods, including soliciting free-form feedback from some "guinea-pig" users.

Of course, too much stake should not be set on one or even on a few users. The long term working habits of those who will be using the program regularly must also be considered. But, in general, usability testing can provide helpful and often surprising insight for the programmer.

From Here...

This chapter discussed some of the fundamentals of interface design, including the mindset required of a programmer to design effectively. You learned many of the standards of layout and choice of controls, as well as ways to make the program more efficient for experienced users. By designing with the user in mind, using the appropriate tools, your interfaces will be easy-to-learn, effective, and streamlined.

• For more information on designing applications that support several open documents, see Chapter 2, "Multiple Document Interface (MDI)."

• For information on some of the additional controls available, see Chapter 20, "Third-Party Controls."

• For a discusion of designing and implementing online help systems, see Chapter 18, "Developing Online Help."