The Complexity of a Simple Chart
A glimpse behind the curtain of the thought that goes into ensuring a chart remains simple
I was recently involved in an effort to create an internal web presence for the internal service my team is working on. We want to take the time to advertise to our colleagues what work we do, what specific services we offer, and how they can take advantage of our services.
I’m going to walk you through the in-depth thought process that led me from the chart on the left to the chart on the right
It got me a little excited, so I reached for my favourite tools (HTML, CSS) to create a simple design that captures “the necessary” and “the minimal”. As I sat back to see what I had come up with, I realised it was going to be hard for my customers to appreciate what went into the design.
Most people see a lot of activity as a lot of work. Most people don’t see what goes into keeping a design simple. I wanted to share all the work that goes into keeping it simple and informative.
For just a moment, I wanted to share just how deep the rabbit holes can go.
💡 TIP
Throughout you will see screenshots of the chart as it evolves, they are all links to a JSFiddle that shows the underlying code changes
In the introductory ITIL Foundations class taught to many organisations, one of the major things that is repetitively highlighted is the need for clear, transparent, communications with customers. In particular, the need for an “is it up” dashboard for your services always stood out for me.
The reasoning and benefits seem obvious to me:
- Reduce labour by preemptively notifying customers: The most important thing a person can be doing in the event of a service failure is repairing the service. Having customers, or managers, continuously asking if the service is available reduces the time spent understanding the problem. By notifying customers from a known, predetermined board, we are able to have them self-serve their questions, leaving technical experts to focus on solving the problem; by auto-generating it, we reduce the burden even further.
- Don’t disrupt people that don’t care: Signal-to-noise is a real problem in organisations. Rather than actively notifying, a pre-published board allows those with a concern or interest to look up the information. Still, for those not actively using the service (perhaps working with a non-impacted portion of the system, perhaps not in the office that day) there is no need to interrupt them, allowing those experts to focus on the problems they are solving while remaining blissfully unaware of other issues. This has the added benefit of not advertising your failures to people that weren’t impacted.
- Advertise your successful services: A standing board of “status” not only shows failures but also a complete list of successes. Most of a board, most of the time, will show a healthy system; even when a portion of the system is failing, it will show that this failure is only impacting a small proportion of what is otherwise a successful service. Letting customers see that while it’s bad, the service is generally reliable can help with this. This has the added benefit of letting customers know about other parts of your service. While your system is healthy, this is a complete menu of all the services you offer; either to be indexed by a search engine, to be pointed to during meetings, or to be naturally discovered by customers.
There is obvious value in having an online, automated, report of some kind; though, naturally, we see it taking different forms depending on the nature of the services involved. Power companies show outage maps, online services show “up time”, and data feeds show tables of API endpoints.
Initially, my team started by bringing forward various reports that individuals had already constructed for observing their individual aspects of the system, and proposing them as something worth sharing. These got presented, one after another, describing the benefits of each, and evaluating their use by our users. After myself and a couple of others had sown our most valuable reports, our manager asked, the question “How do people know its fit for use?”
What is “fit for use” in the context of our system? More importantly, how was the data that we had presented, that I had presented, not expressing that to her?
This question nagged at me through the rest of the day.
That evening, I opened Kate and started typing.
Aside: Defining the Problem
For a working example of the type of system we are dealing with, we need to start by defining the type of service we are offering.
We have a diverse variety of datasets that we ingest into a central repository. This data is standardised and then published back to our customers for use in their research. To give us a working example, let’s take the flow of a couple of hobby projects of mine: imagine something like one of the financial websites that offer data about stock prices. This data needs to be collected from government filings (eg. SEC, SEDAR) and also trade data from the various exchanges (eg. NYSE, NASDAQ, TMX)
Data is ingested from the various sources I can find, standardised in their format, and then various views of that data are used for various analyses by users (human, reports, or AI).
Overwhelming the Viewer
Many years ago, I became enamoured with the idea of Test Driven Development. On the projects I led, I found it was an excellent way to define business requirements, and then communicate those requirements to a diverse group of individuals. Varying interpretations simply led to discussion and a very clearly defined expectation (updated test), which was then immediately distributed to the group (shared unit tests).
Coming from this background, I tend to immediately develop a set of tests, in whatever test framework is available, for observing any system I am involved with, whether that’s from a development, operational, or DevOps, perspective.
For 4 datasets, we run 3 checks, resulting in 12 rows. That’s a lot of information being thrown at the user; the poor person is going to be faced with significant cognitive load, or as I like to call it: “THE WALL OF TEXT”.
The text used, while descriptive to me (monitoring the system) requires more context to be useful to someone. The numbers presented are very busy, of varying scales and unformatted, making them meaningless without thought. Placing the failures at the top was a good idea, but still requires a lot of thinking to determine what has been affected and whether we care (as a user).
We can either
- engage in a training program (failure of intuitive design),
- add more text (making
THE WALL OF TEXTproblem worse), - or maybe we now begin to understand why a simpler solution is needed
We did do a couple of things correctly, failures are at the top putting “interesting” results more prominently, there is an overall summary in the title, and the effective date is important. Unfortunately, there is a lot that needs work.
Starting Over
So this is where me and my text editor start over.
We are looking to create a chart that expresses whether “a dataset is fit for use”.
- dataset (thing)
- fit for use (state, boolean)
Users are only confronted with 4 elements (1 per dataset) and the amount of text to be interpreted. The text could use a little work, but a user will likely know what datasets concern them: users only interested in US stocks will know US market abbreviations and therefore that they don’t care about the ones they don’t know. It could probably be presented more aesthetically, but this is probably the minimum meaningful set.
Order and Limit
Given hundreds of datasets, it may not be feasible to show all of the items on a single pane. The chart should maintain visibility of the top 5 items with the option to scroll for more. It is estimated that a worst-case scenario of simultaneous expires is approximately 3 items so 5 allows for the human to see a naturally occurring comfortable group size, with some successful items at the end offering the knowledge that the end of the error list has been reached.
💡 TIP
Keep lists between 3 and 5 items.
While we are at it, instructions (lines of code?) should be between a half a dozen and dozen items. If you are metric, use fist-fulls (5 to 10 fingers).
Based on experience, and a few introductory Sociology and Psychology classes, this appears to be a natural human thinking scale.
States
There are different reasons a dataset could be “not fit for use”, and some of those reasons a user may or may not care about
- Bad structure
- Incomplete set
- Invalid content
- Stale
A little further analysis offers a tip: if we can detect an error, don’t give it to the users. Therefore we don’t actually need to report bad structure since the bad structure will never end up in front of the user. Instead, we won’t load the dataset, this will leave it “behind” or stale. So a “bad structure” isn’t an error, it just never arrives (making it late).
Stale becomes our primary error state.
There is a third state worth mentioning. I hate mentioning an error while I’m fixing it. So I like to advertise that I am in the process of fixing it. A third state of “updating” is important.
- Valid: Everything is OK
- Refreshing: We are in the state of updating the data
- Expired: It has exceeded its shelf-life
- Error: Something is really wrong. Something we have never considered before
Order matters. We always want the most significant item near the top of the list. This allows people to focus on information that is important and ignore information that can be ignored.
Iconography
Unfortunately, between our error messages and multiple states, we have achieved a WALL OF TEXT again. So much so that we had to add table lines just to make it legible. Any time you have tables of text, you have done something wrong.
Language is also a problem with any text. The internet is an international tool taking communications far and wide. Companies I have worked for have required me to accommodate Spanish, French, and Russian. Any time we reduce the text, we reduce the need for translation.
Our status’ can easily be changed communicate via colour and icons.
Unfortunately, imagery can mean different things to different people especially when crossing cultures, it can also be expensive to purchase, and is subject to people’s aesthetic opinions. Further, those with visual impairments may not be able to interpret the meaning of an icon
Fortunately, we have an international standard of characters that can be used to display the status the Unicode standard identifies all the characters you see on your screen, and include a collection of iconographic sets that we can take advantage of. These icons are available on all computers and have standardised meanings behind them. As long as we choose reasonably correct icons, even screen readers will be able to interpret them.
- ✅ Valid
- 🔄 Refreshing
- ⏰ Expired
- ⛔ Error
Colours are also a delicate subject. While most people reach for Red / Green / Yellow, based on our traffic light system, we know that certain colours can be difficult to distinguish from other colours. Culture also plays a role in that some locals use different colours to mean different things.
My general solution for this is to choose
- blue for “ignorable”
- red for “pay attention”
Pastels have also been identified as a safe shading for most colours.
Now that we are mixing colour and text, it is important to ensure we have a clear dividing line between text and backgrounds. It is important to have light text over dark colours or dark text over light colours.
💡 TIP
You will get the colour differentiation between text and background wrong eventually. Things just won’t line up. As a safety, I like to take an old trick from subtitled movies: use white text, and give it a black boarder. In HTML we can achieve this with a glow effect.
While no iconography or colour palette is perfect, by using HTML and Unicode it is both quick to deliver and simple to change, while still getting reasonable results. Also, by keeping the iconography simple, it is simple for people to learn through practice.
By moving the icons between the error message and the dataset label, we also create a dividing line between them, reducing the need for guidelines.
Using icons and colour we have reduced the cognitive load by reducing the number of symbols a user must interpret to derive meaning. We have also introduced multiple paths to success, using standardised technology, to account for diverse observer needs.
Timeliness
Don’t get distracted!
Remember that our focusing description is “fit for use”. What really defines our dataset’s fitness for use?
Having looked at our error messages and statuses, the recurring theme is the expiry date. Different data changes at different rates, and each piece loses value to the users as it ages.
Obviously, price data from a month ago is less meaningful than price data from a minute ago. On the flip side, corporations don’t change their Senior Executives that frequently, and someone studying the interrelationship of Board Membership with corporate success may find that data refreshed within the last year is good enough for their purposes.
Another consideration might be that waiting for the next load may not be far away and therefore is worth waiting for; if a dataset is expected to be refreshed quarterly, and tomorrow is the expected refresh date, it may be worth putting off the build of your analysis for a couple of days.
Each dataset, therefore, has a refresh frequency associated with it, as well as a last date updated.
💡 TIP
Don’t pull the dataset’s “last updated” from “now” (the moment you physically process the data). Rather try to use some feature of the data itself to determine how up to date it is. In a perfect world, we would mark when the record was created; not the local copy’s creation date, but the date the datum came into existence.
By checking the data itself for an updated date you can account for your upstream provider having an issue as well.
Its not good if you process the same, unchanged, dataset over and over again.
Knowing how close a dataset is to changing state is our core definition of “fit for use”, but we find it is not a boolean or ordinal value, but rather a unit interval where the unit is the size of the expected time.
That’s a long way of saying we can create a countdown for every state.
Rather than very busy error messages, we have relied on the icon to give context and then supplied a countdown/progress meter to help the user understand how the data they are interested in is impacted.
Every state has a countdown of some kind
- Valid: shows how long until the data is expected to be renewed.
- Refresh: gives an estimated time to completion
- Expired: demonstrates a sense of how bad the overrun is
The meter gives the observer a visual sense of completeness as a proportion; while a textual representation gives a sense of scale for the whole and a reasonable time frame for when a user can expect a change. As these are estimates, times are given only in the major unit with a broad fractional unit (quarters and thirds) to prevent a false sense of precision. The supplied meter can help a user decide if the indicated time is one worth waiting for (99% fresh vs 1% fresh).
While not an approved format, the unit of measure conforms to the units expressed in ISO-8601. Using an international standard is intended to maximise the reach to an international audience. The exact ISO-8601 specification is used in the underlying computer-readable component of the text to accommodate computer-aided comprehension (screen readers).
<time datetime='PT8H34M10S'> 8 ½ h</time>
The meter and time are abandoned for overruns to avoid a reverse meter causing confusion, and because it is possible for data to overrun by multiples of our unit interval. For example, an upstream issue could cause a 15-minute refresh to be out for hours resulting in 413% overruns. A percentage allows users to decide how significant it is to them as a 0.5% overrun on annual data, may not be considered significant at all.
An Aside: The part I’m embarrassed to show
- another
WALL OF TEXT - Negative Space
Normally I would not show this transition in the chart, there are some critical things that I kind of skipped over. They are ugly and I don’t normally like to advertise my crappy ideas, but in this case, I wanted to take a moment to talk about them.
I want to show how these issues can be spotted, and what they look like while you are working on them.
As our chart has been progressing, I have talked about the WALL OF TEXT and we can see that we have one creeping into the design. The error messages do not present a lot of meaning and will require translation to accommodate a multi-lingual audience (expensive and time consuming). Those countdown timers are even worse.
What you are looking at is are my personal attempts to resolve THE WALL OF TEXT issue while at the same time accommodating a diverse audience.
maybe we can use decimals?
- How many decimals do people care about?
- What unit of measure should we use? Seconds? Minutes? Months?
- What languages do we use to express the unit of measure?
Maybe we can use the International Metric Specification for Time Formatting (ISO-8601, CSA-Z234.4)
- The units and symbols are defined internationally
- It can be interpreted by digital tools (screen readers)
- … but it has very dense, unreadable, text
So we definitely have at least one problem that we are in the middle of working through. Working through results like this is part of the editorial process.
The end result (shown above) was a compromise between these two formats, but I wanted to show that it would not have existed without this middle step.
There is also a problem of “Trapped Negative Space”, or the space we aren’t using on the chart. (h/t Sharon Cave for drilling this into me)
The obvious problem with Trapped Negative Space is that it is unused. Space requires resources to fill, either it is space that another chart could have used, or we could even talk about the carbon emissions associated with the screen space. We are always making decisions about including or excluding information, and including negative space means we have implicitly excluded something.
Excluding important information, because we ran out of space, is just unfortunate.
Generally, we don’t consciously think about negative space, but subconsciously our eye is drawn to it: it’s different, out of place, something should be there, nature abhors a vacuum. This should be used to bound objects, but trapping it creates false boundaries that the eye follows.
In the development of a chart, we want to communicate significant information to people. Humans are a species with strong pattern recognition capabilities, we can use uniformity to draw the eye away from things that are insignificant. This act of creating a uniform baseline allows for the differences to stand out.
In this case, the Trapped Negative Space breaks the pattern we are trying to express. As I have heard in many a design class “If you highlight everything, you have highlighted nothing”.
If you highlight everything, you have highlighted nothing.
— Sharon Cave, Sharon Cave Fine Art
If you see Negative Space, just like with THE WALL OF TEXT, you have done something wrong, and need to refine what you have done.
In this case, it was noticed that the negative space was nicely checker-boarded. Errors do not have meters, and successes have meters but do not have text. It was a simple step to simply collapse the interlocking space.
Next Steps
This looks to me to be a reasonable chart for expressing the ideas that we want to share with our customers. It is as basically accommodating of diverse biological and digital users and is concise enough to convey information quickly.
This is a good start.
This was only a wireframe and a quick sketch to help get a feel for the data that should be presented to users. For example, that header has a lot of Negative Space just screaming to be moved around, and the black grid is overly contrasting drawing the eye away from the information.
Visually, this chart needs a lot of work.
- Marketing design: this has not even begun to integrate with corporate look and feel. A look at the overall design of the parent containing reports is necessary
- Accessibility: while it has worked to stay constrained to basic accessibility, a deeper look into this by specialists is necessary
- Translation: there is some text, and elements of the text will need to be translated into supported languages
- Peer review: this is representative of a single day’s work, and has not seen a review from peers that may express concerns within our domain
Having said that, the changes that will be suggested by these various groups will address aesthetic reasoning. During the design process, we have been careful to minimise the overlap between the design and data concerns. The data is rendered as a simple table with formatting being controlled separately. This means that designers can drastically change the design without significant changes to the actual data produced.
Again, not perfect, but an eye to future cooperation is always necessary, and being open to their suggestions (or sometimes outright changes) can be a wonderful learning experience.
Animation
I remember reading an article by Mike Bostock in which he described the value of having sorted graph bars slide to their new position when they needed to be changed. Humans see motion and fixate on it, and watching a chart item change position helps us comprehend the change that takes place.
This chart (a horizontal bar chart) represents the exact scenario he was describing. We order items by error state (most significant at the top), and using animations to draw attention to changes in order would draw attention to a significant change in state.
Summary
We were asked “How do users know the dataset is ‘fit for use’?” and I think we have achieved that, but we’ve gone much further
- We have created an advertising list of all our services
- “Fit for Use” is estimated but left to the user
- It is accommodating of various user needs offering multiple success paths
- Information density is high, but not overwhelming.
- The reduced text allows for it to be used multilingually
- Design and Logic have been separated as concerns for easy collaboration
Not bad for 4 hours after supper, and (frankly) a lot of fun.
I’m hopeful that this cart will make its way in front of our users; I think it will help make our service more visible to new users, offer a lot of information to our current users, and free up the team’s time from a lot of status reports.
Ironically, the day after I first presented this report (and wrote most of this post) a colleague gave a presentation on how we present information to users. In it, they emphasised the need to meet the viewer where they are, and not over complicating the problem. From the online audience, I muted my microphone and burst out laughing. A brief chat between us after the presentation summed up our shared perspective:
Keep it Simple Stupid.
Unfortunately, that’s sometimes a complex thing to do.
Further Reading
There is so much great reading to be done on how we convey information to users
- The first stop for me was everything by Mike Bostock. Most famous for his work as a New York Times data visualist, he is also the inventor of D3 and Observable HQ. You should read everything you can by him.
- Fundamentals of Data Visualization, by Claus Wilke, is a must-read for anyone interested in visualisation and makes an excellent textbook for any classroom (it was my first choice)
- White Space is Not Your Enemy, by Rebecca Hagen, is a good introduction and foundation into the visual arts from a marketing perspective. This supplies the right level of general theory to apply across a number of visual disciplines.
- How to Lie with Statistics, by Darrel Huff. Huff focuses on how humans interpret (or misinterpret) numbers and how our expressions of those numbers can help, hurt, or misdirect, understanding.
- I’ve been prone to rants on related subjects over the years.
Most importantly, never forget that User Experience is more than just rounding the borders of the HTML, it’s about understanding the psychology, anatomy, and physiology behind our interactions with our users; so make sure you spend time talking to them to understand their experience.
