Page MenuHomePhabricator

.oo-ui-menuLayout not mobile friendly
Closed, DuplicatePublic

Description

After enabling the ApiSandbox on mobile it's clear the design of the menu layout component needs some work to be mobile friendly.
https://gerrit.wikimedia.org/r/315698

The most straight forward change might be to switch the panel on the left to be a horizontal bar and the second panel to take up the entire width of the screen.

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 13 2016, 4:22 PM

ApiSandbox could use booklet.setMenuPosition( 'bottom' ) (or 'top') on narrow screens. It makes the interface at least kind of usable.

As stated, I think this bug should be declined for OOjs UI. Yes, MenuLayout, especially with the default 'before' menu position, is not mobile friendly. You should not use it in interfaces meant for narrow screens. There's a number of other solutions that work better and should be used instead if mobile is your first priority.

Anomie added a subscriber: Anomie.Oct 14 2016, 1:57 PM

Perhaps the default for MenuLayout should be some sort of 'auto' that switches layout based on screen width. If you require everything using MenuLayout to reimplement this logic itself when someone comes along wanting mobile support, you're going to wind up with code duplication.

MenuLayout would still be suboptimal for mobile, since the menu would presumably still be displayed on the screen at all times. For mobile-oriented interfaces I'd expect you to use perhaps a dropdown menu (DropdownWidget), or a fullscreen menu that would open fullscreen "pages" (which would have an option to go back to the menu). I don't think we can magically transform MenuLayout/OutlineSelectWidget into one of those without breaking backwards-compatibility in some way.

I should note that Echo has the same problem (cc @Mooeypoo ) which solves it by hiding the menu (although sadly this leads to the loss of the useful cross wiki notifications on my mobile device:
https://en.m.wikipedia.org/wiki/Special:Notifications

I think it's the responsibility of a library to solve these problems for the engineers that make use of it. It's unfair to expect that these problems should be solved on a case by case basis. If stacking them vertically is the suggested interim solution then booklet should be aware it is on a mobile screen and make that happen.

I could also see opportunities here to make this a one pane view with the ability to slide between panes (JS needed of course).

We're only temporarily hiding this menu; the idea was to create a "popup" panel (similar to how the notifications popup is opened) to bring it back.

But yes, it would be a lot simpler if we had a mobile-ready OOUI widget.

The biggest problem we have with using the MobileFrontend popup is that it hides mw.notify alerts; we've worked around that by creating our own widget but that's far from ideal. I have a patch (and related conversation on phabricator) for solving this in mw.notify itself, though https://gerrit.wikimedia.org/r/#/c/306560/

This is a bit tangential, but worth mentioning.

Volker_E triaged this task as High priority.Apr 7 2017, 12:31 AM
Jdlrobson moved this task from Needs triage to Triaged on the Mobile board.Jul 25 2017, 5:43 PM
Volker_E moved this task from Backlog to Next-up on the OOUI board.Feb 2 2018, 2:44 AM