Page MenuHomePhabricator

Page options dialog (meta dialog) is unavailable in mobile VE
Open, Needs TriagePublic

Description

Page options dialog (meta dialog) is unavailable in mobile VE. Should we enable it?

image.png (378×502 px, 29 KB)

image.png (463×714 px, 27 KB)

Event Timeline

Change 474840 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/VisualEditor@master] ve.init.mw.MobileArticleTarget: Add the 'meta' dialog to the toolbar

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

Consider this a strawman patch.

The main problem is: where do we put the button to open this dialog? We could just put it on the page toolbar, which is okay on larger phones and tablets, but on smaller phones it leaves basically no space for the page title on the toolbar.

image.png (750×428 px, 37 KB)
image.png (582×334 px, 34 KB)

Maybe there should be no button, and tapping the page title should open the dialog?


The dialog was probably disabled because being based on BookletLayout made it unusable on mobile, but I just proposed a fix for that (T209912).

It looks mostly fine on mobile now with those changes (note that this is basically the worst case of a tiny device, iPhone-SE-sized, so e.g. the "Languages" table scrolls horizontally; I think that's okay):

image.png (568×320 px, 21 KB)
image.png (568×320 px, 34 KB)
image.png (568×320 px, 26 KB)
image.png (568×320 px, 21 KB)
image.png (568×320 px, 14 KB)
image.png (568×320 px, 21 KB)

@matmarex I guess you meant the last row as a possibility as well (it's not clear from the comment). Always showing the buttons has the advantage to provide constant feedback to the user where they are.
A possibility would be to add the toggle menu button only on small screens above the booklet menu as ToggleButtonWidget and expand/contract the full menu with it. And preferred icon would be 'menu'.

Neither an additional button in dialog header (which is already crammed IMO), nor the title itself seem clear indicating places/treatments to signalize a) that it is an interactive element and/or b) what it stands for.
Collection of two treatments with their own disadvantageous

image.png (698×1 px, 34 KB)

I think that the dialog looks like a great way to re-incorporate options, however, I think we need to think about the placement for options in the toolbar.

I'll put comments on T209909 re: dialog and we'll work on the toolbar placement design with the future toolbar improvements prototype.

Change 474840 abandoned by Bartosz Dziewoński:
ve.init.mw.MobileArticleTarget: Add the 'meta' dialog to the toolbar

Reason:
To be considered later

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

Ok, one additional thing that I think is confusing:

image.png (510×427 px, 15 KB)

When you click on another item in this state, first off, you need two clicks to open menu up and then click the item. I would rather see those as shortcuts, as we don't have any widgets in an outlined BookletDialog that result in loosing data. You've got the extra confirmation and cancel step anyways.
Also the menu items are loosing their pointer.
I'd rather keep them active and not greyed out so if you've understood the items as user to enable quickly jumping between items.

image.png (493×697 px, 34 KB)

What would happen with the extra toolbar in a mobile context?

cc: @iamjessklein

JTannerWMF added a subscriber: JTannerWMF.

We plan to look at this with the toolbar work, perhaps immediately after

When you click on another item in this state, first off, you need two clicks to open menu up and then click the item. I would rather see those as shortcuts, as we don't have any widgets in an outlined BookletDialog that result in loosing data. You've got the extra confirmation and cancel step anyways.

I think we need to extra step to display the item labels. It may not be necessary for the page options dialog, but it would be in other interfaces where we can't have a unique icon for every item (e.g. parameters of a long infobox in the template dialog).

Also the menu items are loosing their pointer.
I'd rather keep them active and not greyed out so if you've understood the items as user to enable quickly jumping between items.

I tweaked this in the latest version of the patch. Sorry, I implemented this a bit lazily in the first version :)

What would happen with the extra toolbar in a mobile context?

It's hidden when the menu is collapsed, and shown when it is expanded.

With the latest patch, the clicking behavior remains very confusing.
Sometimes the menu is expanded and the clicked/tapped menu item is activated, sometimes, it's not.
See recording of patch set 4:

With the latest patch, the clicking behavior remains very confusing.
Sometimes the menu is expanded and the clicked/tapped menu item is activated, sometimes, it's not.

I do not see this in the recording. When the menu is collapsed, tapping on the menu only expands the menu, it never activates items. When the menu is expanded, tapping a menu item always activates it and collapses the menu. This is the expected behavior.

I see how it could be confusing though. In the first version of the patch, the items in a collapsed menu were greyed out, which would indicate they are not tappable. You asked me to change this in your last comment, so now they are no longer greyed out. I think at this point you'll need to propose a design that you'd like.

The last interactions at when having selected “Three” is showing it best, starting at 0:04. It doesn't seem to follow a clear enough interaction principle, because as user I'm focused on selecting the nav link, not if the menu is extended or not.
When I click on a navigational item I expect that my click is followed by the system, not that it adds an intermediate step that is invisible to me. We could think about extending the menu additionally simultaneously to activating the navigation item, but not instead on it.
After the menu has been expanded the first time, I might even remember what the other items are and every delay (by the extra expanding/contracting step) triggers frustration.

When I click on a navigational item I expect that my click is followed by the system, not that it adds an intermediate step that is invisible to me. We could think about extending the menu additionally simultaneously to activating the navigation item, but not instead on it.

I don't think this is a good idea. It might work for the "Page options" dialog, which has just 5 options with distinct icons, but we also use BookletLayout in the transclusion dialog (T209909), where you can have 20+ items with identical icons:

image.png (508×717 px, 46 KB)

In this case expanding the sidebar to show the labels is necessary before the user can pick an option.

With T209912 being declined, we should think about a design for this from scratch.

matmarex moved this task from Q4 to Freezer on the VisualEditor board.

(We talked about T209909 today and it doesn't seem like we're going to work on it anytime soon. The same probably applies here.)