The UX of Trees – Design Pattern

By | October 23, 2007

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.

24 thoughts on “The UX of Trees – Design Pattern

  1. Zach Leatherman

    Just wanted to leave a comment to say that I think this is a really good post! UX is definitely one of your strengths.

    In hindsight, this looks like a spam post, but whatever. Good post.

    Reply
  2. mdmadph

    Well, the Ext framework is very expandable — why don’t you try creating a custom tree component (instead of just complaining about it)? 😛 I’m working on extending hovering into my application’s Ext tree right now — the Ext framework makes it very easy.

    Reply
  3. Glen Lipka Post author

    Im not complaining about it. I think it’s the best control out there. However, I still want a few details more that I KNOW can be done wtih its extensibility. But let me ask you a question. How does one configure EXT if one does not know how to program?

    What this post was about it listing out a design pattern for a tree control. A UX design pattern. Programming is not my skill, UX is. Each of us has a job.

    Please don’t say, “Why don’t you just learn to program?” I hate when engineers say that.

    Reply
  4. mdmadph

    Extensive programming ability is not needed — I have to disagree with you there and with your earlier post about it (http://commadot.com/?p=639), too. I wouldn’t call myself an “engineer” by any stretch of the word — your previous post about jQuery (http://commadot.com/?p=646) leads me to believe that your programming skill is probably up there with mine. 😉

    Frameworks like the Ext framework take the mystery out of JavaScript programming — it almost makes me jealous that these things weren’t widely available years ago when I started with web design! These whippersnappers today just have it too easy. All you have to do is read the API and plug stuff in — Jack’s made it easy as can be. (The guy’s a genius.)

    Reply
  5. Pingback: Ajax Girl » Blog Archive » Designing the perfect Tree

  6. Pingback: commadot.com » Blog Archive » Dabble Dabble, program and trouble

  7. Glen Lipka Post author

    Ok, I am going to put my programming where my mouth is. I just posted again. I will do an apples to apples comparison of using a simple widget in jQuery and EXT. I chose Tabs, because I use them all the time. I will see if I am full of hot air, which is always a strong possibility.

    Reply
  8. Glen Lipka Post author

    We had used nlstree in the previous version of our app. I didn’t like the flexibility around icon management. I couldn’t use any kind of sprite at all.

    But regarding checkboxes. I didn’t think of that. It’s a little bit of a special usecase, but you are right. A good tree should have that option. EXT could probably be modified to do that, but I don’t know how.

    Reply
  9. Pingback: Javascript News » Blog Archive » Designing the perfect Tree

  10. Damir Secki

    I am looking for a tree for 3 days now. I have seen the ext tree and I actually like it very much. I am so disappointed something like that is missing in jQuery framework. But ext tree is hard to implement… so will probably make my own in jQuery in next weeks

    Reply
  11. Brian Moeskau

    Hey Glen,

    Checkbox selection is not built in, although an Ext user extended the tree to support it (http://extjs.com/forum/showthread.php?t=5750).

    Another nice feature you may not have noticed — try expanding a big tree so that you can scroll vertically, then drag a node toward the top or bottom — the tree’s container will scroll as you hover near the edge while dragging. Not a lot of other web trees can do that 🙂

    Reply
  12. Jack Slocum

    “But ext tree is hard to implement”

    Have you actually looked at the sample code? You have a full tree with drag and drop support, node sorting and dynamic loading in under 10 lines of code.

    “Checkboxes on the tree is not supported”

    As of 1.1, to add checkboxes to the tree, just add an attribute “checked” to the node with a value of true or false. The selection capabilities (e.g. cascading, bubbling) are not that advanced, but adding checkboxes to the UI is built in.

    Glen,

    As you know some of the things you mentioned (hovering and full width selection) have already been added in the SVN code. Keep up the good posts, and we are always around to help.

    Regards!

    Reply
  13. Marcus

    I know for a fact that the JQuery UI guys are working on a tree component, so if you hang on a bit you might find your wish granted. Might be worth getting in touch with them to bring this blog post to their attention. In fact, I’ll do it myself, but it’s probably a good idea if others did too…

    Reply
  14. Jörn Zaefferer

    Good post Glen! Good to read that Jack and Brian read this too, I’m using the Ext tree on one project.

    The jQuery UI tree should be included in the 1.2 release. Richard, who is working on it, gave me a hint about this post. If you’d like to contribute, give us a visit on the UI list.

    Reply
  15. wellwisher

    “The scrollbar is in the right place. Trees get big. A scrollbar has to appear when needed, quickly and quietly.”

    Please, noooooooo!

    The browser already provides a scroll bar. Additional scroll bars inside the window just make the page harder to navigate.

    Reply
    1. Glen Lipka Post author

      @Wellwisher: I completely disagree. A webpage is not the same thing as an application. A tree control is an excellent UI tool. Think about how outlook would look if there was just one single scrollbar. From experience, I know that a local scrollbar provides much better context for certain types of applications. Don’t throw away a great UI tool because you are religious about what a “web page” looks like.

      There are apps that try this and end up failing to be intuitive and lovable. Don’t focus on the rules. Focus on the experience.

      Reply
  16. Ivan Bozhanov

    Wonderful article. I read it a few years back (after releasing the first jstree version you sent it to me – thanks). I thought I’d just drop a note – jstree supports almost all those features natively (you will just have to prevent the closing of the root node, but jstree offers quite a few ways to do that).
    Once again – thank you for the wonderful tips and for helping me better jstree.

    Reply

Leave a Reply