Love him or hate him, register here for upcoming east and west coast Edward Tufte seminars.
To paraphrase my friend Scott Schwertly from his book How to Be a Presentation God…
If you’re comfortable walking into a
client meeting with a clip-on tie,
then by all means go ahead and use clip art.
While the umbrella of “clip art” can include tasteful and professional images or graphics, in general it defines cheesy, stereotypical and juvenile artwork. Of course, no one wants to be perceived by an audience or client as cheesy, but with clip art there’s a greater danger lurking than simply being tagged as a goofball:
Clip art can undermine your entire credibility and legitimacy of message, because it screams: “Don’t take what I have to say seriously.”
Example? A recent (non-classified) US Army presentation entitled, “Strategic Choices — Adapt to Win.” This one deck may actually break every single rule of good presentation design (bad fonts, colors, low resolution imagery, lack of balance, death by bullet points, little white space, nonsensical charts, and the list goes on and on…) Truly, I think someone could write a PhD dissertation on ineffective communication in this document, but for me the most disturbing part of it was the very serious subject matter at the heart of this that was being treated with cutesy cartoons and tons of clip art.
The above is far from the worst slide, but I think it’s emblematic of the whole deck, with its cartoons, lightning bolts (?) and heavily beveled arrows. Does the graphic treatment match the importance and gravity of supporting and supplying our military? I’m not saying the design should be austere or solemn—just not comical.
And speaking of comical, here are a few more slides in all their comic sans glory. Download the whole deck here.
I have a confession: I’m not really a very good data designer. Okay, I’m pretty good at many parts of information design, but when it comes to visualizing hundreds or even thousands of data points and creating a beautiful and effective visualization, it’s fairly likely you’ll find me with my head down on my desk crying like a 4 year old.
The incredible data visualizations that you’ll find at The New York Times or Information is Beautiful or Visualizing.org make me insanely jealous. And so, I couldn’t wait to get my copy of Nathan Yau’s just-published guide to this whole mysterious world.
Nathan is a contributor to one of the pre-eminent sites on this topic, Flowing Data. I’ve been a fan and reader of both for a while.
While a number of other books have addressed data visualization, the ones I have read have mostly been concerned with the end products. Most are more coffee table book than how-to. Visualize This, on the other hand, may be the first true handbook for how to technically create so many of these interesting charts and graphs.
The reader is taken step by step through the creation of numerous styles and categories of visualization. Sprinkled throughout are solid tips on design, statistics and other resources for those interested in this field. The book is written with a good sense of humor and practicality, and it rarely feels academic.
But, this isn’t to say that the material is easy to digest…
To be honest, I didn’t anticipate how technical this book was going to be. It wasn’t long into the book before Nathan started talking code. Code, as in Python, PHP, Javascript, HTML and his favorite, an open source program simply called “R.” From the descriptions, even a “program” like R still requires writing and pasting in lines of code to create charts. Don’t look for a user-friendly GUI. This is not your father’s spreadsheet program.
And speaking of Excel…well, there’s just not a whole lot spoken of it here. Despite the fact that many (but certainly not all) of the charts discussed can be created at least initially in Excel, and despite the fact that included in the book is a Flowing Data user survey showing that most (31%) of readers use Excel to visualize data, Microsoft’s program is largely ignored after a perfunctory introduction. The how-to’s in every chapter take the user through creating bar charts in R and donut charts in a coding toolkit called Protovis (wasn’t that the software company in War Games?) The introduction to the latter begins with, “The first thing you do is create an HTML page…” All this for a donut chart which is essentially a pie chart with a hole in the middle?
Perhaps the problem I have is not with the book’s decision to ignore more user-friendly solutions, but the fact that there are no powerful one stop shop user-friendly software solutions for data visualization. Even if one insists that I am just intimidated by coding (true), Nathan still explains that he imports almost all of his coded visualizations into Adobe Illustrator in the end to make them look good from a design standpoint. So clearly, all these software solutions only get you halfway there.
Perhaps someone will create the Adobe Photoshop or Final Cut Pro of data visualization one day. But until that time, anyone serious about playing in this space must have this book for the very detailed step by step instructions found within.
I really am a fan of Nathan and his work, but this is a book for a determined data designer who has the patience and drive to learn multiple new software and programming tools. My feeling is that this is an investment too involved for most graphic designers or for the average civilian who often presents data.
Stephen Few has written another strong criticism of a lot of contemporary data visualization (and David McCandless) with regard to some new GE data visualizations. I think many of his points are valid, and his post is well worth a read.
I particularly appreciate Few’s perspective on users who needs data and data visualizations to actually make decisions. As he explains, he works mostly with people who depend on understanding data correctly and efficiently to do their jobs. I think the actual practicality of data visualization is often forgotten in the face of the pretty factor.
Almost always, data visualization should make things easier and quicker for the user to understand the material, not more difficult.
Thoughts?
Well, you’ve all seen the U.S. Army’s “How [Not] to Fix Afghanistan” PowerPoint slide.
It’s not new, but I just found its big brother in the form of this poster describing essentially how our military buys stuff.
Hooah!
h/t to Wired.
I thought the standard 3D Microsoft pie chart was bad until I saw the David Bowie Labyrinth version from an SAP slide.
Bryan Pierce at Perceptual Edge has more.
The increased interest in information graphics has also brought increased debate over their use, abuse and effectiveness. Connie Malamed over at Understanding Graphics even questions the correct usage of the terms “infographics,” noting that most of the time, “infoposter” is more appropriate. (I even use the term “data collage” in certain cases.)
There is no question that infographics and data visualizations are becoming powerful communication tools in journalism, online and in business. One of my colleagues credits the creation of an infographic for one of our client’s products with getting an important news article placed in a major national paper. The infographic itself was never printed, but it successfully “sold” the story to the newspaper.
NiemanWatchdog.org recently criticized and cautioned the media for misuse of infographics in covering the Bin Laden killing. They rightly point out that just because you’re drawing a picture instead of using words, you still can’t make stuff up. (Would you make up sales numbers if you used a bar chart instead of prose?) They laid out 6 rules journalists and the media should follow in using infographics.
Stephen Few is one of the leading voices in data design and his books and site are must-reads. He is a passionate advocate for simplicity and clarity in charts, and he recently reignited a debate over whether there actually is any merit in the type of chartjunk that Edward Tufte rails against.
Last year a group of researchers published a study arguing that embellished USA Today-like charts and graphs are actually more “sticky” and communicative to a reader than Few’s/Tufte’s more spartan styles.
Stephen wrote a critical article respectfully taking exception to the methodologies and findings of the researchers.
If you’re not Tufte-d out, both Few’s article and the original study, are worth a read. Plus, Bruce Gabrielle gives a nice summative overview of the study and its problems at SpeakingPPT.
Stephen also ruffled a few feathers by criticizing on his blog the work and style of David McCandless. There were a lot of comments back and forth on Stephen’s post and even more in a post on Flowing Data, one of the top sites dedicated to information design.
If you’re not familiar with McCandless’ work, a good introduction is his TED talk.
* * *
Well, for what it’s worth, I agree with Stephen Few‘s work and approach. I love David McCandless‘s style. I respect Edward Tufte, and I also admire Nigel Holmes, whose work is often held up as representative of needless chartjunk and embellishment. (But yes, Nigel, you do need to work on that website of yours…)
All that said, I disagree with all of them to varying degrees when it comes to certain things. But I’m glad there is so much passion and that the debate is so lively! Information design is a continually and rapidly developing discipline that holds great promise. I’m seeing firsthand major companies desperate to be able to visually communicate their stories elegantly, succinctly and smartly. Hardly a day goes by now in which the word “infographic” is not part of some conversation at work.
And I’m not even going to go into “Big Data,” a tidal wave of an issue McKinsey just released a large report about.
Oh, and by the way, I’m hiring a full-time information designer…know anyone?
The Washington Monthly just published a in-depth profile on Edward Tufte. Would have expected a little more critical observation, but still good stuff.
I just discovered SparkTweets!
Now there’s a way to visually show a small bit of data in a Tweet, Facebook post, text message or other similar format.
I believe the credit for SparkTweets goes to Alex Kern and his post from nearly a year ago, but they’ve been getting more and more attention the past week: Jason Kottke wrote about them a few days ago and the Wall Street Journal has just started experimented. Zach Seward of the WSJ discusses them here, with a lot of examples.
And here are two SparkTweet generators for creating the unicode text blocks:
* * *
SparkTweets are a variation of Sparklines which were created by Edward Tufte as a way of displaying a great amount of information in a small space. They’re especially good for showing many data points over an extended period of time—things like stock prices or win/loss rates for sports teams. Here are a few examples.
The newest version of Excel has a sparkline tool. It’s not hard to use, but here’s more on it. I’ve played around it with a bit when tracking my investment portfolio.
And what can I say about the awesome handmade sign from BO’s Restaurant in Key West? The attitude and design aesthetic completely mirror that sandwich shack’s decor and approach. The food is amazing, but like The Burger Joint at The Parker Meridien, it won’t be ranking high on Zagat’s decor list.
Okay, this may be nitpicking, but there’s really no reason why 50% of this small notepad need be taken up with hotel advertising. (And the all caps does’t work.)
There’s nothing like a vacation to reacquaint yourself with USA Today. There are ongoing disagreements about whether the “USA Today style” of data graphics actually helps or hinders the reader. I understand both arguments, but I often have issues with their charts. This one, for example, doesn’t work for me on a number of levels:
Again, this style of graphics has its proponents, but after a week of looking at these, they never got any easier to read. In general, I find myself spending too many seconds looking at the whole chart before I completely understand the entire story. Graphs involving so few data points should be fairly instantaneous to understand.