The tree control is a popular choice for navigation in large, complex, web applications, but it’s one that I usually avoid. I avoid it because I think trees have a number of serious usability problems, which I’ll share here today.
What’s a tree control?
Let’s start with a brief introduction to the tree control. This control is present on both Macs and PCs desktops.There are two kinds of items in trees: the stuff (files, in this case) and the containers (folders). Each has an icon associated with it. To the left of the folders there is a little triangle used for opening and closing the folder. When the user clicks on that triangle, the container opens and the children of that container are shown, indented a bit.
It’s worth noting that there’s a big difference between the two platforms’ trees on the desktop. The Windows desktop tree only shows containers (the contents are shown in a pane to the right), whereas the tree on the AppleOS shows the contents in the tree itself. Many Windows based applications and web based applications freely mix both containers and items into the same tree.
Let me also note that in this article, I am talking about using a tree widget for navigation in a web application. That is, you take your application’s screens and put them into a tree. I’m not talking about trees used to present data (such as mail folders, or files in a file system – which is what is done on the desktop). Here’s an example of an application using a tree for navigation.
The example above is a pretty small application – it only has about 20 screens, so the tree control is really entirely unnecessary – they could have just listed all the links with no expand/collapse control and they would have easily fit in the space shown.
Long trees & Deep trees don’t work
When trees are long, they don’t work well. Here’s a product with 60 screens, all in a tree:
This controls scrolls for 4 screen fulls. Good luck finding the right screen in that list. Notice how, to save horizontal space, they ended up abbreviating all the labels, so that the whole UI has become utterly cryptic.
Below (on the left) is another long tree. We’ve scrolled to the middle of a long list of items. The context is gone. You can no longer see the parent of “Edit IP”. That’s another problem with long trees – it’s easy to lose the context of whatever you’re looking at. If you open a folder and reveal 40 children and then start scrolling, pretty soon the only thing you can see is the children. The parents are gone, the “aunts and uncles” are gone – all the context disappears.
Let’s imagine a different tree – a deep tree. If your tree indents just four times, it will start to look like the tree shown below.
In the image above on the right, we have a tree that is just 4 levels deep, and already we cannot read the labels for the items under “Report Alarm”. The only way to see these labels would be to make the tree wider or use the horizontal scrollbar, which is a lot of work to ask the user to do just to navigate to the right screen.
So the upshot of this is that the tree widget only works well when trees are short (not too many items in a list) and shallow (not too many levels deep).
All that clicking is annoying as hell
Most trees start out with the level 1 containers closed but that means that in order to get to work with them, you have to start clicking. And scrolling. A clicking some more. And all that clicking can be really annoying, especially if you’ve got a long way to go through an application to get to the screen you want. You can present the same list of screens with a lot less clicking (read my recent article on Stop Nesting Menus to show how I eliminate all the clicking from a menubar). In the application below, there are only two screens (Health Care Summary and Health Care Dependent Summary), but to get to them you have to open Self Service, then eBenefits, then Health (3 clicks).
This particular tree is “mostly tree” – they have a lot of containers and very few actual screens. That is what is making all the clicking – when the number of containers outnumbers the number of screens, you probably have a serious problem.
Are the containers also screens?
Using trees to list screens also brings all these nasty little interaction design problems. On both the Mac and Windows desktop, the container for the tree is a folder. A folder is not the same as a file. But in web applications, it can be hard to tell whether the containers in the tree are just containers, or actually screens.
Web applications are still experimenting with the right interaction design solution, here. So one thing I suggest is to be consistent: if you have a tree then all the contains should either be containers or screens, but don’t mix them. And then see if you can find ways to make it clear to users that they are (or are not) screens, so that they know what to expect. The example below doesn’t really do a good job of communicating whether or not these containers are just containers or also screens.
You can’t use two trees
Invariably, I will be working on an application that is using a tree control for navigation and then we’ll get to a screen where we really want to use a tree control to show the data. For example, in the application below we have a tree for navigation and then a tree that lists product categories. The categories are hierarchical and a tree is an obvious and proper way to view them. But putting two trees side by side just looks wrong. It’s hard to understand. When you use a tree for navigation, you lose the chance to use the tree anywhere in your application to represent data.
It’s a cop out
You know the expression that “when all you have is a hammer, everything looks like a nail”? When I see a tree control used for web navigation I always ask the team: how many other navigation widgets did you consider before you chose the tree? The answer is usually zero. Zip. Nada. What they did was to take every screen in the product and jam it into the tree. Done. That was easy – now they can get on with the actual coding and the rest of the design work. It’s consistent – consistency is good, right?
It’s not out of malice… Software engineers love trees because they like to think hierarchically. They like to classify things – their brains are good at that. A tree is fundamentally a widget for exploring hierarchies, so for a software engineer it’s ideal. The problem is that they have no real idea of how differently their minds work from everyone else’s. When it’s time to put on a UX design hat, it’s time to think like the user. Chances are good that your users don’t think hierarchically. And it’s certain that none of your users will ever know your application as well as the software engineers (and the designers) know it. Plan accordingly. Most users still don’t really understand the hierarchy of file system, much less the hierarchy in your application. Sometimes a tree is the right tool. Usually I find it’s not. But you shouldn’t just grab it as your hammer and start whacking on everything around you. Try other navigation controls. Be sure that the tree is the right answer.
When do trees work?
So when do I use trees as a navigation tool? When I can meet the following criteria:
- When the tree isn’t too long
- When the tree isn’t too deep
- When it doesn’t have a single root
- When the user doesn’t have to click a lot
- When you’ve sorted out the “are the containers actually screens?” problem – consistently
- When the screens lend themselves to a hierarchy
- When you don’t need a tree for anything else in the application
- When you’ve exhausted your other ideas
In the end I find that when it comes to large, complex web applications the most successful navigation systems are a blend of multiple widgets: tabs, subtabs, menus, tabbed menus and yes even trees. No one widget is really up to the whole task alone, and the tree is no exception.
Let me close with two examples where I think the tree works pretty well. It’s one I’m looking at right now, as I write this article. The tree in WordPress. The tree is not too deep – it’s only 2 levels. It’s not too long – there are a total of 48 screens in it. Icons are used judiciously and effectively. Different levels in the hierarchy have clear differences – Dashboards, for example, is completely separated from the rest of the tree and given its own treatment. The tree behaves well – if you open a container, it stays open.
Another example of a tree that’s been carefully crafted is the one used in Google Analytics. This tree enforces that only one item in the tree can be open at a time. That’s how they control length and manage the tree.
The astute observer will note that neither of these examples actually uses the tree control. Instead, they use a custom designed control that bears a passing resemblance to the tree control. I’m sorry but that’s the best I can do. I wasn’t able to find an example that actually uses a traditional tree control that I think is well designed.
I’m curious: Have you run into the same problems with trees that I’ve mentioned? Are there other problems that I failed to mention? Have you found reliable ways to overcome them? Are you offended that I have maligned the precious tree control? (Please remember, I did say that the tree control is no good as a navigation control – it IS good for lots of other things).