Proposal: Revisit back and hamburger buttons placement for LeftMinimal NavigationView

[YuliKl]

Proposal: Revisit back and hamburger buttons placement for LeftMinimal NavigationView

Summary

Currently, when the NavigationView is closed, the control draws the back button in its top left, and the hamburger button immediately to the right of the back button. When the pane is open, the back button disappears and the hamburger button moves over to be positioned in the top left. This transition looks strange and also results in some usability issues: users are forced to move their mouse to press what feels like the same target.

Rationale

This thread is getting a lot of attention on Reddit, making it look like a Feedback Hub error when in fact this behavior is common to all the navigation menus

https://www.reddit.com/r/Windows10/comments/batj1a/who_designed_this_this_is_bad_ui_design/

Similar feedback and sentiment (posted by the same user) about Store app: https://www.reddit.com/r/Windows10/comments/9kh9hl/microsoft_store_poor_ui_who_designed_this/

Functional Requirements

Number	Goal	Priority
1	Avoid forcing users to move their cursor when clicking on the hamburger in the pane's open and closed states.	Must
2	Ensure that fixing goal 1 results in a reasonable visual lockup.	Must

These changes will only apply to NavigationView's Minimal state, the other modes do not need to be updated.

Proposed Fix

• The placement of the back and hamburger buttons should not change, regardless of the isOpen state of the pane.
  • These images represent the desired appearance when both buttons are visible while IsPaneOpen = False. If IsBackButtonVisible = Collapsed, the back button should not show in the open pane.
    
    
• When the pane is open, the back button will be enabled.
• When the pane is open, activating the back button will close the pane and will not raise any navigation events nor perform any page navigations.
• There will be no change to the hamburger button's behavior, it will continue to toggle the IsPaneOpen property.

Release Checklists

Prerelease readiness

• Dev: quality review + code review done
• Dev: test coverage added
• Dev: initial accessibility review done
• Dev: telemetry implemented
• PM: spec up to date
• PM: feature ready for feedback
• PM: docs.microsoft.com updates ready

Stable release readiness

• Dev: feature previously shipped in a prerelease NuGet package
• Dev: Azure CI tests passing
• Dev: accessibility review done
• Dev: API review done
• Dev: IDL attribute switched from preview to public
• Dev: Add test coverage to the NugetReleaseTest test
• PM: spec done
• PM: glob/loc, privacy, security, license compliance ready
• PM: customer validation done
• PM: docs.microsoft.com updated
• PM: Xaml Controls Gallery updated

[stmoy]

Given the change in landscape and roadmap, the motivations that originally had us introduce the back button into NavView are no longer relevant. Since we're revisiting the back button, we could consider removing it from NavView and giving it back to the shell/titlebar. Thoughts?

[mdtauk]

Given the change in landscape and roadmap, the motivations that originally had us introduce the back button into NavView are no longer relevant. Since we're revisiting the back button, we could consider removing it from NavView and giving it back to the shell/titlebar. Thoughts?

Since it was announced that Sets is not going to happen in Windows - is it time to reconsider the back button in the Shell/Titlebar?

Or does the guidance still make sense to put the back button in the apps.

If this is the case, making it consistent is a key point.

[Felix-Dev]

I loved the idea of Sets and I'm extremely disappointed it was killed by Microsoft.

