Users employ software to achieve specific goals. Also, user interface designers have goals for the designs they create. Design Patterns provide established solutions based on sound design principles that enable these goals as they occur within specific task and environmental contexts.
The user is entering information into a form. Information has either been entered into these form fields in the past or there is some other collection of information meaningful to the user's task from which possible field values can be drawn.
The user wants to enter text quickly and accurately and would benefit from or appreciate having the system provide suggested values.
The solution involves presenting the user, upon the entry of the first character, with a list of suggested values. These values are based on previously entered values or some other meaningful collection. A common example of this is the entry of email recipient addresses for which the suggestions are typically based on the user's contact list and previously entered recipients (see Figure 1). The matches can be based on any number of item attributes, e.g., the contact name and/or e-mail address.
The matched sub-string within each suggestion is emphasized, e.g., it is displayed in bold in Figure 1.
Figure 2 provides another useful example of auto-completion, i.e., creation of software in a specialized editor. Based on the known constraints of the system, the user is provided with a list of suggestions to complete keywords or other common elements.
A suggestion is added to the list when the currently entered string matches a sub-string of an item in the set of potential suggestions. The matching sub-string may be at any position within a suggestion although there may be task contexts in which the sub-string may be usefully restricted to a particular position, e.g., the beginning. However, the emphasis should be on making it as convenient for the user as possible.
Further, suggestions may be formed by concatenating separate attributes of items, e.g., recipient name and e-mail address.
The suggestions are ordered based on rules that are driven by the current task. To continue the e-mail example, the recipient suggestions are ordered by frequency of use; if ties exist, the most recently used suggestion is positioned first.
The set of suggestions are updated each time the user adds or removes characters. The treatment of the suggestion list when there are no matches depends on the task context. Indicate that there are no matches when the user is trying to specify a value from a well-defined set, e.g., an object's properties; close the suggestion list when the set of possible values is ill-defined, e.g., all e-mail addresses. However, the list may remain if it contains other, task-specific choices (see Figure 3).
The suggestion list may optionally have a heading/instruction and include additional relevant information as shown in Figure 4.
The Auto-complete pattern can also be applied to situations other than the entry of simple text values. Figure 5 illustrates the use of auto-complete to specify a property to set. Once the property is selected from the suggestion list, its value can then be set.
Don't use when
Page readers will re-read the page whenever the page is refreshed. Avoid this by not refreshing the page when the suggestion list is updated.
Details on Demand
Users are routinely presented with objects within tables as well as graphically. These displays typically include only a few key properties of each item due to space limitations and to avoid overwhelming the user. Nonetheless, the user may need a bit more information than is initially displayed to evaluate and edit object properties. Routing the user to another view for the additional detail is distracting, potentially confusing and removes the user from the current context.
The designer wants to provide additional object information than is initially displayed in an object view or a list or table of objects.
In response to a user action, immediately display the additional information adjacent to the object or table. Displaying the details must not require reloading the page.
The action might be clicking on the object, clicking on a control associated with the object or just hovering over the object. Which action is appropriate is determined by the context in which the table is displayed. When clicking on an associated control is used, e.g., in Figure 1, remove the details from view upon a subsequent click on the control. Moving off the object would remove the details when they are displayed on hover. Details that are persistent, i.e., not based on hovering, should also provide a close control.
There are three principal approaches to the Details on Demand:
- Dedicated space where the same space is re-used for all the object details. The details of only one object can be displayed at a time.
- Overlay displays the details in a callout that resides over the other table data (see Figures 1 and 2).
- Displacement (see Figures 3 and 4) pushes the other table data away to make room for the object details.
Don't use when
Details on Details is most appropriate for displaying limited amounts of information. Other patterns to be described in the future (Overview Plus Detail and Two-Panel Browser) are more appropriate for displaying considerable additional information for listed or tabled objects.
The user is entering information into a form. The amount of information is potentially large with considerable interdependencies among the form fields.
Complex form-filling is easy to complete without the use of context-switching or a wizard.
Identify dependencies among the information required to complete the task. Orient the user toward the information that is required early in the process while de-emphasizing the remaining information. Update the form dynamically as the user provides information. This pattern reflects the principle of Progressive Disclosure in which users are shielded from unnecessary complexity.
Dynamically updating the form avoids the required mental switching of context as users navigate through the sequential forms associated with wizards.
This technique is particularly useful for walking inexperienced users through unusual or infrequently performed tasks. It is easy for the user to change previous responses and directly see the impact on the form and, therefore, the task. Dynamically displaying controls helps users avoid errors by only enabling or displaying relevant controls given the state of the form. It also allows the designer to manage the sequence in which controls are used, if desired.
Dynamic forms utilize different techniques to tailor the form as the user provides information.
As choices are made, enable additional controls as they become relevant. Dynamic Enablement, depicted in Figure 1, is useful when you want to present a stable interface. Lotus Notes, for example, uses Dynamic Enablement to manage the controls associated with the automatic processing of meeting invitations (see Figure 1).
As it presents a stable form from the beginning, Dynamic Enablement can still result in forms that appear complex and intimidating. In contrast, with Dynamic Display, controls are shown only as choices are made and are thus less intimidating. For example, Tivoli Continuous Data Protection v3.1 (see Figure 2) dynamically displays controls based on the frequency the user chooses to protect their E-mail. Figures 3 and 4 present another example of Dynamic Display.
As the user provides information, the nature of the information collected by individual fields can change. For example, the state/province within which a user resides can be predicted when the country in which they live is known. If the user is permitted to change the form to a country unknown to the application, the state/province field would be changed from a drop-down list, for example, to an open-ended entry field. Figure 5 offers a simple example of Dynamic Controls.
Update the available values in fields based on the values in other controls. For example, a list of cities would be updated to reflect the appropriate values when the associated value in a State control is changed. Figure 6 illustrates the use of Dynamic Values by the IBM Global Print solution.
Don't use when
The complete user interface is changed dramatically rather than simply changing the state of a focused subset of controls. Such an application of this pattern will undermine the user's sense of control.