Tab control

[hermitdave]

We need a control similar to Tab control. iOS has UISegmentedControl as shown below

The control should expose the following properties
UseTabSeparator : determins whether Tab Items are visually separated or not
SeparatorWidth : the distance between 2 tabs in pixels
Items: User supplied list of TabItem
SelectedIndex: Gets or set index position of currently selected TabItem (default 0)
SelectedItem: Gets the item currently selected, zeroth item by default.

Based on above I have done some preliminary work and create Tab and TabItem controls. TabItem derives from ToggleButton and exposes all ToggleButton properties.

UserVoice: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/17983933-tab-control-like-in-microsoft-edge

[hermitdave]

I would like thoughts on whether its worth pursuing and what behaviours are expected out of a Tab control

[ScottIsAFool]

The tab control is a tough one (in my mind) given that the pivot control can be used as tab control now (albeit only if the header items don't take up more space than is available). I wonder whether the tab control should maybe extend the pivot? if we can find a way to force tab mode in pivot, then that would be ideal.

[hermitdave]

Pivot also has content area and there's a very specific transition behaviour while looked great in WP7 is dated and not always wanted.

I'd personally stay clear of Pivot just for that reason

[ScottIsAFool]

I disagree with that. Even built in apps in Win10 are still using tabs with transitions. Just look at Alarms & Clocks. That doesn't look out of place or "dated". Plus those transitions are enabled via storyboards in the template, they can be removed if we really didn't want it.

[hermitdave]

One thing that Windows 8 taught many was that just because a stock templates and often stock apps do that doesn't mean it has to be done everywhere..

And most stock apps use Hamburger.. maybe we should just suggest that to everyone

[ScottIsAFool]

Ignore Windows 8, that was just... well, everything about it was wrong. I don't believe it should be us that makes the tab control behave differently from stock controls, but we should build it so other devs can do if they want.

[hermitdave]

I am talking to Islandwood team and they have an equivalent of UISegmentedControl so maybe iOS ported apps will have one design and rest will have different ?

[ScottIsAFool]

Unless you're suggesting incorporating the Islandwood control into this toolkit, I'm not really sure what your point is with that.

[hermitdave]

We should have equivalent control and one that can be identically templated.

[ScottIsAFool]

I've not said we shouldn't...

[hermitdave]

I am trying to get to the bottom on islandwood control behaviour but I doubt they went about templating pivot

[ScottIsAFool]

Isn't all their stuff on github anyway?

[deltakosh]

@hermitdave has a valid point. to me this control is a list of buttons. The pivot has a client area that we do not want here (do we?)

[ScottIsAFool]

@deltakosh then what would be happening when you select one of those tabs?

[deltakosh]

Like on iOS, you receive an event and you do what you want with it

[ScottIsAFool]

Fair enough. Pivot doesn't have to have content though, right? If we subclassed pivot and changed the template to not include content, would that work? Im just thinking we could borrow a lot from pivot.

[deltakosh]

This is worth a try I would say

[hermitdave]

I'm happy to be shown that Pivot and PivotItem are better suited. ToggleButton has both events and properties that PivotItem doesn't

[deltakosh]

(I'm not convinced as well but it is worth trying)

[ScottIsAFool]

What properties and events do you need?

[ScottIsAFool]

And how will togglebutton support multiple items :)

[hermitdave]

I mentioned PivotItem.. ToggleButton is used to derive TabItem.. Creating a container is easy.

Tapped, Click, Command, CommandParameter, a lot of UI behaviours among a few. Please do give it a go. Play with iOS segemented control.

[hermitdave]

Also container has to be constrained to the view bounds.. Items don't scroll and definitely no cycling

[ScottIsAFool]

I know the container needs to be constrained, that's why I mentioned that right at the beginning of this thread! :P

[timheuer]

Is this of material value without content? Sure you could say that UITabStrip doesn't have a content model, but when used those toggle buttons DO navigate to different content areas, so I'd have to ask from an end user experience why Pivot doesn't meet these needs. As @ScottIsAFool points out you can style the pivot headers to make them look like what you want.

[deltakosh]

Regarding navigating to content: I would have seen this control more like a list view. We should not force the dev to navigate to a different content when clicking one of the options

[hermitdave]

I agree.. Having content pane forces different content model. Pivot and FlipView to an extent already provide that. Having yet another control that behaves in same fashion is pointless

[hermitdave]

And @timheuer by the same token, we should consider retemplating Pivot and deriving FlipView from that (no header and no content transitions) would have made life simpler 👍

[michael-hawker]

@Vijay-Nirmal yup, my current approach is working with tabs that fit on the screen. It's breaking down when I try and fix the native pivot tab scrolling, I have to investigate a bit more. But it looks good:

My Edge tab style (outside the above) is almost done, but I don't have exactly the right brush or hover brush setup.

@WilliamABradley, thanks for the link, we could actually add that more 'Office' style tab to my approach as well rather easily, it would round out the collection nicely.

This item hasn't been my main focus; I've just gotten it to this prototype stage. In the meantime, I've updated both issues with their UserVoice links for voting.

[skendrot]

@hermitdave it was decided to punt on a true TabControl in favor of just restyling the Pivot

[allanrsmith]

This is one I started... it is VERY similar to the Microsoft Edge Tab Control... let me know if you want me to share at least the structure of this. There is still plenty of work to be done to hook up everything.

[hermitdave]

Sorry @skendrot forgot

[hermitdave]

Sorry @skendrot forgot

[Vijay-Nirmal]

@michael-hawker Does it support Drag & Drop?

[michael-hawker]

@Vijay-Nirmal I haven't looked into drag and drop yet. I'm not sure with the custom pivot header presenter panel how possible it will be to hook into that or not for the drag/drop events.

It may be possible to just get it from the item level, but I haven't spent any time looking.

[Vijay-Nirmal]

@michael-hawker Few thoughts about your way of implementing the Tab Control (restyling the Pivot control).

1. Restyling a Pivot to act like a Tab Control seem weird. This is like restyling a Pivot to NavigationView. Also, using extension methods to interact with restyled Pivot seem weird.
2. If we make Tab Control as a style then we can restyle it. The only way to do it is to manually copy the style and edit it.
3. I am working on Office style for Pivot control. Pivot is very hard to restyle because of the panel used in Pivot. I hope this the case for you as well. As for as I know we can't support Drag & Drop, detach to create a new window (with the new APIs in RS5), lot more...

But still, I liked to see it. Better than nothing ;)

