While we all know “it depends” might be the easiest answer, it certainly isn’t the only way to look at guidelines. Our editors took a broad view in finding ways to consider the act of guiding someone to do something versus the mindset of supporting someone to make faster or more standardized decisions. 

There is a lot of design discussed in this issue, from the advanced design systems of Moritz Stefaner, to Leticia Ange Pozza’s take on building data products, to the very first rumination on data design by Étienne-Jules Marey in 1879. Knowing how we design data to be understood is central to Zan Armstrong’s essay, “Make the Important Visible.” Then again, Nadieh Bremer isn’t afraid to shake things up by “Embracing the Taboo!”

Of course, it’s super important to know who your data viz is for. We are delighted to feature a 12-page special feature on accessibility for data viz curated by our new managing editor Emily Barone with content from Frank Elavsky, Jaime Tanner, Johny Cassidy, and Ben Willers. Complementing that section nicely is William Careri’s article, “Designing for Neurodivergent Audiences.”

Our recurring Career Tooltips section features an essay by Jon Schwabish on how to critique a dataviz, while Stephanie Evergreen shares insights from her checklist evaluating the effectiveness of a chart. Shira Feder pounded the pavement in asking a host of experienced professionals across multiple fields what rules they have embraced over the years. The section is rounded out by a new feature, “Dear Dr. Data,” which is our new “advice” column—just don’t take it too seriously.

There’s loads more: We have one of our favorite Dataviz Horror Stories from Miriam Quick, a new Dear Nightingale challenge hosted by India Johnson, and a fun Data Is Plural challenge covering works by Jane Austen and other literary greats! That’s not even counting feature articles by Marco Hernandez, Lisa Charlotte Muth, Joey Cherdarchuk, Peter Grundy, Sonja Kuijpers, Erin Waldron, and Ellen Bechtel, and more. Holy smokes, have we squeezed in a ton of grade-A quality!

How did we get here?

We want to thank our editors and editorial committee who kick-started us back in February. As you can see, we had A LOT of ideas and quite a few of them made the full journey from seedling to blossom. We need to work harder to make a “Sartorial guidelines” article, though. That seems like a ton of fun (heyyy, why not write one for issue 4? Our deadline for article submissions is July 15th!)

Putting this all together is absolutely a team sport, so here’s a little behind the scenes in the form of Q&A with the core team (Emily Barone, Julie Brunet/datacitron, Jason Forrest, and Claire Santoro):

1. Obviously all of the content is fantastic, but what’s one of your favorite articles from issue 3?

EMILY: I am so, so, SO proud of the collection of articles that fit into our “accessibility” coverage. It’s a great mix of topics, from neurodiversity to visual impairment, all with a focus on how our industry can become a leader in this space. (I’m biased, of course. As a data viz practitioner, this topic is close to my heart. As an editor, researching and shaping these stories was a great learning opportunity!)

CLAIRE: It’s so hard to choose! I love the variety in issue 3—there are practical how-to’s, visual inspiration, personal stories—but one of my favorites is the story behind a trail map designed by Ellen Bechtel. That article gives us a different way of thinking about guidelines, or, as Ellen writes, “the lines that guide me.” It’s such a relatable story for data viz enthusiasts. It’s not about creating charts for mass communication, but rather about using data viz to make something special and meaningful and personal. 

JASON: I think our reprint of Étienne-Jules Marey’s Graphic Method introduction is absolutely fantastic. Not only is it a deeply interesting perspective from when the concept of science was becoming codified, but it’s easily one of our best designed articles (by the amazing datacitron, of course). Also, I giggle and giggle over the new “Dear Dr. Data” section. I dunno if people will get it, but I find it hilarious.

JULIE: Like in the previous issues, designing a meta-viz about the magazine itself (Disturbances) was a treat. I’m really grateful for this opportunity to explore and experiment with an unusual form of visualization. Otherwise, I really love the Graphic Method piece. Not only because I loved designing this messy collage article, but mostly because I find it amazing to give a new life to the brilliant work from the past.

2. What was particularly challenging about issue 3? (No pointing fingers at difficult writers or illustrators!)

