Prepared Docs

Prepared Docs

⌘K

    Loading navigation…

User

  1. Blocks
  2. Takeover Page
  3. Usage

Takeover page

Usage

Overview

TakeoverPage from @prepared911/ui-takeover-page owns the whole viewport for one task. It suppresses the usual shell chrome (navigation rails, secondary headers), renders a branded TakeoverPageHeader with an explicit close, and hosts a single focused workflow underneath. Use it when the operator must commit to a task until it's done or dismissed.

It's the right surface for locked workflows—review an incident with drawers open, work through a migration wizard, or park the user in a read-only state while a background job runs—where ambient navigation would distract rather than help.

When to use

Focused, committed workflows

Use TakeoverPage for flows where leaving mid-task is destructive or confusing: an incident review with evidence playback, an export wizard, or an agreement step that gates further work. The full viewport signals "this is the task" and the close button is the single exit.

App-level announcements that need the whole screen

Maintenance pages, forced acknowledgments, and re-auth flows fit here. The header's branded slot and the vertical layout leave room for a short message and a single primary action without competing navigation.

Long, multi-panel review surfaces

When a review task needs multiple synchronized panels (list + detail + drawer + tool strip), TakeoverPage gives each panel room to breathe. The shell component ceases to compete for width, and the layout stays legible at narrower desktop sizes.

When not to use

  • Short interactions and confirmations. Use a Modal for questions, short forms, and destructive confirms that belong in the flow, not outside it.
  • Side-by-side details on a list view. A Drawer keeps the list in context and supports resuming the scan. Takeover breaks that pattern.
  • Navigation that should persist. If the user needs the global nav to switch contexts, stay in the app shell—takeover is a one-task surface.
  • Routes that share keyboard shortcuts with the shell. Shortcuts scoped to the shell will stop working inside takeover; validate hot paths before replacing a shell route.

Composition

TakeoverPage composes two building blocks:

  • TakeoverPageHeader: branded strip with title, optional subtitle, and close affordance. Keep the title task-focused ("Review incident 12345") rather than generic ("Details").
  • Body region: the rest of the viewport is yours. Use the existing app patterns (DataTable, Drawer, PageHeader) inside the body; the takeover is just the outer frame.

Content guidelines

  • Title. Describe the task, not the page. "Start shift handoff" beats "Handoff page".
  • Subtitle. Use it for scope when the title is ambiguous ("Reviewing 24 incidents from 8 a.m.–4 p.m. shift"). Skip it otherwise.
  • Close label. Keep the close affordance tooltip verb-first ("Close review") so screen reader users know what dismissing does.
  • Primary action. When the body has a single CTA, it should be obvious and pinned; if the takeover hosts a multi-step flow, show 1 of 3 progress to match HIG expectations for wizards.

Behavior and states

Close and navigation guards

Close always routes back to the origin (the page that opened it) unless your app explicitly overrides. When unsaved state exists, prompt before closing; never close silently through a route change. Map Escape to the close control when the takeover has no conflicting modal surfaces open.

Embedded overlays

Modals, drawers, and popovers launched inside a takeover should stack above it; the takeover itself is not a modal, so don't trap focus across the whole surface—trap inside child overlays only.

Errors inside takeover

Render errors with a clear recovery path (Callout variant error, or an inline retry state). The user can't use surrounding nav to escape, so make the exit obvious.

Responsive collapse

Takeover does not retarget to mobile; validate narrow-desktop widths and tablet landscape where operators actually work. Don't use it for flows that primarily run on phone sizes.

Best practices

Do

  • Reserve takeover for committed tasks where the shell would distract.
  • Title the page for the task, not the object ("Review incident" over "Incident 12345").
  • Offer a single, unmistakable close affordance in the header and wire Escape to it when safe.
  • Stack drawers and modals inside takeover, not around it.

Don't

  • Don't replace a route with takeover just to feel more focused; short confirms belong in a modal.
  • Don't launch a takeover from inside another takeover.
  • Don't hide unsaved-change warnings—users rely on the close affordance to be safe.
  • Don't remove the header; the title and close are what make the surface usable.

Accessibility

Takeover needs clear focus management on open and close, a labeled header that screen readers can announce, and a close control reachable by keyboard. See the Accessibility page for focus patterns, Escape handling, and how to announce error states inside the takeover.

Related Components

  • Modal: focused confirms and short forms that belong inside the shell.
  • Drawer: detail panel that keeps the list in view.
  • Page header: standard page chrome when you stay inside the shell.

Previous

Page Header / Accessibility

Next

Takeover Page / API and Development

On this page

Overview
When to use
Focused, committed workflows
App-level announcements that need the whole screen
Long, multi-panel review surfaces
When not to use
Composition
Content guidelines
Behavior and states
Close and navigation guards
Embedded overlays
Errors inside takeover
Responsive collapse
Best practices
Accessibility
Related Components