Field note · May 8, 2026
Charting sched_dep_hour by origin
Two facts about the columns decide the chart. Cardinality and skew, in that order.
Someone wants sched_dep_hour broken down by origin on flight-delays. Before choosing a chart, two facts decide it.
origin has 14 values, which is past what a bar chart holds. sched_dep_hour has a mean of 13 against a median of 13 — near enough symmetric that an average is representative.
So: sort descending, show the top eight, and put the rest in an explicit Other bucket. Not the top eight silently — the bucket has to be visible, or the chart claims a completeness it does not have.
A bar of averages is honest here, which is worth checking rather than assuming.
One y-axis. Colour by origin rather than by rank, so filtering a category does not repaint the others. And a table underneath, because someone will want the exact number and squinting at a bar is not a way to get it.
The thing to decide before any of that: what the chart is for. If the question is "which group is largest", a sorted bar answers it and a pie chart does not — angle is the hardest visual encoding to compare and the one most often reached for. If the question is "how much do groups differ", the bars need to start at zero or the difference is whatever the axis says it is. And if the question is "what does the distribution look like inside each group", bars are the wrong family entirely; that is a box plot or a strip plot, and no amount of styling turns one into the other.
With a roughly symmetric column, the mean-of-each-group bar chart is genuinely the right default. Most of the failures in this shape come from skew, and this column does not have much.
The chart builder enforces the mechanical parts — axis, palette, series cap, table view — which was the point of building it. It cannot enforce the first decision, which is the one that matters. Rules that live in a style guide are rules nobody follows at 6pm; rules in code are the ones that survive.