Full-screen takeover

Problem Context

• The user starts from a parent page, list, map, editor, object, or setup context that should still be restored after the temporary mode closes.
• The task needs full-viewport space for camera capture, media review, map detail, multi-section setup, dense editing, or focused scanning.
• Background interaction must stop while the takeover is open.
• The takeover can define exact behavior for Close, Back, Escape, system back, route history, unsaved edits, and completion.

Selection Rules

• Choose full-screen takeover when the task is temporary and modal, but needs the whole viewport to be usable.
• Use a modal dialog when the task is compact and does not need full-screen space, internal navigation, or immersive focus.
• Use a sheet when adaptive sizing, edge attachment, partial parent visibility, or detents are part of the interaction.
• Use a drawer or details panel when users need to compare continuously with the parent page.
• Use a full page or single-page form when the task needs its own URL, browser history, saved progress, sharing, or long-form navigation.
• Use a preview panel or full-page preview when the main job is reading or inspecting media rather than completing a temporary task.
• Use alert dialog or confirmation dialog for urgent decisions and high-consequence review rather than expanding a tiny decision to full screen.
• Do not stack full-screen takeovers; route nested content to an internal step, page, sheet, or separate flow with clear navigation.
• Do not make Close, Back, browser back, Escape, and gesture dismissal disagree about whether they leave the takeover or move one level up.
• Protect unsaved work on every exit route, including close button, system back, browser back, Escape, refresh, and gesture dismissal.

Required States

• Closed parent state with the selected object, filters, scroll, and opener visible.
• Opening state that moves focus into the takeover title, first field, camera control, or main task start.
• Open takeover state with full-viewport layout, task title, exit control, primary action, and blocked parent content.
• Internal step or subview state when Back means previous takeover step rather than leaving the entire mode.
• Dirty state when edits, uploads, captures, or selections inside the takeover are not saved.
• Exit-review state when a dismissal route would discard unsaved work.
• Completed state that closes or navigates intentionally and reports what changed.
• Dismissed state that restores focus and parent-page state to the opener or relevant object.
• Responsive and orientation-change state that keeps actions, title, and exit controls reachable.

Interaction Contract

• The opener communicates the object or task that will enter a full-screen temporary mode.
• Opening the takeover blocks parent-page pointer and keyboard interaction and places focus inside the takeover.
• The top area includes a clear title and a labelled Close, Exit, Done, or Back control according to the current navigation depth.
• Internal Back returns to the previous takeover view when one exists; Close or Exit leaves the takeover and returns to the parent context.
• Primary completion actions use outcome-specific labels such as Save scan, Attach photo, or Finish setup.
• Escape, browser back, phone back, close button, and gesture dismissal follow the same unsaved-change rule.
• Completion, cancellation, and dismissal preserve or intentionally update the parent selection, scroll, filters, and draft context.
• The takeover avoids nested overlay stacks and routes secondary help, pickers, or confirmations through clear inline or child-surface behavior.

Implementation Checklist

• Define why the task needs the entire viewport and what parent context must be restored afterward.
• Name the takeover with a visible heading and expose it as the modal surface name.
• Provide labelled exit controls and distinguish internal Back from leaving the takeover.
• Make background content inert while the takeover is open and contain focus when implemented as a modal layer.
• Track unsaved edits, captures, selected media, uploads, and partial setup progress.
• Send every exit route through the same save, discard, or continue decision when work is dirty.
• Preserve opener focus, parent scroll, selected object, filters, and drafts on cancel or close.
• Decide whether completion closes back to the parent, moves to a result page, or leaves a receipt state.
• Test keyboard, screen reader, phone back, browser back, Escape, gestures, orientation change, zoom, safe areas, and refresh recovery.

Common Generated-UI Mistakes

• Using a full-screen takeover as a dramatic wrapper for a short confirmation, single text field, or routine message.
• Making the takeover look like a normal page while route history and browser back behave like an overlay.
• Providing both Back and Close controls that exit different amounts of the flow without clear labels.
• Stacking another full-screen overlay, sheet, or browser inside the takeover.
• Discarding scans, uploads, or edits when users press Escape, system back, or browser back.
• Closing the takeover and resetting the parent list, filters, selected object, or scroll position.
• Leaving parent controls focusable or clickable behind the full-screen surface.

Critique Questions

• What capability requires the entire viewport instead of a compact modal, sheet, drawer, or page?
• Is this a temporary mode that returns to a parent context, or should it be a normal route?
• What does Back mean inside the takeover, and how is that different from Close or Exit?
• Which parent state must be preserved after cancel, close, save, and system back?
• What unsaved work can exist, and do all dismissal routes protect it consistently?
• Could stacking or ambiguous close controls cause users to lose work or leave the wrong level?