Allow app users to resize NavigationView's Pane

Proposal: Allow app users to resize NavigationView’s and SplitView’s Pane component

Summary

App users should be able to change the width of NavigationView’s left Pane in an intuitive way. Because NavigationView uses a SplitView in its template, ideally this modification is made once to SplitView and NavigationView gets resizing for free.

Rationale

When interacting with complex Windows applications such as Outlook, Visual Studio, and Photoshop, users expect to be able to resize the application’s panes to suit their own preferences. Changing the size of component panes to accommodate the user’s work environment is an expected aspect of productivity on larger screens. Xaml’s NavigationView and SplitView controls provide a Pane component for modern apps to show columns of information but don’t include a mechanism for end-users to change the width of these panes. Enabling this behavior will meet user expectations for a common UI capability.

Adding this feature to existing controls, rather than creating a new GridSplitter or similar class, will greatly speed up adoption because app already using NavigationView or SplitView controls will get the new behavior for free without the need for app authors to modify their apps.

Functional Requirements

#	Feature	Priority
1	Provide cursor hover state to make resizing discoverable with mouse	Must
2	Provide pressed state to make resizing discoverable with touch	Must
3	Resizing is performant. Sacrifice live reflow in favor of overall polished experience.	Must
4	Allow resize only when IsPaneOpen=True	Must
5	Provide minimum and maximum open pane widths to limit user preferences within a range	Must
6	Apps can subscribe to an event notification when OpenPaneLength changes	Should
7	Apps can disable resizing, which will turn off the visual affordances	Should
8	Provide ability to resize using keyboard, possibly by entering a keyboard resizing mode via standard shortcut	Could

Usage Examples

Pane resizing would be enabled by default (but apps would be able to opt out by setting a new IsPaneResizeEnabled property). For an optimal user experience, apps should remember user’s preferred width setting between app sessions. To do so, apps would likely choose to add a handler for a new PaneLengthChanged event and save the current OpenPaneLength value before the app closes.

Detailed Feature Design

Open Questions

1. Should panes be resizable in their light-dismiss overlay state?

   • Because tapping outside the pane currently open as an overlay dismisses it, closing the pane, I’m concerned that attempts to resize would become accidental pane dismissals. Having the UI perform an unintended action can be very frustrating.
   • On the other hand, users are not required to attempt resizing panes, especially if they notice a pattern of false dismissals.

2. Should ability to resize using keyboard/gamepad be built into the controls?

   • Keyboard is a popular type of input device and Xaml controls strive to support all types of interaction. But making keyboard/gamepad resizing discoverable is likely to present a significant challenge.

[michael-hawker]

Thanks @RayKoopa for calling that out. In fact, the Photos app is using the new PropertySizer control I mentioned above, which is now in our new Windows Community Toolkit Labs. That’s available to use from Labs, you can find more info from the tracking experiment issue here: https://github.com/CommunityToolkit/Labs-Windows/issues/101

I even have this specific scenario as part of our sample code, you can see how you can use it easily here: https://github.com/CommunityToolkit/Labs-Windows/blob/main/labs/SizerBase/samples/SizerBase.Samples/PropertySizerNavigationViewPage.xaml#L53

[RayKoopa]

For (visual) comparison, the new Windows 11 Photos (Preview) app has such a splitter.