The patch above https://gerrit.wikimedia.org/r/1028550 doesn't change any layout related behaviour, it just disables the width toggle on pages that are marked as "excluded" in the configuration (i.e. "always wide").

Change #1028550 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add exclusion notice for "width" option in Appearance menu

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

Change #1030989 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/Vector@master] Make pages excluded from $wgVectorMaxWidthOptions reflect "wide" setting

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

Change #1030985 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Revert "Add exclusion notice for "width" option in Appearance menu"

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

Change #1030985 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Revert "Add exclusion notice for "width" option in Appearance menu"

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

After chatting with the team this morning we decided to revert the change and refine the task requirements a little more. I've reverted the patch and we'll look at https://gerrit.wikimedia.org/r/1030989 with Justin.

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

We're talk about this in our task sync on Thursday with @JScherer-WMF

Compare https://patchdemo.wmflabs.org/wikis/73e580f3f4/wiki/Main_Page?vectorappearance=1 with https://en.wikipedia.org/wiki/Main_Page?vectornightmode=1

Discussed this with @Jdrewniak and @Jdlrobson and we decided on 2 interventions:

1. We don't hide width toggle for viewports below 1600px. Instead, we disable it with a message like we do for other exceptions.
2. Our "wide" is always the width of the viewport, not the content area. So wide always means viewport-wide, regardless of viewport size.

Change #1032842 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/Vector@master] Add exclusion behaviour for "width" option in Appearance menu

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

Change #1030989 abandoned by Jdrewniak:

[mediawiki/skins/Vector@master] Make pages excluded from $wgVectorMaxWidthOptions reflect "wide" setting

Reason:

Superseded by: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1032842

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

Change #1032842 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add exclusion behaviour for "width" option in Appearance menu

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

Change #1034990 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/Vector@master] Revert "Add exclusion behaviour for "width" option in Appearance menu"

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

Change #1034993 had a related patch set uploaded (by Jdlrobson; author: Jdrewniak):

[mediawiki/skins/Vector@wmf/1.43.0-wmf.6] Revert "Add exclusion behaviour for "width" option in Appearance menu"

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

Change #1034993 merged by jenkins-bot:

[mediawiki/skins/Vector@wmf/1.43.0-wmf.6] Revert "Add exclusion behaviour for "width" option in Appearance menu"

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

