Views

Views as Screens | Views in Areas | Views in Tabstrips | List or Tree for View Selection | Dropdown List for View Selection | Button Group or Toolbar for View Selection | Overview of Design Options for Views

If the amount of data is large, the data have to be split into several groups, called views (actually, a collection of data could consist of just one view). A view presents a meaningful (sub)set of data.

In the past, views were typically presented as a sequence or network of screens. With the introduction of tabstrips, this control became the mostly used mechanism for displaying views. However, on the web (and even in R/3) there are alternatives to using tabstrips.

Note: The examples are schematic only - they do not exactly follow the current standards for visual design.

Views as Screens

Before the introduction of the tabstrip in R/3, views were presented as screens that were arranged as a sequence, or a network.

Access of Views

For a sequence, users have to step through the screens using functions like "Next Page" and "Previous Page". On the web, especially if the number of views is small, views can be directly accessed via links, or pushbuttons with labels that indicate the purpose or contents of the views.

Sequential Access vs. Random Access

Strict sequences are typically used, if the system wants to guide users. This should be the case for novice or casual users, especially for complex, or critical procedures.

A strict sequence makes also sense, if there are dependencies between the views. It might also happen that depending on the user's actions the sequence of views is changed dynamically during the progression of the views. This behavior can be hidden from the user, if strict sequences are used.

If there are no dependencies between views, direct access to the views should be provided. In addition, a "default" sequence can be offered to the users that simplifies the processing of the "typical" cases. For random access the number of views should not be too large.

Screens vs. Tabstrip

Both screen-based views and tabstrips allow random access; for screens you have to provide links, or "direct-access" buttons in this case. The main difference between both designs is that tabstrips provide a more stable frame of reference when users change the views. In a more extreme case, a tabstrip may comprise only a smaller part of the screen, and changing the view lets most parts of the screen remain unchanged (at least to the impression of the users).

Screen changes, even if larger parts of the screen remain unchanged, cause the impression of loss of context, especially, if a screen refresh or page update does not happen instantaneously. Thus, screen changes should be restricted to cases, where in fact the context changes, or where the look of the screen changes totally.

Views in Areas

Views may not fill a whole screen, but only a dedicated area on it. In this case, space is more limited and may require to break down the data into more views, or to make the area scrollable.

The selection of the views (or access to the views) can be handled differently:

• In the same area:
  • Tabstrip
  • Dropdown list
• In the same or in a different area:
  • Link list, tree with links (web)
  • List or tree with selection mechanism (R/3)
  • Button group or toolbar

The different alternatives are discussed below.

Views in Tabstrips

Tabstrips are the current "state-of-the-art" control for displaying views. However, note that there are some problems with using tabstrips:

• The number of views is limited by the the space for the tabs (no dropdown list for tab selection on the SAPGUI for HTML).
  -> Do not nest tabstrips to overcome this limitation. Nested tabstrip "hide" information, because users have to search the tabs on all levels, if they have no clue where the information is.
• Tabstrips indicate to the user, that views can be accessed in any order; this is often not true in R/3; in this case you should avoid tabstrips.

Space is limited in the tab area. The tab area should preferably not be scrolled.

List or Tree for View Selection

This solution for selecting views is usually a "two area" solution: In one area there is the index to the view which can be a list or a tree (if a hierarchical presentation is really needed), in the other area the respective data are displayed.

Figure 1: A link list in a separate area switches the different views in another area (not functional)

In R/3 usual lists or trees can be used, because there is a selection mechanism implemented for them. In the web, lists and trees use links for item selection.

In the case of only a small number of views, the link list can be arranged on top (and at the bottom, if the view is large) of the view, as shown below. This design solution is functionally similar to the tabstrip, but consumes less space.

Figure2: A simple link list on top of the elements switches the different views (not functional)

Dropdown List for View Selection

A dropdown list on top of a screen area can also be used to access views; basically, there are the same limitations as with tabstrips.

Here are some of the advantages and problems of this solution:

• Consumes less space (no borders).
• Label can be used as instructions.
• More views possible, because space does not limit number of views; however, the list should not be longer than about 12 items.
• The user does not immediately see which views are available (the user has to click the dropdown list).

Figure 3: The dropdown list switches the different views (not functional)

Button Group or Toolbar for View Selection

It is also possible to use a collection of buttons to select individual views. These buttons can be placed into a toolbar (which might reside somewhere else) or simply grouped above the view area.

This solution only makes sense for a limited number of views (but more views than might be possible with a tabstrip). However, this solution should only be used, if the respective user interface can realize a "depressed" state that indicates which view is currently selected.

Figure 4: Buttons switch the different views (not functional, depressed state not indicated)

Overview of Design Options for Views

top

Source:  SAP Interaction Design Guide for Internet Application Components