Your basic tree control has been a great success for showing hierarchical relations. It’s relatively easy to learn for novices and is now the de facto standard for hierarchies. It is very suitable for editing relations, especially with drag and drop. It is perhaps the only viable choice when the hierarchical depth varies arbitrarily by object (i.e., for any object on the tree, there can be children, grandchildren, great-grand-children, and so on to an indefinite number of “generations.”).
The primary alternative to tree is a window with master-detail panes. In this design, one pane contains parent objects and another contains child objects. Selecting a parent object populates the child pane with its children. You can have grand-child panes and great-grand-child panes as necessary, but master-details generally work best when there is a small fixed number of layers to the hierarchy. Users edit the parent-child relations by drag-and-drop and cut/copy & paste of child objects either within or between windows, similar to using a tree control.
Master-details are usually better than trees for the following cases:
You need to show multiple properties or attributes with each object. For example, for a given Project object, you want to list not only the Employee Number for each Team Member, but also their respective Names, Roles, Titles, Divisions, and photographs. With a master-detail, each pane can be laid out as a table or form allowing you to show a lot about each object. Tree controls often resort to inefficient and confusing Properties dialogs to accomplish this.
You need to subdivide children. For example, for a given Project object, you want to keep its Team Members separate from its Project Stages. With a master-detail, you can have two or more child panes for a single parent pane, with one pane listing the Team Members and one listing the Stages. It’s awkward to keep unrelated child objects separate with a tree control.
You have many-to-many relations, where each child may have multiple parents as well as each parent having multiple children. For example say each Project has multiple Employees (as Team Members) but each Employee may work on multiple Projects. You can have a window with Projects in the parent pane and Team Members in the child pane, or Employees in the parent pane and Project Assignments in the child pane, or you can have both windows. Tree controls may confuse users when there are many-to-many relations because users don’t expect the same child to be under more than one parent.