For large hierarchies - checkbox tree or 'guided tree construction'

Question

Context

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:

(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.

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?

Answer 1

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 ).

Answer 2

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.

Edit

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 master-details 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.