Creating lists means organizing data. The better your lists are organized, the easier the user will understand what the data means. 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 which 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.

Lets begin with a simple data structure! Often data consists of just linear lists where all lines have 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: (1) You can force the user to scroll the list horizontally or (2) 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 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, try to introduce vertical flight lines and, better, avoid three-line or multiple-line lists altogether.

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: (1) You may use nested headings, and/or (2) you may split the matrix into several matrices. The first case 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 seperate screens (a tab control would come in handy in this case). Splitting data makes it more difficult to compare. Decide on one of these solutions, dependant on what is important for the user!

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 the hierarchical lists discussed below. All these data structures contain some sort of hierarchy which may be displayed either in tabular or free 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.

Often, when data forms some sort of hierarchical structure, it is best to present them 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 the formal restrictions of lists need not be observed. You should 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 of the latter case. The file hierarchy of a volume also has an imposed sequential structure, because the files and directories are sorted according to some criteria, for example, they may be sorted by alphabet or by date of last revision. On the other hand, it has a "variable" hierarchical structure that makes it inappropriate for table-like presentation forms (such an alternative presents DOS with its DIR and CD commands), 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/4 list processor.

However, with hierarchies which are 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.

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 which is capable of displaying nets.

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 table-like design. In other cases, there may be no structure at all. We can only leave this case to your imagination and 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 chaos.