Is this is a good idea? The preferences are for your account, not your device, so they might need to be altered by a user when they're on mobile but for when they're on desktop (and vice versa). I suppose that's a rare use case, but our normal UX approach has been to disable-and-explain rather than mystery-hide inappropriate UX triggers.

Instead, would it be better to explain in the UX that they don't apply to mobile?

In T311719#8108900, @Jdforrester-WMF wrote:

Is this is a good idea? The preferences are for your account, not your device, so they might need to be altered by a user when they're on mobile but for when they're on desktop (and vice versa). I suppose that's a rare use case, but our normal UX approach has been to disable-and-explain rather than mystery-hide inappropriate UX triggers.

Instead, would it be better to explain in the UX that they don't apply to mobile?

@aminalhazwani and I have gone back and forth on that question a few times. I agree in principle, though I'd argue that the preferences we're talking about hiding are for your skin rather than your account. Almost all of the settings in the 'Editing' tab are really for 'Editing in Vector'. For mobile-only users (approximately half of our active mobile-first users), these settings are less than useless, even if explained. All other things being equal we're trying to centre the experiences of those mobile-only users because they may have absolutely no frame of reference for desktop functionality - the mobile interface needs to be self-explanatory and clear.

I think there's a parallel to be drawn with settings which we hide based on which Wikimedia project you're on. Wikimedia Commons, for example, has a 'Search' tab which we don't show to users on other Wikimedia projects - it would be confusing to show that to them even if it was labelled as 'Wikimedia Commons-only'.

