UI logo
The Webzine for Interaction Designers
uidesign.net
 
     
August 1999
  Tree Component Usage Guidelines

 

Introduction

Tree Component for UI navigation and hierarchical data display have been with us for around 5 years. Despite there wide and common usage, little has been written about when it is good to use a tree and how best to use them. As I promised in April, I am now publishing the results from a debate that I started on the UIDesign.net discussion list. Thanks to all of those who contributed. The content of this article has also appeared in Swing by Matt Robinson and Pavel Vorobiev. This is a taste of the UI Guidelines from the book. Due to my exposure to Java in recent years this article is particularly relevant to Java JFC developers but should be useful for Windows, Motif and Mac developers too.

Tree is a very powerful and sophisticated Swing component. It can often be used for the display, navigation, and editing of hierarchical data. Hierarchical data is, by its very nature, complex and the Swing JTree component is also complex. Care must be taken when selecting to use a Tree in a UIDesign and further care must be taken when selecting which of the many facilities to utilise for a given domain problem.

Earlier Advice

I first turned to the books on my shelf when thinking about Tree usability guidelines. All I could find was a paragraph in Alan Cooper's About Face which said "unfortunately it is problematic for users because many people have trouble with hierarchical data structures. If treeview contents are restricted to no more than two levels, however, it can nicely show a monocline grouping of data".

So not much there but a hint that using Tree is difficult and problematic.

The much newer Java Look and Feel Guidelines have had the benefit of 4 years experience to come up with some advice. So what did they have to offer?

  • Display the 2nd level as the top level. Don't bother with the root node
  • Always display the turners (or +/- icons in Windows) to show the user that a node is expandable

and that as they say was that! Not much to go on. The first point I believe is sound. In most cases you just waste space with the root. In the banking application that I designed in Singapore, we almost always missed out the root node which was usually the Bank (corporation) and went straight to the display of the 2nd level nodes, usually the branches (of the bank, too many leafs and branches here, Ed.)

Usage of Tree Component

When to use a tree
1. As a selection device
Tree component was invented as a mechanism for selection from large hierarchical data sets without having to resort to a "Search" mechanism. As such Tree falls between List and Search as a component which can improve usability by easing the process of finding something, providing that the item to be found (or selected ) is hidden within a hierarchical data set.
For example, finding a employee by name. For a small data set, a simple List may be sufficient. As the data set grows, it may be easier for the user if you sort the names alphabetically, or by department in which they work. By doing so, you have introduced a hierarchy and may now use a Tree component. Use of the tree component may help and speed random selection from the data set, providing that the hierarchical structure used exists within the domain. i.e. don't introduce artificial hierarchies and expect users to understand them. More explicitly, if you can put the hierarchy into your Analysis Model and Users accept it then its fine. If you can't then don't and consequently, don't select a tree component as the solution.
As a data set rises to become very large, tree component may again be of little value and you will need to introduce a full search facility.
As a general rule, when using a tree as a selection device, you would start with the tree collapsed and allow the User to expand it as they "search" for the item they are looking for. If there is a default selection or a current selection then you may expand that part of the tree to show that selection.

2. As a Visual Layering Device
Even with a small data set, you may find it advantageous to display a visual hierarchy to aid visual comprehension and visual searching. With the employee example, even for a small data set, you may prefer to layer by department or by alphabetical order. Even if selection is being used in the UI, it is important to understand when you chose to use the tree component for improved visual communication i.e. selection would still have been perfectly possible using a List but for visual communication reasons a Tree was chosen.
When a tree is selected for display only i.e. no selection is taking place, then you are definitely using the tree as a visual layering device.
As a general rule, when you use a tree as a Visual Layering Device, you will by default expand the tree in full, revealing the full hierarchy.

How you use a tree and which options to select amongst the many selection and display variants, can be affected by the usage as discussed below.

 

Visual Affordances in a Tree Component

