Guidelines for Screen Areas

Areas define the high-level structure of a screen or page. Below we present general guidelines for the use of screen areas.

Note: In Typical Screen Divisions we discuss how screens can typically be subdivided into meaningful areas - or the other way round - how areas can be combined to a coherent structure.

Illustration

Figure 1: A mockup of an ESS web application that demonstrates the principle of areas (click image for larger version); this is the current proposal for the look of areas.

Purpose

Screen elements that belong together and serve a certain purpose are placed into an area, the purpose of which is indicated in the area title (see below). In multiple-area applications, areas separate meaningful groups of screen elements which serve different purposes; for example:

A selection area serves the purpose of selecting data for closer inspection or processing
An overview area provides an overview of a data set
A detail area provides details for a specific item selected from a data set

Often areas correspond to "focus areas", a term that Karen Holtzblatt introduced for describing dedicated screen areas that fulfill a certain task or subtask.

Areas need not technically correspond to an HTML frame (or inline frame). Often frames are introduced for technical reasons only; an area may consist of several frames that together serve a certain purpose.

Look

The current proposal for the look of areas places areas on tiles which reside on the blue tatami background. They start with an area title that indicates the area's purpose. The tile structure also ensures that areas are clearly separated from each other.

Figure 2: Current proposal for the look of areas - here two side-by-side areas are shown.

Note: The visual attributes for areas in SAP IACs are in the stage of a proposal; there is currently no HTML Business function available.

Naming

If there is only one area one the screen, no area title is needed; the application title already contains the necessary information. On screens with more than one area, areas start with a title that clearly indicates the area's purpose (see figure 3 left).

Exception: Areas that are created for technical reasons (e.g. certain frames) have no title.

Note: See Titles of IACs, Areas, and Groups for details on the formulation of titles int the SAP Refence Lists on the SAP Design Guild..

Area can also be without a title bar (see figure 3 right); this feature is primarily used in applications, which consists of one area only. In this case, the application title is used for describing the application.

Figure 3: Area with title bar (left) and without title bar (right)

Note: Areas without title bar cannot be collapsed.

Tabstrips

Area titles (or areas) may be used to indicate the purpose of a tabstrip. That is, single tabstrips should not be included in group boxes for the sole purpose of giving the tabstrip a name; they should be included in an area with a separate title instead.

Initial State

An area should not be empty at startup; this is only admitted if no useful data or data item can be found. If areas contain data in tables or fields, these should initially be presented with the data of a selected item.

Examples for possible items

The item that was processed last
The table (i.e. set of data) that was processed last
A "default" item or table

Collapsible Areas

Collapsing currently unused areas helps to use screen space more efficiently. However, such a feature makes the interface more complex and may cause annoying screen updates. Therefore, as a rule of thumb, IACs should not have collapsible areas (see figure 4 left); however, if such a feature is needed, it is available (see figure 4 right).

Figure 4: Not collapsible area (left, recommended) and collapsible area (right)

As an alternative to collapsing areas, an area may be used for multiple purposes. Thus, the basic screen layout is kept stable, while the contents (and title) of an area may change.

Dependencies between Areas

Often there are dependencies between areas. For example, users can browse items in an overview area and select them for further processing to be done in a detail view. Thus, the details are displayed in an area the contents of which depends on the overview area where the selection is done.

Dependencies should only go in the following directions:

From left to right
From top to bottom

Rationale: These directions correspond to the normal understanding (in western cultures) how things depend on each other and how actions proceed (e.g. you read from left to right and from top in bottom).

Do not reverse this direction of dependencies! Users will have problems in understanding that a selection in, for example, a bottom area causes major changes in an area above it (updates of items in the overview area that have been edited in a detail area below it are of course allowed).

Figure 5: Dependencies between areas should only be from left to right and from top to bottom.

top