Back to compare picker

Full-screen takeover vs Modal dialog vs Sheet vs Single-page form

Choose full-screen takeover when a task must temporarily occupy the whole viewport for focus, capture, immersive preview, or dense editing, while still needing an explicit exit that returns users to the previous context.

Decision dimensions

Dimension Full-screen takeoverModal dialogSheetSingle-page form
UI or UX UI + UX - Temporary full-viewport modal task modeUI + UX - Focused modal task layerUI + UX - Adaptive temporary sheet for a context-bound child taskUI + UX - Short related multi-field submission page
UI guidance Render a full-screen takeover as a full-viewport modal surface with a visible title, labelled exit control, primary outcome action, and blocked parent content.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 sheet as a titled adaptive surface with clear edge or window attachment, visible close or back controls, stable actions, and sizing that matches the task.Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit.
UX guidance Use the takeover only when full-viewport focus materially improves the temporary task and users must return to the invoking context afterward.Use the modal interruption only for compact tasks that genuinely need temporary focus before the user returns to the page.Use sheets for short child tasks that need more room than a dialog while preserving parent context after the task closes.Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.
Good UI A document scan opens a full-screen capture mode with title Attach receipt, Close, Save scan, internal Review back behavior, and the parent expense row restored after close.Account settings opens in a titled dialog with one display-name field, Save, Cancel, close control, and dimmed inactive page context.A review follow-up sheet opens from a claim row with the title Schedule follow-up for Claim C-1042, fields, close control, compact and expanded sizes, and sticky Save and Cancel actions.A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end.
Bad UI A full-screen layer titled Details hides the page, offers only an X, and behaves differently from browser back.A vague popup titled Popup floats over active page controls and offers only OK.A panel titled Sheet opens with no selected object, no close affordance, and hidden actions below an inner scroll area.A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.
Good UX A user opens camera capture from an expense row, moves to Review, uses Back to return to Capture, presses Close, sees an unsaved-scan review, keeps editing, saves, and returns to the same row.Opening moves focus to the display-name field, Tab remains inside the layer, Escape cancels, and closing returns focus to Open dialog.Opening the sheet focuses the first useful field, expanding the sheet preserves typed notes, Escape triggers discard review when edits are dirty, and Save returns focus to the claim row.A user edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once.
Bad UX A user presses the visible X inside a nested takeover and loses the entire product-selection flow rather than only the current detail view.Users can click background Delete or Navigate controls while the modal is still open.A user changes the appointment note, presses back, and loses the work without a decision point.A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed.
Best fit A temporary task needs the whole viewport for capture, immersive preview, focused setup, scanning, or dense editing.A short task must interrupt normal page interaction but should return users to the same context afterward.A user starts a short context-bound task that needs more room than a dialog but should not become a full page.A compact set of related fields should be reviewed together before one submit.
Avoid when The task is short enough for a compact modal dialog.The content is only informational and does not require blocking the page.The content is mainly destination navigation.The form is long, high-stakes, branched, or too hard to recover from on one page.
Required state Closed parent state with the selected object, filters, scroll, and opener visible.Closed page state with an obvious invoking control.Closed parent state with an opener tied to the object, field, or task that launches the sheet.Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.
Accessibility burden Expose the takeover as a modal surface with an accessible name from the visible title.Use dialog semantics with an accessible name from the visible title.Give the sheet a visible heading and use it as the accessible name.Keep field order in the DOM the same as the visible order.
Common misuse Using a full-screen takeover as a dramatic wrapper for a short confirmation, single text field, or routine message.Using a modal as a generic container for routine information that could stay inline.Using a sheet as a catch-all panel for navigation, filters, help, settings, and unrelated actions.Using one page for a long complex application just to avoid designing steps.

Full-screen takeover

UI or UX
UI + UX - Temporary full-viewport modal task mode
UI guidance
Render a full-screen takeover as a full-viewport modal surface with a visible title, labelled exit control, primary outcome action, and blocked parent content.
UX guidance
Use the takeover only when full-viewport focus materially improves the temporary task and users must return to the invoking context afterward.
Good UI
A document scan opens a full-screen capture mode with title Attach receipt, Close, Save scan, internal Review back behavior, and the parent expense row restored after close.
Bad UI
A full-screen layer titled Details hides the page, offers only an X, and behaves differently from browser back.
Good UX
A user opens camera capture from an expense row, moves to Review, uses Back to return to Capture, presses Close, sees an unsaved-scan review, keeps editing, saves, and returns to the same row.
Bad UX
A user presses the visible X inside a nested takeover and loses the entire product-selection flow rather than only the current detail view.
Best fit
A temporary task needs the whole viewport for capture, immersive preview, focused setup, scanning, or dense editing.
Avoid when
The task is short enough for a compact modal dialog.
Required state
Closed parent state with the selected object, filters, scroll, and opener visible.
Accessibility burden
Expose the takeover as a modal surface with an accessible name from the visible title.
Common misuse
Using a full-screen takeover as a dramatic wrapper for a short confirmation, single text field, or routine message.

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.

