Discussion: Keeping Pivot in WinUI 3

[BreeceW]

Discussion: Keeping Pivot in WinUI 3

The release notes for WinUI 3 - Project Reunion 0.5 Preview describe Pivot as “no longer supported” and “deprecated.” Instead, Pivot has been completely removed from WinUI altogether. I found it very surprising that a whole control was pulled out as I was under the impression that WinUI 3 was intended to focus on the underlying platform rather than changing controls.

About twenty hours ago, the guidance on the Pivot, TabView, and NavigationView controls was updated. Notably, these changes included warning us that Pivot may be removed and changing the guidance on TabView. TabView is not meant for static tabs, so Pivot had been suggested as a correct control for static tabs along with NavigationView. NavigationView’s design works for top-level app navigation. If I want to have tabs inside a page, however, the current guidance forces me to have a NavigationView inside a NavigationView, which would be confusing design. So now WinUI provides no control for static tabs. Personally, my app uses Pivot for static tabs, and I would have to write my own control to replace them if I port it to WinUI 3 and Pivot is gone.

If there are technical challenges in porting Pivot to WinUI 3, I would suggest there being a pared-down version that at least has the basic functionality of letting users click between PivotItems.

Pivot is a versatile and beloved control that at the very least should not be a pain point in porting to WinUI 3. I thought people might want a place to discuss how they use Pivot, how Pivot being removed affects them, and how we might be able to move forward (such as with a pared-down control or community control). Issue #4264 asks broadly about deprecated controls—I thought we might want a place to talk just about pivot, which seems appropriate given the number of comments already on announcement #4480.

Related Links

WinUI Project Reunion 0.5 Preview Release Notes Pivot documentation—note new guidance Recent changes to tab guidance Listing of controls in latest preview—note lack of Pivot despite presence of other unrecommeded controls Community maintenance of deprecated controls #4264

[WamWooWam]

I feel I've already made my points relatively clear in #4480, except that we've since noticed that Microsoft.UI.Xaml.Controls.Hub still exists, even though it's been deprecated since Windows 10's launch almost 6 years ago now.

