Moderator Tools/Content moderation on mobile web/Preferences



The Moderator Tools team at the Wikimedia Foundation is currently working on improvements to Special:Preferences on mobile web. We would love to hear what you like and don't like about our progress so far.

Please share your thoughts about the Preferences page on the talk page.

Background
As of June 2022, users of the MinervaNeue (mobile web) skin cannot access Special:Preferences from the user interface. The only way to reach this page is to directly navigate to it via the search bar or switch to desktop view. Since Preferences contains critical user account features such as changing passwords, updating email addresses, configuring notifications, and accessing anti-harassment features, we are planning to work on bringing this page to mobile.

To do this we need to make some changes to how Preferences is displayed at mobile screen sizes. For the desktop view it uses a tab system which becomes scrollable on narrow mobile devices, which is unclear to users. The responsive resizing of fields and explanatory text leaves many settings squashed or with large amounts of text near them. Additionally, many preferences have no effect for mobile-only users. The mobile skin also has a separate mobile settings option, which is additionally available to logged-out users. We need to decide if and how we can present these settings alongside user preferences in a way which is understandable.

Implementation steps and progress
We are currently working on implementing the new page design for mobile users. We decided on Option A from the main menu designs listed below, and decided to move ahead with the other proposed elements.

You can track progress of the technical steps for implementing the first round of design changes at T311708.

We plan to deploy these changes for users with Advanced Mobile Contributions enabled first for testing and feedback, before a wider rollout for all users. We're aiming for each change to be compatible with all the existing functionality of Special:Preferences (i.e. we shouldn't ever have a non-functional page).

Design
Below you will find some early design explorations and options for the different ways we could present this interface for mobile users. We have now made decisions about how to proceed, but your input is still welcomed.

Main menu
The scrollable tabs in Preferences are unclear to users and not a common design pattern for menus with this many items. It takes users time to realise that the tabs can be scrolled, and locating a particular category is difficult. Additionally it isn't clear what settings will be found in any given category in advance. When we reviewed other mobile websites and apps we found that it was much more common for this kind of browsing to occur via a vertical menu of options, often with explanatory text to guide users. We designed a few different options for Special:Preferences:

Which option do you prefer, and why?

We added explanatory text under the menu headings in some variations - what do you think about the wording?

Modals
Preferences currently includes some items, like 'gender', which take up a lot of screen space with multiple options. If a user doesn't want to change that setting we could save screen space by not showing them all the options while they browse the page. We could, for example, move these to sub-menus that only display once clicked:

In this design we've re-used a modal system used in other mobile web systems. The page wouldn't reload to open the modal. What do you think about using the modal system for submenus?

Saving
The Save button takes up a substantial amount of screen space - we wanted to explore how preferences are saved to see if there were better options. One option is to have changes save automatically upon being changed, as is currently the case in Special:MobileOptions.

What do you think about automatic saving? How intuitive do you think it would be?

MobileOptions and Preferences
MinervaNeue has a 'Settings' option in the main menu, which takes users to Special:MobileOptions. In a previous iteration we suggested to have both a 'Settings' and 'Preferences' option in this menu. We are now exploring a less confusing approach where we keep the menu as is, and add a "Additional preferences" section that links to Special:Preferences.



What do you think of this approach?

General questions
We want to learn more about how editors use Special:Preferences overall so that we can better understand how to proceed with our design and UX directions.
 * Which preferences do you find yourself needing to access often?
 * Are there preferences which you need access on mobile more often than desktop?


 * Are there settings which only change desktop behaviour which you need to change from your mobile device?

21 July 2022
The team has been reviewing user feedback and have decided to move ahead with Option A for the main menu, and start with this design element as the first change. Further information on the deployment of these changes can be found in the section above.

22 June 2022
We have posted a new design exploration for bringing Special:Preferences into Special:MobileOptions. While we explore how to merge the two special pages, we opt for this temporary approach that doesn't break or change the users pattern of accessing their settings through the main menu option.

15 June 2022
We have posted design explorations for the various elements of this project which we are aiming to tackle in the section above, along with the open questions we still have. Input is welcomed on the talk page.

Alongside this, our engineers are investigating the technical feasibility of this project and constraining our design options.

6 May 2022
We have started by making an inventory of all user preferences and determining which have an effect in the mobile skin and which don't. From this we discovered that while the 'User profile' and 'Notifications' tabs are 100% effective for mobile-only users, most other tabs are a mix of settings which do and don't have any effect.

We are considering starting this work by making the 'User profile' and 'Notifications' tabs available on mobile, so that we have an expandable design, but don't need to concern ourselves with making technical and design decisions about splitting the tabs which have a mix of applicable and non-applicable options. At the same time, we don't want to hide these settings entirely, as some users may want to adjust desktop preferences from mobile.

In addition, we are beginning design explorations for a mobile-first user interface.