mdTabs: Should the the pagination arrows change tabs?

[PaulMougel]

On a mobile display, if tab labels are long, it is pretty common to display only one tab at a time:

In that case, I have found disturbing that clicking on the arrow doesn't actually select the next (or previous) tab, but only changes the pagination. I understand the goal of this feature, however I wonder if it is a strict design requirement. The design specification states:

Scrollable tabs display a subset of tabs at any given moment, and can contain longer tab labels and a larger number of tabs. They are best used for browsing contexts in touch interfaces when users don’t need to directly compare the tab labels.

To navigate between scrollable tabs, touch the tab, swipe the tabs left or right, or swipe the content area left or right.

It doesn't mention using the arrow buttons to navigate between tab pagination. In that case, can it be an option? md-pagination-arrows="paginate" or md-pagination-arrows="changeTab" for instance?

Can anyone shed some light on this issue?

[ThomasBurleson]

The functionality was originally based on aspects of keyboard focus changes vs. tab selection:

Left/Right arrows will change the focus to the previous/next tab without changing the currently selected tab. If arrow-key past page bounds, then change page and the focus on correct tab (without changing the current selection).

I think, however, if a user CLICKs on the pagintator then the

• page should change,
• focus should change
• AND the selected tab should change.

This would be similar to a left-right swipe to navigation/select the next or previous tab.

[marcysutton]

@ThomasBurleson agreed that a mouse click on an arrow should probably change the tab. I seem to remember we discussed keeping the arrow buttons out of the tab order because a keyboard/screen reader user would just cycle through ALL of the tabs (showing content panels requires space bar). But the arrow buttons currently have tabIndex="0" on them (probably from ngAria) along with aria-hidden="true", making them focusable mystery controls. Tabindex should probably be -1 to pull them out of the tab order, if that was the goal. Then we can do whatever we want on arrow click in regards to changing tabs and tab content.

[ThomasBurleson]

@marcysutton - 👍

[davidohalloran]

Would be nice if the tabs list just scrolled in a similar fashion to how the polymer paper tabs work https://www.polymer-project.org/components/paper-tabs/demo.html.

[tam3r]

@davidohalloran I agree, tabs scroll the same way in Google Play Store and Play Music for that matter.

[marcysutton]

I love this discussion. Taking inspiration from our favorite UI's is a great idea, particularly where the Material Design spec doesn't cover it. A quick glance at the spec for tabs showed no pagination on mobile, so unless there's an update to that part of the spec coming soon, we're on our own.

[PaulMougel]

Awesome.
I agree with what you all said earlier: a mouse click / touch on an arrow should change the tab, while pressing the left/right arrow keys should change the pagination, without changing tab.

@davidohalloran I find the scrollable tabs of polymer a bit weird in that regard: I have to maintain the click a little bit longer than usual for the tabs to scroll, otherwise nothing happens.

[davidohalloran]

@PaulMougel I disagree that the arrow should change the tab mainly because a user will not know what the next tab contains as its label is hidden by the current pagination implementation. I think that is why the polymer team and play teams went with the ability to scroll through the tabs labels. The ability to scroll/swipe through the labels also has the advantage of letting the user quickly switch between say the second last tab in a long list and the first tab without the expense of hitting every other tab content panel along the way.

[robertmesserle]

As @davidohalloran mentioned, I think the main argument for not changing the tab on click is that if we do that, there's no way to see the tabs without changing content. I don't really think it matters if it's triggered by keyboard or mouse, the idea is the same.

[PaulMougel]

I see what you mean. However, clicking on an arrow focuses the first (or last) tab of the page, which is good for keyboard navigation, but weird on the eye.
See this screenshot for instance:

Doesn't it look like the current tab is Tab Five? Even if this is exacerbated due to #1260, to me it looks like Tab Five is displayed. But it is not: Tab One is displayed, and I just clicked on the arrow to display the next page. See this gif.

[robertmesserle]

@PaulMougel this is a good point, and in terms of being less confusing, seems to support the Polymer approach. (The Polymer approach also more closely mimics how we would expect pagination to work on mobile, being able to freely drag the tabs from side to side rather than in a forced pagination.)

[ThomasBurleson]

@robertmesserle, @PaulMougel - My summary is that clicks imply a selection (which is more than a focus-only change):

• click tabs change the selected tab.
• click paginator changes the selected tab (first tab on next page, or last tab on previous page).

[robertmesserle]

@ThomasBurleson I don't think that I agree with that. A click on the right arrow, to me, implies changing the page - not selecting a tab that I haven't seen yet. The issue is that if we force a new selection, there's no way for the user to know what they are selecting until after they've already done it.

[davidohalloran]

@ThomasBurleson a click can only imply a selection when the user knows what they are selecting.

[ThomasBurleson]

@robertmesserle - But if you click to change the page now you see a different set of Tabs yet the current cotent is associated with an offscreen tab. It is this disconnect of UX that seems off to me.

[ThomasBurleson]

Summary 2:

The difference between the Polymer and Angular Tab scrolling is that Angular scrolls by Pages (ie 1...n Tabs) while Polymer scrolls by individual Tab buttons (current scroll by pixels but that is a bug).

[PaulMougel]

@ThomasBurleson Note that the Google Play native app allows the user to swipe across tabs without selecting them. And it allows to scroll "by pixels", if I understand what you mean by that.

[davidohalloran]

@ThomasBurleson what is the benefit of grouping the tabs into pages vs a scroll behaviour? Would it be possible to add an option to disable pagination completely and let the developer add scrolling using CSS.

[robertmesserle]

@ThomasBurleson This is true - I don't think that either is ideal. However, keyboard navigation puts you in the same boat, so I don't see why the two would be treated differently.

[ThomasBurleson]

@robertmesserle - my point [based on community feedback] is that both the keyboard and clicks should be consistent (at least with pagination). If the page set changes, perhaps the selection auto-changes.
Perhaps we have an attribute md-select-on-pagination which is false by default.... (just brainstorming here).

[robertmesserle]

I agree that they should be consistent (earlier in the thread, there was differentiation between click and keyboard functionality). I spoke with @jelbourn earlier and have some ideas for how we could best handle this. Will discuss later.

[davidohalloran]

@ThomasBurleson @robertmesserle any updates on how this might evolve in the near future?