Design Tidbits

back Tidbits Overview

Tools for Design and Visualization


Interaction Design

Screen Design


Visual Design

Design Process

Web, Web Applications, Web Design





Fighting (with) Hierarchies – Part II: Presentation

By Gerd Waloszek, SAP AG, SAP User Experience – Updated: January 29, 2004

This article on hierarchies takes a closer look at the presentation of hierarchies. Hierarchies are often huge, complex and abstract. How can this mass of data be efficiently displayed in the restricted amount of space that is available on a computer screen? In this article, I demonstrate that there are many possible answers to this question.

Note: The first article of this series covers some basics of hierarchies; this article discusses the presentation of hierarchies.


What Is to Be Represented?

A hierarchy is an abstract and universal notion; this notion may be applied to structured data, unstructured information, Websites, or application structures. So, what does it really mean, if we talk about the presentation of hierarchies? What is to be presented? First, there is the structure itself which consists of hierarchically connected nodes. Second, there are the items (or the information), which are organized according to this structure. Third, there are structural units or substructures, which may contain other substructures and items. Finally, there is the path leading from the root node to another node at a certain level or to an item (leaf) on that level.

Schematic tree

Figure 1: Schematic tree; the nodes may, for example, be folders and the leaves files

So, let me collect what parts or aspects of hierarchies can be presented:

  • The structure, basically the nodes of a tree (e.g. the categories or folders)
    Example: the tree control in the Windows Explorer (left-hand side)
  • The structure including the items, that is, a tree with nodes and leaves
    Examples: the tree in the Mac OS Finder (list view), the Hyperbolic Browser, the site view in Macromedia Dreamweaver
  • A substructure, typically with nodes and leaves
    Example: the option to declare a certain node as root node
  • A path through the hierarchy – the nodes alone, typically from the root node to a target node
    Example: the path info in DOS; a path info in combination with setting a node as root node
  • A path through the hierarchy – including nodes and leaves
    Example: the Hierarchical Browser
  • The items without any regard to the internal structure of the data set
    Example: an alphabetically sorted list of all items in the data set
  • A subset of the items without any regard to the internal structure of the data set
    Example: the result of a filter process, i.e. a hit list

As you see, there is a wide range of options for presenting hierarchies, not only one universal solution (see below).

Click here to see images in one file (except Hyperbolic Browser).


Which Criteria Can Help to Choose a Presentation?

How do I know which presentation is the most suitable one in the current application context? The table below lists some criteria, most of them based on formal characteristics of the data set, which can help to distinguish between different presentations and to select the appropriate one.




Part/Aspect of Hierarchy

Structure, items, both structure and items together, path, both path and items

For details see list above.

The task determines which aspect or part of the tree needs to be displayed

Visibility Requirements

One view vs. two or more parallel views

The task determines how many parallel views are needed

Presentation of Nodes and Items

Present as text, as icons or symbols, as images or photos, in a detailed format (e.g. as a table)

The task and user level determines which type of presentation for nodes/items needs to be displayed

Size of Data Set

Different sizes may require different presentations

Small data sets can be linearized and need not be displayed as hierarchies

Depth of Hierarchy

"Flat" hierarchies may require different presentations than deep hierarchies

"Flat" hierarchies can often be reduced to one- or two-level lists and presented in a much simpler list-like fashion


The hierarchy may be abstract (e.g. a scientific taxonomy), or well-known to users (e.g. an organization)

Concrete hierarchies can sometimes be presented using metaphors. In addition, users have less problems in understanding them

The next step would be to add a "semantic dimension" and assign presentations to design problems or tasks using these criteria. In the section, Relationship between Task and Presentation I take a first step in this direction and try to relate presentations to tasks.


The Tree Control – A Universal Solution?

As hierarchies are by definition recursive, substructures can be handled in the same way as the whole structure. This feature makes hierarchies attractive to developers: their "standard" solution to the presentation problem is to use "generic" presentations that display hierarchies in a graphical or semi-graphical format regardless of its content. This means in practice that they implement the tree control whenever possible.

