 |
|
|
|
|
|
| |
<<Previous | 1
| 2 | 3
| 4 | 5 |
Next>>
|
|
Figure 2. Controlled task panel
|
|
|
|
Controlled Task Panel In Figure
2, we show a modification of the context switch for cases where
all transactions belong to a "key object". In this case, the
key object can be referenced as a name, telephone number, or an account
number. (The entry field changes according to the selected radio button.)
We call this a controlled task panel because the task buttons and important
data associated with the key object remain visible on the panel throughout
the application. The panel data must be justified by its usefulness to
the user. Examples of use include telephone customer service and order-taking
applications. Note that the icon buttons on the left can change according
to which button module is active.
Hierarchical Menus Alive! In contrast to the two UI
architectures given above, some task flows are very predictable. The user
may enter data into a structured sequence of screens, such as three screens
used for taking a bank loan application. When that task is finished, the
user may want to accomplish a different task, with a different set of
screens, and so forth. In such cases, we provide a "hub" for
accessing the first screen of the various sequences. See Figure
3.
|
|
Figure 3. Predictable task flows with"hub".
|
|
|
|
The soul-design alternative to pull-down navigation is the "classical
hierarchical menu", shown below in Figure 4.
Notice we've given it a modern flavor by including business statistics
in the various bar chart status indicators. The user keeps in touch with
the pulse of the business every time he or she returns to the hub, or
menu. Human factors research gives us some rules for such menus. No more
than six groups. No more than ten items within a group. And no more than
18 to 24 menu items.
|
|
Figure 4. Classical hierarchical menu.
|
|
|
| |
<<Previous | 1
| 2 | 3
| 4 | 5 |
Next>>
|
| |
GUI Articles List
|
|
 |
|
