<< Back

Treemap vs Bar chart – The end of Treemap

Introduction to treemaps

Bar charts are surely well know but let’s spend a few words on treemaps now. A treemap is a chart type that displays hierarchical or part-to-whole relationships via rectangles. In case of hierarchical (tree-structured) data these rectangles are nested. The space in the view is divided into rectangles that are sized and ordered by a measure. Nested rectangles mean that hierarchy levels in the data are expressed by larger rectangles (above in the hierarchy) containing smaller ones (below in the hierarchy).

The rectangles in the treemap range in size from the top left corner of the chart to the bottom right corner, with the largest rectangle positioned in the top left corner and the smallest rectangle in the bottom right corner. In case of hierarchical data – when the rectangles are nested -, the same ordering of the lower level rectangles is repeated within each higher level rectangle in the treemap. So the size, and thus the position of a rectangle that contains other rectangles is determined by the sum of the areas of the contained rectangles.

Let’s see now an example of a treemap showing part-to-whole relationships and a nested treemap from hierarchical data.

(All the charts will be built on the ‘Superstore data’ provided with Tableau Desktop and will be using consistently the Sales measure for the sake of simpicity.)

A) Simple, ‘part-to-whole’ treemap (1 dimension only, now Region)  

Part-to-whole treemap

B) Nested treemap (more dimensions, now Region & Product Category)

Nested treemap

So much for now about the theory of treemaps, let’s see if they stand a chance compared to bar charts…


Treemaps vs bar charts – what are the differences?

Treemap vs bar chart comparison_

My green/red coloring stands for having an advantage/disadvantage. Although I did not color anything in terms of the ‘strength’ of the chart, bar charts can be further flavoured with a running total line on dual axis (moving towards a Pareto chart) that results in a slight edge over a treemap even in this case.

Concluding the advantages of the bar chart, the next logical question is: can we always replace a treemap with an equivalent bar chart? Let’s try…

A treemap is created from 1 or more dimensions, 1 or 2 measures.

Treemap show me

Let’s see the basic variant, 1 dimension and 1 measure: Product Sub-Category and Sales.


1-1 treemap with sales

Bar chart

1-1 bar with sales

The order of Product Sub-Categories is clearer in the bar chart and the differences between the individual values are also better displayed.

I quit the case of 1 dimension and 2 measures as the second measure is used only for coloring the treemap. Also, later on the variants with an additional measure on color button are not discussed as the number of dimensions will be more important for us.

Let’s move on to including 2 dimensions and 1 measure in the view. We may also use the higher level dimension on color to visually group the marks.

Treemap (hierarchy of dimensions)                                                                                     

2-1 treemap with sales

Bar chart (hierarchy of dimensions)

2-1 bar chart with sales

Individual region-product category combinations are still more accurately shown on the bar chart. What the treemap does well is organizing the cells (region-product category combinations) by regions in a descending order. Still, can you tell if East or West is bigger in total if you do not know the second biggest region should appear below the first one and the third one on the right?

There is another bar chart solution with 2 dimensions and 1 measure, namely a stacked bar.

2-1 stacked bar with sales

A similar view is produced by combining treemaps and bar chart to create a bar chart where each bar is a treemap itself.

Bar chart treemap

Notice that the length of the bars corresponds with the total value of Sales in the region, just like in the stacked bar chart.

Does the treemap outperform the stacked bars? No. Bar sizes still translate the differences in sales clearer. Another aspect you may mention is that dimension members are automatically ordered on treemaps, while it is not straightforward to solve this on a stacked bar chart but can be simply reached.

Just create a combined field of the dimensions (in our case Region & Customer Segment), then drag the new, combined field to Level of Detail, above the dimension (now Customer segment) of color and finally sort that combined field by SUM(Sales).

2-1 SORTED stacked bar with sales_

Sorted stacked bar method_

So far all cases of a treemap could be reproduced with a bar chart that proved to be more effective. When is a treemap superior to a bar chart?

What if we are dealing with a very large number of dimension members?

Treemap (large number of items)                                                                                     

Treemap many  dim members

Bar chart (large number of items)

Bar chart many  dim members

To be honest none of these look appropriate, although the tree map groups the items well using color and labels are visible in larger rectangles.  This many data points are rather visualized in a text table if looking up the individual values is important.

The last resort for the treemap is that due to the rectangular shapes it may be more user friendly on mobile. Yet if a reasonable number of marks are involved, there is no reason why a bar chart would not do the job.

All in all the treemap may be the new pie chart. It looks fancy and the software capabilites are luring us to go for it – it is so simple to create. Please consider the good old bar chart first.

3 thoughts on “Treemap vs Bar chart – The end of Treemap

  1. Hi Laszlo,

    interesting and well written article, but I have a slightly different opinion.
    I use treemaps in situations where I want the viewer to concentrate on only a small group of objects, which matter most. But in the same graphic I want to show that these objects really contribute most of the effect. For this the sales data is not a really good example because the magnitude of the difference between smallest and biggest object is not that big. A good example are tools that show files on a computer by size. The biggest files immediately get attention and all the small files “disappear” in the lower right corner. In the most cases I also get a direct visual feedback that tells me something about how many file space I can save if I drop the X biggest files. For this I would need to transform the bar chart into cumulative one.

    The second thing I like is that I can add multiple labels to boxes only showing up for the biggest (and most important) ones because of the space restriction. In a bar chart they would also show up for the uninteresting ones or mix up.

    That is why I think that there is really a use case for treemaps.

    Just my two cents.



    1. Hi Roberto,

      you are right, this is the use case for treemaps (having a very large number of items to display, paired with high concentration – a few major ones and the rest being small).
      Thank you for adding this.

      All the best,

Leave a Reply

Your email address will not be published. Required fields are marked *