In Special:Preferences, most settings are altered within the primary page, and all preference changes are saved with the Save button:
When Preferences is viewed on mobile web, some settings take up a lot of screen space with multiple verbose options to select from. We want to understand the feasibility of including a link in Preferences which would open a full-screen modal to alter a given preference, which has its own Save button.
Example design
- Preferences displayed as a list, user clicks "Unspecified"
- Modal pops up over the top
- User can change a setting and click Save
Clicking the back/cancel button would take the user back to the settings menu without a page reload.
Questions
Since we haven't made a clear decision about whether this is the direction we would like to go, answers to these questions can be high level - we don't need to know the precise technical steps required to implement, just a high level understanding of the feasibility and complexity involved. If this modal system seems too technically complex or infeasible, we can explore other options.
- How feasible would it be to split some preferences into modals on mobile web?
- In the MobileFrontend extension, a couple of JS functions (Overlay and OverlayManager) can create an overlay. We can leverage those functions for every preference item we want to show an overlay. If we want to use OOUI, we can use a dialog that acts as a modal.
- Could we do the same for settings like changing the password or email address, where the settings are currently found on a different Special page?
- MobileFrontEnd does this with Special:MobileLanguages. When you are using the Minerva skin on desktop or you are in mobile view, you can navigate to an article that is translated in different languages and click on the Languages button in the action bar. Instead of taking you to a separate page, it displays an overlay, added in the mw-overlays-container div.
- Would using this modal system increase the data footprint of Preferences substantially?
- As discussed in our team check-in today, an OOUI dialog won't increase the data footprint and shouldn't hinder the page's performance.
- These modals are based on those used elsewhere in mobile web (e.g. in the editor). How easy would it be to re-use these design elements?