Sheet

UI or UX
UI + UX - Adaptive temporary sheet for a context-bound child task
UI guidance
Render a sheet as a titled adaptive surface with clear edge or window attachment, visible close or back controls, stable actions, and sizing that matches the task.
UX guidance
Use sheets for short child tasks that need more room than a dialog while preserving parent context after the task closes.
Good UI
A review follow-up sheet opens from a claim row with the title Schedule follow-up for Claim C-1042, fields, close control, compact and expanded sizes, and sticky Save and Cancel actions.
Bad UI
A panel titled Sheet opens with no selected object, no close affordance, and hidden actions below an inner scroll area.
Good UX
Opening the sheet focuses the first useful field, expanding the sheet preserves typed notes, Escape triggers discard review when edits are dirty, and Save returns focus to the claim row.
Bad UX
A user changes the appointment note, presses back, and loses the work without a decision point.
Best fit
A user starts a short context-bound task that needs more room than a dialog but should not become a full page.
Avoid when
The content is mainly destination navigation.
Required state
Closed parent state with an opener tied to the object, field, or task that launches the sheet.
Accessibility burden
Give the sheet a visible heading and use it as the accessible name.
Common misuse
Using a sheet as a catch-all panel for navigation, filters, help, settings, and unrelated actions.

Single-page form

UI or UX
UI + UX - Short related multi-field submission page
UI guidance
Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit.
UX guidance
Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.
Good UI
A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end.
Bad UI
A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.
Good UX
A user edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once.
Bad UX
A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed.
Best fit
A compact set of related fields should be reviewed together before one submit.
Avoid when
The form is long, high-stakes, branched, or too hard to recover from on one page.
Required state
Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.
Accessibility burden
Keep field order in the DOM the same as the visible order.
Common misuse
Using one page for a long complex application just to avoid designing steps.
Decision rules
  • Choose full-screen takeover when a task must temporarily occupy the whole viewport for focus, capture, immersive preview, or dense editing, while still needing an explicit exit that returns users to the previous context.
  • Choose modal dialog when the same blocking task is short enough for a compact centered layer with actions visible without full-viewport navigation chrome.
  • Choose sheet when the task is a context-bound child surface that benefits from adaptive size, edge attachment, detents, or partial parent visibility.
  • Choose single-page form when the task should have its own URL, browser history position, saved progress, page title, and normal navigation rather than an overlay lifecycle.
  • Use full-screen takeover instead of a drawer when side-by-side comparison with the parent page is not useful or would distract from a capture, scan, preview, or focused setup flow.
  • Do not use full-screen takeover for routine messages, short confirmations, or one-field edits; those belong in alert dialog, confirmation dialog, modal dialog, inline edit, or popover patterns.
  • If users can move deeper inside the takeover, provide internal Back for the previous takeover step and reserve Close or Exit for leaving the takeover and returning to the invoking context.
  • When takeover content has unsaved edits, route close, Escape, browser or system back, and any gesture dismissal through the same discard, save, or continue decision.
  • Avoid stacked takeovers and mixed close controls because users can lose their place or exit more of the flow than intended.
  • When the takeover closes, restore focus, scroll, selected object, filters, and drafted parent-page context unless completion intentionally navigates to a new result.
Inspect live examples
Failure modes
  • A full-screen overlay looks like a normal page but has no route, no page title, no browser-history contract, and a close button that drops users somewhere unexpected.
  • Close and Back mean different things inside the takeover, causing users to exit the entire flow when they meant to return one internal step.
  • A compact edit form is expanded to full screen without using the extra space or reducing interruption.
  • A long multi-step workflow is trapped in a takeover with no saved progress, shareable URL, or recovery after refresh.
  • The parent page state is reset after closing, losing filters, selected row, scroll position, or draft work.
  • Multiple takeovers stack above each other, making the visible close control ambiguous.