Back to compare picker

Drawer with no close or return path vs Drawer vs Modal dialog vs Navigation drawer vs Details panel

Flag drawer with no close or return path when the drawer opens from a row, object, filter, or navigation control but lacks a visible close affordance, Escape handling, back-route dismissal, scrim dismissal where appropriate, or predictable focus return.

Decision dimensions

Dimension Drawer with no close or return pathDrawerModal dialogNavigation drawerDetails panel
UI or UX UI + UX - Unrecoverable drawer anti-patternUI + UX - Supplemental edge panel for current-context detail or light actionsUI + UX - Focused modal task layerUI + UX - Dismissible slide-in navigation sheetUI + UX - Persistent selected-object inspection panel
UI guidance Treat a drawer without visible close, Escape, back, scrim, or focus-return behavior as an anti-pattern even when the drawer content itself is useful.Render a drawer as an edge-aligned panel with a visible heading, selected-object identity, close control, stable width, and clear relationship to the page content it supplements.Render a titled layer above a dimmed or otherwise unavailable page, with clear task content, named actions, visible close or cancel affordance, and stable scroll boundaries.Render a navigation sheet that enters from the start edge or bottom, is opened by an explicit control, and presents grouped destination items with selected state.Render a details panel as a persistent side or adjacent region that names the currently selected object, shows high-value metadata, status, and local secondary actions, and keeps the object selection visible in the source list, table, map, board, or feed.
UX guidance Use this anti-pattern during review when opening a drawer leaves users uncertain how to get back to the row, filter, list, map, chart, or workflow that launched it.Use drawers to preserve parent-page context while users inspect supplemental detail or perform simple adjacent actions.Use the modal interruption only for compact tasks that genuinely need temporary focus before the user returns to the page.Use a navigation drawer for destinations that need to be available but not constantly visible, especially on constrained screens or complex apps with secondary sections.Use a details panel when users need to select and compare nearby objects while keeping a durable inspection area visible, such as reviewing records, tickets, assets, alerts, comments, files, or map locations.
Good UI A case details drawer names Claim C-1042, has a Close details button in the header, supports Escape, and shows focus will return to the selected row.A right-side case details drawer opens from a table row, names Claim C-1042, shows status, owner, activity, and a close button while the table remains visible.Account settings opens in a titled dialog with one display-name field, Save, Cancel, close control, and dimmed inactive page context.A mobile app bar menu button opens a left modal drawer with Inbox selected, grouped labels, account switcher, and a visible scrim behind it.A ticket queue keeps TCK-2048 selected in the list and shows a right details panel with requester, severity, SLA, owner, activity, and Open full ticket.
Bad UI A right drawer slides over a table with no close button and no Escape response.A panel slides over the table with the title Details, no close control, and no selected record name.A vague popup titled Popup floats over active page controls and offers only OK.A hamburger opens a full-height list with no scrim, no close control, and no visible selected destination.A panel titled Details shows metrics from the previously selected record after the list selection changes.
Good UX A reviewer opens a drawer, switches rows, presses Escape, and lands back on the current selected row with filters preserved.Opening the drawer preserves the table filter and selected row, Next item updates the drawer title, Escape closes it, and focus returns to the selected row.Opening moves focus to the display-name field, Tab remains inside the layer, Escape cancels, and closing returns focus to Open dialog.Users open the drawer, select Sent, the drawer closes, and Sent becomes the visible destination while Inbox scroll state is preserved.A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.
Bad UX A keyboard user tabs through a drawer repeatedly because there is no close target or documented Escape exit.The drawer keeps showing Claim C-1042 after the user selects Claim C-1043 in the table.Users can click background Delete or Navigate controls while the modal is still open.Selecting a drawer item changes the destination behind the sheet but leaves the drawer covering the new page.Sorting the list silently clears the highlighted row while the panel continues to show an old ticket.
Best fit Use this anti-pattern to review temporary drawers, inspectors, side sheets, and mobile drawer layouts for missing close and return behavior.Users need to inspect object detail, metadata, comments, history, or light actions while staying on the current page.A short task must interrupt normal page interaction but should return users to the same context afterward.A constrained app needs access to more destinations than fit in the visible navigation surface.Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.
Avoid when The surface is a permanent side panel or details panel and is not meant to close.The surface is mainly app navigation or destination switching.The content is only informational and does not require blocking the page.Users need constant visibility of the local hierarchy while working in a section.The content is just a short temporary preview before navigation.
Required state Closed state with a clear opener and remembered return target.Closed state with a clear opener tied to a specific object or page section.Closed page state with an obvious invoking control.Closed state with a clear opener such as a menu button.No selection state with a clear prompt or preserved last-selection rule.
Accessibility burden Do not create a keyboard trap inside a drawer; every temporary drawer needs an exit path that keyboard users can discover and operate.Give the drawer a visible heading and expose it as the accessible name for the region or dialog-like surface.Use dialog semantics with an accessible name from the visible title.Give the opener an accessible name such as Open navigation menu.Name the panel region from the selected object's title or a heading that includes the object identity.
Common misuse Hiding close in an overflow menu or offscreen toolbar.Using a drawer as an unlabeled junk panel for unrelated commands, navigation, filters, and help.Using a modal as a generic container for routine information that could stay inline.Hiding the app's most important destinations in a drawer on mobile.Showing a details panel with no selected-object identity.

