One way to visualize hierarchical data is to use tree-maps, a method where rectangles are nested inside larger rectangles. Each piece of data is given a rectangle with an area determined by that data's magnitude in relation to the whole data set. Although it's been used to analyze supply chains, network flow and financial budgets, at Tableau, we believe we have a better method.

Our alternative to tree-maps offers several benefits: ease of comprehension, improved flexibility and ability to provide higher dimensionality. The method simply uses bar charts with size changing in only one dimension. Because the human eye has trouble comparing area – especially when both horizontal and vertical sizes change simultaneously – and can easily compare distance (linear size), a bar chart is perfectly tuned to the human perceptual system. Here is an example of stock data, a typical scenario of treemap proponents, using bars instead of a treemap:

Notice how easy it is, in this example, to see big changes in Stocks with low Capitalization. With treemaps, this is obfuscated because the area of these stocks is very small. Additionally, when analyzing this view in Tableau, the related items highlight for simple identification and comparison.

Furthermore, one of the conclusions in a research paper by Kong, Heer and Agrawala ( shows significant benefits to using this approach over Treemaps.

Use Bar Charts at Low Density, Treemaps at High Density
Bar charts resulted in significantly lower error when comparing leaf nodes at low densities. If a data set has only a few hundred elements, bar charts are more effective than treemaps.

You might also be interested in...


I don't understand - if the Bear Stearns Net Change is -1.72% and the Capital One Fin'l Net Change is -2.25%, why is Bear Sterns to the left of Capital One on the 'Net Change' chart?

Also, what would the software do if two companies had the exact same Net Change?

It was nice that the subject matter for your Treemap v.s. alternatives post happened to be in my area of interest.

One problem: I tried to access the research paper by Kong, Heer and Agrawala, via the Scribd link in your post. I got this error message The document 'Kong, Heer, Agrawala - 2010 - Perceptual Guidelines for Creating Rectangular Treemaps' has been deleted. Redirect URL was
How might I get access? Is the paper available somewhere else, or can it be restored on Scribd?
Thank you,
~~ Ellie K ~~

The link to Stanford's website worked. I was able to access the paper. Thank you, Alan!

Hi Marc,

This is a really nice viz, but it's not obvious to me how the sectors are sorted.
The fine print mentions sorted by Net Change, downloading the workbook it's actually the abs(net change) which I guess means put the most volatile at the top.

One additional feature I'd find useful is to use a parameter to choose how to sort them.
See here for my amendment, adding a parameter driven sort:


The idea is great. However you can't use a barchart to add pct changes. You'll need to calculate a mean or wieghted mean at we do at FRS.

Quite right, by using circles instead of bars you could have a scattered distribution, upon which you can overlay means and variances for each row as reference lines; may be more informative. Thoughts?

All the suggestions are nice and would probably result in a superior analysis. However, I'd like to point out that treemaps - the topic of this post - suffer from the same problems plus more! The order of the rectangles in treemaps is arbitrary - they are put in whatever order is needed to fill the map. Stacking the bars for percentages help highlight the extremes regardless of the value of the stock. In treemaps the most volatile items are often lost due to their small size. Ikejames101 - sounds like a great plan. Anyone have the data?

FYI: The order of rectangles in a treemap is not arbitrary in most implementations. The largest boxes are shown in the upper left and the smallest in the lower right.

I do like the bar attempt at the top but I still prefer the Treemap. I think the bar rendition makes me have to think more about the relationships, whilst the Treemap seems to invite easier comprehension. In the example above I found it a bit confusing at first when I saw 2 representations of the bars (% chg and Market Cap). The treemap handles this representation in a more single contained view.

By the way, has anyone tried the beta of Tableau 8? It has native support for tree maps in vizql. Just drag a dimension to the detail shelf and a measure to the size shelf an voila!

Subscribe to our blog