Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Diff btwen Hierarchical & Tree

Former Member
0 Kudos

Hi All,

What is the different between Hierarchical report and tree report?

L.Velu

1 REPLY 1

Former Member
0 Kudos

hi,

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.

Tree structures (short: trees) and lists are elements that can be used to model a large amount of data in easily readable form. They are particularly well-suited to representing hierarchical dependencies and give the user a clear overview of a large quantity of information.

Do Use

Lists and tree structures can therefore be extremely effective when they are used for the following areas, for example:

Trees allow an excellent overview of different objects that are related to one another. This means many objects are displayed, but each individual object only has a small amount of information.

Trees allow the modeling of graphical relationships between objects. Illustrations of this type can help promote orientation and comprehension of the relationships for users charged with performing a task.

Trees represent a central access point for navigation between different objects. The user can avoid frequent screen changes and having to remember where specific information is located.

Trees allow fast access with direct manipulation (via drag and drop) of objects within the structure. As a result, trees are particularly well-suited to activities that require users to re-sort or move objects.

Do not Use

To enable the above features, the trees and activity structure must "fit" one another. In some situations, the use of trees can cause more problems than it solves. For example, you should not use trees to:

Model existing hierarchical menu and navigation structures in the system without prior revision. Simply copying nested area menus into a tree structure does not help the user.

Display complex information in trees, as well as interface elements like pushbuttons or checkboxes. This is not recommended due to the complexity of the resulting tree and the limited space available.

Problems

In addition, the use of trees results in other typical problems:

Space requirements: The tree occupies space on the screen, restricting the size of the work area.

Visual complexity: Because the overall screen is divided into different areas, it appears to be more complex.

Complex interaction between index area and work area: Changes in views and highlighting for object selections have to be carefully coordinated between the two areas.

Too much information: Displaying too much information for individual objects in a tree can quickly make the entire structure confusing.

Misuse of icons and colors: It is easy to use unsuitable, too many, or confusing icons. The same thing applies to colors.

Assigning functions: It is often unclear which pushbuttons affect the tree structure and which ones affect the data.

Tree functions in menus: Functions that only apply to a specific tree structure can be "hidden" in various places in the menus.

Tree is used for navigation. By clicking on an entry the associated data is displayed in another place.

Hierarchy levels defined cannot be left out when displaying the UI element

a TreeNodeType element that is bound to the Orders must also exist to display the items for the hierarchy Customers ® Orders ® Items, which is defined in a context.

Regards

Sathish