EMILY: The writers and illustrators were awesome. But the managing editor… eek! She had to learn on the job which really slowed everything down. Thank goodness she had fabulous colleagues to support her—love you, guys!—and is ready to rock the next issue. 

CLAIRE: We’re thrilled to have you, Emily! I think we all had a bit of a learning curve with issue 3. The biggest challenge for me wasn’t even the magazine itself—it was everything we needed to do to upgrade our printing, fulfillment, and subscription processes. We changed almost ALL of our logistics between issues 2 and 3. But those changes were absolutely worth it. 

But in terms of the magazine, I think one of the biggest challenges was finding the right layout for graphics-heavy articles. Take Lisa Charlotte Muth’s piece relating data viz to art theory. That topic obviously comes with a lot of imagery, and you want to make sure all the fabulous works of art and data viz have enough room to shine. 

JULIE: To be honest, I always find every article challenging. You would think that being the third issue, the fear of the blank page would be tamed by now, but not really… At the same time, that’s where all the fun comes from, right?!

JASON: I had the worst time curating the gallery section this time. The previous two issues were pretty straightforward to find great content, but this time I was paralyzed between choosing different curatorial concepts. In the end, I opted to focus on “trailblazers” and I’m very pleased with the results!

3. How did the issue 3 process compare to issues 1 and 2?

CLAIRE: The total time spent compiling the magazine was similar to issue 2 (about three months), but the process was more predictable. Now that we’ve done it a few times, we have a much better sense for the workflow! From the time an article submission comes in, it moves through a predictable series of steps: an initial edit with the author in Google Docs, setup in InDesign, layout and design by Julie, design edits in parallel with copyediting in InCopy, and, finally, compilation of the whole PDF. It’s beginning to feel like we know what we’re doing. And of course, as with issues 1 and 2, we owe a lot to our volunteer editors! This issue is immeasurably better because of your ideas, edits, and keen eyes. Thank you!  

EMILY: As this was my first issue, I cannot compare the process; only the final product. And this issue is a tier above. 

JASON: As we mentioned in our Podcast with Andy Kirk at Outlier, issue 3 was not just assembling the issue, but also rebuilding our entire operation. Not only did we make the issue, but we switched to a US-based printer, built a new online shop, and established the new infrastructure to mail to more countries, faster, with order tracking. Honestly, it’s been a lot, but we’re glad we did it.

JULIE: Our global process stayed the same as Claire explained it, though improved in terms of copyediting thanks to Emily’s inputs. We’re trying to find ways to make things more efficient and smooth, but the very nature of Nightingale (being a collective publication) requires more flexibility and adaptability than, well, too strict guidelines ! 

4. What are you most excited about moving forward?

EMILY: Our new systems! While editing and designing issue 3, our team was also really busy developing new back-end systems and resources—a fresh style book, a more-efficient content management process, a new fulfillment and distribution system—which will all make issue 4 (and issues 5, and 6, and 7…) a much smoother process!

CLAIRE: I’m actually really excited about the theme for issue 4: “emotion.” Some of my favorite articles are the personal or quirky ones—data humanism, data art, physical data viz, etc. “Emotion” is an open-ended enough prompt that I think we’ll get some creative pieces! (Submit yours by July 15!)

JASON: I am super-excited about rolling out some MERCH! Get ready for some DVS and Nightingale T-shirts, sweatshirts, mugs, hats—you name it! I’m also really excited about the theme for issue 4, “Emotion!”

JULIE: I’m looking forward to the return of the Kids’ Table in the next issue! We couldn’t make it this time due to the massive reworking of our processes and entire operation, but this is our top priority for issue 4. It’s a really important part of the data literacy agenda and it’s an absolute treat to design!

And if that wasn’t enough…

We also had the absolutely honor of being interviewed as a team by the one and only Andy Kirk for his Explore Explain podcast! The episode was taped live at the Outlier Conference (which was just fab) and featured our whole editorial team. Here are the video and audio versions:

The post More than “It Depends”: Behind the scenes on Nightingale magazine issue 3, Guidelines appeared first on Nightingale.

In recent years, there’s been a growing movement within the data visualization community of well-known experts pushing back against what are regarded by many as universal rules of data visualization, such as…

