# Two-pane list and detail > The viewer works through a queue and needs the list and the item at once. - Canonical: https://patterns.konigi.com/dashboards/two-pane-list-detail - Group: Page layout - Level: context - Status: published - Updated: September 10, 2026 - Also called: issue list plus detail, master-detail --- ## Problem Forty alerts need triaging. Opening each one as a page means forty navigations and forty returns, and after the third the person has lost their place in the list and started over. ## Solution List on one side, selected item on the other, both visible at once. Selecting a row updates the detail pane and nothing else moves. The pattern is old—mail clients, file browsers, IDEs—and it survives because it fits a specific shape of work exactly: a queue of similar items where the decision about each one is quick and the next one matters as much as the current one. Keeping the list on screen means position is never lost and the remaining volume is always visible, which is itself information when the queue is the thing being managed. Three properties separate a good implementation from a pane that happens to be split. **Keyboard traversal.** Up and down through the list with the detail following is the entire productivity argument. If it takes a mouse, the pattern is worth much less than the space it costs. **Stable list.** If the list re-sorts or refreshes while someone is working through it, they lose their place and may skip items entirely. A live queue needs to hold its order until the viewer asks for new items, usually via a "3 new" affordance rather than an automatic insert. **Detail that fits.** The right pane is narrower than a full page. Content designed for full width—wide tables, waterfalls, long stack traces—gets cramped, and the escape hatch is usually a full-screen view, which is where this pattern hands over to detail on demand. ## Use when The work is a queue of comparable items, decisions per item are fast, and the viewer's place in the list matters. Alert triage, error inboxes, code review, moderation. ## Don't use when Items are rare and consequential enough to deserve a full page each, or the detail genuinely needs the full width. And it fits badly on narrow screens, where the two panes become two screens and the pattern's whole advantage disappears. ## Trade-offs The split costs horizontal space permanently and both panes are compromised: the list shows fewer columns, the detail shows less. Deep-linking is awkward, because a URL has to encode both the list state and the selection. It encourages processing items in list order rather than by importance, which is fine for a sorted queue and bad for an unsorted one. And on touch, hit targets in a narrow list are hard to size well while keeping density. ## Checklist - Can the viewer move through the list entirely by keyboard? - Does the list hold its order while someone is working, and how do new items arrive? - Is the current selection obvious in the list, not only in the detail pane? - Does a URL restore both the list state and the selected item? - Does the detail pane have enough width for its widest content? - Is there a full-screen escape for content that does not fit? - Are actions available from the list, or only after selecting? - What happens on a narrow screen? - Do list hit targets meet minimum sizes without destroying density? - Does the viewer always know how many items remain? ## Compare **Sentry** is the clearest current example in this space: the issue stream on the left, the selected issue on the right, keyboard traversal, and per-row actions so common decisions never need the detail pane at all. **Email clients** established every convention this pattern uses, and remain the reference for keyboard traversal and for how to handle new items arriving mid-triage. **Datadog** uses the split for logs and traces, where the detail is a structured record and fits a narrow pane well. **Grafana** does not offer it as a dashboard layout, because a dashboard is a grid of independent panels rather than a queue, which is a fair statement of where this pattern does and does not apply. ## Related Data table is the list half, and covers sorting and column decisions. Detail on demand is the escape hatch when the pane is too narrow. Ranked list is what the list should be if order is meant to imply priority. Filter bar is how the queue gets narrowed before triage starts. Drill-down is the alternative when the detail deserves its own page. ## Examples ### 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) *(this pattern)* — 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) — 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 - [Data table](https://patterns.konigi.com/dashboards/data-table) — The viewer needs exact values for many items and wants to sort and scan them. - [Detail on demand](https://patterns.konigi.com/dashboards/detail-on-demand) — A small panel needs to become a big one for a moment. - [Ranked list](https://patterns.konigi.com/dashboards/ranked-list) — The viewer needs to know which few items dominate, not the distribution of all of them. - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — The viewer needs to narrow a large set by several attributes and see what's applied. - [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. ## 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/) - [W3C, WCAG 2.2—Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.