User-controlled layout

Problem Context

• The interface has multiple regions that support one task, such as a queue, selected record, notes, preview, activity, metadata, or action panel.
• Users alternate between comparing regions side by side, focusing on one region, reading long content, editing details, or using a narrow screen.
• Layout choice may be temporary, personal, device-specific, workspace-specific, inherited from an organization policy, or unavailable on small screens.
• Pane arrangement affects focus order, screen-reader order, keyboard shortcuts, scroll anchoring, unsaved changes, validation visibility, and responsive navigation.
• The product may also offer splitters, saved views, dashboards, density settings, themes, and preferences that must remain separate from layout arrangement.

Selection Rules

• Choose user-controlled layout when users choose the arrangement, visibility, or order of workspace regions around the same task object.
• Use window splitter when users only resize adjacent panes with a separator and the broader region arrangement does not change.
• Use custom dashboard when users compose dashboard widgets, add or remove tiles, and persist a dashboard canvas.
• Use dashboard layout when the product defines a fixed monitoring page with widget hierarchy, filters, and drill paths.
• Use saved view when users persist columns, filters, sort, grouping, density, or display mode for one data surface.
• Use user-controlled density when spacing or row height changes but region arrangement stays the same.
• Offer named layouts only when each arrangement has a real task benefit and can preserve selection, focus, drafts, validation, and scroll position.
• Show whether the layout change is temporary, this workspace only, device-specific, account-wide, workspace-wide, or organization-managed.
• Provide reset to default and avoid resetting filters, density, theme, columns, dashboard widgets, or saved views when only layout is reset.
• On mobile or high zoom, translate side-by-side layouts into explicit stacked or focus navigation rather than forcing horizontal scroll.

Required States

• Default layout state with current layout name, scope, affected regions, and reset availability.
• Split or side-by-side layout state showing primary and secondary regions together.
• Focus layout state that hides secondary regions while preserving their state and return controls.
• Stacked or mobile layout state with labelled navigation between regions.
• Inspector-left, inspector-right, or below-content arrangement state when pane position changes.
• Preview-before-save, saved personal layout, workspace-managed layout, and reset-to-default states.
• Unavailable layout state when screen width, policy, permission, or content length makes an arrangement unsafe.
• State-preservation proof for selected item, filters, draft edit, validation, scroll anchor, and focus target.

Interaction Contract

• Changing layout rearranges regions but does not change the active record, dataset, filters, columns, sort, density, theme, or saved view unless the user explicitly chooses those changes.
• The current layout and scope are visible before and after change, and a status region announces the new arrangement.
• Hidden panes remain recoverable and keep their draft, scroll, validation, loading, and permission state.
• Saving layout is a distinct action when persistence goes beyond the current session or current workspace.
• Reset restores only the named layout scope and leaves data filters, density, saved view, and dashboard composition untouched.
• Keyboard order and screen-reader order follow the visible arrangement or provide clear region navigation when stacked.
• Responsive fallback maps each desktop layout to a usable mobile or high-zoom state with no off-screen essential pane.

Implementation Checklist

• Define a layout model with layout ID, region order, region visibility, pane position, scope, persistence, responsive fallback, saved timestamp, and policy owner.
• Keep layout state separate from filters, sort, columns, density, splitter sizes, theme, zoom, dashboard widgets, and saved views.
• Provide named controls for switch layout, preview, save, reset, return to hidden pane, and explain managed or unavailable arrangements.
• Preserve selected item, focused control, draft edits, validation messages, scroll anchor, open panels, loading state, and permission state across layout changes.
• Align DOM order, keyboard order, visible order, and mobile navigation for every supported arrangement.
• Test narrow widths, zoom, long localized pane titles, active form edits, validation errors in hidden panes, keyboard shortcuts, screen readers, and browser back behavior.

Common Generated-UI Mistakes

• Treating layout as a cosmetic preference while losing task state when panes hide or move.
• Combining layout with filters, density, columns, theme, or saved view settings so users cannot reset one without the others.
• Saving a personal layout as a workspace default without scope warning or permission checks.
• Using a side-by-side desktop layout on mobile and creating horizontal scroll or unreachable panes.
• Offering vague icons for layout modes with no labels, preview, current state, or recovery.
• Calling a single resizable splitter a full user-controlled layout when no arrangement or visibility choice exists.

Critique Questions

• Which regions can move, hide, stack, or switch sides, and which task state must survive every change?
• Can users distinguish layout from density, saved view, dashboard customization, and splitter resizing?
• Is the selected layout temporary, personal, device-specific, workspace-wide, inherited, or policy-managed?
• What happens to drafts, validation, scroll, focus, and hidden pane content when the layout changes?
• Does the mobile or high-zoom fallback preserve region order and task completion without horizontal scrolling?
• Can users preview, save, reset, and recover a layout without changing data filters or shared defaults by accident?