Dialog Box

The case against tree view

I know, I know—right now you’re saying, “Anyone who uses Windows knows about the tree view, because it’s used in Windows Explorer.” But most people don’t use it because it’s not the default view in Windows Explorer. The default view is a list of files and/or folders with a panel on the left that lets you perform certain actions on those files, like burn them to CD. And most people don’t change the defaults because they either don’t know they can, don’t know how, or don’t know why it would matter.

The bigger problem, however, is that the only people who really understand deep, hierarchical structures like those represented by tree views are IT people. People like us. People who use Windows Explorer all the time and understand that a Web site is often comprised of a set of nested folders, each targeted individually within the code so everything on the site displays correctly. People who understand how the file system is organized. Regardless, developers often try to move this paradigm online, believing users will understand it. In most cases, however, they won’t.

Even Microsoft concurs with this view. In its own MSDN Library (msdn.microsoft.com/library/) it says, “Advanced users are more proficient at using trees. If your application is aimed at novice users, avoid using tree views.” Many people outside of our world just dump everything into the My Documents folder and struggle to find files later on. And this, remarkably, works pretty well, because Windows defaults to the My Documents folder in File Open and Save As dialog boxes when it hasn’t been told to point elsewhere.

In addition to the difficulty of understanding the design of tree views, these painful little widgets also tend to include a ridiculous amount of functionality. When you click on the small plus-minus icon, the nested folders either display or are hidden, respectively. When you click on a folder name, the contents of the folder are revealed in a separate panel. But the plus-minus icon doesn’t do the same thing. All that does is expand or collapse the view of nested folders. It doesn’t show you files. So you can expand a folder and not see its contained files, or you can click on a folder label to see its contained files without expanding the view to see its nested folders. What you can’t do, however, in some tree view implementations, is click once to expand the view and see contained files at the same time.

Figure 2: Each part of a tree does something different, and many implementations of tree view interfaces behave differently than the others. This is an example of a typical implementation.

So, in addition to the rather bizarre rules you must follow to work with a tree view, you also have to keep track of all the different versions of tree views you come across, because many of them operate differently from the others.

And if that’s not enough—and maybe I’m nitpicking here—the plus-minus icon is usually very small, making it fairly difficult to roll over with a mouse so it can be clicked. It doesn’t exactly scream, “Hey! I’m a button!”

All in all, it’s a confusing piece of wizardry that only a geek could love. (Though I’m a geek, and I don’t love it one bit.) The myriad ways you can interact with a tree view control are all made possible by a system that does way more than it should. Developers who build these controls see all the possible ways a user can interact with the tree view, and insist on making each one an option. More options are not what’s needed here. What’s needed is a simpler control that provides the same functionality in a way that’s easier to understand.

To get a new perspective, consider this:

Tree-view controls are used as menus. Nothing more. Nothing less. People use them to make selections until they find the files or data objects they’re looking for. A tree view is a selection control.

With this in mind, we could just redesign tree views as menus with nested submenus, right? Well, sure, if we wanted to cause different problems instead of cure them. Deep, nested menus are equally, if not more, complicated than tree views, because hardly anyone is precise enough with a mouse to keep it in line well enough to move through three or four submenus without error.

So how do we get rid of tree views? And in addressing the need for the deep, nested menu options, how do we Know the Best Ways to Implement It? The first thing to realize is that we can ditch the root level of the tree entirely. It’s not necessary at all.

Figure 3: Here’s the tree view interface without the root node, which doesn’t help users in any way.

In the tree view, all it tells us is there’s some sort of root container that contains everything else. This is pointless when you look at it as a way to choose simple options. If we get rid of the root level, we are left with a list of options. We can display this in a simple list box.

Figure 4: This list box replaces the first layer in the tree view.

The second thing to understand is that the final solution still must offer a way to go on endlessly. You must be able to provide an infinite number of nested options. So we need a solution that just shows an initial set of options, and upon clicking one of them, shows us more options, and on and on until we’ve located the object we need.

To do this, we can line up several list-boxes in a horizontal row.

Figure 5: This cascading list-view, with a more obvious menu-style design interface, replaces the tree view.

In case you don’t recognize it, this new control is a cascading list. Apple uses this paradigm in Mac OS X operating systems, in the Finder application used to navigate the file system on a Mac. It’s simply a set of list-box components lined up side by side and bound together with code to display the progression of levels within a hierarchy in a much friendlier way than a tree can offer.

Instead of seeing the branches and leaf nodes of a tree, you see options. Instead of asking users to learn about the deep, hierarchical nature of the file system, we show options. Clicking an option in one column displays another set of options in the next column. Simple as that. There’s exactly one way to make a selection using a cascading list. You just click on a label. When you run out of columns, the set of list-boxes scrolls (animates) to the left to hide the first column and simultaneously reveal a fourth.

Amazingly, this style of component has not yet made its way to the Web except in a few rare cases. So here’s your call to action: kill the trees. Use cascading lists.

Where to go from here

For more information about web design and design philosophies, check out the following resources:

• More is better: Address multiple learning styles, by Luanne Seymour
• How we really use the Web, by Steve Klug
• Right on target: Designing for your audience, by Luanne Seymour

Page 2 of 2

Previous Page