Drawer vs Modal vs Page | LlamaPress Pattern Catalog
LlamaPress
Inspect
Decision guide

Drawer vs Modal vs Page

The decision guide for where a record or task should open. Three surfaces, three different promises about context — pick on the conditions, not on taste.

Inspect Act & Decide

You have a list and you need somewhere to put the detail. Every team argues this from preference, ships whichever surface someone liked last, and ends up with all three in one app meaning nothing in particular. The choice is actually decidable, and getting it wrong shows up as either lost context or a workflow trapped in a box too small for it.

Live demo — try it Open full screen
Use when
  • You are deciding where a record opens and the team is arguing from preference.
  • An existing screen feels wrong and nobody can say why.
  • You are about to add a third surface to an app that already has two.
Avoid when
  • The answer is already forced — deep linking is a requirement, or the parent list must stay visible. Then you have a condition, not a choice.

The decision

Start at the top and take the first row that matches. The order matters — the earlier conditions are hard constraints, the later ones are preferences.

If this is true Use Because
People must link, bookmark or share this record Page Only a page has a durable, meaningful URL
The record contains its own multi-step workflow Page Nested workflows need room and their own history
People will spend more than a couple of minutes here Page A long stay in a temporary surface feels precarious
The parent list must stay visible and in place Drawer It is the only surface that preserves the collection
People inspect several records in sequence Drawer Replacing panel content beats navigating twice per record
The task is short, bounded, and worth interrupting for Modal Deliberate interruption is the modal's one real strength
None of the above Page The safest default: it can hold anything and always has a URL

What each surface actually promises

A page promises permanence. It has an address, it can be sent to a colleague, it can hold anything, and browser Back means what people expect. The cost is that it takes the previous context away — which is exactly why it is wrong for sequential inspection and right for deep work.

A drawer promises the parent stays. Its entire value is that the list does not move: scroll, sort, filters and your place in the queue all survive. Everything else about a drawer is a detail. If the parent is not visible, or the panel takes so much width the list is unusable, you have built a modal with a slide-in animation and paid for nothing.

A modal promises this is the only thing that matters right now. It blocks the page deliberately. That is a strength for a confirm, a short form, a picker — and it is a liability for anything else, because a blocked page cannot be referred to. The classic tell that a modal was the wrong choice: someone needs a value that is behind it.

The rules that are not negotiable

  • Never open a modal from a modal. The named anti-pattern is Modal Maze. The second modal is the signal that the first one was already carrying too much; promote the whole thing to a page.
  • One surface per kind of object, everywhere. If a customer opens in a drawer from the list, it must not open in a modal from search and a page from the dashboard. Three surfaces for one object means people learn three mental models for one thing — the same failure as viewing an invoice one way and editing it another.
  • Anything that can be linked to, should be. A drawer without a URL is a record you found and cannot share. Writing the id into the URL is cheap and turns the drawer into something forwardable.
  • Escape closes, on every surface that floats. Both drawer and modal. People try it first.

When the choice is a symptom

Three cases where the argument about surfaces is really an argument about something else:

  • The drawer keeps getting wider. Every widening is evidence the record deserved a page. Promote it.
  • The modal grew tabs. A modal with tabs is a page that has not admitted it yet.
  • You need the detail because the table is unreadable. Sometimes the fix is a better table — the right six columns — and no detail surface at all. Check the dense operational table before building anything.

Exemplars

GitHub is the clearest demonstration of all three in one product, each used correctly: an issue is a page because people link to issues constantly and conversation accumulates there for months; the file finder is a modal because it is a bounded ten-second task; the pull-request file browser uses panels because you are moving through a sequence and the list of files must stay put.

Linear shows the drawer at its ceiling — issues open beside the list, and the keyboard moves between them without the mouse. It also shows the escape valve: the same issue has a real URL and a real page, so the drawer never traps anything.

Stripe is worth studying for its restraint with modals. Almost nothing is modal, because almost nothing in reading a payment ledger is a bounded interruption. The modals that exist are confirmations and short forms — exactly the surface's job description.

The extractable rule: the surface is a promise about context. A page promises a place, a drawer promises the list stays, a modal promises this is the only thing. Break the promise and no amount of polish fixes the screen.

Instead of this, consider

Same problem, different trade-off. Pick on the condition, not on taste.

Master–Detail Drawer
When: You have decided on the drawer and want the detail of building it well.
Dense Operational Table
When: The real fix is fewer columns and no detail surface at all.

Ask Leo for this

Paste this into your Leo chat. It describes the behaviour, not the code, so Leo can fit it to your data.

Prompt
Before building the detail view, choose the surface deliberately.

Use a side drawer when the parent list must stay visible, people inspect
several records in a row, and the detail is about one screenful. Keep the list
unmoved, put the record id in the URL, and let Escape and browser Back close it.

Use a modal when the task is short and bounded, interrupting is the point, and
there is exactly one way out. Never open a modal from a modal. If the modal
needs its own tabs or a second step, it should be a page.

Use a full page when the record has real depth, people will spend minutes
there, it has nested workflows, or the URL needs to be shareable and
bookmarkable.

Pick one surface per kind of object and use it everywhere that object appears.
Do not mix surfaces for the same object in different parts of the app.

Related

Cookbook recipe
Progressive Disclosure for Dense Detail Pages
What to do once you have chosen the page and it is still too dense.
Cookbook recipe
Filterable Index with Slide-Out Detail Drawer
The implementation, if the decision below lands on the drawer.
Wiki guide
UX Principles Guide for Building Web Software
Orientation and progressive disclosure, the two principles this decision trades against each other.