Page MenuHomePhabricator

Present Preferences submenus as full-screen modals
Open, Needs TriagePublic3 Estimated Story Points

Description

In T311717 we've redesigned the main menu of preferences on mobile with a vertical design. Submenus currently open within the central area of the screen, still under the Preferences heading.

The next step towards our final designs is for the contents of submenus to open within a modal-like interface, where the submenu title is presented at the very top of the screen, hiding both the grey navigational bar and the Preferences heading, with a button which takes users back to the main menu.

Design

State of the artMock-upSpacing
en.m.wikipedia.org_wiki_Special_Preferences(iPhone SE) (1).png (1×750 px, 126 KB)
iPhone 8 - 222.jpg (1×754 px, 244 KB)
Frame 156.jpg (1×756 px, 248 KB)

Acceptance criteria

  • Navigating to a submenu in the new Preferences design should display the Mock-up design above
  • Clicking the back arrow should return users to the top of the Preferences main menu
  • The grey navigation bar and Preferences headings should no longer be visible in submenus
  • The submenu heading ('User profile' in the mockup above) should be sticky as the user scrolls down the page

Event Timeline

Samwalton9 set the point value for this task to 3.Sep 14 2022, 10:05 AM
Samwalton9 removed a project: Epic.

Change 843505 had a related patch set uploaded (by Eigyan; author: Eigyan):

[mediawiki/core@master] Present Preferences submenus as full-screen modals

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

Test wiki created on Patch demo by SCardenas (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/08eded1a70/w

@AAlhazwani-WMF Do you think the header in these submenus should be sticky as the user scrolls down?

@AAlhazwani-WMF Do you think the header in these submenus should be sticky as the user scrolls down?

For lengthy pages they might be very useful. I'm only afraid that in our case with an existing sticky navigation bar, sticky footer/save button (and potentially also sticky browser bars for some mobile browser) we might end with several sticky elements.

Would be great to maybe have the submenu sticky in the navigation bar, which is updated on scroll, dunno if it's feasible thou. In the example below we display only the submenus.

image.png (1×1 px, 573 KB)

While in this example we display both the menu and submenu together, with a breadcrumb-like UI.

image.png (1×2 px, 571 KB)

Thanks! I'll update the acceptance criteria to include this header being sticky if that seems viable @eigyan?

@Samwalton9 I think this is doable - I should be able to add css sticky attribute hopefully nothing breaks :)

