Layout

Trays

iViews use trays as container. The tray is added automatically to the iView by the Workplace environment (more information on trays is available: see iView Framework - Trays).

Figure 1: Different types of trays, depending on the overall page layout.

Figure 2: Usage of different types of Trays.

Figure 3: Templates for different screen resolutions.

More information on Column Usage and Workplace 3.0 Metrics can be found in the PowerPoint presentation.

Note: Trays are reserved for use in iViews! They are not allowed for IACs (Internet Application Components) or other application types.

The tray contains a header bar with the following elements

Title
Edit Button
Collapse Button
Close Button

The title should be descriptive so that users easily understand the purpose of the iView. It has to be defined statically in transaction PFCG.

Proposal
The title can be set dynamically. For example, the title of a collapsed iView may dynamically display the number of unread e-mails.

For more information on trays see iView Framework - Trays.

Tabstrips

Tabstrips may be used in iViews, for example to display different views; however their use should be restricted to cases where the views look very differently (e.g. tables of different width) and where other presentations would cause an instable environment.

Figure 4: Tabstrip with table inside

Tabs may contain dynamic information so that users get a quick overview and are informed about important data, events or changes within the views.

Tabstrips may contain tables or group boxes.

Tabstrips may not be nested! This is "information hiding".

For views and alternatives to tabstrips that consume less space, see Selecting Views.

Group Boxes

Group boxes may be used in iViews, but only if there are no other methods available for separating fields or information. We rather recommend considering using white space for grouping / separating elements.

Group boxes may not be nested!

Several types of group boxes have been designed. At this time there are no specific rules as to which tray should be combined with which group box. Nevertheless, there does exist a rule of thumb: Always arrange group boxes from dark to light - if you have to use group boxes within trays, place lighter group boxes within darker trays.

The different box designs (see below) use headers to describe their content. These headers can be formulated either as object descriptions (e.g. "Address Data") or as instructions (e.g. "Enter Address Data").

You can see the different group box designs below.

Figure 5: Group box designs.

Alternatives to group boxes:

separating groups by white space or lines
labelling groups with simple headings (possibly in combination with separators)

Group boxes should not contain:

Tables
Tabstrips
Trees

Tables

Tables are "high level" screen elements. You can place tables in tabstrips (see figure 4 above), but not in group boxes. Take a look at PortalDataViewer and Tables, as well.

Figure 6: Table

Trees

Trees are like tables "high level" screen elements. You should avoid using trees in iViews, especially trees with more than 2-3 levels. Consider using dropdown lists, the shuffler (filter) or tabstrips in combination with tables in order to select partial data sets. This leads to a far less complex user interface than large trees that have to be scrolled or paged through.

Figure 7: Tree

You can place trees in tabstrips, but not in group boxes.

Separating and Grouping Screen Elements

To separate and group screen elements, rely on the Gestalt Laws. The most prominent one, the Law of the 'good Gestalt', states that the human brain always tries to organize the perceived elements into sensible structures. Following the Law of Proximity, items that are spatially near to each other are seen as belonging together - no group boxes needed!

Use empty lines or columns (white space) for structuring information in iViews: Field groups, tables or compound elements like the shuffler should be separated from other elements by empty lines.

Example: A shuffler should be separated by an empty line from the table below it.

Whenever possible, use empty lines instead of group boxes for clustering screen elements. Empty lines use less space and are visually less complex than group boxes (group boxes also currently interfere with the tray design).

Exception: When using narrow iViews of half height, there is little room left for the content. In this case, try to design the iView without separating elements, that is, without empty lines. Make sure that the layout does not become confusing!

Starting Point for Placing Screen Elements

The placement of screen elements should typically start in line 1, column 1 - thus, the starting point for the layout is the upper left corner of the screen. Do not insert spaces or other spacing elements manually - the correct distance to the iView frame will be created automatically when the iView appears in the Workplace.

top