Page MenuHomePhabricator

Evaluate IndexLayout (TabLayout) appearance on mobile
Closed, ResolvedPublic

Description

As of v0.28.1, IndexLayout (TabLayout) doesn't provide a great experience for mobile users, you can make at best a good guess what is the current tab option and its connected panel and also interact, but not much more than that.

image.png (392×818 px, 33 KB)

One proposal by @Pginer-WMF is evaluating something like nav pills (Bootstrap) when screen space isn't sufficient. They do have advantages, but in the Bootstrap implementation there are also clear shortcomings:

image.png (326×804 px, 26 KB)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

To me, "nav pills" look just like our tabs, but with different colors and font. What is the difference supposed to be? (And what's the problem with tabs in the first place? They seem okay to me on mobile.)

To me, "nav pills" look just like our tabs, but with different colors and font. What is the difference supposed to be? (And what's the problem with tabs in the first place? They seem okay to me on mobile.)

The main difference I was pointing to is that in the current implementation tabs (when they get detached from the content below) are shown with the top corners rounded and the bottom corners not-rounded (looking like a broken tab). That could be improved by making all corners look the same (e.g., rounded), conforming to the "nav pill" metaphor (only when all tabs cannot remain connected to the content below). Other aspects of the visual style can remain the same.

Making all corners round should be fairly easy and then make tab contents move up by negative margin-top. Nevertheless I see the real urgent issue with more than a few tabs, where suddenly you've got a lot of floating interactive elements. We've already had some discussion around them in T176034, with one CodePen showing an overflow transformation on smaller screens.

  • Operating system tab interfaces reordered the tabs (active ones got reordered so that there was a clear visual connection between tab labels and contents), I personally have never been a big fan of the reordering as you lost track where you've been before:

https://b2c-images.idg.zone/3315729_original.jpg

  • Another option was scrolling the overflowing tabs, providing arrows left and right or on one side of the tabs. Firefox does such in its tab bar
    image.png (36×740 px, 14 KB)
  • Or an overflow menu with the order remaining the same, but the current tab in the visible area

For touch interfaces, overflowed tabs with no extra UI is a standard in material design: https://material.io/design/components/tabs.html#scrollable-tabs

Just adding white-space: nowrap is enough to achieve this as seen in https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/511344/

This isn't a great interface on desktop, but adding this style just for mobile devices would be an improvement.

Change 512358 had a related patch set uploaded (by Esanders; owner: Esanders):
[oojs/ui@master] Horizontally scroll tabs on mobile

https://gerrit.wikimedia.org/r/512358

Change 512358 merged by jenkins-bot:
[oojs/ui@master] TabSelectWidget: Horizontally scroll tabs on mobile

https://gerrit.wikimedia.org/r/512358

Given the constraints of other solutions @Esanders proposal is the best compromise to move forward for now.

Volker_E assigned this task to Esanders.
Volker_E moved this task from Backlog to OOUI-0.32.0 on the OOUI board.
Volker_E edited projects, added OOUI (OOUI-0.32.0); removed OOUI.

Change 513020 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] Update OOUI to v0.32.0

https://gerrit.wikimedia.org/r/513020

Change 513020 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.32.0

https://gerrit.wikimedia.org/r/513020