We are exploring different ways of displaying Special:Preferences on mobile web so that the visual style is more intuitive to users. The current style, where each section is a tab as part of a scrollable bar, is unintuitive on mobile.
To find a better layout we are considering a menu style, where the tabs would be arranged vertically and open up sub-menus. This style would only apply on mobile, and we are not currently planning on making changes to the desktop view. We want to understand whether it is technically feasible to lay the page out like this on mobile without changing the desktop page, and without creating an entirely new mobile-specific Special page.
Example designs
 |  |
Questions
- What is the technical feasibility of implementing a menu design like those sketched above for Special:Preferences on mobile devices (i.e. in the MinervaNeue skin)?
- The designs above implement a list view menu layout. Currently there is no such menu demonstrated here. One layout we might consider, and is available currently in OOUI, is the BookletLayout show below:
-
The front end layout is based on Handlebars templating which means we can create a list item view in a HandleBars template and reuse as needed. - Desktop and mobile both share the same preference page - which requires making changes to mediawiki core (heaviest lift). However since MobileFrontEnd provides a way to overwrite/re-route core pages specifically for mobile, we may be able to create a MobileFrontEnd specific SpecialPreferences page( slightly less heavy lift)
- We have icons available to be used here
- Could we implement this design without also redesigning the desktop Preferences layout?
-
We could implement this design without redesign and hook into the mobile page logic to present a mobile friendly <template> version in list view. - Yes, MobileFrontEnd might provide a way for us to create a mobile specific version of preferences with css/js injection.
- Otherwise due to the tightly coupled nature of this menu in mediawiki core as demonstrated here and here a refactor would be needed.
