How, when, and why to use bullet charts

Bullet charts, an invention of Stephen Few's, are a handy visualization tool. Though not often seen, the bullet chart is often a better option than other competing visualization types, such as the dashboard gauge.

Why use a bullet chart?

Why should we prefer to use the bullet chart? The dashboard gauge places all of the values to be analyzed around a circle. This then means that we must make quick angle comparisons if we want to distinguish one value from another.

Take a look at this example from Klipfolio:

How far below our target is our measurement? What is the value that is being indicated by the indicator bar? It turns out that the value is $23.6M. That is an incredibly difficult calculation to make, though -- you have to mentally calculate how many millions of dollars correspond to each portion of the arc, determine how many degrees away from 0 the indicator bar is, and determine the degree difference between the $30M target and the indicator. 

Where the dashboard gauge necessitates an angle comparison to determine the difference between two charts, a bullet chart only requires a comparsion between two common scales. This is preferable because we are making use of a stronger preattentive attribute of visual perception. In other words, we are more readily able to discern objects that make us undertake linear scale comparisons than those that make us undertake slope or angle comparisons. You can see a very useful chart that compares the relative accuracy of different attributes of visual perception here:

The visualization is from Alberto Cairo's superb The Functional Art. If you are unfamiliar with preattentive visual attributes, check out Cairo's book or Stephen Few's excellent article, Tapping the Power of Visual Perception.

We ought to prefer bullet charts because they make use of a stronger preattentive attribute. If we are looking at two bullet charts that are aligned, we even get to make a comparison along two common, aligned scales.

When to use a bullet chart?

A bullet chart is useful when you have a single, continuous variable whose value you wish to indicate in relation to several categorical regions. For example, you might wish to categorize economic growth for a country (measured in percentage points, so a continuous variable) as good, average, or bad (a categorical indicator).

How to create a bullet chart?

There are a number of ways to create bullet charts using modern visualization tools. One approach is to make them from scratch using d3. For a great overview of how to create these, you can read Mike Bostock's Bullet Chart Block.

For those wishing to use a higher-level JavaScript library which will enable you to make a bullet chart using just a few lines, check out NVD3.

To scroll or not to scroll -- changing the rules of the game for dashboard UX

I was rereading Few's Information Dashboard Design recently and was struck by one of his "13 key mistakes in dashboard design":

 Exceeding the Boundaries of a Single Screen

My insistence [is] that a dashboard should confine its display to a single screen, with no need for scrolling or switching between multiple screens...

-- Few, Information Dashboard Design, Ch. 3.1

First, what does this mean in a post-mobile revolution world? Many devices no longer have screens big enough to fit a traditional dashboard. Refusing to make online applications mobile compatible is simply no longer an option given the ubiquity of devices. What are we left with? We need to find a way to provide meaningful data for our dashboard viewers without necessitating side-by-side visual comparison. We need to use dynamic, flexible layouts such that when viewers are on a smaller device, their screen renders content in a way that best uses their screen real estate. Finally, we need to make sure that we are presenting data in ways that allow for meaningful comparisons to be made. Given the plethora of data manipulation libraries, we have no excuse not to slice, dice, and aggregate the underlying data to facilitate viewers' analysis.

What about the cases where viewers are using devices that do have sufficient screen real estate to make a meaningful one-page layout? It used to be the case that many well-designed web pages also followed this steadfast rule: keep your content to a single page to avoid the burden of having your user scroll down the page. Additionally, if we had too much content on one page, it took a long time for content to load which created a sub-par experience.

Now that we have the ability to widely make asynchronous requests (e.g. with Ajax), this is not as much of an issue. Users are also used to web applications that make use of infinite scrolling -- scrolling is a more natural part of the online user experience than it was even 5 years ago. To put it in the language that Donald Norman from The Design of Everyday Things uses: the nature of the browser environment's affordances have changed. Browser users have always been able to scroll through a web application. Nowadays, though, browser users are aware that they can scroll easily, and use this as a primary method to interact with web applications, whereas before it was a secondary method.

Does this mean that we should let our dashboards grow into multi-page mammoths? No. The point of a dashboard should still be to succinctly provide informative data. There is more justification, though, to think about extending the dashboard boundary beyond the edge of the page when it is necessary.