[Odonno]

I am not sure of this feature anymore because of

1. The UI controls library announced at Build will soon (I think) be available which will bring new Pivot style (the Office style and the iOS-like style)
2. The NavigationView will have a Top-view design in RS5 (like a Pivot but including back button, settings and second bar). It's a NavigationView like the one you can see in the Microsoft Store app

I am the first to say that if it ain't available now, we should do it but it seems too late even for me.

@nmetulev Your thoughts on this?

[Vijay-Nirmal]

@Odonno But it is in the investigation stage.

[nmetulev]

Here is the recording of our first live standup where we discussed this control in detail: https://www.youtube.com/watch?v=qd14_3etv98

[mdtauk]

@nmetulev I had no idea you were planning to do video stream discussions! Great idea. Am watching it now.

[michael-hawker]

@mdtauk it's our first one! We hope to continue them in the future after the success from today.

I'll post more of the document info I shared here in a bit, I want to finish my investigation on using ItemsSource first (hopefully tomorrow).

In the meantime, you can find my working branch here if anyone wants to play around with the live demo I showed. The TabView code is here and the sample page.

[mdtauk]

It may be helpful to document WPF and Win32 uses for Tabs and Tab Controls, and offer guidance where pivots and NavigationView Top position should replace traditional tab usage.

Then you can focus on building a tab control that handles those scenarios were Tabs "should be used" and let that help answer some of the questions you come up against while planning and developing it.

Either of these works, but when would you choose one over another? With the properties dialog, the buttons at the bottom apply to all those tab views, so they are outside of the tabs. But all those tabs are showing filtered view of the same file's properties. No re-ordering is required. No closing tabs either. So is Pivot the right control to use here?

---

Alarms & Clock used a customised Pivot before but is now/will soon use the NavigationView control.