Drawer with no close or return path

UI or UX
UI + UX - Unrecoverable drawer anti-pattern
UI guidance
Treat a drawer without visible close, Escape, back, scrim, or focus-return behavior as an anti-pattern even when the drawer content itself is useful.
UX guidance
Use this anti-pattern during review when opening a drawer leaves users uncertain how to get back to the row, filter, list, map, chart, or workflow that launched it.
Good UI
A case details drawer names Claim C-1042, has a Close details button in the header, supports Escape, and shows focus will return to the selected row.
Bad UI
A right drawer slides over a table with no close button and no Escape response.
Good UX
A reviewer opens a drawer, switches rows, presses Escape, and lands back on the current selected row with filters preserved.
Bad UX
A keyboard user tabs through a drawer repeatedly because there is no close target or documented Escape exit.
Best fit
Use this anti-pattern to review temporary drawers, inspectors, side sheets, and mobile drawer layouts for missing close and return behavior.
Avoid when
The surface is a permanent side panel or details panel and is not meant to close.
Required state
Closed state with a clear opener and remembered return target.
Accessibility burden
Do not create a keyboard trap inside a drawer; every temporary drawer needs an exit path that keyboard users can discover and operate.
Common misuse
Hiding close in an overflow menu or offscreen toolbar.

Drawer

UI or UX
UI + UX - Supplemental edge panel for current-context detail or light actions
UI guidance
Render a drawer as an edge-aligned panel with a visible heading, selected-object identity, close control, stable width, and clear relationship to the page content it supplements.
UX guidance
Use drawers to preserve parent-page context while users inspect supplemental detail or perform simple adjacent actions.
Good UI
A right-side case details drawer opens from a table row, names Claim C-1042, shows status, owner, activity, and a close button while the table remains visible.
Bad UI
A panel slides over the table with the title Details, no close control, and no selected record name.
Good UX
Opening the drawer preserves the table filter and selected row, Next item updates the drawer title, Escape closes it, and focus returns to the selected row.
Bad UX
The drawer keeps showing Claim C-1042 after the user selects Claim C-1043 in the table.
Best fit
Users need to inspect object detail, metadata, comments, history, or light actions while staying on the current page.
Avoid when
The surface is mainly app navigation or destination switching.
Required state
Closed state with a clear opener tied to a specific object or page section.
Accessibility burden
Give the drawer a visible heading and expose it as the accessible name for the region or dialog-like surface.
Common misuse
Using a drawer as an unlabeled junk panel for unrelated commands, navigation, filters, and help.

Modal dialog

UI or UX
UI + UX - Focused modal task layer
UI guidance
Render a titled layer above a dimmed or otherwise unavailable page, with clear task content, named actions, visible close or cancel affordance, and stable scroll boundaries.
UX guidance
Use the modal interruption only for compact tasks that genuinely need temporary focus before the user returns to the page.
Good UI
Account settings opens in a titled dialog with one display-name field, Save, Cancel, close control, and dimmed inactive page context.
Bad UI
A vague popup titled Popup floats over active page controls and offers only OK.
Good UX
Opening moves focus to the display-name field, Tab remains inside the layer, Escape cancels, and closing returns focus to Open dialog.
Bad UX
Users can click background Delete or Navigate controls while the modal is still open.
Best fit
A short task must interrupt normal page interaction but should return users to the same context afterward.
Avoid when
The content is only informational and does not require blocking the page.
Required state
Closed page state with an obvious invoking control.
Accessibility burden
Use dialog semantics with an accessible name from the visible title.
Common misuse
Using a modal as a generic container for routine information that could stay inline.

