Layout Hierarchy - Nesting Rules

From Containers to the Layout Hierarchy - A Little Theory | Layout Hierarchy for iViews | Table Overview of the Layout Hierarchy | General Nesting Rules

This page describes the layout hierarchy for iViews; this hierarchy defines the options for nesting of iView elements. Thus, this page tells designers, which screen element — including containers — can be placed into which container.

The layout hierarchy is the basis for establishing textual layout rules for iViews. 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.

From Containers to the Layout Hierarchy - A Little Theory

iView 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.

Application Containers - Trays

At the root of the layout hierarchy there is a "root" container that contains the application. For iViews the application container is the tray. From an iView's point of view the tray is all it knows about - at least from a design perspective.

Figure 1: The tray is exclusively used as an iView container

Container Controls Inside iViews

Inside an iView, the following container controls define its layout hierarchy:

• Tabstrips
• Groups
• Subgroups (group of simple elements with or without heading — not included in a group control)

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

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

From a technical point of view, not all of these containers are "real" containers. For example, subgroups are groups of simple iView elements that may be introduced by a heading. They are typically separated from the remainder of the iView by whitespace or separator lines.

Figure 3: Simple groups are elements, which are introduced by a header; they are separated from each other and from other elements by whitespace

From a layout point of view, however, it is easier to view areas and subgroups as "real" containers. This does not make any difference for the layout process. The advantage of regarding these elements as real containers is that the layout can be expressed in a hierarchical or tree-like fashion, which makes it easy to gain an overview of the iView 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, tables, and images or charts. 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 aspect into account might state that tables may not be placed inside groups or tabstrips.

Figure 4: Even though a table is a complex control, from a layout point of view it is a "non-container" because it does not contain other controls

Separators

Separators, such as lines or whitespace set elements or containers apart. 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.

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

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 (IACs) and iViews. Both application types use different containers, serve different purposes, and therefore differ in complexity with respect to the layout. Here we restrict ourselves to iViews.

iView Layout Hierarchy

• Tray = iView container - may contain:
  • Tabstrip - may contain:
    • Group (if it is not the only element)
    • Subgroup
    • Table, Image, Chart (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, Image, Chart (if it is not the only element)
    • Simple elements (form elements, text, ...)
    • Separators
  • Subgroup - may contain:
    • Simple elements
    • Separators
  • Table, Image, Chart
  • Simple elements
  • Separators

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

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

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

Table Overview of the Layout Hierarchy for iViews

The following table present a more detailed description of the layout hierarchy for iViews. Red cells explicitly prohibit certain ways of nesting controls. Yellow cells indicate cases where elements can be placed into other elements with only certain restrictions. (See also the reasoning behind these rules; these are captured in general nesting rules)

Table 1: Layout hierarchy for iViews

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
• Where a "no" is shown in bold, it indicates a common error, such as nested tabstrips.

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 into tabstrips
• Singular tables with a table heading within group boxes

Avoid Too Much Framing (Visual Complexity)

Too many frames and borders make iViews 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
• Group boxes within group boxes — use sub 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

Specific Nesting Rules — Relations between Controls

Specific nesting rules care for the relation between controls - in short, they describe what can be placed inside a container control. You can extract the specific nesting rules for controls from the table overview above. In addition, we provide explicit rules for specific controls in Layout within iViews.

 top

Source:  SAP iView Guidelines