• “Never use pie charts.”
• “It’s always OK to start a chart’s quantitative scale at something other than zero, as long as it’s not a bar chart.”
• “High-precision ways of showing data are always better than low-precision ones.”

Those who object to these being universal rules argue that they all have exceptions, i.e., that there are situations in which it clearly makes sense to break them. I consider myself to be part of that movement. I can point to scenarios in which I consider that these rules—and many others—should be broken.

I depart from my fellow partisans, however, when it comes to what they say next (what movement would be complete without splintering into competing sub-movements?)

Those who believe that there are no universal rules tend to go on to assert that dataviz design decisions are too complex, subjective, or situation dependent to be captured as rules that always apply in every situation. Their battle cry is, “It depends!”, the implication being that practitioners can’t learn how to make these decisions by learning rules. They just need to develop judgment over time through practice and experience, and by studying others’ charts as examples.

“That sounds reasonable…”

…but I disagree. I think that many common dataviz design decisions can be codified as formal rules that can be followed by practitioners of any experience level to make the best possible design choice in any situation, without exception. The bad news is that these rules can’t be captured in simple “always/never” sentences, like the rule examples above. The good news is that many of them can be captured in relatively simple decision trees.

“Show me!”

I’ll show sample decision trees for two common-but-tricky dataviz design decisions in a moment, but I need to mention an important caveat first. These decision trees aren’t intended to be self-explanatory. They’re excerpted from my Practical Charts course, in which I explain the rationales for why they’re designed as they are via examples and scenarios. While you can probably guess how to interpret these trees, you probably won’t understand why they’re structured as they are without the context of the course. That’s OK, though, because that’s not necessary for the purposes of this article, so don’t worry too much if you don’t understand why they’re structured as they are.

Now that that’s out of the way, here’s a sample decision tree that guides practitioners of any experience level when determining whether a pie chart or an alternative chart type is the best choice in virtually any situation:

The decision tree below is for another common-but-tricky design decision: determining when it is or isn’t necessary to include zero in a chart’s quantitative scale.

“I’ve seen ‘chart chooser’ diagrams like the pie chart one before.”

Yes, there are many other “chart chooser” diagrams and tools floating around out there, but the ones that I’ve seen omit many relevant decision factors. For example, other tools that I’ve seen take, at most, two or three factors (e.g., if the values are parts of a total, how many parts there are, etc.) into account when determining when to use a pie chart or an alternative chart type. In the pie chart decision tree above, however, there are eight decision factors. If a tool takes just two or three decision factors into account, I’m not sure how it could recommend reliable design choices in a wide variety of situations.

I think this oversimplification is why, with other tools that I’ve seen, it’s easy to come up with realistic scenarios in which following the tool’s recommendation would yield a design choice that no one (including, almost certainly, the creator of the tool) would consider to be a good choice. More often, though, such tools don’t actually recommend a specific chart type for the situation at hand, they recommend a group of chart types, and then advise chart creators to “use their judgment” to choose from within that group. “Use your judgment” isn’t helpful, though—especially for less experienced practitioners—and I think that it’s possible to offer more specific, helpful guidance than that.

“But how do you know that your decision trees always point to the truly best design choice in any situation?”

Well, I can’t be 100 percent certain, but I’ve shown the pie chart decision tree to thousands of workshop participants and blog post readers from a wide variety of demographics and backgrounds, and implored them to tell me if they can think of a single scenario in which it wouldn’t point to what they’d consider to be the best design choice for that scenario. When I started showing early drafts of that particular decision tree, people did find scenarios in which it wouldn’t recommend what they considered to be the best choice, and I made several tweaks to the tree as a result (thanks, guys!). It’s been at least a year since anyone’s spotted an exception, though, so I think it’s pretty solid at this point. If you spot an exception, however, please tell me so that I can revise the tree!

The “Do I need to include zero in my chart’s scale?” decision tree, on the other hand, is hot off the presses and will likely get a few tweaks as people spot scenarios in which it wouldn’t recommend what they consider to be the best design choice. I expect it to be pretty solid after a few hundred people have scrutinized it and I’ve shored up any exceptions. If you want to understand the rationales behind that particular decision tree, here’s the very long explanation.

