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: #4480 (comment)

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.

[terrycox]

'Waiting for April' is now waiting for when? When can we expect the 0.8 preview?

[mdtauk]

'Waiting for April' is now waiting for when? When can we expect the 0.8 preview?

Build is next week...

[mdtauk]

Posted something from Flutter for the Material You updates for Google
#2310 (comment)

May be helpful for a Pivot replacement, a NavigationBar

[knightmeister]

+1 on I think that Pivot should be retained. The control has a very different look and feel when compared to a NavigationView. Sure, it's used to switch between views, but it is more suited to small user interfaces.

This raises a larger concern for me in that what is the decision process behind this and are other controls going to arbitrarily discontinued?

I can't find the code for Pivot in the repository (is it even here?) but I can't imagine it is obviously difficult to support...

I'm all for Microsoft becoming more ruthless with removing dead code, but there is a certain irony that Windows still supports many dead controls, like when was the last time someone used the Win32 pager control?

[mdtauk]

Has there been any decisions made as to what will replace Pivot in all the inbox apps in Windows 10 (or the soon to be announced Windows 11)?

Fluent UI supports Pivot still with no talk of it being deprecated - and it supports Android's Tabs and iOS' Segmented Control - as well as the various UI view changers. A discussion exists for a Horizontal Grouped Button like control, which could take the place of at least the Pivot Items Header part of the control.

Win32 apps have the Tab Control, which is in use with the Properties Dialog in File Explorer, as well as various other dialogs in the shell.

So WinUI should have an equivalent, which is in line with Fluent UI which is it's cross platform counterpart.

Pivot is staying for now, but its old code you probably want to excise. So you could create Pivot2, like WebView2 - re-written to be nicer/more modern code. Or you could decide on #2310 and begin work on this proposal, and use it for a pivot replacement.

[mdtauk]

The Windows 11 store has one kind of Pivot like control, on the Library page

[dpierangeli]

The Windows 11 store has one kind of Pivot like control, on the Library page

In that context I think that they are only horizontal buttons.

[mdtauk]

The Windows 11 store has one kind of Pivot like control, on the Library page

In that context I think that they are only horizontal buttons.

Buttons that exhibit a RadioButton like behaviour where only one is "selected" at a time

[WINMAN174]

TabView is fat, NavView is obese and Pivot is a lean mean fighting machine. We need them all.

[ghost]

This one might fit better as a grouped selection control rather than Pivot, because it doesn't really navigate between pages.

[mdtauk]

This one might fit better as a grouped selection control rather than Pivot, because it doesn't really navigate between pages.

Well that is the proposal that is closest linked to a Pivot replacement.
#2310

Using this new control as a primitive, tied to some kind of view panel

[LancerComet]

If you were using a Surface as the daily driver you should have known how important the swiping gesture is.
I just wonder that do designers at Microsoft use touch devices with a mouse at anytime by any case?
For the user experience, Pivot is the alpha, NavView SUCKS.
I give up porting my comic reader UWP to .NET WinUI 3 just because lacking of pivot.

[knightmeister]

I want to reiterate the earlier sentiments made by others about why it is useful to have different controls - I can absolutely see the use case for pivot, nav view and tab view.

Has a decision been made as to whether this will return?

It feels like the response from Microsoft has been tone deaf and has not read the room well at all.

[kmgallahan]

Pivot was added back with release .8 Preview in May. Is there something I'm missing, or were you two not aware of this? Does swipe not work with it? @LancerComet @knightmeister

[kmgallahan]

@StephenLPeters Is this issue still relevant in some way or should it be closed? I'm unsure if there is still any discussion about Pivot removal to be had here since it has been available for 6 months and made it into the final 1.0 release.

[LancerComet]

@kmgallahan There is no Pivot control in WinUI 3 Gallery App, that is misleading. People would check this app before using the WinUI 3 I believe

[kmgallahan]

@stmoy Can the Pivot control be added back to the 3.0 version of the Gallery without much trouble?

[knightmeister]

Pivot was added back with release .8 Preview in May. Is there something I'm missing, or were you two not aware of this? Does swipe not work with it? @LancerComet @knightmeister

I didn't realise it had been added back, I checked the WinUI gallery and skimmed this thread and it wasn't obvious to me it was available. Glad to know it's there and ready to use.

[StephenLPeters]

@gregwoo-microsoft Can we look into adding Pivot back to the Winui3 gallery?

[mdtauk]

What control is being used for the new Media Player app here? It looks like a Pivot. Could this become a third party replacement?

[gregwoo-microsoft]

@mdtauk I've asked the MediaPlayer team and will update this thread when I get an answer.

[gregwoo-microsoft]

Hey @mdtauk! To follow up, the MediaPlayer team is using a customized NavView control in the screenshot you've shown. Btw to answer the comments from a few others, we have recently released an updated version of the WinUI 3 Controls Gallery that contains the Pivot control. Happy holidays everyone!

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[abhisavadiya]

How this all tab is sticky on scroll ???