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