This chapter describes the navigation model for mouse and keyboard users. Navigation refers to how the user moves pointers and cursors within your interface. This chapter also discusses the activation of controls. Activation refers to using controls to perform actions, such as initiating an action choice.
Input devices have different actions, depending on which part of the interface the user is interacting with. Due to the inherent flexibility in mouse manipulation, users with a mouse and keyboard can access windows and controls more easily than users with just a keyboard.
This chapter describes:
How users know which element they can currently interact with
How users navigate within the interface
How users activate controls and change values
Shortcuts to help users navigate, select, activate, and change the value of elements
Applications that interact with the user via windows must present information in a clear manner. Similarly designed windows help the user to understand the interface better. The system requires that an application manage the windows in the interface. That application is called the window manager . The window manager is a specific application that manages the windows in an interface. The window manager follows the same guidelines for input, navigation, selection, and activation as described in this book.
The window manager supports multiple applications, each with one or more primary windows. It also supports secondary windows and associates each secondary window with a primary window or another secondary window.
You can design the window manager to allow users to configure it, as well as other elements, including key bindings, menu contents, and default window controls. The window manager supplies the default settings. Users can toggle between their configured settings and the default settings.
A typical interface has several applications in operation simultaneously, and each application has a primary window. Applications can also have secondary windows to communicate context-specific interactions to users.
For more information, see the Primary Window and Secondary Window reference pages.
Several windows may be open simultaneously, but input from the keyboard is directed to only one of them at a given time. This window is called the active window.
Similarly, the active window may contain many controls, but keyboard input is directed to only one of those controls at a given time. The control to which keyboard input is directed is said to have the input focus , also called keyboard focus, or just focus.
The control with input focus generally displays focus emphasis, indicated by a cursor on or within the control. For example, a push button displays an element cursor on it when it has focus, a list box displays an element cursor on some item within the list when it has focus, and a text-entry field displays a text cursor at the current insertion point within the text when it has focus.
Some controls may display a graphical cue similar to a cursor even when the control does not have focus. In that case, when the control has focus the graphical cue changes in some way. For example, the text cursor may be visible even in a text-entry field that does not have focus, but might flash on and off when the field does have focus.
Stacking order determines what parts of windows or controls are visible when they overlap. The user can choose whether to have the stacking order change as the focus changes. Changes in the stacking order are especially important at the window level. There are two different stacking policies: manual stacking order and automatic stacking order (see Figure 5-1).
Manual stacking order refers to a window that does not have to be on top of all other windows to be active, meaning the user can interact with a window without changing the stacking order of the window hierarchy. With manual stacking order, the user must perform a specific action to surface an active or inactive window to the top of the stacking order.
Automatic stacking order refers to an active window that the interface automatically surfaces to the top of the stacking order when it receives input focus. The user does not need to explicitly surface the window.
Within a window, stacking order is less important since controls or elements generally do not overlap one another. An important exception is within areas devoted to graphics. In this case, you can use an automatic stacking policy; but most commonly, selected graphics elements change their stacking order by specific actions, typically chosen from a menu.
Only one window and only one control within that window can have input focus at any given time. Determining which window or control will receive input focus is dependent on the focus policy that is in effect. A focus policy is a specific policy for moving the focus among windows and controls. There are two focus policies: explicit focus and implicit focus. The user can choose which focus policy to use, depending on the task and environment.
When using an explicit focus policy, sometimes called click-to-type, the user must explicitly indicate which window or control receives the input focus by clicking a mouse button or by using navigation keys on the keyboard. When a new window is created, it often receives the input focus automatically.
Remember that input focus determines only the window or control affected by keyboard operations. Mouse-based operations (clicking on a button for example) affect the window and control under the pointer, regardless of the current input focus. In fact, when an explicit focus policy is in effect, most mouse-based operations move the focus to the window and control that contain the pointer.
When an implicit focus policy is in effect, keyboard events are automatically sent to the window and control where the pointer is located. Implicit focus is sometimes referred to as pointer focus, focus-follows-mouse, or real estate-driven focus.
Different parts of the interface can have different focus policies. For example, you can use an implicit focus policy to determine which window has focus (that is, the one containing the pointer); you can use an explicit focus policy to determine which control within the window has focus (for example, the user has to click on a text-entry field to move focus to it). Mouse users generally do not have to be concerned with the current focus policy because the mouse button action generally passes to the control under the pointer.
“Navigating Within the Interface” provides more information about navigation within particular parts of the interface.
The user can choose either manual or automatic stacking order when using implicit or explicit focus. Table 5-1 summarizes how stacking order and focus policies work together within the interface at the window level.
Table 5-1. Summary of Stacking Order and Focus Policies
| If you have... | And... | Then... |
|---|---|---|
| Automatic stacking order | Implicit focus | User surfaces the window by moving the pointer into it (after a delay or when the pointer stops moving). |
| Explicit focus | User must click on the window to surface it. | |
| Manual stacking order | Implicit focus | User moves the pointer over the window to make it active but does not surface it. Clicking in the window frame surfaces the window. |
| Explicit focus | User must click on the window to make it active; but clicking on the window does not make it surface. Clicking in the window frame surfaces the window. |
For more information, see the Active Window, Cursor, Input Focus, Secondary Window, Stacking Order, and Window Navigation reference pages.
This section discusses how the user navigates within and between the elements of your interface when an explicit focus policy is in effect. Users can navigate in the following ways:
Between windows (window navigation)
Within windows
Between tab groups in windows (tab group navigation)
Between controls within tab groups (control navigation)
Within controls (internal navigation)
Between and within menus (menu navigation)
Figure 5-2 illustrates navigating between and within window families.
For more information on mouse and keyboard navigation, see Appendix B, “Keyboard Model and Key Bindings” and Appendix C, “Mouse Techniques”.
See also the Cursor, Input Focus, Keyboard (Device), Mouse (Device), and Pointer reference pages.
Each primary window may have one or more related secondary windows. Together, a primary window and its related secondary windows are called a window family. Users can navigate within a window family and between window families.
Window navigation for mouse users differs according to which focus policy is in effect. For environments with implicit focus, the input focus is wherever the pointer is located. For environments with explicit focus, users explicitly indicate where the input focus is by moving the pointer to the appropriate window or control and clicking a mouse button or by using the following keys to specify which window or control has focus:
| Alt Esc | Moves the focus forward from one window family to the next. | |
| Shift Alt Esc | Moves the focus backward from one window family to the next. | |
| Alt F6 | Moves the focus forward among windows within a window family. | |
| Shift Alt F6 | Moves the focus backward among windows within a window family. |
When you use a window icon box, the window icon box is a separate primary window. When you do not use a window icon box, each window icon that appears on the desktop is a separate window family, and so Alt Esc and Shift Alt Esc navigate to window icons as well as to open windows.
Using a mouse and explicit focus, the user can move between windows by moving the pointer to the window to receive focus and clicking the SELECT button. With implicit focus, the window under the pointer automatically becomes the active window.
For more information, see the Window Navigation reference page.
Using implicit focus within a window, the user can navigate to a control by moving the pointer to the control. With explicit focus, the user can navigate to a control by moving the mouse to it and clicking on it or by using the keyboard.
The following sections describe how to use the keyboard to navigate within a window. The user can navigate between groups of controls (tab groups) and between individual controls. For example, the user might navigate between a radio box and a combination box (groups of controls) and between radio buttons within a radio box (individual controls). Also, the user can navigate within controls, for example, within the text-entry field in the combination box to move between characters in the field.
The following sections describe:
Navigating between tab groups
Navigating between controls
Navigating within controls
Focus-only navigation
A tab group is a control or group of controls that the user can navigate to by pressing Tab (to move forward), Shift Tab (to move backward), or by moving the pointer to a tab group and pressing the SELECT button. Within some controls, multiline text in particular, Tab is interpreted by the control itself (for example, in text it may insert a Tab character). In those cases, the user can press Ctrl Tab to move focus forward to the next tab group and Ctrl Shift Tab to move backward.
Tab groups fall into two categories:
Tab groups that contain a group of other controls (for example, a radio box that contains a group of radio buttons)
Tab groups that consist of a single control (for example, a text field)
Within a tab group that contains a group of controls, the user must navigate among those controls (see “Navigating Between Controls”). Within a tab group that consists of a single control, such as a text-entry field, the user must navigate within the control (see “Navigating Within Controls”). Figure 5-3 illustrates navigating between tab groups.
The user can move focus between controls within a tab group (or within a window without distinct tab groups) by using directional keys or by moving the pointer to a specific control and pressing the SELECT button.
You can treat a push button as an individual control in a tab group or as an individual tab group. The user can then navigate among the push buttons by using directional keys, by pressing Tab, or both, depending on how you design the push buttons.
For more information, see the Push Button (Control) reference page.
Keyboard users use directional keys to move within a control such as a text-entry field or list box (see Figure 5-4). Mouse users move the pointer and press the SELECT button to move within a control.
Even when you use an implicit focus policy within a window, you can still use an explicit focus policy within an individual control. For example, when you use an implicit focus policy, a text-entry field has focus only while the pointer is within the text-entry field. The user must still click the SELECT button or use keyboard navigation to move the text cursor; the cursor does not move when the mouse is moved within the text-entry field.
When you use an explicit focus policy within a window, a mouse user can move focus to a control or element by clicking the SELECT button on it. However, this sometimes has another effect; for example, it could activate a push button.
Focus-only navigation allows for moving focus to a control without causing side effects. With focus-only navigation, the user can click Ctrl SELECT on a control to bring focus to it but not activate it.
Within some controls, Ctrl SELECT may already be defined as an action. In this case, focus-only navigation is disabled and the control's definition remains in effect.
For more information, see the Control Navigation, Internal Navigation , and Tab Group reference pages.
Mouse users click or press the SELECT button or the MENU button to display menus and navigate among them. Menus, other than menu bars and tear-off menus, are temporarily displayed (see Figure 5-5). The user can display pop-up menus by using the MENU button. The user can display pull-down, option, or cascaded menus by pressing the SELECT button or the MENU button on a cascading choice.
Pop-up menus and cascaded menus are spring-loaded — that is, when the user makes a noncascading choice within the menu, the menu automatically disappears. These menus may also be spring sensitive. A menu becomes spring sensitive when it appears as a result of pressing an appropriate mouse button, or when an appropriate mouse button is pressed in a menu that is already displayed.
In a spring-sensitive menu, an active cursor follows the pointer as the user moves the pointer through the menu. The following may occur in a spring-sensitive menu:
When the user moves the pointer over a cascading choice, a corresponding cascaded menu immediately appears; if the user moves the pointer off the cascading choice (but not into the cascaded menu), the cascaded menu disappears.
If the user releases a mouse button over a noncascading choice within the menu, that choice is activated (or toggled), and the menu disappears.
When a menu is spring sensitive, you should use an implicit focus policy within the menu. When a menu is not spring sensitive, you should use an explicit focus policy within the menu. The user may move the cursor within the menu only by pressing an appropriate mouse button within the menu (which makes it spring sensitive) or by using keyboard navigation.
When a menu appears as a result of a keyboard operation, the menu is not spring sensitive. In addition, if a spring-loaded menu remains displayed when a mouse button is released (for example, if it is released on a cascading choice), the menu stops being spring sensitive.
Menus displayed by mouse users may or may not be spring sensitive. Menus displayed by keyboard-only users are never spring sensitive and always use an explicit focus policy.
Keyboard-only users navigate menus by using the directional keys and special keys. The user presses F10 (or Shift Menu) to move to menu bars and presses Menu (or Shift F10) to display pop-up menus. Once the cursor is within a menu or menu system, the user navigates by pressing directional keys.
Some lists, like menus, may be displayed only temporarily. In particular, drop-down lists and drop-down combination boxes contain a list button and cascading choice from which a spring-loaded list may be temporarily displayed.
Like menus, spring-loaded lists may or may not be spring sensitive, depending on the following:
If a list is displayed as the result of the user pressing the SELECT button over a list button, the list is spring sensitive. Releasing the SELECT button on an item in the list selects it and removes the list.
If the list is displayed as the result of a keyboard operation or remains displayed when the user releases the SELECT button over the list button, the list, though displayed, is not spring sensitive. The user can use keyboard navigation to move the cursor through the list.
For more information, see the Menu (Control), Menu Guidelines , and Spring-Loaded (Control Type) reference pages.
When the user clicks the SELECT button on a choice that can be activated, an action occurs. When the user presses the SELECT button on a push button, the push button appears with ready emphasis to indicate that releasing the SELECT button will activate the push button.
Choices that support activation include action choices, dialog choices, and cascading choices.
For more information, see the Action (Choice Type), Cascading (Choice Type), and Dialog (Choice Type) reference pages.
There are several ways the user can change the value that is managed by a control, depending on the type of control. Controls that allow the user to change values include check boxes, radio buttons, spin boxes, and sliders.
In a check box, the user can click the SELECT button while the pointer is on the control or press Spacebar while the focus is on the control to change the value of the check box. For example, if the user clicks the SELECT button while the pointer is on a check box that represents the choice Boldface, the check box changes from its current state and cycles through the states available: boldface on, boldface off, and possibly a special indeterminate state.
In a radio box, clicking on a radio button that is off turns it on and turns off any other buttons in the box that were on.
In a spin box, the user changes the value by clicking the SELECT button while the pointer is on an arrow. For example, if a spin box represents the days of the week, the user can click the SELECT button while the pointer is on the up arrow button to change to the next day of the week.
In a slider, the user changes the value represented by the slider by directly manipulating the slider arm, that is, by pressing the directional keys or by pressing the SELECT button while the pointer is on the slider arm and then moving the pointer in the direction of the desired value. For example, if a slider represents decibels for sound output, the user can press the Right Arrow directional key or press the SELECT button and move the slider to the right to increase the volume of the output.
To speed user actions, you can provide your interface with shortcuts such as first-letter cursor navigation, mnemonics, default actions, and shortcut keys. The following sections discuss these shortcuts.
You can use first-letter cursor navigation in list boxes, containers, and similar controls. In first-letter cursor navigation, the user navigates to and selects an item in a list by inputting (from the keyboard) the first character of the item. Inputting the character again allows the user to navigate to and select the next item in the list beginning with that character (see Figure 5-6).
For more information, see the First-Letter Cursor Navigation reference page.
A mnemonic is a readily recognized character that the user can type to move the cursor quickly from one place in a window to another and, in some cases, to activate or change the value of a specified control. A mnemonic is usually represented as a character from the Control label and is underlined in the label to indicate its function as a mnemonic (see Figure 5-7).
The user presses Alt and the mnemonic key to activate action, cascading, and dialog choices in buttons and cascading choices in menu bars. Also, the user presses Alt and the mnemonic key for a label associated with a tab group to navigate to the tab group. The user presses only the mnemonic key when in a menu or tab group to activate or toggle a choice in the same menu or tab group.
For example, the user may need to navigate to a specific choice within the File menu. To do so, the user presses Alt F, which displays the File menu and highlights the first item within it. Then, the user presses S to activate the Save choice.
For more information, see the Mnemonic reference page.
A shortcut key, or accelerator, is a key along with a modifier that the user can press to activate a choice (see Figure 5-8). You should provide shortcut keys for choices that the user frequently chooses.
A shortcut key usually appears next to the choice to which it pertains so that the user can learn to associate the shortcut key with the choice. You might want to provide a mechanism that allows users to turn off the display of the shortcut keys. Appendix B, “Keyboard Model and Key Bindings” lists predefined shortcut keys.
For more information, see the Shortcut Key reference page.
Within a window, especially a secondary window used for a message, there is often an action that the user may want to perform at any given time. Your application can have this action be the default action of the window; the user can then invoke it (when the window has focus) simply by pressing Enter, Return, or keypadEnter. If Enter is used for other purposes, such as when the focus is in multiline text, use Ctrl Enter.
In general, the default action is the action choice of a push button displayed in the window. You should display that push button with default emphasis.
Assigning a default action allows the user to invoke an action without first navigating to (then activating) the desired choice. Default actions are also useful for inhibiting the user from making potentially harmful choices. Figure 5-9 illustrates the default action for a text-entry dialog.
For more information, see the Default Action reference page.