I would recommend labels if it is by any means possible. There are some nasty issues with hierarchical trees in my opinion:
- Searching for items in a tree is problematic. The user would expect you to show only relevant results. But this leaves out important information, as to where in the hierarchy items belong.
- To address this, you might want to display a subset of the tree with the direct ancestors of a highlighted item. This leads to a confusing search result, that asks users to filter out irrelevant information by them self.
- If the tree becomes large, you might not want to load all items into the user interface at once. This is usually addressed using pagination. But for trees pagination is awful. Where do you break a page, and how do you indicate where the next page starts in relation to the hierarchy?
- To reduce loading time, you might instead initially collapse some parts of the tree, but this again leads to confusing behavior when searching for items that might be in the collapsed parts of the tree. Furthermore, browsing for items becomes a pain, where the user needs to do a lot of clicking.
In a recent project I took part in, we initially had a tree when displaying an organizational hierarchy, and it turned out bad. We didn’t even have that many layers and users (about 100 user). We realized that something had to be done, so we went for a flat list with labels (like in a breadcrumb). None of our users wanted the old tree back when seeing the new list.
Keeping items in a flat list, is clearer, more flexible, and scales better to large numbers of items.
I've included an example from our prototype:
The Chicago sales office could easily have more sub organisations on the next page. The relationship to their parent organisation would still be clear.
When searching, only relevant organisations would have to be shown:
It is still obvious as to where in the hierarchy the search-results belong.