I’m guessing that some readers might object that these decision trees just codify my own personal preferences or biases. That could, of course, be true, but it seems unlikely since no one has pointed to anything that they personally consider to be an exception in quite some time, despite my supplications to do so. I suspect that these decision trees just codify practices that most experienced practitioners agree with, but that are complicated to formalize in a robust way, in much the same way that it’s tricky to codify the rules of English grammar, but, once those rules are codified in a robust way, experienced speakers tend to agree with them.

“Are you saying  that all dataviz design decisions can be codified as rules?”

No. There are plenty of design decisions that are too complex, creative, or situation specific to be codified as universal rules. For example, I don’t think it’s possible to codify specific rules for determining which parts of a chart to visually highlight, or for formulating effective chart titles. For those types of decisions, we can only offer general principles and high-level advice such as, “It’s often (but not always) useful to put the main message of a chart in its title.” For the many design decisions that can be codified as rules (my Practical Charts course and upcoming book contain over 20 such tools), however, there are significant benefits in doing so.

Writing provides a useful analogy here. Can every aspect of writing be codified as formal rules that will allow anyone to write the next best seller? Obviously not. Does that mean that writing doesn’t have any codified rules that apply in all situations? No, writing has many such rules, from basic spelling and grammar to the logical sequencing of ideas. For writing decisions that can be codified as universal rules (e.g., when to use “they’re”, “there”, or “their”), providing practitioners with specific guidance for those decisions instead of telling them to “use their judgment” makes it far easier for them to become competent quickly and to make the best choice every time.

“Are these rules truly unbreakable? Do they really apply in every situation?”

Just like writing, they’re are times when it makes sense to break formal rules, but there limited to times when the author is exercising artistic license (see what I did their?). When creating data art, then, it can absolutely make sense to knowingly break the rules. The keyword in that last sentence, though, is knowingly. Deliberately breaking rules for artistic reasons can be extremely effective, but breaking them because you didn’t know about them in the first place will reliably produce charts that are unobvious, confusing, ambiguous, and/or misleading, just as written prose that breaks the basic rules of writing will be unobvious, confusing, ambiguous, and/or misleading (how many times did you have to re-read the first sentence in this paragraph?).

“What about data visualization research? Isn’t that supposed to tell us what ‘the rules’ are?”

If a data visualization research study finds that people can compare the parts of a total with one another more precisely as a bar chart than as a pie chart, that’s important information to know when choosing chart types in practice. Does that mean that practitioners should always choose bar charts over pie charts? No, because, as the pie chart decision tree above shows, the ability to compare the parts of a total with one another precisely is just one of eight decision factors that go into determining whether to use a bar chart or a pie chart in a given situation. (I’ll publish a whole article on pie charts–yes, apparently, the world needs yet another pie chart article–when I’ve braced myself sufficiently for the inevitable backlash.)

Data visualization research findings are crucial inputs into making design decisions, but they don’t typically point to specific design choices in specific situations. They tend to focus on just one or a few factors, such as how precisely people can compare quantities in a few different types of visualizations, how likely people are to misinterpret the underlying data in a few specific types of views, or how rapidly people can interpret a few different ways of showing the same data. This is why many studies caution practitioners to “use their judgment” when extrapolating the study’s findings to real-world chart design decisions.

In order to develop practical guidance for questions like, “Exactly when should I use a bar chart instead of a pie chart?”, multiple research findings need to be factored into a single decision tool that takes all relevant decision factors into account. I believe that the decision trees in my Practical Charts course accomplish that, but tell me on LinkedIn or Twitter if you disagree!

“Do you think that research will eventually resolve most best practice controversies?”

Many people seem to assume that controversial dataviz design best practices (pie charts, anyone?) have remained controversial or in murky “it depends” territory for decades because there hasn’t been enough research into them, and that a deeper understanding of how humans process visual information will eventually settle these long-running debates once and for all.

While that’s undoubtedly the case for some of these controversies, I suspect that many of them evaded consensus because we hadn’t identified all of the factors that go into making those design decisions, and hadn’t sorted out the complex ways that those factors interact when making a final design choice in practice. In other words, we didn’t have robust decision trees for them. When those decision trees are in hand, the controversy tends to dissipate.

