The UX of Trees – Design Pattern

I actually am having trouble finding a decent Design Pattern for a Tree.  A tree is a critical user interface element and is being used more and more on applications.  Since, I can’t find one, I am going to quickly summarize the pattern I proscribe.

Let’s start with the EXT JS Tree. This tree is pretty full featured, but it’s not perfect.  Let’s review what it does well.

  1. All leaf nodes have icons.  It is important for a tree node to have an anchor.  The icon helps set alignment visually and also to give a quick hint to the user as to the type of leaf node.  Icons are important, don’t skimp on them.
  2. The tree levels are visually clear.  Specifically, there are little lines that show which level a node is on.  This is good, to help users understand the context of item.
  3. Opening and closing works smoothly.  They animate nicely.  The folders change from open to closed.  Little details like these matter alot.
  4. The scrollbar is in the right place.  Trees get big.  A scrollbar has to appear when needed, quickly and quietly.
  5. Some nodes are loaded via Ajax, with a logical “please wait” spinner.  MSDN was one of the early users of Ajax for their tree.  They didn’t get the contents of every node because it was just too much stuff.  So they used Ajax (before it was called that) to get the nodes on demand.  The EXT example also includes a spinner icon to help indicate to the user that the information is coming and to please wait.  That makes the difference between an elegant experience and a mistaken notion that the tree is broken.
  6. Keyboard shortcuts work.  This is a nice addition.  Although it is missing a few details in the implementation.  However, keyboard functionality helps UX significantly.  The keyboard is often forgotten in most applications.
  7. Mouse wheel works on scroll.  The mouse-wheel is the best invention since the mouse.  It’s critical to support its use.  Alot of flash trees don’t do this and it stinks.  In fact, my Aptana editor, which I am testing, doesn’t scroll in the main window.  Bothers me to death!
  8. Reorder works nicely.  Nice transitions and animations.  Everything about it is elegant. Not all trees are re-orderable.  However, if you have one that is, then this is a good example of it working well.
  9. Right-clicking works.  Not on that example, but it works in other examples.  Can’t seem to find one on EXT’s site though.
  10. Line-height is good. Although I might increase it by 1px, it’s not bad.  I hate it when a tree is too compact and hard to read.

Ok, that’s the good stuff.  However, I have additional suggestions for a “perfect” tree.  I haven’t seen one better than this example, but I still want to have the Holy Grail of trees.  Here is what is missing:

  1. Hover.  This is a problem with Vista as well.  If it’s clickable, then it should afford clicking.  The best way to do this is with a color change in the background.  EXT and Vista do this very well in Menus, but they forget about it in the Tree.  Trees need clear hover states.  This is my number one pattern in general for trees and it is missing in tons of JS trees out there.
  2. Bigger target.  The hover in the above step needs to be wide.  As wide as the whole tree.  Plus it needs to have a little padding.  Give the user a decent target to hit.  Don’t make them hit a tiny spot.  Give them breathing room. David Foltz says, “Don’t make the user play target practice”.  He is right.
  3. Keyboard shortcuts are good when the tree is focused, but what about when it’s blurred.  Keyboard shortcuts don’t work when tree is blurred.  In Vista the “on state” changes to be lower contrast on blur, so that it’s easier to tell that moving the mouse will have no effect.  In the EXT example, it doesn’t change.  This causes issues.  I actually asked the engineers to turn keyboard shortcuts off, and it seems that the keyboard option is not easily turn-off-able.

    The pattern I actually like with keyboard shortcuts better than this example is to move the “selector” or “hover” with the keyboard, and NOT the onstate. Moving the onstate changes the right side.  This is OK in an operating system, but not OK in a web application, where latency is much greater.  Interestingly, Vista is different than XP on this score.  Vista moves the hover state, although it looks like the onstate.  And XP actually moves the onstate.  Ugh, this is all a mess.

    Ok, the bottom line is:  Keyboard shortcuts for web trees should move the hover state and require an enter or spacebar.  This is the same pattern as keyboard shortcuts in raw HTML.

  4. Bigger On state.  It should be clearer that you are ON a selection.  It should be a background color going as wide as the whole tree.
  5. Should not collapse the entire tree.  The root node on a tree with only one root node should not collapse.  Even though I see this in lots of trees including Microsoft, I think its terrible.  Why would the user want to collapse the tree down to one node?  It makes no sense to me.

I think I should probably flesh this out with some pictures, but at least it’s a start.  Overall, the EXT tree is the best I have seen, but I can’t help myself.  I want even more.  I want the perfect tree.

%d bloggers like this: