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.
Auto-complete
Context
Figure 1
(Click the image to enlarge it.)
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.
Goal
The user wants to enter text quickly and accurately and would benefit from or appreciate having the system provide suggested values.
Solution
Figure 2
(Click the image to enlarge it.)
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.
Figure 3
(Click the image to enlarge it.)
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).
Figure 4
(Click the image to enlarge it.)
The suggestion list may optionally have a heading/instruction and include additional relevant information as shown in Figure 4.
Complex values
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
Figure 5
(Click the image to enlarge it.)
- Security applications should not rely on auto-completion for the entry of user IDs, passwords, or other sensitive data.
- There are numerous matches and there is no basis for ordering suggestions by probable desirability.
- The system is unable to update the suggestion list quickly enough to be useful to the user.
- Auto-complete should not be used for fixed lists. For example, a list of US states should use a simple drop-down list or combo-box rather than auto-complete.
Examples
Figure 6
(Click the image to enlarge it.)f
Figure 7
(Click the image to enlarge it.)
Accessibility
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
Context
Figure 1
(Click the image to enlarge it.)
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.
Goal
The designer wants to provide additional object information than is initially displayed in an object view or a list or table of objects.
Figure 2
(Click the image to enlarge it.)
Solution
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.
Figure 3
(Click the image to enlarge it.)
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.
General Considerations
- The visual design of the control used to access object details is distinct from that of the control used to navigate within a hierarchical tree.
- Ensure that the visual design of the objects reliably communicates to the user that additional details are available.
- Where a control is used, its visual state should be different in the displayed (e.g. ) and closed (e.g. ) states.
- Display only one level of details, i.e. don't nest details within details.
Figure 4
(Click the image to enlarge it.)
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.
Examples
Figure 5
(Click the image to enlarge it.)
Dynamic forms
Context
The user is entering information into a form. The amount of information is potentially large with considerable interdependencies among the form fields.
Goal
Complex form-filling is easy to complete without the use of context-switching or a wizard.
Solution
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.
- Controls can be enabled/disabled (Dynamic Enablement) or hidden/displayed (Dynamic Display).
- Controls used for specific fields can be replaced with other types of controls (Dynamic Controls). For example, an entry field might replace a drop-down list when the entered value choices change from being predictable to entirely unpredictable.
- The field values can be changed (Dynamic Values).
Dynamic Enablement
Figure 1
(Click the image to enlarge it.)
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).
- Ensure that the user understands the actions necessary to enable a control that is currently disabled.
- Place controls near the controls that affect their enablement to make their relationship apparent.
- Provide information about the relationships among the controls within the help system.
Dynamic Display
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.
Figure 2
(Click the image to enlarge it.)
Figure 3
(Click the image to enlarge it.)
Figure 4
(Click the image to enlarge it.)
Dynamic Controls
Figure 5
(Click the image to enlarge it.)
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.
Dynamic Values
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.
General Considerations
Figure 6
(Click the image to enlarge it.)
- The keyboard focus remains on the control with which the user last interacted even if the interaction resulted in new controls being enabled or presented. This is to both maintain the user's sense of being in control and to keep the form fully accessible to disabled users.
- Controls are positioned on a form below those that affect them. For example, the Shipping Address controls are positioned below the radio button that affects their display in Figure 2.
- The space consumed by a form is determined by the controls that are currently displayed. As illustrated in Figure 7, existing controls are re-positioned to accommodate newly displayed controls.
- As controls are added, the positions of controls above it on the form remain stable, i.e. there is no apparent movement of the top portion of the form as new controls are displayed.
- It's always possible that the user may not notice when controls are displayed or enabled as a result of an action. Hence, the default values of the newly displayed or enabled controls must be carefully selected to support the most likely user intent.
Figure 7
(Click the image to enlarge it.)
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.
Accessibility
- Newly enabled or added controls in a form should be located below the control which currently has focus.
- Do not automatically move focus to a newly enabled or added control. It should receive focus only when the user explicitly moves it (e.g. by clicking on the new control with the mouse or tabbing to the new control.)