Using the Keyboard
One of the most important considerations in the design of an application is how user input will be captured. In graphical user interfaces (GUIs), application developers often tend to focus on capturing input from the mouse. A user typically employs the mouse to perform actions such as clicking buttons, dragging and dropping files and information, and highlighting data. The mouse is a very useful tool and the most convenient method of accessing features of a GUI application.
As a developer, you painstakingly design a user interface that has a lot of buttons, menu options, drop-down lists, and other such features to make sure all the information your application is presenting is a simple mouse-click away. You might spend months working on such an application getting it to look and function just right.
Now it's time for the end user to run your application. (See Figure 16-1.) You'll find that it's functional and simple to use. Now try using it without the mouse. You've just found yourself in a predicament many people find themselves in every day. A number of disabilities can make it difficult or impossible to use a mouse. Quite often, experienced computer users and skilled typists simply prefer to use the keyboard-it can be quicker and more convenient than using the mouse. Whatever the reason, because your application relies so heavily on the mouse, it's totally useless or extremely inconvenient for a very large number of people.
What can you do to remedy this situation? You must design keyboard access into all your applications and interfaces. Try running the Keyboard sample. You'll notice it looks very similar to the NoKeyboard sample, but there is one big difference: every action you can perform with the mouse you can also perform using the keyboard. Let's go over some of the changes that were made to the NoKeyboard sample to produce the Keyboard sample.
Menu layout
One difference between the Keyboard sample and the NoKeyboard sample is the menu layout-the menu items are in a different order. If you've ever worked in product support, you know you spend a lot of time explaining things that can be found in the online Help. So why not call the user's attention to the Help option by putting it first on the menu? Because that's not where the user is used to finding it. Windows applications have been designed according to standards that allow users to move seamlessly from one application to the next. You might not agree with all the standards, but for your users' sake, don't try to change them. Menu order is especially important for people with visual impairments who expect to find certain interface elements in certain places, and searching around an interface can be a time-consuming and frustrating chore.
Key combinations
Shortcuts are an important part of interface design. All menu options should have an access key. An access key appears as an underlined character in the option name, indicating pressing that key activates that option. Pay careful attention to the keys you are assigning-every key must be unique within each menu or submenu. If your menu includes options that you expect to be used frequently, providing hotkeys (such as Ctrl+S for File Save), also known as accelerator keys, can save the user a lot of time. The user can perform the action without continually activating the menu. Look at the difference between the menus in Figure 16-2.
Figure 16-2 Menus from the NoKeyboard sample (left) and the Keyboard sample (right)
If you're providing functions that are common to most applications, use the most common naming standards and key combinations, such as File Open and Ctrl+O for opening a file. I once had to work with software that had menus you would expect to see, but the keyboard interface drove me crazy. Instead of exiting an application by selecting Alt+F (for the File menu) and then X (for Exit), the interface was designed to select Alt+F and then E. You'd be surprised to know just how many times I hit Alt+F and then X and the computer just beeped at me. Your users will spend a lot less time learning and remembering how to use your application if you give them something they're familiar with.
Navigation
Navigation is the means by which the user moves from one part of a window or dialog box to another, such as from one text box to another. Keyboard navigation is usually accomplished through use of the Tab key and the arrow keys. Setting a logical navigation order makes an application much easier to use than if pressing the Tab key or an arrow key takes the user to unpredictable places. When you create a form in Visual Basic, the tab order of controls on the form is set automatically according to the order in which you place the controls on the form. This can easily make for a strange tab order if you've rearranged the controls or deleted and then added controls. For example, the tab order shown in Figure 16-3 will confuse or simply annoy users. The tab order in Figure 16-4 is much more intuitive. When your user interface is final, you should determine a logical tab order, and then set the TabIndex property of each control according to that order (starting with 0).
NOTE
The MSDN Library includes a sample application called TabOrder. You can use this add-in in your Visual Basic environment to set the tab order of your form without setting each individual TabIndex property yourself.
Figure 16-3 Confusing tab order
Figure 16-4 Logical tab order
Navigation order is a common convenience for all users, but is especially important for users who don't or can't use the mouse. For example, someone who uses a screen reader will tab through the controls on a form to find out what each control does. Logical navigation makes the interface much easier to use and understand.