SAP DESIGN GUILD

Screen Layout – Part II: Layout Hierarchy

By Gerd Waloszek, SAP AG, Product Design Center – 04/18/2002, updated 07/30/2002

From Containers to Layout Hierarchy | Example: Layout Hierarchy for iViews | Nesting Rules | Separator Rules | Final Word

This is the second article in my short article series on layout, and it is undoubtedly the most difficult to digest. I apologize for this in advance – abstract principles are not as easy to explain as practical examples. The latter will follow in the next article.

In this article, I cover the sequencing and nesting of screen elements. First, I present a generalized container concept. A simple layout "theory" or "scheme" follows that can be applied to a wide range of applications. It is based on the concept of a "layout hierarchy" that describes the sequencing and nesting of screen elements in a hierarchical fashion. In short, this scheme tells user interface designers which element can be placed into which container element – including placing containers inside containers. Note that these rules do not include the spacing between and within elements.

For a specific application type, such as an iView, Web application, or R/3 application, the general layout scheme can be adapted and transformed to table overviews and text rules. The main goal of such rules is to prevent user interface designers from creating overly complex and visually cluttered pages caused by excessive nesting.

A third and final article will introduce practical examples that demonstrate the application of the concepts presented in this article. The first article in this series describes general steps for laying out applications.

 

From Containers to Layout Hierarchy

Screen or page elements can either be containers or non-containers. In short, containers can contain other elements; non-containers cannot. The layout hierarchy described below basically deals with container elements, that is, with elements that can contain other elements. These elements may include other containers. This issue is critical because too much nesting can visually overload a page.

Figure 1a-b: A group box is a container, a tree is not a container

Application Containers

At the root of the layout hierarchy there is a base container that "contains" the application. For example, in the SAP Web or portal environment, there are two cases to consider:

1. The application container is a simple background, such as a frame or window. This is the case for Web applications (or IACs), including the portal administration applications.
2. The application container is a tray, that is, a container which may have elements and controls of its own. The iView that resides inside this container may use the services of the container. From the iView's point of view the tray is all it knows about – at least from a design perspective.

Figure 2: The tray is an application container for iViews

Containers Inside Applications

Inside an application, container controls or elements define the layout hierarchy of an application. In the SAP portal environment such containers are:

• Areas (Web applications only)
• Tabstrips
• Groups
• Subgroups (group of simple elements with or without heading – not included in a group control)

Figure 3a-c: Examples for containers within applications - the HTMLB tabstrip (top) and the HTMLB group box in two different versions (bottom)

A Matter of Interpretation - Linear Sequences Versus Sequences of Containers

From a technical point of view, not all of these containers are "real" containers. In the context of SAP's Web applications, areas are subdivisions of an application, that is, areas follow one another. Subgroups are groups of simple screen elements that may be introduced by a heading. They are typically separated from the remainder of the screen by white space or separator lines.

From a layout point of view, however, it is easier to view areas and subgroups as "real" containers. This does not make a difference to the layout process. Regarding these elements as real containers offers the advantage that the layout can be described in a hierarchical or tree-like fashion. This makes it easy to gain an overview of the page or screen structure.

From Abstract Containers to Specific Containers and Their Visualizations

I listed several containers above, such as areas, groups, or tabstrips. These containers have been developed for specific purposes. Now let's step back and look at the "general" characteristics of containers.

Definition

Let me define a container as a rectangular area on a screen or Web page that may contain other containers or screen elements. To make things clearer, here are a few examples of what does and does not constitute a container:

• Yes: Group boxes and tabstrips are containers.
• Yes: Tabstrips are containers because they offer different views consisting of other screen elements in a single rectangular area.
• No: A compound or complex control, such as a table or tree, is not a container even though the items (table cells, nodes) within this compound control may define certain other controls, such as input fields or dropdown list boxes.

Components of a Container

A container consists of three components, all of which might be absent or present:

