Designing the Procedure Dialog › Design Online Dialogs › Function Keys

Function Keys

The chapter “Preparing for Design” covers the use of standard function keys.

All commands for a host procedure step should be accessible by function key, provided that the function key standards are not violated, and that the keyboards in use support enough function keys.

Function keys to navigate online procedures are more convenient for the frequent user than entering commands.

The following illustration, Flow Actions for Online Procedures, shows three online examples that call for a Display First flow action.

The following list details the keys to the illustration:

• Example 1 shows that Display First is most often used in flows from menus.
• Example 2 shows that flows in loosely structured dialogs between dissimilar procedure steps exist purely for user convenience.
• Example 3 shows that there are occasions when the destination procedure step is required to create entities.

Note: This example, the Command field and Customer Number field are prepopulated with pertinent information, even though Display First was specified.

The following illustration, Execute First Flow Actions, shows two examples of dialogs using Execute First flow actions.

Execute First is most often used when the destination procedure step is to present data identified in the source procedure step or in menus that allow the capture of key information relevant to the destination procedure step.

For dialog flows that are transfer flows, a flow action is specified for the destination procedure step. For dialog flows that are link flows, two flow actions are specified-one for the destination procedure step and another for the source procedure step on return.

An interesting aspect of the Execute First flow is that its execution, when followed by any other flow, can cause user interaction with procedure steps to be bypassed. Consider the following illustration.

Assume that the link between procedures P1 and P2 specifies Execute First in both directions, that is, for P2 when the link is initiated and for P1 when the link completes. Also assume that the link flows on ES1 and returns on ES2.

The following scenario is then possible:

1. The user fills in the display for P1 and presses Enter.
2. P1 executes and sets Exit State to ES1 at its conclusion.
3. Based on the value of the Exit State, P1 links to P2.
4. Because the flow action is Execute First, P2 executes. At its conclusion, it sets Exit State to ES2.
5. Based on the value of the Exit State, P2 returns to Pl.
6. Because the flow action for return is Execute First, P1 executes. At its conclusion, it sets Exit State to ES3.
7. No dialog flow is associated with exit state value ES3, so the display for P1 is displayed.

From the user's perspective, the execution of procedure P2 is completely hidden. The display for P1 is used for input and subsequently redisplayed, just as if P2 had never been invoked, although P2 contributed to the successful execution of the procedure.

Sometimes a procedure step does not need to display a display. In this case, it is defined as non-display.

When commands are passed along a dialog flow using a Display First action, the value of Command specified on the flow appears on the display of the destination procedure step. Example 3 in the illustration, Display First Flow Actions, shows this display.