Fullscreen takeover
Fullscreen takeovers provide a focused, full-page experience that purposefully interrupt the user flow.
Loading...
Overview
Resources
Install
yarn add @activecampaign/camp-components-fullscreen-takeoverVariations
Full screen takeovers provide a focused, full-page experience that purposefully interrupts the user flow. They tell when a user needs to undertake an action that requires full attention, without distractions.
They appear similar to a standard page layout, sitting above the navigation with a header and have a close button in the upper right-hand corner to allow the user to exit the experience at any time. The user can also press the escape key on a keyboard to exit this view.
The anchor subcomponent dictates where in the component tree the takeover will mount to.
Default
<div style={{ height: '100vh', width: '100vw', display: 'flex' }}>
{/* Navbar */}
<div
style={{
width: 100,
height: '100vh',
backgroundColor: '#004cff',
zIndex: 111111,
position: 'relative',
}}
>
<Button.Outline
dangerouslySetStyles={{
position: 'absolute',
top: '50%',
transform: 'translate( 10px, -50% )',
zIndex: 'inherit',
}}
onClick={() => setTakeoverIsOpen(!takeoverIsOpen)}
>
Toggle Takeover
</Button.Outline>
{/* Purposely rendering FsTo outside of the "Page" */}
<FullscreenTakeover.Root {...args} onDismiss={handleDismiss} isVisible={takeoverIsOpen}>
<FullscreenTakeover.Header>
<FullscreenTakeover.Title>Fullscreen Takeover!</FullscreenTakeover.Title>
</FullscreenTakeover.Header>
<FullscreenTakeover.Body insetBackground={insetBackground}>
<div style={{ height: '100vh', position: 'relative' }}>
<p>Hello Takeover</p>
<p style={{ position: 'absolute', bottom: 0 }}>Bye-Bye Takeover</p>
</div>
</FullscreenTakeover.Body>
<FullscreenTakeover.Footer>
<Button.Outline children="Cancel" onClick={handleDismiss} mr="sp400" />
<Button children="Ship it" onClick={handleDismiss} />
</FullscreenTakeover.Footer>
</FullscreenTakeover.Root>
</div>
{/* Page */}
<div style={{ height: '100%', flexGrow: 1, position: 'relative' }}>
<FullscreenTakeover.Anchor zIndex={100000} styles={{ width: '-webkit-fill-available' }} />
<Button.Text
dangerouslySetStyles={{
position: 'absolute',
left: '50%',
top: '50%',
transform: 'translate(-50%, -50%)',
}}
onClick={() => setTakeoverIsOpen(!takeoverIsOpen)}
>
Open Takeover!
</Button.Text>
</div>
</div>Inset background
The inset background is oftentimes used for as a focused canvas area for previews or forms. Utilize fullscreen takeover’s alternate background with the insetBackground prop.
<FullscreenTakeover.Root isVisible={takeoverIsOpen} anchorId="my-takeover">
<FullscreenTakeover.Header>...</FullscreenTakeover.Header>
<FullscreenTakeover.Body insetBackground>Hello Takeover</FullscreenTakeover.Body>
<FullscreenTakeover.Footer>...</FullscreenTakeover.Footer>
</FullscreenTakeover.Root>No animation
By default, the fullscreen takeover animates in and out to indicate to the user that they are not being navigated to a new page. Use the noAnimation prop for situations when these animations are inappropriate.
<FullscreenTakeover.Root noAnimation isVisible={takeoverIsOpen} anchorId="my-takeover">
<FullscreenTakeover.Header>...</FullscreenTakeover.Header>
<FullscreenTakeover.Body>Hello Takeover</FullscreenTakeover.Body>
<FullscreenTakeover.Footer>...</FullscreenTakeover.Footer>
</FullscreenTakeover.Root>Usage
Anchor
Fullscreen takeover is in many ways similar to modal. Both modal and fullscreen takeover require a mount point, or “anchor” to be defined in the component tree that defines where in the component tree that the contents of the modal or takeover mount to. The main difference between modal and fullscreen takeover is that modal’s z-index causes the modal to render above all other content in the DOM, whereas fullscreen takeover does not have the same behavior.
In order to address this additional complexity with the usage of fullscreen takeover the idea of two main developer “roles” have been established for the consumption of the fullscreen takeover component. The first role being the developer that defines the contents of the Takeover and has control of the open state of the takeover; we will refer to as the consumer role. The second role is the facilitator, who is responsible for the anchor and both setting the width and z-index of the anchor, along with any other necessary styles on the anchor.
{/** Facilitator Code */}
<Navbar styles={{ zIndex: 5001, width: 50 }}/>
<FullscreenTakeover.Anchor zIndex={5000} styles={{ width: 'calc(100vw - 50px)' }} />
{/** Consumer Code */}
<FullscreenTakeover.Root {...args} onDismiss={handleDismiss} isVisible={takeoverIsOpen}>
<FullscreenTakeover.Header>
<FullscreenTakeover.Title>Fullscreen Takeover!</FullscreenTakeover.Title>
</FullscreenTakeover.Header>
<FullscreenTakeover.Body insetBackground={insetBackground}>
<div style={{ height: '100vh', position: 'relative' }}>
<p>Hello Takeover</p>
<p style={{ position: 'absolute', bottom: 0 }}>Bye-Bye Takeover</p>
</div>
</FullscreenTakeover.Body>
<FullscreenTakeover.Footer>
<Button.Outline children="Cancel" onClick={handleDismiss} mr="sp400" />
<Button children="Ship it" onClick={handleDismiss} />
</FullscreenTakeover.Footer>
</FullscreenTakeover.Root>In the example above, the consumer is defining the content of the fullscreen takeover and controlling the open state. Elsewhere in the application, the facilitator is setting the anchor to take up all horizontal space in the viewport except for the navbar as well as coordinating the z-indices of the navbar and the takeover. The takeover defined by the consumer will take up 100% vertical space of the viewport as well as the horizontal space declared by the facilitator, this means that the consumer does not have to worry about where the takeover will mount to, nor the dimensions or z-index of the takeover.
Requirement of zIndex prop
The zIndex prop is required on the anchor component. This was done as a way to coordinate overlapping elements in the usage of fullscreen takeover. In the designs, the navigation sits mostly next to the fullscreen takeover, however an element of the navigation—the expansion button—sits on top of the takeover. In practice, the takeover needs to have a z-index greater than the page content, but lower than the navigation. The z-index of the anchor is managed internally by the anchor component based on the mount state of the fullscreen takeover. When a takeover is open, the z-index is set to whatever is passed into the prop by the facilitator, however when no takeover is open the z-index is set to -1. This is done to allow the page content to be accessible when the takeover is closed.
Best practices
- Use a fullscreen takeover when the user needs to focus exclusively on a single task without distractions. This is ideal for complex workflows, multiple step tasks, or reviewing content that requires a lot of screen space. For things like multi-step processes, the immersive experience of stripping away extra UI elements improves focus and minimizes distractions and encourages completion.
- Fullscreen takeovers can be used across multiple areas of the platform (e.g., explore page, campaign flow, with automations). They are not tied to a specific location or URL.
Considerations
- User flow: Ensure clear exit points (e.g., “Close,” “Save,” or “Go Back”)
- Accessibility: A fullscreen view can be overwhelming; provide keyboard controls, clear labels and clear navigation
- Performance: Optimize loading times to avoid user frustration. If a lot of loading is necessary, consider a dedicated page where the user experience is more predictable.
Fullscreen takeover vs. dedicated page
Unless there are compelling reasons—such as focused complex steps, the need for immersion, or the ability to start from any point within the platform—consider using a new page instead.
The decision between a dedicated page (with a URL) and a fullscreen takeover depends on the context, user needs, and the nature of the task. Below are the key benefits of each approach, along with considerations to help you determine which option is more appropriate.
| Criteria | Fullscreen takeover | Dedicated page |
|---|---|---|
| Focus | Fully focused, removes distractions | Maintains navigational context |
| Reusability | Launch from anywhere | Fixed location |
| Permanence | No URL, less permanent | Bookmarkable, sharable |
| Use case | Quicker interactions, immersive tasks | Complex workflows that need to be referenced |
| Performance | Lightweight, fast-feeling interaction | Predictable loading |
When to choose a dedicated page
Permanence and Shareability
- URL: A dedicated page has a unique URL, allowing users to bookmark, share, or revisit the page later. This is particularly useful for workflows that users may need to return to frequently.
- Example: A dashboard view, a report or a campaign page that users can bookmark, revisit and make edits to.
Navigation Context
- Navigation: A dedicated page retains the main navigation, providing users with a sense of context and allowing them to switch between platform pages easily.
- Example: Users can navigate to other sections of the platform without losing their place in the current workflow.
Performance and Scalability
- Predictable Loading: Dedicated pages often have predictable loading times and performance characteristics, making them easier to optimize for large-scale use.
- Example: A reporting dashboard, expectation of loading is more familiar than in a bespoke display.
Content guidelines
Fullscreen takeover headers should be clearly and consisely written, in sentence case and with no punctuation at the end. Avoid unneccessary or ambiguous words, but include articles like “a” and “the,” as they provide clarity especially in translating.
✅ DO
- Add a new account * Create a new form * Connect your Calendly contacts
🚫 DON’T
Accessibility
Keyboard support
- From the trigger that launches the fullscreen takeover, use
spaceorenterto open tabwill first focus on the drawer dismiss (close) in the header before following the tab order in the body, followed by the fullscreen takeover footer actionsspaceorentercan also be used to select an option from the fullscreen takeover footer