This approach has its advantages: once the users understand how hierarchies work, they can utilize their knowledge of the standard presentation, such as its notation and handling rules, and need not learn different rules for different presentations. On the other hand, such an approach assumes some formal education on the side of the users, a requirement, which may be reasonable for one user group but not for another. The broader the user group is for an application, the less likely it is that you can assume a formal education, and the less the target users will feel comfortable with hierarchies and with abstract notations.

As an example, many developers believe that users can handle hierarchies well, because they are so prevalent in today's operating systems. However, if you take a closer look at how people deal with hierarchies, this assumption seems to be a myth: you will find many users struggling with hierarchical file systems. There are, for example, users who prefer to work with diskettes because doing so does not require them to save files to some location on a hierarchically organized hard disk (this attitude may in turn lead to a disaster, because temporary files soon fill the diskette without the users even knowing that there is such a thing as a temporary file. Many users save files "somewhere" on the hard disk and have trouble finding them afterwards.


Example Presentations and their Characteristics

Now let's take a look at some "real" presentations and their characteristics. The basic presentations for hierarchies are the list, the semi-graphic tree and the (graphical) tree. These have already been introduced in the previous article. However, there are far more presentations for hierarchies in use. The following table lists some types, example implementations, and their characteristics.

Click here to see images of standard presentation techniques in on file; click here to see advanced presentation techniques in one file.




Characteristics of Example

Graphical Tree

Displays nodes or nodes and leaves (typically as boxes)

Uses connecting lines (or similar devices) for indicating levels and assigning items (leaves)



Typically nodes and items are boxes, realistic or symbolic (icons) images of the nodes/items

Hyperbolic Browser

Uses a hyperbolic spatial mapping which distorts the space in order to emphasize the active node and its surround

Semi-graphic Tree

Displays nodes or nodes and leaves, typically as text labels

Uses indentation for indicating levels and/or items

Nodes: Windows Explorer

Displays nodes; displays the items of one activated node in a parallel window

Nodes and Leaves: Mac OS Finder, Site view in Macromedia Dreamweaver

Displays nodes and leaves in one presentation (window)

Nested Boxes

Displays nodes or nodes and leaves as boxes

Uses a spatial metaphor, such as inclusion or height (typically together with inclusion) for indicating levels

TreeMap, WinSurfer, TreeViz

Indicates the hierarchy by nesting boxes; closely related to LISP notation (see below)

Hierarchical Browser

Displays a path through a tree with a window for the items of each sub-tree on the path

Displays the items on each visited sub-tree in a docked window with the item on the path highlighted

NEXTstep, Mac OS X, Masterfinder

Useful only for hierarchies no more than five to seven levels deep

Each separate path through the hierarchy requires an extra hierarchical browser

Windows for Levels

Displays a path through a tree with a window for the items of each sub-tree on the path

Displays the items on each visited sub-tree in a freely arranged window

Mac OS Finder, Windows if used that way

Typically more than one path can be displayed simultaneously; however, there is no clear indication of this in the interface

Bread Crumb (Path info)

Displays a path through a hierarchy, that is, only the category names (e.g. the folder hierarchy)

The current level is last in the path info

Path info in DOS

Indicates the active = current level in the directory; user may display the items using the DIR command

Changes within the path or within the hierarchy can be made via the CD command

Bread crumbs in Websites

Allows users to navigate along the path, especially to jump back to higher levels (level names act as links).

Text-based Notations

The hierarchy is indicated by using certain text attributes or characters and by the ordering of the textual information

LISP notation (programming language)

Uses brackets to indicate the hierarchy (in LISP called "lists"); in other notations brackets may not be necessary
Note: LISP expressions can also be expressed by nesting boxes

Nodes appear implicitly only; however, the first list item may be used as the node's name, e.g. as a function name

Click here to see images in one file; click here for advanced presentation techniques in one file.

