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
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 ).
No comments:
Post a Comment