(Re)designing Entry into the Applications
Explicit Selection of the Processing Object from a List / Tree | Direct Input of the Object | Omitting Selection of the Processing Object in a Single-Screen Application | Navigation in Single-Screen Applications
These recommendations apply to the user interface design for selecting the actual processing object within an application, e.g. specifying an order number to process an order, specifying a vendor to change the vendor data, etc.
In this solution - which fits the new design paradigm of "single-screen applications" - the processing object and the processing type are chosen or specified in the same screen where the object is subsequently processed.
This approach both improves navigation for the enduser and eliminates the forced sequence of the dialogue across multiple screens. There are still situations, however, in which the processing object has to be selected in a separate screen, such as for complex selections (queries) or situations in which there is no alternative to placing many fields or select options on one screen to determine the processing object.
The Situation for the Enduser
Once the user has chosen the application (transaction), such as "Purchase order", he frequently also has to specify the process object first, or even during the processing of subsequent objects. Different processing types can be used with the processing object, such as the usual "Create", "Change", and "Display", as well as more specific functions like "Delete" or "Lock" the entire object.
The Conventional Solution
Under the conventional solution in the R/3 System, the object for processing is selected in a separate initial screen (primary window). The processing type (Create, Change, Display) is selected previously from the menu level (work area menu). This forces the user into a modal dialogue with screen changes. Changing the subsequent processing object always requires an additional step via the initial screen, while the processing type is changed through the object menu, which also goes via the initial screen.
The Future Solution
New technical features of the R/3 GUI (subscreens, split bar, events, control containers, trees, etc.), as well as increased screen resolutions and a greater default size, allow a more modern solution that
- Does not require an additional screen change to select the processing object
- Allows direct selection of the processing object through a list or tree
- Links the selection of the processing type with object selection
These recommendations take the following requirements into account:
- Different fields must be filled depending on the processing type
- A new object can be created through a reference to an existing object
- Error and save dialogues must work correctly
- The "Cancel" function resets the input data, but remains on the screen
Source: SAP R/3 Style Guide