Practical Standards for Microsoft Visual Basic .NET (Pro-Developer)

[Previous] [ Next ]

Developing for Microsoft Windows has many benefits. When creating a Windows application, you don't have to focus on the foundation of the interface design. For instance, Windows already contains the code for drawing forms, complete with menus , Minimize and Maximize buttons , and a border. Windows draws forms consistently, using system colors and standard sizes for common elements. DOS application developers, on the other hand, had to individually create their own interfaces, which led to a bewildering amount of variety. Switching from one DOS program to another was more than just a physical task (usually requiring that the first program be shut down before the second was started); it required a mental leap as well. The general behavior of each DOS program was often so unique that you couldn't apply techniques or skills learned in one program to a different program.

Over time, experience taught users and developers alike what worked well and what didn't. Eventually, common interface elements evolved. For instance, we take for granted that every application we run in Windows gives us a nice menu bar at the top of the program's main window. Not all DOS programs offered a menu bar (although most eventually did). When Windows came along, it freed programmers (somewhat) from the details of the basic interface. This sometimes means that developers must give up flexibility, but the trade-off is usually more than worth it.

Although developers benefited from the standardized approach of Windows, users gained the most from that approach. Users quickly became accustomed to the interface of Windows, and just as quickly they became intolerant of programs that didn't adhere to the Windows standards. For example, if a user could print in three of her favorite programs simply by pressing Ctrl+P, it became unacceptable to have to press Alt+P in other programs. As developers, we're always focusing on reusable code. Users want reusable knowledge .

Microsoft Office is a good example of the advantages of interface standardization. Whether you love it or hate it, you have to respect what the Office interface offers users. Switching from one Office program to another, a user is empowered by the fact that commonality in features between the two programs equates to commonality in interaction. If you want to view or change the main options of a program, you look on the Tools menu for an Options item. Creating a new document is always performed from the File menu. If you're looking for the New, Save, or Print buttons on the toolbar, you always look to its left side; when you need to access Help, you look on the right side of the toolbar. If no toolbar button is available for Help, you look on the Help menu or simply press F1. Through such consistency, Office gives users the ability to leverage skills across applications.

Interface consistency spans many levels. At the highest level, all Windows programs have a common interface ”the Windows interface. (For example, dialog boxes that allow users to close them have an X in the upper right corner, and all forms are drawn using common system colors and sizes.) The next level is application consistency. Office again serves as an excellent example. Toolbars have a similar appearance, including common icons and a common order of buttons. The location of menu items and the assignation of their associated shortcut keys are also standardized. The mechanics of shortcut key behavior is consistent among Windows applications. You have complete freedom to assign specific shortcut keys to different menu items in your own application; nevertheless, you should attempt to create shortcuts that are consistent with common Windows programs. Creating application consistency demands attention to detail and considerable effort.

The next layer, and the focus of this chapter, is general design consistency. When you look at two dialog boxes in two different programs, they should seem very similar, as though they could both be part of the same program even though their content and purpose might be very different. Windows handles much of this detail by performing all the drawing routines, such as drawing a form or a combo box. However, it's up to you to use a combo box where appropriate and to assign properties that make sense to forms and controls. For instance, why give a dialog box a sizeable border or a Maximize button if doesn't resize its contents? Why create a set of 12 option buttons when a single combo box can be used? In this chapter, you'll learn to avoid these mistakes and to apply a set of standards to your interfaces to give them an appearance and behavior consistent with popular Windows applications and Windows itself.

Goals of Consistency in Interface Design

• Creating interfaces that are consistent within a program, as well as across applications
• Allowing users to leverage their existing skills (that is, to apply reusable knowledge)
• Reducing user confusion and frustration
• Producing visually attractive interfaces to build user confidence and satisfaction