Rethink app back navigation once again

[jaigak]

Proposal: Rethink app back navigation once again

Back navigation patterns are inconsistent across different apps and a unified, standard model should be introduced.

Summary:

Before Windows 10, this was fairly straightforward. Each app would render its own in-app back button or even a forward button and handle it on its own. On Windows Phone though, there was a system-wide back button and while the app can render its own back button, it was preferred to use the system one because it's connected and global. The same functionality became available in Windows 10 through the SystemNavigationManager API. On tablet mode, it worked very similar to the phone while on desktop, the back button appeared on top of the window. A few years later due to the Sets features (which never really shipped) Microsoft started recommending in-app back button and WinUI did provide an easy way to draw a back button however with this, tablet mode was completely neglected. On desktop mode, already the back button appeared inside the app title bar so moving to a custom one didn't really change the experience however on tablet mode, the back button still existed but now it became really inconsistent because newer apps didn't register for SystemNavigationManager's BackRequested event so the back button on the taskbar would just be an app switcher. For the best experience with a custom back button and tablet mode, an app developer needs to create and handle their own back button in addition to the system one on tablet mode but hide the system provided button on desktop mode. Even more, this is all UWP only. Desktop apps don't work with the tablet mode back button and since Reunion is unifying Win32 and UWP, the model for handling back navigation needs to be rethought to work well in tablet mode.

Rationale

• Unified, consistent model for all app developers
• Improves tablet mode UX

Scope

Capability	Priority
This proposal will allow developers regardless of app type use the SystemNavigationManager API for tablet mode scenarios	Must
This proposal will allow end users to expect a consistent navigation experience across Windows when using in tablet mode	Must

Important Notes

Related Feedback Hub suggestion: https://aka.ms/AAbw6ns

Open Questions

The custom back button model works well on desktop so should that need to be changed for consistency or should we just go back to the world where the back button was controlled by the system using SystemNavigationManager so developers don't need to handle it separately for tablet mode? Or should the tablet mode back button be removed completely which means apps don't have to handle that anymore and can just add a simple custom back button?

[orcmid]

I just installed a Microsoft Sculpt Ergonomic desk set. I am having to relearn touch typing for non-alphabetic keys (though I learned backspace and delete rather quickly, and I am using the numeric pad more :). The mouse has a back button reachable by thumb. I had no idea why that was the default and I have remapped it to toggle mouse velocity/resolution. I am using a desktop PC though. My only tablet device is running Windows XP and I use it as a little Local server for web development.

My only in-use touch devices are smartphones, and since my Lumia went out of support, they do not run any flavor of Windows. Yet the are a pretty common interoperable use case.

This is a long-winded way of me wondering if having a consistent conceptual model across all the common device cases in which Reunion apps will appear is an over-constrained problem. This is not an objection. just a concern.

[sylveon]

I would argue the custom back button model does not work well on desktop. It leads to inconsistent placement, functionality, and, the most annoying of them all, poor support for the back button built-in on mouses.

[orcmid]

And then there's this voice on the matter: https://www.tbray.org/ongoing/When/202x/2021/04/10/The-Sacred-Back-Button

[rkarman]

This is great feedback and I agree that we should really do an extensive overhaul of the back navigation pattern for Windows apps (for example, the SystemNavigationManager is not aware of mouse back buttons, or alt-arrow navigation, etc.). For 2021 though, we are focusing on desktop apps and have higher priority core features to get up and running in the windowing and navigation space before we tackle this particular functionality.

[nickrandolph]

@rkarman I get that the focus is on windowing/navigation but I feel that at least a basic understanding of how the back button will fit into this process would be essential in order to get the former right. How are you planning to provide navigation without supporting a back operation.

[rkarman]

@nickrandolph - the current UX guidance for Windows apps is, as alluded to in the original post, to have in-app affordances for all navigation. That continues to be the guidance for Reunion as well. Since the SystemNavigationManager is not part of Reunion, as per my comment above, there is no "system back button" event for Reunion apps to give guidance on for now.

[shaheedmalik]

@mdtauk

[shaheedmalik]

Here's some previous discussion on the issue:
#563

[mdtauk]

Tablet mode has become a bit of an after thought it feels like, for Microsoft.

Reunion and WinUI are focused on desktop app Devs so I don't see them doing much except for those controls which include a back button by default.

Putting it in the title bar is a bad idea as the button gets so small, and many apps will likely extend their UI into the Titlebar area. So Microsoft should probably create a back button control, with the behaviours needed built in.

The Titlebar height is too short to have a great back button experience, it would conflict with the window's icon too.

The in app back button is best visually and for hit targeting, but needs to also work with the Xbox Controllers B/dismiss button, as well as any hardware or Tablet Mode back navigation

This control should then be used in NavigationView to reduce code repetition, and maintain consistency.

App templates should probably include a Frame control wired up to this back button control. Or the Navigation View

[shaheedmalik]

For 2021 though, we are focusing on desktop apps and have higher priority core features to get up and running in the windowing and navigation space before we tackle this particular functionality.

That's more reason to get it right. "We'll think about it later" is how inconsistencies started in the first place. Isn't the whole point of WinUI and Reunion to remove inconsistencies?