The approach of configuring user interfaces with user interface patterns only works if there are a small number of “generic” tasks, which can describe very many different business activities. The following sections use examples to demonstrate what generic tasks may look like and how they can be used to define reusable components.
Before users can perform an activity, such as editing an invoice, they need to select the corresponding business process. Users can then search for a work object, or define one directly. The work object can be selected on the user interface by means of a solution with various drop-down boxes and a button, for example. The “Show” drop-down box enables a predefined query to be selected; the “Get” drop-down box enables a key field to be selected instead and also enables a value to be entered in the corresponding input field. The “Advanced” button activates a window in which an extended search query can be launched.
Orienting, identifying, editing
The possible work objects that were identified by the query can be grouped in a particular area of the user interface. The user can thus decide how to proceed, that is, whether to select one or more work objects. The user requires information about the current work object, such as its status and navigation options, for orientation purposes. The user interface must enable the user to identify the work object clearly. A work object’s most important data can be made available in a form, in a table, in a tree, or displayed graphically.
SAP selected an activity such as “recording an invoice” as the unit of measure for the definition of an application. The assumption is that each business activity consists of an easily describable underlying structure that a user can make a mental picture of. This structure is made up of concepts (objects) of differing degrees of abstraction. Each object may be of the type “categorial” or “enumerating”. The header data of an invoice, for instance, consists of different information that can be represented as a form (categorial). The invoice line items, on the other hand, are enumerating and can be easily represented in a table. During the re-engineering of a large number of business activities, SAP established that the specific object structure is often part of a general object structure.
The focus areas of a business process can be combined into a floor plan. Each “room” of the floor plan defines a place on the user interface, such as horizontal top, vertical left, or bottom right. Further, each story of the floor plan describes a screen change. In the context of what has been said above, an underlying generic task can be identified for every focus area that describes a specific task. For its “user-centric” mySAP CRM solution, for instance, SAP defined an application floor plan that is suitable for the “edit objects” task. Other floor plans are required for other tasks.
Mapping generic tasks to the user interface
The floor plan of the generic tasks can be mapped to a floor plan of user interface patterns which have been programmed in full. The following applies:
- At least one generic task is mapped to a user interface pattern.
- This component is assigned on the screen in accordance with a predefined floor plan.
- The component contains all functions, data, and links that a user needs for his or her current task.
User interface patterns enable developers to configure interfaces instead of programming them. All the developer has to do is decide which functions and fields should appear on the user interface for each pattern. To do so, the developer selects items from proposal lists provided by the development tool. The actual view seen on screen is generated. For instance, a form view for categorial data that groups and arranges the corresponding screen elements, such as fields, radio buttons, or check boxes, in two dimensions can be generated by layout algorithms.
SAP is happy with the outcome of the first project that used user interface patterns. The following results can be noted:
- The selected level of abstraction proved suitable for deriving functionally powerful and general components.
- The number of identifiable, generic functions remains transparent.
- Generic functions can be mapped to generic user interface patterns. A precise description of the functions is necessary here.
- Composition into floor plans is comparatively simple. In doing so, the way in which data is to be exchanged between user interface patterns must be established. In the case of “master detail relationships” between two object data patterns, the selection of a different row in the superordinate pattern naturally influences the representation in the subordinate pattern.
- Configuration of the user interface, as opposed to programming it, can be implemented technically and makes developers’ work far easier.
Predefined user interface components provide three key advantages. Firstly, they provide a simple means of creating highly consistent user interfaces. Secondly, the usability of individual components can be optimized retrospectively; and thirdly, a high gain in productivity is made during development as the interfaces merely need to be configured. The different types of business activities pose challenges as they demand a compromise between suitability for the task and consistency. Similarly, development requests for functional enhancements may over time complicate the clear structure of a user interface pattern. Experience will show which floor plans are most suited to which application types.