The app may own only a slice of the screen

What it is

Tablets and foldables let two apps—sometimes three—stay visible at once. The app may own only a slice of the screen means layout is measured against that window, not against the whole piece of glass. System split-screen, slide-over, stage-style windowing, and freeform windows can cut an app from full screen to half, to one-third, or to a small draggable pane while it is running. An app that still lays out as “I am this display”—full-width navigation, a full-screen splash, a dialog centered on the glass—will clip type in a half-window, stack layers, and push a primary button into the neighbor. How narrow that slice can get, and what cross-app drag is for, are separate entries.

Why it happens

Full screen is one window metric; split-screen is another. Width, height, and insets become those of the cell, but a lot of tablet code grew from phone full-screen and treats display width as window width, and the physical bottom edge as its own bottom. After a split, a bottom bar may paint over the neighbor’s content; a modal centered on the display lands on the divider or in someone else’s window. System gestures (home swipe, edge back) still play on the whole glass, so in-app edge gestures are easier to steal. The user can also drag the divider mid-task, so “only a slice” is not a form chosen at install; it is a state entered and left during work. Entering split-screen through a launch layout makes the app look restarted.

Studying it

On one tablet, compare full screen, half, one-third, and a slide-over pane on a path that includes a nav bar, a form, and a dialog.

Independent variables: layout against window metrics versus display metrics, whether dialogs are clipped to the app’s window, whether the UI is recreated when entering split-screen. Dependent variables: clipping, controls painted outside the window, dialogs in the neighbor, task breaks that feel like a restart.

Let participants drag the divider and invoke split themselves; do not only prepare four static sizes—the jump lives in the drag. Do not substitute desktop multi-window data: tablet split usually has no draggable title bar, and the paths for finding and closing a window differ from desktop.

Where it stops holding

On a device the user never splits and whose OS has no multiwindow, the full-screen assumption holds. Games and full-screen video may refuse split-screen or pause on entry, but they have to say so rather than keep rendering as full screen in a half-window and claiming to be playable. An app’s own two panes are inside the window; split-screen is outside it. Two panes in a half-window may still need to collapse to one—that is not enough width, not “the app still owns the display.” On an external display a tablet sometimes becomes a freely resized window; treat that as a desktop window, not as a fixed half-and-half.

Applying it

• Measure every layout against the app’s own window width, height, and insets. Do not read display width to place navigation and bottom bars.
• Keep dialogs, menus, and toasts inside this window. Do not center them on the display.
• Listen for window-metric changes; reflow from full screen into split-screen instead of walking a launch page.
• Verify by dragging the app to half and to one-third, walking the main path, and opening a dialog. Any control outside the window frame, or a dialog sitting on the divider, is still laid out against the whole glass.

Related

• Within the group: K3.05.2 A split pane can be narrower than a phone · K3.05.3 Cross-app drag and drop is what split-screen is for
• Adjacent: K3.01 Large-screen Two-pane Layout · K2.01 Window Management · K3.03 Fold-state Transitions
• Search terms: split-screen window · multiwindow tablet · window metrics