Can research produce these decision trees? Unfortunately, developing them is essentially a very tricky Boolean logic puzzle, and Boolean logic puzzles can’t be solved with lab experiments. They just need to be reasoned through—while factoring in research findings for decision conditions for which research is available—and then reality-checked with as many real-world audiences and in as many real-world situations as possible.

I think of developing these decision trees as analogous to developing grammar-checking rules for word-processing software. The main challenge isn’t that we have an insufficient understanding of how people process language, it’s that it’s hard to reverse-engineer rules that expert speakers of a language intuitively know, and then codify those rules in a way that’s robust enough that they make good grammatical recommendations automatically in any situation. The challenge isn’t that we lack research into how people process language, it’s that the rules of English grammar are a tricky logic problem to sort out, and no amount of lab experimentation with research subjects will solve that problem.

I’m not suggesting that data visualization research isn’t valuable or that it shouldn’t continue, however. Quite the opposite. Many decision trees can undoubtedly be improved by new research findings, and research findings are invaluable when making design choices that are too complex or situation-dependent to be codified in simple decision tools. Improving our fundamental understanding of how humans process visual information also has intrinsic value and many other practical applications.

“So, what does this mean when it comes to ‘universal rules of data visualization’, then?”

A few things, I think:

1. It is possible to codify many—but not all—design decisions as rules that can be used by practitioners of any experience level to make the truly best design choice in any situation. These design decisions don’t ultimately come down to “it depends” or “use your judgment”.
   
2. The rules for these types of design decisions can’t be expressed as single “always/never” sentences. Attempting to distill these decision trees into single sentences would result in the worst run-on sentences in history. And trying to shorten or simplify them would inevitably open up the possibility that following the rules would yield design choices in certain situations that wouldn’t be the best choices. The simplest possible expression of these rules, then, is as decision trees, not sentences.
   
3. Many long-running best practice controversies can probably be resolved by moving from debating single-sentence rules to discussing decision trees. In data visualization best practice debates, people often argue for or against single-sentence positions, such as, “Never use pie charts”, or “Always include zero in the quantitative scale.” As I hope I’ve shown, these design decisions are too complex to be captured in a single sentence, so debates over single-sentence positions will never end because no single-sentence position can ever be correct in every situation. I’ve seen many workshop participants strongly disagree with one another on a given data visualization best practice, but then melt into agreement when walked through a decision tree that factors in everyone’s concerns and objections.
   
4. Distilling universal data visualization rules is hard. While these decision trees may seem fairly straightforward, they were difficult to develop. Just realizing that decision trees of this type (as opposed to text, Venn diagrams, or other formats) were a good way to express these rules wasn’t obvious. I was only able to develop them after years of dataviz teaching and consulting, and after looking at many thousands of real-world charts to make sure that I was considering the widest possible spectrum of scenarios. Even with all that experience, figuring out which decision factors needed to be included in each tree and how to sequence and connect them was some of the most challenging, cognitively demanding work that I’ve ever done, and drew on my (now distant) experiences as a software developer.
   

I certainly didn’t invent the idea of using decision trees to codify and simplify potentially complex decisions, though. In medicine, for example, similar tools called “clinical pathways” are widely used to provide clinicians of any experience level with guidance on how to make the best possible medical decision in tricky-but-common situations:

“Now what?”

Like I said, I’m firmly in the “it depends” camp, but I think we can do better than that. I wrote this article to encourage my compatriots to go beyond “it depends” and start asking, “What, exactly, does it depend on, and can those factors be organized into codified rules that can be applied by practitioners of any experience level in any situation to guide them to the best design decision every time?” This isn’t an easy undertaking (it took me several years to develop the 20+ decision-making tools in my Practical Charts course), but I hope that I’ve convinced you that it’s worth the effort.

For some design decisions, we will be able to come up with relatively simple rules and tools which will make practitioners’ lives much easier and instantly improve the quality of their work. Other design decisions will turn out to be too complex, subjective, or situation dependent to codify as rules despite our best efforts, and that’s OK. We should at least try, though, since, if we don’t, we’re falling back onto “use your judgment”, or its cousins, “use common sense” and “choose the design choice that looks best to you”, none of which are helpful or reliable, especially to those who are early in their dataviz journeys.

