I think I see a Pareto law of data visualisation: most of the data visualisation needs of a <i>field</i> can be satisfied by a small number (hypothesis: N = 3) of visualisations.<p>Lines for time series, histograms for frequencies, and panels for everything else is a good heuristic for <i>web analytics</i>. E.g. in quantitative finance a scatter plot is my go-to visualisation.
Food for thought, here is a visualization I've made in an app for tracking team mood: <a href="http://i.imgur.com/PUUYGKI.png" rel="nofollow">http://i.imgur.com/PUUYGKI.png</a><p>It's pretty easy to spot what days were good, bad, and in between. You can start to see patterns (Every other Tuesday seems to be better, why is that? Oh, that's when we had donuts!).<p>If you were to apply the Three Chart rule, this would be a line chart since it shows change over time. I find the calendar visualization much easier to interpret than a line chart in this case.
Those three may be fine (and indeed all you really need for representing most data) in some fields. In other fields though, they're entirely unsuitable.<p>A lot of people have mentioned scatter plots.<p>I'd quite like to know how you'd represent relationships between things using only a histogram or line chart.<p>I realise that it's covered somewhat by the "95% of all cases" statistic, but really, as with most things, if all you're doing is visualising relationships, then that statistic is likely way off.<p>The general point is a good one - use a visualisation that's appropriate for representing your data not one that's appropriate only for looking nice, but I think the message is lost somewhere in amongst the rhetoric.
Assuming that you're comfortable with 2d histograms (hexagonal binning is the standard) I completely agree. Otherwise <i>scatterplots</i> are pretty crucial.
I disagree with this post: there's another use case for visualizations -- consuming data as fast as possible to take action (eg firefighting). I work on tools for engineers, and I've found that a rich, non-standard visualization that people can learn to parse quickly after a tiny bit of initial acclimatization -- but showing them exactly what they need can help a lot.
I mostly agree with the article, but disagree with the idea that unusual visualizations are harder to understand. Tuning your chart to your data often makes it easier for your audience to understand. For example, if you want to communicate the detailed difference between how well two models predict the performance of teams in the NFL, an ROC chart showing both models is usually the clearest way to present[0]. If you want to model different scenarios, a segmentation chart may be better. If you just want average conversion rates, bar charts may be more helpful.<p>That said, I certainly agree with using the same chart for things like weekly updates, etc. Creativity for creativity's sake is pointless-the point of using different types of charts is to communicate a complex message as simply as possible.<p>[0]: <a href="http://blog.optimalbi.com/wp-content/uploads/2012/12/ROC-chart1.png" rel="nofollow">http://blog.optimalbi.com/wp-content/uploads/2012/12/ROC-cha...</a>
Interesting thesis, I would like to see a cage match between Noah and Edward Tufte :-) I tend to favor Tufte's thesis that humans can extract more knowledge per millimeter of paper space out of a chart than they can out of text. The trick of course is constructing that visualization. Most folks are facile with words, while fewer can work as effectively with shapes.<p>I like the notion that if you cannot see at least four things in a chart then the chart isn't doing its job. It makes me ask the question, "What is the context in which this chart is expressing information? Can I show that?"
I'm a fan of histograms above nearly all else. When I need to show change over time, I actually prefer heatmaps:<p><a href="http://deliveryimages.acm.org/10.1145/1810000/1809426/gregg3.png" rel="nofollow">http://deliveryimages.acm.org/10.1145/1810000/1809426/gregg3...</a>
<a href="http://queue.acm.org/detail.cfm?id=1809426" rel="nofollow">http://queue.acm.org/detail.cfm?id=1809426</a><p>It's like a scatterplot, but a bit better at showing collapsed data (i.e., there's a lot of data at that point on the graph -- is in more or less than that other jumble of Xs?).
And completely missing, the old reliable pie chart. Used when showing attributes (percentage, counts, etc) of a whole.<p>And then there's the scatterplot. Very useful in regression models for best fit.<p>Charts and plots are tools. To limit yourself to just three is using a screwdriver for a hammer, or C# for any programming task.<p>Understand the available tools and use the right one for the job at hand.
Slightly more advanced guide that I like -<p><a href="http://giveupinternet.com/2009/01/16/chart-of-the-charts-chart-suggestions-a-thought-starter-pic/" rel="nofollow">http://giveupinternet.com/2009/01/16/chart-of-the-charts-cha...</a><p>They hit the most important thing about chart making right on the head: What are you trying to communicate?
he forgot pie chart. I found that no matter how rational one can be about visualization, single pie chart can make world of a difference to a client.<p>edit: thanks for downvotes, I really appreciate how people can't recognize sarcasm. I'm very big on Tufte but it's easier to just give client damn pie chart than re-educate him on all aspects of data visualization.