If we're ditching Pivot because it's "Deprecated" (despite very little information about it's deprecation previously), why on earth does Hub still exist?

[robloo]

You're right, it doesn't make much sense to remove Pivot -- instead it should be upgraded to fix the open issues.

Removing this control, instead of deprecating it, creates yet another stumbling block for those moving over to WinUI 3. My company still can't even use the previews due to missing features (which saves me from all the bugs at this point I guess).

Pivot originally was the recommended alternative for TabControl as well. Since then we have finally gotten TabView although it is also intended for a different use case: App-wide, paged, navigation. We are still missing just a basic 'tab control' for general content that can be placed anywhere.

The Pivot control is no longer supported, and has been deprecated in WinUI 3. We recommend using the NavigationView control for your in-app navigation scenarios.

NavigationView is a very heavy control and is not a good fit for a Pivot replacement for a number of reasons several of which you mentioned. It is intended as a top-level control to basically host all pages of your app in various layouts. It isn't designed for nesting or for just lightweight tabbing of options/settings and the like. I can't fathom some decisions from Microsoft these days.

[huoyaoyuan]

The Pivot control is no longer supported, and has been deprecated in WinUI 3. We recommend using the NavigationView control for your in-app navigation scenarios.

In fact, I'm often using Pivot to replace NavigationView.

[mdtauk]

If it were my choice, I would clarify the usage of the control, and discourage people from using it as a top level pattern, citing TabView for a multi document pattern, and Navigation for a structure pattern.

But I can understand there may be a perception of a lack of usage or engagement with the control, and so a judgement of what level of support or uplift is to be considered.

But there should be a process for deprecating that could involve adding it to the toolkit, or creating a legacy nuget package which is provided "as is" for older controls.

[robloo]

Copied from: https://github.com/microsoft/microsoft-ui-xaml/issues/4480#issuecomment-797219390

TabView and NavigationView are very heavy controls and are top-level paradigms, so having a light-weight control as a lower hierarchical level option, is useful.

Exactly. This is why I ask if anyone on the framework team is building apps these days.

Now if it were my choice, I would clarify the usage of the control, and discourage people from using it as a top level pattern, citing TabView for a multi document pattern, and Navigation for a structure pattern.

Agree. There are better choices for top-level navigation patterns like the example given before.

But I can understand there may be a perception of a lack of usage or engagement with the control, and so a judgement of what level of support or uplift is to be considered.

I think this is missing the point. There is a gap in functionality in the framework without the Pivot control. We need a basic, lightweight TabControl equivalent (from the WPF days) to do things such as below.

[robloo]

I get an impression from reading things here and there that this is driven by the Microsoft design/PM teams who do not have experience using controls like this and do not understand why they are needed.

@ranjeshj @chigy @jevansaks @StephenLPeters @ryandemopoulos You are developing a framework for developers (the customer). Developer needs must be paramount and work hand-in-hand with design only when areas overlap. Design should not dictate to developers. PM should not dictate to developers. PM should work FOR the developer team and design team not the other way around. I get the impression the whole decision making structure is wrong for decisions like this to come about (with no explanation or reasoning on top of that).

[omikhailov]

Well, in my opinion, Pivot is overrated control, it is just equivalent of the ListView + ContentControl + Swipe gesture. But using swipe for navigation is not the best practice because this gesture is incompatible with Drag-n-Drop and sometimes causes troubles with ScrollViewers. On the other hand, it is already part of the library and if there are no good reasons to remove it, it would be better to leave it as is.

[robloo]

Well, in my opinion, Pivot is overrated control, it is just equivalent of the ListView + ContentControl + Swipe gesture. But using swipe for navigation is not the best practice because this gesture is incompatible with Drag-n-Drop and sometimes causes troubles

This is certainly true, and Pivot has a lot of other bugs/issues you don't mention. Nevertheless, this control serves a unique function and should not be removed. Ideally, it would be rewritten to fix the issues.

[vitordelucca]

As this is the right topic, I'll explain further on the subject.

IMO, Pivot was originally made for touch-centric metro UI as a top-level pattern. Because of that lack of a few useful controls early on UWP, people started using as a way it was never designed for it.

If you want a top level pattern, there's NavView now. If you want multi-document control, there's TabView now too. And I do say, next step would be a ribbon control for @dpaulino app and others alike.

Pivots is not part of Fluent UI use cases anymore.

However, maybe the best step would be to include Pivots in WinUI 3.0 because of migration from UWP. But with a deprecate warning until newer controls and current controls like NavView get the fixes to fully-substitute and then you remove pivots.

[robloo]

IMO, Pivot was originally made for touch-centric metro UI as a top-level pattern. Because of that lack of a few useful controls early on UWP, people started using as a way it was never designed for it.

You are oversimplifying the history here and missing a major point.

• True, Microsoft designed the pivot for Mobile OS first. It was intended as a top-level navigation for switching between various views of the apps. This is back when there was simply no space for a lot of content and Metro design actively discouraged information-rich UI's. Long before NavigationView and long before the hamburger button, Pivot was the standard for Microsoft apps. I'm with you so far.
• Microsoft created the UWP platform unifying their various UI and app models (sounds familiar?). This new unified framework obviously kept the Pivot from mobile for combability and mobile use. However, UWP was also for desktop apps and anything in-between.
• UWP, as it was also for Desktop apps, was missing a pretty fundamental control: the TabControl. This control is not exclusively for top-level navigation and is more for switching between settings in a widget, side-pane, flyout, or some other subset of a view. Naturally, Pivot was the recommended alternative and we all begrudgingly accepted use of the Pivot in place of the TabControl (even with all it's issues).
• Microsoft creates new controls for top-level app navigation: The NavigationView and the TabView. Both of these controls cover the initial purpose of the Pivot (so you're right there). However, they do not cover the TabControl.
• Microsoft forgets the TabControl even exists as a standard non-toplevel UI element and removes the Pivot thinking it is now replaced.
• Now we have no replacement for TabControl. There is no way to do something like the below in a reasonable way (NavigationView is not reasonable for this scenario)

So to say "people started using as a way it was never designed for" is correct but doesn't account for the evolution after it was initially released. It is the de-facto replacement for TabControl (which isn't intended for top-level app navigation).

If you want a top level pattern, there's NavView now. If you want multi-document control, there's TabView now too. And I do say, next step would be a ribbon control for @dpaulino app and others alike.

You are only thinking of the top-level application navigation patterns. Think TabControl! There are other important use cases not covered by a NavigationView, TabView or even a Ribbon. As @mdtauk stated "TabView and NavigationView are very heavy controls and are top-level paradigms, so having a light-weight control as a lower hierarchical level option, is useful."

[shaheedmalik]

Not to mention NavigationView doesn't support swipe.

[vitordelucca]

You are only thinking of the top-level application navigation patterns. Think TabControl!

I'm thinking about that! TabView samples specifically show usage for TabControl scenario. What exactly stops TabView to be a TabControl replacement? Because I never tried in practice, but in theory, sounds fine. Being honest here.

[robloo]

@vitorgrs

According to Microsoft's own documentation: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/tab-view

In general, tabbed UIs come in one of two distinct styles which differ in function and appearance: Static tabs are the sort of tabs often found in settings windows. They contain a set number of pages in a fixed order that usually contain predefined content. Document tabs are the sort of tabs found in a browser, such as Microsoft Edge. Users can create, remove, and rearrange tabs; move tabs between windows; and change the content of tabs.

TabView offers document tabs for UWP apps. Use a TabView when:

• Users will be able to dynamically open, close, or rearrange tabs.
• Users will be able to open documents or web pages directly into tabs.
• Users will be able to drag and drop tabs between windows.

If a TabView is not appropriate for your app, consider using a NavigationView control.

The control simply isn't designed for TabControl "static tab" scenarios. It's too heavy, interaction isn't ideal and it's overdesigned specifically for the "document tabs" scenario. If they want to rework the control and make it better for other scenarios -- great. Otherwise, Pivot is still a better fit.

[dpaulino]

@robloo well said regarding TabControl and how it can be used in areas that aren't top-level like in that Word screenshot. In Nightingale, there are 4 pivots always visible at almost any given time. Of these pivots, only one is top level. The other three are nested in a way where a NavigationView is completely out of the question and where TabView may not look as great as pivot because two of the pivots live inside a TabView already...

[vitordelucca]

@vitorgrs

According to Microsoft's own documentation: https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/tab-view

In general, tabbed UIs come in one of two distinct styles which differ in function and appearance: Static tabs are the sort of tabs often found in settings windows. They contain a set number of pages in a fixed order that usually contain predefined content. Document tabs are the sort of tabs found in a browser, such as Microsoft Edge. Users can create, remove, and rearrange tabs; move tabs between windows; and change the content of tabs. TabView offers document tabs for UWP apps. Use a TabView when:

• Users will be able to dynamically open, close, or rearrange tabs.
• Users will be able to open documents or web pages directly into tabs.
• Users will be able to drag and drop tabs between windows.

If a TabView is not appropriate for your app, consider using a NavigationView control.

The control simply isn't designed for TabControl "static tab" scenarios. It's too heavy, interaction isn't ideal and it's overdesigned specifically for the "document tabs" scenario. If they want to rework the control and make it better for other scenarios -- great. Otherwise, Pivot is still a better fit.

So, maybe a TabControl fork based on TabView but for lightweight scenarios that old TabControl covers?

Like I said in my previous comment, I do say that WinUI 3.0 should have Pivots, but only as a migration and stop-gap until new controls (and improvements to current ones) are made!

[Neptune-mk2]

I'm only here to voice my support for for keeping Pivot control in WinUI 3, I just recently found out of its complete removal in the reunion preview and am completely shocked to be honest.

The removal would force a lot of already established apps to either write their own custom control or redesign a lot of key parts of an app since there is no easy existing drop in replacement, and the suggestion to use navigation view makes no sense, navigation view is a completely different thing how it comes across as a replacement for pivots is beyond me since using it as a replacement requires you redesign your app.

The other thing I don't understand about the removal is this - Other platforms (ie. Android) recently have began embracing their own pivot like control, if your a cross platform developer and you want to bring a iteration of your app to Windows, replicating what would be a pivot on Windows would now require you to write your own custom control instead of using the existing pivot, or if you follow the suggestion to use navigation view, you would again like I said before have to redesign parts of your app.

[mdtauk]

Another example of Pivot inside a Navigation View Groove Music

[eleanorleffler]

To echo others' responses, my team also relies on the Pivot control heavily. We use Pivots dynamically, statically, and within other Pivots. The removal of the Pivot control was shocking and has us scrambling among other issues we are facing from the previous release. We hope to hear about future feature removals earlier especially as we are getting another release closer to Reunion 1.0! We look forward to hearing the discussion about the Pivot control at this week's community call!

Edit: Upon further investigation, we are finding the TabView Control to work for our use cases - fortunately! Hope others are having similar luck!

[shaheedmalik]

It's literally such a shortsighted notion. Was this decision ran by anyone?

Feedback Hub uses them for heaven's sake.

[Noemata]

Losing the Pivot control certainly isn't the end of the world for WinUI, especially if this change had been made with the initial release. The last preview had it. It was working well. So the real question is ... What master is Microsoft trying to please? For your customers, Pivot was a well established UI pattern. Including it is a win win.

Please stick to the double win approach. A Microsoft win at the expense of your customers will lead to poor adoption. Future WinUI = present UWP UI is the benchmark. Anything less will be a form of failure. If WinUI winds up neutering UWP UI, well then we will have this yet again (apologies to German speakers / turn off sound, it's still tragically funny) :

https://www.youtube.com/watch?v=RRFiu0xfQzw

[terrycox]

I use Pivot for second-level static navigation within Pages, with enough PivotItems that carousels are present in most Pages. While I can convert to NavigatonView, I'm concerned that the change from swiping across the carousel to the overflow menu dropdown will degrade the user experience, although I haven't tried this yet. I get the feeling that this eleventh-hour change won't offer time enough to see what this will do across the developer community.

[robloo]

@anawishnoff

From the community call:

So. We hear you. Our plan for the future is first evaluating all of that great feedback you guys are bringing us and bringing that into our discussions. When we gather around our virtual table and talk about what we are going to do next in this space we really think about, well, you know, our developer community said this this and that. We should think about that. And we are continuing to evaluate this space and actively investigating which controls may add more value to this space. So while we haven't make any decisions yet, the conversations are actively ongoing.

You've been told this is poor direction for the development community. However, you are doubling down it seems and are not going to put the Pivot back in (at least you gave no indication that was even being considered). However, you acknowledge that there are ongoing conversations for what to do in this space. In effect you are forcing a change before there is an alternative.

Strategically it's a mistake. Resources to update the Pivot would be trivial in comparison to the resources that the existing developer community is going to have to expend to work-around this missing feature. You also can't put a price on good-will which you are burning with decisions like this. The attitude of 'we know best' is frustrating (to put it mildly). I bet there are multiple companies that would flat-out pay for the Pivot to be included here so money shouldn't be an issue.

We are asking you not to remove Pivot until there is a clear replacement. Several examples have been given for why Pivot cannot be replaced with NavigationView or TabView.

[Noemata]

How do you maintain the façade of listening to your customers when you don't? Answer, declare the world to be flat and trust only the opinions of a small enclave of trusted cohorts. Pivot(ing) does not belong in a flat world. Looks like WinUI has gone flat. Pivot Microsoft, it will be roundly appreciated.

[mrjfalk]

I use the Pivot a lot in my UWP apps, one of my favorite controls. Really sad to see it go. Even web and iOS libraries of Fluent UI have the Pivot, but not WinUI 😥

[Linjie123]

In my project, I used the pivot control as the unit classification in the content page. Now when I build a new project, I don’t have this control. Using tabview is really bad. I can’t find a better one for the time being.

[Panda-Sharp]

I cannot actually add something to what everybody already said, I can reiterate that Pivot is vital also for our apps, the fact that's not "good for desktop" it's not really true, in fact there is a widely used pivot control, that works perfectly in Desktop, for the web in Microsoft Fluent Design https://developer.microsoft.com/en-us/fluentui#/controls/web/pivot

[robloo]

@ryandemopoulos Confirmed Pivot isn't coming back in the community call. He acknowledged they should have announced this better and there is still some investigation on what to do with nested 'tabs'.

To justify Microsoft's removal of the Pivot, aside from the technical issues, it was mentioned that Pivot usage is very low according to the data Microsoft has. I imagine they pulled this data from the Microsoft store.

Calculating a simple usage percentage (number of apps with Pivot divided by number of apps in the store) is not a good idea. There is a wide range of apps on the Microsoft store and the vast majority are still quite simplistic. Using these simplistic apps (which can and likely have moved on to other controls like TabView/NavigationView) in the metrics incorrectly skews the results. App 'quality' or 'complexity' MUST be factored into the data. Larger apps, or ones with more complex UIs, are much more likely to need the pivot for the scenarios mentioned above -- using it as a TabControl replacement (which is still a justified use for Pivot unlike top-level navigation). These apps are the ones that have tool settings in a side pane or similar concepts. The more-complex and higher quality apps are the ones Microsoft needs to be catering to over the simplistic ones. Weighting all apps the same is a serious mistake.

Again, higher complexity apps are a smaller percentage of apps already and are also more likely to need a Pivot (used as a TabControl). These are also the apps Microsoft wants to be cultivating. However, a simple percentage will not properly convey any of this and in fact works against it.

@ryandemopoulos I challenge you to share the data and full reasoning used to justify this decision so that the community can be on the same page. If it's as clear as you indicate we can all understand Microsoft's decision. instead it seems like you are making big decisions like this while:

1. Not properly understanding what the Pivot was being used for in all cases (creating a feature gap)
2. Not communicating ahead of time big changes like this (as you acknowledged) so you can understand impact and all viewpoints
3. Making decisions like this based on resource constraints at Microsoft and not considering the significantly higher amount of resources required of your customers to work-around this
4. Making changes like this based solely on the direction of the design and PM teams. Developers (or your customer) need to have a stronger voice and should be able to overrule both in this case.
5. Using highly suspect data to justify a decision you already wanted to make

[Jay-o-Way]

Just wanna X-ref a comment with some pretty nice UI examples: https://github.com/microsoft/microsoft-ui-xaml/issues/2310#issuecomment-801259653

[shaheedmalik]

5. Using highly suspect data to justify a decision you already wanted to make

It's definitely 5. When you have Microsoft's own Inbox apps using it to a large degree (Feedback Hub), and no alternative, the decision was made at least a year ago. I know this from previous issues reported in this very GitHub that were denied because they didn't want to work on Pivot.

[Noemata]

Time to build a new Pivot. .... "flogging a dead horse" is an apt idiom at this stage.

[ryandemopoulos]

@Noemata @robloo @shaheedmalik @mdtauk and everyone else on this Issue: I've spent the last couple days reflecting on this. As mentioned on the Community Call, I'm regretful of how we handled the removal of Pivot. Let me elaborate on this a bit:

WinUI is a product with its own ambitions. The reason we removed Pivot wasn’t because of low usage—we removed it because we want to evolve the product (and Fluent design itself) in a different direction. It absolutely was the case of us making an a priori decision to remove it, and we consulted our telemetry to try and determine whether we could safely do this without too much disruption. We’re fully aware of its usage in inbox apps since we work closely with those teams. In terms of raw external (3rd-party) numbers, it is not highly used, and so we felt—incorrectly—that that we could remove it without causing much stress.

That was obviously poor judgment. The error is my responsibility, and from now on I'll endeavor to consult with the community on any features we remove, to the best of my ability. There will be times when we want to change product direction, and Pivot is a good example: we still want to move away from Pivot long term and have better alternatives in place for it. But we also owe it to you, our community, to consult with you before we take actions like that and to listen and adapt our solutions so you aren’t left completely high and dry. We fell short on this and I apologize.

Below is a set of steps I'm proposing to correct this error. Before we implement them, I'd like your thoughts:

1. II think we should restore Pivot to WinUI 3 as soon as possible. It’s clear that customers are actively using it for important purposes, and us yanking it out of the product was frustrating & disruptive. We can alleviate that pain by restoring it asap. (that is likely to be in April, since Reunion 0.5 is too close to shipping and we can’t change the bits now)

2. I'd like to continue the discussion openly in this repo on how we can evolve WinUI beyond Pivot (and deprecate it), while ensuring suitable alternatives are in place. As many of you indicated, you don’t feel an adequate alternative is in place that warrants Pivot's removal; let's discuss how to get that in place so we can evolve WinUI past it, while making sure we all feel feel good about it too. My goal would be to do this before ~Oct 2021, since Reunion 1.0 will ship in Oct and we very much would like to deprecate by that release so we aren't forced to wait all the way until Reunion 2.0 ships (due to our commitment to SemVer versioning).

3. Finally, if October approaches and the community isn’t satisfied with the alternative(s) to Pivot that we’ve worked with you to define, then we’d remove it from WinUI and release the source code. This would be a backstop to allow anyone/everyone to use that source code however they please. An aspiring person could even port it to WCT if @michael-hawker feels it’s a fit 😊. My hope is that we can work together to do better then just a source code dump, but I also want folks to know that we can at least keep this as a Plan B to ensure that Pivot doesn't just disappear into the void.

I'd really appreciate your input on this proposed plan of action. You’re not flogging a dead horse; you’re expressing legitimate frustration/concern that is warranted, and I'm hopeful you'll work with us to try doing this again the right way.

[sylveon]

Finally, if October approaches and the community isn’t satisfied with the alternative(s) to Pivot that we’ve worked with you to define, then we’d remove it from WinUI and release the source code. This would be a backstop to allow anyone/everyone to use that source code however they please. An aspiring person could even port it to WCT if @michael-hawker feels it’s a fit 😊.

Isn't WinUI 3 as a whole supposed to go open source before that?

Also a big issue with putting the source in the WCT is that they're vehemently refusing to use C++ code, which would mean a WCT pivot is C# only (or incurs loading the whole .NET runtime for a single control), which is not a suitable solution for me, which consumes XAML from exclusively C++.

[robloo]

@ryandemopoulos Thanks for your response. It was unexpected and is certainly encouraging to read. I certainly respect several of your points and understand the need to drive evolution (and do look forward to an all-encompassing design refresh). I think we agree that how that was done in this case is the issue.

1. II think we should restore Pivot to WinUI 3 as soon as possible...(that is likely to be in April, since Reunion 0.5 is too close to shipping and we can’t change the bits now)

It's too bad you can't slip this in Reunion 0.5 (although I admit doing it in 1-2 days is tough). I'm sure it was removed with a single commit and adding back removed code is usually quite trivial. Testing is also minimal as it's pre-existing code. Additionally, it's not like Pivot was removed months ago and I expect it's had the necessary changes already to include it in WinUI as-is. Regardless, if the ship has sailed we'll have to live with it. The concern is only that you are missing a lot of feedback from the apps that won't be able to use Reunion 0.5 due to this issue. That might mean more surprises than excepted come Reunion 0.8.

2. I'd like to continue the discussion openly in this repo on how we can evolve WinUI beyond Pivot (and deprecate it), while ensuring suitable alternatives are in place.

I think that's fair. Microsoft should be able to deprecate controls. It's important for advancement to be able to remove old code and embrace new ways of doing things - I fight for that all the time. I'm also no fan of Pivot itself using it only for lack of better options (and have written an issue or two for it that is still open). However, changes as drastic as removing a control must be done slowly, with a heads up (as you are quick to acknowledge yourself), and more importantly: with a clear replacement in mind. I would say the primary issue here is there is no clear replacement and little time for everyone to start writing their own solutions.

It would be great to see the ideas 'in this space' expanded upon in a structured way:

1. Rewrite the Pivot fixing the issues and updating the design
2. Bring back the TabControl from WPF (better data binding and simpler use with both header+content together)
3. Rework TabView and make it usable for all cases instead of only for top-level document style navigation (Can't fix the binding inconveniences though and there are some hardcoded things that will be tricky to change at this point)
4. Adopt more powerful concepts like SwitchPresenter + Radio/ToggleButtonGroup header (More powerful but not as rapid/user-friendly to develop with).

It also might be a good idea to take more than 1 approach at once (short-term/long-term solution).

3. Finally, if October approaches and the community isn’t satisfied with the alternative(s) to Pivot that we’ve worked with you to define, then we’d remove it from WinUI and release the source code.

Sounds reasonable, I just hope October is enough time all things considered.

An aspiring person could even port it to WCT if @michael-hawker feels it’s a fit

It's usually trivial to convert WinUI controls from C++ to C#. This won't be an issue.

@sylveon

Also a big issue with putting the source in the WCT is that they're vehemently refusing to use C++ code, which would mean a WCT pivot is C# only (or incurs loading the whole .NET runtime for a single control), which is not a suitable solution for me, which consumes XAML from exclusively C++.

I'm a big fan of writing in C# only as well but that's certainly a valid point for those apps that require C++.

[marcelwgn]

Isn't WinUI 3 as a whole supposed to go open source before that?

@sylveon I think they mentioned somewhere that open sourcing WinUI 3 will come around Q3/Q4 2021 due to other priorities and the complexity surrounding open sourcing the code.

Also a big issue with putting the source in the WCT is that they're vehemently refusing to use C++ code, which would mean a WCT pivot is C# only (or incurs loading the whole .NET runtime for a single control), which is not a suitable solution for me, which consumes XAML from exclusively C++.

The main issue for the WCT I think is that most devs use C# and are a lot more familiar with that, so having a community driven project in C# makes it easier for folks to contribute to. After all C++/WinRT has a few gotchas and things to keep in mind that you don't have to care about with C#.

Not sure how good that is from a legal standpoint but I was thinking of just keeping a C++ version of Pivot around and ship that given that WCT is very unlikely to switch to C++ and folks like you rightfully don't want to load the .NET runtime. Maybe that would help you?

[lukemcdo]

The problem I have is that I don't understand what about pivot is all that legacy? The swipe gestures are still useful on Windows tablets, which still exist. Beyond that, it's a pleasant tab-like interface that still looks surprisingly modern and integrates fine with current controls.

So what is changing? Underlying implementation, objective of the control, or both? I am not at all attached to the underlying implementation, but the objective of the control is necessary and the feature set it provides is basically a minimum for its replacement. That includes its tablet-friendly nature, which frankly is what I expect the "move away from" comment refers to, and I disagree with. Microsoft clearly wants to revisit tablets at some point. WinUI should be prepared for this.

"As a Pivot user, I expect my tablet users to easily change pivot panes using intuitive gestures."

[mdtauk]

Thank you @ryandemopoulos for your frankness.

I had noted some of the off hand comments and the way people like @chigy had dismissed proposals being made to refresh the Pivot control over the past year. So the writing was on the wall, but nothing was being said publicly and definitively. I had assumed the control would remain, but guidance to stop using it would come forward. I did not think the control would be yanked out of the toolbox however.

Anyway, we should move forward with this. Once inbox apps start updating, we'll have some idea of how Microsoft has decided to rework UI that currently uses Pivot, and that may give direction to others, so they can adapt.

The two replacement UX patterns that have been put forward, both have the same issue. They presume people are using Pivot in the style of Windows Phone, as a top most navigation pattern.

NavigationView has become the new Fluent default control for handling app navigation, and as such breaks when trying to nest a NavigationView inside another NavigationView.

Then there is the TabView which is quite a heavy control to just nest within a page, and again, feels like it should be a top level UX pattern.

Since we have left the Windows Phone world behind, the ways Pivot is used has changed for the most part I think. It is also present within Fluent UI, and so should have an equivalent in WinUI, as there is an intent to blend these two Frameworks together through Fluent Design.

What Pivot breaks down to basically is a lightweight control where tapping on HeaderItems will swap out views containing content. Currently this includes swiping as a shortcut gesture, and an animated transition to reposition the HeaderItems to move the currently selected one to the left most position.

The swiping is something many have called out here, and is something no other controls cover, in terms of functionality.

The HeaderItem transition was needed for the phone UX, but could be lost I think without much fuss. Other versions of the Pivot only move the selected indicator anyway, and this is visually in keeping with NavigationView.

So a control that presents headers, with a toggle like behaviour (only one selection at a time), which swaps out visible content in a region on the screen, with no visual framing or content background and border (which gives it the lightweight feeling) - is what I think would fit the bill as a suitable replacement for those use cases not covered by TabView and NavigationView.

There have been proposals for a SegmentedControl, which is the Apple and Google approach to this design pattern. And that has evolved to the recent #2310 Lightweight radiobuttons in horizontal layout.

If this kind of control were paired with a view control like FlipView, with its gesture support, that would cover most uses of a Pivot.

And the new Expander control could replace uses of Pivot for things like the Terms and Conditions pages in Microsoft News and so on.

Eitherway, thank you for your decision to reinstate the control, at least in the short-term, while perhaps a mini audit can be done to fill in those use case gaps, with a replacement control put in place before 0.8 and 1.0 (3.0 WinUI). The new TabbedCommandBar control in the community toolkit being one such control that relies on a Pivot currently.

I think this discussion issue has done a good job of collating uses of the control that would not be suitably replaceable with the two controls put forward.

And there are proposals that could cover the functionality that will be lost with Pivot's deprecation - as well as aesthetic proposals for a version of the controls design that would make it feel at home with other Fluent Design directions.

[robloo]

@mdtauk

There have been proposals for a SegmentedControl, which is the Apple and Google approach to this design pattern. And that has evolved to the recent #2310 Lightweight radiobuttons in horizontal layout.

This is number 4 in the list of options I wrote above "Adopt more powerful concepts like SwitchPresenter + Radio/ToggleButtonGroup header (More powerful but not as rapid/user-friendly to develop with)."

I know you have been pushing for this but I think it's important to consider other options instead. Also keep in mind:

• Your comment that a SegmentedControl is how Android does tabs is incorrect. Android has a TabLayout
  • https://material.io/components/tabs
  • https://developer.android.com/reference/com/google/android/material/tabs/TabLayout
• Your comment that a SegmentedControl is how Apple does tabs is also incorrect. Apple has TabView (which is designed to look like a SegmentedControl only in the header)
  • https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/tab-views/
• So bottom line, both Android and macOS have specialized controls for tabbing like the old WPF TabControl or even the Pivot
• Having separate header + view switching controls is more complex from a developer standpoint. It would not be as quick to develop with or as intuitive. Loosing the direct link between header + content is honestly not a good idea.
• Separate header + view switcher controls is a more powerful concept though in terms of styling, design, etc. As mentioned I certainly don't think that outweighs the convenience of a Pivot or TabControl.

[shaheedmalik]

Anyway, we should move forward with this. Once inbox apps start updating, we'll have some idea of how Microsoft has decided to rework UI that currently uses Pivot, and that may give direction to others, so they can adapt.

The two replacement UX patterns that have been put forward, both have the same issue. They presume people are using Pivot in the style of Windows Phone, as a top most navigation pattern.

It's if Microsoft, as a whole, wants to distance itself from Windows Phone so much that it is willing to sabotage Touch UX in the process. Windows Phone had some of the best UX designs to the point IOS and Android copied it to various degrees. The problem wasn't the UX, the problem was the mismanagement of the PM teams and Marketing causing it to get out the gate slow. The UX was never the problem.

Microsoft has regressed from the touch standpoint. The Edge team will literally ignore Windows Touch UX feedback sent in, reported on forums or send it to the Mobile team knowing they don't work on the Windows Desktop version of the app. Edge on Desktop from a touch standpoint hasn't reacted parity with Windows 8.1's Modern IE interface. To add insult to injury, some of the touch features of that browser were added to New Edge (ShyUI) and won't even work with touch. They won't even work in Tablet Mode.

Since this is happening, the controls are needed to keep touch in working order. Pivot happens to be one of those controls that simply work. The code might be dirty and need updating, but isn't that the point of Open Source? I have a 2-and-1 and I am forced to use it on laptop mode 99% of the time because I can't use it as a tablet the way I want to and I still use it in Tablet Mode 99% of the time.

Microsoft as a whole has a habit of replacing something with something newer before an adequate replacement is made or feature parity is set and it needs to stop. "Hurry up and release it. We'll fix it later." needs to stop. It serves no purpose but wastes time in the long run for short turn wins.

There were a multitude of projects and apps that Microsoft have released over the years that were good, even ahead of their time, that resulted in low usage rates because something was broken on release, or unpolished and feedback was ignored. The perfect example of this is Paint3D. It was put out as a replacement to Paint but the UX and UI was so bad that nobody used it. Now it has been removed as an Inbox app from Windows 10 because the feedback wasn't acted on. This app could've been fixed with a UI 'Simple Mode' and 'Advanced mode' toggle and the interfaced could've been cleaned up.

The whole purpose of WinUI is to create parity and consistency between the apps, and the user interfaces have to support, keyboard, mouse, gamepad, eye control, and touch.

End Rant.

[robloo]

Can we get a survey run by one of the Microsoft PMs on which of the options developers prefer? I think if Microsoft ran this on twitter or even Survey Monkey it would shed light on how developers as a while approach this topic. If I ran the survey myself I wouldn't get near the visibility Microsoft does.

---

How to handle Tabs in WinUI:

1. Rewrite the Pivot fixing the issues and updating the design

2. 4555 Bring back the TabControl from WPF

3. Rework TabView and make it usable for all cases instead of only for top-level document style navigation (similar to WCT TabView)

4. 2310 Adopt other concepts separating header and view switching such as SwitchPresenter + Radio/ToggleButtonGroup

5. Something else not listed
6. Don't add a specialized TabControl (this doesn't affect me and NavigationView/TabView work for my needs)

[mdtauk]

This is number 4 in the list of options I wrote above "Adopt more powerful concepts like SwitchPresenter + Radio/ToggleButtonGroup header (More powerful but not as rapid/user-friendly to develop with)."

I didn't say using the proposed control is the only way to create a new control to replace Pivot, just that it takes an existing useful control proposal (that should be created and included anyway, used for CommandBars and other tool surfaces), and uses it with another existing control which already supports swipe gestures. There are lots of other ways this can be done, all with pros and cons to those who will use it, and those who have to code the control itself.

I know you have been pushing for this but I think it's important to consider other options instead. Also keep in mind:

• Your comment that a SegmentedControl is how Android does tabs is incorrect. Android has a TabLayout

  • https://material.io/components/tabs
  • https://developer.android.com/reference/com/google/android/material/tabs/TabLayout

The TabLayout is basically a Pivot. If the team were open to keeping the Pivot, then we wouldn't be talking about working around its removal. TabView exists, but it is not always an appropriate choice where a lightweight solution is needed. If the propsal for horizontal aligned button group is taken forward, that could still work with this SwitchPresenter control right? We are still talking about one control to display Tab/Pivot Headers, and another to contain the content for the Tab/Pivot content?

• Your comment that a SegmentedControl is how Apple does tabs is also incorrect. Apple has TabView (which is designed to look like a SegmentedControl only in the header)

  • https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/tab-views/

I look at iTunes as an example of a pivot like control for changing views, as a comparison with Groove, so the two examples are similar enough.

Taking the TabView example in their HIG

This looks very similar to their Segmented Control (which the article points out), only overlayed onto the views that hold the Tab content.

Also the Finder (macOS's File Explorer) has a different take on tabs, which are more like the Browser style tabs

---

• So bottom line, both Android and macOS have specialized controls for tabbing like the old WPF TabControl or even the Pivot
• Having separate header + view switching controls is more complex from a developer standpoint. It would not be as quick to develop with or as intuitive. Loosing the direct link between header + content is honestly not a good idea.
• Separate header + view switcher controls is a more powerful concept though in terms of styling, design, etc. As mentioned I certainly don't think that outweighs the convenience of a Pivot or TabControl.

My understanding of your proposal, is that every dev would have to manage their own presentation of Tab/Pivot items, and write their own code to link the views to the selector control (using SwitchPresenter)...

My idea would be to create a single control, that internally uses one control to display Headers/Tabs (The ButtonGroup control for instnace), and another that contains or manages the views/content (the SwitchPresenter) then the developer need not have to roll their own solution when moving from Pivot to this new replacement control, and you could copy the Xaml content from an existing Pivot and move it to this new control.

Some Issues I foresee will be:

• How to re-introduce a swipe gesture to change views, which is one reason many want the Pivot to stay (maybe with the ability to turn it off);
• What would this composite control be called? TabView is taken, and anything else with Tab in the name could be confusing.
• How do you handle the content panels? Pages... UserControls... ...
• The SwitchPresenter will need to be ported from the Toolkit to the WinUI repo, and be made C++

[mdtauk]

Here are my views on these options you propose

1. Rewrite the Pivot fixing the issues and updating the design

Microsoft wishes to move away from this control's aesthetic and functionality - rewriting this control could break existing apps, whereas a new control allows for breaking changes, and providing an alternative Microsoft wont be "ashamed" of :)

2. 4555 Bring back the TabControl from WPF

As long as its not got Tab in the name I am happy to see a light-weight alternative to the TabView. All throughtout the development of that control I was pointing out uses like toolbar and property panes where the control should be made suitable for.

3. Rework TabView and make it usable for all cases instead of only for top-level document style navigation (similar to WCT TabView)

TabView when used as a top-level navigation pattern has many of the things it needs, and as such should not be compromised when a custom control would be a more appropriate option.

4. 2310 Adopt other concepts separating header and view switching such as SwitchPresenter + Radio/ToggleButtonGroup

This could be wrapped up into a new TabControl like control, so developers can get the benefits of this approach, and not find it too difficult to transition from the current Pivot control

5. Something else not listed

😁

6. Don't add a specialized TabControl (this doesn't affect me and NavigationView/TabView work for my needs)

This would also affect the TabbedCommandBar control, which is gearing up to be an alternative to the Ribbon control that Microsoft have been reluctant to bring to the WinUI toolset. The Ribbon being another control which theoretically would use a Pivot as a Template Part

[robloo]

@mdtauk

The TabLayout is basically a Pivot. If the team were open to keeping the Pivot, then we wouldn't be talking about working around its removal.

TabLayout is a tab control. Pivot is like a tab control in several use cases. Microsoft acknowledges we need to do something about tabbing for the cases previously described. While they may not keep Pivot in name, the concept of 'tabs' stays and without Pivot there is a feature gap in tabbing functionality. Android follows the described tabbing concept in this control. I think Microsoft dislikes the Pivot for several reasons including legacy code, outdated interaction, unpatched issues, misunderstanding that it was used only for top-level navigation, etc. Microsoft is still open to a control that takes Pivots use cases so I guess I disagree with your assertion here.

Taking the TabView example in their HIG...This looks very similar to their Segmented Control (which the article points out), only overlayed onto the views that hold the Tab content.

Yes, I pointed out the same. My point was that header + content switching is integrated together. I had the impression that you were advocating for separate controls for that. However, it seems I was mistaken:

My idea would be to create a single control, that internally uses one control to display Headers/Tabs (The ButtonGroup control for instnace), and another that contains or manages the views/content (the SwitchPresenter) then the developer need not have to roll their own solution when moving from Pivot to this new replacement control, and you could copy the Xaml content from an existing Pivot and move it to this new control.

If the more 'primitive' controls were wrapped and integrated as you describe in a higher-level control I have no concerns. I just want to see the header and content stay together.

[mdtauk]

TabLayout is a tab control. Pivot is like a tab control in several use cases. Microsoft acknowledges we need to do something about tabbing for the cases previously described. While they may not keep Pivot in name, the concept of 'tabs' stays and without Pivot there is a feature gap in tabbing functionality. Android follows the described tabbing concept in this control. I think Microsoft dislikes the Pivot for several reasons including legacy code, outdated interaction, unpatched issues, misunderstanding that it was used only for top-level navigation, etc. Microsoft is still open to a control that takes Pivots use cases so I guess I disagree with your assertion here.

I agree, I think it is down to the association with Windows Phone, as well as issues with scrolling content and swipe gestures conflicting - as well as likely calls to Win8 touch interactions that may not exist when lifted from the OS.

The name Pivot is used with FluentUI and it is the functional equivalent of a Tab in the general sense.

The TabView control could cause confusion if a new Pivot replacement was also called TabSomething . That is my only concern when it comes to the name. Whatever replaces Pivot when not covered by the TabView or NavigationView would not be much different from a Tab control or the current Pivot, from a user point of view.

Taking the TabView example in their HIG...This looks very similar to their Segmented Control (which the article points out), only overlayed onto the views that hold the Tab content.

Yes, I pointed out the same. My point was that header + content switching is integrated together. I had the impression that you were advocating for separate controls for that. However, it seems I was mistaken:

My idea would be to create a single control, that internally uses one control to display Headers/Tabs (The ButtonGroup control for instnace), and another that contains or manages the views/content (the SwitchPresenter) then the developer need not have to roll their own solution when moving from Pivot to this new replacement control, and you could copy the Xaml content from an existing Pivot and move it to this new control.

If the more 'primitive' controls were wrapped and integrated as you describe in a higher-level control I have no concerns. I just want to see the header and content stay together.

That is what I was proposing, wrapping a ButtonGroup (for displaying pivot/tab headers) and a FlipView (for displaying pivot/tab content) into a single control. My reasoning for suggesting the FlipView is because it supports swipe to change views (a two way binding with the ButtonGroup could ensure Headers and Content remain in sync)

Using existing controls would help get this control done in time for WinUI 3.0 release which is the priority for Microsoft.

A new implementation with the name Pivot would be a breaking changed. A name with Tab in it may be confused with the TabView, so a new name would probably be needed. In your TabControl proposal I said ViewSwitcher could be a suitable name.

[ryandemopoulos]

I'm tied up today preparing for a major deadline on Monday, so probably won't be responding to the various replies here for a bit. Sorry for the delay; will likely get back to this next week. I've already started the ball rolling on getting Pivot back into WinUI 3 for April, though, as a first step.

[mdtauk]

I'm tied up today preparing for a major deadline on Monday, so probably won't be responding to the various replies here for a bit. Sorry for the delay; will likely get back to this next week. I've already started the ball rolling on getting Pivot back into WinUI 3 for April, though, as a first step.

Good Luck with the deadline @ryandemopoulos, we will all be here when you are able to respond or engage with the conversation.

Would be interesting to see examples of where inbox apps have replaced their usage of Pivot, to see where the thinking is.

[ryandemopoulos]

On that specific point, not all of our inbox apps are under active UX development. (they're usually all under some amount of development, but not always looking to change UX and some aren't planning to use WinUI 3 any time soon) So although we have used it a fair bit in the past, WinUI 2's stack still has Pivot -- it literally can't be removed -- and so this isn't much of an issue for most of those apps.

[mdtauk]

On that specific point, not all of our inbox apps are under active UX development. (they're usually all under some amount of development, but not always looking to change UX and some aren't planning to use WinUI 3 any time soon) So although we have used it a fair bit in the past, WinUI 2's stack still has Pivot -- it literally can't be removed -- and so this isn't much of an issue for most of those apps.

I guess that is understandable, if a little unfortunate. But who knows, maybe like Calculator, they may get open sourced in the future.

• Groove has felt abandoned for a while;
• Mail, Calendar, and People are due to be replaced with this One Outlook hybrid web and native app;
• Paint 3D and all the other 3D apps likely to be untouched now;
• Store is a bit limbo, its also a hybrid app, with its webviews - but I don't think that is being left behind;
• I can see Microsoft News and MSN Weather being supplanted by PWAs - like the News and Interests flyout with insider builds;
• Films and TV makes sense to be part of Xbox's oversight, and Xbox hasn't gone full Fluent yet
• Photos and Camera hopefully may find some future development with new Surface devices, possibly cross platform app with Android and Surface Duo;

[terrycox]

@ryandemopoulos Thanks for this update. Making these changes at this late date must be both complicated and costly. I use pivot, but not as a top-level navigation control, as per this: TabView and NavigationView are very heavy controls and top-level paradigms, so light-weight control as a lower hierarchical level option is useful. My Xaml for each tab is inlined in each PivotItem. If Pivot is (was) removed, I'd switch to NavigationView. Still, my concern would be more about user interaction with carousel behavior changing to a drop-down for the tabs that don't display. I'd likely never have used Pivot had I known it was deprecated. I don't recall seeing any compile errors informing me of that. My other concern is that waiting until April or whenever means waiting to move to 0.5. That can be mitigated by doing other things like moving from MVVM Light to the WCT MVVM, which is, as far as I'm concerned, the other 'forced to change' bit associated with WinUI 3.

[lukemcdo]

That is what I was proposing, wrapping a ButtonGroup (for displaying pivot/tab headers) and a FlipView (for displaying pivot/tab content) into a single control. My reasoning for suggesting the FlipView is because it supports swipe to change views (a two way binding with the ButtonGroup could ensure Headers and Content remain in sync)

Using existing controls would help get this control done in time for WinUI 3.0 release which is the priority for Microsoft.

A new implementation with the name Pivot would be a breaking changed. A name with Tab in it may be confused with the TabView, so a new name would probably be needed. In your TabControl proposal I said ViewSwitcher could be a suitable name.

This proposal looks good to me. Could always do FlipPivot, which would show up in intellisense for pivot, and flip, indicating the underlying technology being used for the content area.

[SuperBrain]

Looking at apps in near future ... Something's weird here ... Every single app looks very similar to every other app ... I wonder why this is the case?