CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Reply To:
Tue, 20 Nov 2007 06:45:41 -0800
text/plain (303 lines)
Hello -

Here is the collection and summary with all responses to a question I
posted a week ago on alternative UI structures to the tree.

Thanks to everyone who responded! Sorry for the messy format of my
previous C+S of this posting - I made the mistake of sending it out from a
Web browser.

Happy (American) Thanksgiving -



-----Original Message-----
From: ACM SIGCHI WWW Human Factors (Open Discussion)
[mailto:[log in to unmask]] On Behalf Of Kay Corry Aubrey
Sent: Friday, November 09, 2007 18:52
To: [log in to unmask]
Subject: Alternate navigation structures for a tree

Hi - I am wondering if people can suggest alternative Uis to a tree
structure as a primary navigation method. The product has rich and deep
functionality. It uses an Explorer-style tree for product navigation, and
this presents a number of obstacles for users.

For one, they need to know the precise node to click to find their stuff,
they can't see what is under the node and some of the information lies 4-5
levels down. Because everything is presented on the same plane so there is
no indication on where to start. Using a tree in this context presents
many other types of problems, though the tree's organization is very well
thought out and seems appropriate to the domain.

We are going to offer multiple ways of navigating the product, search, by
task, etc. However, it would be cool to also translate the existing tree
into other navigational formats that are less overwhelming, offers more
guidance, and can show users the range of choices they have for their
We will likely segment the taxonomy into facets.

Can people point me to examples on the web that are successful in
presenting a complex taxonomy in a very simple UI that might spark ideas?
Please send your responses to me - I will collect and summarize.

Thanks -



