This section is primarily taken from the Microsoft Visual Basic 6.0 Programmer's Guide (Microsoft, 1998).
Being an artist is not a prerequisite for creating a great UI. Most of the principles of UI design are the same as the basic design principles taught in any elementary art class. The design principles of composition, color, and so forth apply equally well to a computer screen, a sheet of paper, or a canvas.
Although programming tools make it easy to create a UI by simply dragging controls onto a screen-based form or Web page, a little planning up front can make a big difference in the usability of an application. The development team might consider designing UI elements on paper first, determining which control mechanisms are needed, the relative importance of the different elements, and the relationships between the control mechanisms.
These basic design principles apply equally well to a native application UI or a Web-based UI. The application code required to implement these principles may be radically different for native and Web-based applications; however, designing the UI for both types of applications is a similar process.
Several common elements are used in many implementations of UIs. These UI elements, when used properly, can help create the efficiency and productivity gains for the team's user community. Although these elements may look slightly different in a native interface than in a Web-based interface, they all function similarly in both environments.
In the Windows-based application world, not all UIs look or behave the same. There are three main styles of UI:
In determining which interface style is best, the development team needs to look at the purpose of the application, as well as the work of the users. A simple clock application would be best suited to the SDI style, because it's not likely someone would need more than one clock open at a time. (In the case of this rare event, a second instance of the SDI application can be opened.) An application for processing insurance claims might lend itself to the MDI style, because a clerk is likely to be working on more than one claim at a time or might need to compare two claims. The Windows Explorer-style interface is being used for many new applications, because it lends itself to navigating or browsing through large numbers of documents, pictures, or files. Reports can provide a permanent record of the information at a particular point in time, and do not require direct interaction with the application to be useful to the user.
Most applications need to directly communicate with the user. In Windows-based applications, dialog boxes prompt the user for data that the application needs to continue or to display information to the user. Dialog boxes are a specialized type of form that present information and generally require user interaction. Dialog boxes typically must be closed (hidden or unloaded) before the user can continue working with the application.
Applications must also present choices to their users, ranging from a simple yes/no option to selecting from a list containing hundreds of possibilities. Several controls can be useful in presenting choices. Table 7.1 summarizes a few of these controls and their appropriate usage.
Table 7.1 Controls and their usage
|Label||Text that is displayed only.|
|Text box||Text that can be edited by the user. Text boxes are used to gather free-form information from the user. Text boxes are effectively used to gather numerical information as well as alphabetic information such as user IDs and passwords.|
|Command button||Typically rectangular buttons in a dialog box that carry out a command. When the button is chosen, it executes the appropriate action and typically looks as if it's being pushed in and released.|
|Check box||A small set of choices from which a user can choose one or more options. It indicates whether a particular condition is on or off, true or false, yes or no. When displayed in a group, check boxes work independently of each other; the user can select any number of check boxes at the same time.|
|Option button||A small set of options from which the user can choose just one. Option buttons should always work as part of a group; selecting one option button immediately clears all the other buttons in the group.|
|List box||A scrollable list of choices. Typically, the list of choices is displayed vertically in a single column, although multiple columns can be used as well. If the number of items exceeds what can be displayed in the box, scroll bars should be pre- sented. Often multiple choices can be made from a single list by using the CTRL key to indicate multiple selections. Addi- tionally, the box can drop down to display the list of choices.|
|Combo box||A scrollable list of choices along with a text edit field. Iden- tical to a list box, except the user can either type information in the text box or choose the item from the list.|
|Slider control||A relative range that indicates the current position on a scale. These controls can be used to control program input, such as a volume control, or to adjust the colors in a picture.|
|Progress indicator||A percentage of a particular process that has been completed. These controls are useful as indicators that the application is performing work. If an excessive amount of working time is required, an estimate of the time remaining to complete the operation can also be supplied.|
When requiring that the user make a choice, it is preferable to provide a default setting for the choice.
The composition or layout of each UI element not only influences its aesthetic appeal, but also has a tremendous impact on the usability of the application. Composition includes such factors as the following:
In most interface designs, not all elements are equally important. Careful design ensures that users readily understand which elements are more important. These elements should appear in prominent locations, and less important, or less frequently accessed, elements should be relegated to less prominent locations.
Many languages are read from left to right and from top to bottom on a page. The same holds true for a computer screen. Most users' eyes are drawn to the upper left portion of the screen first, so the most important element should go there. For example, if the information on a form is related to a customer, the name field should be displayed where it will be seen first. Buttons, such as OK or Next, should be placed in the lower right portion of the screen, because users normally won't need these buttons until they have finished working with the form.
The grouping of elements and controls is also important. Information should be grouped logically according to function or relationship. For example, because their functions are related, buttons for navigating a database should be grouped together visually, rather than scattered throughout a form. The same applies to information; fields for a name and an address are generally grouped together, because they are closely related. In many cases, the relationships between controls can be reinforced with frames.
Often users move from one control area to another by pressing the TAB key. For input forms such as dialog boxes, maintaining a meaningful TAB order improves the user experience.
Consistency is a virtue in UI design. A consistent look and feel creates harmony in an application—everything seems to fit together. A lack of consistency in the interface can be confusing, and can make an application seem chaotic, disorganized, and cheap, possibly even causing users to doubt the reliability of an application.
For visual consistency, the development team should establish a design strategy and style conventions in the early phases of the development process. Design elements such as the types of controls, standards for size and grouping of controls, and font choices should be established in advance. As discussed in Chapters 5 and 6, prototypes and proof-of-concept systems can be used to help make this type of design decision. Consistency in the following areas should be considered:
Affordances give visual clues about the function of a visual element. Although the term may be unfamiliar, examples of affordances are everywhere. For example, a bicycle handgrip that has depressions where fingers should be placed makes it obvious that it is meant to be gripped. Push buttons, knobs, and light switches are all affordances, because their purpose can be discerned just by looking at them.
A UI should make ample use of affordances. For instance, three-dimensional effects on command buttons indicate to users that the buttons are meant to be pushed. If a command button has a flat border, this affordance is lost, and it is no longer clear to users that the button is a command button. However, the team might decide that flat buttons are more appropriate for a particular type of application, such as a multimedia application. Breaking with convention is acceptable as long as consistency is maintained throughout the application.
Another example of a common affordance is the text box. Users expect that a box with a border and a white background will contain editable text. Although it's possible to display a text box with no border, doing so makes the box look like a label that is not editable.
The use of white space in a UI can help to emphasize elements and improve usability. White space doesn't necessarily have to be white in color; the term refers to the use of blank space between and around information on a form. Too many controls and information can lead to a cluttered interface, making it difficult to find individual fields, controls, or information. Incorporating white space in the application design emphasizes the form's design elements.
Consistent spacing between controls and alignment of vertical and horizontal elements can also make the design more usable. Text in a magazine is arranged in orderly columns with even spacing between lines to make it easier to read; similarly, an orderly interface is easier to read.
Perhaps the most important principle of interface design is that of simplicity. If an application's interface looks difficult, the application is probably difficult to use. From an aesthetic standpoint, a clean, simple design is always preferable.
A common pitfall in interface design is to try and model the interface after real-world artifacts. For example, suppose the team has been asked to create an application for completing insurance forms. A natural reaction is to design an interface that exactly duplicates the paper insurance form on screen. This strategy has several problems, including:
A far better approach is to design the UI specifically for the application, perhaps providing a printed duplicate (with print preview) of the original paper form. By creating logical groupings of fields from the original form and using a tabbed interface or several linked forms, all the information can be presented without requiring users to scroll. Other options include:
Observational testing of the application is the best way to test for simplicity. If a typical user can't immediately accomplish a desired task without assistance, a redesign may be in order.
The use of color in the interface can add visual appeal, but it's easy to overuse it. With many displays now capable of displaying millions of colors, it's often tempting to use as many as possible. Color, like the other basic design principles, can be problematic if not carefully considered in the initial design.
Preference for colors varies widely; the user's taste may not be the same as the team's preferences. Colors can evoke strong emotions, and certain colors have cultural significance. It's usually best to stay conservative, using softer, more neutral colors.
Choice of colors is influenced by the intended audience, as well as by the tone or mood the application designers are trying to convey. Bright reds, greens, and yellows might be appropriate for a children's application, but would hardly evoke an impression of fiscal responsibility in a banking application.
Small amounts of bright color can be used effectively to emphasize or draw attention to an important area. However, the number of colors used in an application should be limited, and the color scheme should be consistent. It's best to stick with a standard 16-color palette if possible, because dithering can cause some colors outside this palette range to disappear when viewed on a 16-color display.
Another consideration in the use of color is color-blindness. Many people are unable to tell the difference between different combinations of primary colors, such as red and green. To someone with this condition, red text on a green background is invisible.
The use of pictures and icons can add visual interest to the application, but careful design is essential. Images can convey information efficiently without the need for text, but different people perceive images differently.
Toolbars with icons that represent various functions are a useful interface device, but if users can't readily identify the function represented by the icons, they can be counterproductive. When designing toolbar icons, it's important to follow the standards already established for other applications. For example, many applications use a sheet of paper with a folded corner to represent a New File icon. Although there may be a better metaphor for this function, representing it differently could confuse users.
It's also important to consider the cultural significance of images. Many programs use a picture of a rural-style mailbox with a flag to represent mail functions. This is primarily an American icon; users in other countries or cultures probably won't recognize it as a mailbox.
When designing icons and images, the best rule is "Keep them simple." Complex pictures with a lot of colors don't degrade well when they are displayed as a 16-by-16-pixel toolbar icon, or when displayed at high screen resolutions.
Because text is often used to communicate information, selecting fonts that are easily read at different resolutions and on different types of displays is an important part of designing the UI. It's best to stick with simple fonts where possible. Script and other decorative fonts generally look better in print than on the screen, and they can be difficult to read at smaller point sizes.
Generally, the standard Windows fonts, such as Arial, Times New Roman, or System should be used. Otherwise, the team must distribute the selected font with the application, because if the application is used on a computer that doesn't have the selected font installed, the system will make a substitution that might change the appearance of the application.
When designing for an international audience, it is important to investigate what fonts that audience is likely to have available. Also, the team needs to consider text expansion, because text strings can take up to 50 percent more space in some languages.
Again, design consistency is important when choosing fonts. In most cases, no more than two fonts at two or three different point sizes should be used in a single application. Too many fonts can leave the application looking like a pieced-together ransom note.
Ultimately users determine the usability of any application. Interface design is an iterative process, and rarely is the first pass at an application's UI design going to yield a perfect interface. Involving users early in the design process creates a better, more usable interface with less effort.
A good place to start when designing a UI is to look at some of the best-selling applications. Much research, effort, and resources are expended on the usability of these applications. They have many things in common, such as toolbars, status bars, ToolTips, context-sensitive menus, and tabbed dialog boxes.
The team's own experience as users of software will also yield some insight into good UI design. By thinking about what works and what doesn't, and about how what doesn't work can be modified, the team can identify examples to emulate and examples to avoid. However, it's important to recognize that the personal likes and dislikes of a small team might not match those of the users by validating ideas with user prototypes.
Additionally, most successful applications provide choices to accommodate varying user preferences. For instance, Windows Explorer allows users to copy files with menus, keyboard commands, or drag-and-drop functions. Providing options broadens the appeal of the application; at a minimum, all functions must be accessible by both mouse and keyboard.
One of the main advantages of the Windows operating systems is that they present a common interface across all applications. Users who can work with one Windows-based application can easily learn another one that uses the same basic interface, but can't as easily learn one that strays too far from the established interface guidelines.
Menus are a good example of this common interface. Most Windows-based applications follow the standard of positioning a File menu at the left end of the menu bar and a Help menu at the right end, with optional menus such as Edit and Tools in between. It can be argued that Documents would be a better name than File, or that the Help menu should come first. There's nothing to prevent the team from breaking with the standard, but doing so can confuse users and decrease the usability of the application.
The placement of commands is also important. For example, users expect to find the Copy, Cut, and Paste commands on the Edit menu; moving them to the File menu would be confusing. It's best not to deviate from the established guidelines without very solid reasons.
One of the key concepts in usability testing is that of discoverability. If users can't discover how to use a feature (or even that the feature exists), that feature is worthless. For example, many Windows 3.1 users were never aware that the ALT, TAB key combination could be used to switch between open applications. There was no clue anywhere in the interface to help users discover this feature.
To test the discoverability of a feature, the team should ask users to perform a task without explaining how to do it. If they can't accomplish the task, or if several attempts are necessary to accomplish it, the discoverability of that feature needs work.
All computer users can become familiar with menu-based navigation systems. Like many of the UI elements, consistent use of a menuing system is most important. As with other usability issues, the team should use the Windows standards to improve usability through discovery. With the improvement of browser scripting, Web-based applications can take on the same menuing styles as the classic native application menu systems. Additionally, native applications can use the link and page metaphors of Web-based applications to improve navigation throughout the application. Once again, simplicity and consistency are the key points to designing an application navigation system.
No matter how great the UI, there will be times that a user needs assistance. The user assistance model for the application should include online help and printed documentation, and it may include user assistance devices, such as ToolTips, status bars, "What's This?" help, and wizards.
The user assistance model should be designed early in the development process, just like any other part of the application. The model's features will vary depending on the complexity of the application and the sophistication of the intended audience.