Free window size means layout cannot assume a fixed canvas
Aliases: fluid window layout · free-sized window · no fixed artboard
What it is
A Windows app lives in the window the user drags, not on the panel the device shipped with. Width can fill a display or shrink to a snapped strip. Fluent takes that as a layout premise: widgets cannot be composed against one locked canvas. Call the premise an unfixed window canvas. Phone-style “sign off at one width” clips, overlaps, or leaves empty fields here.
This is not a taxonomy of menus and shortcuts, and not how mouse and touch coexist. It is about space: the independent variables of layout are the current window’s width and height, not the artboard in the file.
Why it happens
People treat a window as a tool, not a poster. Size is a continuous variable in the session: narrow beside a document, wide to compare columns, a different ratio when thrown onto another display. If layout locks a set of coordinates at design time, every runtime size is the “wrong size.” Reflow, wrapping, column changes, and navigation morphs are responses to that continuous variable, not three breakpoint skins.
The fixed-canvas illusion comes from design tools: artboards have a width. If acceptance stares at that one picture, engineering will treat the picture as the contract. The real contract is that the user may rewrite all four edges at any time. The layout system must read “how wide now” as input, not write “how wide in the mockup” as a constant.
Where it stops holding
A full-screen game, a locked-aspect video player, or a bolted kiosk may pin the canvas; that is a product contract, not a Fluent desktop app. A very small window may declare a minimum size and refuse to shrink further, but the minimum must still complete the main task — “please maximize” is not a layout. Displays differ in scale; the same window crossing screens changes logical pixels, and a background authored in fixed physical pixels cracks first. Print and PDF export are a different fixed canvas; do not share assumptions with window layout.
Applying it
- Use flexible containers and wrapping tracks, not absolute coordinates from the mockup. Navigation should change form when the window narrows, not lose entries to clipping.
- Declare a minimum usable width and complete the main task at that width. Below the minimum, limit resize and say why.
- Put very narrow, medium, very wide, and portrait windows on the same acceptance path, rather than signing a single 1280-wide frame.
- Verify by recording a continuous drag from minimum width to maximized, content unchanged. Every clip, overlap, unreachable control, or jump to a “please enlarge the window” empty state treated the canvas as fixed. Repeat while snapped to half the display.