You are welcome Kay, if you need anything just let me know (we have just
rolled out a major change to our principal web site regarding Faceted
Search. Ie. )  (KAY'S NOTE.... TAKE A LOOK AT

On Nov 20, 2007 12:12 AM, Kay Corry Aubrey <[log in to unmask]>

thanks Mario!

From: Mario E. Santoyo S. [mailto:[log in to unmask]]
Sent: Monday, November 19, 2007 3:11 PM
To: Kay Corry Aubrey
Subject: Re: Alternate navigation structures for a tree

Hi Kay,

Have you read upon Faceted Search Approaches?

it might help useful depending on your problem domain...


I have found working with trees in a mindmap format to be helpful. On my
(Windows XP) desktop I use Freemind and
recently started using comapping online. Being
able to see labels located in close proximity to one another (a
facet-area) works for me as a way to quickly scan elements of a collection
and get a feel for relationships.


Michael Everitt



I have found working with trees in a mindmap format to be helpful. On my
(Windows XP) desktop I use Freemind and
recently started using comapping online. Being
able to see labels located in close proximity to one another (a
facet-area) works for me as a way to quickly scan elements of a collection
and get a feel for relationships.


Michael Everitt


Hello Kay,

I'm dealing with the same problem, and I'd love to hear what responses you
get. A big question is of course how much information is contained in each
node, and how much of it you always want to display.

One (space-consuming) visualization that I think you could use to traverse
a tree of 4-5 levels is presented in a series of articles for the weblog
"Boxes and Arrows":
(more articles upcoming, I believe)

These articles talk about creating a multi-level portal-style (or
'dashboard') GUI based on the idea of containers within containers. A
container in this context is (in descending order of size): a Web site, a
Web site section, a page, a large box on a page (such as a content area or
a sidebar area), and a small box on a page (something the size of one
weblog entry or news article, for example). Containers share common
controls, such as 'print', 'search' or 'send by e-mail'.

It occurred to me that you could use these various containers to represent
the different levels of a hierarchical tree, offering a way of navigating
through the hierarchy that is both familiar and natural to users. Also,
typically, the deepest nodes in a tree contain the most information, which
this model provides for.

The problem is that this visualization can take up a lot of space, which
may force you to place the contents of a node into a separate browser
window, or otherwise force you to separate the navigation from the
content. As I said, it really depends on the amount of information
contained in each node.

Hope this helps,

Mathijs Panhuijsen


Thanks for this, I can provide a URL:

Check under 'Is this the right control?'

This section does conclude, however:

"You must use a tree view if you need to display a hierarchy of more =
than two levels (not including the root node)."

I personally don't agree with that statement. I feel that hierarchy is =
often fairly artificial to the user (even if they do know directory =
trees), and more a type of structure that software developers are =
comfortable with. It's also often unrelated to actual conceptual =


From: Lorenzo Pastrana [mailto:[log in to unmask]]=20

Sent: Saturday, November 10, 2007 12:18 PM

To: Kay Corry Aubrey

Subject: Re: Alternate navigation structures for a tree

Hi Kay,

There is a nice article on MS website (can't provide an url right now) = on
alternatives to treeviews, I think it's in the vista design guidelines.

Basicaly it states that you can browse a tree (witch is a list of lists = of
lists of...) using a list+content view at each level.

The main advantage, as I understood it, is the abscence of the unique
display/choice paradigm that you face in the treeview.

Using a simple list and content pane at each level (you can nest a =
couple of

levels if needed) allows you to use a variety of typologic, topologic, = and
graphical solutions to convey a particular meaning depending on each
case/level/node etc. Thus getting users to travese some initial levels
without even thinking they are.

Of course that 'magic' only operates if those levels are designed to be
'usage oriented' :

I think however, that you might get to question the tree itself in the = end
... Is the tree 'object-centric' or is it 'usage-centric' ? My =
conception of

a taxonomy (as you say) is that it works well in the definition-domain = and
that it's a good way to represent entities in memory on a computer or

programmer point of view. But on a usage point of view, you would = organize
access to the entities in a different way.

I'd dare an example : in a car's physical taxonomy the tree root would = be
the chassis, branching down to the tires, pedals and door handles; but =
on a usage point of view who would ever think of the chassis in the first
= place ?

My 2 cents.




I believe that there are several alternatives to a blasphemous tree view

1. Content Links

By providing content links, users can easily scan information. This also
increases efficiency as the clicking effort is reduced as compared to =
tree view navigation.=20

According to GOMS methodology <> , the
number of clicks needed to gain information should be at its minimal.=

2. Dashboard View

A page with the top level navigation links displayed upfront will =
definitely help users gain momentum before they step into it deeper. The =
disadvantage that tree view provides is the fact that it confuses users
with too many structures upfront. By providing a page with the key links
upfront, = users will not be overwhelmed as they see a clean layout that
describes = content.

3. Keep It Simple

Keep it simple. That's the key. The language used in most tree view
structures often make users cringe as they are already overwhelmed by =
its length and depth. Keeping the language simple will help users gain a =
better understanding of what's happening and also a clear welcoming
feeling = before they begin looking for information.=20

The greatest fear that users face is when they encounter a navigation
structure that contains sub-level navigation within the top level =
navigation at the same place. Users need a distinction between the two. So
separate = it for them.

4. Use Horizontal Space

Tree views often take up space vertically and not horizontally. This =
adds to the confusion as users move in one direction with too many nodes
being displayed. To allow breathing space, try using space horizontally.
To = ensure this happens, we need to replace a tree view structure with
content = links as mentioned above.=20

5. Abuse Fitts's Law=20

Fitts's Law <'_law>  "predicts the =
time required to rapidly move to a target area, as a function of the
distance = to the target and the size of the target." Knowing this, a tree
view = structure is a definite no-no! By providing content links, users
can not only = target it easily, but they can also view them upfront
rather than having to move through sub categories at the same place.=20

Here are my observations without examples from the web. I'm sure someone =
else can contribute to this as I would love to receive them as well. :-)



    Tip of the Day: Suspend your subscription if using auto replies
     CHI-WEB: POSTINGS: mailto:[log in to unmask]
              MODERATORS: mailto:[log in to unmask]