# Detail on demand > A small panel needs to become a big one for a moment. - Canonical: https://patterns.konigi.com/dashboards/detail-on-demand - Group: Screenspace - Level: flow - Status: published - Updated: September 10, 2026 - Also called: expand panel, full-screen panel, side panel --- ## Problem One panel in a grid of twenty has something interesting in it. At a sixth of the screen the viewer can see that it moved and cannot see when, by how much, or which series. They do not want to navigate away, because the surrounding panels are the context. ## Solution Expand in place. The panel takes the full page, keeps its query and its time range, and closes back to exactly where it was. Shneiderman names details-on-demand as one of the seven tasks and the ordering matters: it comes after overview, zoom and filter, which is to say the viewer has already decided this is the interesting thing. The interaction's job is to be cheap in both directions, because it will be used dozens of times in a session and most expansions end in "no, not that one". Reversibility is the whole design. If closing is as cheap as opening, viewers expand freely and the pattern does its job. If closing loses the scroll position, resets the grid, or drops the time range, they learn not to expand, and the detail may as well not exist. The three common forms trade differently. **Full-screen panel** gives the most room and the strongest context switch, which is right for a chart with many series and wrong when the neighbouring panels are the reason you are looking. **Side panel** keeps the page visible and works well when the detail is a record rather than a chart—a log line, a host, an issue. **Inline expansion** pushes the grid down, which preserves the most context and disturbs the layout most, and is the option that most often makes the surrounding page unusable while open. The subtle trap is state. An expanded panel is a different view of the same query, and if expanding changes the interval, the aggregation or the series limit, the viewer sees something that disagrees with the small version they were just looking at. That disagreement is rarely explained and quietly undermines trust in both. ## Use when Panels are necessarily small, the page's arrangement is the context, and viewers need occasional close reading rather than navigation. ## Don't use when The detail belongs to a different subject. That is drill-down, and dressing a navigation as an expansion makes back behave unexpectedly. ## Trade-offs Expansion state rarely survives a link, so what you found is not what a colleague opens. It is nearly always mouse-driven, so touch and keyboard get a worse version or none. Modal expansions trap focus and are frequently the least accessible thing on the page. And the pattern lets teams justify panels too small to read on the grounds that they can be expanded, which quietly degrades the default view everybody actually uses. ## Checklist - Is closing exactly as cheap as opening? - Does closing restore scroll position and grid state? - Does the expanded view use the same query, interval and time range as the small one? - If it uses a finer interval, does anything explain the disagreement? - Full-screen, side panel or inline, and does the choice suit the content? - Does the expansion go into the URL so it can be shared? - Is it reachable by keyboard, and does focus return correctly on close? - What is the touch equivalent? - Is any panel too small to read in its default state, relying on this to be usable? - Does expanding trigger a fresh query, and how long does it take? ## Compare **Grafana** offers full-screen panel view from a keyboard shortcut or the panel menu, keeps the dashboard's time range, and puts the view in the URL so an expanded panel is linkable, which is the detail most implementations miss. **Sentry** favours the side-panel form for events and traces, keeping the issue list visible, which suits a queue where the next item matters as much as the current one. **Datadog** uses full-screen with the surrounding scope preserved, so an expanded graph stays filtered to whatever the page was showing. **Honeycomb** barely needs the pattern, because the result of a query already occupies the page and there is no grid of small panels to escape from. ## Related Drill-down is the navigate-away sibling and the entry that covers moving to a different subject. Hover detail is the cheapest form of the same task. Collapsible row applies the idea at section scale. Panel grid is what has to hold still while a panel expands. Two-pane list and detail is the layout that makes this permanent rather than on demand. ## Examples ### Honeycomb Query-first; heatmaps and BubbleUp replace the dashboard-of-panels model with draw-a-region cross-filtering. **Trace / cart checkout** — captured September 11, 2026, Honeycomb sandbox, public dataset (signed out). analytical, dense density, light theme, desktop-web. Seventy-one spans over 3.288 seconds for one checkout, and the shape gives the answer away before you read a single duration. Two thirds of the way down, getDiscounts runs for 2.576s—more than three quarters of the whole request —and underneath it nine visible SELECT spans step down and to the right in a staircase, each starting after the last one finished. The badge on the parent says 19. Nineteen queries in a loop, run one at a time, and the waterfall says so by its outline rather than by any number. That is the shape worth learning: siblings overlapping means concurrency, siblings in a staircase means something that should have been one query. The panel top right is the other good idea here—it plots the distribution of this span's duration across the whole dataset and marks where this particular trace fell, so you can see whether you are looking at a normal request or the tail before you start optimising. Hotspots in this capture: - [Trace waterfall](https://patterns.konigi.com/dashboards/trace-waterfall) — Indentation is causality, length is duration, horizontal position is when it started. Six levels deep here. - [Trace waterfall](https://patterns.konigi.com/dashboards/trace-waterfall) — The staircase: nineteen SELECTs one after another inside getDiscounts. Batch the query, don't add a machine. - [Percentile summary](https://patterns.konigi.com/dashboards/percentile-summary) — This span's duration against the whole distribution, with this trace marked—so you know if you're looking at the tail. - [Detail on demand](https://patterns.konigi.com/dashboards/detail-on-demand) *(this pattern)* — Selecting a span fills the right pane with its fields. The waterfall never moves while you read. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) — A minimap of all 71 spans above the list, so the shape of the whole trace is visible before you scroll it. - [Categorical series palette](https://patterns.konigi.com/dashboards/categorical-series-palette) — Five services, five hues, and the name in a column beside every one. Colour is never carrying it alone. ### Kibana (Elastic) Query-first rather than panel-first: the search bar is the primary control and the charts are downstream of it, which inverts Grafana's arrangement. **Discover / filebeat logs** — captured September 10, 2026, Elastic demo environment (guest session; no version string exposed). analytical, dense density, light theme, desktop-web. Two panes: 315 fields down the left, 13,637 documents on the right, and a volume histogram over both. The left pane is the good half—it opens with a search box rather than a tree, which is the only sane way to navigate that many fields. The right pane is where it falls over. The documents table ships with two columns, a timestamp and "Summary", and Summary is every field on the record concatenated into one cell: agent.ephemeral_id, agent.id, agent.name, agent.type, agent.version, cloud.account.id, cloud.availability_zone, and on for three wrapped lines per row. It is technically complete and it cannot be scanned, so the first thing anyone does here is pick columns—which is to say the default view's job is to make you configure it. Underneath, the pager reads 100 rows per page across 137 pages, and the sort control sits above a table showing the first of them. Hotspots in this capture: - [Two-pane list and detail](https://patterns.konigi.com/dashboards/two-pane-list-detail) — Fields on the left, records on the right, both on screen at once. The oldest working shape for a queue there is. - [Detail on demand](https://patterns.konigi.com/dashboards/detail-on-demand) *(this pattern)* — An expander on every row. Inline rather than a side panel, so it pushes the rest of the list down. - [Data table](https://patterns.konigi.com/dashboards/data-table) — One column called Summary holding every field on the record. Complete, and unreadable at a glance. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — 315 fields, so the sidebar opens with a filter box. Past a certain count a tree is a filing system nobody browses. - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — A query language in the bar rather than chips. Powerful, and it hides what's applied from anyone who didn't type it. - [Time-range picker](https://patterns.konigi.com/dashboards/time-range-picker) — Relative by default, with the refresh control beside it rather than buried in a settings menu. - [Histogram and distribution](https://patterns.konigi.com/dashboards/histogram) — Volume over the window at a 30-second auto interval. The final bar is the bucket still filling, and it always reads low. ## Related patterns - [Drill-down](https://patterns.konigi.com/dashboards/drill-down) — The overview shows that something is wrong; the viewer needs to get to what, in one click. - [Hover detail](https://patterns.konigi.com/dashboards/hover-detail) — The chart shows shape; the viewer needs the exact value at one moment without leaving it. - [Collapsible row](https://patterns.konigi.com/dashboards/collapsible-row) — The dashboard grew to sixty panels and the viewer needs the top twelve most of the time. - [Panel grid](https://patterns.konigi.com/dashboards/panel-grid) — Many independent panels need to share one screen without fighting for it. - [Two-pane list and detail](https://patterns.konigi.com/dashboards/two-pane-list-detail) — The viewer works through a queue and needs the list and the item at once. ## Sources - [Shneiderman, The Eyes Have It—A Task by Data Type Taxonomy](https://www.cs.umd.edu/~ben/papers/Shneiderman1996eyes.pdf) - [Nielsen Norman Group, Progressive Disclosure](https://www.nngroup.com/articles/progressive-disclosure/) - [Grafana, Use dashboards](https://grafana.com/docs/grafana/latest/visualizations/dashboards/use-dashboards/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.