• A title area or title bar (on top) – contains the title text and optional functionality for the container as a whole). A special title area case is the tab bar of a tabstrip.
• The content area (below the title area or status area if present) — contains the content.
• A status area or status bar (below the title area, or below the content area, position is set globally) — contains an area for displaying status and/or error messages, and local information, such as time or date. It may contain further functionality.

Container Attributes

Container components can be described through a variety of attributes. Setting these attributes and combining different components allows to the creation of a multitude of containers. The following attribute list serves for demonstration purposes only; it may not cover all possible container types and requirements.

Title – Attributes

• Multiple – yes/no (multiple or single view)
• Title text
  • Text (for multiple views, several texts, and positions within the list of tabs)
• Text attributes: face, size, weight, italic, underline, color, ...
• Text position - left, center, right (for multiple views "left")
• Background
  • Background color – color, transparent, ...
• Frame
  • Frame border – yes, no
  • Frame border width
  • Frame border color or style
• Padding
  • Padding left, top, bottom right or only one padding value
• Functionality
  • Buttons: Button text, icon, position, tooltip text
  • Examples of functions: Hide/show content, edit, personalize, ...

Content – Attributes

• Background
  • Background color - color, transparent, ...
• Frame
  • Frame border – yes, no
  • Frame border width
  • Frame border color or style
• Padding
  • Padding left, top, bottom, right, or only one padding value

Status Bar – Attributes

• Global Position – below title bar, below content area
• Text
  • Text
• Text position
• Tooltip text
• Functionality
  • Buttons: Button text, icon, position, tooltip text
  • Examples: Hide/show content, edit, personalize, ...

Creating Specific Containers

Specific containers, such as trays or group boxes, are built by combining certain title components with certain content components and possibly status components. For example, the group controls in the HTMLB library may be derived from a fixed set of title bars and content areas with their attributes set to a restricted value set.

The tabstrip is a special container: It can be regarded as a container with multiple titles.

Example: The HTMLB Group Box Set

Although the current HTMLB group boxes are not created from components having different attributes, they can help to illustrate the composition of containers following a modular construction principle. I found that there are three different header types and four different content types. From these two sets you can compose the five current HTMLB group boxes (see table 1):

	Light-blue header	Medium-blue header	Dark-blue header
Transparent content area (with frame)
White content area
Light blue content area
Dark blue content area

Table 1: The HTMLB group boxes can be composed from sets of three different headers and four different content areas

Non-containers

While containers create the "skeleton" of a page, non-containers are its "flesh." Such elements are, for example, fields, buttons, selection elements, text units, and tables.

As these elements differ in complexity, nesting rules ensure that a page cannot become too complex. For example, tables are similar in complexity to groups and tabstrips. Therefore, they are placed on the same level in the layout hierarchy as these containers. A rule that takes this fact into account would state: Tables may not be placed into groups or tabstrips if they are the only control that is inside the container.

Figure 4: Even though the table is a complex screen element, from a layout point of view it is not a container because it does not contain other controls

Separators

Separators, such as lines or white space, "separate" elements – non-containers as well as containers. They are, therefore, difficult to integrate into a hierarchical model of a page layout. They can be viewed as "concluding elements" or "borders" of containers (they are easier to integrate into a "linear" model of the layout).

Creating the Layout Hierarchy

The layout hierarchy is created by placing containers and simple elements on a page. The rules presented below govern how page elements can be combined, either by sequencing them vertically or horizontally, or by nesting.

Containers may include containers (nodes), simple elements (leaves), or both. In addition, non-containers may reside on the same hierarchy level as containers. However, they are "end nodes" and do not continue the layout hierarchy.

Example: A table may reside on the same level as a group or a tabstrip

The layout rules presented below specify:

• Which containers may contain which other container(s) – including itself
• The specific conditions for the nesting, for example, alone or together with other elements
• How many levels deep the nesting may be
• Which simple elements may be placed into which container – and the specific conditions for this
• Which containers and which simple elements are on the same hierarchy level

