Multi-Resolution Dashboard¶
Display or reporting tool — instantiates Temporal Resolution and Sampling Rate Design
Presents one process at several linked temporal scales at once, so users can move between second-by-second detail and long-run trend without switching tools.
A Multi-Resolution Dashboard lays out the same process at several time scales side by side — say a live second-by-second panel, a minute view, an hourly view, and a multi-week trend — and links them, so that selecting a span in one view drills the others into that same span. Its defining property is that it holds multiple resolutions simultaneously and coordinated, rather than making the viewer choose one. That is what distinguishes it from every sampling-side sibling: it does not observe, adapt, gate, or compute the summaries — those happen upstream. It arranges pre-computed scales into one coherent, navigable surface and keeps them tied to a shared timeline, so that an operational user and a strategic user can look at the very same process at their own scale without ever confusing one scale for another.
Example¶
A site-reliability team runs a dashboard for a checkout API's latency. It shows four coordinated panels: a live 1-second stream, a 1-minute view, a 1-hour view, and a 30-day trend, all sharing a single time cursor. During an incident an on-call engineer spots a suspicious bump on the hour panel, brushes it, and the second-level panel immediately drills into the exact 40-second window where latency spiked — possible only because the raw traces from that moment were retained and every panel is pinned to one synchronized clock. Meanwhile the reliability lead reads the 30-day panel to judge whether the service is slowly regressing, and a capacity planner reads the same board at weekly grain. Three users, three scales, one process — and nobody argues about which time window is "the real one," because all of them are on screen and linked.
How it works¶
- Define the scale ladder. Decide which resolutions exist and why each earns a panel — every rung should serve a distinct user or decision, not just exist because the data allow it.
- Link the views to one timeline. A shared cursor and drill-through, so a selection in any panel resolves to the same instant in every other.
- Retain enough to drill. Keep raw or high-resolution data behind the coarse panels, because a drill-down into detail that was already discarded is a broken promise.
Tuning parameters¶
- Scale ladder — which resolutions get panels; more rungs cover more users but clutter and slow the board.
- Linkage behavior — shared cursor, brush-to-drill, or independent panning; tighter coupling aids investigation, looser coupling aids parallel monitoring.
- Retention depth per scale — how far back each resolution's raw backing survives; deeper enables older drill-downs at storage cost.
- Default landing scale — which view greets the user first, framing what they notice.
When it helps, and when it misleads¶
Its strength is that it lets operational, analytic, and strategic users coexist on one process without fighting over a single time window, and it makes the scale of every number explicit on its face. Its failure modes come from the multiplicity itself. The same data can tell opposite stories at different aggregations — a metric rising hour over hour can be falling day over day — an aggregation cousin of Simpson's paradox that a poorly-labeled board invites viewers to walk straight into.[n1] And a drill-down is a quiet lie if the raw data behind the coarse view were already aged out. The guarding discipline is to keep the scales linked rather than standalone, label every panel's resolution unmistakably, and retain raw data wherever drill-down is offered so the detail is really there when someone reaches for it.
How it implements the components¶
multi_resolution_view_map— its core: the explicit map of which temporal scales exist and how they link and drill into one another.raw_data_retention_horizon— drill-to-detail only works if the raw or high-resolution data behind the coarse panels are still kept.clock_synchronization_assumption— linked panels must share one aligned timeline for a selection in one to line up in all.decision_latency_requirement— each scale is routed to the user whose action latency it matches, from live incident response to quarterly review.
Does NOT compute the summaries each panel shows (aggregation_window_definition): that is rolling_window_aggregation. The dashboard displays and links scales that were already computed; it defines no windows itself.
Related¶
- Instantiates: Temporal Resolution and Sampling Rate Design — supplies the archetype's multi-scale viewing surface: several resolutions held at once without confusing them.
- Consumes: rolling_window_aggregation supplies the aggregated series each coarse panel renders.
- Sibling mechanisms: fixed_interval_sampling_schedule · adaptive_sampling_rate_controller · event_triggered_capture_gate · anti_aliasing_prefilter_or_smoothing_rule · rolling_window_aggregation · alert_cooldown_and_deduplication_rule · burst_sampling_protocol
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: The mechanism presents linked temporal scales through a shared cursor and drill-through so users can move between local detail and long-run trend.
Nearest alternative: Monitoring, Sensing & Alerting — Retained data populate the panels, but the mechanism is the navigable viewing surface rather than the detector of change.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Interactive overview, drill-down, and level-of-detail displays are an HCI lineage; data aggregation and statistical resolution choices materially shape them. This establishes human_computer_interaction as the primary origin lineage rather than merely a domain where the mechanism is now applied.
Related originating lineages:
- Data Science & Analytics — Linked views of one process at several temporal resolutions are established analytics and monitoring practice.
- Statistics & Experimental Design — Aggregation effects and time-series interpretation constrain valid cross-resolution comparison.
Review resolution: Authoritative/primary-source research resolves the conflicting primary-origin claims in favor of human_computer_interaction: Interactive overview, drill-down, and level-of-detail displays are an HCI lineage; data aggregation and statistical resolution choices materially shape them. Retained alternate origins (data_science, statistics_experimental_design) are limited to independently formative or materially shaping lineages supported by the reviewer evidence; downstream adoption alone was not promoted to origin. The breadth of present-day use is recorded separately as domain_reach=multi_domain. origin_mode=cross_disciplinary_synthesis, confidence=medium, and encyclopedia_synthesis=false reflect the surviving provenance evidence and the encyclopedia's generalization.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
- Shneiderman, The Eyes Have It — Primary HCI source for overview-first visualization, zoom/filter, and details-on-demand navigation across levels and resolutions.
Notes¶
[n1] Simpson's paradox — an association visible in aggregated data can reverse when the data are broken out differently. Its temporal analog is that a trend's apparent direction can flip between hourly, daily, and weekly aggregations of the same series, which is why a multi-scale board must label each panel's resolution rather than let viewers assume the scales agree. ↩