openai-winui-app/references/shell-navigation-and-windowing.md

---

title: Shell, Navigation, and Windowing priority: HIGH tags: navigationview, titlebar, appwindow, multi-window, shell sources: - https://learn.microsoft.com/windows/apps/design/basics/navigation-basics - https://learn.microsoft.com/windows/apps/design/basics/titlebar-design - https://github.com/microsoft/WinUI-Gallery - https://github.com/microsoft/WindowsAppSDK-Samples/tree/main/Samples/Windowing

---

What This Reference Is For

Use this file for top-level app shells, page navigation models, custom title bars, and multi-window decisions.

Prefer

• NavigationView for standard desktop shells with clear top-level destinations.
• A small, stable set of primary destinations.
• Built-in back navigation behavior that matches user expectations.
• AppWindow and Windows App SDK windowing APIs for modern window management.

Avoid

• Overloading the nav surface with every command and secondary action.
• Turning the NavigationView pane into a branded hero area when the user did not ask for custom shell treatment.
• Custom title bar layouts that break drag regions or caption button clarity.
• Multi-window designs unless the workflow clearly benefits from them.

Navigation Guidance

• Use left navigation when the app has several stable, high-level destinations.
• Use top navigation when there are few peer destinations and width is available.
• Use a single-page or document-first layout when navigation is shallow and the user mostly stays in one workflow.
• Keep naming and iconography stable across pages.
• Treat NavigationView as functional shell chrome first. Keep pane headers, footer content, and decorative branding minimal unless the product requirements clearly call for them.
• Prefer the platform's normal pane structure before adding custom logo blocks, taglines, or non-navigation content that changes the shell's native feel.
• For narrow or phone-like widths, stop reserving permanent pane width for desktop navigation. Prefer a minimal or overlay navigation mode, show the pane toggle when needed, close the pane by default after navigation, and give content the width back.
• When a shell enters a phone-width mode, reduce content padding and decorative chrome so the page reads as one primary column instead of a desktop shell with a squeezed content strip.

Title Bar Guidance

• Treat the title bar as functional chrome first, branding surface second.
• Keep empty non-interactive areas draggable.
• Blend title bar visuals with the rest of the app when possible.
• Respect light, dark, and high-contrast states.

Windowing Guidance

• Start with one main window.
• Add secondary windows only for workflows such as document detachment, inspection panes, or tool windows.
• Use Windows App SDK samples for resizing, placement, and window-specific behaviors instead of inventing custom platform abstractions.

Sample and Source Anchors

• WinUI Gallery NavigationView, TitleBar, AppWindow, and windowing sample pages
• WindowsAppSDK-Samples Samples/Windowing
• Learn navigation and title bar guidance

Review Checklist

• Is the navigation model simple and intentional?
• Does the shell still look and behave like a normal WinUI NavigationView unless there is an explicit reason to diverge?
• Does the title bar still behave like a Windows title bar?
• Are back, search, and pane behaviors consistent?
• Is multi-window use justified by the workflow?
• Does the shell intentionally switch behavior at narrow or phone widths instead of leaving a full desktop pane open?