In my Web based application I have a hierarchy of musical genres. There are around 1.5k genres in the tree, and the depth of the tree is at most about four levels.

My application allows you to choose genres from the tree that are 'allowed'. I have used a checkbox tree to model this. The entire tree is rendered, and the nodes that the user wishes to 'allow' are checked. Here's a screenshot:

Checkbox genre tree screenshot

(I'd like to concentrate on the question of large checkbox trees. There is another argument to be had whether hierarchy is the correct way to navigate genre - there are two reasons I did it this way: (1) it's easier to find a genre as search isn't provided and (2) where genres are disallowed the application looks for the most specific parent genre that is allowed. I wanted this mental model retained in the UI).

Checkbox trees for large hierarchical structures: concerns

From now on, I'll talk about checkbox trees in the abstract.

My concerns with using checkbox trees for such a large structure are as follows:

  • Increased cognitive load due to so many nodes being presented
  • User has to search for a particular node they want to select
  • It's damn slow (in slow JS engines like IE)

Here, 'large hierarchy' is a tree with 1k nodes or more.

An alternative - guided tree building

An alternative I've come up with in my head is as follows:

Start with either a blank tree, or choose some good default root nodes.

When a node is selected, provide an affordance to add a node. When clicked, a list of suggested children is presented. This suggests a 'model' or 'template' tree is understood by the UI. In the case of the genre tree above, the same hierarchy could be used, it's just this is only ever used for suggestion of child nodes. Alternatively, the user could just type in the node they want.

All nodes can be removed from the tree.

All nodes that are in the tree are thus selected (in the case of the genre tree, 'allowed').

There would need to be a bulk addition mode, because otherwise adding a number of nodes would take 2*N where N=number of added nodes.

Another alternative - flattened list building

While the model used internally to decide on genre alternatives for an album uses a tree, this doesn't necessarily need to be represented in the UI. Instead, a list builder / dual list approach could be adopted.

Here's an example mockup of what I'm thinking

Requirements of either solution

  • Nodes with arbitrary, user decided, values may be added or removed
  • Any node must have some way of being selected (in the checkbox tree this is being checked, in the latter this is being simply in the tree)

Am I overthinking this? Should I just go with the checkbox tree?

  • 2
    Your difficulty in presenting the information may point to the fact that you cannot actually ignore the conflict between the user's mental model and your represented model. If the data simply doesn't fit in a tree, no clever presentation is going to make it fit... – Alex Feinman Jun 16 '11 at 14:51
  • Agree this can always be an issue. I'm trying to make sure the UI represents the internal model. Are you saying users may expect a flatter/folksonomy approach? – Dan Gravell Jun 17 '11 at 9:24
  • 1
    Definitely. You might be able to use a more map-like layout, with tags and tag synonyms. Also, a single piece of music may fit into many genres, since they are generally not orthogonal. – Alex Feinman Jun 17 '11 at 16:20
  • Thanks Alex. I'm beginning to come around to the flatter style. Please see @agib's answer below. – Dan Gravell Jun 20 '11 at 14:40

Tree traversal and node selection (at least in the "classic" implementation) is a tedious and fiddly task from an interaction design perspective.

Just a quick thought:

How about flattening the hierarchy smartphone style combined with something along a Listbuilder pattern (in an updated version, the one shown in the picture is rather archaic). The latter because it can be hard to keep track of your selections in the same list you navigate.

The left list would be your entire genre collection (does it really need to be that big, btw?). It would follow the One-window drilldown pattern. At each level you would be able to either add a genre (and its subgenres if any) or drill further down (apart from the lowermost levels, of course), something like Birdbrain here: http://pttrns.com/lists.

The right list would be the allowed genres represented in a flat list, with the genre hierarchy represented as breadcrumb-like "meta data", with a meta data format like e.g. Instacast, from the same resource as cited above ( http://pttrns.com/lists ).

  • I kinda like this. Here are the reasons I started with a tree view: (1) possible to navigate to find the appropriate genre (2) if an album has a genre that is not 'allowed', the software chooses the first parent that is allowed. I wanted the model of (2) to be represented in the UI. Maybe it's not important? Maybe the communication of genre parenting in breadcrumbs is enough? – Dan Gravell Jun 20 '11 at 14:39
  • In my suggestion one would still be able to navigate to the appropriate genre in the "left" (or wherever it is spatially) list. In terms of (2) I suppose the breadcrumb representation would be sufficient, but a quick lo-fi mockup and a user test would help you find out. – agib Jun 22 '11 at 8:49
  • I added a mockup of what I'm thinking it might look like. Feel free to agree/disagree and let me know if I'm not following. Right now, I'm not sure if there is a need for the breadcrumbs/hierarchy at all after all. Maybe an additional 'add by browsing' option, in addition to 'add by search', could use this. – Dan Gravell Jun 22 '11 at 11:16
  • 1
    Yes something like that. I'm not sure about the two "Add" buttons, tho. Perhaps the left should be labeled something else when the genre list is shown (a toggle)? And the right is just misleading I think, when it's next to the search field. You could just omit it, and make the search "live" as the user starts typing. In the right list, how do you plan on conveying the subgenre relationships? It might work just by grouping of related genres. I don't think the (red?) remove? icons next to the allowed genres should be always visible, perhaps just on hover-they clash with the message of "allowed". – agib Jun 23 '11 at 14:55
  • Also, I'm not sure I understand your topmost dropdown - what are the other options? You might also consider visually "embedding" the "+" (Add) icon in the genre list rows and make the entire row initiate the add action. For example a large "+" with and inset shadow or just a plain pictogram style... Hmm, by second thought, in order to be able to add all subgenres of a parent genre, you need a scheme for that. Perhaps, abandon my idea of the entire row as actionable, and then - on the parent genre rows - have two add icons (visually distinguished) - one for adding the genre itself, and one... – agib Jun 23 '11 at 15:07

You should just go with a checkbox tree, but find a fast one.

Unfortunately I can't point you to a fast one - but I'd hope someone else can. I've in the past solved a similar speed problem with IE. The underlying problem is the cost of displaying a widget that a large proportion of is actually clipped/hidden or off screen. It can be solved by javascript that re-uses DOM elements as the user scrolls. This made a complex widget with 'over 4000 elements' as fast as when it only had 100. I would hope someone else has solved this for checkbox trees before.


Checkbox tree is familiar - or at least both tree and checkboxes are, so it is only a small leap for users. A tree building interface on the other hand will need instructions with it. The tree-building solution is going to be more confusing as you are adding/removing both nodes and leaves. It will particularly confuse users what a non leaf node in the tree means. Does it mean everything encompassed by that node, or only what has been explicitly added underneath it. When adding a non-leaf node, you'll need to have some way to show what is under that node (I want to add 'hip-hop', is 'hip-hop' under 'contemporary'?). So at some times you'll want to be choosing from a tree to build a tree. It seems a lot easier if the tree is already built for you and you are just selecting in place within it.

If you can't find a faster checkbox tree, splitting the levels of the tree at some point using could give you enough performance gain. You'd have the two parts side by side. As an example, if you have a top-level tree with 50 nodes in it, you can use that to choose between 50 checkbox trees each with about 50 nodes in it and constructed on request. With that strategy you could afford to disable open/close for tree elements and have them all open - so that both left and right trees effectively become scrollable indented lists. This will reduce the amount of clicking to select, but will need a lot more TLC to look good and work smoothly than a fast checkbox tree would.

  • Thanks, but what are the reasons for going with a checkbox tree? Familiarity? Clumsiness of the alternative? – Dan Gravell Jun 17 '11 at 9:20
  • Thanks for the extra detail. I just added the clarification that either tree must support adding arbitrary user-entered nodes/leaves. For example, select 'Rock' and add '70s Rock'. It should possibly also allow some movement of a sub tree elsewhere, for instance via copy/paste or d'n'd. – Dan Gravell Jun 17 '11 at 11:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.