Page MenuHomePhabricator

Review feasibility of proposed settings interface on mobile and desktop
Closed, ResolvedPublic2 Estimated Story Points


Mobile and desktop designs for Vector 2022 and Minerva have been proposed in T347309 and T349210.

We should review the feasiblity of the designs from a technical point of view and adjust as and where necessary.


In particular:

  • How does this impact client performance?
  • How can code be shared between the two skins for easy maintainability / updates

Event Timeline

ovasileva set the point value for this task to 2.Oct 30 2023, 5:49 PM

Change 969984 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] POC: Apply Vector client preferences to Minerva options page

Change 969985 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] POC: typography settings interface

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:

TLDR: I've outlined proposed sequencing in T345359 and T350195 is the next step. Roll out to production would be blocked on the following tasks owned by design systems team: T289208 and T335317. @JScherer-WMF
was going to have another pass at the design to see if there are any opportunities to simplify things.

desktop (T347309)

The big issue I can see with the design on desktop is it requires being able to load Codex styles for checkboxes and radios on the page. In mobile we don't have this issue as we have a completely separate page, however I think that's a bit of a poor experience, so ideally we should try to find ways to render the first.

Right now we can only render checkboxes and radio buttons if they are hidden by default. e.g. collapsed or inside an overlay. We ran into a similar issue in T286835 and have a standing request for the design systems team/mediawiki platform team in T289208 to provide clear guidelines on that.

Since the pinned menu in T347309#9248004 is persistent, we would be required to load Codex on page load. I don't see how to do this in a way that doesn't damage our existing site performance and that isn't blocked on the design systems (who are working on code splitting T335317)

There are possible compromises we could make to avoid these blockers:

  • introduce a control for revealing the functionality e.g. show/hide functionality and where hidden by default.
  • Instead of using radio buttons we might want to use links
  • We may want to limit the exposure of these controls on page view to logged in users only (the idea being that logged in users already run gadgets etc so performance is less of a concern)

@JScherer-WMF was going to review the above to see whether any would make sense.

Despite this I think we can build this out provided we are okay with the Codex code splitting being a blocker for a full release. As a next step I would propose we work on T350195.

@Jdlrobson, @JScherer-WMF - I think we're okay to go ahead and sign off on this one, do you agree? We can separately have the conversation of which version of the menu we want to start with for Version 1.

Change 969985 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] POC: typography settings interface


Working on the production version in

Change 969985 restored by Jdlrobson:

[mediawiki/skins/Vector@master] POC: typography settings interface