Sep 302013

I recently attended the Tableau Customer Conference.  It was a great conference and if you are into Tableau you should definitely go to next year’s event (see

In any case, during the myriad networking opportunities I was very pleased by the number of people who told me how much they had gotten out of a blog post I had written over two years ago.  I decided I should revisit that post and see what, if anything, I would write differently.

So, before you read this post, make sure you read that post.

Did you read it?  The comments, too?

I think it holds up quite well but there are some things I would change.

Let’s go through the major points one by one.

Size Matters

I think I’m ready to retract this recommendation for two reasons:

  • The world has gotten a lot smarter about embedding Tableau Public visualizations.  Either folks make sure to get the size right or they have a link to where people can view the full-sized visualization.  Indeed, it’s been awhile since I’ve seen anything that was really mangled.
  • I would hate to handcuff people from doing work that warrants a larger canvas.  For example, have you looked any of the things Kelly Martin is doing over at her VizCandy blog?  Go ahead, click here (but do come back when you’re finished.)

Some great stuff going on there — in fact my reaction when I first saw what she’s producing was “damn, I’m really going to need to ‘up my game'” — but I’ll blog about this at a later date.  In any case, while the constraints of a 650 pixel-wide canvas can in fact be very useful as it forces you to pare down the fluff, by all means use a wider canvas if your viz warrants it.

Never Use Red and Green as Contrasting Colors

I got some grief about this one, but my rationale is still spot on (more about this in a moment).  That said, I will modify the rule so that it reads as follows:

Never use red and green as contrasting colors without an affordance

And just what do I mean by an affordance?

Consider your typical traffic light.  How do people with red-green color blindness deal with traffic lights?  The answer is that they look at the positioning of the light: red is on top, yellow in the middle, and and green is on the bottom. If the light is configured sideways, red is left, yellow is in the middle, and green is to the right.  If there were only a single light that changed color there would be many more accidents — and not just because of confusion among the color-blind; the non color-blind fine the positioning very helpful as well.

So, if you like red and green or feel you must use it, the following two visualizations are acceptable as they both contain an affordance.  Specifically, The first contains arrows that point up or down and the second has bars that ascend or descend.




The following view is not acceptable as there is nothing besides the red and green to telegraph high values vs. low values.


As for having to worry about this at all, I attended Maureen Stone’s session on Best Practices for Using Color: How and Why and came away with two key findings.

1) This woman is brilliant; and,

2) Yes, you need to worry about this. So do yourself and your interactors / viewers a favor and do as I suggest.


There’s nothing I would remove from this section, but there is so much more that I should add.

I’m not going to do that right now (sorry).


… as I re-read my post there’s one idea I really want to underscore and that is to ask at least one other person to “fly” your dashboard before you publish it.  That person will both break the thing immediately and find the major stumbling points.  Really, it’s amazing how quickly a set of fresh eyes can find all the flaws.

Hover Help

I still completely endorse this practice but will provide one caveat about creating the ersatz calculated field called “Help”: adding this custom field can, in some cases, really slow down performance if you have a large database and are executing a big query against that database.

The very simple workaround is to create a very sparse additional data source (you can do it in Excel) and create the custom calculation in that additional data source.  Indeed, I’ve gotten in the habit of placing my help and navigation control scaffolding in a secondary (and very small) data source.

Navigation – Dealing with Multiple Tabs

My major takeaway in reviewing this is that I can’t wait for Tableau 8.2 to be available as it will have a new feature called Story Points that will be WAY better than the click forward / click back navigation buttons I recommend when publishing multi-tabbed workbooks.  I only saw a very brief demo of Story Points but what I saw was absolutely beautiful.

In the meantime I still recommend you hand-chisel these forward and back buttons and, should you run into performance problems, put any calculated fields you use in a secondary data source as described in the “Hover Help” section above.


I agree with everything I wrote but think my examples are dated as the state-of-the-art has improved enormously in the past two years.  In particular, Tableau’s ability to support floating elements has made it easy for the design-savvy among us to do some great things.

By the way, now would be a good time to revisit Kelly Martin’s VizCandy blog.  And when you’re done check out this post at Anya A’Hearn’s DataBlick web site.

They draw you in, don’t they?

As fun and inviting as all this stuff is I have found the best way to get people engaged is to somehow make the visualization about the person who is viewing it.  One of my favorite examples is the one below, a much-scaled down version of an interactive salary dashboard I built awhile back.  The reason this works is that people want to know (and know immediately) how they compare with their peers.  So, if you really want people to use your stuff your “stuff” should be able to answer questions like these:

  • How does my department compare with other departments?
  • How does our company compare with others?
  • How does my performance compare with my peers?

If you do this people will interact with your dashboards, I guarantee it.