Interaction Design for Trees
Let’s talk about how to use trees in interaction design, and we’ll start with the fundamentals. If you’re thinking you may want to use a tree then you are working with hierarchical information.
Trees work best when users already know the hierarchy
I often find that the people who are the most enthusiastic about using a tree control are the ones who know the hierarchy the best. Let’s start by thinking about two things: who made the hierarchy, and do my users know the hierarchy?
Option #1: It is known
In the case of the geography-based tree (Tree A, above), the hierarchy has been built, collectively, by humanity in the naming and location of our countries. As a designer, you might be able to make the assumption that most of your users know and understand the tree. If so, they will likely find it very easy to quickly use tree controls to navigate to a specific county, such as Canada. But even with “well known” trees, users may struggle to know where things are classified. Could you reliably find Russia? Armenia? Slovenia? Nauru? Ask yourself honestly, do the users really know this tree?
As soon as the user is not sure where an item might be found in the tree, they will have to resort to searching the tree, which (as we will discuss in a moment), is time consuming.
Option #2 Known to masters of the domain
In our Kingdom of Life Tree (Tree B, above), it’s probably reasonable to expect that most biologists would know where to go to start looking for any specific item in the tree. These users are experts in their domain (biology) and they have agreed upon the way to organize this information within their profession. Only, they really haven’t. There are actually disagreements about this hierarchy, and as a result even your expert users might not know exactly where to go to find specific items within this tree. So again, we have a domain with a supposedly “well known tree” that may actually not be well known.
Option #3 Known only to its creator
In our file system example (Tree C, above), the tree was created by a specific user for her own use. In this case, the user is likely to be familiar with the tree so long as he or she continues to interact with it — leave it alone for a few weeks or months, and that knowledge might fade. And if another user tries to find something in that space, he will likely find it very difficult.
I’ve used these examples to demonstrate a basic truth of trees: if the user knows what he is looking for, and where it is located in the tree, the tree a great widget. It can take hundreds or thousands of items and present them in a compact space that the user can very quickly navigate. Two or three clicks and the user has the item he is after… but, if the user does not know the tree well, how can we support him?
Adding search to trees
Even in relatively small trees, I like to add search controls. The tree for countries (Tree A, above) only has 195 leaf nodes in it, organized into six groups, but even in this relatively small tree, adding a search control will make it that much faster to find Slovenia. Let’s walk through a simple example of searching a tree.
We begin on the left. In this example the tree is fully collapsed (but it could start in any state).
In the middle panel the user has typed “sl” — this UI will start the search as soon as the user starts typing. If you have performance issues, you could also have search wait for the user to press return or click a Search button. Even with just these two letters, you can see that the tree has been substantially altered. Any nodes that do not contain matching children have been removed entirely. Only matching nodes are shown. For extra clarity, I’ve highlighted the match in red. In this example, matching takes place both in the beginning and in the middle of a string: you could choose to only match the beginning of the string, if that makes more sense for your data.
In the right panel, the user has typed four letters and you can see that the tree has been trimmed further, only showing Slovakia and Slovenia. The user can clear the search by clicking the “x” icon, or by clearing the text in the search box.
Let’s dive in a little deeper and talk about some possible edge cases for searching a tree. Here we’ll work with a file system tree, a place where search is very useful.
On the left, we start with our file system. In the middle panel, the user has begun to type “wiz” and we can see that, as before, there are some leaf nodes that match.
- The first two, wizard1.sketch and wizard2.sketch are inside of the Concepts folder. The folder is opened, the matches are shown.
- The third item, though, is nested within two folders: Pluto Project and Team notes. Although both Pluto Project and Team notes do not contain the string “wiz”, they are present because they are the parents of the node that does match: help wizard.txt.
- The next edge case is the folder, Testing Wizards. The folder matches the search, but none of the nodes inside match. Therefore, that folder is shown with no children.
- Finally, we have wizard-list.docx (which matches the user’s search), and the folder that contains it (Wizards) also matches. These are both shown. It’s when you start to study edge cases that you can begin to see why highlighting the matches is useful.
In the right panel, the user has typed wizq and there are no matches. We’ve got a “no matches found” error, along with a link to clear the search and restore the tree.
Search: Knowing the names of things
What if the user is be searching for a movie, but cannot recall the name of the movie.
Any time you are using search, you have to ask yourself: does the user know the names of the thing he’s trying to find?
This is an example where a simple search won’t work. If you believe that your users may not know what, exactly, to search for then you may need to supplement your tree elements with attributes that the user can search (e.g. who starred in the film, what year it was released, etc). One way you can support this is by adding filters to the tree.
In the panel on the left, we see a tree of movies, organized by genre. In the middle, the user has opened a Filter panel and has chosen all best picture films between 1970 and 1980. In the right panel, we see the 11 films that match this query. Note that the right panel follows some of the basic rules of filtering: showing the user that a filter is active, showing the number of matches, and making it easy to clear the filter.
One of the disadvantages of this approach is that the user cannot see how the attributes of the films match with the filter criteria. In this example, he can’t see the year the film was released, so it’s hard to understand how these items actually match the filter. In this example, it would be easy enough to add the year to the tree — e.g. The Godfather ( 1973). However, that approach will quickly fail as the user builds more complex filters (e.g. films directed by Stephen Spielberg or George Lucas between 1980 and 2000).
In truth, if you want to have attributes in your tree, you probably want to consider a tree table or some of the other tree alternatives, which we’ll discuss below.
Search: Can you spell it?
Another problem with search is that the user might know the name of something, but not how to spell it. In a list where the user is entering an ID number, spelling won’t be an issue, but this problem will crop up in almost any hierarchical list that contains names of people or places
.A great example might be a directory of employees: a user may not be sure how to spell someone’s name. Is it William, Will, Bill, or Billy? Or perhaps he has heard the name of the Venkatanarasimharajuvaripeta railway station in India, but isn’t sure of the spelling.
If user’s aren’t sure of the spelling, then there are a few strategies you can consider:
- Restrict the search to just the first few letters of the string — sometimes when users don’t know how to spell something, they may know the first few letters. Don’t match in the middle.
- Add the ability to filter other attributes, as shown in the film example above
- Offer additional attributes in a tree table
- Build a more flexible search that offers “looser matches” to support misspellings (e.g. match Sheryl, Cheryl, or even Sherril).
Icons in a tree
As soon as we start to think about adding attributes to a tree, we start thinking about icons. Icons are great for fitting information (or commands) into a compact space. Where they struggle is that users often don’t understand the meaning of an icon, and they can add considerable clutter. You’ll want to lean hard on a visual designer to help you to make smart choices. Let’s look at two examples where icons are used in tables and talk about what works and what doesn’t work.
What are some things that make the icons on the left tree fail?
- You don’t need an icon for both the folder and the expand/collapse control. Pick one way of showing “I’m a folder” and stick with it. The tree in the middle and on the right has dropped the icon for folder and are easier to read.
- The “movie” icons appearing before the name of each film in the tree on the left are interfering with the indentation of those items, making the hierarchy of the tree more difficult to scan. In the middle tree and the right tree, the icons have their own column distinct from the hierarchy.
- It’s hard to tell which icons are indicating status and which are clickable. I like to avoid clickable icons in trees when I can, just because the target area is relatively small and users don’t seem to realize they can be clicked on. But if I must have clickable icons, I try to make sure they’re visually distinct. In the tree on the right, any icon that’s clickable is link blue.
- There are a lot of icons in the tree on the left and in the tree in the middle. Even though the middle tree has things better aligned, it’s still a lot to take in and adds to the visual muddle. The tree on the right has simplified to one column, which makes everything easier to read. Prioritize your information.
All icons share the problem of the user not knowing what they mean, so do plan to offer tooltips for each icon. If you do find yourself adding more and more information to your tree, it might be time to move away from the tree entirely and consider some of the alternatives (below).
Icons for type
The most common use of icons in a tree is to show the type of the item that’s listed. This originates from the design of trees on the desktop: folders which contain files that can be documents, images, movies, etc. But sometimes trying to put an icon on to every item in a tree just results in an icon salad.
On the left we can see the Apple file system, which uses icons to show type: folders, files. There are special folders, such as the Home folder, that have unique icons, and special types of files that have their own icons. In the middle example we see many different icons for many different types of things, and the icons are starting to just become visual noise. On the right we’ve got a different icon for each item in the tree: icon salad achieved.
If you’re going to use an icon to show an item’s type, you should ensure that all your icons are using the same visual style. In the tree on the left, above, all are clearly drawn in the same style. In the tree in the middle we have some icons drawn in one dimensional style, and some (like NFSUDISK1) seem to be completely different. It’s very visually jarring.
In general, if you are making an icon that refers to one item and one item only in the tree, then you probably should not use it. The example above on the right falls into this trap. Consider whether or not removing the icons entirely will simplify your design and improve usability.
Large trees fall down
We’ve talked a bit about how to use trees, but we also need to talk about when to not use trees. Fundamentally a tree is used to organize hierarchical information so that the user can find it quickly and without error. The user finds items by exploring the tree: opening and closing nodes and scrolling (we’ve also seen that the user can find items with search and filter).
The more items there are in the tree, the harder exploration becomes. This means that a tree with 10,000 items in it is harder to use than one with 100 items in it. That’s true even if all the items are in one container, just because of the scrolling required. However, the more folders there are, the more difficult it becomes to explore all 10,000 items. The user has to open, scroll, close, scroll, open, scroll, close, scroll, etc. to find all those items. As the number of items in your tree grows, consider some capabilities that will help users:
- Try to give the tree as much vertical space as possible, to enable the user to see as many items at a time as possible.
- Add commands for expand all / collapse all, so that the user can quickly open the entire tree and browse it. This could also include “expand everything in this folder” and “collapse everything in this folder”.
If you do have a lot of items, you may want to consider the alternative Windows File Explorer model, below.
Similarly, the more nested folders there are in a tree, the harder exploration becomes. As more folders and levels are added, the nodes in the tree move to the right, increasing the chance of a horizontal scrollbar appearing and cutting off the text. As trees get both longer and deeper, it’s harder to see where you are in the hierarchy: the parents scroll out of view and much of the important context is lost. If you need to represent truly large amounts of information, consider some alternatives to the tree.
Preserve your user’s trees
One of the things you have to keep in mind with a tree is that using it is work. The user has to do a lot of clicking and scrolling to get to exactly the right item.
Let’s look at the example below, from Google Drive. The user has navigated through the tree and selected the folder “Offline”. He’s also scrolled so that he can see the folder “apps” because he’s planning to drag files from “Offline” to “apps”. Everything is perfectly positioned, and the user is ready to work. The last thing you want to do at this moment is to reset the tree (change the scroll position, close the folders, etc.). And yet Google Drive does this all the time.
In contrast, if you open up views in the Apple Finder, expand the trees and then turn off your computer and log in again, you will return to exactly the same view of the tree that you left. The work the user has done is preserved. This is critical to acceptance of trees.
If you’re going to use a tree, you need to preserve the user’s work on that tree.
Give your trees some space
Because trees put so much pressure on horizontal space (long names and indentation both will trigger horizontal scrolling), you should plan to make your tree pane’s width adjustable, so that the user can see more (or less) of the tree. Once the user has set the width, remember it.
Trees for navigation
I, personally, am not a fan of trees being used to navigate within an application and I’m not alone. More and more online retailers have moved away from the tree as a navigation control. Let me explain what I see as the problems.
- They are clicky — it can take a lot of clicks (and scrolls) to find the right page, especially if your site or application has a lot of screens.
- If you don’t have a lot of screens (less than 30), then you probably don’t even need tree expand/collapse controls. You could just show the “tree” fully expanded and let the user pick the item they want directly.
- It’s easy to lose your place. Scrolling, expanding, and collapsing move everything around. Effectively, large trees destroy positional memory (our sense of location), which is a vital skill for finding things.
- They can take up a space I might need for trees later. Consider the application below, which uses trees for navigation in the left pane and then another tree to show a list of objects in the middle pane. I’ve seen a lot of users deeply confused by this exact design approach: in this case, I would use the tree for the objects and find another way to present navigation.
In general, I prefer to use trees to manage data and information, not to navigate between pages.
What are some alternatives to using Trees?
Alternative #1 Tree tables
Typically, when we use a tree we show the tree on the left and the user can select an item in the tree. On the right, we often show the properties of the selected item. An alternative to this is to instead use a tree table, which incorporates the expand/collapse controls into a table.
Here’s an example of such a tree table, below.
Right away, you can see an advantage. Instead of viewing the attributes for items one at a time, the user is able to view all the item attributes at once. This means that the user can compare items more easily.
Because we’re using a table, we can allow the user to sort this table: either within each folder or even using a sort that flattens the tree, dropping the hierarchy entirely. With this change, users could sort and compare information across the entire hierarchy more readily.
I do find that tree tables work best where there are just two levels: the parent and children. Multiple, nested levels often becomes unusable very rapidly, as it’s harder to actually see the hierarchy within the table.
One warning about tree tables: if your items have very different properties, you’re going to have trouble.
In the case of the example above, all items (both the containers and the individual items) have an Assignee, and a Status, and a Start and Due Date. But what if the table also included, for example, the names of team members. Those might have completely different attributes: email, location, phone number. The more diverse your data set, the harder it will be to use a tree table successfully.
Alternative #2 Miller columns
The Miller column is a fantastic way to handle hierarchies that are very deep (many levels), and work well for hierarchies that are also long (lots of items within a level). Apple offers a Miller column view in the Finder.
One obvious problem with Miller columns is that they take up a lot of room. A less obvious drawback is that it’s impossible to look at more than one portion of a hierarchy at once. Nevertheless, the Miller column is a powerful tool to help a user dive into a deep, complex hierarchy. I would not hesitate, for example, to use Miller Columns to navigate the taxonomy of life (kingdom, phylum, class, etc.), which contains millions of entries.
Mobile applications make use of miller columns extensively — the only difference is that they only show one column at a time. Amazon uses this for their “hamburger menu” navigation (circa 2020).
I’d also urge you to look at Apple’s remarkable implementation of Miller columns with groupings in the Finder. This unusual UI allows the user to clump information in each container, making it easy to parse large amounts of information.
Alternative #3 Windows File Explorer
If your tree is complex (many items and/or a deep hierarchy), you may want to consider Microsoft’s approach for the File Explorer. Below, on the left, we see a typical tree of folders and items and the properties for the currently selected item. On the right we see a tree that ONLY contains folders. On the right is a view of all the items in that folder (which can include folders). (By the way, I am using the word folder loosely as a stand-in for whatever container your tree has: shipment, team, group, office, etc.
Below is this example from Microsoft. They offer many different views of the folder contents: a table, previews, etc.
This takes up more overall screen space, but greatly simplifies the tree such that it only includes folders.
Alternative #4 Menubars for navigation
I did mention that I don’t like to use Trees for navigation, particularly as the number of screens grows large and gets complex. I think there are a number of excellent alternatives, but I’ll focus on the menubar.
Consider the menubar from Quickbooks (circa 2016), a desktop application. This impressive navigation system includes about 300 of items, most of which are accessible at the top level. There are (sadly) pull-right menus, but most of the commands and screens are available at the top level.
Unlike a tree, the items in a menubar don’t change location. In a tree, if the user scrolls, items move off screen. In a menubar, they are always in the same place.
Unlike a tree, the items in a menubar can be quickly scanned by holding down the mouse button and moving across the bar to open each menu (I don’t recommend opening items on hover). Try performing the same action in a tree.
Menubars are searchable — both Apple and Google have provided examples of searching within menus.
Alternative #5 Tags
The truth is that many things don’t fit well within a hierarchy or a tree, because there aren’t clear categories for the items. The geography tree is a great example. Canada cannot be in both North America and Latin America — by definition it must appear in one place and only one place.
Really, if you stop to consider it, the tree is basically a weak tagging system where each item has exactly one tag that identifies its “location”. The problem is that there’s only one way to view the information in the tree, and that’s super limiting. Lots of types of information would benefit from using a tagging model instead of trees to organize and find
Lots of hierarchies contain nodes that could be in more than one location in the tree. In that case, maybe you should be using Tagging instead of a tree.
In the example above we have a typical tree on the left, showing films organized by genre. But on the right we see a tag based approach: here the user can filter on tags and see all the items that match those filters on the right. This makes it possible for an item to be “filed” in more than one container.
Closing
Fundamentally, you have to keep in mind that a tree is just one tool for helping users to find hierarchical information. A tree can be a quick, easy way to get just where you want, or it can be a nightmare of open, close, scroll, and scan. Just because your information is hierarchical doesn’t mean that a tree is the best way to represent it: consider all your options.
