usability design
The usability of any application is essentially determined by the user. Interface design is an iterative process; when designing an interface for an application, it's rare to get a perfect interface right from the first step. The earlier users are involved in the design process, the less effort it takes to create a better, more usable interface.
What is a good interface
When designing a user interface, it's a good idea to start by looking at some of the best-selling applications from Microsoft or other companies. After all, an app with a poor interface won't sell well. You'll find many common things, such as toolbars, status bars, tooltips, context menus, and markup dialogs. It's no accident that Visual Basic has the ability to add all of these things to an application.
You can also rely on your own experience using the software. Think about some applications you've used, what worked, what didn't, and how you could modify it. But remember that personal preferences are not equal to user preferences, and you must align your own opinions with those of users.
Also note that most successful applications offer options to accommodate different user preferences. For example, Microsoft Windows Explorer allows users to copy files through menus, keyboard commands, or drag-and-drop. Providing options will broaden the appeal of the application, and should at least make all functions accessible by mouse and keyboard.
Windows Interface Guidelines
The main advantage of the Windows operating system is that it provides a common interface for all applications. Users who know how to use Windows-based applications can easily learn to use other applications. Applications that deviate too far from the established interface guidelines are difficult to understand.
Menus are a good example of this - most Windows-based applications follow this standard: the "File" menu on the far left, then "Edit", "Tools" and other optional menus, and the "File" menu on the far right. Help" menu. If Documents would be better than File, or the Help menu should be placed first, it would be worth discussing. There's nothing stopping you from doing this, but doing so can confuse users and reduce the usability of your application. Users have to stop and think every time they switch between apps and other programs.
The location of submenus is also important. Users expect to find submenus such as "Copy", "Cut" and "Paste" under the "Edit" menu, but moving them under the "File" menu will cause confusion for users. Don't deviate too far from the guidelines that have been created unless there is a good reason to do so.
usability testing
The best way to test the usability of your interface is to involve users throughout the design process. Whether you are designing a large, compressed application or a small, limited-use application, the design process should be exactly the same. Using the design guidelines that have been created, interface design should start on paper.
The next step is to create one or more prototypes and design the form in Visual Basic. You still need to add enough code to get the prototype started: display the form, populate the list box with sample data, and so on. Then prepare for usability testing.
Usability testing can be an informal process of reviewing the design with users, or it can be a formal process in a usability lab that has been created. The purpose of both methods is the same: to learn first-hand from users about what works well and what needs improvement. Let go, let users be with the application, and observe them; this approach is more effective than asking users. Ask users to express their thought process as they try to complete a series of tasks: "I want to open a new document, so I look for it in the File menu." Note where the interface design doesn't reflect their thought process. Test with different types of users; if you find that users have difficulty completing a particular task, that task may need more attention.
Next, review the records and consider how to modify the interface to make it more usable. Modify the interface and test again. Once you are satisfied with the application usability, you are ready to start coding. Testing is also required from time to time during the development process to ensure that the assumptions about the prototype are correct.
Feature discoverability
A key concept in usability testing is discoverability. If users can't figure out how to use a feature (or don't even know it exists), it's unlikely to be used. For example, most users of Windows 3.1 never knew that the ALT and TAB key combination could be used to switch between open applications. Nowhere in the interface are clues provided to help users discover this feature.
To test functionality discoverability, ask users to complete a task without explaining how to do it (for example, create a new document using a "form template"). If they can't complete the task, or it takes multiple attempts, then the discoverability of this feature needs to be improved.
Interact with users when something goes wrong with them or the system
In an ideal world, software and hardware would always work without glitches, and users would never make mistakes. In reality, mistakes are inevitable. Deciding how your application responds when things go wrong is part of user interface design.
A common response is to display a dialog box asking the user for input on how the application should handle the problem. A less common (but better) response is to simply fix the problem without disturbing the user. After all, users are primarily concerned with completing tasks, not technical details. When designing a user interface, consider possible errors and determine which ones require user interaction and which ones can be resolved with prearranged solutions.
Create easy-to-understand dialog boxes
Occasionally an error occurs in an application and judgment is required to resolve the situation. This usually occurs as a branch of code - an If...Then statement or a Case statement. If this judgment requires user interaction, this issue is usually presented to the user using a dialog box. Dialog boxes are part of the user interface, and like other parts of the interface, their design plays a role in application usability.
Sometimes it feels like many designers of program dialog boxes don't speak words that make it easy for people to understand. For example, a message like this: "Sector of hard disk C is damaged or inaccessible. Abort, retry, ignore?" (See Figure 6.22) This is not easy to understand for ordinary users. This is equivalent to a waiter asking a customer: "We have no soup or the kitchen is lighting a fire, abort, try again, ignore?" How would you answer? It's important to describe the problem (and choice) in a way or phrase that users can understand. In the previous example, a better message would be "There is a problem saving the file on drive C. Please save the file on drive A. Do you want to save the file?"
When creating dialog boxes for your application, keep the user in mind. Does this message convey useful information to the user? Is it easy to understand? Are the choices represented by command buttons clear? Is this choice suitable for the given conditions? Remember, just one annoying message box can give users a bad impression of your application.
If you are designing a custom dialog box, try to stick to standard types. If it deviates too far from the standard message box layout, users may not recognize it as a dialog box.
For more information about dialog boxes, see "Dialog Boxes" earlier in this chapter.
Error handling without dialog box
It is not necessary to interrupt the user when an error occurs. Sometimes it is preferable to handle errors in code without notifying the user, or to alert the user in a way that does not stop the user's workflow. A good example of this technology is the "AutoCorrect" feature in Microsoft Word: if a common word is misspelled, Word automatically corrects it; if an uncommon word is misspelled, a red line is drawn under it to remind the user to correct it later.
There are a large number of techniques available; it is up to you to decide which techniques are appropriate for your application. Here are a few suggestions:
1. Add the "Undo" function in the "Edit" menu. For situations like deletion, rather than interrupting the user with an "OK" dialog, you can ensure they made the right decision and provide an "undo" feature in case they change their mind later.
2. Display message on status bar or icon. If the error does not affect the user's current task, do not stop the application. Use a status bar or a bright warning icon to alert users that they can handle the issue when they are ready.
3. Correct the problem. Sometimes the wrong solution is obvious. For example, if the disk is full when the user tries to save a file, the system checks other drives for space. If space is available, the file is saved; a message is displayed in the status bar telling the user what was done.
4. Save the message and wait for processing. Because not all errors are critical or require immediate attention; consider logging these to a file and displaying them to the user when they exit the application or at another convenient time. If the user makes an input error (for example, writing MainSt. instead of MianSt.), log it. Add a "ReviewEntries" button and a function that displays differences so users can correct them.
5. Don’t do anything. Sometimes the error is not important enough to warrant a warning. For example, the fact that the paper is not ready for the printer on the LPT1 does not matter much until it is ready to print. Wait until the message is relevant to the current task.
For more information on error handling techniques, see Chapter 13, "Debugging Code and Handling Errors."
Designing user-assistive patterns
No matter how well designed a user interface is, sometimes users will need help. The user-assistive mode of an application includes things such as online help and printed documentation; it can also include user-assistive devices such as tooltips, status bars, "what's this" help, and wizards.
Like any other part of an application, user-assistive pattern design should precede development. The content of the schema will vary depending on the complexity of the application and the intended audience.
Help and documentation
Online Help is an important part of any application and is often the first place users look when they have questions. Even simple applications should provide "help". Not providing it is like assuming users never have a problem.
When designing a Help system, remember that its primary purpose is to answer questions. Try to use user terms when creating topic names and index entries, for example, "How do I format a page?" Topics are easier to find than the "Edit" or "Page Format" menus. Don't forget context; most users will be frustrated if they press the F1 key for help with a specific field only to find themselves on the content topic.
Documentation of basic concepts, whether printed and/or provided on zip disk, is helpful for all but the simplest applications. It can provide information that would be difficult to convey with a short Help topic. At the very least, there should be a document in the ReadMe file form that the user can print if needed.
user assistive device
In user interfaces, there are several technologies that assist users. It's easy to add tool tips, "what's this" help, status displays, and wizards to your applications with Visual Basic. It is up to you to decide which of these devices are suitable for your own application.
tooltip
Tooltips (Figure 6.23) are a great way to display information to users as they search on the user interface. A tooltip is a small label that appears when the mouse pointer rests on a control and usually contains a description of the control's functionality. Normally tooltips are used in conjunction with toolbars, and they work well in most parts of the interface.
Most Visual Basic controls include a property used to display tool tips: ToolTipText. The following code will provide a tooltip for a command button named "cmdPRint".
cmdPrint.ToolTipText=Printsthecurrentdocument
Like other parts of the interface, make sure this text clearly communicates the message to the user.
For more information about tooltips, see "ToolTipText Property" in the Language Reference.
"What is this" help
When the user selects What's Help and clicks the What's Cursor on the control, What's Help provides a link to the pop-up Help topic (see Figure 6.24). "What's This" help can be launched from a toolbar button, a menu item, or a button on the title bar of a dialog box.
To enable "What's This" help from the menu or toolbar, follow these steps:
1. Select the control you want to help.
2. In the Properties window, select the WhatsThisHelpID property.
3. Enter the context identifier for the relevant pop-up Help topic.
4. Repeat steps 1 through 3 for any other controls.
5. Select the form.
6. In the "Properties" window, set the WhatsThisHelp property of the form to True.
7. In the Click event of the menu or toolbar button, type the following code:
formname.WhatsThisHelp
When the user clicks the button or menu, the mouse pointer changes to a "What's this" help pointer. To enable the "What's This" help on the title bar of a custom dialog form, set the form's WhatsThisButton and WhatsThisHelp properties to True.
For more information about the "WhatsThis" help, see "WhatsThisHelp Property" and "WhatsThisButton Property" in the Language Reference.
status display
Status displays can also be used to provide user assistance in much the same way as tool tips. Status displays are a great way to provide instructions or messages that wouldn't lend themselves well to tooltips. The status bar control included in the Professional and Enterprise editions of Visual Basic can display messages very well; the Label control can also be used as a status display.
The text displayed in the status display can be updated in one of two ways: using the control or form's GotFocus event, or using the MouseMove event. If you want to use the display as a learning device, add an item to the Help menu to toggle its Visible property on and off.
To add a status display, follow these steps:
1. Add a Label control to the form.
2. Select the control for which you want to display a message.
3. Add the following code in the MouseMove (or GotFocus) event of the control: Labelname.Caption=Enterthecustomer'sIDnumberinthisfield When the mouse moves over the control, this message will be displayed in this Label control.
4. Repeat steps 2 through 3 for any other controls.
wizard
A wizard is a user-assisted device that guides you through the implementation of a process step-by-step using your own actual data. Wizards are often used to provide task-specific assistance. They help with tasks that require a lengthy (and annoying) learning process, and they provide expert information to users who are not yet experts.
The Professional and Enterprise editions of Visual Basic include a tool for creating wizards: the Wizard Manager.
For details about the wizard, please refer to "Using Wizards and Add-Ins" in Chapter 4 "Project Management".
->