Microsoft-ui-xaml: Proposal: Update back button guidance

[YuliKl]

Proposal: Update back button guidance

Summary

Update guidance for app developers about the back button experience, currently documented here: https://docs.microsoft.com/en-us/windows/uwp/design/basics/navigation-history-and-backwards-navigation

[YuliKl]

Lively discussion about the right placement for the back button in #563

[JustinXinLiu]

I don't think the back button should belong to the NavigationView control at all. We don't need a button there to navigate between pages that are already presented as icons.

Back buttons are simply not at the same logical level as the menu items. It's like we don't need a back button for a tab control. Instead, they should be app-specific and handed by each content page.

[mdtauk]

_This image was my thinking when Sets was coming, connecting the tab to the content_

Inconsistent mixing of Titlebar Back Buttons, and the In-App ones, needs to be fixed. Sets no longer being a thing, means the guidance for back buttons needs to be updated, but that need not mean reversing to the Titlebar.

Some have proposed putting the Back and Sidebar Toggle button on one line, but I believe that is only because not all apps extend into the Titlebar area, where they should do.

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

[mrlacey]

Navigation is done at an app level and so buttons for navigating should be at the same level. It needs to be in a place that is consistent throughout an app and so that means the frame/title.

Building it into individual controls is not the answer as there are multiple controls that may be used for top level navigation or as part of a page in an app that uses another top level control.

The position of the back button should, ideally, also not be used for anything else. Having a space in the screen that is sometimes used to show the back button and sometimes used for the hamburger/menu icon can easily lead to people navigating incorrectly when they activate the button without first checking what it is going to do.

[Felix-Dev]

@JustinXinLiu

Based on my experience and looking at MS apps there are many apps where a back button is being introduced exactly because some sort of navaigation is used in those apps. And looking through the UWP navigation documentation, and also apps, that navigation is now mainly powered by controls such as the NavigationView control. In this case, the navigation target is the same for the top-level app navigation control and the back button. I don't know of many modern UWP where that isn't the case.

It's just logical for me that any top-level app navigation control should come with a back-button. Clicking on the icons only provides me with a natural "forward navigation", so the back button is absolutely needed for "backwards navigation".

[Felix-Dev]

@mrlacey Interesting point about multiple top-level navigation controls in a page. Could you perhaps point me to such a real-life example (just to see how it looks like). On that matter, and perhaps I am picturing this case wrong here, if I have multiple top-level navigation controls on a single page but just one back button, won't I as the user be confused as in where I will navigate "backwards" to when pressing said button? Will I navigate back in navigation level A or will it be navigation level B (C, D, E,....)?

If I understood it correctly, in such a case making every navigation control ship with its own back button will cause no confusion at all: The user will exactly know what context he will navigate backwards to when clicking one of the back buttons.

In fact, at one point I did work on an app which had a top-level navigation realized with a navigation view and one navigatable context itself also had navigatable context (realized as a grid of items where clicking on each item opened an item-specific details page - think a list of albums and clicking on each album showed its content in the same sub-frame). In that case I had a back button for my top-level navigation and also a back button for my album list view, so I could navigate back from an album details view to the album list.

[mrlacey]

@Felix-Dev I was following on the discussion from the original issue where it was suggested that all controls that can be used for top-level navigation should include a back button. I was arguing against this and trying to say that the back button should be at the page level and not controlled by individual controls.

• Some controls can sometimes be used for top-level navigation and sometimes not. such as pivot or Tab controls. You typically want to avoid having multiple back buttons displayed as it can be confusing about which will navigate where/what.
• Sometimes it's necessary to break out of the container of a top-level nav control and display a page full screen. These scenarios then require custom back buttons.
• If individual controls need to reserve space for the back button this would be wasted when they're not being used to display it.
• Having multiple controls contain a back button requires more work for development and testing for both the controls and apps that use them.
• Some apps are built without a standard top-level navigation control but still need a way to navigate backwards through a page stack. They shouldn't be required to implement this themselves as this leads to inconsistency.
• Having the back button provided by the app frame makes it much easier to achieve consistency across all apps.

[Felix-Dev]

@mrlacey

Some controls can sometimes be used for top-level navigation and sometimes not. such as pivot or Tab controls. You typically want to avoid having multiple back buttons displayed as it can be confusing about which will navigate where/what.

I am actually confused by that. If I have multiple different navigation contexts on the same page but only a single back button then that should be confusing, not if each navigation context would have itw own dedicated back button. As I pictured above if I have two navigation contexts A and B but only a single back button, will I navigate back to A or B? I don't know.

Sometimes it's necessary to break out of the container of a top-level nav control and display a page full screen. These scenarios then require custom back buttons.

That's a good point.

If individual controls need to reserve space for the back button this would be wasted when they're not being used to display it.

I think that could be solved in logic part of the standard navigation controls.

Some apps are built without a standard top-level navigation control but still need a way to navigate backwards through a page stack. They shouldn't be required to implement this themselves as this leads to inconsistency.
I guess it depends on how those type of apps would actually look like. For example I could picture a simple app which displays a list of content, each content at a time and below the content backward and forward navigation. There are many possibilities here though.

I'd argue that having the back button baked into much used navigation controls might even provide more consistency because devs are, IMO, likely less willing te re-template an entire control (and perhaps break stuff such as accessibility) to change the position of the back button then a simple documentation will be much less resilient to dev changes ("Eh, but I want my back button to be in some other place. Let's just add one there!").
That could be solved with an app-global back button which instead of being built into specific controls as it is now would be exposed on the app level, such as App.IsBackButtonVisible (this idea might already have been proposed here in this issue, not sure exactly.)

[DragoCubed]

Gnome/GTK handles back button placement, tab placement and title bars a bit differently to MS Edge and Store. I prefer using Chromium/Chrome/Firefox to Epiphany (aka Gnome Web) but that may just me being used to it.