Proposal: TabView vNext

[stmoy]

Proposal: TabView vNext

Summary

TabView v1 shipped with WinUI 2.2. Now that we've got v1 out the door, lets look at the set of features we weren't able to complete in the v1 release!

A list of outstanding bugs in v1 is here: Issues List

Rationale

• Since v1 was scoped primarily to Terminal asks, we weren't able to address many of the great community-driven suggestions provided on the original issue Proposal: Tabs Control #304 and corresponding PRs 28 and 53
• TabView doesn't have full feature parity with the WCT version yet, meaning the WCT cannot yet be deprecated
• TabView doesn't have full feature parity with WPF TabControl

Scope

In Scope for WinUI 2.4

Capability	Priority
Update tab strip to ItemsRepeater (from ListView) (#1837)	Must
Tabs stay within the "rails" during drag/drop (#1685)	Must
Animation alignment with Edge canary (#1511)	Must
TabView Gamepad improvements (#1648)	Must
Bug fix: Add CloseCommand on TabViewItem (#1246)	Must
Bug fix: Observable collection (link to comment)	Should
WCT Parity: Close button overlay hover	Should
WCT Parity: TabWidthMode collapse to icon sizing	Should

Out of Scope for WinUI 2.4

Capability	Priority
Expose TabStrip as standalone component/API (link to comment)	Should
Bottom of tab corner rounding	Should
ProgressRing in TabViewItem (#1386)	Could
Update selected tab visual state	Could
Alternate tab strip placements (bottom)	Could
Alternate tab strip placements (left, right)	Could

Important Notes

Open Questions

[mdtauk]

Who is planned to work on the WinUI Ribbon control, they may have some asks which should be considered?

[michael-hawker]

@mdtauk good call. I could see the Ribbon as containing a TabView as it's a very similar paradigm. It'd be nice to re-leverage components for compositing in this manner.

[shaggygi]

I could also see some goodness come with Ribbon and docking. Referencing #668

[mdtauk]

Could there be a lightweight mode for things like Tool Palettes and Dialog Tabs.

[stmoy]

Who is planned to work on the WinUI Ribbon control, they may have some asks which should be considered?

@mdtauk, good question. #168 tracks the Ribbon feature. As of right now, the Ribbon is in the "freezer". That said, I did a basic ribbon prototype using TabView v1 as the building block. Here is a really rough, really old proof of concept screenshot using a prerelease TabView from a few months ago:

This issue tracks potential improvements to TabView, of which Ribbon might have special requirements. Since Ribbon is in the "freezer" however, we shouldn't tightly couple these two topics.

[adrientetar]

@stmoy What do you think of rounding the inner corners of the tab?

Looks nicer & more consistent to me than just rounding on the outside. It would also make us more consistent with new Edge browser.

[stmoy]

@stmoy What do you think of rounding the inner corners of the tab?

I love this look! I added this to the table above. We did some preliminary investigation of this particular visual and determined that it was too difficult to "get right" for the v1 release of the control, but I'd love to take another look for v2.

[Poopooracoocoo]

@shaheedmalik i think thats normal behaviour so it's easy to drag tabs and the 1px line is the active window border

[Poopooracoocoo]

Also, dragging tabs with the current implementation doesn't feel nice.

It would be better if other tabs that are not selected/being dragged don't shrink or become "inactive" (greyed out). It should also snap to the tab strip so that there needs to be some force to create a new window. Chrome/Chromium/Edge (Anaheim) are like epitome of tabs :p

[lukeblevins]

EDIT: Check out the new issue tracking this

TabView Unintended ListView Behavior

@stmoy In my app scenario, we have an ObservableCollection containing InstanceTabItem class objects which each contain a property for the Content. This collection is binded to the TabItemsSource property. The Content property contains a Frame that becomes the content of the TabView ContentPresenter. However, I noticed that closing each TabViewItem won't release the memory used by the InstanceTabItem's content property even though it is completely removed from the collection. In fact, the Loaded event for the TabViewItems themselves is only called one time. Meaning that closing the TabViewItem does not unload/dispose it. This behavior implies that the TabView must have some kind of virtualization mechanism used to recycle items which has the unintended consequence of not destroying the TabViewItem content when closed. Hopefully, you can see how this is a problem for my application scenario. Considering we're on the subject of removing/modifying unintended ListView behavior from the TabView, I wanted to ensure this was noted.

Open questions:

Is ListView virtualization needed for the TabView, if so how can I disable it or prevent this issue?

Should there be an easy way to disable virtualization for the TabView?

Is there a better way I can associate a Page's content with each tab and display it in the TabView ContentPresenter when selected?

[ToddThomson]

Not sure if this is the correct issue, but...

I would like to be able to use only the TabStrip from the TabView.

[stmoy]

Scoping Update (Jan 13, 2020)

Hi all! I wanted to provide a quick update on this. Thank you to everyone who provided their input and ideas! I have taken these ideas and pitched them to our team to see what is in scope for the next version of WinUI.

Several of the ideas that we liked the most were the ones that improved the overall polish and user experience of TabView. One of our original goals was to try to make TabView feel as good as what you see in browsers and we've found that the current implementation doesn't yet meet up to that goal. The primary reason is that TabView was built using a specialized ListView "under the covers" which restricted our ability to get some of the fit-and-finish features that we really wanted.

To that end, we're going to swap out the ListView implementation to one based on the more flexible ItemsRepeater instead. In doing so, we expect to be able to tackle several features that were previously blocked - namely around animations and drag-and-drop. This also means that we won't get to everything on the list since this will be a fairly hefty rewrite.

I have modified the issue above to reflect the set of features that we expect to get to in 2.4 vs. the features we won't be able to get to right now. As with all planning exercises, this came with some painful cuts - but my hope is that we'll be better set up to get to these features post 2.4 once we have a more robust foundation to build upon.

[michael-hawker]

@ToddThomson If you don't give any of the tab items content, then the tabs will just be on their own, so it should allow you to just use the tabs.

@stmoy if the corner rounding is just exposed as a resource, then it could be modified, so that way a developer could easily re-template or fake having bottom tabs until the tab location property is implemented.

[michael-hawker]

@stmoy I also just noticed that TabView uses IconSource vs. the NavigationView's Icon (IconElement). Will this be better aligned in WinUI3?

It is handy to just be able to put Icon="Home" for simple construction and then elaborate the IconSource with a complex type if needed.

[shaheedmalik]

Here's a concept of how Edge should look.

https://www.reddit.com/r/Windows10/comments/hwsgyc/so_its_been_more_than_a_year_since_we_got_the/

[yoshiask]

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

[mdtauk]

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

So what you are asking for is a larger touch target for the close button?

[Felix-Dev]

Touch hit target areas should generally be 40x40 pixel sized in WinUI to my understanding (we can see those used for the NavigationView/TreeView chevron and the NumberBox Popup spin buttons). Values like a min height of 32px are also sometimes used (see for the example the Checkbox). While a hit target area of 40x40px or 32x32px for the Close button are problematic given the current TabVíew UI, I did some quick testing and an increase from 16x16px to 24x24px for the hit target area seems possible:

16x16px (ccurently)	24x24px (possible change)

(I have also adjusted the right margin of the close button in the screenshot above. With the original right margin, it would look like this:
)

[mdtauk]

@Felix-Dev The Touch Target can be larger than the visual for the hover background - I would argue a touch target of 32x32 with a visual hover of 20x20 would both look good, and function well.

[Felix-Dev]

@mdtauk So something like the CheckBox hover visual then (this is a modified checkbox with transparent check background in rest state):

[mdtauk]

@mdtauk So something like the CheckBox hover visual then (this is a modified checkbox with transparent check background in rest state):

That would aid in finger target size, and not look bad.

Background set to a Transparent brush and the Background TemplateBinding goes onto a new Rectangle used as the Hover/Pressed visual. Focus Visual would be around the 32 x 32 size.

[Felix-Dev]

@mdtauk Here is how it could look like then (visual hover area is 20x20px):

with the hit target area (32x32px) shown in red below:

The Close button currently does not participate in tab stops, so there is no Focus Visual to my understanding, but if it were to participate, it could look like this:

What do you think?

[mdtauk]

Looks good to me. I'm sure it would need to be looked at by the design and accessibility teams to make sure it functions well for those audiences.

[Felix-Dev]

Yeah, perhaps the margin between the TabViewItem's ContentPresenter and the 'x' symbol could be reduced a bit further (especially if there is no Focus Visual which needs to be kept in mind for now). Pinging @stmoy here for overall thoughts on the above discussion.

Edit: Here is a screenshot showing a slightly reduced margin (compare it with the screenshot/GIFs above):

[mdtauk]

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

What kind of UI Layout changes did you have in mind - supposing the Touch Target for the close button were to change?

[shaheedmalik]

I transposed the touch targets of Modern IE on Windows 8.1 on to the tabs of Tabview and came up with this.

Here's it with a 40x40 touch target.

[yoshiask]

The acrylic makes it look cleaner, but it still isn't really Fluent. The UI layout hasn't changed at all, and the close buttons are still just as difficult to tap.

What kind of UI Layout changes did you have in mind - supposing the Touch Target for the close button were to change?

Touch targets are what I have the biggest issue with. The proposals for the close button look great, but the new tab button has the same issue. That's really all I can put into words; the current design just doesn't feel as Fluent Design as the WCT one, but I can't really describe why.

[shaheedmalik]

Here's a mockup with a 20x20 new tab button and 20x20 close buttons.

[mdtauk]

Here's a mockup with a 20x20 new tab button and 20x20 close buttons.

The Close glyph feels oversized

[shaheedmalik]

The Close glyph feels oversized

I don't really like it either. It should be like 17x17 maybe.

[michael-hawker]

@stmoy some of these have been addressed now, eh? Should this issue be closed or updated to factor in current thinking of future updates (if any)?

[stmoy]

Good call, closing this since the features that it initially tracked are now complete.

[yaira2]

@stmoy It looks like one of the features marked as "Must" was not completed yet #1685. Additionally, the comment linked to here is an issue that we were hoping would be fixed with TabView vNext.

[stmoy]

Got it, thanks @yaichenbaum - initially, this issue was really "the set of work required in WinUI 2.4" which has come and gone. You're right that there are still some outstanding work that was being tracked here.

I'm wondering if we should create another issue (something like "TabView desired features" or something) - but I'm not sure if that'd be better than just tracking all of these by a label.

[yaira2]

@stmoy It's probably better to just continue tracking these separately.

[stmoy]

I was going through to clean up the issue and was reminded that quite a few of the features listed above were marked as "Must" but were not completed in WinUI 2.4. Our initial plan was to do a significant TabView overview, but that ended up being deprioritized and we're not doing a major TabView update at this moment. My bad for not updating this issue earlier.

Rather than updating the "in scope vs out of scope for WinUI 2.4" tables above, it's more accurate (and up to date) to track these as separate issues since we're not doing a big investment right now.