Trees

Trees.png

The previous chapter was all about single categories. But categories can be nested as well—categories under categories. And this nesting can go deep. Just look at your PC’s file manager for examples of deeply nested categories.

These nested categories are called trees. We can also refer to them as hierarchies, but hierarchies imply an inheritance property. In the example below, a Square inherits the qualities of the broader terms. A Square is-a Quadrilateral, is-a Polygon and is-a Shape.

In the example below, however, Privates do not inherit the qualities of the higher chain of command. A Private is not a Sergeant, for example.

This arrangement is called a tree. Trees offer a more lenient approach to nested categories.

Shown below is an example of a tree used in intranets.

Here is a question: Why do we have trees? Why can’t we live with multiple independent categories?

You'd use a list if you had only a few items to arrange. If you had more than a few, say 15-20 items on the list, then you’d categorise them into logical groups. If you had around 200-500 items on the list, you’d categorise them but may start finding a need to nest them, thereby building a tree. Maintaining multiple categories at this point makes the arrangement unwieldy. Look at your computer's folder structure—a classic example of a tree structure.

The primary purpose of trees is to organise large amounts of information so that we can understand and use it more efficiently. This is the same reason we have corporate structures (trees)—to command and manage the company and drive it to success.

A folder structure on your computer is still manageable as you create and nest the folders. But what happens when you want to share your folder structure with others? Your folder structure may not go down well with others unless and only if the principle behind the arrangement is common knowledge. The only way to know for sure is to test it out.

Did you notice how many times we’ve resorted to card sorting?

Shape of a tree

A common question about trees concerns their shape: Should they be narrow and deep or broad and shallow?

trees.png

The shape of a tree affects the predictability of finding information on it.

A broad-and-shallow tree shows more of it at first, so it is more predictable. However, what happens if the categories are similar or ambiguous in meaning? Users will have a hard time figuring out which categories to go with.

Or, a narrow-and-deep tree offers users fewer entry points, making it more predictable. This is not quite right here, either. What if the deeper levels are used more frequently? Users will need to make many decisions before getting to the right level.

So, back to the original question: narrow-and-deep or broad-and- shallow? The answer: it depends!

But here’s a tip: start with the broad-and-shallow shape first. Just be careful with overlapping or confusing categories. Broad-and-shallow improves the visual scanning of information, which people often do when browsing.

Problem with trees

Let’s take an example to understand the problem with trees. Let’s say you’ve created a tree for organising trip reports.

Staff go on trips and then write a report on what they did, what they learned, whom they met, and so on. This is called a trip report. The trip report becomes the diary for the trip and an important source of knowledge that can benefit others.

The purpose of creating the tree structure is to help:

How would you make it if you were in charge of creating the tree structure?

If you want to make it easy for staff to submit the report, you might organise the folder by year with the organising principle: by the year the trip was made.

So far, it is a good organising principle. But what happens when a staff comes along looking for a report on a trip made to Australia?

Well, she better know the year the trip was made! Otherwise, she’ll be spending time (and company money) opening every category and looking for the report on the Australia trip.

You say, Organise by ‘country’ and by ‘year’ then. That should do it.

Let’s see.

This might serve both staff submitting the report and staff seeking the report. However, there is still one problem. You knew this was coming!

Trips are rarely made to chalk up visits to different countries. They are made to serve work-related goals. They may be trips made for academic conferences, research collaboration or joint exercises. If only a few such trips are made in a year, then we’re still okay with the tree structure by country.

But if many such trips are made, then you may have the possibility of staff coming along looking for ‘joint exercises in 2022’. If you have many such queries, then you’re in trouble. Staff will have to do the unproductive work of opening and checking every document under 2008 to find joint-exercises reports.

You only wish you could have information magically reorganise itself into different tree structures on demand—one by year, another by country and another by purpose. Only then could you satisfy all types of queries (at least a large majority of them).

You’re in luck. There is a way to create this on-demand organisation of information. It is called organising by facets.