Taxonomy Hierarchy Management UI Pattern

Question

Overview

I have a custom lightweight web CMS I am developing. It has a feature that allows business users to define hierarchical taxonomies, add/edit/delete nodes, change their sort order relative to sibling nodes, and change their parent node within a taxonomy.

Taxonomies could be n levels deep (the application doesn't force any limits) though in practice a great majority of them will be 1-3 levels deep.

Problem Statement

Previously in the admin UI a tree represented the node hierarchy with client-side drag-and-drop for rearranging nodes within the hierarchy. This was poorly received by users due to the mouse dexterity required to drag a node and place it next to or under another node. This created a negative experience which turned users off to dragging and dropping entirely. As a result using a different mechanism for managing the node hierarchy is required.

Requirements

The user must be able to:

• Add new nodes to the hierarchy (create the title and description)
• Edit exsiting nodes (update the title and description)
• Reorder nodes (change sort order relative to sibling nodes or change parent node)
• Delete nodes

Research

I have been researching alternatives and have found several good questions on ux.se however they are either different use cases or the answers supplied do not address my specific problem statement:

• What is the most user friendly way to allow users to insert data into a hierarchy?

  This is a very similar question however I don't need to just allow for insertion, I need to support editing, deleting, and re-ordering. The best answer in that thread suggests using a miller table that adds a new column for each level of the hierarchy.

  The problem with this approach is to address all CRUD requirements could make for a lot of buttons. Plus the possibility of horizontal scrolling exists in edge cases where hierarchy depth exceeds 3-4 levels.

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

  Another similar yet not quite the same use case. The best answer suggests a flattened list-builder pattern. The issue with this approach is that the user does not have a full view of the hierarchy, and making simple changes will require multiple post backs reloading the entire screen which could get old pretty quickly.

Solution A: Two Panel Selector

One approach I have considered is a two panel selector pattern:

^{download bmml source – Wireframes created with Balsamiq Mockups}

It's similar to the flattened list builder except it maintains visibility of the hierarchy and provides instant feedback after an action is taken without taking the user to a different page (reducing pogo-sticking).

The possible drawback would be for shallow hierarchies with many siblings at each level. This could create some scrolling or would require the right panel to be "sticky".

Solution B: Tree Table w/ Modal Window

Another option is to use a tree table pattern combined with a modal window:

^{download bmml source}

Higher fidelity version of Solution B tree table:

This is a little more structured and less cluttered (selecting and editing are more distinctly separated). I'm leaning toward this approach.

Which option do you think is better (and why), or what third option do you think would be better (and why)?

Answer 1

An option 1 I see is to use toolbar instead of a separate panel.

An option 2 I see is to use context actions, i.e. actions shown near the selected (focused) row (or, maybe, a several rows):

So, the "Add child" and "Edit" options will popup a dialog with details to add or change.

Answer 2

This is a good place to use the control-panel pattern, such as in Adobe Illustrator, when you click on a shape object, it will show you the operations you can perform with it in the control panel.

Control panel is the E area in this screenshot:

So here's what you can do:

There's nothing wrong with your last solution except that it's too long with the toolbar. And the solution with cleaner icons from one of the above answers doesn't have affordance, no one knows that they suppose to select an item in order to see the toolbar. Maybe you can combine them, which means rollover to see a shorter toolbar.

Answer 3

Charles,

I suggest the following approach:

The icons are below the listbox, keeping the design simple and hopefully the implementation simpler as well (no need to show/hide icons every time selection changes). Note that there is no Edit icon; most people are now familiar with double-clicking to edit. However, you can still add it or use the following icons:

On the gears menu, you can put

• Edit “Citrix”

• Delete “Citrix”

You can use the gears menu as a way to provide other options such as Add Child, and add any number of future options in a way that would not be possible icons-on-a-list-item (solution B) or would require more extensive changes to the implementation (solution A).

Answer 4

Tough problem. I don't like #2 because it strikes me as very unconventional to place editing commands in a table like that.

Option #1 seems a little less unconventional but I think it might be take some poking around to discover how to restructure things (edit -> change parent). Perhaps combine the edit panel into first side panel, so there's only one side panel showing all the operations.