"First, programmers don't often have a lot of taste. The fonts [in Excel and Powerpoint] are flaccid, the defaults are wan and uninspiring. There's no sophistication."<p>The programmers working on the latest version of Excel are about as likely to choose the fonts as they are to design the advertising campaign for it.
Whoa - he didn't put a time scale or units on his graph are we looking at one month, one year, or 50 years?<p>His graph definitely looks more attractive but I would add that it's very important to put scales and units on your graph. And don't trick people by playing with the units. Make sure that they are meaningful.<p>This is not one of those rules you want to break.
Off the top of my head, I can think of way more than "four reasons I can imagine [I] would want to show someone a graph." How about "look at this interesting pattern in the data," or "look how data set foo correlates with data set bar?" Neither of those fall under "help me figure it out", and they're both telling at least as much of a story as "everything is going great".<p>Also, while his graph is somewhat more pleasing to my eyes than the original, it still doesn't tell me what I really want to know about that data. I have two questions about that line: what happened with that first really big spike, and does he think that the two similarly-shaped regions that follow it represent the beginning of a cycle that we might see again. His graph is called "Rapid Traffic Growth", but I think there's a more interesting story in there.
One of his rules says "Good results should go up on the Y axis. This means that if you're charting weight loss, don't chart "how much I weigh" because good results would go down. Instead, chart "percentage of goal" or "how much I lost." "<p>A graph that needs to track weight loss should chart weight loss, but imo it isn't a good idea to say that good results should always go up on the y axis.<p>If I were interested in tracking weight, I'd rather have a graph track the actual "weight" instead of some other convoluted metric like "how much I lost". Weight going up may be a "bad" result for some users and it may be a "good" result for other users. So it wouldn't make sense for a weight-tracking for a graph to categorize it as good or bad<p><a href="http://blog.CascadeSoft.net/2009/07/05/product-ui-design-why-the-green-up-arrow-isn’t-always-good/" rel="nofollow">http://blog.CascadeSoft.net/2009/07/05/product-ui-design-why...</a> also addresses this topic.
These suggestions aren't very good suggestions for making charts in general. Instead they seem to be biased for an audience which doesn't want to parse and understand your data but simply be wowed by hand-waving and feel quantitative reassurance in that belief.<p>John Tukey (I believe) suggested that there were two broad classes of charts: exploratory and descriptive. Exploratory (Tufte style) seek to visually describe as many variances in your data and their relations both to one another and the marginal totals. With all this at hand, a careful analysis may reveal patterns and idiosyncrasies in your data. Descriptive comes later, once you know what you want to present, and seeks to maximize the visibility of whatever detail you're highlighting while providing appropriate context. It's the kind of statistic that "lies" via omission (or, rather, selective attention) but it also leaves the hints that let a careful reader suspect a larger picture.<p>Godin's suggestions don't really produce either of these though. Without contextualization his graphs are simply ethos arguments wrapped up in a white lab coat.<p>Not to rag on him: I'm sure he knows this, too. These aren't really suggestions for good graphs but instead for good presentation of technical matters to non-technical audiences: an endeavor which is probably doomed to live as a half-lie.