Drawer

A screen can only hold so much at once. For a long time, editing one row of a list left you with two options: navigate to a separate page, or open a window that covers what's behind it.

Both options charged rent. Navigating away throws out the list you were reading. You edit the third item out of twenty, come back, and the list has reset to its opening state — the filters you set are gone and so is your scroll position, and you rebuild both before you can reach item four. A covering window avoids the trip but cuts the context. If you want to check whether the value you're typing matches the row next to it, you have to close the window, and closing it discards what you typed.

Pagedeck ran into the same scene over and over. Someone would filter the document list down to "edited last week," open one document's detail page to change its sharing permissions, and return to find the filter cleared and the full list back on screen.

Drawers exist to remove that round trip. The list stays exactly where it was, and only the thing being edited slides in from the side. Half the screen behind stays visible, so you can compare while you edit, and when you close the panel the filter and the scroll position are untouched. You pick up at item four instead of rebuilding your way back to it.

The panel sits off-screen until something opens it, then slides inward from one edge. Building that behavior means deciding four things.

1. What opens it. Clicking anywhere on a row, or a dedicated button at the end of the row. Make the whole row open the drawer and people who meant to open the document keep landing in an edit panel instead.
2. Which edge, and how wide. Sliding in from the right is the common case; navigation menus on phones usually come from the left. Width is either a fixed number like 480 pixels or a proportion like 40 percent of the screen. A proportion needs a maximum alongside it, or the panel sprawls on a wide monitor.
3. What happens behind it. The background can be dimmed and set to close the drawer when clicked, or left fully live so the list stays operable.
4. How it closes. A close button inside the panel, a click outside it, and the Esc key — open all three by default. Leave only one and anyone who misses it presses the browser's back button, which takes them off the page entirely.

The sliding motion is explanation rather than decoration. A transition is the movement between two states, and a drawer that takes roughly 200 milliseconds to arrive from the right tells the user where the panel came from and where it goes when dismissed, without anyone having to explain it. A panel that appears instantly reads as the whole screen having changed.

For people working from the keyboard, opening the drawer has to move focus into the panel. Focus is the state that marks which element is currently receiving keyboard input. Skip that step and the Tab key wanders across the list hidden behind the panel, while someone using a screen reader never learns the drawer opened at all. On close, focus returns to whatever element opened it.

Three situations account for most drawers.

The first is editing beside a list. Users, documents, orders — anything that arrives as a long row of items you pick one from and change a value on. This is work where comparing against neighboring rows helps, so keeping them visible pays off.

The second is a filter panel. Once a screen has more than six or seven filters, they stop fitting in the layout and get folded off to the side. A faceted filter, which narrows results by stacking one attribute condition on another, easily runs past ten controls, so a drawer becomes its default home.

The third is navigation on a narrow screen. Responsive design rearranges a layout as the viewport changes size, and a menu pinned to the left edge on a wide screen has nowhere to live once the screen narrows. Folding that menu into a drawer leaves a single icon in its place.

There is an equally clear case for not using one. A question that has to be answered before anything else can happen — "delete this document?" — does not belong in a drawer. With the background still live, people click past it and carry on.

"Let's make this a drawer instead of a modal. You need the list behind it while you edit."

The task involves comparing against what's behind, so don't block it.

"Should the drawer be fixed at 480, or 40 percent of the viewport?"

A decision about how far the panel spreads on a wide monitor.

"First thing to fix: the list behind the drawer scrolls along with it."

Scrolling inside the panel is moving the background, and it shouldn't.

At Pagedeck the phrase came up most often around the team management screen. Noa first drew the permission-change flow as a separate page, and in usability testing four of five participants came back to the list afterward and hunted for which member they had just edited. Redrawing it as a drawer cut the time to finish the same task in half, largely because the row they had just edited never left the screen.

Theo added one more thing. Because clicking outside by accident would throw away whatever was typed, he blocked outside-click dismissal whenever the panel held unsaved edits.

The most common mistake is treating a drawer as a smaller sibling of the modal. They both float above the existing screen, so the assumption is reasonable, but the two components have opposite goals. A modal blocks the background because it wants an answer; a drawer steps aside because it wants the background kept. Mix them up and you get delete confirmations that people wander away from unanswered, and long edit forms in modals that hide the very values the user needs to reference.

The other misreading is filing drawers as a small-screen component. Plenty of people meet one first as a phone menu, which makes the assumption easy. In practice they often earn more on large screens. On a 1400-pixel-wide layout, a list can hold the left 900 pixels while a drawer holds the right 500 and both stay readable at once — an arrangement a narrow screen can't produce. Classify the drawer as mobile-only and the same task on desktop gets built as a page navigation for no reason.