Problem
There are two hundred dashboards. The viewer needs to move between them constantly, needs to know where they currently are, and needs the data itself to get almost all of the screen.
Solution
A persistent rail down one side carrying navigation and current position; everything else is canvas. The rail is narrow, always present, and never scrolls with the content.
The value is orientation as much as travel. A rail that highlights the current item answers “where am I” continuously, for free, which a breadcrumb only answers when someone reads it. That matters most for the person who arrived from an alert link and has no idea what else exists.
Three decisions do most of the work.
What the rail contains. Global sections, or the contents of the current section, or both stacked. Both is the most useful and the most likely to overflow. A rail that tries to hold a two-hundred-item tree becomes a scrolling list inside a page that also scrolls, which is the single most common way this pattern goes wrong.
Whether it collapses. On a data-dense page the rail is competing with the thing people came for. A collapse control reclaims the width, and then the orientation benefit disappears exactly when the page is densest.
What happens when the window narrows. The rail is the first thing to go, and if it held the only navigation, the narrow layout has no navigation. That has to be designed rather than discovered.
Use when
There are many destinations, viewers move between them often, and the page needs a persistent sense of place. Products rather than single dashboards.
Don’t use when
There are four destinations. A rail holding four links is a horizontal nav rotated ninety degrees and costing more width. Also avoid it on anything going on a wall, where nobody is navigating and the rail is pure loss.
Trade-offs
The rail costs 200 to 300 pixels forever, which on a dense grid is a column of panels. Deep trees inside a fixed-width rail truncate labels, and truncated labels are close to useless for distinguishing similarly-named dashboards. Two scroll regions on one page is a persistent small annoyance that nobody reports and everybody feels. And a rail invites growth: every team wants an entry, and the list becomes the thing you need navigation for.
Checklist
- What is in the rail: global sections, current-section contents, or both?
- Does it show current position clearly enough to orient someone who arrived from a link?
- What happens at two hundred items, and is there search?
- Do labels truncate, and are truncated labels still distinguishable?
- Does the rail scroll independently, and does that fight the page scroll?
- Can it collapse, and does anything break when it does?
- What replaces it below the mobile breakpoint?
- How much horizontal space does it take from the canvas, and is that trade stated?
- Does it survive being on a wallboard, or should it be hidden there?
- Who decides what gets an entry, and what stops the list growing?
Compare
Grafana runs a collapsible left nav for products and sections with dashboard search as the real navigation, an admission that at real scale a tree stops working and a search box is the honest answer. Netdata puts a node and section tree in the rail and uses it as the page’s table of contents as well as its navigation, so the rail scrolls the canvas rather than replacing it. Kibana splits the difference with a collapsible rail for apps and in-page controls for everything within an app, which keeps the rail short at the cost of two different navigation models to learn. Sentry keeps a thin fixed rail for top-level areas and pushes all narrowing into the content, which suits a product where the work is a queue rather than a library.
Related
Overview then detail is the hierarchy the rail exposes. Multi-page dashboard is the alternative when the destinations are few and parallel. Tabs as genres is the horizontal version for a small, fixed set. Two-pane list and detail is the same split applied to items rather than destinations. Mobile adaptation is where the rail has to become something else entirely.