If, after reading this article, you still feel that there are no universal rules that apply in all situations and that there will always be exceptions, tell me on LinkedIn or Twitter! I just ask, however, that you also provide at least one scenario—even a hypothetical one—in which a reality-tested decision tree would not yield what you consider to be the best design choice. If you can’t come up with even one such scenario, I’m going to struggle to agree that these design decisions can’t be codified as rules that work in any situation. If you can, great! Let’s update the relevant decision tree to account for it ? 

The post Does Data Visualization Have Rules? Or Is It All Just “It Depends”? appeared first on Nightingale.

Rules for a joyless world

Goof van Winkel recently wondered:

If everyone uses the same rules, do we risk a joyless world of boring, homogeneous visualisations? — Goof van Winkel

Goof concluded that rules, because everyone interprets them differently, leave enough room for creativity. However, I’m not sure if Tufte would agree. Edward Tufte has had a major influence in data visualisation and, for that alone, he is a must-read author. However, some of his rules leave little room for interpretation. In Envisioning Information,Edward Tufte describes a couple of principles. One of those principles is ‘chartjunk:’ every chart should be stripped down to the minimum, to show just the data and nothing else. One of the chartjunk examples in his book is a well-known graphic by Nigel Holmes from Time Magazine in 1982.

Tufte proposes a corrected, stripped-down version where only the data is shown. Here is my version of what a stripped-down version could look like:

Tufte writes:

Chartjunk promoters imagine that numbers and details are boring, dull, and tedious, requiring ornament to enliven. — Edward Tufte, Envisioning Information

That probably makes me a chartjunk promoter because that looks like a joyless graph to me, even though it is easier to read the data. From a readability point of view, Tufte is right, but the original chart is a lot more memorable than the stripped-down version. Some charts do need some form of ‘ornament’ to engage an audience, especially when the audience lacks data literacy. It’s this target audience that I often miss in the equation. The rules you follow and how rigid your interpretation, really depend on who you are designing for and for what reason.

Paradoxical rules

As if being devoid of joy and leaving your audience behind aren’t reasons enough, sometimes it’s even impossible to strictly follow the rules. In fact, some rules, like Tufte’s Lie Factor and Baseline Principle, are contradictory.

The Lie Factor

A more elaborate account on the Lie Factor can be found here. In a nutshell, the Lie Factor is a formula with which you can calculate if a chart is misleading:

The recommended Lie Factor should be around 1. It’s an interesting concept with useful applications. Take a look at this example from USA Today:

Most people who know their dataviz rules see that this chart has a truncated y-axis, which is known to exaggerate change. The amount of welfare people have received seems to have increased enormously. The Lie Factor supplies us with an objective measure to show that, in reality, this change is much less dramatic. Consider the images below: the chart on the left contains a corrected version with a Lie Factor of 1, while the chart on the right reflects the original version with a Lie Factor of 16.08.

Now that I have measured the ‘lie,’ I can conclude that the demonstrated increase in received federal welfare is grossly overestimated in this chart. 

But, what if I turned this viz into a line chart, a common representation for time series?

The Lie Factor is the same, but somehow the corrected version on the left seems a bit off. That’s where the Baseline Principle comes in.

The Baseline Principle

How should you visualise a change in the data that is relevant, but barely visible when you visualise it? If you rigidly stick to the Lie Factor rule, you are not allowed to show this change by truncating your y-axis. Luckily, Tufte addresses this on his website:

In general, in a time series, use a baseline that shows the data, not the zero point. […] don’t spend a lot of empty vertical space trying to reach down to the zero point at the cost of hiding what is going on in the data line itself.— Edward Tufte

Let’s look at another example to show why this Baseline Principle is important, using this line chart of the average annual global temperature:

This chart has a Lie Factor of around 110, while it should be around 1. This chart ‘lies’ according to Tufte’s Lie Factor. Is this line chart really that misleading? According to Steven Hayward, it is. Hayward is an American author and political commentator. In 2015 he criticised these types of global temperature line charts for not starting at zero. He published a corrected version, accompanied by his view that global warming is a hoax:

