Layout Hierarchy

From Containers to the Layout Hierarchy | Layout Hierarchy for iViews and Web Applications | Table Overview of the Layout Hierarchy | General Nesting Rules | Related Controls

This page describes the layout hierarchy of Web pages, which defines the options for nesting page elements. In short, this page tells designers, which page element can be placed into which container element - including placing containers inside containers.

The layout hierarchy is the basis for establishing textual layout rules for pages and page sections. The main goal of such rules is to prevent overly complex and visually cluttered pages caused by excessive nesting.

Note: These rules do not comprise the spacing between and within elements.

Top

From Containers to the Layout Hierarchy

Page elements can either be containers or non-containers. Containers can contain other elements, non-containers not. The layout hierarchy described below basically deals with container elements, that is, with elements that can contain other elements including other containers. This is critical because too much nesting can let a page appear visually overloaded.

Application Containers

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

• The application container is a simple background, such as a frame or window. This is the case for the so-called Web applications, including the portal administration applications
• The application container is a tray or tile. The container which may have elements and controls on its own; the application that resides inside this container may use the services of the container. From the application's point of view the container is all it knows about -- at least from a design perspective.

Container Controls Inside Applications

Inside an application, container controls define the layout hierarchy of an application. Such containers are:

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

A Matter of Interpretation - Linear Sequences vs. Sequences of Containers

From a technical point of view, not all of these containers are "real" containers. Areas are subdivisions of an application. That is, areas form a linear sequence within an application. Subgroups are groups of simple page elements that may be introduced by a heading. Typically, they are separated from the remainder of the page by whitespace or separator lines.

From a layout point of view, however, it is easier to view areas and subgroups as "real" containers - for the layout process this does not make any difference. The advantage of regarding these elements as real containers is that a layout can be expressed in a hierarchical or treelike fashion, which makes it easy to gain an overview of the page or application structure.

Non-Containers

While containers create the "skeleton" of a page, non-containers are the "flesh" of a page. These elements are 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, table views are similar in complexity to groups and tabstrips. Therefore, they are placed on the same level in the layout hierarchy as these containers. A respective rule that takes this aspect into account would state that table views may not be placed into groups or tabstrips if they are the only control that is inside the container.

Separators

Separators, such as line or whitespace "separate" elements or containers. Therefore, they are 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).

Note that separators are different. While you would separate containers or elements that are on the same hierarchy level whitespace, you would use lines because that would introduce unnecessary framing.

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 contain containers (nodes), simple elements (leaves), or both. In addition, non-containers may reside on the same hierarchy level as containers. But they are "end nodes" and do not continue the layout hierarchy.

Example: A table view 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 exampe, 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

Top

Layout Hierarchy for iViews and Web Applications

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 the layout.

iView

• Tray = iView container
  • Tabstrip - may contain:
    • Group (if it is not the only element)
    • Subgroup
    • Table View (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 View (if it is not the only element)
    • Simple Elements
    • Separators
  • Subgroup - may contain:
    • Simple Elements
    • Separators
  • Table View
  • Simple Elements
  • Separators

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

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

Note: A similar tree can be created for real iViews based on the elements used.

Web Application

• Application Background = Window/frame background = application container
  • Area - may contain:
    • Tabstrip - may contain:
      • Group (if it is not the only element)
      • Subgroup
      • Table View (if it is not the only element)
      • Simple Elements
      • Separators
    • Group - may contain:
      • Tabstrip (if it is not the only element)
      • Group (if it is not the only element, different group types only)
      • Subgroup
      • Table View (if it is not the only element)
      • Simple Elements
      • Separators
    • Subgroup - may contain:
      • Simple Elements
      • Separators
    • Table View
    • Simple Elements
    • Separators
  • Single elements??? - Open

Generally, there should not be more than one level of nesting within Web applications. Also note that tabstrips may not be nested.

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

Note: A similar tree can be created for real Web applications, based on the elements used.

Note: The critical question for Web applications is, whether single elements and containers other than areas can be placed on the application background. Currently, the application background may not be used for non-container elements (see the IAC Guidelines in the SAP Design Guild). In R/3 applications, header data may be placed on the application background; there is no such a container concept in R/3 applications as areas.

Top

Table Overview of the Layout Hierarchy

The following table overviews present a more detailed description of the layout hierarchy for iViews and Web applications. Red cells explicitly prohibit certain nestings. Yellow cells indicate cases where elements can be placed into other elements with certain restrictions only (see also the reasons for these rules).

iView

Legend

• *) As iViews are simple applications, tabstrips and table views should not be placed into group controls.
• Red cells: Nesting forbidden
• Yellow cells: Nesting allowed under certain conditions only
• The bold no's indicate common errors, such as nested tabstrips.

Web Application

Legend

• Red cells: Nesting forbidden
• Yellow cells: Nesting allowed under certain conditions only
• The bold no's indicate common errors, such as nested tabstrips.
• ??? Open (placement of elements on the application background)

Top

General Nesting Rules

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

Avoid Redundant Headers

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

• Singular group boxes within areas (Web applications only), or tabstrips
• Singular tables with a table heading within group controls

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 group controls - Web applications: place them in areas instead; use header texts, or the area header as a title for the tabstrip
• Group controls within group controls - use groups with text headers and separators instead (not forbidden but should be used with care - try to use different types for the nesting)
• Tabstrips within tabstrips - nesting tabstrips is a perfect way of information hiding
• Separator lines between containers or container-like elements

Top

Related Controls

Flow Layout, Grid Layout

Top