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.

Jul 112013

I love Tableau and I articulate that love through consulting, training, evangelizing, and blogging.

But there are some things about the product that just drive me nuts.

Here’s a flaw that’s been in the software since at least version 2.0 that I know has tripped up EVERYONE that uses Tableau.

And just what is this problem?

This incredibly intelligent product with so much built-in smarts becomes positively brain-dead when you click File | Save as.  Specifically, when you attempt to save a workbook under a new name, Tableau saves the file into whatever fold from which you just opened a file, not the folder where the previous version of the file was saved.  Let me illustrate.

Let’s say I have two customers, Coke and Pepsi, and I’m currently working with a workbook called SodaWorkbook_Coke.twbx that is saved in the Coke folder.


A file saved in the Coke folder

Now let’s say I want to look at something that is in another workbook and that workbook is in a different folder, so I open that workbook from the other folder, in this case the Pepsi folder.

Open a file from a different folder, in this case the Pepsi folder

Open a file from a different folder, in this case the Pepsi folder

Now let’s go back to the first file and perform some low-tech version control; specifically, saving the file under the name SodaWorkbook_Coke_B.twbx.


Doh! The file gets saved into the wrong folder!

Unless I override Tableau, Tableau will save the Coke file to the Pepsi folder.


As you may have gathered, I’ve been using Tableau for a long time and have gotten used to this “ill-behaved-Windows-application” anomaly.  There have been occasions, however, that I’ve forgotten about this “gotcha” and I now have random files littered across myriad folders because when it comes to saving files I had expected Tableau to behave like EVERY OTHER WINDOWS APPLICATION ON THE PLANET !

(Oops, caps lock problem… my bad.)

This issue seems so fundamental.  Why the delay in fixing it?

Want to see this fixed?  Chime in at






 Posted by on July 11, 2013 1) General Discussions, Blog Tagged with: , ,  2 Responses »
Mar 052013

My problem with most infographics is that they sacrifice accuracy and clarity for whimsy and cuteness. While I understand the desire to “draw the reader” in, I believe it’s critical that the information and the story not be misleading.

So, imagine my delight when I thought I had found an infographic that was spot-on accurate and fun and engaging.

Last month a friend had posted a link to a Huffington Post article about the Ten Most Read Books in the World.  This article contained Jared Fanning’s clever  infographic.

Wow, I thought, this is fun, clever, and clear.

But then I saw that the zero value for the Y-axis was in the middle of the chart and realized that the graphic was very misleading.  If you don’t look carefully you would think that readership of The Holy Bible is a little more than twice that of The Diary of Anne Frank.  If, however, you hide the clever part of the graphic and have the y-axis start at zero, you see a much more accurate interpretation of the data.

So, how would I display the data?

If I did not feel pressure to be mirthful I would go with something like this (rendered using Tableau 8 in about five minutes):

If I felt compelled to add some eye candy I might try something like this:

Then I would spend around three hours trying to make the book icons easier to read.

By the way, I’m the first to admit that this approach is not nearly as much “fun” as the first infographic.

But this graphic is accurate and clear, and that has to come first.

Note: One of the problems with the data itself is that The Holy Bible so dwarfs most of the other books.  I did experiment with a Bubble chart (see below) but didn’t want to spent valuable time getting all the book icons to be “just so.”