Fast and slow visualization

Visualization is often described in the context of speed and efficiency. Get the most insight for the least amount of ink or pixels. Elijah Meeks argues that visualization goes far beyond this point of view:

This breakneck pace is a real data visualization constraint. It’s not a myth that charts are often deployed in rooms full of people who only have a short time to comprehend them (or not) and make a decision. Automatic views into datasources are a critical aspect of exploratory data analysis and health checks. The fast mode of data visualization is real and important, but when we let it become our only view into what data visualization is, we limit ourselves in planning for how to build, support and design data visualization. We limit not only data visualization creators but also data visualization readers.

In the three-parter, Meeks tries to make the fuzzy aspects of visualization — meaning, insight, impact, etc. — more concrete.

See also:

Note the dates on all of them. We’ll figure out this visualization thing one of these days.

Tags: , ,

Visualization for an audience

Jonathan Corum, the Science graphics editor at The New York Times, talks about his experiences communicating scientific research to the public. Much of visualization design is about figuring out the audience and making graphics for that audience, so Corum uses a lot of examples that start from technical research papers and finish with a more focused result.

Tags: ,

Abstract: The Art of Design, with Christoph Niemann

Abstract: The Art of Design kept popping up on my Netflix recommendations list for the past several months. I ignored it though, because I’m tired of the heavy-handed design shows talking about how design is life and life is design, etc. Also, I probably spend more time flipping through what I can watch than actually watching anything.

In any case, for some reason I hit play and was happy to see the first episode with Christoph Niemann. Niemann is known for his whimsical, visual storytelling, and his process was fun to watch. Recommended.

And if Netflix isn’t your jam, this talk by Niemann is also good:

Tags: ,

Understanding animated transitions in data visualization

Alec Barrett for TWO-N describes the benefits and some of the intricacies of animated transitions in data visualization.

This visual essay is inspired by the question: What is happening conceptually between the start and end of a transition? I look at reasons for using animated transitions (besides “it looks cool”) and at the kinds of variables that can be transitioned. I conclude that we can think of animated transitions in two categories: those where the space between the start and end states consists of real/realistic data and grammatically valid states for that visualization, and those where it does not.

The essay by the way was published on Observable, a new-ish way to publish “interactive notebooks for data analysis, visualization, and exploration.” Worth a look if you’re into publishing and sharing code.

Tags: ,

Choropleth map design considerations

Lisa Charlotte Rost for Datawrapper provides guidance for designing choropleth maps that most fairly represent your data:

Maps are not objective, but a version of reality. When creating them, lots of choices are made: What to map, how to map and whether or not to use a map in the first place. Here we’ll try to find guidelines to all of these questions, for a specific subset of maps: Choropleth maps (the ones in which each region is filled with a color that represents a value).

Rost’s other guides (line charts, area charts, pie charts, and more) are also full of practical advice. Highly recommended.

Tags: ,

People font

You know those graphics that use icons of people to represent units or counts of people? The Wee People font by Alberto Cairo and Scott Klein makes it easier to use such icons on the web. Just add the CSS file and you’re ready to go.

Tags: , ,

Alternatives to the rainbow color scale

Oh. It’s that time of year already. Time to hate on the rainbow color scale, which is still prevalent but equally less useful than alternatives. Matt Hall provides (scientific!) reasons for looking to scales that don’t include the full spectrum and some solutions.

We know what kind of colourmaps are good for interpretation: those that increase linearly and monotonically in brightness, with no jumps or stripes of luminance. I’ve linked to lots of places where you can read about these — see the end of the post. You already know one perceptual colourmap: the humble Greyscale. But there are lots of others, so let’s start with one of them.

Tags: ,

Importance of form and survey design to gain an accurate picture

Lena Groeger, writing for Source, shifts attention upstream from analysis to the design of forms in the data collection process.

Whether you’re filling out a form or building it yourself, you should be aware that decisions about how to design a form have all kinds of hidden consequences. How you ask a question, the order of questions, the wording and format of the questions, even whether a question is included at all—all affect the final result. Let’s take a look at how.

Census surveys, election ballots, and racial profiling. Oh my.

Tags: ,

Choosing color palettes for choropleth maps

Choropleth maps, the ones where regions are filled with colors based on data, grow easier to make. However, choosing colors, the number of colors, and the breakpoints is often less straightforward, because the answer is always context-specific. Lisa Charlotte Rost, now at Datawrapper, provides a rundown of the decision process.

The explanation is in the context of the Datawrapper tool, but you can easily apply the logic to your own workflow.

Tags: , ,

Project Lincoln from Adobe aims to reverse data visualization workflow

With data visualization, you start with the data and let it guide geometry, colors, etc, and from there, you work on aesthetics, readability, and usability. The data informs the design. Project Lincoln is an experiment from Adobe that flips this. You draw shapes and illustrations first and then bind data to them.

Here it is in action:

My brain was confused. Something about this order of things doesn’t feel right. You go in with design first and then bring in the data, and then you edit again? Maybe this would be useful for quick prototypes or visual experiments? It’s hard to say how this would go in practice without actually trying it out, but my gut says no.

Tags: ,