Page MenuHomePhabricator

Present Preferences submenus as full-screen modals
Closed, ResolvedPublic3 Estimated Story Points

Assigned To
Authored By
Samwalton9-WMF
Sep 6 2022, 1:05 PM
Referenced Files
F35826936: image.png
Dec 1 2022, 1:29 PM
F35826060: image.png
Dec 1 2022, 1:36 AM
F35826058: image.png
Dec 1 2022, 1:36 AM
F35826025: image.png
Dec 1 2022, 1:36 AM
F35826023: image.png
Dec 1 2022, 1:36 AM
F35826021: image.png
Dec 1 2022, 1:36 AM
F35826019: image.png
Dec 1 2022, 1:36 AM
F35825967: image.png
Dec 1 2022, 1:36 AM

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
  • Form state should be preserved during navigation:
    • the save button should initially be disabled (gray)
    • changing a setting should enable it (blue)
    • the button should stay enabled when navigating between sections
    • changes across multiple sections should be recorded by a single click of the save button

Event Timeline

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.

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

This looks really great @eigyan! Very happy with this from a UX perspective :)

Awesome to hear @Samwalton9 all the feedback made for a great result!

Change 843505 abandoned by Eigyan:

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

Reason:

Went a different direction with implementation.

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

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

@eigyan, @jsn.sherman:

I have verified the Preferences Submenus are displaying and functioning per the Acceptance Criteria listed in the ticket Description.

Below are some screenshots of the Preferences Submenus with various devices:

image.png (894×564 px, 159 KB)
image.png (887×589 px, 195 KB)
image.png (889×566 px, 187 KB)
image.png (879×455 px, 183 KB)
image.png (858×443 px, 199 KB)
image.png (869×430 px, 183 KB)
image.png (890×475 px, 170 KB)
image.png (876×427 px, 160 KB)
image.png (415×870 px, 112 KB)
image.png (424×875 px, 124 KB)
image.png (878×587 px, 203 KB)
image.png (876×608 px, 217 KB)
image.png (674×976 px, 180 KB)
image.png (651×924 px, 180 KB)
image.png (864×663 px, 166 KB)
image.png (875×681 px, 169 KB)

@Samwalton9 is there space to optimize the vertical (and horizontal) spacing and layout? If yes, currently there are several keylines that I would like to reduce and optimize to provide a more linear scanning/reading experience.

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

+2ed. @AAlhazwani-WMF I created another placeholder task (T324227) for us to do any followup discussions/tweaks since we have some other things to look at post-merge.

Change 855023 merged by jenkins-bot:

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

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

@Samwalton9 is there space to optimize the vertical (and horizontal) spacing and layout? If yes, currently there are several keylines that I would like to reduce and optimize to provide a more linear scanning/reading experience.

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

There definitely is space for this, though this might be more of a consideration for @eigyan in T317110 - we've deliberately not touched layout of the preferences submenus themselves yet (besides checkboxes).

@Samwalton9 is there space to optimize the vertical (and horizontal) spacing and layout? If yes, currently there are several keylines that I would like to reduce and optimize to provide a more linear scanning/reading experience.

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

There definitely is space for this, though this might be more of a consideration for @eigyan in T317110 - we've deliberately not touched layout of the preferences submenus themselves yet (besides checkboxes).

@Samwalton9 that makes sense; we'll just use the task I mentioned for code quality optimization then, and I'll remove any references to the design. I just didn't want to move this to done without making sure we were including @AAlhazwani-WMF!

Change 851666 abandoned by Jsn.sherman:

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

Reason:

used for learning

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

Test wiki on Patch demo by SCardenas (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/08eded1a70/w/

Test wiki on Patch demo by EIgyan (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/07375e9fac/w/

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/2c9405e32b/w/

Test wiki on Patch demo by JSherman (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/c25ba2ec50/w/

Test wiki on Patch demo by EIgyan (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/4b28dbdda9/w/

Test wiki on Patch demo by EIgyan (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/ef44755004/w/

Test wiki on Patch demo by EIgyan (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/9716dfc801/w/

Test wiki on Patch demo by EIgyan (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/d0f0da80d4/w/