Visual Basic 2005 Design and Development - Chapter 5 pot

User-Interface Design Chapter 4, “Object-Oriented Design,” explored issues in high-level object-oriented design. However, the best application architecture and design in the world won’t save a program unless it helps the users do their jobs. The application must be easy enough to use that the users can do their jobs better with the program than without. This chapter explains some important user interface (UI) design concepts. It describes some of the rules you should follow and the techniques you should use to build a system that is useful, powerful, engaging, and natural to the users. Many developers believe that UI design is a simple matter of following common sense. Some of the rules of interface design are intuitively obvious, but others are fairly subtle. Individually, the rules for producing a good UI design seem obvious, but to build the best application possible, you must fully exploit every possible advantage, not just those that seem like common sense. This chapter begins by discussing a user-centered design philosophy that keeps UI design in per- spective. It helps you remain focused on the user. The chapter then discusses the characteristics of types of users. Different groups of users have different skills and different deficiencies. If you take the users’ strengths, weaknesses, and environ- ments into account, you will arrive at a better design. The remainder of the chapter describes different kinds of forms and design principles that you should follow to make a clean, smoothly running UI. By minimizing distractions and following design guidelines that lead the user toward performing the job correctly, the UI can make the users as productive as possible. 09_053416 ch05.qxd 1/2/07 6:30 PM Page 97 UI Design Philosophy It may sound a bit wishy-washy, but good UI design begins with the proper attitude. Developers must remember that the goal is not to show off the latest cool controls and UI techniques. It’s not to build unique, attention-getting designs, or to show off all of the colors of the rainbow. It’s not even to display the application’s data. Instead, the goal of UI design is to devise an interface that lets the users perform their jobs as efficiently as possible. To build the most efficient design, you must keep the users in mind while you are designing the applica- tion’s UI. You should try not to think about the software behind the screen, the object-oriented design, or the application’s database structure. You should focus on the users and their needs. Some of the consequences of this attitude are obvious, while others are fairly subtle. The following sections explain some of the results of this user-centric philosophy. It explains some of the goals of UI design at a very high intuitive level. Later parts of the chapter explain techniques you can use to achieve these goals. Give the User Control The customer should always be in the driver’s seat. The application is merely a tool to help the customer get a job done. The customer is neither a slave servicing the application’s demands, nor a supplicant begging for the application’s attention. The user should be active, not responsive. The user has a task and performs it. The program doesn’t per- form the task with the user’s help; the user performs the task with the application’s help. The program should phrase interactions with the user to emphasize the user’s control. It should be rea- sonably concise to save time, but it should also be humble. It should say things such as “ready for input,” rather than “enter values.” The emphasis is that the program is ready to do the user’s bidding, not that the program is commanding the user to enter data. I’ve seen many systems that tried to perform complex tasks automatically and then let the user handle the small percentage of cases where the program isn’t up to the task. In most of those applications, the “small percentage” turned out to be fairly significant, so the users ended up doing a lot of work. Because the program hid the easy cases, the users got less practice, and their skills actually atrophied over time, so they were less able to handle the exceptional cases. There’s nothing wrong with making the users’ jobs easier. After all, that’s what the application is supposed to do. If you think the program can do all of the work, however, you’d better be sure it really does all of the work. Focus on Tasks Users perform tasks, so the goal of the application should be to help them perform those tasks. Rather than thinking about the data available to the user, you should think about the jobs they perform and what they need to perform them. For example, suppose a billing representative needs to examine a delinquent customer’s data and decide whether to send a gentle reminder letter, send a stern warning letter, or discontinue service. A data- centric approach might be to display the customer’s data and then let the user decide what to do. 98 Part I: Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 98 The problem with this approach is that it includes all of the customer’s data. It might include the cus- tomer’s name, address, phone number, account number, previous orders, product configuration, pay- ment history, outstanding balance, and so forth. What the user really needs for this task, however, is the customer’s payment history and records of any previous correspondence. All that extra data can dis- tract the user, and make it more difficult to focus on the essential information needed to finish the task. Even if the critical data is nicely separated and easy to find, the presence of the other data adds to the complexity of the screen and slows the user down. A task-centric approach to this problem would display the customer’s billing history and list of previous correspondence. It might also display the customer’s name, just to give the user a sense of working with a person, but it doesn’t need to include the customer’s address, phone number, account number, order history, and other data. All of that information should be easily available in case the user needs it, but it should be hidden if the user won’t typically need it. Advise, Don’t Act The application can provide default values, give hints, suggest actions, and make actions available to the user, but it should not perform actions on its own unless those actions are an integral part of its job. A popular management aphorism is that it is easier to ask forgiveness than it is to ask permission. The idea is that it is sometimes better to take action (even if it later turns out to be wrong) than it is to do nothing. This idea makes sense when it’s difficult to make a decision or get approval to take a particular action, but it doesn’t make sense when the decision is quick and easy to make. Even if the program can save the user some time and trouble by taking action automatically, it should not do so unless it has a good chance of taking the proper action. It’s better to do nothing than it is to take action and apologize 85 percent of the time. Abraham Lincoln never saw a computer but his words apply equally to people and programs: “Better to remain silent and be thought a fool than to speak out and remove all doubt.” The Visual Studio development environment is an example of an application that doesn’t automatically take action. If you accidentally misspell a keyword or variable name, Visual Studio doesn’t automati- cally correct it for you. Instead it provides support to make it easier for you to fix the problem, as shown in Figure 5-1. Rather than correcting the error, Visual Studio flags it with a wiggly underline and a little red rectangle. If you hover the mouse over the error, a tooltip appears describing the error and a small information icon pops up. If you click the icon, a drop-down list appears, describes the problem, and lists possible solutions. In contrast, Microsoft Word automatically corrects spelling, replaces certain characters with others (for example, replacing straight quotation marks with “smart” quotation marks), and makes other improve- ments as you type. These are an integral feature of Word, just as applying styles is, so it makes some sense for Word to take action by itself. Note, however, that Word allows you to deactivate these features. If your program can automatically provide this sort of convenience feature, you should let the user turn it off as well. 99 Chapter 5: User-Interface Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 99 Figure 5-1: Visual Studio does not automatically correct spelling errors. Help Users Do the Right Thing Though the program shouldn’t do the users’ jobs for them, it can constrain the specific actions that the users can take. By using restrictive controls, it can help the users avoid mistakes. For example, by using combo boxes and lists, you can ensure that the user selects only valid items. Suppose an address form provides text boxes for city, state, and ZIP code. The user can enter any old garbage in those fields, so you will need to write additional code to validate the fields. More impor- tantly, if the user does make a mistake, he or she will have to waste time correcting it later. Now, suppose your form includes a combo box listing all of the cities in your distribution area. The user picks a city from the list, and the program fills in the state and ZIP code. Now the user cannot enter an incorrect city, state, or ZIP code, nor can the user enter invalid combinations of those values. For exam- ple, the user cannot enter a city with the wrong state and ZIP code. You can also restrict text boxes so that they allow only numeric input, input that matches patterns such as ###-###-#### for telephone numbers, and so forth. A program can use regular expressions to verify that strings match certain patterns. Although they are not covered fully in this book, the section “Making a Better Add-in” in Chapter 8, “Snippets, Macros, and Add-ins,” explains how to build add-ins that create properties that are validated by regular 100 Part I: Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 100 expressions. The section “Building Extender Providers” in Chapter 10, “Custom Controls and Components,” describes how to build extender providers that use regular expressions to validate controls. Make your forms as restrictive as possible to prevent the user from making mistakes that must be fixed later. Users Before you can write the best application for a user, you need to understand who the user is. You need to understand the user’s point of view, job, work environment, and abilities. It’s remarkable how many developers write applications without really knowing who will use them. Understand the User’s Job The first thing you should do when starting a new project is learn about the user’s job. If you don’t know what the user does, you won’t be able to write an application to help do it. Read any documentation or training materials that the users have that describes the job. Then talk to the users. Warn them that you’re going to ask a lot of stupid questions and then do so. Almost everyone likes to answer questions about their jobs and you’ll probably have no trouble getting answers. Sit with the users and watch them do their jobs. Ask what’s hard, what’s easy, what’s normal, and what’s unusual. Ask what they like and don’t like about the job. Ask what they would change, what they would keep the same, and why. When I worked for GTE Laboratories, developers were regularly sent to a training center where telephone personnel were trained. We spent several days crawling in cable vaults, visiting switching offices, learning how to splice telephone cables, trying out the techniques for diagnosing line faults, and learning as much as we could about phone company operation in general. It provided some very important perspective (and some funny stories) for many of the projects that I worked on later. Then do the same with another user. And another. Get perspectives from users who play different roles. Sit with the person who knows the whole process inside and out (there’s at least one in every office) and get a supervisor’s perspective. If you can, try performing the job yourself. The more you understand about the user’s job, the better you’ll be able to write an application to help. Respect the User Just because your users don’t understand how to write software doesn’t mean they are stupid or in any way less important than you. Often, the users have spent years in training and performing their jobs, and there’s no way you can expect to acquire their level of expertise in just a few hours or days. Fortunately, your goal isn’t to become as good as the users at their jobs; it’s to understand their jobs well enough to build an application that can help. 101 Chapter 5: User-Interface Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 101 At one company I worked for, an employee’s badge had a big star on it for every five years of service. Typically, the expert users we worked with had four or five stars. Even many of the hourly “craft” workers had 10 or 20 years of experience and performed relatively complicated technical jobs. Never think that the users’ jobs are trivial or inconsequential. Your job is to translate the needs of the users into an application that can help them do their jobs. Without your users, you wouldn’t have a job. If you alienate your users, development can become a nightmare. At best, you’ll face a lack of cooperation and little or no feedback leading to an ineffective application. At worst, you’ll be replaced by someone who understands the importance of the users in the grand scheme of things. Understand the User’s Environment While you are working on an application, it’s important to focus on what the application does and how it works, but it’s also important to keep the user’s large environment in the back of your mind. Do the users work with other important applications? If so, your program will probably need to share screen real estate with other programs. Will your application need to interact directly with those systems? If it won’t now, might it later? Do the users work in a noisy environment? If so, sounds won’t be very useful in your application. Do the users all work in the same space? In that case, lots of sound may interrupt other users trying to get their jobs done. I once built a few applications for a billing center where the users wore very sensitive telephone headsets to talk to the customers. Even the sounds of their typing were sometimes picked up on the phone. The applications they used needed to stay quiet. Do the users work mostly with the keyboard, the mouse, or some other input device? If the users’ hands are always full, or they wear heavy gloves, the application may need a voice interface. What kind of computers will the users have? It’s very common for software developers to work on very powerful up-to-date computers while the eventual users have older, sluggish systems with little mem- ory, full hard drives, and lethargic network connections. Developing on a powerful computer will save you time, but be sure to think about the target platform, particularly when you consider the response time issues described later in this chapter. While you develop in one environment, the users perform their jobs in another. To build the most useful application possible, you need to see your system in the context of the users’ complete environment. Understand User Types Users come in all shapes and sizes with different sets of skills and expectations. Although you cannot take into account every difference between users, you should think about large classes of users that you are likely to encounter. Two particularly important dimensions to consider are the users’ ages and their physical differences. 102 Part I: Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 102 Younger users have better vision and hearing, faster reaction times, and better memory than senior users. They also have higher level of reading comprehension and have finer motor control. Older users may have weaker vision and hearing, slower reaction times, and trouble positioning the mouse precisely. Interestingly, children share some characteristics of both groups. They have good hearing and vision but are still developing their reactions and fine motor skills. Unless you know that your group of users includes only people of a certain age, you should plan to sup- port as wide an audience as possible. Overall, the world’s population is aging, so over time, a larger per- centage of your potential users will be older. It makes sense to spend additional effort making the application easier to use for this growing segment of your user population. That means using larger fonts and icons to support weakening vision, and larger buttons to support declining fine motor skills. It also means reducing the importance of sounds in the UI. In addition to age-related differences, users may have physical differences that affect how they use an application. About 10 percent of men and 1 percent of women have some form of color blindness. Unless you have a very small user population, odds are you will have some users that have trouble distinguish- ing certain colors. To help those users, you should not rely solely on color (particularly red and green) to convey important information. One check you can perform is to put the computer in high-contrast mode using the Accessibility applet settings and see if the application is still readable. If you can’t understand the application in this mode, chances are some of your users won’t be able to understand it either. Some users may have different skills than others. Touch typists can work much more quickly if you don’t force them to use the mouse. Users experienced with the numeric keypad can enter numbers extremely quickly if you let them use the keypad. All users slow down greatly if you force them to switch frequently between the keyboard and mouse. Cultural difference may also play a role in how users interpret your system. Culture obviously affects such issues as language, but it also has many subtler differences. For example, different images and col- ors can have different interpretations in different parts of the world. In some parts of the world, a dog represents a faithful friend, whereas in others it symbolizes a sneaky, cunning, and degraded person. Finally, your user population may include those with physical handicaps such as impaired vision, hearing, memory, and motor control. You can help some of these users with the same techniques that help older users: larger fonts and icons, bigger buttons, and not relying on sound alone. You can also look at the checklist at www.webaim.org/standards/508/checklist to help make applications more accessible. Good UI design helps further by providing textual representations, non-mouse alternatives for perform- ing actions, and hints and guides to reduce the user’s memory load. 103 Chapter 5: User-Interface Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 103 Forms There are several kinds of forms an application may need. You can group these into the following categories: ❑ Main forms provide a base from which a user begins a work sequence. Some applications have a single main form that controls all other forms. Other applications have several main forms that control different aspects of the system. For example, a control panel application might provide an assortment of tools that let you manage different processes. Usually main forms are resizable. ❑ Secondary forms provide additional detail for main forms. ❑ Dialogs give the user feedback or let the user enter data immediately. Dialogs are modal so the user must dismiss them before interacting with the rest of the application. Main and secondary forms are modeless. Having lots of forms connected in unusual ways is confusing. As users open and close forms, they can become disoriented. Later, they may have trouble figuring out how they got into the position they’re in, how to get to a particular form, or how to backtrack to a previous position. You can make this a lot less confusing by minimizing the ways in which users can navigate between forms. You can also make navi- gation simpler by minimizing the number of levels in the hierarchy. For example, Visual Studio provides a main form that includes everything else. It can launch secondary forms that are code editors, form editors, resource pages, and so forth. Those secondary forms display dialogs such as warnings, property editors, and wizards, but they generally don’t display new forms. The dialogs are modal, so you need to finish using them and close them before you can go back to the rest of the project. This hierarchy has only two levels containing a single main form and secondary forms contained inside the main form. It is usually better to have a shallow hierarchy of forms so the user can- not get too lost. Another possible design uses a set of accessor forms that provide access to main forms. For example, you might have a series of search forms that let the user look for orders, customers, and inventory items. Once you have found a set of items, you could open a new form to view that item. This item view form might include secondary forms to provide additional detail, or it might include all of the item’s detail, possibly by using tabs. Instead of using accessor forms to search for items, you could use search dialogs launched by a main application form. That would make the most sense if the user spends relatively little time searching and lots of time working with the item view forms. If the user spends a lot of time searching and monitoring lists of items, it is reasonable to make the accessor forms instead of dialogs. One way you can decide whether a form should be a main form is to ask whether it should appear in the taskbar. Main forms belong in the taskbar, while secondary forms and dialogs do not. In the previous design, you would want the main application form and the item view forms to be in the taskbar. You would probably not want to show the accessor forms in the taskbar. MDI versus SDI You can sometimes use a multiple-document interface (MDI) to make managing the program’s forms eas- ier. An MDI application uses a single large form to hold child forms. The user can move, resize, and even 104 Part I: Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 104 iconify the child forms, but they always sit within the MDI parent form. Visual Studio is an MDI applica- tion with a main form containing any number of form editors, code editors, and other child forms. In contrast, a single-document interface (SDI) does not contain a main form that holds the others. Each form sits separately on the user’s desktop and the user manages them separately. Microsoft’s Paint, Notepad, and WordPad programs are all SDI applications. When you open a bitmap in Paint, or a text file in Notepad or WordPad, Windows creates a new independent instance of the application with its own taskbar icon. If your application deals with very complicated data, you can even create a hybrid with characteristics of both SDI and MDI applications. For example, you can make an application that launches MDI parent windows as needed. The main form could be an MDI parent form containing a series of MDI accessor forms as children. When the user selects an item from an accessor, you could launch a new MDI parent form to display its data. That form could contain its own MDI child forms to provide details about the selected item. SDI has the advantage that it is simple, easy to build, and easy to understand. It has the disadvantage that it can only reasonably hold information about a single entity. MDI has the advantages that it can hold any number of windows and that it keeps them grouped together. In addition to providing a container for the child windows, the parent window can provide tools for arranging the children by tiling, cascading, minimizing, and maximizing them. A disadvantage of MDI windows is that it’s more confusing to manage a collection of windows. Secondary windows that are not MDI children aren’t integrated into the whole, but if you make them MDI children, it’s easy to lose the connection between a secondary window and the main window to which it is related. It’s also more difficult to tell how the menu bar works, because the commands on it depend on the child window that currently has the focus. Which option is best depends on your application. In the end, you need to balance simplicity with flexi- bility, and pick the simplest solution that can satisfy the users’ needs. Resizing Forms Main forms should generally be resizable. Secondary forms may be resizable or not, depending on how much information they need to display. If a secondary form can show all of its information in a limited space, give it a fixed size. If all of the information won’t fit on the form at once, you can let the user resize it to see more data. Dialogs should generally not be resizable. One common exception to this rule is the unfolding or expanding dialog. In an unfolding dialog, a button allows the user to show or hide additional advanced information. For example, look at the ColorDialog shown in Figure 5-2. If you click the button labeled “Define Custom Colors >>”, the dialog expands, as shown in Figure 5-3. Note that the expansion button includes the characters “>>” at the end to tell the user that the dialog can expand. Ideally, the dialog expands to the right. If the dialog is too wide, some applications expand the dialog downward, although they usually still use the characters “>>” to indicate the expansion, which is somewhat misleading because the expansion isn’t to the right. 105 Chapter 5: User-Interface Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 105 Figure 5-2: The ColorDialog starts in this small state. Figure 5-3: Click the “Define Custom Colors >>” button to expand the ColorDialog to this state. In some designs, the expansion button’s caption changes after it is pressed, and it then allows the user to collapse the expansion. In this example, the button’s caption might change to “<< Hide Custom Colors.” You can also make an argument for allowing the user to resize dialogs that contain a large amount of information. For example, a selection dialog might let the user pick from a list of thousands of customer accounts. In that case, the user might want to make the dialog very tall to see more of the list at one time. If you know the list will hold between few dozen items and perhaps 100 items, make it large enough to show a substantial portion of the list (10 or 12 items) and make it a fixed size. If the list will contain sev- eral hundred items, make the dialog resizable. Better still, restrict the information in the list to make it smaller, or consider moving the functionality into a secondary screen with search capabilities. 106 Part I: Design 09_053416 ch05.qxd 1/2/07 6:30 PM Page 106 [...]... teapots, and so forth) Many of the ideas also apply to UI design, and can give you a general feel for what makes a good design and what doesn’t This chapter and Chapter 4 show two different aspects of an application’s design Chapter 6, “Data Storage Design, ” shows a third aspect of design: how the data behind the application is arranged, stored, retrieved, and presented to the user 131 09_ 053 416 ch 05. qxd... down, and may lead to errors when the user switches from one application to another Visual Studio makes building a standard menu easy First, add a MenuStrip control to the form Rightclick the MenuStrip and select Insert Standard Items Figure 5- 1 1 shows the result Figure 5- 1 1: To build standard menus, place a MenuStrip on the form, right-click it, and select Insert Standard Items 119 09_ 053 416 ch 05. qxd... will need some additional training and practice if you use one in your application Visual Studio has proven that this can be a powerful and effective method for editing object properties, however This control is not a standard used in many applications, but that may soon change 108 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 109 Chapter 5: User-Interface Design Figure 5- 5 : The PropertyGrid control displays... left group box and its contained controls grew to match while the group box on the right and its controls did not Visual Studio also enlarged the form and the group boxes 1 15 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 116 Part I: Design Figure 5- 1 0: By default, a control inherits its container’s font Before taking the image of the form in Figure 5- 1 0, I set the system to use extra large fonts, and you can... system has a particular menu command, but be unable to find it If the item is disabled, the user can at least see it and try to figure out how to enable the command 120 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 121 Chapter 5: User-Interface Design Context menus handle unavailable items a little differently than standard menus Context menus are tied to specific controls and data, so their contents should... The 116 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 117 Chapter 5: User-Interface Design resizing also doesn’t always produce the best appearance, and some items look better if they are rearranged after resizing One trick for handling different system font sizes explicitly is to use Visual Basic s localization features to build “fake locales” for the different sizes First, build the basic form design, giving... times and then stop (like the ErrorProvider does) 130 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 131 Chapter 5: User-Interface Design Consistency At every level of UI design, be consistent Design main forms, secondary forms, and dialogs consistently Place buttons in the same position on all dialogs, either at the bottom or on the right Use similar font styles for headings, labels, instructions, and data... anchored on the top, left, and right, so they expand horizontally as the form does The State and ZIP code fields and their labels are anchored on the top and right, but not the left, so they move with the form’s right edge The list at the bottom is anchored to the top, bottom, left, and right, so it expands vertically and horizontally as the form does Figure 5- 9 : This form’s fields expand to take advantage... awkward 110 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 111 Chapter 5: User-Interface Design Figure 5- 7 : A balanced form feels natural and smooth To minimize eye movement, keep related items close together This also helps minimize mouse movement when the user is manipulating the data Use big targets to make pointing and selection with the mouse easier That means using larger fonts and buttons Of course, larger... uneven, and misaligned, the user will have greater trouble finding the pattern and may get lost Figure 5- 6 shows an unbalanced form Figure 5- 7 shows the same controls arranged in a more balanced way In this version, the group boxes are all the same size, even though their contents don’t take up the same amount of room Figure 5- 6 : An unbalanced form is uncomfortable and makes form flow awkward 110 09_ 053 416 . User-Interface Design Chapter 4, “Object-Oriented Design, ” explored issues in high-level object-oriented design. However, the best application architecture and design in the world. representations, non-mouse alternatives for perform- ing actions, and hints and guides to reduce the user’s memory load. 103 Chapter 5: User-Interface Design 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM. isn’t to the right. 1 05 Chapter 5: User-Interface Design 09_ 053 416 ch 05. qxd 1/2/07 6:30 PM Page 1 05 Figure 5- 2 : The ColorDialog starts in this small state. Figure 5- 3 : Click the “Define Custom Colors