That said, I do think (especially looking at NavigationView's top-mode) having the back button in the actual control is much better than having it (separately) in the title-bar. With the current design, the back button is clearly visually-related with the rest of the NavigationView and both serve the same functionality, which is navigation.
With the NavigationView also being one of the most popular navigation controls around for UWP (based on Build 2018 UWP session and also looking at a number of maintained UWP apps) I think there are enough compelling reasons to keep the current design as it is.

(And I also hope that MS will reconsider and finally give is us the greatness of Sets system-wide in the future.)

[YuliKl]

This proposal is very specific to NavigationView, which already includes an IsBackButtonVisible property. We're continuing to give app developers a choice to show either NavigationView's back button or the title bar back button.

Revisiting back button guidance all up continues to be interesting to me, but I don't believe impacts controls in this repo. Similarly, the Sets conversation is out of scope for the WinUI repo.

[YuliKl]

The Proposed Fix section of the issue description defines the desired changes. The scope of this proposal is deliberately very narrow. This issue is ready for implementation.

[SavoySchuler]

I linked this proposal on the non-archived Reddit thread - hoping to direct some feedback here! Thanks for picking this up from Reddit, @YuliKl, I'll try to make sure I'm listening there too!

[shaheedmalik]

@SavoySchuler asked me on the Reddit page to leave my feedback here.

Here's a copy and paste of what I wrote:

For something like a back button, consistency is something that a user needs. The placement of it should be predictable and one should be able to dependently count on it being in the being in the same spot across all apps. Whether it's in the title bar or visible, a user needs to know exactly where it is. It should not be dependent on how the app creator designed it.

It should be treated like how the minimize button or maximize button is treated in Windows. In the case of these buttons for example. No matter who I am talking to, I can tell them that they are in the in the top right hand corner.

If something like these buttons were app dependent, you would have them in the top left corner, bottom right corner, that doesn't help anyone.

I use my desktop in Tablet Mode Upwards to 95+% of the time, and some apps, the back button is in the Title Bar, others are visible, and of course the back button is also on the Taskbar. For someone using an actual Tablet, this consistency will benefit them greatly. One shouldn't have to guess where the back button is.

With all of this being said, I tend to always have apps snapped, having the back button on screen would create a better target than having it in title bar.

[Tourniquet88]

Yeah consistency is key here. I guess it would benefit all users 👥 when the back 🔙 button it going back to the title bar. Even now most apps I use have it there. Also its the best way to have consistency with all apps everywhere.

[mdtauk]

Yeah consistency is key here. I guess it would benefit all users 👥 when the back 🔙 button it going back to the title bar. Even now most apps I use have it there. Also its the best way to have consistency with all apps everywhere.

I used to think the TitleBar was a great place for the back button, but the touch target is too small, and it doesn't work well when extending into the TitleBar area, which is essential to make good looking apps with Acrylic.

I think this could be achieved with a PageHeader control, and for controls like NavigationView, Hub, etc to include Back Button support that is there by default, and using a design designed consistently, and for all inbox apps to use this design and Back Button placement.

[shaheedmalik]

To add to what I stated above, app creators shouldn't have the option to pick where the Back button is located, as this choice creates inconsistency. The back button should be treated as a system button like how the close button is treated.

As for the designs in the proposal, they look good to me.

[dpierangeli]

I think that the best position for the backButton is in the App, and the guidelines should be sufficient to create the consistency across Apps.

I like the proposed fix.

[DragoCubed]

I don't have any issues with the touch target of the back button in titlebars. I just tap/click on the top left corner of my screen. As for acrylic in the titlebar area, Settings looks fine with the back button in the titlebar.

There are upsides and downsides to having it in the titlebar and in the app.

[mdtauk]

Here is how I would imagine the Back Button and headers could look.

[shaheedmalik]

Here is how I would imagine the Back Button and headers could look.

To combine the proposal image with yours,
If they (The Back Button, and Menu button are placed in the Title bar and treated as system buttons, that would make things cohesive) It could look like this.

This is kinda how the Store currently looks currently.

Here's another mock up.

[Felix-Dev]

I do think the back arrow should be built into navigation controls like the Navgiation View or Pivot control (that would also mean adding a back button to the pivot control alongside the necessary properties like IsBackButtonVisible - copied over from NavigationView.)
Take the "top" mode of the navigation view, for example:

It makes sense to put the back arrow close to the available navigation options as they are connected functionally - the back button typically navigates back to the content of a previously selected navigation item. Same would go for the Pivot control. The reasoning here is that UI elements working on the same navigation context should also be in close proximity to each other.
That would also imply that if the top-level app navigation control is in the titlebar, the back arrow is also in the titlebar. If it's not, then the back arrow also isn't.

Of course, there are also other navigation elements such as hyperlinks which might be worth thinking about how to include in these ideas. I'd say though that hyperlinks aren't a top-level app navigation control and thus we shouldn't make assumptions how that navigation looks like (i.e. navigation could just happen in a small region of the overall UI).

The Settings app uses both the navigation view and hyperlinks to navigate and since the hyperlinks either navigate to another page in the app or to an external app (such as the Control Panel) the back arrow of the navigation view is just fine there. Whenever you click on the back arrow you return to a page which you could reach with the navigation view no matter how you navigated to it (via the navigation view or hyperlinks).

[YuliKl]

Thank you for the great discussion everyone! While the scope of this issue is very limited and applies only to NavigationView's back button in Minimal display mode, I did create a more generalized issue to track some of the back button discussion all up: #810

Let's move the back button discussion there to keep our issues on track. Thank you for your help in maintaining some sanity in this repo 😎

[SavoySchuler]

Nice idea to split this into a few actionable issues, @YuliKl! And thanks for joining us from Reddit, @shaheedmalik, we're excited to have you! Love the mock ups!

[mdtauk]

Here is how I would imagine the Back Button and headers could look.

To combine the proposal image with yours,
If they (The Back Button, and Menu button are placed in the Title bar and treated as system buttons, that would make things cohesive) It could look like this.

Where does the Hamburger Toggle Icon go when the sidebar is collapsed if inline with the Back Button?

What happens when Back navigation becomes visible, moving the Hamburger toggle horizontally is not an ideal experience.

Keeping the back button in place and moving the Hamburger Toggle down works in both situations, but the uses of the Titlebar Back Button need to be replaced with the Back Button and header style

[shaheedmalik]

@mdtauk The issue was for when the screen was collapse to minimal size. The pivot menu collapses into the hamburger. Your images doesn't show the expanded view. This is why the hamburger needs to at the higher versus the side.

[chigy]

@YuliKl , I am not seeing any mention of documentation or sample. Does this require update if so was that done?

[YuliKl]

@chigy, I don't believe this requires any doc updates. The new behavior should light up in the Controls Gallery once we switch to using a newer version of WinUI. I don't see anything in the NavigationView article discussing the old behavior. I feel like this is a bug fix.

[mdtauk]

@YuliKl Do the images need updating?

[YuliKl]

@mdtauk, which images?

[mdtauk]

@mdtauk, which images?

@YuliKl Any docs images showing the Left Minimal pane, with the Back Button alterations - or mentions of the fact the Back Button in that state will hide the pane?

Added a 'close' button that looks like the 'back' button in MinimalLeft display mode when the pane is open.

[YuliKl]

@mdtauk, I don't see any images of the pane opened in Minimal mode, which makes me believe there are no images to update.

It's true that in this state, the back button will always perform a close action, never a back navigation. But I honestly feel like this is a very small nuance that will 1) feel natural to users and 2) will not require any action by app developers. So I don't see any value in highlighting this issue's fix in the docs. (But we can have a small celebration on Reddit)

[mdtauk]

@mdtauk, I don't see any images of the pane opened in Minimal mode, which makes me believe there are no images to update.

It's true that in this state, the back button will always perform a close action, never a back navigation. But I honestly feel like this is a very small nuance that will 1) feel natural to users and 2) will not require any action by app developers. So I don't see any value in highlighting this issue's fix in the docs. (But we can have a small celebration on Reddit)

And I assume one the pane is closed, the normal Back Button will be visible, and behave like it should, navigating back?

[YuliKl]

And I assume one the pane is closed, the normal Back Button will be visible, and behave like it should, navigating back?

Correct.

[msft-github-bot]

🎉This issue was addressed in #1016, which has now been successfully released as Microsoft.UI.Xaml v2.2.190731001-prerelease.:tada:

Handy links:

• Release Notes
• Official Nuget Release

[YuliKl]

@RBrid, this change isn't working quite as expected. When I explicitly set my NavigationView's PaneDisplayMode="LeftMinimal", the back/close button behaves exactly as expected. However, when NavigationView's PaneDisplayMode isn't set (so defaults to Auto) and I resize my app window to a narrow width (so that NavigationView's DisplayMode becomes Minimal), the correct back/close button does not appear.

So this code snippet is working correctly:

<mux:NavigationView PaneDisplayMode="LeftMinimal">
    <mux:NavigationView.MenuItems>
        <mux:NavigationViewItem Icon="Play" Content="Menu Item1" Tag="SamplePage1" />
        <mux:NavigationViewItem Icon="Save" Content="Menu Item2" Tag="SamplePage2" />
    </mux:NavigationView.MenuItems>
    <Frame x:Name="contentFrame"/>
</mux:NavigationView>

But this code, which should do the same thing as above at narrow window widths, does not work correctly.

<mux:NavigationView>
    <mux:NavigationView.MenuItems>
        <mux:NavigationViewItem Icon="Play" Content="Menu Item1" Tag="SamplePage1" />
        <mux:NavigationViewItem Icon="Save" Content="Menu Item2" Tag="SamplePage2" />
    </mux:NavigationView.MenuItems>
    <Frame x:Name="contentFrame"/>
</mux:NavigationView>

[RBrid]

@YuliKl, I thought the change was intended for LeftMinimal exclusively as seen in the title.
Are you sure a change is needed when PaneDisplayMode is Auto? I don't see the toggle button shifting as I click it in Minimal display mode, using our MUXControlsTestApp. Are you seeing the toggle button moving underneath your mouse pointer?

[YuliKl]

My second code snippet in action.

[RBrid]

Love it, thanks!

[RBrid]

"#1195 - NavigationView: Fixing visibility of close button in Auto PaneDisplayMode and Minimal DisplayMode" fixed the bug with PaneDisplayMode == Auto.

[shaheedmalik]

It seems like this behavior has reverted back to the problem state. I was going to file Feedback in the Hub for this issue appearing again in the Store app when I noticed it is appearing again in Feedback Hub as well. This issue was previously fixed.

It works as intended currently in the XAML Controls Apps still. It doesn't work as intended anymore in Feedback Hub or Microsoft Store,

[YuliKl]

The only app that the WinUI team has direct influence over is the Xaml Controls Gallery. I'm not sure whether the other apps' behavior reverted or wasn't fixed, but we can't force them to use the correct version of WinUI with this fix in place.