Publish an intelligible first state
The first view should communicate a meaningful finding before anyone touches a control. A blank chart with several unselected menus transfers editorial responsibility to the reader. Decide which period, metric and comparison best orient the intended audience. Name those choices in visible text so the default looks deliberate rather than arbitrary.
Ben Shneiderman's overview-first, zoom-and-filter, details-on-demand formulation is a useful design reference, not an obligation to implement every stage. Some stories need only an overview and one annotated detail. Others benefit from rich exploration. The important question is whether each additional operation supports a reader task that the simpler version cannot serve.
Make the state readable
A selected team, time window or metric should remain visible after the interface updates. Put units close to values and show active filters in plain language. When several controls interact, explain their relationship: does selecting a player preserve the time window, or reset it? Unexpected resets make readers doubt both the interface and the analysis.
Separate a genuine zero from missing data and from an empty filter result. “No recorded attempts in this selection” differs from “location data unavailable.” Neither should silently become a blank plot. Empty states are part of the explanation, and their wording should be reviewed with the same care as the main headline.
A small control with a defined task
This demonstration answers one narrow question: which illustrative events had occurred by a selected minute? It does not estimate momentum, infer possession or explain causality. The full table is the initial view. Move the slider with a pointer or focus it and use the arrow keys; moving it back to 90 restores all rows.
Illustrative regulation-time sequence only. No added-time model is implied.
5 illustrative events shown through minute 90.
| Minute | Team | Recorded event |
|---|---|---|
| 8 | North | Attempt wide |
| 22 | South | Attempt saved |
| 43 | North | Attempt blocked |
| 61 | South | Attempt wide |
| 78 | North | Attempt saved |
Use native controls before custom machinery
HTML buttons, selects and range inputs already provide familiar interaction patterns. The WAI-ARIA Authoring Practices Guide is useful when a custom widget is genuinely necessary, but adding ARIA attributes does not automatically supply keyboard behavior. A complex visual control needs tested focus movement, announced state and a clear way to leave it.
Hover can offer supplementary detail, but it should not be the only route to a value or explanation. Touch users cannot rely on a persistent hover state, and keyboard users need an equivalent path. If tooltips contain essential evidence, offer a stable selection or a visible detail panel rather than asking readers to hold a pointer over a tiny mark.
Protect comparison while exploring
When a filter changes, keep scales stable where practical. A chart that rescales silently can make a smaller number appear larger. If rescaling is necessary to inspect detail, disclose it next to the axis and preserve a route back to the shared scale. The interface should not reward exploration with a new opportunity to misread the data.
Transitions should help readers track continuity, not delay access to the answer. Avoid long sequences that must finish before another input is accepted. Respect the CSS prefers-reduced-motion setting and make the updated state comprehensible without animation. If data must load asynchronously, communicate loading and failure states without trapping focus or erasing the last valid view.
Design for the actual device
A desktop dashboard should not simply be squeezed into a phone-sized frame. Prioritize the central question, move secondary detail below it and allow tables to scroll inside their own containers. Keep labels readable and controls comfortably targetable. A compact interface is not successful if it requires precise taps or repeated horizontal navigation to interpret one comparison.
The MDN Web Docs references for Pointer Events and native form elements help clarify implementation behavior. W3C's WCAG 2.2 provides accessibility criteria that should shape testing. These resources support engineering decisions, but they do not replace observation of actual readers trying to complete the intended task.
Test comprehension, not just completion
Ask a reader to explain what changed after applying a filter. Can they identify the denominator, current period and important limitation? Completing a click sequence is weak evidence if the resulting interpretation is wrong. Test with keyboard-only navigation, touch input and magnification, and include readers who are unfamiliar with the sport's analytical vocabulary.
End by removing any control that produces a view with no useful editorial purpose. A strong interactive story is not a warehouse of possible states. It is a bounded explanation that gives readers enough freedom to investigate a question without abandoning context, evidence or their place in the story.