Actually, the concept of a layout hierarchy is not new or unique. For example, part lists can be organized as hierarchies. In 3D modeling programs, objects are hierarchically composed of different 3D shapes and modeled as an object hierarchy (see Carrara Studio from Eovia, for an example).

 

Example: Layout Hierarchy for iViews

Depending on the container elements used, different application types can have different layout hierarchies. In the case of the portal environment, there are Web applications and iViews. Both application types use different containers, serve different purposes, and therefore differ in complexity with respect to their layout. For the sake of brevity, I will only present the iView hierarchy here (click here for a hypothetical layout hierarchy for Web applications).

iView Layout Hierarchy

• Tray = iView container - may contain:
  • Tabstrip – may contain:
    • Group (if it is not the only element)
    • Subgroup
    • Table (if it is not the only element)
    • Simple elements
    • Separators
  • Group – may contain:
    • Group (if it is not the only element, different group types only)
    • Subgroup
    • Table (if it is not the only element)
    • Simple elements
    • Separators
  • Subgroup – may contain:
    • Simple elements
    • Separators
  • Table
  • Simple elements
  • Separators

Containers can be recognized by the fact that there are elements on the next level(s).

Generally, there should not be more than one level of nesting within trays/iViews. Also, you should note that tabstrips may not be nested.

Simple elements are: input fields, selection elements, text, or buttons

Table Overview of the iView Layout Hierarchy

The following table overview provides a more detailed description of the layout hierarchy for iViews. Red cells explicitly prohibit certain nesting. Yellow cells indicate cases where elements can be placed into other elements with restrictions only. (See also the reasons for these rules).

iView

Element below can be placed within Container to the right	Container
	iView (Tray)	Tabstrip	Group	Subgroup
Tabstrip	yes: together with other elements no: as single element	no	no *	no
Group	yes: together with other elements no: as single element	yes	possible - but use with care! one level at maximum - try to use different types for the nesting	no
Subgroup	yes	yes	yes	no
Table View	yes: together with other elements no: as single element	yes	no *	no
Text Area, Graphic	yes	yes	yes	no
Separator (White Space, Line)	yes	yes	yes	no
Heading	yes: for subgroup, text area, graphic	yes: subgroup, text area, graphic	yes: subgroup, text area, graphic	yes (as heading for the subgroup)
Field, Selection Element, Icon, Button	yes	yes	yes	yes

 

Table 2: Layout hierarchy for iViews

*) As iViews are simple applications, tabstrips and table views should not be placed into group controls.

Note: Where a "no" is shown in bold, it indicates a common error, such as nested tabstrips.

 

Nesting Rules

The following nesting rules are derived from the table overview above and arranged according to design rationales, such as "avoid too much framing" and "avoid redundant headers".

Avoid Redundant Headers

The nesting rules defined for the layout hierarchy strive to avoid redundant headings. Thus, do not place:

• Singular tabstrips into group boxes
• Singular tables with a table heading into groups

Avoid Too Much Framing (Visual Complexity)

Too many frames and borders make screens visually complex and waste screen space. Thus, do not place:

• Singular tables with a table header within group controls – use a table heading instead
• Singular tabstrips within groups
• Groups within groups – use groups with text headers and separators instead
• Tabstrips within tabstrips – nesting tabstrips is a perfect way of hiding information

 

Separator Rules

The layout hierarchy is also helpful when formulating usage rules for separators. You should note that "not all separators are equal." You would not typically want to place separator lines between containers, but would use white space instead.

Thus, a rule for using separators might state: Do not use separating lines between containers or, simple elements that are on the same hierarchy level as containers. (For example, do not place a line between a group and a table). This rule follows the rationale of "avoiding too much framing," as stated above.

Here, the layout hierarchy helped to clarify the situation for screen elements, such as tables and tabstrips, with a visual complexity similar to containers.

 

Final Word

This article undoubtedly contains material that is hard to digest. In the next article, therefore, I will apply the notions of a layout hierarchy and the container model described here to concrete applications and controls.

 

top