Designing Lists

A Lists Classification Scheme | General Design Guidelines | Highlighting Important Information | Hotspots

General Considerations on Data Structures and Presentation Forms

When designing lists, it is important to present the information in a simple layout that is easy to understand. As an aid, we first discuss general data structures and ways in which they can be presented.

Creating lists means organizing data. The better you organize your lists, the easier the user will understand what the data mean. In the following, we discuss some issues that may help you in organizing your lists.

Data may occur and be organized in endless different ways. Ideally, each data structure should have a corresponding form in that it is always presented. However, since data is often complex and can be viewed in such a different number of ways, there must also be a number of different ways in which they can be presented. This is one of the strengths of the R/3 System, but it makes list design harder for you.

Linear Lists: Single-Line and Multiple-Line Lists

Let us begin with a simple data structure! Often data are just linear lists with all rows having the same column structure. This is the simplest and most important case. Normally, you display such data in a one-line table or list. There are cases, however, where the list is wider than the screen or window width. You have two options for this problem: You can force the user to scroll the list horizontally or you can transform the one-line list into a two-line or even multiple-line list. In the first case, it is important that the most frequently used data columns appear on the left so that the need for horizontal scrolling is minimized. In addition, you can fix data columns - usually you fix the key columns - so that users have horizontal guidance. There are, however cases, where scrolling is not possible or not appropriate. Here, you "fold" the "logical" lines into several "physical" lines, thus creating a multiple-line list. Such lists usually look very disordered. Often you cannot use vertical lines for separating the columns, and you can display fewer logical lines simultaneously on one screen. Therefore, it is very important that you design such lists carefully and try to introduce vertical flight lines. However, it is much better if you avoid three-line or multiple-line lists altogether.

Note: Single-line and multiple-line lists should be replaced by ALV.

Matrices

Sometimes data is not arranged sequentially but according to two or more aspects or variables. With two variables, you get a rectangular matrix scheme, which is easy to handle (if it is not too wide). With more variables, you are in trouble - the more variables, the more trouble. In this case, you can do the following: You may use nested headings, and/or you may split the matrix into several matrices. In the first case, this may help for up to three variables per axis. It is very likely that your matrix will no longer fit on the screen horizontally. In many cases, it may be better to split the data into several matrices arranged one below the other or on separate screens (a tab control would come in handy in this case). Splitting data makes it more difficult to compare them. Decide on one of these solutions, dependent on what is important for the user!

Note: Matrices could not be replaced by ALV.

Hierarchical-Sequential Lists

This type of data structure has a horrible name, but is nevertheless important to the R/3 System. It is closely related to multi-dimensional matrices as well as to the hierarchical lists discussed below. All these data structures contain some sort of hierarchy that may be displayed either in a tabular or in a tree form. A tabular form is preferable, if the "leaves" of the tree are simple linear lists, as is the case with hierarchical-sequential lists. With matrices, the leaves usually consist of one element only, but the tree is "complete", that is, all combinations of variables have to be displayed. This again calls for a tabular design. Trees are more useful, if the hierarchy is irregularly shaped, is partially visible, and involves a lot of interaction.

As you will see below, hierarchical-sequential lists usually form the cross-section of a multidimensional data cube, where the dimensions create the hierarchical part of the data structure, and the data creates the sequential part of it.

Below you can find guidelines for implementing hierarchical-sequential lists. But keep in mind that there is an alternative solution to this presentation problem: You may also split the list into several simple lists, one for each group, which will follow one below the other or are distributed onto several screens (a tabstrip come in handy).

Note: Hierarchical-sequential lists could be replaced by ALV lists. But check first whether you can present your data by a linear list type.

Hierarchical Lists and Trees: Hierarchical Data Structures

Often, when data forms some sort of hierarchical structure it is best to present it in a tree-like fashion. You can present such data in a format that closely resembles a list (semi-graphics), or you can present it in a more graphical form where you need not observe the formal restrictions of lists. Choose the first case, where space requirements are tight, graphics cannot be used, the hierarchy is not too deeply nested, and if there is some sort of sequential structure imposed on the data (according to the user's point of view!). The Windows file manager is a good example for the latter case. A volume's file hierarchy has also an imposed sequential structure, because the files and directories are sorted to some criteria. For example, they may be sorted by alphabet or by date of the last revision. On the other hand, it has a "variable" hierarchical structure that makes it inappropriate for tabular presentation forms, as files and directories are permanently added and/or deleted. In addition, the file hierarchy is often not too deeply nested. While Windows uses graphics for displaying the file hierarchy, this hierarchy is equally well displayed in the semi-graphic list-style of the ABAP list processor.

However, with hierarchies which are more complicated and/or more deeply nested, you should consider using the R/3 Business Graphics. This tool also provides the graphics in a separate window which may be of advantage in many cases. However, such a presentation form also involves more complexity for the user. So, consider the advantages and disadvantages of either solution, before you use Business Graphics.

For detailed informations see Tree structures.

Nets

Nets are data structures with more complex interconnections than the hierarchical ones in trees. In their simplest form, they are just trees with loops or with only a few cross links between their branches. Here, you can try to split the nets into several trees. In more complicated cases, you have to use a graphics system like the R/3 Business Graphics that is capable of displaying nets.

Note: Nets could not be replaced by ALV.

Data with Little Structure: Object Lists

This case is the most irregular, and it may be the most difficult when you are designing lists. For instance, the data may have a basic sequential structure, but each block of data may have a different structure so that you cannot use a tabular design. In other cases, there may be no structure at all. We can only leave this case to your imagination. We urge you to try to impose some sort of structure onto the data in order to help the user find his or her way through this data chaos.

Note: Object lists could not be replaced by ALV.

top

Source:  SAP R/3 Style Guide