Facibus Reviews

I find myself today having to advise on why trees are a poor choice for navigation. I know they’re wrong - I used early versions of XMLSpy and had to find the right node to edit (which is great for people that speak XML, and need to directly edit it, but you wouldn’t wish it on a non-coder).

I googled to see what was out there in peer-land, and came across some good articles:

• Why is a tree view a poor navigational choice?
• Tree view removal surgery

If you know of any others please leave a comment.

The one and only use for trees is where a strict taxonomy is available and enforceable, and expert knowledge can be assumed. I’ve used them myself under these strict circumstances - please see the Browse by body system hierarchy at pbs.gov.au. Expert knowledge (in this case medical) can be assumed. But that is it - any other use of trees should be used with extreme caution. I think that Why is a tree view a poor navigational choice? says it all (where ESA is an Enterprise Software Application):

1. Many types of artifacts: Typically in ESAs, the tree is composed of artifacts like actions, files, and tasks. This type of hybrid scheme is confusing as it makes it difficult for users to make a consistent mental model.

2. Non consistent mental model: A non-consistent mental model increases memory load and makes learning difficult. Even experienced users make mistakes if there is a hybrid scheme.

3. Many points and clicks: To find any action, file, or a task, a user usually takes many points and clicks.

4. Clicks are actually slow: Though pointing and clicking seems lightning fast, but remember Fitt’s Law - each point and click takes a whooping 1 to 1.5 seconds! Each find and final click may take anywhere upwards of 10 seconds.

5. Poor navigational help: A tree structure offers poor help to find and select next logical task after completing the current one. It forces users to learn the next logical step.

6. No use of spatial memory: People use spatial memory to find artifacts on a screen. However, the tree structure does not support spatial memory - makes it harder to find artifacts. It also increases the time to find artifacts.

7. Poor location information: A tree typically provides poor navigational clues - does not tell where the user is now, what is clicked, and what is open. To provide all these clues, a software developer spends a lot of energy.

8. System model differs from user mental model: A tree helps software developers put artifacts as in the systems model. This model is usually very different from the user’s mental model.

9. Takes too much of space: The tree typically takes more than 20% of screen space. This amount of space for navigating from one point to another is a waste of precious screen area.

10. No corresponding content: Software developers believe that each “leaf node” in the tree must be associated with a corresponding screen. These corresponding screens typically dont contain any content and are shown blank or with content that users never need.

11. Vertical and horizontal scrolling: In most cases the tree is open. In this position the actual content is hidden behind the scrolls. This does not help users to find out where they are.

12. Difficult to implement: Contrary to popular belief, implementing a tree view by a developer is very difficult and time consuming. The basic implementation is fast, however, tweaking the tree view for good user experience is time and resource intensive.

13. Only IT users understand deep hierarchies: In our experience, we have experienced that only IT (read developers) understand deep tree structures. Others just refuse to understand tree structures with more than 2 types of artifacts (like files and folders). So, files in a folder or folder in a folder is okay, but sub-process in a process, process in a business location, business location in a business, and a business in an enterprise in NOT okay - it is confusing.

Anyone differ?