If you calculate the Lie Factor for both charts you can see that Steven Hayward is under representing the change a little as well, but compared to the Lie Factor of the original graph, his version is a lot closer to the desired 1.

Following Tufte’s Lie Factor, Steven Hayward is right for criticising the line chart. His flat corrected chart, where global warming is barely visible, should be preferred. Still, I dare to say, the graph on the left shows the data more appropriately than the corrected version. Although it’s a small change of just a couple of degrees, it’s an extremely relevant change considering the subject matter. This change should be visible, not hidden because of a rigid rule that a vertical axis should start at zero. Furthermore, there are cases where the zero point is somewhat arbitrary, like temperature. A graph with the same data in Celsius or Fahrenheit would look different just because the zero points of these measuring systems differ. Sometimes it just doesn’t make sense to start at zero.

But wait, what about the Lie Factor that was sky high? You now have a Baseline Principle and a Lie Factor that can’t both be right for this chart. Is there’s a way to reconcile the two? Or maybe the Lie Factor does not apply for time series? There was a time when I tried to solve this paradox by allowing it for line charts, but not for bar charts or area charts. For the latter two, you fill the area below and with that, you visually imply a baseline at the bottom, where the fill ends. In those cases a zero baseline seems necessary. In the Federal Welfare example, although the Lie Factor is off for both charts, for the line chart that would be okay, while for the bar chart it would be misleading:

However, what both charts show is still quite similar: there was a sizable increase in the amount of federal welfare that was received. In other words, is the bar chart really more misleading than the line chart? Some argue that line chart should have a zero baseline when there is a ratio scale (where 0 means that there is a total absence of the variable you are measuring). However, that could still lead to the undesirable situation where relevant change is hidden because of these rigid rules. 

Another solution I came up with is to treat it like a spectrum with the Lie Factor in one hand and the Baseline in the other hand. Every designer should decide how much they can deviate from the Lie Factor to justify a Baseline not starting at zero and the other way around. 

But maybe I shouldn’t try to solve this paradox at all. It exists in the first place because I am trying to follow these rules to the letter. Rules are only useful when you use them with the applications for which they were invented. The Lie Factor was developed to show data in proportion and to prevent distortion by manipulating axes. The idea behind the Baseline Principle is that relevant change should be visible, when you are showing change over time, for instance. Look at the data, the context of the data, and your target audience to determine what rules might be most relevant. And feel free to ignore rules altogether if you find a better way to represent the story in the data.

Unfortunately this won’t help you in a discussion with Steven Hayward, because he can argue he followed Tufte’s rule. Fair warning: if you break the rules yourself, it might lead to criticism. However, it will help you to become a better designer, consider the rules, and be able to justify or defend your choices. It is our job as data visualisation designers to tell the stories that are in the data, show them in context, and engage our audiences. In fact, I encourage you to use a pie-chart once in a while, add some chartjunk if that helps to engage your audience, and even truncate a y-axis to show relevant change if you dare.

The post The Lie Factor and the Baseline Paradox appeared first on Nightingale.

Looking at the wide range of contemporary board games presented there, I couldn’t help noticing how much board games have in common with data visualizations. In fact, at their core, all board games are data visualizations. Data and information are visualized as pieces of different colors and shapes (called meeples) placed on boards specifying coordinate systems. The rules of the game determine how the current situation of the data can be transformed into a more desirable state.

Board game players are willing to pay 30–50 € for standard games, and well over 100 € for elaborate expert games. Players spend hours and hours poring over these visual representations of data. That is a degree of user engagement that would be great to also achieve for data visualizations.

The good news is that many of the elements that make board games so engaging, fun, and accessible, are equally applicable to data visualizations. In the following, I will discuss a few such points. Board games use easily readable data encodings, use overarching plots and metaphors, have graphic design that fits the topic, and represent the data in physical form.

Board games tend to use easily readable encodings of data. Categorical data is usually encoded via color hue and shape. This goes, for example, for the different kinds of meeples controlled by each player. Numerical data is usually encoded via location among common axis, number of elements, and size of elements. Board games seldom include more difficult to discern encodings like shades of a color hue (light to dark) or orientation. Using them would quickly result in misreadings and confusion.