I'm also not sure what the use case would be for a user determining that one of the above listed settings needed changing, and they were going to do so on their mobile device. If the user is on desktop, I can't imagine them pulling their phone out to toggle a preference, and if they're on mobile they're not going to encounter a situation which prompts them to want to change one of these settings. (The 'Revision scoring' settings are an exception because I think they might be bugged rather than intentionally non-functional, I'm looking into this).

Right now we're operating on the basis that even with hidden settings, making the other preferences available and linked-to is a direct improvement over the status quo where none of these preferences are accessible. I absolutely want to get user feedback on the issue of hidden or non-functional preferences though, and then we can evaluate from there whether something like labelling is necessary.

Thanks for sharing your concerns @Jdforrester-WMF. I'm also happy to share additional details!

Is this is a good idea? The preferences are for your account, not your device, so they might need to be altered by a user when they're on mobile but for when they're on desktop (and vice versa).

We don't think the decision has to be binary. For some of the preferences it makes sense to prioritize the account, eg. changing your password should be the same experience on any device or platform, while for other preferences it makes sense to prioritize the device, eg. search results, an editor might prefer to view fewer results on a device with a smaller screen.

I suppose that's a rare use case, but our normal UX approach has been to disable-and-explain rather than mystery-hide inappropriate UX triggers.

Instead, would it be better to explain in the UX that they don't apply to mobile?

Yes, it has been our "normal" UX approach, but it's symptomatic of a desktop-first perspective, where we assume that all of our editors have both a desktop and a mobile device (and where we also assume that all preferences work equally on any device, which is unfortunately not the case). We suggest to promote a mobile-first approach, where we display only the things that an editor can control on their mobile device. Rather than telling them what they can't do because they're on a "wrong" device, we display features they can actually interact with, without any additional information about a (desktop) device that they might not even own.

Moreover, we also have to consider the current state of the art, which is Special:MobileOptions. Therefore, we are not really hiding things, because those things are not easily accessible in the first place. Our strategy is to incrementally display desktop preferences that also work on mobile web, and carefully listen to the community feedback along the way to prioritize this.

I hope this can help to better understand our rationale behind this, I'm more than happy to further expand if necessary!

Note that tests are currently failing in the proof of concept generated for T307909, so exploring the reasons for that will be within the scope of this ticket.

This should probably be blocked by T311717.

Change 832010 had a related patch set uploaded (by Scardenasmolinar; author: Scardenasmolinar):

[mediawiki/core@master] [WIP] - Hide preferences on Special:Preferences for mobile

https://gerrit.wikimedia.org/r/832010

In T311719#8120396, @Samwalton9 wrote:

Note that tests are currently failing in the proof of concept generated for T307909, so exploring the reasons for that will be within the scope of this ticket.

Additional documentation that helped fix the failing tests: https://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions and https://www.mediawiki.org/wiki/Manual:Hooks/GetPreferences.

Test wiki created on Patch demo by SCardenas (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/c34aff28ab/w

Test wiki on Patch demo by SCardenas (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/c34aff28ab/w/

Test wiki created on Patch demo by SCardenas (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/c15f1060a8/w

Looking at the Patch Demo I'm seeing a preference that wasn't displaying in the production project I looked at as my source of truth

Reference previews and page previews should both be hidden in this section

Reference previews and page previews should both be hidden in this section

This might be because Page previews works on the mobile site when you have a non-touch device (try desktop browser on https://en.m.wikipedia.org/wiki/Main_Page). It's logic is a little more complicated than "is on mobile". I guess we'd want to add something inside the Popups extension to disable that preference for mobile users if we decided it was confusing.

Test wiki on Patch demo by SCardenas (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/c15f1060a8/w/

Having reviewed the dialog and the PoC code on this, I believe:

• When we envisioned this task we had a less-than-clear understanding of the multidimensional matrix of users experiences enabled by combining core, skins, mobileFrontend, and configuration across multiple projects
• This should not be a part of the MVP for mobile preferences, since users mobile users can achieve everything we set out to enable without this
• If we want to pursue treating settings differently based on mobile/desktop, it should probably happen in mobileFrontend
  • The simplest implementation I can conceive would be for us to maintain an exclude list of preferences that we hide in mobileFrontend
• If we can't come to a solution we (including readers web) all like in mobileFrontend, we should just backlog this and come back to it when we (moderator tools) have more experience.
• We've actually hit on a different, bigger problem than mobile/desktop: preferences demands a high cognitive investment from users because it presents so many preferences with the sections being the only tool to filter the set for applicability
  • a solution that makes it to core should probably try to address that larger problem

Another thought: if we are going to hide preferences in mobile: we should inform users and give them the option to unhide them; eg. perhaps at the bottom of a section with hidden settings, there could be a notice and a button so that a user could view all settings if they don't find what they need in the filtered set.

To Jasons' thought, it seems to me that anything that is not necessary for the end user to see is the best way to go for a handheld device - I guess the go to message if shown is to say it doesn't work in this skin set - I am trying to get away from mobile, because it does not include all hand held devices and to keep clear if we are referring to a part of the skin, or a part of the underlying code base. As an end user, I want to see things that work which are available to me based on personal AND device. Don't make me click something that just says it doesn't work in this environment. --- IMHO

In T311719#8432407, @jsn.sherman wrote:

Another thought: if we are going to hide preferences in mobile: we should inform users and give them the option to unhide them; eg. perhaps at the bottom of a section with hidden settings, there could be a notice and a button so that a user could view all settings if they don't find what they need in the filtered set.

@jsn.sherman to echo what @ERayfield shared just above, I'm reposting down here a comment that I shared early on about why it's not necessary to inform users about "missing" preferences. Moreover, I would like to highlight two important aspect to consider:

• We are not hiding preferences on mobile web, all the contrary. Today it's non-trivial to access user preferences on mobile web, what we're doing instead is to make user preferences much more accessible.
• We have to acknowledge (and prioritize) for those people whose only and primary device is a mobile device.

In T311719#8111357, @AAlhazwani-WMF wrote:

Thanks for sharing your concerns @Jdforrester-WMF. I'm also happy to share additional details!

Is this is a good idea? The preferences are for your account, not your device, so they might need to be altered by a user when they're on mobile but for when they're on desktop (and vice versa).

We don't think the decision has to be binary. For some of the preferences it makes sense to prioritize the account, eg. changing your password should be the same experience on any device or platform, while for other preferences it makes sense to prioritize the device, eg. search results, an editor might prefer to view fewer results on a device with a smaller screen.

I suppose that's a rare use case, but our normal UX approach has been to disable-and-explain rather than mystery-hide inappropriate UX triggers.

Instead, would it be better to explain in the UX that they don't apply to mobile?

Yes, it has been our "normal" UX approach, but it's symptomatic of a desktop-first perspective, where we assume that all of our editors have both a desktop and a mobile device (and where we also assume that all preferences work equally on any device, which is unfortunately not the case). We suggest to promote a mobile-first approach, where we display only the things that an editor can control on their mobile device. Rather than telling them what they can't do because they're on a "wrong" device, we display features they can actually interact with, without any additional information about a (desktop) device that they might not even own.

Moreover, we also have to consider the current state of the art, which is Special:MobileOptions. Therefore, we are not really hiding things, because those things are not easily accessible in the first place. Our strategy is to incrementally display desktop preferences that also work on mobile web, and carefully listen to the community feedback along the way to prioritize this.

I hope this can help to better understand our rationale behind this, I'm more than happy to further expand if necessary!

• We are not hiding preferences on mobile web, all the contrary. Today it's non-trivial to access user preferences on mobile web, what we're doing instead is to make user preferences much more accessible.

If we make no changes to what's in production right now, all preferences are visible on mobile devices (for users with AMC enabled). If we roll out what we have right now to all users, all preferences will be visible to all users on mobile devices. The stated goal of this task is to make some of those individual preferences go away. This is the hiding that I'm referring to.

• We have to acknowledge (and prioritize) for those people whose only and primary device is a mobile device.

100% agree.

To achieve that goal, there are technical and organizational considerations which the engineers have to sort through. We learned quite a bit about how wikimedia projects are deployed and maintained during our work to get the mobile layout merged. We're now intentionally going back and reviewing the tasks that were written before we had that experience.

For example, if we were doing the mobile preferences layout switching over again today, I would base the layout change on isResponsive (which is a thing core and skins are already aware of) instead of desktop/mobile. Here's why:

Mediawiki core is mostly device agnostic. The resource loader, and now the preferences layout are the two exceptions to that. That concept of mobile/desktop had to be added to skins/extensions that run in production on enwiki because we added it to core preferences. We've received pretty consistent feedback on the engineering side that going responsive will have longer-lasting impact for the effort, and now I understand why.

We thought the mobile/desktop approach would be a quick win, but it wasn't. We spent a lot of time working out the machinery and updating extensions to work with the concept of desktop/mobile. We are now effectively owners and maintainers of that machinery. That work (whose scope we didn't previously understand) could have gone into a responsive layout that didn't need per-skin/extension opt-in and would have left us with less thorny code to maintain.

There are other areas that need improved for mobile users, like page diffs, as well as another project we have been asked to look at. We are also the maintainers of the Wikipedia Library. If we want to make progress on a mobile first strategy, we need to make sure sustainability is a top-level consideration. Otherwise, we will quickly spread ourselves too thin to be able to make any progress.

Rather than continuing to grow the presence of mobile/desktop switching code in core, I think we should try to limit that kind of logic to mobileFrontend. If the mobileFrontend maintainers think we may be taking the wrong tack, then we should consider other approaches. I'm suggesting that if we can't come up with a solution that is feasible to implement and maintain, we should backlog this task and come back to it when we (the engineers) have more mediawiki experience under our belt.

Change 832010 abandoned by Scardenasmolinar:

[mediawiki/core@master] [WIP] - Hide preferences on Special:Preferences for mobile

Reason:

We are not planning on hiding preferences at the moment

https://gerrit.wikimedia.org/r/832010

We stumbled into this causing an issue for a user providing feedback on T203151 -- they were, as far as they could tell, changing their skin in the mobile-preferences, and were confused by how this didn't really change their skin (because MobileFrontend).

I wonder whether a useful interim "fix" would be to have a note -- either a brief banner on the preferences page, or in the mobile-settings link to the preferences page -- calling out that not all the preferences will apply to the mobile experience?

I personally think the mobile skin should be a preference like the desktop skin: T173527 I think this would go a long way to reducing confusion. Alternatively perhaps the label could be changed from skin to "Desktop skin" (at least when MobileFrontend is installed or using WikimediaMessages?)