Allow app users to resize NavigationView's Pane

[YuliKl]

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.

[mrlacey]

OpenPaneWidth, not OpenPaneLength
and
PaneWidthChanged, not PaneLengthChanged

To make (re)setting a remembered width easier, can OpenPaneWidth be bindable?
Also, need to ensure that this can easily be set before the UI is first rendered with the default width. This is to avoid any delay, flicker, and re-layout when launching the app.

Can an example of persisting pane width be a requirement for documentation?

[YuliKl]

OpenPaneWidth, not OpenPaneLength

OpenPaneLength is an existing property on NavigationView. (Developers can already change the width of the Pane using this property).
In case you're interested in the history, this property name was copied from SplitView. SplitView, in turn, used "length" instead of "width" because there had been the possibility of allowing the pane to open up or down in addition to left or right. SplitView has not been extended in this way, its pane can only be vertical, but the property name was future-proofed just in case.

Can an example of persisting pane width be a requirement for documentation?

Absolutely!

[mdtauk]

There is a splitter control for resizing elements. I would suggest if that were to be added to the SplitView control, and inherrited by the NavigationView - the default should be set to False.

The control could also have the ability to remember the new OpenPaneLength so navigating to and from, or re-opening the app restores that value.

It may also be prudent to include a Maximum and Minimum PaneLength. Also perhaps dragging below the Minimum length could toggle the Pane to Closed.

[YuliKl]

The control could also have the ability to remember the new OpenPaneLength so navigating to and from, or re-opening the app restores that value.

It's an interesting idea but would be a change from how Xaml controls behave today. While we specify defaults, no control that I can think of saves any values from runtime. I don't think we have a place to store this kind of information.

[mdtauk]

The control could also have the ability to remember the new OpenPaneLength so navigating to and from, or re-opening the app restores that value.

It's an interesting idea but would be a change from how Xaml controls behave today. While we specify defaults, no control that I can think of saves any values from runtime. I don't think we have a place to store this kind of information.

Ok, so perhaps there is an Internal value, and if no default is set in XAML, it just uses that value?

If not, then maybe offer guidance and sample code to implement it as a recommendation? The mail app currently supports this for its left most sidebar.

[YuliKl]

@mdtauk - I think remembering the user's preferred width (like Mail) needs to be the app's responsibility. That's the documentation piece that I beleive @mrlacey is asking for as well.

[mdtauk]

@mdtauk - I think remembering the user's preferred width (like Mail) needs to be the app's responsibility. That's the documentation piece that I beleive @mrlacey is asking for as well.

That is fair enough. :)

The ability to resize should still be considered for the SplitView control, and inherited by the NavigationView. Then developers can implement the save and recall of that OpenPaneLength value, with perhaps the Max and Min Lengths to constrain the resizing.

[atiyka]

Hi, I would like this feature as well, what is the current state?

[michael-hawker]

FYI, in the 8.0 release of the Windows Community Toolkit later this year we'll have a new PropertySizer (name TBD) control which enables this scenario on a NavigationView out-of-the-box with no modifications. It will be the sample for this control in our sample app. If you want to try it out, you can find out PR for it here: CommunityToolkit/WindowsCommunityToolkit#4083 (though we need to fix a CI issue hopefully on Monday to get a nice PR based NuGet package for it.)

[RayKoopa]

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

[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: CommunityToolkit/Labs-Windows#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