skip to content

A chart's legend labels a series in a colour the chart no longer uses — how does a legend drift out of step with its marks?

level: seniorimportance: should knowfreq 34%

answer

  1. where did the legend come from?
  2. derived guide against hand-written caption
  3. colours assigned by drawing order
  4. the empty series shifts every label

basics

~20 s

A legend drifts when it was not derived from a binding. Where colour is a mapped channel with a scale, the guide follows the mapping automatically. Where colour is chosen per drawing call, the legend is hand-written text and only matches until someone changes the drawing.

solid answer

~50 s

The question to ask is where the legend came from. Where colour is a **bound channel** — the statement that colour varies with a column, backed by a scale from values to colours — the scale owns its guide, so the legend is derived and cannot disagree with the marks. Where colour is a literal chosen at each drawing call, there is no scale to derive anything from: the legend is a separate list of labels, usually written in the order the author drew things, and it stays as written no matter what the drawing does. Three edits desynchronise it — adding a series, reordering the drawing calls, and filtering a series away so a colour is never drawn. The durable fix is to derive both the colour and its label from one explicit mapping keyed by the category value, so drawing order stops being load-bearing.

go deeper

for a junior

Recall that a legend does not always come from the data. Some are generated from the mapping between a column and a colour, and some are just text somebody typed next to the chart.

for a middle

Explain the mechanism: colours assigned in drawing order against labels written by hand, with nothing forcing the two to agree, so any insertion or reordering rotates one and not the other.

for a senior

Diagnose from the source rather than the picture, reproduce it by rendering with a reordered or short-one-category input, and fix it by removing the dependence on drawing order instead of editing the text.

for a principal

Make it a rule worth arguing for: nothing on a chart may depend on the order things were drawn in unless that order is the information, and a category-to-colour mapping is a shared artefact with an assertion behind it.

## The symptom, and what it is not A reader says the legend is wrong: the entry claims one series is a given colour, and that colour is either on a different series or absent from the picture entirely. This is almost never a data problem and almost never a rendering bug. It is a structural property of how the chart was built, and the first job is to find out which of two structures you are looking at. ## Two ways a legend comes to exist | | derived from a binding | maintained by hand | |---|---|---| | What decides a mark's colour | A scale mapping the column's values to colours | A literal passed at each drawing call | | Where the legend comes from | The scale, which owns its guide | A separate list of labels the author wrote | | What happens on new data | Both the marks and the guide are re-derived | The marks change; the labels do not | | Can the two disagree | No — one source | Yes, and nothing detects it | | What keeps them aligned | The binding itself | The author's memory of the drawing order | The important consequence is that **a legend's presence proves nothing about whether anything is bound.** In the second structure the legend is a caption, and a caption can say whatever was last typed into it. ## The three edits that break a hand-maintained legend 1. **A series is added.** The new drawing call picks the next colour, but the label list was written for the old set. Every entry after the insertion point now names the wrong series, and the picture still looks plausible. 2. **The drawing calls are reordered.** Nothing visible changed in the code's intent, but the colours were being assigned in draw order, so the mapping rotated underneath a legend that did not move. 3. **A series is filtered away.** The data for one category came back empty, so nothing was drawn for it — but its label is still in the list, and every subsequent label has shifted onto the wrong colour. This is the nastiest one, because the trigger is in the data and not in the code. All three share one cause: the colour is a function of *drawing order* while the label is a function of *what the author wrote*, and nothing forces those two functions to agree. ## Diagnosing it Do not start from the picture; start from the code that produced it. - **Find the colour.** Is it coming out of a scale attached to a column, or is it a literal on the call that drew each series? That single question decides which of the two structures you are in and therefore whether this bug is even possible. - **Find the label list.** If the legend entries are written out as text somewhere, that is the hand-maintained structure and the labels can be arbitrarily stale. - **Reproduce it deliberately.** Render once with the series supplied in a different drawing order. If the legend text stays put while the colours move, you have confirmed the cause without reading any more code. - **Check the empty case.** Feed the chart data with one category absent. A legend that keeps its full length while the picture loses a series is the third failure above. ## Fixing it so it stays fixed Editing the labels once fixes the screenshot and nothing else — the next edit reintroduces the same bug, which is why this tends to recur on the same chart for months. Two durable repairs, in order of preference: - **Bind the channel.** Where the design supports it, state that colour varies with the category column and let the scale produce the guide. The two can then no longer disagree, because there is one source for both. - **Where the design has no scale behind colour, build one yourself.** Hold an explicit mapping from category value to colour in a single place, look up both the drawing colour and the legend label from it, and key the lookup on the value rather than on position. Drawing order stops being load-bearing, and a missing category produces either no entry or a deliberately drawn absent one, rather than a silent shift. The second repair is worth stating as a rule the team can apply: **nothing on a chart should depend on the order things were drawn in unless that order is itself the information.** ## What an interviewer is listening for That you go straight to the source of the legend rather than to the data. That you can name the structural difference — a derived guide against a hand-written caption — without asserting that one of them is how charts work, because both are real designs in wide use. And that your fix removes the coupling to drawing order rather than correcting the text, because a candidate who fixes the text has treated a symptom and will see the same bug again after the next edit.

  • Why is a missing category the hardest version of this bug to catch?
    Because the trigger is in the data, not the code. The chart was correct when it was written and correct in testing; one day a category has no rows, that series is never drawn, and every later label shifts onto the wrong colour. Nothing errors and the picture looks complete.
  • Does binding the channel guarantee the same category keeps the same colour across two charts?
    Not by itself. A derived guide guarantees the legend matches the marks within one chart. Keeping a category the same colour across charts needs the mapping from value to colour fixed explicitly, otherwise each chart assigns colours from whichever values it happened to see.
  • How would you stop this class of bug from recurring on a dashboard-free reporting script?
    Make the value-to-colour mapping a single named object that both the drawing and the labelling read, and assert that every category present in the data has an entry in it. The assertion converts a silent mislabelling into a loud failure at render time.

saying these in an interview costs you the question

  • Blames the data rather than asking where the legend came from.
  • Assumes a legend is always derived from the chart's bindings.
  • Fixes the label text once and considers the bug closed.
  • Thinks reordering the drawing calls is a cosmetic change.
  • Believes every charting design keeps a scale behind colour.