Note: I will return to presentations for hierarchies used in operating systems and Websites in more detail in the fourth article.


Relationship between Task and Presentation

In the previous section, I listed some general criteria that might guide the selection of a presentation. But most of these criteria are based on superficial or formal characteristics of the data or presentation. Users, however, have to deal with hierarchies in the context of a certain task. So, one might ask, "Do I need to know what task the user has to perform in order to decide on a presentation for the hierarchy?" If it didn't matter, designers would simply strive for the optimal presentation and then done with it. This would be an ideal world for software developers because design would be easy. If it does matter, you as a developer would have to analyze the characteristics of the task (which may not be easy) and then find the best presentation based on these criteria. Of course, you could rightfully expect that some usability people already have solved this problem for you and that there would be a selection table somewhere to help you out. To my knowledge, there is no such table. Therefore, I suggest some preliminary criteria in the table below as a start in this direction.

Elementary Task Types




Psychological Features

Presentation, Design Proposal

Search I (Specify)

Specify an item – either fully or partially – and then start a search performed by the system

Example: Find a colleague in the address book

No presentation space needed

The tree need not be presented

Size and depth of data set is irrelevant for presentation

Relies on recall (easier than remembering items for a short time, harder than recognition)

Indirect interaction – the system does most of the work

May result in a huge result list or no result at all if the search criteria were specified inappropriately (many users have problems with this)

"Shuffler"-like design (attribute-based filter):

  • Input fields (free or fixed)
  • Hit list as output

No "tree" presentation is needed because the system does the search – not the user

Search II (Browse, Scan)

Browse or scan a hierarchical data set; here the user, not the system, actively searches a data set

Example: Browse the hard disk for a file (search would also be possible, but few users use this feature)

One presentation space suffices

Nodes and items need to be presented

Size and depth of data set matters

Relies on recognition (the easiest task)

Direct interaction – the user is in command

May be inefficient for large data sets. Users may overlook the search target


Large data set: Tree presentation such as

  • semi-graphic or graphical tree
  • Hyperbolic Browser
  • TreeMap

Small data set: Ordered list (ordering criteria may be changed by the user)

A text-based presentation is possible (see the CD and DIR commands in DOS) but inferior to graphical presentations


Compare two or more items (names, attributes, ...)

Example: Six new digital cameras appear on the market; users want to compare their features on a digicam Website

Example: A user wants to compare two or more files from different sections of the hard disk to find the most recent or useful version of a document

Two or more presentation spaces needed

Presentation of the data set depends on how the items are located before the comparison

Size and depth of data set matters

May rely on short term memory if the items cannot be presented in parallel (the hardest task)

Direct interaction – the user is in command. However, may be cumbersome if the user has to remember items and to switch between them

Example: Items reside in different windows, which cover up each other and have to be brought to the front in turn

Comparison (attributes, textual information):

  • Few items: side-by-side presentation
  • Many items: table presentation

A specification or browsing may be needed to locate the items first

Assign, Reassign

Change the position of an item or node within a hierarchy. Complex variants may include the movement of noncontiguous items or nodes; however, such complex tasks should be avoided

Examples: A new colleague has to be assigned to a cost center; a colleagues moves to another department and has to be reassigned to a different cost center

Two presentation spaces needed

Typically, nodes and items need to be presented

Size and depth of data set matters

May rely on short term memory, if the items cannot be assigned directly (the hardest task)

Direct interaction – the user is in command. However, may be cumbersome if the user has to remember items, to assign them textually or if drag-and-drop may cause problems (too many windows, too little space)

Example: In Windows you can use clipboard operations for copying or moving files, on the Mac you cannot – you have to rely solely on drag-and-drop operations

Double-list or double tree for simple (re-)assignments between sets or sub-trees.
Example: Font Mover

Full-fledged tree with possibility to drag items or nodes
Example: Directory display for hierarchical file system

Text-based (re-)assignment
Example: DOS, older R/3 applications

