Minimized Layout

Minimized layout enables an alternate headed UI mode for ambient sessions in the Headed Web SDK. The hosted Suki iframe shrinks to a small overlay so your application stays the main focus. Recording, pause, cancel, and generate still run through the same session; only the surface area of the iframe changes to a small overlay.

​

When minimized layout is available

In the headed iframe, auto-minimize runs when the following conditions are met:

• Ambient and Re-ambient: The minimized UI tracks an active ambient-style session in that iframe. It is not a partner-controlled “small UI” mode for non-ambient flows.
• Minimize capability: The hosted iframe evaluates policy and runtime constraints for the current user or organization before shrinking. The UI requests minimized layout only when minimize capability is on. If it is off, the Headed Web SDK stays expanded and auto-minimize does not run.

​

Common integration patterns and use cases

Plan minimized layout around the host UI that must remain usable while ambient or re-ambient capture continues.

​

Minimized layout capabilities

​

How Minimized layout works

Suki turns on minimize capability in the hosted configuration for eligible partners and users. On your side, ship a correct mount and reclaim layout space so the minimized iframe does not leave a large empty slot in your app.

​

Configure the mount point

In Minimized layout, the SDK draws a small overlay using position: fixed. Fixed positioning is resolved against the nearest containing block, not always the browser viewport. If that block is wrong, the widget can shift, clip, or disappear. Follow these rules when you choose the DOM node where the Web SDK mounts.

​

Where to mount

Mount the Headed Web SDK root on a stable, full-viewport ancestor, for example:

• Mount on document.body.
• A full-height app shell you control (main layout wrapper).
• A side panel that is not nested under an element that applies CSS transforms.

Prefer a host layout with a dedicated slot (for example a flex or grid track) sized for the full headed iframe while expanded, and collapsible when minimized so the rest of your UI can grow into the freed space.

​

Avoid transformed ancestors

Do not mount the SDK inside subtrees that set transform, filter, or will-change in a way that creates a new containing block for fixed descendants. Those properties create new stacking contexts; position: fixed on the iframe may then resolve to the wrong box, which can look like offscreen placement, clipping, or odd layering. If you cannot move the mount, remove or isolate those properties on ancestors above the mount node.

​

Keep overflow visible

While minimized, set the mount element (and any immediate wrappers you own) to overflow: visible so the fixed iframe is not clipped by overflow: hidden or auto scrollers.

​

Reclaim screen space

The SDK sizes and positions the iframe for both headed and minimized modes. Your app still owns the mount container around that iframe. If that container keeps the same width and height as the full headed panel (often about 360×640 px reserved in your layout), you will see a large empty gap even though the SDK UI is already small. After minimize, shrink or collapse that container so your grid, flex, or split view can grow into the freed space. Recommended approaches:

• Drop or lower min-height / min-width on the mount wrapper while minimized.
• Switch the mount slot to auto height, a smaller fixed height, or hide a dedicated “SDK column” until the user expands again.

Match the reserved area to the minimized footprint you want, or remove the reservation entirely if the widget is fully fixed and does not need layout flow space.

​

Next steps

Listen for minimize capability from the parent integration and wire mount sizing in code on the Implementation page.