Selecting Views

Why Views? | Table Views and Form-Like Views | Choosing Controls for Switching Views | Views in Tabstrips | Dropdown List Box for View Selection | Link List for View Selection

Why Views?

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

For iViews collecting data into views is even more important than for regular applications, because space is at a premium and splitting has to be used with a smaller amount of data than usual.

Table Views and Form-Like Views

Large data sets are typically displayed as tables or trees (to be avoided in iViews), while singular data are displayed as fields which may be clustered into meaningful fields groups.

Tables: Scrolling vs. Views and Filters

The same data might either be put into a long table or tree that has to be scrolled or into a set of views. While scrolling provides a more sequential access, views lead to a more random-like access (of course, in both cases some parallel viewing and some sequential scrolling is involved).

In iViews tables typically have only few lines (typically 5-10). As a consequence, more scrolling is required than in regular applications.

Therefore, in iViews data should either be

1. clustered into views (with less scrolling), or
2. filtered to reduce the quantity of presented data.

Here we deal with views only. For using filters see Filtering Data - The Shuffler.

Forms: Views - Dependencies

Collecting data into views requires that the data views be independent from each other. This is the case with tabular data, but should also be the case if interface elements like the tabstrip or dropdown lists, link lists etc. are used for view selection (see below).

In the R/3 system forms-like data views often are not independent from each other; in spite of this, often the tabstrip is used to access the data views. For iViews, which are by definition simple applications, dependent data views are not allowed. Whenever there need to be dependent data views, use other interface options like wizards or screen changes - and do not implement this application as an iView.

Choosing Controls for Switching Views

There are several design options available for switching views in iViews - each has its own advantages and disadvantages:

• link lists
• tabstrip
• dropdown list box

The link list uses very little space and is rather Web-like; unfortunately it is only suited for displaying a limited number of items. Furthermore, link lists can seem visible unstable, especially if the views look very differently. Due to their nature and associations users can have with links (i.e. when clicking on a link one will be sent to another object or another page), link lists should be used for switching to views of different objects.

The tabstrip has the advantage that users can see all alternatives at any time (provided that the tabs fit into the width of the tabstrip; otherwise it should not be used at all). Thus users have a stable context and can navigate easily between the views, provided the views are not interdependent or have to be walked through in a fixed sequence. Tabstrips should best be used for applications or for screens on which to change an object's attributes (i.e. application-like screens, such as an Options dialog).

Use dropdown list boxes if

• users have to switch between larger numbers of views,
• the number of views may change dynamically
• the labels for the views are very long

On the negative side, users only see the name of the current view. Also selecting a view take more interaction steps than for the other design options. Dropdown lists should only be used if the number of option is too high to display them as a link list.

The table below summarizes the pros and cons of the different design options. Then the design options are discussed in detail.

Overview of the Design Options for Views

Table 1: Design options for views and their pros and cons

Link List for View Selection

In the case of only a small number of views, a link list can be arranged on top of the view. Like the dropdown list box version, this design option needs less space than a tabstrip. Furthermore, it is perceived as "Web-like".

Figure 1: A simple link list can serve for switching views

Views in Tabstrips

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

• The number of views is limited by the space for the tabs.
  -> Do not nest tabstrips to overcome this limitation - that is "information hiding"!
• Tabstrips indicate to the user that views can be accessed in any order; if this is not the case, avoid tabstrips.
• Tabstrips provide a rather "massive" appearance.

Even though space is limited in the tab area, the tab area should not be scrolled.

Figure 2: Tabstrips used to switch views

Dropdown List Box for View Selection

A dropdown list box at the 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).
• The label can be used as instruction.
• More views are possible, because space does not limit the number of views; however, the list should not be longer than about 12 items.
• The user cannot immediately see, which views are available (the user has to click the dropdown list box).

Note: The view should be activated after the user has pressed a "Go" button. This prevents users from selecting views inadvertently. It is also consistent with the shuffler.

Figure 3: A dropdown list box can also be used for switching form-like views

 top

Source:  SAP iView Guidelines