Navigation

Posted on Thu 23 May 2013 in UI Design

Dear tree huggers,

I'm one of you. I like trees - preferably on the left of my application. They give me the impression that I exactly know where I am and where I can go next. Just recently I learnt how much I appreciate a tree as a navigation element when I worked with Confluence 5 for the first time and tried to replace the navigation tree on the left by the new space sidebar. It felt strange to me because I always looked for things that were not there. I tried to familiarise myself with the dynamic contents of the sidebar, but I gave up after a couple of days. The mental overload was too high.

Why was it so difficult to get rid of the tree?

As a developer I'm used to thinking about tree-structured data so trees are in my head all the time..
I encounter trees in many of my tools: my IDE, my file manager, my email client.

So I live in a forest. As this is my natural habitat, I'm pretty good with trees. I know how they work and how to find what I want as they are an accurate representation of my mental model in most cases. In other words: my brain was not ready for that sidebar thing.

But there are other people in the world. People who tend to think in different ways than a software developer. Scary, I know.
Some of these people use the software I build and at the same time do not like trees, in particular as navigational elements. Their mental model is different from mine, maybe workflow-centric rather than data-centric. They might not think of the data they're working with in the same way I do. It's not unlikely that some of them do not think about their data at all but simply execute a given (no-brainer) task.

In these use cases, a tree is of limited value at best and can even be harmful when the user is faced with too many options and too many paths that do not get him where he wants to go. It is better to restrict user choices and thereby make the user focus on the current task. A context-sensitive UI helps guide the user through the given workflow whereas a tree might encourage the user to meander through the application and explore things are are not to be explored.

No wonder a full chapter of Designing Interfaces is about navigation. No wonder the first paragraph in Microsoft's developer documentation on tree views is titled "Is this the right control?" No wonder even a small thing like a breadcrumb bar deserves a full-blown description on patternry. Because even with a limited set of navigational widgets, you have many options to do it right and many more to do it wrong. There's more to navigation than just putting an extra menu bar somewhere. Or worse: a tree.

Having written this already helps me to let go of the tree. Now it's time to look for alternatives. In my JavaFX world this means goodbye TreeView and hello ...

I'll save the answer for another blog post. Stay tuned.