Navigation drawer

UI or UX
UI + UX - Dismissible slide-in navigation sheet
UI guidance
Render a navigation sheet that enters from the start edge or bottom, is opened by an explicit control, and presents grouped destination items with selected state.
UX guidance
Use a navigation drawer for destinations that need to be available but not constantly visible, especially on constrained screens or complex apps with secondary sections.
Good UI
A mobile app bar menu button opens a left modal drawer with Inbox selected, grouped labels, account switcher, and a visible scrim behind it.
Bad UI
A hamburger opens a full-height list with no scrim, no close control, and no visible selected destination.
Good UX
Users open the drawer, select Sent, the drawer closes, and Sent becomes the visible destination while Inbox scroll state is preserved.
Bad UX
Selecting a drawer item changes the destination behind the sheet but leaves the drawer covering the new page.
Best fit
A constrained app needs access to more destinations than fit in the visible navigation surface.
Avoid when
Users need constant visibility of the local hierarchy while working in a section.
Required state
Closed state with a clear opener such as a menu button.
Accessibility burden
Give the opener an accessible name such as Open navigation menu.
Common misuse
Hiding the app's most important destinations in a drawer on mobile.

Details panel

UI or UX
UI + UX - Persistent selected-object inspection panel
UI guidance
Render a details panel as a persistent side or adjacent region that names the currently selected object, shows high-value metadata, status, and local secondary actions, and keeps the object selection visible in the source list, table, map, board, or feed.
UX guidance
Use a details panel when users need to select and compare nearby objects while keeping a durable inspection area visible, such as reviewing records, tickets, assets, alerts, comments, files, or map locations.
Good UI
A ticket queue keeps TCK-2048 selected in the list and shows a right details panel with requester, severity, SLA, owner, activity, and Open full ticket.
Bad UI
A panel titled Details shows metrics from the previously selected record after the list selection changes.
Good UX
A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.
Bad UX
Sorting the list silently clears the highlighted row while the panel continues to show an old ticket.
Best fit
Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.
Avoid when
The content is just a short temporary preview before navigation.
Required state
No selection state with a clear prompt or preserved last-selection rule.
Accessibility burden
Name the panel region from the selected object's title or a heading that includes the object identity.
Common misuse
Showing a details panel with no selected-object identity.
Decision rules
  • Flag drawer with no close or return path when the drawer opens from a row, object, filter, or navigation control but lacks a visible close affordance, Escape handling, back-route dismissal, scrim dismissal where appropriate, or predictable focus return.
  • Choose drawer when users need supplemental edge content and the surface names its object, offers an explicit close control, supports keyboard dismissal, preserves page state, and returns focus to the opener or selected object.
  • Choose modal dialog when the content is a compact task that must block the page; in that case the surface must trap focus intentionally and still restore focus on close.
  • Choose navigation drawer when the panel contains app destinations; it still needs selected destination state, route-change behavior, dismissal rules, and focus recovery.
  • Choose details panel when the side content is a persistent part of the workspace and does not need temporary open or close behavior.
  • If responsive layout turns a drawer into a full-screen panel, provide a clear back or close path, keep the object title visible, and restore the user's list, filter, scroll, and focus when returning.
  • If Escape, outside click, browser back, route change, or object switch can close the drawer, route every path through the same cleanup: preserve page state, close the surface once, and return focus locally.
  • If closing the drawer would discard dirty edits or unsaved selections, ask for a scoped discard decision rather than removing the close route.
  • Do not hide the only close route in an offscreen toolbar, overflow menu, hover-only control, or swipe-only gesture.
  • During generated UI review, inspect temporary drawers, mobile full-screen drawers, side sheets, inspectors, and navigation drawers for close, Escape, back, focus return, and state preservation as one contract.
Inspect live examples
Failure modes
  • A case drawer opens with no close button and Escape does nothing.
  • The drawer can close visually, but focus drops to the page header instead of returning to the selected row.
  • Browser back leaves the drawer open while the URL changes, or closes it and loses the user's list filter.
  • A mobile full-screen drawer hides the originating list and provides no Back or Close control.
  • A scrim appears behind a temporary drawer but clicking it does not dismiss or explain why dismissal is blocked.
  • A drawer asks users to swipe to close with no keyboard, pointer, or screen reader equivalent.
  • Closing the drawer resets selected object, scroll position, draft filters, or review state.
  • Object switching while the drawer is open leaves focus and return target attached to the previous row.