Design

Design multi-window layouts

Updated: Sep 3, 2026

A layout can hold supporting content beside an app’s primary window, keeping navigation, details, or repeated controls visible while someone works in the primary window.

Start with one primary window

Give the layout one clear primary window. It should hold the main task, the current context, and any action someone has to complete.

Each supporting window adds information to scan and another place to look. Work through this checklist before adding one:

Is the need persistent, or does it only apply for a moment?
Is it useful while someone is actively working in the primary window?
What is the relationship between the supporting content and the primary window?
What are the hero experiences, or the tasks that define the app?
Who decides where the content lives: the person, or the app?

Decide who controls the layout before choosing a pattern. Preserve that ownership throughout the task.

A supporting window may fail to appear, be displaced when capacity is limited, or be closed by the user or system. Treat supporting windows as enhancements:

Keep essential activities and navigation available from the primary window
Give each supporting window one clear purpose
Remove duplicate controls that compete with the primary task

The app should stay understandable when only the primary window is visible. A supporting window can shorten a workflow, but it should not become the only route to a critical action.

Choose a pattern

Supporting panels belong with the primary window, remain grouped with it, and move as one unit.

Pattern	Use it when	Keep in the primary window
Navigation and primary content	People switch sections often	Current page and main actions
Primary content and details	People need context for a selected item	Item list, selection, and main action
Primary content and compact controls	People repeat a small set of controls	Controlled content and a way to open the controls

Do not separate content only to fill space. Keep information together when people have to read it together or compare it line by line.

Use a supporting navigation window when people switch sections often and benefit from seeing their location. Keep the current section and its actions in the primary window.

Deep navigation hides top-level destinations as someone drills into a section, forcing them to back out to reach another one. Persistent supporting navigation keeps those destinations reachable without that detour.

Avoid this pattern for a short flow with only a few steps. Navigation inside the primary window is easier to scan.

Primary content and details

Use a details window when someone selects an item in the primary view and needs more context without losing the collection. Update the details window with the current selection, and preserve that selection when the window cannot appear. See Design for limited space.

Avoid moving the main action into the details window. People should not have to look back and forth to understand what will happen.

Primary content and compact controls

Use a supporting controls window for a small set of repeated actions, such as media controls or a focused tool palette. Keep the controls stable while the primary content changes.

Avoid turning the supporting window into a second full interface. If the controls need their own navigation or several levels of settings, return them to the primary window.

Keep hierarchy and visual flow clear

Arrange windows in the order people need them. The primary window should draw attention first, followed by the supporting window that helps with the current task.

When the app controls window orientation, angle supporting windows toward the viewer instead of keeping every window on the same plane.
Place related windows near each other
Align content that people scan in sequence
Keep labels and interaction patterns consistent across windows
Avoid motion or animation that competes with the primary task
Avoid layouts that require repeated large head turns

Interactive elements must remain comfortable to target in every window. Follow inputs and hit targets for current target-size and spacing guidance.

Meta VR Layout SDK spatial windows do not support transparency. You must fill and paint the complete root of each window with an opaque background. Arrange windows so one does not cover content in another. See Meta VR Layout SDK layout best practices and Meta VR Layout SDK troubleshooting.

Design for limited space

Do not make a task depend on a fixed number of supporting windows. Keep critical content and a route to each supporting task in the primary window.

Design for one primary window and no more than two supporting windows that are important at the same time. This is a design target, not a capacity limit. Platform capacity varies.

For every supporting window, decide what happens when it cannot appear:

Render the content inside the primary window
Keep a route to the content from the primary window
Delay nonessential content until space is available
Remove extra or repeated content

Preserve someone’s work when a supporting window appears, disappears, or returns. Selection, playback, and task progress should not reset because the layout changed.

Do not use main-window sizes as limits for other windows. Size each window for its content, and test the group at different viewing distances. See layouts for responsive main-window guidance.

Keep supporting windows in sync

Supporting windows should share the same state as the primary window they belong with. A change in one should update the others without creating conflicting selections or controls.

Use these rules:

Give one window ownership of each action
Reflect the result in every affected window
Preserve focus when content moves between a supporting window and the primary window
Close or update supporting content when its source item is removed

Design the window group so it remains in a predictable location after the primary window is repositioned. Avoid a layout that makes someone search for a supporting window after moving the app.