Summary
The user interface of your application exists solely to communicate with the user of your software. As with other forms of communication, you can "say" things that hinder the conversation, or you can "say" things that will enhance the dialog. The guidelines in this chapter seek to enhance the experience of the user in communicating with the essential data controlled by your application. Among the control guidelines listed in this chapter, the following key topics appeared as core issues.
Design your forms so that the user recognizes the consistency found within your program. The features present on each of your screens should be similar in usage throughout the application, and where reasonable, they should be similar to the features found in popular off-the-shelf software packages. Consult the Microsoft Windows User Experience manual for a useful introduction to the "official Windows" way of thinking about the user interface.
Never trust data supplied by the user. If there is any chance that the user could select or type in an invalid data entry (especially in Text Box controls), validate the data before its use. When presenting similar pieces of data (such as date fields), always use the same format so that the user has some expectation about how fields should be updated when needed. If possible, design your data entry fields so that the user cannot enter invalid data, either in individual fields, or in combinations of fields.
If you place graphics within your forms or controls at design time, always store a separate copy of the graphic files outside of the application. Place these files in a single, known location, either within your technical documentation set, or as part of your source code directory tree.
Several controls allow you to identify file and directory names, network addresses, Uniform Resource Locators (URLs), or other static destinations at either design time or run time. Never store such static locations directly in your controls or source code. Instead, store these destinations in an INI-type file, in a proprietary format configuration file, or in the Windows registry.
Some features of the controls available within Visual Basic access information that resides outside of the control of the Visual Basic application. Therefore, you must always use proper error handling in any procedure that uses these features. Make use of the On Error statement to capture any errors, and take the appropriate corrective action. When communicating with a remote computer, never assume that the connection will remain valid throughout the lifetime of your application. Handle unexpected termination of such connections gracefully. Alert the user to the situation, and either retry the connection, cleanly exit the application, or degrade performance where appropriate.
If you employ any advanced, obscure, or complex features of a control within your application, clarify the special expectations surrounding the control in your technical documentation. Also document custom resources or components used by your application, such as proprietary hardware devices.
Above all, provide the user with an application that is efficient, convenient, and consistent in presentation and data handling. By establishing and using standards within your user interface, you bring the user one step closer to accurate communication with your software and the data it manages.