Role of Context

When choosing a presentation, you should ask how much context is needed for processing the target items. Display just these items, not the whole data set if it is not needed.

Context Needed

The necessary context may vary; it may be:

  • The whole data set
  • The items on a specific level – so, only this level needs to be displayed
  • The categories only – so, the items need not be displayed
  • A path – either the categories only, or both categories and items, again either at one or at several levels – so, only the path needs to be displayed

Typically, the context is needed for tasks that involve several items, such as comparisons, or that put items in relationship to a category, such as assignments.

The context may also be useful if the user switches frequently between items.

No Context Needed

Often the user is only interested in one or a few items within a data set. Then it may be better to display only this or these items (e.g. in a hit list or in a comparison table). Do not bother users with the rest of the data if they are not involved in the task. For example, many applications reserve a screen area for the whole data set, typically displayed in a tree control, even though none of the items is accessed when the task is executed.

The context is also not needed if the user works with one item for a longer period of time or does not switch between items.


Formally all hierarchies are the same, and the category and item labels could be arbitrary. In the "natural setting" of a user performing a certain task this is not the case – semantic issues play an important role:

  • Category names can make a difference when users scan hierarchies; if the names are inappropriate users may not find the items they are searching for because they do not know where to search.
  • Sometimes it is difficult to find suitable category names. Example items can help users to understand what a category name stands for.


The CHI '97 Competition

Let me illustrate the relationship between the presentation and the task type by using a competition, which took place at the CHI '97 in Atlanta, GA, as an example. This competition, misleadingly called a "browser competition" (the presenters meant tree browsers, I expected Web browsers), compared the efficiency of different tree presentations.

Tasks Types

Expert teams were asked to perform at the most ten tasks from a set of four task types under time pressure. The four task types varied in complexity:

  • Simple Tasks (search): Find lake Victoria
  • Local Relations (within one category): How many Dutch kings did not have the name "Willem"?
  • Global Relations (between categories): Which Greek god has the same name as an Egyptian god?
  • Complex Task (complex relations): Which army is commanded by a "generalissimo"?

Presentation Types

Each team used one of the following presentation types:

  • The Hyperbolic Browser
  • Semi-graphic treelike presentations, such as the Windows Explorer and WebTOC (two teams)
  • A presentation based on the spatial "inclusion" of tree levels, the TreeMap (WinSurfer)
  • A fully text-based presentation - DOS (as a "fun" entry by some students)

Click here to see the more advanced presentation techniques in one file.

The tasks were performed on a database of about 1500 nodes on a hard disk directory with the nodes being folders (folder names = category names) and the leaves being files (file names = information).


The Hyperbolic Browser was the overall winner of the competition, with the Windows Explorer and WebToc coming in second. Although the Hyperbolic Browser scored well in most tasks, the team struggled whenever it had to establish relationships among items because the members were forced to remember items that were distributed over distant parts of the tree. Other teams, however, had the same problem. Note the breakdown of the Windows Explorer for complex tasks; interestingly the WebTOC browser fared much better, even though it is based on a similar presentation technique.


Tree Browser






























Hyperbolic Browser






*) One participant not included

In a "laymen test" the Hyperbolic Browser and WebTOC fared equally well; the winner, however, was a paper-based filing system.


At closer look it is evident that some of the tasks could be performed much more efficiently using searching instead of browsing. This was, of course, not the intention of the browser comparison. But as an interface designer you should indeed ask whether browsing is the best solution for the task at hand.



Obviously, I scratched only the surface of the presentation issues for hierarchies in this article. Information visualization is a rich field in itself, and there are many good books available. One of the latest additions is Robert Spence's book "Information Visualization," which covers many of the newer presentation methods mentioned in this article.



Robert Spence (2001). Information Visualization. Addison-Wesley, Harlow, England (Review).

Ben Bederson & Ben Shneiderman (2003). The Craft of Information Visualization: Readings and Reflections. Morgan Kaufmann (Review).


top top