Mentioned in SAL (#wikimedia-operations) [2024-05-22T20:33:29Z] <jdrewniak@deploy1002> Started scap: Backport for [[gerrit:1034993|Revert "Add exclusion behaviour for "width" option in Appearance menu" (T364015)]], [[gerrit:1034992|Small font size is not applying to excluded pages (T364887 T365408)]]

Mentioned in SAL (#wikimedia-operations) [2024-05-22T20:36:22Z] <jdrewniak@deploy1002> jdrewniak and jdlrobson: Backport for [[gerrit:1034993|Revert "Add exclusion behaviour for "width" option in Appearance menu" (T364015)]], [[gerrit:1034992|Small font size is not applying to excluded pages (T364887 T365408)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-05-22T20:50:16Z] <jdrewniak@deploy1002> Finished scap: Backport for [[gerrit:1034993|Revert "Add exclusion behaviour for "width" option in Appearance menu" (T364015)]], [[gerrit:1034992|Small font size is not applying to excluded pages (T364887 T365408)]] (duration: 16m 46s)

Change #1034990 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Revert "Add exclusion behaviour for "width" option in Appearance menu"

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

Thanks very much for the overview on this @Jdrewniak!

From my perspective there are a few things that have happened here. This is a good example of small UX shortcuts and compromises adding up into a tangled mess of an experience when they compound with eachother.

• • We let users override the default width in V22 for reasons that were discussed before my time. I'm curious @ovasileva to read the paper trail of this decision.
    • A lot of the churn comes from my lack of understanding of why anyone would want anything other than the default width for any page. What is the "wide" use case really? What are the root causes and motivations behind it?
    • Are people really looking at a full-width browser window on a 2000+px wide screen?
      • Surely some people are, but how often? How many people? We have no notion of how prevalent (or not) these use cases are very rarely (see below).
  • We decided to disappear the width toggle below a certain viewport size without explaining anything, which we inherited in the width control in the appearance menu. We got rid of this hiding behaviour in favour of disabling the width control at viewport sizes where it no longer has an effect with a disclaimer to that effect. I want to keep this behaviour where the width control remains and doesn't disappear regardless of viewport width.
  • Certain pages, like home pages, have lots of skinny little columns and floating images, which makes them less readable at larger font sizes because the characters per line in that column is decreased below accessibility/usability standards.
    • We wanted to default those pages to wide to provide a good default reading experience. Also, they are read by a lot of casual, non-contributor readers.
    • These pages already default to the "wide" setting by default. They don't get wider when you click "wide" in settings unless your viewport is over wide.
  • Rather than overriding the defaults for pages on the exception list and allowing users to change the controls, we decided to disable the width control on those pages and force readers into a certain width because overriding defaults for certain pages was too technically complex. This decision has left us in a place where we're now "forcing" certain users into a very wide view.
  • Some users think "wide" isn't wide enough and want a full-width view. Some users with ultrawide monitors think the full-width is too wide.
    • The discrepancies between two flavours of wide is a bit silly, in my opinion, and only affects folks with viewports over 1920px wide. I want to have one definition of wide for all pages.
      • That was a large part of the decision to make wide always mean full-width: Removing inconsistencies and layout nuances that the vast majority of readers and contributors neither need nor want to understand.
• Ways forward:
  • I think we may have come at this in the wrong way in the first place. We could just get rid of the exception list for page width and allow readers and contributors to adjust the width of their screen to their preference using a combination of the existing font size and width controls. This is the simplest solution. This also favours user control and freedom over our control of the default experience, which is better aligned with our design philosophy and values. We don't really have viable data about reader behaviour to inform the design decision.
    • The tradeoffs for this are that some casual readers will get a less than optimally readable experience by default.
    • Some users may need to adjust width fairly often.
      • The prominence and permanence of the appearance settings mitigate this problem somewhat.
  • We do our due diligence on actually understanding the use case for wide and adjust the designs accordingly:
    • We do a proper data analysis of viewport sizes, if we don't have it already.
    • We do a community survey asking about why folks prefer wide views for things
    • We can also look at our prototyping exercise from font-size and see what folks' viewport widths were as a sample.
      • I scraped our Prototype responses with GPT and have a sample of 195 viewport resolutions, which could assume is a somewhat representative sample of powerusers.
  • We introduce a new "advanced custom width" feature for folks with atypical monitor sizes.
    • I think this would serve a lot of power users who prefer both very wide or very narrow viewports.
  • We un-revert the patch at 1032842 and ask folks with ultrawide viewports to scale their browsers down to the width they prefer.
  • We formalize all three widths "Standard, wide, extra wide" and get rid of the exception list. We figure out how to deal with situations where "extra wide" is impossible.
  • we ask home page maintainers to re-design them to have fewer, wider columns.

What do folks think? @sgrabarczuk @ovasileva @Jdlrobson @Jdrewniak

Elaborating on the data I pulled from the prototyping exercise

• Of 195 respondents, only 4 (2%) had viewport widths over 1920px, and they were all 2560px.
• 145 respondents (75%) had widths below 1920px.
• 1920px was the most common resolution (n = 43, 22%), followed by 1366px (n = 32, 16%) and ~1280px (n = 23, 12%)
• 23% (n = 45) of the widths corresponded to "tablet" sizes <= 1280px

This suggests to me that the "full-width is too wide" segment is very small, and that 1032842 might be fine, after all.

I'll also bring this to a design review on Thursday and see what the rest of the design team thinks about it.

I spoke with Olga about this briefly and she proposed that we change the definition of Standard for these pages to be the content width, the wide would be viewport-wide still, and we never need to disable the setting. At first glance, I think this is a good solution.

Noting that this is a can of worms, but worth us reexamining at some point

@Jdrewniak: Web-Team was archived. Please either resolve/decline this task or add an active project tag so this open task can be found on a workboard. Thanks.

Assuming this lingering task with no active project tags is about the Vector 2022 codebase. Please add codebase project tags to tasks.