Navigation between Screens

This chapter presents the "whole story" of navigation between hierarchically organized screens within a task. For each basic screen type we present the options for moving around. There are from-options to hierarchy levels above and below and within the same hierarchy level. There may also be to-options, that is, navigation options to the current screen.

Navigation: The Screen Calling the Task

From: Moving to Subordinate Hierarchy Levels

• By choosing a pull-down menu item, a function key, a pushbutton, or a fastpath.

To: Moving to "the Screen Calling the Task"

• Relative branches to "the screen calling the task".
• Exit always jumps to "the screen calling the task".

Navigation: The Initial Screen

From: Moving to Superordinate Hierarchy Levels

• Exit , Back and Cancel jump to "the screen calling the task" (exits the editing).

From: Moving to Subordinate Hierarchy Levels

• Unrestricted access: If the object components are contents-related groups of data and can be defined without restrictions (see below), you can define freely navigation options for selecting a group.
  Branches that cannot be carried out because they are object-dependent result in an error message. Continue can carry out a default branch.
  Try to provide pushbuttons in the application toolbar for accessing the views. If too many different views are possible, offer the navigation options used less often only for selection via pull-down menus.
• Predefined navigation sequence: If the next screen is predefined, for example, the first screen of a sequence of screens, the user can get there by using Continue. However, avoid predefined screen sequences in R/3!

To: Moving to the Initial Screen

• Relative jumps to the initial screen.
• Other <object> always goes to the initial screen.

Note: The standard functions Create, Display, Change, Edit, Single processing, Collective processing, Enter, Single entry and Collective entry always navigate to the initial screen as well. In the following, this is not pointed out separately.

Navigation: The Object Component List Screen

From: Moving to Superordinate Hierarchy Levels

• Other <object> jumps to the initial screen.
• Back: If the object component list screen was directly accessed from the initial screen Back also returns to the initial screen.
• Exit always jumps to "the screen calling the task".

Returning to the initial screen exits the editing of the current object.

From: Moving at the Same Hierarchy Levels

• Nested lists/tables: Previous list via Previous <object component>, next list via Next <object component>

From: Moving to Subordinate Hierarchy Levels

• Only one view: If there is only one screen for every line of the list, the user can choose an entry by positioning the cursor on the required line and by choosing the function Choose (F2).
• Several views: If several views are possible for every line, the user selects an entry by positioning the cursor on the required line. The user then chooses the view by activating a corresponding function. Here, the function Choose (F2) might select the most often used function (default function).

Navigation: The Object Component Screen

From: Moving to Superordinate Hierarchy Levels

• Standard navigation: With Back, you get to the screen that is exactly one level higher in the hierarchy.
  With Other <object>, the user always reaches the initial screen.
  With Exit, the user reaches "the screen calling the task".
  If data is not yet saved, a safety prompt must be displayed.
• Saving when making fast entries: In some cases (for example fast entry), it can be useful to link the function Save or Post with a simultaneous navigation to the initial screen.
• Navigation in case of inconsistent data: If navigation to a superordinate hierarchy level is actually impossible (e.g., because data is still inconsistent), you have to support Cancel anyway. In this case, however, data entered by the user will be lost.

From: Moving at the Same Hierarchy Levels

• Unrestricted access: If it was possible to choose the object component for processing without restrictions via various functions, then use the same functions also for navigating at the same hierarchy level.
• Access via object component list screen: If the access to the object processing occurred via the object component list screen, then after having processed an object component the user can branch as follows: with Previous <object component> to the object component's predecessor (according to the list), and with Next <object component> to the object component's successor (according to the list).
  With the function Other <object component>, the user can branch directly to any object component on the list. You need not support this, however. With Other <object component>, it is not possible to branch to an object component outside of the list.
• Preselection: If a selection has already been made by selecting something from the object component list, the functions only branch between these selected lines.
• Nested lists/tables: If the displayed screen in turn consists of a list/table via which the user can branch to a "component/object component" screen, then Previous <object component> and Next <object component> only navigate at the current level.
• Changing the view for object components: Sometimes you can change the view on subordinate screens, that is, the user can look at yet further screens to an object component. Then after Previous <object component>, Next <object component> he should see again the original view for the next displayed object component with which he initially accessed the display of the object components.
• Predefined sequence: Previous screen via Previous screen, next screen via Next screen or Continue.

From: Moving to Subordinate Hierarchy Levels

If the subordinate hierarchy levels can be defined freely, any functions can be defined (see initial screen); if a choice was made via a list, then a distinction is to be made as on the object component list screen (see there).

Navigation: The Sub-Component of Object Component Screen

From: Moving to Superordinate Hierarchy Levels

• Standard navigation: With Back, the user returns to the object component screen, with Other <object>, to the initial screen, and with Exit to "the screen calling the task".
• Navigation when data is inconsistent: If it is not possible to navigate to a superordinate hierarchy (e.g., because the data is not consistent at this point in time), you have to support the function Cancel anyway. The data entered by the user, however, is lost in this case.

From: Moving at Same Hierarchy Levels

The same rules as for navigating between object component screens apply.

From: Moving to Subordinate Hierarchy Levels

If further hierarchy levels exist, the same rules as for navigating from an object component screen to a sub-component of an object screen apply.

top

Source:  SAP R/3 Style Guide