Page MenuHomePhabricator

Make non-responsive Monobook the default for German-language Wikipedia
Open, Needs TriagePublic

Description

As I have elaborated e.g. in T196215#4257219, Monobook is only used by experienced editors who prefer it because it provides them with a consistent working environment. There is no need for a responsive Monobook for this user group.

The (first) activation of the responsive Monobook skin caused significant, negative responses, with user scripts breaking the site layout in the mobile view (T196215).

I would therefore like to request that the user setting to enable responsive Monobook is set to disabled by default. If necessary, we are happy to demonstrate editor consensus.

Event Timeline

Cirdan created this task.Jun 8 2018, 4:47 AM
Isarra added a comment.Jun 8 2018, 7:37 AM

I would recommend against this. While currently the preference does indeed only govern one skin, the direction we would ideally be going is to add responsiveness to all skins - and you can bet your arse people are going to want the same option for Vector, and Timeless, and potentially also to be consolidated to govern Minvera/MF's weird fanciness. Having separate preferences that do the exact same thing on every single skin would quickly get ridiculous, and would likely also go against user expectation (if you've turned it off once, would you expect to have to turn it off for Vector, too?).

What this would mean in the end, on a project level, however, would that the entire site would not be responsive by default, for anyone - so once the option is given wider coverage, the site default would have to be changed regardless. And that would be a lot more painful at that point than the people who specifically don't want it opting out immediately at the point when they decide that, indeed, they simply don't want it. Otherwise they don't want it, don't have it for awhile without anyone specifically having to do anything, and then it shows up anyway and then everyone has to turn off the preference for themselves regardless.

(This doesn't actually block a site deciding to turn it off for everyone for now, but it is why I don't think it's a good idea.)

Cirdan added a comment.Jun 8 2018, 9:08 AM

I agree that if it becomes a global option, it is obviously a bad idea. But for now with the Monobook-only setting, it would really avoid all problems our editors are facing.

So would the editors in question just turning it off themselves, though. And in the meantime that way anyone new who starts using monobook is also more likely to see there even is a responsive option (that they can then decide if they want to turn it off as well). Things off by default are much harder to find.

Izno added a subscriber: Izno.Jun 8 2018, 1:14 PM
Cirdan added a comment.Jun 8 2018, 1:58 PM

It is very annoying and perceived as disrespectful if editors have to change their settings due to a change which has no effect on readers or is generally perceived as useful by the larger community.

How many people are switching to Monobook? How many actually want a responsive option? I'm very certain that this number and especially their contribution to our projects is minimal compared to the number of editors complaining. Why do you want to force a change on these valuable editors?

Isarra added a comment.Jun 8 2018, 3:57 PM

Eh, I've got no issue with you doing that if you want to do that. I'm just saying it's about the same amount of effort for you lot either way, and probably messier down the road if you do make it sitewide now.

Just get consensus and put in the config change/get someone who knows what they're doing to put it in, and that should be good enough to actually make it happen.

FWIW I do think this should be opt-in rather than opt-out. The existing workflows of editors are important and we should be respectful with any new development in allowing time for adoption and feedback. We made page previews opt-in for logged in users for this very reason.

stjn added a subscriber: stjn.Jun 10 2018, 2:15 PM

Page previews are not the same thing though: their lack is not detrimental to the experience of readers and users. If this development will prove to be good and will be eventually replicated in other skins as well, it would not make sense to have responsive skins turned off by default anywhere at all. However, if there’s a way to make this off only for older users, then it is an OK approach (although I should say that it would limit the ability and willingness of communities to implement more responsive layouts with things like TemplateStyles if majority of older users would not see any changes from this, so that must also be considered).

...wasn't page previews set like that because it'd conflict with the power user gadgets that also include the same functionality, along with a lot more? Or am I thinking of something else?

Does this conflict with an already extant solution I don't know about? (Pleasesayyespleasesayyespleasesayyes...)

TheDJ added a comment.EditedJun 13 2018, 8:40 AM

wasn't page previews set like that because it'd conflict

No, it has a separate mechanism for that, which just stops it from presenting when it detects that Navigation Popups is active (so not really disabled, just not showing).

Making PagePreviews opt-in for existing users (while preserving beta opt-in settings) was a decision that basically flowed out of this discussion in 2016: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_131#Proposal:_Enable_Hovercards_by_default

I ran a small poll and the participants are in favor of changing the setting to opt-in: Permalink.

stjn added a comment.Jun 13 2018, 6:20 PM

I ran a small poll and the participants are in favor of changing the setting to opt-in: Permalink.

Could you try to make a fairer description of that topic? It seems unfair to developers to do such survey under a topic ‘Strange portrayal’ and not mention anything at all about the changes they made based on community feedback, incl. yours (lower threshold for responsive layout, accessibility fixes etc.).

Furthermore, I don't think FzW is a sufficient platform for a community consencus to topics like that, as this really affects many users and isn't just a little technical detail. Furthermore, the whole discussion seems quite biased to me.

Cirdan added a comment.EditedJun 14 2018, 7:24 PM

Well, I thought that we had a policy along the lines of "we do not disrupt editor's UX with design changes unless there is an underlying security issue, something endangers the stability of our website, or the feature is relevant to new users or readers". That's why e.g. T163152: ERI Metrics fromrc=1 URL-extension breaks heavily used admin script led to rollback, that's why there was so much effort put in T127881: Enable VisualEditor for logged-out and newly registered users on German Wikipedia. Why does it make any difference to you whether this feature, which only very few people in the Wikimedia universe will ever come across, is opt-in or opt-out?

I'm certainly not going to put any more energy into this. If you are so eager to have this feature that after the first rushed deployment you do another one without proper investigation of all issues, waiting for the translation, and proper communication of the opt-out setting, so be it. That's not what I think of as good practice in our volunteer-driven ecosystem.

If you are so eager to have this feature that after the first rushed deployment you do another one without proper investigation of all issues, waiting for the translation, and proper communication of the opt-out setting, so be it. That's not what I think of as good practice in our volunteer-driven ecosystem.

> "volunteer-driven ecosystem"
> expecting volunteers to do all that before making anything

Seriously, do you really expect actual volunteers to have any idea how to do that ever? Staff don't even always get this right, and they have resources and management and people keeping track of all the steps, and generally don't go months or years between doing things and thus lose track of stuff/have everything totally change underfoot regardless, and have time to devote to actually fixing and addressing things that do arise with some immediacy... (If they don't have these things, something is either very wrong, or they were contributing in a volunteer capacity as well.)

Vvjjkkii renamed this task from Make non-responsive Monobook the default for German-language Wikipedia to uebaaaaaaa.Jul 1 2018, 1:05 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
Ahecht renamed this task from uebaaaaaaa to Make non-responsive Monobook the default for German-language Wikipedia.Jul 2 2018, 1:49 AM
Ahecht lowered the priority of this task from High to Normal.
Ahecht updated the task description. (Show Details)
Ahecht added a subscriber: Aklapper.
Ahecht raised the priority of this task from Normal to Needs Triage.Jul 2 2018, 2:05 AM
Evad37 moved this task from Backlog to Responsive MonoBook on the MonoBook board.Aug 21 2018, 7:32 AM