User Interface Patterns • Components for User Interfaces

By Udo Arend, SAP User Experience, SAP AG – November 19, 2004 • Original article (Edition 8)

Reusable components, known as user interface patterns, considerably simplify the development of consistent and ergonomic user interfaces. The first part of the following article describes the pattern approach used at SAP. The remainder of the article shows how the patterns are derived from generic user tasks and then mapped on the user interface.

Developers are faced by a great many questions when designing the user interface, or UI, for a corporate software application. Should they use icons? Where should the header data and the detail data be positioned? How do users search for objects or data? How should new rows be inserted into a table? Which working areas should make up a view?

Finding the right answers to all these questions is not easy. This is why SAP uses predefined "floor plans" that are populated by reusable generic "user interface patterns" when developing user interfaces. As part of a user-centric design process ("user interface first"), developers design business applications and configure their user interface using predefined components. They are assisted in this task by appropriate development tools.

 

The Pattern Approach at SAP

Reusable components, or patterns, are not new concepts in software development and user interface design. According to the definition of design experts Douglas van Duyne, James Landay, and Jason Hong, they provide insights into design problems by defining the specifics of a particular issue and its solution in a compact form. A well-known example would be the shopping cart used by online shops, where users can collect all the items they want to buy before placing the order.

The UI pattern concept

Figure 1: The UI pattern concept

The pattern approach at SAP is characterized by two special features. Firstly, it separates the description of a task that the user executes from its representation on the user interface. This separation has the advantage that the floor plans and components can be structured both according to the prevailing design paradigm and also in line with the specific features of the terminal, such as a large monitor on a PC or a small monitor on a PDA. Secondly, the approach only works if generic user interface solutions are found for generally applicable, or "generic", tasks - after all, the intention is to be able to use one component for a large number of applications. Both tasks and the elements of the user interface can be mapped in a nested "decomposition hierarchy", that is, simple elements can be combined to produce more complex ones.

The "search for a work object" is one example of a generic task. It is irrelevant whether the object is an order, a delivery, an invoice, or a material. The general assumption is that if generic tasks exhibit similar properties for a specific number of business processes, then a standard solution can be found on the user interface. For instance, a button represents a "classical" solution for the generic "trigger function" problem.

The SAP approach is about moving away from the level of these elementary actions and solutions, such as entering text or clicking a button, and identifying more complex tasks. To achieve this, elementary components, or "user interface controls", such as the button, are assembled into more complex components, the "pattern elements". A pattern element may be a toolbar that combines several controls for triggering functions. Pattern elements themselves can be combined into even more complex components, the user interface patterns. A user interface pattern fulfils one or more generic tasks, such as searching for and selecting a business object. A pattern such as this may consist of a search area, various function buttons in a tool bar, and a collection area for the hit list.

 

Standardized Floor Plans for Applications

During application development, user interface patterns are combined into application floor plans, and are arranged on the screen. The application floor plans can be standardized for identical application types ("business activities"), such as editing a customer order. One part of the "people-centric" mySAP Customer Relationship Management (mySAP CRM) solution, which marks the beginning of the deployment of user interface patterns at SAP, consists of just two floor plans and uses only two different user interface patterns. This provides for a highly consistent solution. However, it is only possible to do with a small number of floor plans in this application area because the applications have a similar structure. Naturally, more floor plans and user interface patterns may be used to make the application more suited to the needs of the user.

SAP bases its development of user interfaces on Karen Holtzblatt's "Contextual Design" method, which takes the users' working practices as its starting point. Developers and UI designers use this method to create the model of an interaction structure ("user environment" model), that is, the structure of a business process from the user's point of view. The interaction structure consists of discrete areas, known as the focus areas, each of which describes a user activity, such as entering invoice line items. A focus area is defined by its purpose for the user, by other areas to which the user can navigate, and by functions available to the user. According to Holtzblatt, the user interface should represent a focus area as a coherent whole on the screen that allows users to concentrate on it and complete their tasks there.

Focus areas are normally derived for one specific business process and are only valid for this. However, the SAP approach requires similar focus areas to be defined from different business processes. Only then can reusable UI components be built that can then be configured for each specific application scenario. One result of this is a consistent user interface structure of different applications that have a similar composition.

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.

 

Design Method

Searching for and selecting a work object

Figure 2: Searching for and selecting a work object

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.

Possible work objects in a results list

Figure 3: Possible work objects in a results list

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.

Sample object structure for an invoice

Figure 4: Sample object structure for an invoice

Transparent Structures

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.

Floor plan for generic tasks of the "editing objects" type

Figure 5: Floor plan for generic tasks of the "editing objects" type

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 of generic tasks to UI patterns

Figure 6: Mapping of generic tasks to UI patterns

 

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:

  1. At least one generic task is mapped to a user interface pattern.
  2. This component is assigned on the screen in accordance with a predefined floor plan.
  3. 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.

 

Positive Outcome

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.

 

References

  • [1] Alexander C., The Timeless Way of Building. Oxford University Press (1979).
  • [2] Tidwell J., Common Ground: A Pattern Language for Human-Computer Interface Design (1999). http://www.mit.edu/~jtidwell/ui_patterns_essay.html
  • [3] Van Welie M., Web Design Patterns (2003). http://www.welie.com/patterns/index.html
  • [4] Van Duyne D.K., Landay J.A. and Hong J.I., The Design of Sites - Patterns, Principles, and Proc-esses for Crafting a Customer-Centered Web Ex-perience. Boston: Addison-Wesley (2003).
  • [5] Card S.K., Moran T.P. and Newell A., The Psy-chology of Human-Computer Interaction. Hills-dale, NJ: Lawrence Erlbaum Ass (1983).
  • [6] Beyer H. and Holtzblatt K., Contextual Design: Customer-Centered Systems. San Francisco: Morgan Kaufman (1998).
  • [7] Wesson J. and Cowley L., Designing with Pat-terns: Possibilities and Pitfalls. In Rauterberg, M., Menozzi, M., Wesson, J., "Human-Computer In-teraction, Interact 2003, Workshop Software and Usability Cross-pollination - The Role of Usability Patterns", Zürich (2003). http://wwwswt.informatik.uni-rostock.de/deutsch/Interact/index.html

 

top top