Common Visualization Missteps on the Web

An Article By Nick Walsh // 3.20.2020

Statistical visualization made its debut in the 1700s, but we’re still in the figuring it out phase in translating it effectively to the web. Reasons abound:

  • The underlying technology continues to evolve
  • Visualization experts and software developers don’t often overlap on a Venn diagram
  • Digital formats cede control of things like device size and context
  • The ability to add interactivity

Evolving technology takes most of the credit for the advancement we’ve seen in the last decade. With SVG as a cross-browser open standard (and HTML canvas soon thereafter), we were able to drop proprietary solutions like Flash and deprecated also-ran VML. This triggered a Renaissance of sorts for visualization tools and libraries, and gave web developers a reason to dredge up all of that forgotten trigonometry knowledge.

Demand can also claim a bit of that credit. We’re well into the era of big data, and insights behind complex lakes of information usually benefit from some sort of graphic. That’s especially true when dealing with deliverables like executive summaries, public policy, stories in media, and site analytics.

With the right amount of demand, and the capabilities to back the need, visualization is prevalent just about everywhere we look on the web. Like any maturing discipline, though, we see a handful of repeated missteps on the road to good data visualization.

Graph Choice

Picking the right chart is tricky, even for experienced practitioners. It requires balancing the type and amount of data, the space available, the audience’s visualization literacy, and a host of other considerations. Pie charts are the perfect example: They were everywhere, then considered harmful, then new research helped make them a conditional option. If you’re not actively following the field, it’s a lot to track.

The Most Effective Visualization is a Number

Sometimes, the hardest choice is not including a graph. Just because you can doesn’t mean you should; if the data can be distilled down to a number, there’s no clearer representation. If we wanted to talk about Orlando City Soccer Club’s (OCSC) win percentage for their first 5 years in MLS, a number is a powerful communication tool:

Sparklines, donut charts, and three-dimensional word clouds all look fancy, but effective visualization is all about removing visual clutter.

Tables Never Go Out of Style

Keeping with the number theme, it’s also worth mentioning our trusty friend: Table. Tables get a bad rap, but one that’s well-formatted is still easier to process than chart axes, relative volumes, and spatial arrangements.

If we were interested in breaking down OCSC’s win percentage for their first 3 coaches, a table comes in handy:

Choose a Chart Based on the Data

Once we’re dealing with too many numbers, or comparing amounts difficult for humans to picture (one million versus one billion), it’s time to go chart shopping. Making the right graph choice is like following a decision tree with the data details.

Back to our win percentages. If we still wanted to highlight wins, but also visualize draws and losses, we’d turn to a horizontal stacked bar:

Innovate Where it Makes Sense

In the right setting, adding complexity can provide useful context.

Ligonier Ministries conducts a survey (called The State of Theology) every two years, reporting on insights found in pairing religious views and demographics. For the Data Explorer, we stuck to a familiar bar chart concept, but added the component responses — a circle for each individual. Doing so helps visualize sample sizes, and shows how populations shift between questions.

Accessibility Underpins Good Data Visualization

Web accessibility is an involved process. For visualization experts picking up web development, or web developers picking up visualization, it’s something that tends to drop off the list.

Visualizations are Images

As a visual medium (it’s right there in the name, after all), visualizations need some extra care to help screen readers out — just like photographs. Unlike photographs, though, adding a bit of alt text generally doesn’t cover the need. Describing our stacked bar example above adequately would require several paragraphs.

There’s no catch-all solution for every graph and output type. For SVGs, markup tweaks are usually sufficient (after spending a bit of time acquainting yourself with current browser inconsistencies). Canvas is a black box. If it can’t be communicated with a sentence, providing a hidden table of the same data may make the most sense.

Color Choices

Choosing the right colors — especially the right amount of them — is another hurdle that many have trouble clearing. Take D3, the web’s most popular visualization library. Many examples out there use a built-in color scheme (Category10), which would make our stacked bar chart look like this:

Aside from disappointing designers everywhere, it’s also nearly indecipherable for certain types of color blindness:

That’s a lot of DrawLosses

When deciding on the right splash of color:

  • Use as few colors as you can. Needing an excessive amount to communicate information is a complexity red flag.
  • Make sure your choices meet WCAG contrast standards and are distinguishable for different types of color blindness.
  • Using green for expenses and red for revenue may be confusing — pay close attention to the inherent positive or negative connotations certain colors carry.

Labeling

In a bid to reduce visual clutter, tooltips often shoulder detailed data. It’s not necessarily bad, but they should be tested for keyboard accessibility, on touch devices, and with screen readers.

Picking a Chart

A visualization is useless if the audience doesn’t understand it (or have time to).

Bar charts, scatterplots, line graphs, and even pies — uniformity plays off users’ chart literacy. If the answer is something new or complex, you don’t have to start there. Building up to something bigger in pieces lowers the risk of an end product being written off.

Responsive, Like Everything Else

Like any other content on the page, visualizations should adapt to the size of their container. In the wild, we cede control of the devices and contexts users choose to view the end result, necessitating flexibility.

It can be difficult to find actual examples that do this well amongst the major libraries. Like accessibility, there are two core hurdles: It takes extra time, and the right way varies on a case-by-case basis. Options include:

  • Letting the generated image scale like a photo
  • Redrawing the graph (or parts of it) when the page resizes
  • Enable zooming, remove detail, or change the chart type outright

Even the charts in this article aren’t safe — as images, they become difficult to follow as the browser width decreases. Compare that to the Ligonier Data Explorer pointed out earlier. Here, we’ve set pieces up to redraw and resize as needed in either direction.

Adding Interactivity

Web visualizations’ killer feature is interactivity. Bringing our stacked bars back, it’d be trivial to communicate more information with a toggle that switches percentages with game counts:

There’s a catch, though: Explorative visualization takes extra time to make, and there’s no guarantee that users will even use it. The New York Times famously found that only about 15% of their audience took advantage of interactive elements.

Like everything else we’ve talked about, it comes down to a couple extra considerations:

  • Interactivity is great for engaged users, but don’t reveal your core insight through it
  • Making multiple points should start with multiple charts

We’ve seen success in splitting explanatory and exploratory charts into different portions of an application. In contrast to The State of Theology’s Data Explorerthe landing page presents notable findings in static visualization form.

Performance and Library Reliance

As a final word of web charting warning, beware the hidden magic of visualization libraries and frameworks. Understanding what they output (and how) is vital for troubleshooting performance issues, and deciding when to swap a library or change direction altogether.

Given a sufficiently large or complex set of data, we prototype early. For projects like Camassia’s Shipyard, these early stress tests led to format changes and custom options.

Tricky, Hard, Difficult, and Other Adjectives

In pairing two worlds largely characterized by context, web visualization evokes every synonym of difficult you can muster. Like learning to drive a manual transmission, it’s a skill that’s uncomfortable at first — but in the meantime, it’s important not to let the other core components of driving fall to the wayside.

As charts and graphs make their way into web applications everywhere, hold them to the same base-level requirements as the rest of your content. Accessibility, responsiveness, performance, and clarity are just as important (if not more) here.