Icons & Root Handles
Icons used on each node and leaf are overloading on the root handles to communicate whether an element is a document or a container and whether that container is open or closed. For example, a book icon has two variants to communicate "open book" and "closed book". The icons are communicating the same information as the root handles which can be turned to display open or closed.
Therefore, it is technically possible to remove the root handles. In some problem domains, hidden root handles may be more appropriate, providing that the Users are comfortable with interpreting the book icons and realise that a "closed book" icon means that the node can be expanded.
In my own work I have tended to do this. Discussion on the list seemed to bear this out. It seems to be generally accepted that root handles offer poor usability whether in Java L&F or Windows or Mac or Motif. Many contributors reported problems with all the various iconic representations e.g. +/-, arrows, turn handles. These are idiosyncratic widgets which require idiomatic learning i.e. training of users is essential. In my own work, I have tended to rely on the icon communicating along with the text and the users domain knowledge which will tell them whether they are viewing a node or a leaf. Personally, I find the root handles add visual clutter and in many data domains they add nothing. This is pure anecdotal evidence. I wonder if anyone reading this has real usability experimental data to back it up?
So in this key area, I am in disagreement with the new JLF Guidelines. A key example showing that it doesn't do to be too dogmatic about adherence to guidelines and standards.
However, it is also worthy of comment that the root handles usually require a single mouse click, when some operating systems require a double click on the icon to achieve the same expand or contract behaviour. You may prefer to have the added visual clutter and extra space in exchange for the single mouse click.

 
When to use connecting lines
Angled connecting lines (or edges ) add visual noise and clutter to a tree display. Reduced visual clutter aiding recognition and comprehension is a clear advantage to leaving them out of the design. So when is it appropriate to have them included? The JLF Guidelines offer no clues, simply stating that two types of lines are available. So here is my advice...
Include the line edges when it is likely that:-
(a) due to the domain problem, several nodes may be expanded at the one time
and/or
(b) the data set is very large and a node may expand off the bottom of the screen and perhaps several screens deep. In this case the introduction of the lines, helps to give the viewer a clear picture of how many layers deep in the hierarchy they are viewing and makes it easier to trace back to the original root node.
JLF also introduces the idea of separator lines rather like HTML horizontal rules. These separate the top level nodes in the hierarchy. I believe that these will have a similar usability effect as has been seen in HTML with horizontal rules. They will act as a stop to the user scrolling. Causing the user to pause and consider the boundary that they are crossing. I think that this is important in large data sets. Hence,
(a) use a horizontal separator when you have a very large data set which will need to scrolled significantly for the user to find the relevant data.
(b) use horizontal separator when the data set is large but the first level is only a small number of items, making the boundaries between top level items very important to highlight.

 
Visually reinforcing variations in behaviour
If you intend to introduce context dependant pop-up menus on tree cells, or any other context dependant behaviour then this is an ideal time to consider the use of a tree cell renderer which incorporates an icon. The differing icons help to reinforce the idea that the data on the cell is of different types and consequently when the behaviour is slightly different across nodes, it is less surprising. The icon visually reinforces the difference in behaviour.

 

Enhanced Usability with added widgets

Tooltips as an aid to selection
Tooltips have two really useful advantages for tree cells. Trees have a habit of wandering off to the right hand side of a display, particularly in deep hierarchies. This may result in cell labels being clipped. Using the tooltip to display the full length cell label, will speed selection and prevent the need for scrolling.
The second possible usage of tooltips is used to unravel the hierarchy, display the full path. This would be particularly useful when the original root node is off screen. The User can see quickly, the full hierarchical path to the selected cell. This is a very powerful aid to correct selection. Another example of additional coding effort providing improved usability and why straight out of the box UI toolkits are often not good enough.

 

Guidelines on Hierarchical Data

Family Trees and Organisation Charts
There is still considerable debate in the UI Design field as to whether Tree component is appropriate for displaying and manipulating Family Tree style data which is often portrayed using a distributed graph. Some distributed graph components have become available for Java. There was a particularly useful one provided by Java Developer Journal last year.
Generally, Family Trees or Organisation Charts are displayed using a top-down (horizontal orientation), evenly distributed graph. Therefore, the Tree component view with its Left-Right (vertical orientation) is alien for this type of data.
If your User community is particularly technical then you should have no difficulties, however, consider carefully before selecting tree component for a wider user group, in this instance.
You may also like to consider that such a tree component could be used a prototype or "proof of concept". You could later replace the Tree component with an OrganisationChart component.

 

Summary

Before using Tree Component in your design, be very sure that the User Task requires it. Don't get trapped into the idea that Hierarchical data must be presented with a hierarchical component. Consider other methods such as flat data display in a table or using a Search Criteria. If the hierarchy is not widely understood by users because they do not consider the domain as hierarchical then do not use a Tree at all. Just because you have a hierarchy in the object or data model doesn't mean it should be on the screen.

If you must use Tree Component then think carefully and consider all the issues. Consider the problem domain and level of user knowledge. Consider how well you can iconify the containers and leafs in the tree. How well can you visually communicate with the user. When you have the answers to these questions then you can decide how best to use Tree Component.

Acknowledgments

This paper was developed from the work I did for the Swing book by Matt Robinson and Pavel Vorobiev (see August news). It was also developed from feedback on comp.human-factors and from the UIDesign.net discussion list. The following people all contributed to that discussion: Stephen Palmer, Matt Robinson, Phil Bradley, Christine Ridgen, Terry Simpson, Jeff De Luca, Theo Hendriksen, & Mike Anderson. I also referred to About Face by Alan Cooper and the Java Look and Feel Guidelines by Sun and the March 99 UI Design Update by Dr. Bob Bailey at humanfactors.com. Further evidence for small levels of depth is in William Horton's 1994 book, Designing and Writing Online Documentation.

 
uidesign.net
hosted by likk.net		            
 
Copyright uidesign.net, 1999 - 2003.
The UI logo device and uidesign.net wordmark are trademarks of uidesign.net