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.


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


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:

Solution B Hi Fidelity

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

  • Just a heads up, better to have the save button aligned right, and the cancel button to be at the left side of the save button.
    – Andy
    Commented Dec 27, 2012 at 20:57
  • I've been playing around with that actually -- currently I have the cancel button in the top right but I still have the save button aligned bottom left. Commented Dec 27, 2012 at 21:00
  • @Andy Check this out, it has some good info in it. Commented Dec 27, 2012 at 21:18
  • 1
    For Windows, nowadays they are actually stacked vertically for a saving popup window. For installation screens, i think it's a design flaw that they are too lazy to fix or too late to fix. For an alert box that shows only a message and requires no user input, it's a different story because it's not a form. So what I am saying is, the universal rule is "right" means "forward" while "left" means "back." That's how we read book and that's how we swipe mobile screen. That's just based on my observation and just my opinion.
    – Andy
    Commented Dec 27, 2012 at 21:38

4 Answers 4


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

enter image description here

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

  • 1
    And it seems like it's almost like your High Fidelity Solution B (which was posted just before I finished editing my answer :) Commented Dec 20, 2012 at 20:12
  • Yes I added that high fidelity version just because the lofi didn't seem like it accurately illustrated. However I like your cleaner tool bar quite a bit. Commented Dec 20, 2012 at 21:08
  • A few years past. I want to make a comment in this one. The reason I like 'Solution B tree table' more is it's in 1 row. The context actions hovering above entry breaks Gestalt principle Continuity. So maybe you caught yourself going back and fourth from highlighted Dell row to Actions panel. You have to do some extra work to 'glue' these 2 together.
    – myradon
    Commented Jan 19, 2015 at 20:14

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:

enter image description here

So here's what you can do: enter image description here

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.

  • This is a good option as well --- how would you envision this working as the item list collection grows to 30+? Would you have the item box scroll, have the toolbar stick to the top of the viewport...? Commented Dec 27, 2012 at 20:39
  • 1
    Yeah, as implied by the bounding box, the scrollbar will be rendered inside the box that directly contain the items. As you can see from the Adobe Illustrator screenshot, the scrollbars do not concern the control panel.
    – Andy
    Commented Dec 27, 2012 at 20:53


I suggest the following approach:

enter image description here

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:

enter image description here

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

  • This is a great option as well, plus I think your implementation point is very well taken Commented Jan 2, 2013 at 16:05

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.

  • I've gone back and forth on the mechanism for changing the parent. I've gone from including it in the UI to hiding it under the edit view and back again. Commented Dec 20, 2012 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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