Test wiki created on Patch demo by EIgyan (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/9716dfc801/w

Test wiki created on Patch demo by EIgyan (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d0f0da80d4/w

Test wiki created on Patch demo by EIgyan (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/07375e9fac/w

Parts of this are looking good, but we're now making much less effective use of higher resolution displays:
before:

image.png (2×3 px, 807 KB)

after:
image.png (1×3 px, 210 KB)

This is looking good! There's one small detail about transitions. On bigger screens, you can see some elements from the header disappear in a funny way. See the top left corner of the GIF included here. This behavior happens from tablet sizes to larger screen sizes.

Modal transition.gif (272×1 px, 132 KB)

In my browser it looks like the modal isn't quite filling the screen - there seems to be a 12-16px border around the edge at the top and sides. Per the mockup, this should be filling the screen.

patchdemo.wmflabs.org_wikis_07375e9fac_wiki_Special_Preferences(iPhone XR).png (1×828 px, 130 KB)

Perhaps related to the border - preferences-summary is still being rendered on the submenu pages (this screenshot uses ?uselang=qqx):

patchdemo.wmflabs.org_wikis_07375e9fac_wiki_Special_Preferences_uselang=qqx(iPhone XR).png (1×828 px, 240 KB)

This means, on wikis which have defined MediaWiki:Preferences-summary, there will be extra text up there. I added this to the patch demo so you can see what it looks like. I don't think we should be displaying this in submenus, just in the main menu:

patchdemo.wmflabs.org_wikis_07375e9fac_wiki_Special_Preferences(iPhone XR) (1).png (1×828 px, 145 KB)

I also agree with Jason - we should fill the screen with preferences and the Save button. In fact, I wonder if we should hide the footer entirely while this submenu is open. That's how the mobile editor modals work - they fill the screen and don't show the footer while open. Given that you can easily tap back to the main menu to see it I think this could make sense?

@jsn.sherman @Scardenasmolinar @Samwalton9 thank you for your valuable feedback. I am applying the changes you mentioned and hope to have a patch demo soon.

The mod tools engineers all took some time today to look at this and found that this is another task where we need to reconsider our approach. It's really come into focus that we should be looking for ooui- or codex-based solutions wherever possible, and only considering pure js/css solutions when there is no other choice. We discussed how we might use dialogs and/or overlays
https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.Dialog
https://www.mediawiki.org/wiki/OOUI/Concepts#Overlays
to achieve the modal interaction.

I actually discovered that our pure html/js/css approach for the contents of the stacked layout is one of the underlying problems that lead us to need to T321330: Fix anchored links in new mobile preferences design. My in progress resolution for that involves reworking the markup to use more OOUI layouts instead of html elements in the form class to try to take better advantage of existing event handling, so I think it will be valuable for @eigyan to keep syncing up on these two tickets.

@Samwalton9 given that we're trying another approach on this, could we move the sticky heading back out of acceptance, and set it (and maybe the breadcrumb) as a stretch goal? We'd like to try to come back at it as narrowly as possible with the available libraries because those libraries encapsulate a lot of existing work of the design systems team, both in powering interactions and also code maintenance. Once we have an MVP, I think we could get some advice from design systems to hit those stretch critera if we're struggling with them.

Change 851666 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):

[mediawiki/core@master] [WIP] Mobile Prefs Dialog Demo

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

Test wiki created on Patch demo by JSherman (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/2c9405e32b/w

Okay, I have a mimium (non-functional) OOUI dialog example.

I'm shoving a -content element from one of our current panel layouts from within the current stack layout directly into a dialog window.
https://patchdemo.wmflabs.org/wikis/2c9405e32b/w/index.php?title=Special:Preferences&mobileaction=toggle_view_mobile
I'm also jamming the submit buttons section of the form into the dialog footer, just to see what it would look like.

Some things to consider:

  • right now the dom is form -> stack layout -> each section panel w description -> each form section content within panel
  • Dialogs are handled by a window manager that can have many dialogs to show and hide
  • you might try stack layout -> each panel with section description and then window manager -> each dialog with form content with a click handler on each stack panel (just adapted from what we have for now) to open the dialogs. That might break the form
  • you might try keeping the form intact by doing stack layout -> each panel with section description and then window manager -> dialog -> form -> each form section content in which we would selectively show/hide based on a section argument or something provided by the click handler for the panels in the stack layout.

these are just thoughts I had while I was working up this example, so I'm happy to talk more about it.

Thank you for the example @jsn.sherman . After creating a dialog containing the content, I've found that interactions with the dialog inputs have no effect on enabling the save button. That's when I realized I need to wrap each content element in a form. Which is what I think you are mentioning above when you mention

window manager -> dialog -> form -> each form section content

I think I will need to update PreferencesFormOOUI.php logic to wrap each content section in a form element rather than the entire stacked layout being wrapped in a form.

From our conversation on Monday: What I meant by window manager -> dialog -> form -> each form section content was sticking the whole form into a single dialog and just using the stack layout for navigation.

I think splitting up the form could create state management headaches, but I haven't done a poc for that.

I think I will need to update PreferencesFormOOUI.php logic to wrap each content section in a form element rather than the entire stacked layout being wrapped in a form.

Could you share some example code for this? If it's too small to warrant a Gerrit patch, some snippets here would help me give you more thoughtful feedback.

We're all definitely learning here, and I'm suggesting that we all show more of our work and thinking along the way to help us learn faster.

To flip that suggestion back on myself: would it be helpful if I shared some poc code for the structural approaches I'm suggesting? They could have their own problems that I missed because I haven't actually tried them yet.

Change 855023 had a related patch set uploaded (by Eigyan; author: Eigyan):

[mediawiki/core@master] WIP: Present preferences in OOUI dialog

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

Test wiki created on Patch demo by JSherman (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/c25ba2ec50/w

The modals look great! Clearly a big improvement over the current implementation :) A few thoughts and questions:

  • When I click a main menu item there's a quick blink where the menu disappears before the modal animation plays. Is there any way to prevent that? It's a little distracting. [Not a blocker. Happy to proceed if there's not an obvious/quick fix]
  • The Save button at the bottom of the screen seems to work well. I do think it needs to be sticky, however. Given the length of many of these sections, it stands to reason that an editor is likely to think their preference has been saved automatically when they don't see any Save button appear after making a change. [Blocker - has a high likelihood of confusing users]
  • I'm happy to drop the request to have the header be sticky. I'll file a follow-up task for us to prioritise.

@Samwalton9 Thank you for the feedback, I am glad to see things are progressing to the vision of the ticket. I think it is achievable to address all the concerns above, I will implement them in my next patch.