The table shows the encodings used in traditional and contemporary board games. The game of Go uses the simplest encoding with black and white stones (interpreted as categorical color hues here although factually color shades) placed on a grid (position). Modern games very seldom use further encodings beyond those already used in the game of Monopoly, first patented in 1904.

In data visualization, if the intention is to get information clearly across, easily readable encodings should likewise be used. The experimental encodings of data art play a very important role in extending the boundaries of the genre. But for many, such elaborate encodings pose a barrier to understanding. I personally have to admit to often skipping elaborate data art if it is too tiring to decode.

Board games make use of overarching plots and metaphors to integrate masses of complicated information. Typical settings of board games include medieval trade, fantasy adventure, armed conflict, and science fiction exploration. The setting provides the information encoded on the board with an easy to understand and memorize mental model. Entirely abstract board games are much rarer. Chess is the most popular abstract strategic board game in the western world. In 1924, Bauhaus designer Josef Hartwig created suitable abstract pieces for the game. The forms reflected the movements of the pieces. These did not catch on. Today, chess still uses the metaphor of two armies with knights and bishops maneuvering against each other to kill the other’s king. The human brain craves tangible plots and metaphors.

Over the last few years in data visualization design, there has been a strong trend to move from presenting rational arguments towards telling emotionally involving stories. This was especially initiated by Cole Nussbaumer Knaflic’s 2015 book “Storytelling with Data.” Narratives integrate lots of individual data visualizations into a whole to make a clear point. The narrative also makes individual facts much more memorable. A good story usually consists of a three-part structure with introduction, conflict, and resolution of conflict.

Board game publishers go long ways to make the graphic design fit the topic. Often the general mechanism and layout of board games are designed by one person (the board game designer/author), and the final illustrations done by a professional illustrator, who sometimes remains unnamed. Illustrations, color palettes, and fonts are chosen to reflect the content.

A wide range of illustration styles are used from rational flat infographics to realistic and very artistic styles. Photographs are rarely used as image material in board games. One reason could be that the use of somewhat abstract illustrations and icons makes it easier to remain in a mental state of imagining and abstract reasoning. In Germany, there is even an award solely for the visual design of board games, the Graf Ludo. If something is beautifully designed we are much more willing to invest time understanding and engaging with it.

Data visualizations can equally be made more enjoyable by using a graphic design language that fits the topic. Header fonts can be chosen to go along with the topic. Color schemes can set the general mood of a visualization. Integrated illustrations and icons can serve decorative purposes. Many good examples of this can be found in the Tableau Ironviz qualifier Dashboards (not in the quickly prepared finals).

Part of the fun of playing board games is to have tangible objects before you. The quality of the game material plays a big role in the enjoyment of a game. Usually, cardboard, wood, and plastic are used. It is nice to touch and literally walk around visual representations of information.

Most data visualizations are pure digital products for the screen. But for workshops, showrooms, and conferences it can be worthwhile to bring a visualization into the physical world. A low-level method is to print a (static) data visualization out as a large poster. Today, there are many possibilities of turning digital graphics into physical objects by 3D printing plastic, laser cutting plywood, or laser engraving on plastic, metal, or glass. If one is willing to put in some manual work, the possibilities are endless.

In this article, I have demonstrated how many elements that make board games so engaging can also be applied to data visualizations. The points discussed in this article are the use of easily readable data encodings, the use of overarching plots and metaphors, the use of a fitting graphic design, and the physicalization of the visualization. These are the more static aspects of board games. Further discussions would be warranted for the social aspects, the interactivity (think interface design), and the gratification and rewards integrated in board games (think gamification).

After a long day, I left the board game trade fair with lots of new ideas and inspirations. To me, it is clear that data visualization designers can learn quite a few tricks from board game designers and illustrators. But the inverse also holds true. I’ve seen quite a few board games that could have been improved with basic data visualization know-how. And it makes me think: “How would a board game look that was designed from the ground up by a data visualization designer?”

The post What Board Games Teach Us About Data Visualization appeared first on Nightingale.