Clearly this is whole app navigation, so NavigationView makes sense here right?

So as a quick thought about how devs should be guided to use the control:

• For whole screen / majority of the screen navigation, use NavigationView set to top;
• For views of related data/content use Pivots;
• For grouped content/controls use Tabs?
• For multiple documents, leave it to window Sets?

LoB apps tend to use tabs to both provide multiple views (so the screen is divided to allow you to view different things in a single space) as well as filtering different views of content from a single source.

[JustinXinLiu]

This is what I would suggest:

If you use the tab control for a small section inside one of your pages, use the new TabView.
If you want tab control to be function-rich, use the new TabView.
If you want a touch-friendly tab, use the Pivot. However, I'd suggest the TabView should be touch-friendly too.
If you need a top-level, responsive and tab-like menu, use the NavigationView.

It would be nice for the TabView control to have multiple built-in styles. What you showed above are two of them.

[mdtauk]

@JustinXinLiu That seems a little vague especially in your guidance on the Pivot.

Pivots Originally the intent was for filtering views of the same data, but have become a generic way to "swap out" a region/area within a view/window/screen. It is the most lightweight visually and in terms of complexity.

Simple - Tabs Once considered obsolete in a touch first, immersive UI. Favoured by LoB and more traditional UIs, as well as UIs which rely on tool windows and pro software. More visually complex as they form a contained box with UI inside, and a container for the tabs themselves.

NavigationViewListItems The UWP way of navigating to discreet content in an app. Used as a shell and flexible enough to be used as side navigation, as well as top navigation. No concept of re-ordering, strictly a read-only concept. The most heavy of control schemes, it will most commonly occupy the entire window.

Complex - Tabs Essentially all apps will feature this concept of a tabbed interface with Window Sets. Tabs which the user controls by creating them, re-ordering them, closing them, (saving them as a set and restoring them). As a control usage of the re-ordering makes sense in pro software, and where the user is encouraged to re-arrange their UI.

---

The Tabs can be both lightweight and complex. Having them as a single control makes total sense, but the default options should lean towards the lighter end I believe. CanReorder, CanClose, CanBeTorn, these should be set to false.

Visually the idea of a tab is like a page with content on and a part poking out - especially when it is used within a page, instead of used as a window's shell/chrome. This should probably be maintained through the Tab's selected state, and the content area's border and background brushes.

If someone wants to use it for a full app shell, how does that work when Sets becomes the default? Does there need to be an explicit IsCompact property when the intended use is for a dockable toolbox? (Think Visual Studio, or Photoshop)

---

I think there should be clear guidance so developers do not automatically eschew NavigationView and Pivot controls. The Windows Team should do this too with more judicious use of these controls, but also the Toolkit documentation and the sample apps.

[michael-hawker]

Great input @mdtauk. I do like the idea of the CanReorder, CanClose, CanBeTorn type paradigm to add-in the advanced scenarios as desired by the developer.

I also think the main difference in the traditional WPF tab styling and the Edge tab styling is mainly padding around the text/icon/close buttons. So, I think providing an alternate style for Edge tabs should be more straight-forward in that sense, if we can share the rest through an inherited style.

[JustinXinLiu]

@mdtauk This thing is that the new TabView control should be able to do everything a Pivot does, plus a lot more in the future.

[mdtauk]

@JustinXinLiu I do agree with the idea of a TabView control becoming a super-set of the Pivot. However the Pivot control is more lightweight with a distinct typographic and clean visual style. I think the Pivot should remain

Now of course you can re-style the other to look the same, but as both will exist, my thinking is that some guidance should be offered as to when to use each control. Of course, developers do not have to follow it. But when Tabs make their way to the Windows UI Library (as is being investigated and will probably use the Community Toolkit version as a base) there should be a Windows UX story to tell, as to when one gets used over the other.

The TabView's default "heavier" visual style makes it more present in the app window. It also implies a discreet grouping of UI elements, compared to a Pivot.

I am not arguing about the functionality or feature set. TabView should do much more than a Pivot. But when it should be used instead of a Pivot control, there should be a use case example to push.

Ideally this example should be agreed with the Windows team so the use of TabView can be consistent

[nmetulev]

merged 🍾