General Explanations 

Menüleiste der Anwendungsebene

The following example explains the object-oriented concept and its advantages:

Consider the user work area as a desk. There are various things on this desk such as pencils, file cards, papers and files. The employee can now take a pile of newspaper articles (object class) and go through the articles (objects), read them, make notes, staple them together, and sort them. The user might also add certain new articles to the pile. Then the user takes the card index (object class), takes individual cards from it (objects) and reads them or makes notes on them. Of course, new cards will be added from time to time.

Advantages of an Object-Oriented Approach

The employee is spared the continual opening and closing of the card index and the stack of papers. From the quantity of similar things compiled, the user only needs to work with some of them at a time. After the user has edited the file card and put the card index away again, he or she takes the pencils in order to sharpen some of them. Industrial productivity improvements are to a large extent the exploitation of this principle, whereby setup times, transport times and training periods, among other things, are reduced.

A second advantage is that the employee does not have to commit himself to particular actions when choosing the object class, but can carry out the appropriate action, depending on the characteristics of the object.

Disadvantages of an Object-Oriented Approach

The advantage of working with the current object class, however, becomes a disadvantage when the employee wishes to read an article and then to create a new file card for it straight away. The work process , so to speak, cuts across the object classes. In this case, the changes of the object classes required by the work process should be supported by specific navigation options. This adaptation of the interactive possibilities to the work process of the user leads to the concept of a process chain.

Conclusions for the Design

The decisive factor in gathering many objects in an object class is, thus, that it is generally possible to process a number of elements of this class one after another, using the same actions. The more effectively the objects with which an employee works are grouped into classes, the less he or she needs to "fetch" an object class for editing or to name it, and the less he or she therefore needs to rename the action. Ideally, the user needs only choose the function Other object after editing a particular object, and enter the name of the new object.

The second advantage of an object-oriented procedure relates, however - in contrast to the procedure already outlined - to the processing of one and the same object by means of various actions, without the employee having to plan these long in advance of choosing the object. This should also be possible for the user, so that we now have to combine two potentially conflicting requirements:

The object-oriented dialog has, thus, to be combined with a job-oriented and user-oriented design.

Relating Objects to User and Task

Inadequate analysis of the user's knowledge and of his work processes, an object-oriented interface design may force the user to work with objects in a form that he does not recognize. He frequently thinks on the basis of objects which originate from his work process and his workplace, not on the basis of objects which correspond to the abstract commercial or technical point of view.

For this reason, the objects should always refer to the working environment and the objectives of the user. They must be familiar and depict the conceptual framework of the user's work (and not the database system perspective, for instance). Processes such as "transfers" or "incoming payments" are thus also possible on the object class level. Concreteness or "physical reality" is not a defining attribute for an object.

The R/3 concept involves a move away from rigid process-based interaction by means of transaction codes to flexible, object-oriented user menu management.

These requirements are realized and standardized as far as possible in the pull-down menus of the SAP tasks under Menus - General Structure, Menu Bar at Task Level and Menu Bar at Application Level.