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 17).
Figure 17. Manual and Automatic Stacking Order.
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 4 summarizes how stacking order and focus policies work together within the interface at the window level.Table 4. 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.