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:
Figure 18 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.
Figure 18. Navigating Between and Within Window Families.
View figure. |
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:
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:
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:
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 19 illustrates navigating between tab groups.
Figure 19. Navigating Between Tab Groups with the Tab Key.
View figure. |
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 20). 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.
Figure 20. Using a Directional Key to Navigate Within a Control.
View figure. |
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 21). 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 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:
Figure 21. Menu Navigation While Pressing the SELECT button.
View figure. |
For more information, see the Menu (Control), Menu Guidelines, and Spring-Loaded (Control Type) reference pages.
