Windows Interface Components - Secondary Windows
Although secondary windows share many characteristics with primary windows, they also differ from primary windows in behavior and use. For example, a secondary window should typically not appear as an entry on the taskbar. Secondary windows obtain or display supplemental information that is often related to the objects that appear in a primary window.
A typical secondary window includes a title bar and a frame; a user can move it by dragging its title bar or by clicking the Move command on its shortcut menu. However, a secondary window typically does not include Maximize and Minimize buttons because these sizing operations rarely apply to a secondary window. You can include a Close button to dismiss the window.
The title text is a label that describes the purpose of the window; the content of the label depends on the use of the window. The title bar does not include icons.
A typical secondary window is shown in Figure 9.1.
Figure 9.1 A secondary window
You can include status information in secondary windows, but avoid including a status bar control used in primary windows.
Like a primary window, a secondary window includes a shortcut menu with commands that apply to the window. A user can access the shortcut menu the same way as for primary windows, by clicking the title bar with the secondary mouse button.
A secondary window can also include a What's This? button in its title bar. This button allows a user to display context-sensitive Help for controls displayed in the window.
A secondary window is typically smaller than its associated primary window and smaller than the minimum display resolution. As a general rule, avoid displaying any secondary window larger than 263 dialog units x 263 dialog units. A dialog unit (DLU) is the device-independent measure to use for layout based on the current system font. For example, the recommended sizes for property sheets are as follows:
These sizes keep the window from becoming too large to display at most resolutions. However, they still provide reasonable space to display supportive information, such as Help windows, that apply to the property sheet.
More Information
For more information about dialog units, see Chapter 14, "Visual Design."
Because secondary windows often provide a large part of the user's interaction with your application, spend a significant amount of time on the design and layout of the controls you place in the windows. Consistency and aesthetics contribute to readability and comprehension of operations and tasks. This, in turn, has an impact on the overall usability of your application. In addition to the information in this chapter, you can find information about layout for controls in Chapter 8, "Menus, Controls, and Toolbars," and an overview of layout design in Chapter 14, "Visual Design."
A secondary window can be modeless or modal. A modeless secondary window allows the user to interact with either the secondary window or the primary window, just as the user can switch between primary windows. It is also well suited to situations where the user wants to repeat an action — for example, finding the occurrence of a word or formatting the properties of text.
A modal secondary window requires the user to complete interaction within the secondary window and close it before continuing with any further interaction outside the window. A secondary window can be modal in respect to its primary window.
Because modal secondary windows restrict the user's choice, limit their use to situations when additional information is required to complete a command or when it is important to prevent any further interaction until satisfying a condition.
A dependent secondary window is the most common type of secondary window. This kind of secondary window can be displayed only from a command on the interface of its primary window. In general, you should close dependent secondary windows when the primary window closes, and hide them when their primary window is hidden or minimized.
Independent secondary windows are secondary windows that the user can open without opening a primary window — for example, a property sheet displayed when the user clicks the Properties command on the menu of a desktop icon. An independent secondary window can typically be closed without regard to the state of any primary window unless there is an obvious relationship to the primary window.
When the user opens or switches from a secondary window, it is activated or deactivated like any other window. For mouse control, activate a secondary window the same way as a primary window. For keyboard control, use the ALT+F6 key combination to support the user switching between a secondary modeless window and its primary window, or between other peer secondary modeless windows related to its primary window. In addition, if you define a shortcut key to open the secondary window, use this key to activate the secondary window when it is already open. If a secondary window appears independently of its parent window, as is the case for property sheets for desktop icons, you can also provide more general access to the secondary window by supporting ALT+TAB for switching to the window.
When the user activates a primary window, bringing it to the top of the window Z order, you should also bring all of its dependent secondary windows to the top, maintaining their same respective Z orders. Similarly, activating a dependent secondary window should bring its primary window and related peer windows to the top.
When activated, a secondary window should appear at the top of the Z order of its peers. When a peer is activated, the previous topmost secondary window appears on top of its primary window but behind the newly activated secondary window. You should always display a dependent secondary window higher in the Z order than its primary window.
You can design a secondary window to appear always at the top, or topmost, of its peer secondary windows. Typically, you should use this technique only for palette windows and, even in this situation, enable users to configure this feature by providing an Always on Top property setting for the window. If you support this technique for more than one secondary window, then the windows should be managed in their own Z order within the collection of topmost windows of which they are a part.
Avoid having a secondary window with the always topmost behavior appear on top of another application's primary window (or any of the other application's dependent secondary windows) when the user activates a window of that application, unless that topmost window can also be applied to the application's windows.
When the user clicks a command that opens a secondary window, use the context of the operation to determine how to present information in that window. In property sheets, for example, set the values of the properties in that window to represent the selection.
In general, display a secondary window in the same state as the user last accessed it. For example, an Open dialog box should preserve the current folder setting between the openings of a window. However, always verify that the settings being restored are appropriate for the current system display settings, and adjust the window settings if necessary. Similarly, if you use tabbed pages for navigating through information in a secondary window, display the last page the user was viewing when the user closed the window. This makes it easier for the user to repeat an operation that is associated with the window and provides more stability in the interface.
However, if a command or task implies or requires that the user begin a process in a particular sequence or state, such as with a wizard window, you should present the secondary window using a fixed or consistent presentation. For example, entering a record into a database may require the user to enter the data in a particular sequence. Therefore, it may be more appropriate to present the input window always displaying the first entry field.
A secondary window's purpose is to provide concise, predefined information. Avoid defining a secondary window to be resizable unless it provides some benefit to the user, such as reconfiguring the arrangement or showing more information. If you support a resizable secondary window, make sure you appropriately adjust the presentation of all its elements.
You can also use an unfold button to expand a window to reveal additional options as a form of progressive disclosure. An unfold button is a command button with a label that includes >> as part of its label, as shown in Figure 9.2.
Figure 9.2 An unfold button
When the user clicks the button, the secondary window expands to its alternative size. As an option, you can use the button to "refold" the additional part of the window. This is a good alternative when the interface contains a fixed set of options or controls that seldom need to be accessed.
You can provide the user with access to additional options by including a command button that opens another secondary window. If the resulting window is independent in its operation, close the secondary window from which the user opened it and display only the new window. However, if the intent of the subsequent window is to obtain information for a field in the original secondary window, then keep the original window displayed with the dependent window on top, offset slightly to the right and below the original secondary window. However, limit the number of cascading levels to a single sublevel to avoid creating a cluttered chain of hierarchical windows.
When determining where to place a secondary window, consider a number of factors, including the use of the window, the overall display dimensions, and the reason for the appearance of the window. The first time you open the window, display it in a location that is convenient for the user to navigate to and that fully displays the window. In a multiple-monitor configuration, display the secondary window on the same monitor as its primary window. If neither of these guidelines apply, horizontally center the secondary window within the primary window, just below the title bar, menu bar, and any docked toolbars. If the user then moves the window, display it at this location the next time the user opens the window, adjusted as necessary to the current display configuration.
When defining a secondary window, you can assign the ENTER key to activate a particular command button, called the default button, in the window. The system distinguishes the default button from other command buttons by adding a bold outline around it.
Define the default button to be the most likely action, such as a confirmation action or an action that applies transactions made in the secondary window. Avoid making a command button the default button if its action is irreversible or destructive. For example, in a text search and substitution window, do not use a Replace All button as the default button for the window.
You can change the default button as the user interacts with the window. For example, if the user navigates to a command button that is not the default button, the new button temporarily becomes the default. In such a case, the new default button takes on the default appearance and the former default button loses the default appearance. Similarly, if the user moves the input focus to another control within the window that is not a command button, the original default button resumes the default appearance.
Defining one of your command buttons as a default button is a common convention. However, when there is no appropriate button to designate as the default button or you need to apply the ENTER key to another function (for example, entering new lines in a multi-line text control), you do not need to define a default button for the window. In addition, when a particular control has the input focus and requires use of the ENTER key, you can temporarily have no button defined as the default. Then when the user moves the input focus out of the control, you can restore the default button.
Optionally, you can use double-clicking a single-selection control, such as an option button or single-selection list, as a shortcut technique to set or select the option and carry out the action of the default button of the secondary window.
With the mouse, navigating to a particular field or control is accomplished by the user pointing to the field and clicking it. For button controls, this action also activates that button. For example, for check boxes, it toggles the check box setting; for command buttons, it carries out the command associated with that button.
The keyboard interface for navigation in secondary windows uses the TAB and SHIFT+TAB keys to move between the next and previous controls, respectively. Each control has a property that determines its place in the navigation order. Set this property such that the user can move through the secondary window following the usual conventions for reading: in Western countries, left-to-right and top-to-bottom, with the primary control the user interacts with located in the upper left area of the window.
You can use static text fields to provide access to controls that do not have labels. However, when the user navigates to that label, move the input focus to the associated control. Order controls such that the user can progress through the window in a logical sequence, proceeding through groups of related controls. Command buttons for handling overall window transactions are usually at the end of the order sequence.
You do not need to provide TAB key access to every control in the window. For example, because option buttons typically appear as a group, use the TAB key for moving the input focus to the current set choice in that group, but not between individual options — use arrow keys for this purpose. However, for a group of check boxes, provide TAB navigation to each control because their settings are independent of each other. Combination controls such as combo boxes, drop-down combo boxes, and spin boxes are considered single controls for navigational purposes.
Optionally, you can use arrow keys to support keyboard navigation between controls in addition to the TAB navigation technique wherever the interface does not require those keys. For example, you can use the UP ARROW and DOWN ARROW keys to navigate between single-line text boxes or within a group of check boxes or command buttons. Always use arrow keys to navigate between option button choices and within list box controls.
Also define access keys to provide navigation to controls within a secondary window. This allows the user to access a control by pressing and holding the ALT key and an alphanumeric key that matches the access key character designated in the label of the control.
More Information
For more information about guidelines for selecting access keys, see Chapter 5, "Input Basics."
Unmodified alphanumeric keys also support navigation if the control that currently has the input focus does not use these keys for input. For example, if the input focus is currently on a check box control and the user presses a key, the input focus moves to the control with the matching access character. However, if the input focus is in a control where an alphanumeric key is used as text input, such as a text box or list box, the user will not be able to use it for navigation within the window without using it in combination with the ALT key.
Access keys not only allow the user to navigate to the matching control, they have the same effect as clicking the control with the mouse. For example, pressing the access key for a command button carries out the action associated with that button. To ensure the user efficient access to all controls, select unique access keys within a secondary window. If two or more controls share the same access key, pressing that key moves the input focus to the next matching control but does not activate it.
You can also use access keys to support navigation to a control, but then return the input focus to the control from which the user navigated. For example, when the user presses the access key for a specific command button that modifies the content of a list box, you can return the input focus to the list box after the command has been carried out.
Avoid assigning access keys to OK and Cancel command buttons because the ENTER and ESC keys, respectively, should typically provide access to these buttons. Pressing ENTER should always navigate to the default command button, if one exists, and invokes the action associated with that button. If there is no current default command button, then the ENTER key can be used for a control.
In some situations you may want to include a hyperlink to a Web page in your secondary window. This works best when you use the link to display supplemental or related information about the topics described in the secondary window. Do not use hyperlinks to replace the standard OK and Cancel buttons or other actions.
You can create hyperlinks in a secondary window by using a text box control without its visible border or by using the WebBrowser control. However you implement hyperlinks, always use display and interaction conventions consistent with the system conventions. For example, display the text for the link using the system's settings for link colors, and display the hand pointer when the user moves the pointer over the link.
When you include a hyperlink in your secondary window, always express what will happen when the link is clicked, or why the user would want to click it. In some cases, connecting to the Web can be expensive, time consuming, or not currently available. Make sure that users have as much information as possible so they can decide whether or not the link is worth clicking. Avoid using the phrase "click here," which takes up valuable room on the screen. Most users understand the concept of links.
| Correct | Incorrect |
| Register your product online | Click here to register your product |
| Online Support | For product support, click here |
More Information
For more information about designing hyperlinks, see Chapter 10, "Window Management."
Validate the user's input for a field or control in a secondary window as closely to the point of input as possible. Ideally, validate the user's input when the user types in text or chooses an option. You can either disallow the input or use audio and visual feedback, such as balloon tips, to alert the user that the data is not appropriate. You can also display a message box, particularly if the user repeatedly tries to enter invalid input. In either case, make sure you provide enough information to help the user enter appropriate data. In any case, avoid requiring that the user enter valid data before navigating away from a control.
You can also reduce invalid feedback by using controls that limit selection to a specific set of choices — for example, check boxes, option buttons, or drop-down lists — or preset the field with a reasonable default value.
If it is not possible to validate input at the point of entry, consider validating the input when the user navigates away from the control. If this is not feasible, then validate it when the transaction is committed or whenever the user attempts to close the window. At that time, leave the window open and display a message; after the user dismisses the message, set the input focus to the control with the inappropriate data.
Fundamentals of Designing User Interaction
Design Specifications and Guidelines