data bitten
data science, business intelligence, and quantrepreneurship

• Home
• About
• RSS
• Subscribe:e-mail

• Recently Written

  • Learning Machine Learning: Beyond the Hype
  • After Hours Marketing podcast: “The Subtle Differences Between Reporting and Analytics”
  • Seven ways to avoid the seven month data science itch
  • The law of small numbers
  • The red and green rule
  • CRAPOLA design principles for quantitative data
  • Reporting versus analytics
  • Uber’s newest data visualization is uber misleading
  • How to hire data scientists – free white paper
  • Hiring data scientists: the data problem

• Categories

  • Uncategorized

• Archives

  • May 2019
  • July 2016
  • June 2016
  • May 2016
  • February 2016
  • March 2013
  • November 2012
  • October 2012
  • September 2012
  • June 2012

The red and green rule

Early in my career, I produced many data visualizations for a senior executive. Let’s call him Gordon. Gordon is unabashedly a man of strong convictions. One of his most strongly and repeatedly voiced was that, in any data visualization, the color green had to represent good and the color red had to represent bad. And there always had to be good and bad. No exceptions.

I quickly caught on, and for the work I did for him I began abiding by his iron red and green rule. Nevertheless, he reminded me of it several times, asking whether red meant good and green meant bad in the visualizations I produced, despite my answers being uniformly in the affirmative.

At first, I attributed his frequent questions to a lack of trust; in fact, it was one of the only factors contributing to my (slight) perception of a lack of trust in our relationship.

Then, one day, I was sitting in Gordon’s office, while a dashboard brimming with my red and green charts filled his computer screen. He was one of the primary users of this particular dashboard, and was quite familiar with its content. He asked me a question that, for the first time, took me by surprise: “are these charts red and green?”

That’s the moment I realized that the frequent questions were not about trust. Gordon is colorblind.

Why would someone with red-green colorblindness want reports of which he is a primary user in red and green?

It turns out that Gordon picked up this conviction while working for a (colorseeing) CEO who insisted on red and green in his charts. Once acquired, it became a hard and fast rule, part of Gordon’s data visualization grammar.

We all have strong convictions. In the world of data visualization, convictions are often influenced by poor conventions set over decades, such as by lay users of Microsoft Office. The proliferation of 3D pie charts is more about convictions and conventions than about good data visualization.

The next time you’re creating a data visualization, apply your own critical thinking rather than relying on conventions. Consider the best way to surface and communicate the information. Critical thinking, not following conventions, is the path to creating the best data visualizations.

CRAPOLA design principles for quantitative data

Robin Williams (from her website: “writer. teacher. mom. not the actor”) has developed the widely cited CRAP design principles: Contrast, Repetition, Alignment, and Proximity. These are powerful general purpose design principles, but a few additional principles are helpful with respect to the display of quantitative information.

Inspired by the work of Edward Tufte, I propose three additional rules be added to complete CRAP: Obviousness, Lightness, and Accuracy. The resulting CRAPOLA design principles for quantitative data are:

Contrast: avoid similar elements (type, color, size, shape, etc.); if they’re not the same, make them very different.

Repetition: repeat visual elements throughout to organize and unify.

Alignment: every element should have some visual connection with another element.

Proximity: group related items close together to facilitate comparison.

Obviousness (clarity): clearly communicate the data.

Lightness (efficiency): show the data and nothing else.

Accuracy (precision): do not omit or distort data.

Reporting versus analytics

“We are drowning in information but starved for knowledge.”

- John Naisbitt

For the love of statistics, please stop using the words “reporting” and “analytics” interchangeably. Reporting is the display of information. Analytics is the interpretation of information. Analytics is the process that turns information into insight, reporting into understanding.

Every time someone uses the word “analytics” to mean “reporting,” a statistician loses its wings. If you ever need evidence that the misuse of these terms is widespread, just think about how many statisticians you’ve met who have wings. I’ve never met one. All the wings are gone.

Here are a few of my favorite illustrations of the difference between reporting and analytics:

Since analytics solves problems, which is a lot sexier than reporting’s goal of presenting information, companies with reporting solutions have a vested interest in conflating the terms. Phrases like “analytics solution,” “analytic database,” and “advanced analytics” are used with the intent to confuse, to convince users to invest in technology over thought. A typical exchange goes as follows:

Reporting tool salesperson: “I have an analytic database.”

Business person: “Thank God! All my problems are solved.”

Here are a few of my favorite examples of oversells in the reporting world:

And don’t get me started on the phrase “business intelligence,” which has been used so many different ways with so many different connotations that it has been rendered virtually meaningless. If you ask ten people in the BI industry what “business intelligence” means, you’ll get twenty opinions. In case you’re looking for something to do this weekend.

• About

  Data Bitten aims to tell the story of the data revolution. More to come.

• Stay connected