Design Tidbits

back To Overview of Tidbits

Design Tools

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

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.

Group box as example for a container        A tree is not a container

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.

The tray is an application container for iViews

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:

HTMLB tabstrip control
 
Two group box examples

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:

Components of a Container

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

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

Content – Attributes

Status Bar – Attributes

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
  Light group box header Medium group box header Dark group box header
Transparent content area (with frame)     Group box with header
White content area   Header group box 2  
Light blue content area Primary group box Header group box 1  
Dark blue content area   Secondary group box  

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.

Table view control

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:

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

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:

Avoid Too Much Framing (Visual Complexity)

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

 

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 top