RefBan

Referral Banners

Yashi

Wednesday, October 19, 2011

FlowingData - The Don’ts of Infographic Design

FlowingData - The Don’ts of Infographic Design

Link to FlowingData

The Don’ts of Infographic Design

Posted: 19 Oct 2011 12:24 AM PDT

Speedometer

Smashing Magazine offers advice on the dos and don'ts of infographic design, but they forgot to include the former. It's as if I wrote a fake post and someone mistook it for a serious guide. Written by Amy Balliett of Killer Infographics, the post is basically tips for how to create linkbait that doesn't work. Or at least I hope it doesn't.

Let's take it from the top.

Infographics are visual representations of information, or "data viz" as the cool kids call it these days. The term "data viz" comes from "data visualization," which implies that sets of data will be displayed in a unique way that can be seen, rather than read.

I'm not going to get into the semantics. That's for people who are smarter (and cooler) than me, but the obsession with a visually unique result is overdone. Sure, you want your graphic to be compelling, but that comes from the data or the information. You're just trying to make crap look like cake if you do it any other way: it looks good from far away, but as soon as you take a taste, you realize you have poop in your mouth.

Next up, which refers to the graphic above:

What's wrong with this infographic? It breaks the first rule right out of the gate. When you have an opportunity to display information visually, take it. Here, the tweets per second could have at least been shown in a bar graph.

What? We all know the first rule of infographic design is to not talk about infographic design. I guess that's implied. After that though, the first thing wrong is that there are numbers? What about that gauge on the left without any labels? What does it mean?

Most run-of-the-mill infographics take a few data points and make it look like a lot with big things. This is both a reflection of the data on hand and the creator's data comprehension.

It gets worse.

Two alternatives to the above are offered. Do you choose the utterly boring, horribly regular graph A or the awesomely, cool, and round graph B?

I hope you didn't answer graph A. If so, you're wrong.

If you answered Graph B, you're catching on. Of course, not all data lends itself to creative and unique graphs. Graph A might work very well if the rest of the infographic shared a similar aesthetic. Sometimes you just have to bite the bullet and produce a traditional bar graph or pie chart; nevertheless, always consider ways to dress it up [...]

It's that obsession with unique again. The problem isn't the bar chart. It's that there's only five data points occupying a lot of screen space. Plus, the speedometer makes tweet rate look way more than it really is, because the method uses arc length as its visual cue.

A more useful graphic would provide more context to the events that these numbers describe. What made the Women's World Cup Final so much more exciting than Super Bowl 2011? Which final was it? Was it really more exciting? When were these measurements taken? Are they the peaks of each event or is it a mix? Were there more tweets because there were more Twitter users at the time? Was it because the time of the day each thing happened? Tell people something — anything — more about the data.

The second half of the post covers mostly general design tips such as color and focus, so it's less rough, but the examples aren't any better.

Bottom line: when it comes to information graphics, it should always be data and information first, and then you design around that. For that to happen, you have to learn more about data — how to work with it, where it comes from, and what it represents in the real world.

Now how about some real dos of data and information design? Leave a DO in the comments below by the end of this Friday, and a signed copy of Visualize This goes to a randomly picked doer.

Statisticians don’t program?

Posted: 18 Oct 2011 11:45 AM PDT

We're statisticians. We don't program.

— Anonymous statistician

I was talking to a small group of statisticians a few months ago, and someone said that to me when I told them how I go about mucking around with data. It still annoys me just thinking about it. It wasn't that he didn't know how to program — because that's perfectly understandable — but he said it in a way as if programming and statistics were so separate that there was no possible way the two could go together.

Wrong.

Let's set things straight before this silly idea spreads further. Programming and statistics belong together, and you don't have to be a coding genius for it to work.

No comments:

Yashi

Chitika