Linking tables to their associated bar charts

One of the shortcomings of stacked bar charts can be overcome by allowing users to choose which category is aligned to the chart's baseline. This article describes one possible implementation of that solution.

Stacked bar charts

For the purpose of this article I’m going to be using a real world example, specifically a stacked bar chart designed to show the number of aircraft of each type e.g 737-800, A320-200 etc. in an Airline’s fleet, categorised by the aircraft status i.e. In Service, On Order, and Storage. This ‘fleet breakdown by type and status’ is essential when trying to understand the composition of an airline’s fleet.

A screenshot showing a horizontal stacked bar chart, each bar represents the total count of aircraft of a specific type e.g. 747 etc, each category in the bar represents the count of aircraft with a specific status e.g. on order, in service etc.
The fleet breakdown for American Airlines (as at 4 Mar 2022 - Source: Cirium Airline Profiles).

The chart above [fig. 1] shows the Fleet breakdown for American Airlines. This chart enables us to:

  1. Determine the total aircraft of each type e.g. ≈300 737-800.
  2. Determine the relative difference in total aircraft between types e.g. ≈80 fewer A321-200 than 737-800.
  3. Determine the relative differences between statuses within a type e.g. More than ½ of the 737 Max are On Order.
  4. Easily compare the number of In Service aircraft across the different aircraft types.
  5. Compare (but not easily) the number of On Order and Storage aircraft across the different aircraft types.

The problem with stacked bar charts

The main problem with the list above is №5. Although it’s possible to compare the number of On Order and Storage aircraft across the aircraft types, it’s not easy to do this comparison well. The In Service category is on the far left i.e., it touches the chart’s baseline, whereas the other statuses typically don’t. For example, which aircraft type in in the chart above [fig. 1] includes the highest number of Storage aircraft? It’s like trying to compare the height of individuals in a group when everyone is standing on a box of different height.

Possible solutions

Filtering

This stacked bar chart was taken from an online application that includes the ability to filter by status. So one solution is for the user to filter the data by the status of interest. e.g. On Order. This would make the chart far simpler (it would no longer be a “stacked” bar chart), and make a comparison of the number of On Order aircraft across the aircraft types very easy, but, you’d lose the context e.g., is the number of On Order large or small compared to the number of In Service?

A screenshot showing a horizontal bar chart, each bar represents the total count of aircraft of a specific type. Unlike the previous image, there are no categories in this chart, i.e. it only includes aircraft with a status of on order.
The same fleet summary but filtered by On Order aircraft only.

Choosing a ‘primary’ status

Another option would be to allow the user to select which aircraft status is aligned to the baseline. What we’re really asking the user to do in this scenario is to prioritise one of the aircraft statuses over the others, i.e. to select one of them as being of ‘primary interest’. This isn’t a typical request we make of users when asking them to interact with charts, there’s no convention to ask users to “choose their most important category”. But, there is with tables…sort of.

Often, when presented with a table of data, users will sort the column of data that’s of most interest to them. There’s no filtering going on (although previous research has shown that when users are asked to filter a dataset that’s presented in a table, they will often sort a column, rather than actually apply a filter), so there’s no loss of context.

For Cirium Airline Profiles (the product where the stacked bar chart above is used) each stacked bar chart has an associated table of data, and both the chart and table are always visible (initial mock-ups included options where the user could toggle between table and chart, but there was a strong user preference that both should be visible at the same time.) With table and chart always visible, it opened up the possibility for some linking between the two visualisations i.e. for some table interactions to directly affect the chart.

Linking a data table to its associated stacked bar chart

In the animation below [fig. 3], each table column header is selected in-turn by the user to be sorted i.e. Total, Storage, On Order, and In Service. When a specific status in the table has been sorted (or “prioritised” by the user), the stacked bar chart is adjusted accordingly i.e.:

  1. the sorted status is moved to the chart’s baseline
  2. the bars are sorted to match the sort order chosen in the table
  3. the status category colour is emphasised (and the others de-emphasised)

The result is essentially a bar chart within a stacked bar chart. It retains some of the simplicity of a non-stacked chart [fig. 2] while not throwing away the useful contextual data.

The link between the table and chart is further emphasised by the fact that each bar in the chart aligns horizontally with its associated row in the data table (in the image below [fig. 3] the chart and table are stacked vertically, this view is used on tablets and mobile, the desktop view has the visualisations side-by-side.)

An animated GIF showing the same stacked bar chart displayed in the first image, but this time the user is clicking on the different statuses e.g. in service, on order etc. and the categories in the bar chart are shifting to the chart’s baseline depending on the selected category.
Table-sort choice, and its effect on the linked stacked bar chart.

Conclusion

The solution described above, and which we implement on Cirium’s Airline Profiles is not perfect (the colours specifically need to change), but I do feel that the solution does go some way to overcoming one of the issues with stacked bar charts. I wouldn’t describe this feature as essential, but I’d like to think that it’s one of those “micro-interactions” that might bring a small moment of delight to some of our users.