**As a mobile editor, I want to change my user preferences with the confidence that I'm not going to configure a setting which doesn't affect my experience, so that I don't get confused.**
As part of our work to investigate [[ https://www.mediawiki.org/wiki/Moderator_Tools/Content_moderation_on_mobile_web/Preferences | making Special:Preferences available to mobile editors ]], we discovered that many settings do not change anything for mobile users.
While some tabs only contain settings which are applicable to users on any device (User Profile and Notifications), others contain a mix of applicable and non-applicable settings. For example, the Search tab contains some settings to configure the default number of search results to display, which works on both mobile and desktop views. However it also contains settings to configure advanced search settings, which is not displayed on mobile.
Ideally, mobile editors would either not see settings which don't affect their experience, or these would be flagged in such a way that this is understood. We want to understand the technical feasibility of flagging or completely hiding certain options on a per-setting basis.
**Questions**
- Some settings are only shown on certain projects. How are settings currently configured for display? Are there any existing options for hiding settings based on the user's skin or device?
- We can hide settings individually with the `hide-if` parameter and by creating a [[ https://www.mediawiki.org/wiki/Manual:HTMLForm_Tutorial_3#hidden | hidden field ]] that indicates whether a user is using Minerva or not. You can check a small PoC on the Gerrit patch attached to this ticket. We can also add more hidden fields if necessary. For example, if a setting can be shown if AMC is turned on.
- If not currently feasible, how might we flag or hide specific settings based on the user's skin?
- We can hide specific settings based on user skin. See above.
- If this is not currently technically feasible, what would the steps be to implement this functionality? If this is too large a question for a single spike, or would require substantial investment from technology teams, please explain how the problem needs to be broken up.