Should the Vector 2022 skin be deployed as the default to English Wikipedia on desktop at this time (pending completion of tasks already agreed upon by the community)? OVasileva (WMF), SGrabarczuk (WMF) (talk) 15:02, 21 September 2022 (UTC)[reply]

The skin introduces changes to the navigation and layout of the site, adds persistent elements such as a sticky header and Table of Contents, and makes changes to the overall styling of the page. Currently, the skin is the default on more than 30 projects of various sizes, accounting for a bit more than 1 billion pageviews per month. To preview what the skin looks like, go to this article (open in a private browser window to see what it will look like for a logged-out reader).

This is an RfC written by the Web team at the Wikimedia Foundation (WMF), with help from a number of community members after several months of preparation and discussion at the Village Pump.

The WMF Web team has been working on the Vector 2022 skin for three years. Since July 2022, there has been a discussion on the Village Pump on the needs of the English Wikipedia community. Within that discussion, the community decided on the changes necessary before deployment, which the Web team is addressing. The community also recommended that the next step would be this RfC.

If there's consensus for deploying Vector 2022, the skin would be turned on for all logged-out users, and also all logged-in users who currently use Vector legacy (2010) in a deployment with multiple stages to ensure sufficient time for testing. Logged-in users can at any time switch to any other available skin.

If the community decides against deploying the skin, no deployment will be made. The Web team will review the comments, propose further changes based on the feedback, and begin another RfC once the necessary changes are agreed upon.

The Web team would like to thank the many Wikipedians who have worked on this skin and given their feedback and guidance. To name just about a dozen: Barkeep49, BilledMammal, Certes, Enterprisey, Femke, Ganesha811, Izno, L235, Pelagic, Sdkb, Sj, Terasail, TheDJ, WhatamIdoing, xaosflux, and Xeno. Thank you!

This section was written by the web team to highlight the main findings from the team's analysis of A/B tests and other quantitative data. The list is not exhaustive of all research, quantitative, and qualitative findings throughout the project. The full background on the skin and details on the data analysis can be found on a separate page. Note: we're doing this to keep the opening statement as neutral as possible and to shorten the length and information, as per the recommendation of the community.

The analysis of the data done by the Product Analytics team concluded that these changes improve readability and usability, and save time spent in scrolling, searching, and navigating – all of which was interpreted by the team to create an easier reading experience. The new skin does not remove any functionality currently available on the Vector skin.

Results at a glance

• On average, 87% of active editors across our pilot wikis (incl. French and Portuguese Wikipedias) continue to use the new skin once they try it.
• The sticky header decreases the amount of scrolling logged-in users have to do by giving access to tools that editors use most frequently. It decreases scrolling to the top of the page by 16%.
• The new table of contents increases navigation to different sections. Readers and editors jumped between sections 50% more than with the old table of contents.
• The new search bar was built to make it easier to find the correct search result from the list. This increased the amount of searches started by 30% on the wikis where tests were performed.
• PHP code in Wikimedia deployed skins has been reduced by 75%
• The skin does not negatively affect pageviews, edit rates, or account creation. There is observational evidence of increases in pageviews and account creation across partner communities.

Rationale discussion

Responses to common questions from the Web team

Why should we make the change now?

Though no interface can ever be perfect, we believe that the new skin is a big improvement for readers on desktop already. We want them to start benefiting, even as we strive to make the skin better into the future. We believe this change will be crucial to making the contents of the project more readable, the projects' interfaces more welcoming to less-technical contributors, and thus, to the overall growth of new readers and editors.

Why are you sure the new skin is an improvement over the old skin?

The results and analysis of A/B testing and qualitative testing confirmed the team's initial hypothesis that these changes make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more, without negative effects to pageviews, account creation, or edit rates when compared to the Vector skin. The team has been working on the new skin for the past three years, ensuring that every change is tested and proven to work.

The current skin is good enough for me; why do we need to change?

The current skin, Vector, has been in use since 2010. When it was developed, it reflected the needs of the readers and editors of the Wikimedia sites in that year. (See the Wikimedia Usability Initiative wiki for more information.) Since then, vast new audiences have begun using the Internet and Wikimedia projects. Research done with these audiences showed that the current default skin doesn't meet their needs. The Vector 2022 skin aims to change the interface in ways which include the needs of all of the current audiences – both those who have been using the projects for a long time, as well as those who have joined more recently, or have yet to join.

What if I don't like a particular feature in the skin?

It is possible to configure and personalize the changes. The Web team offers support for volunteers with technical skills who would like to create new gadgets and user scripts. So far, many gadgets and user scripts have been built by community developers that customize different aspects of the new skin, including restoring full width, disabling sticky elements, restoring the old table of contents, and more. Check out the repository for a list of currently available customizations, or to add your own.

Can you just tell me how do I opt out from it? Do I need to do that if I'm using Monobook or Timeless?

If you're using the current default, go to your preferences and select Vector legacy (2010). You may also opt-out across all the wikis using global preferences. If you're using Monobook or Timeless, you will not notice the change.

What changes does the new skin bring?

The skin includes changes to the layout of the site, location and prominence of some features, the overall readability, and addition of sticky features. This improves the overall readability and usability of the site. Among the best-received by the communities, there are the new Table of Contents, sticky header, and the search widget. No existing features or tools were removed as a result of the new skin.

Will you support the skin in the future?

This is not a one-shot project, and we will continue working on the Vector 2022 skin. First, we will be working on the page tools feature, to be completed in October/November 2022. Then, we will collaborate with the Growth and Editing teams on making it easier to learn about how the wikis work and begin editing. For more details, see the sub-page.

Apart from that, we strongly encourage you to go to our FAQ page. OVasileva (WMF), SGrabarczuk (WMF) (talk) 15:02, 21 September 2022 (UTC)[reply]

Support

Yes, the Vector 2022 skin can be deployed. (This section may cover different kinds of support, like "I may opt-out but I don't mind it becoming the default.")

1. Support - While I still think there are issues (width being the primary one), it's about time we updated the default skin. Vector 2010 is starting to show its age. Anarchyte (talk) 16:24, 22 September 2022 (UTC)[reply]
2. Strong Support - the 2022 skin is not perfect, but the 2010 skin is much farther from perfect. The English Wikipedia community is conservative by nature, but I hope we will adopt this needed change to benefit readers and editors alike. —Ganesha811 (talk) 16:28, 22 September 2022 (UTC)[reply]
3. Support Andre🚐 16:28, 22 September 2022 (UTC)[reply]
4. Support not interested in using it myself, but I do think it is likely to be more user-friendly for beginners. (t · c) buidhe 16:44, 22 September 2022 (UTC)[reply]
5. Strongly Support My only skin for all my accounts on all Wikimedia wikis. Zippybonzo | Talk (he|him) 17:01, 22 September 2022 (UTC)[reply]
6. Support at this time. Will keep monitoring. --SarekOfVulcan (talk) 17:17, 22 September 2022 (UTC)[reply]
7. Support: I have been using it for a while now, I think that it is an improvement overall and think it would benefit logged-out readers in particular to have this as default. Terasail^[✉️] 17:37, 22 September 2022 (UTC)[reply]
8. Support. It's a more simple design than the previous skin. Agusbou2015 (talk) 18:41, 22 September 2022 (UTC)[reply]
9. Support; I'm using it for almost a year now on all projects, and find it clearly fit for use as default skin for all users—including particularly unregistered readers. —MisterSynergy (talk) 19:02, 22 September 2022 (UTC)[reply]
10. Support - Not anywhere near perfect, but good enough. Schierbecker (talk) 19:09, 22 September 2022 (UTC)[reply]
11. Strong support: Vector 2022 is an extreme improvement in readability and look that is strongly needed in 2022. People come to Wikipedia because they know it has the information they're looking for. The only reason they might go to another website is because that site might present the information in a more digestible way. The current unconstrained width of Wikipedia with its extremely long line lengths makes reading uncomfortable and you feel like you're thrown a ton of information at once. Vector 2022 solves all of this and has been a great experience to use. Second, the simplified user interface with the sidebar hidden by-default, the user-account menu in the upper right being collapsed, and the new languages browser allow the user to not be distracted by elements that they 99% likely do not use yet still provides great iconology to promote to users that the features are still available. I especially like the larger "Create account" button. The positive effects of these changes is supported by the proposal's statement above, "There is observational evidence of increases in pageviews and account creation across partner communities.", which should be a green flag to the community that these changes will actually grow the movement. Finally, it's table contents improvements are life-changing compared to the old table contents which looks awful and has been an extreme pain to users for a number of years because it completely blocks the flow of the article. The proposal above states that through testing this has had the dramatic benefits of "decreases scrolling to the top of the page by 16%" and "Readers and editors jumped between sections 50% more". Vector 2022's improvements will show to typical readers that Wikipedia is an evolving resource and not just a static resource that looks like it's from 2010 and run by nerds. Lectrician1 (talk) 20:19, 22 September 2022 (UTC)[reply]

    Frankly, it does look like it's run by nerds. The defensive "thank you for asking that question" stance in the surprisingly large number of rebuttals to Oppose comments is one hint. A bigger hint is that there isn't much granularity or transparency in regard to the "facts" that support this decision. I clicked the bold "details on the data analysis" and went to the separate page which merely clarified bullet 4 in the Key Results section (top of this RfC page) as "searches initiated". Why is that necessarily salutary? It could be the reverse: search errors are more frequent (i.e., repeating a search counts as initiated) or info within the page is less readable (i.e., user needs to search via algorithm rather than own eyes). In other words, there seems to be a bubble effect or group-think about surveys which assumes/presumes a correct way to frame Key Results. See also the manipulation-by-conflation of survey stats pointed out by BilledMammal (graphs) and Red-Tailed Hawk (data) in Oppose #3. Martindo (talk) 08:01, 24 September 2022 (UTC)[reply]

    Stats are more impressive when given in context, which typically moves the POV closer to balance/NPOV. For example:

    Currently, the skin is the default on more than 30 projects of various sizes, accounting for a bit more than 1 billion pageviews per month.

    Wow! But wait, what is the total number of pageviews per month for the entire wikipedia across all projects?

    Not mentioning that number (or % that currently use the default) is a characteristic of nerdishness. Martindo (talk) 01:23, 25 September 2022 (UTC)[reply]

12. Support We don't own Wikipedia and the WMF can do whatever it wants on techincal matters --Guerillero ^{Parlez Moi} 20:22, 22 September 2022 (UTC)[reply]

    This page is a request for comment, WMF Is asking the community for their opinion on the changes. If WMF were to truly do whatever it wants with no control, we would not be at this point today at all. PerryPerryD Talk To Me 20:24, 22 September 2022 (UTC)[reply]

    True. Even an oligarchy is subject to popular will to some extent. If they foster a situation that devolves into starvation (or serious impediments to usability/popularity/revenue in the case of WMF), they will be unseated one way or the other. It is simple wisdom and self-preservation to take the pulse of the populace. The next step is to ask whether the information offered in the request for support is accurate and fairly interpreted, or merely spun/obfuscated. Martindo (talk) 08:09, 24 September 2022 (UTC)[reply]

    This is incredibly flawed and the same logic could be used to support even superprotect. --Rschen7754 00:14, 23 September 2022 (UTC)[reply]

    Media viewer is a global default despite the best efforts of the German Wikipedia which forced the creation of superprotect. We can ask nicely, but we have no control over how the devs and sysadmins do their jobs. Per WP:CONEXCEPT "These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features" (emphasis added). Changing the skin clearly falls under the list of things that does not need community approval and something that we can not bind the WMF on under existing policy. If we reject new vector it will be implemented as the global default in a number of years without an opt-out for us. -- Guerillero ^{Parlez Moi} 10:03, 23 September 2022 (UTC)[reply]

    By this reasoning alone, you could have prefixed your message with "Oppose" as well (with a meaning like "I don't like this, but I have no choice"). So if I understand correctly, there is something beyond "they can do so" that made you support rather than oppose. If you could point that out, and even if it's just "looks better", I think that would improve the overview. ~ ToBeFree (talk) 18:33, 23 September 2022 (UTC)[reply]

13. Support. The table of contents on the left side of the Vector 2022 skin is a much better use of space than the blank bar in the Vector legacy skin. Being able to see where you are in the article and being able to jump from section to section without needing to scroll around is a massive usability improvement for our readers. — Newslinger talk 20:28, 22 September 2022 (UTC)[reply]
14. Support: I've been using the new Vector since it was released on first early adaptor wikis, and I find it so much easier to read and navigate with the limited width. I believe it should be enabled globally as soon as possible. Betseg (talk) 20:52, 22 September 2022 (UTC)[reply]
15. Very weak support I could potentially get used to it with MediaWiki:Gadget-wide-vector-2022.css in place, but it wasn't obvious to be at first what the very top-left button did in terms of the left-hand side-bar. -Kj cheetham (talk) 20:57, 22 September 2022 (UTC) P.S. I don't like how it takes two clicks to get to pages like Contributions or my own Talk page though. -Kj cheetham (talk) 20:59, 22 September 2022 (UTC) P.P.S. Just noticed there even seems to be extra whitespace at the very bottom of the pages for some reason too! I also think the visuals of the tabs are worse than the previous Vector. This skin has potential, but it needs more work.[reply]
16. Sure, I use monobook anyway so I don't really care about the aesthetics personally. As a matter of web design, I think it implements a number of improvements such as a sticky TOC that will help readers navigate and a more minimalist design that modern readers will be more familiar with. If the devs think it's ready to deploy, then go for it, but I'll probably still use monobook myself. — Wug·a·po·des​ 20:57, 22 September 2022 (UTC)[reply]
17. Strong support the improvements made through Vector 2020, while not yet perfect, are definitely a step in the right direction and are better than the status quo of Vector 2010. Although I was sceptical of Vector 2020 when it was first an option, I now have it as my skin on all wikis as I find it much easier to use and less cluttered. I do have the gadget that removes the narrowed viewing space, but for readers I definitely see the benefits of this. Dreamy Jazz ^{talk to me | my contributions} 21:53, 22 September 2022 (UTC)[reply]
18. As long as an easy way (a gadget is one) exists for disabling the width limitation, support per the arguments provided in the proposal. ~ ToBeFree (talk) 22:03, 22 September 2022 (UTC)[reply]
19. Strong support I mostly use Wikipedia on my laptop in large windows; but when I make the windows smaller, the always-visible sidebar makes it practically unusable. It's also hard to overstate just how much better the 2022 layout is, for example on the iPad (without Safari's forced desktop view); previously, each section needed to be expanded manually, and it behaved like a true mobile site; with the 2022 design it behaves far better. I initially didn't like the 2022 design on another early-deployment Wikipedia, but I've since turned it back on and it just looks cleaner. Also absolutely love the ToC sidebar; makes it far easier to navigate articles. Fantastic change. DFlhb (talk) 22:18, 22 September 2022 (UTC)[reply]

    To add context to what I said above, after using Vector 2022 full-time over the past few days: I absolutely hated Vector 2022 at first when I saw it on another country's Wikipedia, and switched it back to the old one, but after browsing Wikipedia some more I realized how indispensible the always-visible ToC was, and how much nicer it was to have consistent page widths, and I ended up opting-in even on en.WP. I suspect most people would get used just fine to the new design, like I did, and, like me, would come to absolutely hate the old skin if they tried switching back. I literally can't use Vector legacy anymore. DFlhb (talk) 00:00, 26 September 2022 (UTC)[reply]

20. Support. I think articles are a bit easier to read with this skin. Overall, it looks cleaner while still "feeling" like Wikipedia. As far as default display design changes go, this is pretty mild and hard to find fault with. Pyrrho the Skipper (talk) 22:23, 22 September 2022 (UTC)[reply]
21. Support I switched from Monobook to Vector 2022 a few months ago, and am quite satisfied with it. - Donald Albury 22:36, 22 September 2022 (UTC)[reply]
22. Strong support - like DFlhb, I mostly use Wikipedia on my laptop and my iPad; V22 is a much better expereince on both, particularly the latter. It truly feels like it was designed for a variety of devices, and the lack of unnecessary (and, frankly, ugly) gradients make it look much cleaner. I personally find the fixed width much easier to read - as long as the gadget to disable it is easily accessible (and as long as the toolbar split happens soon-ish), I think this is ready for wider deployment. Remagoxer ^(talk) 23:00, 22 September 2022 (UTC)[reply]
23. Support: It's fine if we have a couple bugs here and there. As a whole, the skin is better based on the survey results, if we count people that liked Vector 2010 better because of resistance to change and nostalgia as neutrals. WP:PERFECTION. Sungodtemple (talk) 23:33, 22 September 2022 (UTC)[reply]

    Seriously, you are going to present that as quantitative info? What's the standard for "resistance"? Where's the evidence of "nostalgia"? See the Oppose #3 discussion about manipulation of stats (conflating neutral with like to negate a plurality of don't like).

    The deployment page says:

    vast new audiences have begun using the Internet and Wikimedia projects. Research done with these audiences showed that the current default skin doesn't meet their needs.

    Well, as we say in Wikipedia, CITATION NEEDED. Which audiences? What research? I would specifically like to know how the claim of universality/global outreach is addressed. Mention is made of WP French or Portuguese moving forward happily with the new look. How exactly were the new audiences tallied? Number of countries? Countries weighted by population? Majority of languages that have their own WP? None of this is transparent, most is simply declared. I think the most relevant way to address "vast new audiences" would be to look at access device & platform, with a sharp eye toward realistic (not max advertised by local ISPs) bandwidth in sample countries around the world.

    I give more credence to Support votes who honestly say "I like it" and give an example of why than I do to votes that offer statistical tricks or unproven claims about who prefers what (e.g., "most" of the people participating are old hands). Martindo (talk) 10:41, 24 September 2022 (UTC)[reply]

    mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey#Resistance to change Sungodtemple (talk) 13:26, 25 September 2022 (UTC)[reply]

24. Very weak support: I understand that they're looking for a more unified visual experience across platforms and screens, though I wish the look were "unifying" more around the traditional desktop experience and less around the mobile experience. It's a little odd how the designers seem determined to tell those of us who want to view and edit Wikipedia in a landscape orientation rather than portrait that we're somehow using our monitors (or our eyes?) incorrectly. I'll like the new one much, much better once the tools can be put in the right sidebar and I have less blank space on my screen. -Bryan Rutherford (talk) 23:45, 22 September 2022 (UTC)[reply]
25. Support: I've been using Vector 2022 ever since something with the logo was changed several months ago. The TOC is really useful when navigating pages, and search is more prominent. The sticky header is useful as well. I also think that hiding the user menu declutters the page and only adds a negligible amount of time when navigating. I also actually like the reduced width (except perhaps when editing. This is okay as long as there is an opt out for editors) for readability after using the skin for a while and agree that it probably is best practice. There's also significant technical benefit with other features to potentially come with it. Icons significantly reduce space that's needed for links, are intuitive, and website users will be able to become familiar with them. Opposers currently mention a chart that has an invalid question--of course the old one should be easier to use when a user first views it, and it should not prevent the skin from being deployed. That said, I think the link color change is OK and doesn't detract from site usability much, but I'm not sure how much readers might care it's because accessiblity. Given concerns down below, I think that this site should have a way to enable the wide vector gadget by default with it: including width limitations with the skin proposal makes getting consensus for it much too hard. It's already hard enough to get a design change through because there will usually be a negative response at first. I'll probably comment again after more people give their thoughts. —Danre98^{(talk^contribs)} 00:50, 23 September 2022 (UTC)[reply]
26. Support may or may not use it myself as an editor but as a reader, the sticky header and sidebar TOC are substantial improvements. Net positive change. – Teratix ₵ 01:43, 23 September 2022 (UTC)[reply]
27. Support. The new table of contents is excellent. Also per Ganesha811. Also... I hated the new design when I first saw it years ago. Since then, I've grown to like it quite a bit. The fundamentals of the design haven't changed, which means only one thing... good ol' change aversion. I suggest editors in the oppose section reconsider whether they're assessing the design based on accepted design principles. Which, by the way, have nothing to do with "mainstream/modern/recent web design". People have known limited text width increases readability for ages: a very old trick for increasing your reading speed is by practicing on newspaper columns. There's a reason every website with an ounce of design thinking has fixed-width text - the eye wasn't meant to jump, like, one foot after reading each line. Enterprisey (talk!) 03:01, 23 September 2022 (UTC)[reply]
28. Support. Having a max width is a good thing, in my view. I agree with some of the concerns that there is too much white space in some places. See screenshot for one thing that stuck out to me. Overall, I support.

    

    Adumbrativus (talk) 04:38, 23 September 2022 (UTC)[reply]
29.  Support, works a lot better for me than 2010 Vector on my tablet. — Qwerfjkltalk 06:13, 23 September 2022 (UTC)[reply]
30. Support - Believe it is better for readers. Using it as an editor has been an alright experience so far, so I see no issues worth opposing for. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 06:21, 23 September 2022 (UTC)[reply]
31. Support A strong improvement in reader experience (I already used it in Vietnamese Wikipedia) Thingofme (talk) 08:41, 23 September 2022 (UTC)[reply]
32. Support. Love the new TOC. I also want to figure out how to enable pinned tools.. 0xDeadbeef 09:21, 23 September 2022 (UTC)[reply]

    Hey @0xDeadbeef — thanks for joining the discussion. We've just started working on moving the article tools and making them pinnable. It will be available soon. If you'd like to follow along here's the task: https://phabricator.wikimedia.org/T302073. Cheers, AHollender (WMF) (talk) 15:25, 23 September 2022 (UTC)[reply]

33. Support. Don't mind the new look... Just as long as I get my wide width for my wide screen. – robertsky (talk) 09:41, 23 September 2022 (UTC)[reply]
34. Support Been using it for months and feels almost like its never been any different. Paint that nuclear power plant so we can get back to infighting about the color of the bikeshed please. —TheDJ (talk • contribs) 10:12, 23 September 2022 (UTC)[reply]
35. Support Iff support for the other skins isn't going away. I think it's ugly, and i have no intention of using it myself, but if the statistics and reviews show that it's "better" for today's new users, why not? Happy days ~ Lindsay^Hello 11:22, 23 September 2022 (UTC) Have to move from my first response; amusingly, i agree with the statement immediately below ~ the enhancements cannot be understated: I've been using it on and off for a while (before and after this RfC), and i seriously think that they are not enhancements, and we can do ~ and already do ~ far better as a default or introduction to our site. Happy days ~ Lindsay^Hello 11:38, 25 September 2022 (UTC)[reply]
36. Strong Support The enhancements to readability cannot be understated. I think a period of adjustment is inevitable but the end result is worthwhile. Much better for navigability as well. Clarysandy (talk) 12:41, 23 September 2022 (UTC)[reply]
37. Support I was initially a little apprehensive of the new skin but after testing it out for myself, I find aspects such as the TOC sidebar and sticky header significantly improve navigation and usability. I also think an increase to font size would further improve readability and address concerns about whitespace. Alduin2000 (talk) 12:53, 23 September 2022 (UTC)[reply]
38. I support implementing the improved UI, after mucking about with it for the better part of a day. None of my typical activities are diminished in any way, and some were improved. Do it to it. — Fourthords | =Λ= | 13:26, 23 September 2022 (UTC)[reply]
39. Strong support I've closely followed improvements of the skin and there's no aspect of it that I don't love. There are still a few rough corners and it might have been better if this RfC came later, but the overall direction is good and has my strong support. I don't understand complaints about "wasted space" (doesn't cost a thing, helps your eyes!), and I'm sure that in the future that space could be filled in with infoboxes and images, preventing current clashes and squeezes. Ponor (talk) 14:09, 23 September 2022 (UTC)[reply]

    Pardon the cliche, but everything has its limits. Excessive white space typically means more scrolling, which tires eyes, hand(s), and brain. (See Oppose 62.)

    I don't think esthetics are changing in favor of more white space. If anything, the trend is in the other direction: more clutter to "capitalize" on "real estate". So, the addition of white space may indeed be a relief to older users like myself, but then we're dissed as "nostalgic" or "resistant" -- you can't have it both ways. The younger generation(s) raised to be comfortable browsing on cell phones don't value it as much. If there's a study that specifically contrasts device type in regard to the appeal of white space, let's see a link for it.

    Although I Oppose a new default, I agree that worldwide increase in cell phone browsing should be addressed as a key usability issue. However, the huge rise in such browsing in the global south needs to be coupled with serious consideration of bandwidth available to such users. Otherwise, re-design simply continues to favor developed countries. Martindo (talk) 00:53, 25 September 2022 (UTC)[reply]

40. Support: I was pleasantly surprised when Vector 2022 was introduced as an opt-in, and I already view it as vastly superior to the 2010 Vector, even in its current—still somewhat flawed–state. I've been using it for over a year now, and my contributions have exponentially increased during that time—a testament to the new skin's utility. I particularly enjoy the decreased page width as it allows for a much more comfortable reading experience. Simplification of buttons and sidebars and the removal of outdated design elements like blue vector gradients contribute to a more unified, organized, and contemporary look. I'm frankly baffled to see how strongly editors are defending the old Vector's grotesquely large page width; "Humans are resistant to change" rings true, doesn't it? The same flock of vocal conservative editors are the reason why the main page will remain unchanged for the next 30 years and why this proposal will probably end up being rejected. Wikipedia is finally approaching basic aestheticism, something that's been long overdue. Throast ^{{{ping}} me!} (talk | contribs) 14:28, 23 September 2022 (UTC)[reply]
41. Strongly support (logged out) // oppose (logged in; possibly out-of-date feedback) -- As a logged out user, I love this change. Nav gets out of the way (I can see content right from the top), but I can also jump immediately to whatever section is relevant, and the fixed width makes the reading experience easier + more consistent. As a logged in user (today's the first time in months), the Main Page / Contribute / Tools sidebar entries hide the Nav ToC, and that is a strict regression from the current setup. In order to see the article sections, or to jump to a specific section, I have to scroll down the page to access the nav. EDIT: It looks like my opposition will be addressed by "[EPIC] Article Tools". mhlinder (talk) 14:33, 23 September 2022 (UTC)[reply]
42. Neutral/Cautious support - there are still problems with responsive design on mobile. Despite this, I think that the new skin is a significant improvement on not-at-all-responsive Vector 2010. When proper responsive design is added to Vector, it will render the mobile front-end entirely obsolete. Aasim - Herrscher of Wikis ❄️ 14:41, 23 September 2022 (UTC)[reply]
43. Support, but I hope that methods for opting-out or changing the skin are displayed prominently for users the first time they see the new interface. Not everyone likes change, and if there is a technical way to display the simple instructions in the FAQ here once this is rolled out, I expect it would reduce any stress or friction resulting from this deployment.~TPW 14:44, 23 September 2022 (UTC)[reply]
44. Strongly Support I have been using Vector 2022 for a few days and it is vastly superior to the old Vector. The TOC on the sidebar is a game changer and brings in line the desktop experience with the mobile experience. The white space is also a great feature, brings much needed breathing room for the content and makes reading wikipedia articles much easier and feel less like a chore. It would be helpful to have a more traditional hamburger menu that includes the table of contents like the mobile app. There's no easy way to hide the TOC in the middle of an article and access it easily again. I also wonder how necessary the main wikipedia menu really will be after the page tools are added on the right. The TOC & remaining main wikipedia navigation links could live in the same hamburger menu. While I understand the desire to solicit feedback on the design, I will be very disappointed and frustrated if the WMF takes the feedback of a few loud and disgruntled editors as reason to not go forward with this implementation. The vast majority of readers will be positively impacted by these changes, and most of them will not be seeking out an RFC to comment on Ha2772a (talk) 17:09, 23 September 2022 (UTC)[reply]

    Some good suggestions here, even though I vote Oppose. I, for one, would like to see easy (not merely easiER) navigation between different language versions. Like others who speak English and foray into reading/editing the WP-En history of a country that generally uses a different language, I occasionally find references to their language's version of WP. In some cases, there is a direct link to the corresponding article in the other language, but in many cases I have to go back to Main Page, then select the other WP, then search a relevant term. Martindo (talk) 00:19, 25 September 2022 (UTC)[reply]

45. Support: I have been using it for a while now, and it's an improvement. I would, however, like to see easy-to-use options allowing the user to adjust the width. MichaelMaggs (talk) 17:37, 23 September 2022 (UTC)[reply]
46. Support I think it's an improvement. It's not perfect yet, but it's good enough to switch over, IMO. Nosferattus (talk) 19:24, 23 September 2022 (UTC)[reply]
47. Strong support: I hope to come back and provide proper reasoning, but I encourage the WMF to implement this even if the en.wiki community disapprove, a huge departure from my usual disdain for all things WMF. However, the en.wiki community have been so obstinately and consistently opposed to any non-trivial design improvements, be they the Main Page or the sidebar or whatever, that I am unhappy but not at all surprised to see the knee-jerk opposition to this longstanding project. It is natural that this happens because people don't like change, and our core community consists mostly of people who have been here for half of Wikipedia's history, as we have been steadily getting worse at new editor retention for many years. But spending 10 minutes looking at the skin and describing what differences feel strange at first is not a substitute for professional web design.
    Some criticisms like the TOC limit removal are completely valid, but these are just ways to improve Vector 2022; that WP:FAC would need redesigning if this were not fixed is not a reason to hold all readers back. I've been using Vector 2022 since I saw it was possible to and I wouldn't seek to deny that it takes getting used to and can be improved, but it is quite simply less embarrassing than the 2000s-era skin we use currently. — Bilorv (talk) 22:33, 23 September 2022 (UTC)[reply]
48. Strong support: The skin isn't perfect. But it is a massive upgrade from Legacy Vector. I've seen lots of concerns about the width, but after a few months on Vector 2022, it's actually not that big of a difference. This skin and its ease of use will make it easier for readers to become editors, especially after the reorganization of the menus and page tools. All of the other changes just make sense. ~BappleBusiness^[talk] 01:16, 24 September 2022 (UTC)[reply]
49. Support - I installed the skin a few weeks ago to try it out, and once the novelty shock wore off, I liked it. I did tweak the width to shrink the right-side spacing a bit, but actually ended up changing it less than I thought I would - leaving it mostly there, along with the other changes, makes things more readable in general even if it doesn't maximize use of my screen width. I'm in favor overall. --PresN 02:20, 24 September 2022 (UTC)[reply]
50. Support - tbh still looks like it's 5 years out-of-date to me, but it's better than the 15 year out-of-date design we currently have. I will still use the legacy one because that's what I'm used to, but I understand that the new one implements basics of web design (frankly, basics of web design from five+ years ago). My colleagues who think that white space or fixed width reading lines are bad should be, well, ignored. Web design isn't something to be decided by a vote. Levivich (talk) 02:51, 24 September 2022 (UTC)[reply]

    Gee, I thought web design was rooted in usability feedback. Isn't that what Jakob Nielsen pioneered? Martindo (talk) 00:22, 25 September 2022 (UTC)[reply]

    Nope, and nope. You're confusing "usability feedback" with "usability". We learn about web design in the same way we learn about other things: with controlled double-blind studies. Levivich (talk) 14:54, 25 September 2022 (UTC)[reply]

51. Support – Like many of the other editors writing here, I thought the new skin was horrible at first due to the reduced line width and empty space. After just a few days using it, I totally reversed my opinion, and came to love that design choice because it's simply a huge improvement for readability (along with the sticky ToC, which I also like). Wikipedia's current visual style is dated, ugly, and frankly just embarassing for a website of its prominence, and stretching lines of text across the entire screen is a major contributor to this. I am dismayed to see opposition from editors who seem to have only glanced at the screenshots and rejected the skin outright without giving it a chance. For the sake of our readers now and in the future, I hope we won't be stuck with the status quo for another 20 years. — Goszei (talk) 05:41, 24 September 2022 (UTC)[reply]
52. Strong Support — Since it's been like 12 years since we actually had really any update with considering Vector, I believe we should move on to a better version of Wikipedia now. We all do deserve a change sometime and I think this is a perfect opportunity since the team has worked on this for about 3 years, I don't see why should this be opposed.  Rejoy2003  06:04, 24 September 2022 (UTC)[reply]
53. Support After a week or so of use I've found the sticky header and the index in the sidebar reduce scrolling. I'm taking advantage of foreign-language wikipedias more frequently.--AntientNestor (talk) 07:23, 24 September 2022 (UTC)[reply]
54. Weak support - The current default skin has already been in use for a long time and not really changed. I would like to see some change, but not necessarily this skin. ¹⁴¹Pr 08:27, 24 September 2022 (UTC)[reply]
55. Support - Though I'm not immediately a fan of the limited width or empty white space (it's difficult to tell where the article ends and empty space begins, and is awkward that when scrolled down beyond the sidebar content the article content is off-centred in whitespace), I support modernizing the UI in line with broader web trends. Even though many of us are used to the existing UI, WP is for readers, and readers on the web expect (and deserve) a different (modernized, improved) experience than they had 12+ years ago. -M.nelson (talk) 12:00, 24 September 2022 (UTC)[reply]
56. Support Moving from oppose to support. I think the new skin is better for reading and maintaining focus. — hako9 (talk) 13:56, 24 September 2022 (UTC)[reply]
57. Strong support: I didn't like this skin last year but the concerns I noted to the development team have since been addressed. (Concerns included the positioning of coordinates and overlapping text when using a big font.) Reasons I now like it: I recently got some progressive glasses and a wide body of text is no longer practical to view on the Internet (or even sometimes in a book). This is because the portion of the lens for intermediate distances is confined to a small area in the centre of the lens, and material on the perimeter is distorted, meaning with this type of glasses the entire head has to be moved to read material on the perimeter of a wide page. Not a comfortable way to read text! Also on a wide page it's difficult to find the correct line when moving from one line to the next. So TLDR, for me the limited width of the text is a feature, not a bug. Adapting to the new locations of my favorite features (Twinkle, the clock, the table of contents) has gone quite quickly. So, I now think the new Vector is the way to go. — Diannaa (talk) 14:37, 24 September 2022 (UTC)[reply]
58. Support - I have been using this skin for some months. It is based on sound graphic design principles. William Avery (talk) 14:44, 24 September 2022 (UTC)[reply]
59. Support Is it fantastic? No. I’m not a fan of the line width changes, and the design overall isn’t great. But, I suspect a large portion of my dislike is simply resistance to change, and I’ll get used to it. Looking at it rationally, it’s fine. I can always opt out if I dislike it. Although, to me, it’s not easier to read, it does seem to be based on actual evidence, and will probably be better for the majority of people. ThePlatypusofDoom (talk)
60. Support - I really love the redesign, especially the new ToC and the floating top-bar, and I'm excited for the coming Article tools on the right sidebar. I do think it needs some more polishing, but the way that happens is by really taking it to wide deployment; and most of the friction is just temporary. The one thing I'd like to see from one of the prototypes is the classic grey for all the non-article areas of the screeen. including both sidebars, as in Option nine from this prototype https://di-visual-design-borders-bgs.web.app/Zebra, which seems to reduce air strain on very wide monitors by using a gentler background that focuses attention on the article. Azertygod (talk) 15:48, 24 September 2022 (UTC)[reply]
61. Support I was leaning to oppose but given how it looks like after I switched to Vector 2022, I feel I like it. It however needs some improvements that several editors have pointed to above. Nothing is perfect, not even at the peak of its success. ─ The Aafī (talk)
62. Weak support The old Vector is definitely too wide, which makes it uncomfortable to read. I use the new Vector myself, though I'm not sure if it's for everyone. — W.andrea (talk) 21:51, 24 September 2022 (UTC)[reply]
63. Support Current vector has far too much text and is hard to read for a long time (and I have good eyesight). It desperately needs updating. I currently use Timeless which makes the text a bit bigger and limits the width, and it really makes viewing Wikipedia much prettier and nicer - I think Timeless does a lot better job because it greys out the extra space and makes it symmetrical unlike in Vector 2022. I think improving symmetry would definitely be nice for the new skin. Galobtter (pingó mió) 23:25, 24 September 2022 (UTC)[reply]
64. Support. While not perfect, I've come around to the changes proposed here – let's not let perfect be the enemy of good. The narrower width makes it easier to follow long passages of text, and the floating sidebar and header are useful ideas. Clear WMF support to fix bugs after deployment will be essential, however. RunningTiger123 (talk) 23:50, 24 September 2022 (UTC)[reply]
65. Support. Net improvement for our general audience. Keep the improvements coming. czar 23:54, 24 September 2022 (UTC)[reply]
66. Support, per others. It's long overdue. CactiStaccingCrane (talk) 02:27, 25 September 2022 (UTC)[reply]
67. Support. While I found the line width extremely jarring when I first switched over about a year ago, I now can't go without it. Other changes such as the buttons and the top right and the floating top bar would also be helpful for our readership. Yeeno (talk) 04:06, 25 September 2022 (UTC)[reply]
68. Support, there are problems, I have reported a few (incompatibility with WWT being one), but I support this in the interest of progress. Shyamal (talk) 07:04, 25 September 2022 (UTC)[reply]
69. I've been using it for some time, and think it's generally an improvement. Those who don't like the fixed width can switch back to the old skin. I'd like a toggle for that, though, as well as a persistent search field. Sandstein 07:16, 25 September 2022 (UTC)[reply]
70. Support It is obviously an improvement over the old vector. Massive improvement. Ladsgroup^overleg 10:56, 25 September 2022 (UTC)[reply]
71. Support. I turned it on earlier to try the editing experience, given the concerns listed below, and within an hour it felt comfortable and natural. Personally I will probably continue to use Legacy Vector, since that's what I've always used, but it's easy to see how a new user starting on Vector 2022 would stick with it (much like I did with Legacy Vector). Having said that, I'm uneasy about setting this as the default skin for all logged in accounts – I'd prefer enabling it as the default for logged-out users and new users, and for the already existing accounts have something like a CentralNotice banner linking to a way to switch to it. Giraffer ^{(talk·contribs)} 11:59, 25 September 2022 (UTC)[reply]
72. Support. While I have concerns with the new layout (primarily, I dislike 'information minimalism' when it comes to menus, and the changes to the header menu lean close to so minimalist they don't deliver the information they're designed to deliver), I generally prefer it over the existing template, I am glad to read that it may make dark mode simpler to implement, and the sticky menu and sticky table of contents on the sidebar are brilliantly useful. I also have concern that the present slightly dark underline is not enough to make it clear which tab is presently focused, but overall find the new tab design much more attractive. The prominent language-change button is also much more user friendly. JTdale 🗩 14:19, 25 September 2022 (UTC)[reply]
73. Support, echoing in particular TheDJ. This is largely a coat of paint; we'll get past its growing pains (already mentioned elsewhere) in exchange for a slightly more modern design. Let's do this again next decade, too. :) {{Nihiltres |talk |edits}} 16:05, 25 September 2022 (UTC)[reply]
74. Support I did not like the width at first...at all..., but when I returned to Vector 2010 after using 2022 for a couple days, I immediately noticed how much harder I had to work my eyes to keep up with the wide text. I think my kneejerk reaction was just resistance to change. I implore people who oppose to give Vector 2022 a little time before coming to any conclusions. TarkusAB^talk/contrib 17:38, 25 September 2022 (UTC)[reply]
75. Support This is obviously an improvement for readers, even if I may not like it for editing. Put the readers first, not the editors. HouseBlaster^talk 17:52, 25 September 2022 (UTC)[reply]
76. Support. Even though this is now a numbered list, I hope this RFC will not turn into mere vote counting (did we make sure eveysone's voice is heard... logged-off users?). People tend to be against new things, and those who are against tend to make effort having their voice heard. I hope that those who oppose the reduced text width will be satisfied with an additional setting. There are a lot of websites mentioned that have limited content width, I would add stackexchange (no ads!). My Full Support for Vector 2022+. It's design at its greatest and a breath of fresh air. PhilipPirrip (talk) 17:54, 25 September 2022 (UTC)[reply]

    I agree. Most users of Wikipedia are readers—most readers never comment on talk pages, let alone RfCs—most (but not all) changes to Vector 2022 are intended to make the experience better for readers—everyone commenting here is an editor, not a reader. This disconnect *is* a big problem for this RfC and I'm not sure how it can best be addressed. Editors have a lot of power here, naturally—they're the ones who show up to discussions like this. It would be unfair to implement this change unilaterally against the wishes of a clear majority of editors, if it shakes out that way, but it would also be unfair to ignore that editors are a tiny minority of those who use the site. —Ganesha811 (talk) 04:22, 26 September 2022 (UTC)[reply]

77. Support. As a reader of wikipedia on a large display, I often have to make my window smaller because the content is too wide to naturally read otherwise. Limiting the width is a massive improvement, and the other changes are nice too. The only negative I notice is that the 'hide' button on the TOC causes it to move to a position that is unintuitive to me, I would expect it to collapse in place but instead it moves next to the article title with a button I would likely never click if I didn't know what it did. 70.28.60.254 (talk) 19:07, 25 September 2022 (UTC)[reply]

    I agree about the TOC hiding being weird. When I tried it, I expected it would collapse to a single line with a "show" link, and I could just toggle back and forth between the two in-place. Instead, it just went away. Out of the corner of my eye, I could see that something had happened somewhere else on the page. After a few attempts, I finally figured out that it morphed into the dotted hamburger menu, but it's still unintuitive and surprising. -- RoySmith (talk) 21:29, 25 September 2022 (UTC)[reply]

78. Support. Nostalgia for the current design aside, this will be a better experience for readers. thegreenstripe (talk) 20:14, 25 September 2022 (UTC)[reply]
79. Support. Most features except the maximum width seem broadly acceptable. For the maximum width, I believe that it improves readability and it's worth attempting to standardize the experience across users who may have very different screen widths. 🌊PacificDepths^talk|contrib 08:51, 26 September 2022 (UTC)[reply]
80. Support. I've been using the new skin for a few months now and it's definitely an improvement. Oppose arguments based on takes like "white space is wasted space" should be given very little weight, since the WMF has already rebutted them with the empirical research and design expertise linked above. Really, I question the wisdom of putting questions like this to a bunch of amateur encyclopaedia-writers all together, but here we are... – Joe (talk) 09:56, 26 September 2022 (UTC)[reply]
81. Support: I have been using Vector 2022 for a while now and I like how it looks. It provides a more modern look for Wikipedia. I found that I can scroll less thanks to the sticky bar and the table of contents on the side. However, I understand other people's concerns, mainly about page width and whitespace. I personally find the page easier to read with the smaller page width, but to address these concerns, I would appreciate a width setting, similar to the one on Fandom. Finding ways to fill the whitespace (like putting page tools on the right, similar to the Timeless skin) would also be appreciated. Otherwise, I think it's time to roll it out. Good job to the creators! Aditoo17 [💬|✒] 10:32, 26 September 2022 (UTC)[reply]
82. Support. Deploy it already. Whoever doesn't like it can disable it. It's an improvement. Also, I'm tired of people asking me why does the English Wikipedia looks old-fashioned than Hebrew and French. Honestly, this actually happens every few days. --Amir E. Aharoni (talk) 14:29, 26 September 2022 (UTC)[reply]
83. Support Net positive for the general reader. Editors always have the choice of going back to classic vector if they don't like it. The skin is responsive which makes it usable on mobile, a big win over Vector-2010. Sticky TOC is another improvement. Being deployed as default on English Wikipedia would hopefully mean improvements such as native support for configurable page width and dark mode would be considered in the future. – SD0001 (talk) 14:48, 26 September 2022 (UTC)[reply]
84. Support: Been in the industry for more than 22 years. Spent several years at Google during the early 2010s and helped usher in Material Design. Excellent product improvements here. Highly recommend implementing them. We need to move forward with UX improvements on Wikipedia. — Preceding unsigned comment added by 73.100.215.54 (talk) 09:44, September 26, 2022 (UTC)
85. Support - I agree with others that this is overall a much-needed improvement and refresh of the current default setting. I sympathize with people who dislike the screen width limitations, but I find it much easier as a reader and as an editor have not encountered any issues. ThadeusOfNazereth(he/they)^{Talk to Me!} 17:41, 26 September 2022 (UTC)[reply]
86. Support The data from the key results make it clear that overall right now that the new skin is an improvement, both for readers and the editors who have tried it and mostly stuck to using it. The fact that the team at the WMF has been responsive to feedback and diligently fixing bugs also gives me a lot of confidence that it will continue to improve over time. A lot of opposition seems to revolve around not personally preferring the increased whitespace/how width is handled, but since you can go back to the old look any time if you prefer that it's not very convincing argument for how millions of readers should experence Wikipedia. For readers, it's very uncontroversial and universally known that increased whitespace / less focus on the sidebar filled with tons of esoteric links will improve readability of the content, which you can see is true from things like the 50% increase in use of the TOS to navigate more quickly. In short, it's clearly better for readers, who are the primary audience of a default skin. Steven Walling • talk 17:45, 26 September 2022 (UTC)[reply]
87. Support I won't personally be using it, since I am used to and prefer the 2010 skin. But the focus of Wikipedia is on our readers. This new version is better for our readers. Wikipedia has a top notch design team that worked hard on making a modern interface. The internet changes, and so must we. CaptainEek ^{Edits Ho Cap'n!}⚓ 17:50, 26 September 2022 (UTC)[reply]

    I'll also add that today I discovered a website called Wikiwand, which explicitly sets out to make Wikipedia easier to read and use and claims a large userbase. To me, that is a big sign that our current interface is not working for readers. CaptainEek ^{Edits Ho Cap'n!}⚓ 00:17, 27 September 2022 (UTC)[reply]

88. Support Whitespace is not an issue for me because my zoom is set at 120%. I did test it out switching back forth with both my zoom and old vs. new and overall I find the 2022 version "cleaner". Having a drop-down to get to my talk page will take some getting used to and perhaps something the WMF should consider changing given, as editors, communication is a key component to what we do. However, the sticky headers and TOC are cool features. I did notice those features where not present in draft space though, which is another recommendation. S0091 (talk) 18:48, 26 September 2022 (UTC)[reply]
89. Support While I appreciate that editors in the oppose section don't personally like the fixed width, I'm yet to see any convincing argument that the new skin would be worse for readers or new editors, which is really what this RfC is about. Folks who like the current Vector skin can continue using it. Sam Walton (talk) 11:13, 27 September 2022 (UTC)[reply]
90. Strong support: I have been using the new design as well as following its development for a while, and I find it greatly improves Wikipedia and other projects. Very good work. It should definitely be the default. ~ nicolas (talk) 11:21, 27 September 2022 (UTC)[reply]
91. Strong support: The changes in this skin definitely improve overall user experience in my opinion. I also feel like it opens up a lot of possibilities for the future when it comes to adding/modifying features. Above all, this is making reading articles a pleasant experience and finding things you are looking for where they should be. Apart from visual design that can be polished and iterated, strongly support this proposal. Nirzardp (talk) 13:05, 27 September 2022 (UTC)[reply]
92. Support ɱ (talk) 15:36, 27 September 2022 (UTC)[reply]
93. Support: As a longtime reader, one of the main issues in reading long articles is that you can't use navigation box to quickly go between sections since the former would be so far above, hampering reading experiences and forcing editors to make accommodations by removing texts which might otherwise be pertinent for the article's narrative flow; in turn becoming perennial headaches and debates among editors while sucking away valuable time in the process. The movable navigational box therefore can finally tackle the issue and help Wikipedia to realize its maximum potential. However there is a caveat that an extra click is needed to go to random page or see my contributions. I would certainly like a dark mode feature to be added as well. 45.136.197.235 (talk) 15:58, 27 September 2022 (UTC)[reply]

    Technically there is a dark mode already however it simply inverts the colors on the pages. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:02, 27 September 2022 (UTC)[reply]

94. Support: Editors can opt-out of the new skin. Given the skin is widely adopted across other language projects, I think it's essential that we maintain cohesiveness in the Wikipedia experience across projects. I believe having this skin rolled out on English Wikipedia, will lead to lots of valuable feedback due to wider use, and will only get better. Jdlrobson (talk) 16:58, 27 September 2022 (UTC)[reply]

Oppose

No, the Vector 2022 skin cannot be deployed. (For editors opposing, if there are changes to the skin that you would like to see completed before a future RfC on the skin, the team responsible for creating the skin would appreciate you detailing them)

1. Oppose I can't get behind the fact that we're going to make a hard limit on the width of the screen for readers. Especially for image-heavy articles, this is going to cause a host of formatting issues when combined with moving the table of contents that will take substantial time to fix content-wise. If the skin change is going to create issues with the readability of existing readable text, then it is a net negative to our encyclopedia's readers. — Red-tailed hawk _(nest) 16:50, 22 September 2022 (UTC)[reply]
2. The width of the screen is a deal-breaker for me. I have opted out of Vector 2022 globally because of this. --Rschen7754 18:04, 22 September 2022 (UTC)[reply]

   I am also concerned that the screenshots at the top of the RFC do not adequately illustrate this problem, and this is not clearly disclosed in the RFC descriptions either. --Rschen7754 18:06, 22 September 2022 (UTC)[reply]

   @Rschen7754, could you elaborate if this is more about your personal preference (which is fine, that's why there's a gadget disabling the limited width for individual users) or anything broader? Note that it's been working on 30 different wikis, so I'd really like to figure out what issue related to the limited width you're most concerned about. SGrabarczuk (WMF) (talk) 18:17, 22 September 2022 (UTC)[reply]

   Look at pages like this - the limited ability to use the screen width means a lot more scrolling to use the table. Not to mention that for editors, the limited screen width is a significant handicap. --Rschen7754 18:25, 22 September 2022 (UTC)[reply]

   @Rschen7754, there are at least two different issues to unpack: wide tables that get narrowed down, and the editing experience. We need a bit of time to address the first issue. Regarding the second one, in the editing mode, the limited width is disabled - both in VisualEditor and the wikitext editor. That seems to be an effective solution. What do you think? SGrabarczuk (WMF) (talk) 18:50, 22 September 2022 (UTC)[reply]

   in the editing mode, the limited width is disabled - both in VisualEditor and the wikitext editor. That seems to be an effective solution At least in VisualEditor mode I would find this worse, since now the text I wanted to edit is in a different location. --Rschen7754 00:12, 23 September 2022 (UTC)[reply]

   @SGrabarczuk (WMF) is it disabled in VE, though? Editing that page, it seems to have identical width constraints as in read mode. (I haven't been paying attention to design discussions for this lately -- I know there was a back-and-forth about the accuracy of VE as a preview being affected by an inconsistency there...) DLynch (WMF) (talk) 19:07, 26 September 2022 (UTC)[reply]

   That article looks better with the new skin; in the old skin, the massive table rather resembles an Excel spreadsheet instead of an encyclopedia article. Enterprisey (talk!) 04:14, 23 September 2022 (UTC)[reply]

   @SGrabarczuk (WMF): in the live version, the right-side whitespace gutter is about the same size as the left side gutter on my screen, but in the screen shot File:Screenshot of English Wikipedia Pluto article in Vector 2022 skin.png the right-side gutter appears to be cropped to about half of that width. — xaosflux ^Talk 18:38, 22 September 2022 (UTC)[reply]

   Compare to File:Pluto full screen vector 2022 2022-09-22.png. — xaosflux ^Talk 18:41, 22 September 2022 (UTC)[reply]

   @Xaosflux - thanks for flagging this. We didn't crop the images - this is just due to the size of my window when I was taking the screenshot - should roughly correspond to the width of the right and left sidebars at 1400px (most 13 inch screens). We can potentially add some additional images for screens of different sizes or highlight/bold the "try it out" link to encourage people clicking on that. OVasileva (WMF) (talk) 19:07, 22 September 2022 (UTC)[reply]

   For reference, this is how the Pluto article looks for me, it has a width of 4K.

   

   _→AzaToth 20:53, 22 September 2022 (UTC)[reply]

   @Xaosflux I believe the screenshots are at two different screen widths. Does this image help to clarify?

   

   Also, as a reminder, we've just begun work on the article tools (phab task). Once this is done, in a month or so, you will be able to pin article tools (and other gadgets) to the right-side of the article. You can view the prototype of that here: https://vector-2022.web.app/Moth.

   

   AHollender (WMF) (talk) 19:21, 22 September 2022 (UTC)[reply]

   Out of curiosity, how does it look with the article tools pinned on a 1453 px-wide screen? — Red-tailed hawk _(nest) 19:45, 22 September 2022 (UTC)[reply]

   Yes, thank you for the updates. — xaosflux ^Talk 20:08, 22 September 2022 (UTC)[reply]

   @Red-tailed hawk, both the table of contents and the article tools menu can be "pinned" or hidden, so there are a few different options for how can look. However here's the direct comparison of what I shared above:

   

   You can of course play around with the prototype yourself to get a more concrete understanding. Our hope is that by making the menus configurable, and also providing configurability for the width of the text via gadgets, each person will be able to configure the layout to what works best for them. AHollender (WMF) (talk) 20:27, 22 September 2022 (UTC)[reply]

   @SGrabarczuk (WMF):, sorry to join this thread - happy for it to move to discussion. I gave new vector another go on en-wiki and tried different variations of the gadgets/scripts in the repository (the wide-2022 gadget, and Quiddity's, and both), but none of them were widening it out to the full width (assuming I still want the sidebar, which of course I do). This rather stresses my point in discussion. We need full width control, ability to have TOC in the sidebar, on the page, or in both.

   With regard to new editors (really the nexus of this RfC), Vector2022 causes major problems for articles with wide tables, and articles with pictures on both sides. I've not seen any solution to the first in place yet and any solution to the latter looks like it will take a huge amount of community time. Nosebagbear (talk) 20:39, 22 September 2022 (UTC)[reply]

   

   Even in the demo article I wind up with this, which is a horrible waste of space. --Rschen7754 01:22, 23 September 2022 (UTC)[reply]

   This should be a good motivation for editors to stop assuming they can put stuff next to eachother and that it will look the same in all screen resolutions:) —TheDJ (talk • contribs) 08:47, 23 September 2022 (UTC)[reply]

   Yes, this is a problem with editors, not the skin -- Guerillero ^{Parlez Moi} 10:05, 23 September 2022 (UTC)[reply]

   Even accepting this argument at face value (which I strongly disagree with): Pluto is a FA. How many more instances of this are there on the English Wikipedia? At a minimum, we would need to go around and change all these, or otherwise we have a bunch of articles looking like this. --Rschen7754 18:07, 23 September 2022 (UTC)[reply]

   They already look like this to a large set of users, they don't look like this to YOU. Here is the exact same screenshot in Vector: https://phabricator.wikimedia.org/F35536100 There just isn't a problem here. —TheDJ (talk • contribs) 09:40, 27 September 2022 (UTC)[reply]

   Yes, some articles look like a scrapbook with too many diagrams, tables and pictures next to each other. There should be an option to put (at least some of) these *into* the right margin (→Marginalia of tufte or classicthesis LaTeX styles). Ponor (talk) 14:22, 23 September 2022 (UTC)[reply]

3. Oppose. First, the most important thing to consider is the experience of the reader, and per a survey conducted by the WMF they find new format skin harder to use than the current skin as can be seen on the graph below. This means that we should reject the change at least until there is an easy way for non-logged in readers to revert back semi-permanently to the current skin.
   The chosen width of the page is another issue; it is important to consider how the width affects the perception of Wikipedia, as we want to be perceived as a broadsheet, not as a tabloid, and this width change is unlikely to have a positive impact on this perception. It has also resulted in a unsightly gap between the left hand navigation bar and the content, while reducing the space available for content that need to utilize large amounts of space on the page, such as larger tables, charts, and panoramas.
   Elsewhere on the page, the position of coordinates and icons have been usurped. While it is possible that this decision is an improvement, these content decisions should not be made without closer discussion with enwiki, and we should not approve the implementation of this skin until we are satisfied with the new location for coordinates, or until the decision to usurp their position is reversed.
   Other issues also exist. For example, there has been no investigation of what highly used scripts will be broken, and the testing of the various features has been insufficient at times, with features such as the sticky header only being tested in such a way to see whether they are in use, rather than whether they improve the user experience. BilledMammal (talk) 19:12, 22 September 2022 (UTC)[reply]

   @BilledMammal Can you share the source for this data? Sam Walton (talk) 19:40, 22 September 2022 (UTC)[reply]

   Reading/Web/Desktop Improvements/Repository/Sentiment Survey. The figures are presented in a different light there, with the WMF saying that The majority of respondents reported that the new experience is easier to use or that the new and old experience are equally easy to use. This is technically true but misleading as can be seen when looking at the raw figures. BilledMammal (talk) 19:43, 22 September 2022 (UTC)[reply]

   Jumping in here: For the exact quotes, see 60 responses reported the old experience as easier to use, while 49 respondents reported that they find both skins equally easy to use and 37 respondents reported that they find the new skin easier to use. WMF spin aside, this seems like a pretty damning report regarding the usability of the new skin. — Red-tailed hawk _(nest) 19:49, 22 September 2022 (UTC)[reply]

   It does say later on that most of the respondents that said the old skin is easier to use also mentioned it is because of nostalgia / resistance to change. Sungodtemple (talk) 23:30, 22 September 2022 (UTC)[reply]

   @BilledMammal, thank you for bringing this up.

   1. I'd like to share some context on these survey results. The survey we ran does not study usability itself, but rather the perception of the skin during the very first encounter with it. That is, what people think when they first see it. Prior to filling out the survey, readers were only able to see the skin on a single page. This data was collected before they were able to use the skin, for example, jump between different pages and feel the difference. We cannot make the conclusion that readers find the skin harder to use based on this data. However, we would like to point out that, upon deployment, we will receive different types of feedback from both logged-in and logged-out users immediately after deployment. As is common with most changes in design, some of this feedback will be negative. By then, we will have fixed many issues, but there will always be some portion of negative feedback along the lines of WP:IDONTLIKEIT. For transparency, we've shared these survey results to create the correct expectations for what will happen in the few hours after deployment. These are not accurate predictors for long-term behavior and should not be framed as such.
   2. I would also like to gently push back against your example of the sticky header. The data shows that the sticky header decreases scrolling to the top of the page by 16%. This is behavior that is due to people using the sticky header, but is not just showing that people are using it - they could use it and still scroll just as much as before. In that case, we would not consider the feature a success.

   SGrabarczuk (WMF) (talk) 19:49, 22 September 2022 (UTC)[reply]

   Re point 2: that's actually confirmation of BilledMammal's point: if the benchmark for whether or not the feature is a success is whether or not it results in a decrease in scrolling, you are taking for granted that decrease in scrolling = improved experience. Now, that's obviously going to be the case pretty often, but it does depend on the methods used to achieve it, and how any downsides from that weigh up against the benefit of less scrolling. (To take it to a humorously-intended extreme to illustrate what I mean: if you build things so that, once readers have scrolled down, they quite literally cannot go back up, that's going to reduce scrolling to the top by quite a bit! But it's rather hard to argue it's going to improve the experience of most readers) AddWittyNameHere 01:40, 23 September 2022 (UTC)[reply]

   @SGrabarczuk (WMF), how many unfinished responses were there? If there were a significant number, how do the numbers change - e.g. for the "which skin is easier to use" question - when the unfinished responses are added in? Enterprisey (talk!) 03:55, 23 September 2022 (UTC)[reply]

4. Oppose until the developers can assure us that the fixed width/width limitation will be removed in the near future and is not deeply baked into the layout or otherwise unfixable. I accept that the new skin cannot be perfect but this violation of a fundamental usability principle does not inspire confidence so I have to know that this is a problem that can and will be addressed. ElKevbo (talk) 19:28, 22 September 2022 (UTC)[reply]

   @ElKevbo, why do you consider this a violation of a fundamental usability principle? What principle are you referring to? I'd be grateful if you could elaborate. SGrabarczuk (WMF) (talk) 19:39, 22 September 2022 (UTC)[reply]

   Not forcing unnecessary white space around the contents of a webpage and wasting available screen space is a pretty old and fundamental design principle for webpages. I'm sure that you can find a lot of information if you look for "fluid" designs and look into some of the history of HTML and CSS that emphasized this idea; for example, "Use a liquid layout" is one of the design guidelines explicitly enumerated by Jakob Nielsen all the way back in 2001. ElKevbo (talk) 20:14, 22 September 2022 (UTC)[reply]

   It's funny that you're referencing a recommendation for home pages, which is closer to Google or in the time of that advice, our main page.

   pretty old and fundamental design principle for webpages Content should be responsive in this day and age, which is probably close to what the concept of fluid became. However, research on readability clearly indicates somewhere in the realm of 80-150 columns is superior; this is why you see all of the blogging platforms with an enforced maximum width, and it's this kind of content which we are delivering to our readers. This is born out in WMF's own user research on the point; from the subpage:

   1. In prototype testing with editors, most editors appreciated the shorter line lengths and agreed that the feature created a more comfortable reading experience.
   2. A significant number of editors disliked the whitespace around the content and felt that it was wasted space.
   3. In user testing with readers, participants reported a strong preference to the limited content width, stating that it improved the reading experience.
   4. Previous research indicated that users read more accurately and more quickly at limited line widths.

   (My enumeration.) Note how items 1, 3, and 4 all point to a better experience for our readers. Izno (talk) 20:40, 22 September 2022 (UTC)[reply]

   @ElKevbo thanks for your concern. To note: the article you pointed out is from 2001, at which time the most common monitor size was 1024x768 (link). To put it simply: people had not started to study, or design for, how to handle text on large monitors because they were not in use. Today research on this point, line length for optimally readable text, is very clear. If you look around the internet at popular content websites — ProPublica, BBC, Snopes, AVClub, BBC, The Lancet, Reddit, The World Health Organization, Baidu, Medium, or any other that you would like to choose — you will find that they all have width limitations on their content. If you look at newspapers, books, and magazines, you will find the width of the text all falls within the same range. The approach is standardized for good reason. This is not something we are reinventing, or making a guess at. It is a clearly established best practice. Thanks, AHollender (WMF) (talk) 21:22, 22 September 2022 (UTC)[reply]

   I appreciate these responses. Without support from empirical testing - not just opinions - I am not willing to change my !vote. I appreciate that you may not want to look for and provide links to that research for one editor. I am simply extremely wary of changes or decisions made in web design at this scale that is not well supported by empirical research. ElKevbo (talk) 21:45, 22 September 2022 (UTC)[reply]

   @ElKevbo thankfully there is plenty of empirical research [EDIT: updated list with the help of editors]:

   • Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language -- "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
   • Effects of Surrounding Information and Line Length on Text Comprehension from the Web (2002), from Canadian Journal of Learning and Technology -- "Comprehension was affected by whitespace; participants had better comprehension for information surrounded by whitespace than for information surrounded by meaningless information", which is more likely to happen if the text stretches to the edge of the browser.
   • The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies -- "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
   • Shorter Lines Facilitate Reading in Those Who Struggle (2013), from PLOS_One -- "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
   • The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University -- "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
   • The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting -- "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
   • Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed -- "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."
   • https://baymard.com/blog/line-length-readability
   • https://laurenscharff.com/research/textmargin.html
   • https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf

   Please note: the range of line-lengths studied is somewhat narrow. Some of the research shows certain positive effects of longer line lengths, but those line lengths are significantly less than what results from the maximum width we have in place in Vector 2022. In other words, even with Vector 2022 we are well beyond the maximum recommended range of any of the studies. AHollender (WMF) (talk) 02:54, 23 September 2022 (UTC)[reply]

   I think there is confusion of means and goal here. The goal is usability/readability and the debate is actually focused on forcing vs choosing. I read Nielsen's book way back when and IIRC, a key principle he advocated was letting the user's device/browser modify the parameters of the display.

   IMO, those advocating a forced default are saying either (or both) of the following:

   1. users don't know what's good for them, look at all the research that supports shorter line width!

   2. users don't know how to adjust basic preferences to fit known generalizations about readability

   Quite a number of votes here, both Oppose and Support, address the issue of choosing, but I don't see the developers doing that. Mostly they seem to be defending the means because they assume (perhaps correctly) that a large fraction of worldwide users agree with the goal. Martindo (talk) 00:31, 25 September 2022 (UTC)[reply]

   @AHollender (WMF): thanks for the update, much appreciated. If it helps, the journal name of the fourth link down is PLOS One. Jr8825 • Talk 11:43, 27 September 2022 (UTC)[reply]

5. Oppose No-go for me because of the width of the screen. Privybst (talk) 19:35, 22 September 2022 (UTC)[reply]

   @Privybst, just to be sure we both understand the context. If it's a no-go for you, meaning, your personal experience, you can opt out and never see it again. We're fine with that, and we don't consider this as a major blocker preventing from enabling Vector 2022 for all the Vector legacy users. However, if you try to use it for a few moments and point out some specific issues, we will be able to address them. Perhaps there's something that could be improved. SGrabarczuk (WMF) (talk) 19:55, 22 September 2022 (UTC)[reply]

   No, I believe that the new skin has a very big issue with dead space, which makes navigation extremely difficult and inconvenient. Of course, I opted out globally, but instead, users who want to use this skin have to opt it in. The whole question is what will be the default, especially for unregistered users. Privybst (talk) 20:12, 22 September 2022 (UTC)[reply]

   I noticed dead space between the contents frame at left and the main body. I use a MacMini linked to a TV, so any forcing of display dimensions could be problematic for me. Martindo (talk) 03:56, 24 September 2022 (UTC)[reply]

6. No. (The new Vector is probably technically superior, but the change from the full width main text weakens the brand recognition.) Vecr (talk) 19:33, 22 September 2022 (UTC)[reply]

   "Brand recognition" feels like a weird argument here - are we anticipating that people will stop recognising Wikipedia and using it on that basis? Nosebagbear (talk) 19:52, 22 September 2022 (UTC)[reply]

   Sad that keeping things looking outdated helps us with brand recognition, but... Retswerb (talk) 03:55, 24 September 2022 (UTC)[reply]

7. Oppose I agree with several people above regarding the screen width, and if the survey results cited by BilledMammal are legit then that is another reason not to move forward with this. PCN02WPS (talk | contribs) 19:45, 22 September 2022 (UTC)[reply]
8. Rework As of right now, the skin has the major issue of dead space. Everything is too spaced out and it makes navigating hard, especially on 4:3 ratio screens. Until this problem is fixed, I highly advise to not roll out the skin. ElusiveTaker (talk) 19:49, 22 September 2022 (UTC)[reply]
9. Hell no!. I may be opposing on limited information, but having just compared the 2022 version alongside the 2010 version among other defects I found the weird, faint, purplish colour/font of some Wikilinks and "edit source" all but unreadable. I also fail to understand why the column width of the 2022 version is significantly narrower than that of 2010 - it looks for all the world like a bug, which I assume it isn't. By all means let us have Vector 2022 as an option, but this is not what we (or, at least, I) want new readers or editors to experience. Gog the Mild (talk) 19:54, 22 September 2022 (UTC)[reply]

   The wikilink adjustment actually increases accessibility against the surrounding text; WCAG specifically has a recommendation on it. (NB, I don't like it either, but I have not quite 20/20 vision and no color deficiencies. I assume you are the same.)

   I have responded above about the fixed width. Izno (talk) 20:50, 22 September 2022 (UTC)[reply]

   I don't really care what policies it ticks, you are proposing that the default version of Wikipedia be one which I assume many users will, like me - this is not hyperbole - find near unreadable and which you do not like yourself! (I assume that you will be voting oppose?) Why should we ram these defects down new users' throats?

   Privybst's response to your response on this comes close to my opinion.

   Are support voters going to be similarly badgered over their opinions. This comes across as a deliberate attempt to discourage potential oppose voters by making it clear that they will be asked to defend their opinions in, often technical, detail. I will AFG that this is inadvertent, but IMO it has already come close to invalidating the RfC and I hope that the eventual closer takes due note. Gog the Mild (talk) 21:29, 22 September 2022 (UTC)[reply]

   find near unreadable and which you do not like yourself! I have not proposed anything in matter of fact.

   Privybst's comment that I can see above was not in response to mine but left much earlier and in response to the primary question.

   Are support voters going to be similarly badgered over their opinions. I do not see badgering here. I do see several corrections of matters of fact and a marked restraint on commenting on matters of opinion for the majority of opposers so far (to wit, I did not attempt to invalidate that you hold an opinion you do). In fact, I made reference to my comment above because I did not want you to assume either a) that I had deliberately not responded to that comment, or b) that I was badgering; badgering would be me posting the exact same comment or having the exact same discussion with every separate user. This is a discussion. If you believe the supports have been inappropriately discussed with, you are more than free to have one in the context of their comment, but I doubt the whataboutism was anything other than rhetorical. --Izno (talk) 21:37, 22 September 2022 (UTC)[reply]

10. Oppose - The limited width is a no-no for me. _→AzaToth 20:15, 22 September 2022 (UTC)[reply]

    Hey @AzaToth, have you had a chance to look at any of the research regarding line-length and reading comfort and comprehension (link to start with)? Thankfully it has been well researched over the past several decades (starting with printed text, and more recently for electronic text). And the findings are quite clear. We think it's critical to offer the best reading experience, based on the research available, to the majority of our readers. People who don't want the optimal reading experience are free to make the text full-width. I'm curious if you have any thoughts once you've had a chance to look through the materials. Thanks, AHollender (WMF) (talk) 21:33, 22 September 2022 (UTC)[reply]

    I think we have opposing definition of "optimal reading experience"; I don't feel having to move my eyes back all the time increase the reading experience. And as I showed in File:Screenshot of English Wikipedia Pluto article in Vector 2022 skin - 4K.png, the screen estate usage on my monitor is laughable.

    I have a feeling you are bogged down in refusing to support an official way to have full width, pushing it down to people hacking it using gadgets, which gives a sour taste in my mouth.

    Unless you support a official way to enable full screen, I must stick with my oppose. _→AzaToth 22:01, 22 September 2022 (UTC)[reply]

    @AzaToth thanks for replying. Honestly, we are following the well established research regarding optimal line-length. I am not coming up with some definition on my own. Have you read the research yet?

    It looks like we will end up building an official toggle for full-width (see below). My initial opposition to that is nothing personal, it's just because it goes against the research. Again, reference books, magazines, other websites — I honestly believe it is a standard practice for a good reason. AHollender (WMF) (talk) 22:40, 22 September 2022 (UTC)[reply]

    @AHollender (WMF) - I did read the research (the formally cited one that's 17 years old, plus a bunch of others I found myself). I struggled to find any research that was a) genuinely analogous to Wikipedia (that is, no ads, a need for a tool sidebar, moderate page hangtime, images on both sides) and b) a decent statistical sample. I did find a 2013 study that had most of the above, but only with 24 participants. Could you point me to a modern or modernish piece of research with the above - I certainly imagine I didn't do an exhaustive literature review! Nosebagbear (talk) 15:30, 23 September 2022 (UTC)[reply]

    Hey @Nosebagbear, so part of what is difficult here is that as far as I have found nobody has studied the kinds of line-lengths many people in this discussion are advocating for. Most studies focus on the 55–100 character per line range. On Legacy Vector, if you are using a large monitor, you regularly get ~300 characters per line, with a minimum around ~225 (if text is next to an infobox or floated image). So, the way I've made sense of this is:

    • Most of the studies I've found, old and new, advocate for shorter line-lengths (and even when they advocate for longer ones, they're still talking about line lengths shorter than we currently have in Vector 2022)
    • I assume it's meaningful that the studies do not include lengths over ~100 characters per line, but of course I cannot be certain as to why that is
    • I'm triangulating based on other references (again, maybe flawed, but also somewhat hard to imagine that basically everyone else who does typography in print or on the internet has gotten this wrong). The intro to this study articulate this pretty well.

    Here is the literature review we assembled:

    https://drive.google.com/file/d/19gUtEzZvHE4Mgp02S1D-scPgdIwKpD3r/view?usp=sharing

    Ultimately I think what is needed is more research, specifically for Wikipedia articles, and including line lengths that result in 300+ characters per line. Until then, the conclusion I've come to is that we should err on the side of caution, and follow the established best practices. We can always make the text wider if we find that to be beneficial — we are certainly not opposed to that.

    What do you think? AHollender (WMF) (talk) 16:09, 23 September 2022 (UTC)[reply]

    @AHollender (WMF) - thank you for your quick and detailed response. In that review, it does write "The format of Wikipedia is similar to other web pages that use different fonts, font sizes, whitespace, etc...so the recommendations from this literature can still support", but your above on characters would seem to indicate that that paragraph is not so justified in that regard. Shaikh's work was also interesting in that it suggested it was mid-length that people didn't like, with both shorter and long-length being okay. I wonder whether that is more relevant here - short-length means that eyes can just look forwards and move down. Long-length means that much less downwards (and scrolling) is needed, with midlength just being worst of both worlds.

    .

    On a different note, I don't know whether it would have fallen into this particular lit review (as it's much more purely Wikipedia focused), but did the team consider how to handle the major community worktime issues that come from needing to redesign very large numbers of articles to match this layout better (most notably those with wide tables, now both looking odd and jutting well below) and articles with images on both sides (there are smaller scale ones, as well, such as where TOC was moved from the normal place on V10) Nosebagbear (talk) 16:31, 23 September 2022 (UTC)[reply]

    Hey @Nosebagbear, apologies for the delay. I think that the overall experience of reading a Wikipedia article is similar to the experience of reading other webpages such that the research is applicable. However there are some differences, which we can take into account. I wrote about that here: Why not to choose "the simplest" solution. Three things I've noticed in some of the comments on this page (not your comments), which are interesting to me:

    • People thinking that Wikipedia is vastly different from every other website such that we shouldn't even begin to consider the research, general typographic recommendations, or examples of other websites, because they bare absolutely no relevance
    • Nobody has offered up research indicating that 200, 300, or more characters per line is good for readability/usability. Nobody has provided a single example of other popular content websites (non-profit, government, or otherwise), that don't have maximum width limitations on their text. It's helpful to question the research that recommends shorter line lengths, but if there was a valid counterargument I think there would at least be some proof for that.
    • People thinking that by making some changes to the interface, we're enviably going to end up entirely corrupting the experience, and that we might as well be some evil tech company who mines user data and litters the site with ads

    I think there is a lot of nuance here. I agree that Wikipedia is very different in so many (great) ways from the rest of the internet. And at the same time, when it comes to text settings, it's not necessarily that different. We should probably increase the font-size a bit (this has been studied specifically using Wikipedia pages, and we had a great discussion about that following the prototype proposed here), and have a max-width as to avoid super long lines of text. I honestly think in this case it's not so complicated.

    Regarding "the major community worktime issues that come from needing to redesign very large numbers of articles to match this layout better". I doubt my answer will be satisfactory, but here is how I think about it. Firstly, for anyone using English Wikipedia on a laptop these issues are already present. It seems that many editors have large monitors. We don't have screen resolution data for Wikipedia specifically, but as far as we can tell from the data that is online (example), most people do not. So regardless of whether or not there is a width limitation on the content this is an issue we need to fix at a systematic, template level. Are we making the formatting issue (specifically for tables) worse for people with large monitors with Vector 2022? Yes, I don't think there is anyone trying to deny that. For a while I've thought that we should invest more in the formatting of articles (both in terms of templates/software, and in terms of cultivating a sort've designer/layout editor role within the community).

    What do you think? AHollender (WMF) (talk) 13:59, 27 September 2022 (UTC)[reply]

11. Oppose I have used vector 2022 for a while, I found many MANY bugs and issues with it, all that would easily be noticed by people that dont have a wikipedia account, which would cause people to dislike wikipedia more. PerryPerryD Talk To Me 20:18, 22 September 2022 (UTC)[reply]

    Please point to specific issues that you think should block deployment. Izno (talk) 20:24, 22 September 2022 (UTC)[reply]

    Sure, For 1, the most noticeable, is the fixed screen display, considering that most monitors run at different scales of 1440p, 1080p, fewer, or less (My own monitor runs at 1366x769), Almost every new user to Wikipedia will think "This looks squished and hard to read", When I used vector 2022, I had to ZOOM in onto the page to be able to read it properly.

    2. Some bugs I've noticed are in the Preferences buttons, in vector 2022 some buttons can appear to have 2 options selected at once in situations where that isn't possible, i.e. the layout preference.

    3. The sudden change may cause severe issues and bugs to scripts and plugins that rely on the design itself. PerryPerryD Talk To Me 20:28, 22 September 2022 (UTC)[reply]

    Thanks @PerryPerryD for this comment. For our convenience, I'll address these issues using a numbered list, too:

    1. "Almost every new user to Wikipedia will think This looks squished and hard to read" - this isn't what we have observed so far, and bear in mind that this is live already on some large Wikipedias. There are also some arguments for introducing the limited width for the benefit of reading. More precisely, this is both about limiting the width, and introducing unused space. In addition to that - we're considering increasing the font size. We want to have that conversation after we make Vector 2022 the default, because we know this issue is important and delicate for the community, and want to give it due time and space. What do you think about that?
    2. Any chance that might have been GlobalPreferences, not local preferences?
    3. We've been working on this skin since three years, and all the time, we've been collaborating with the technically skilled volunteers quite closely. Most popular gadgets and user scripts have been fixed quickly. We may have missed something, though. Have you noticed anything being broken in particular?

    SGrabarczuk (WMF) (talk) 20:45, 22 September 2022 (UTC)[reply]

    Could you clarify "we" and "observed"? Specifically list the number of the decision makers, as well as ALL combinations of browser/processor/display unit that were surveyed. I'm wondering if there is a pro-laptop-class bias in the assertion about popularity (I mean "second most popular") that is a justification for the change. Martindo (talk) 04:01, 24 September 2022 (UTC)[reply]

    @PerryPerryD, thanks for testing the skin. Would you like to help us identify the bugs? I'd be grateful if you could share what you've noticed so far. SGrabarczuk (WMF) (talk) 20:28, 22 September 2022 (UTC)[reply]

12. Leaning Oppose - I guess I just don't get why a screen width preference isn't a built-in option without needing gadgets/scripts, and I'm puzzled that the developers/planners of Vector 2022 are seemingly either flat out unwilling to or just very hesitant to implement such an option. When FANDOM announced that they were redesigning their website, the biggest feature requested was a full-width option, and FANDOM did it. When TV Tropes redesigned their website, people wanted a wide load option, and they made it an option. Why the seeming resistance? Also since I'm a Monobook user, I like how the buttons are actual words as opposed to just icons. ♠JCW555 (talk)♠ 20:22, 22 September 2022 (UTC)[reply]

    Registered users can continue to use legacy vector or even monobook and use the full width of their displays. Unregistered users neither have preferences nor user scripts to fiddle with the width. For whom should there be a width preference in the skin? —MisterSynergy (talk) 20:43, 22 September 2022 (UTC)[reply]

    I mean, other people here and over at MediaWiki have commented that they'd use Vector 2022 if it had a full-width option. ♠JCW555 (talk)♠ 20:59, 22 September 2022 (UTC)[reply]

    Thanks so much for joining the conversation and for this Fandom reference @JCW555. It is very relevant. We appreciate it and are taking it under consideration. AHollender (WMF) (talk) 15:35, 23 September 2022 (UTC)[reply]

    NP Alex! I should have also mentioned in my initial comment that there are some aspects of Vector 2022 that I do like, like the scrollable TOC (though it is a bit janky sometimes). But if I had to choose between them, I'd rather have full-width text. SGrabarczuk's comment below does assuage some of my concerns. ♠JCW555 (talk)♠ 00:15, 24 September 2022 (UTC)[reply]

13. Oppose, bordering on a strong oppose. I think the 2022 skin is unattractive, increases dead space, is more unpleasant for reading, and shouldn't be dumped on readers and editors alike. I would rather we improve any shortcomings within legacy than try this. I also agree with User:JCW555 that it is bizarre how the 2022 developers are hesitant to give a wideform option, and the amount of formatting that will need to be reworked for image-heavy articles will be a nightmare. Frankly, the skin itself is not a compelling reason to make such a significant switch for little to no real benefits. Kazamzam (talk) 20:41, 22 September 2022 (UTC)[reply]

    In my skim of the wiki when reviewing in this skin, I have seen fewer issues with image-heavy articles, not greater. MOS:SANDWICH basically disappears with a fixed width, as does the effect of image-stacking that pushes images out of the vicinity of the text they go with. Izno (talk) 20:48, 22 September 2022 (UTC)[reply]

14. Oppose, for now. I don't find it that much better in terms of readability. The width issue concerns me right now as well. If we can change that preference I'll likely vote in support. SEMMENDINGER (talk) 20:50, 22 September 2022 (UTC)[reply]
15. Oppose. Too much whitespace wasting screen real estate. Useight (talk) 20:55, 22 September 2022 (UTC)[reply]
16. Oppose primarily due to fixed width - Here are my general thoughts after testing new vs old vector. The good of new vector: The table of contents staying visible in the left sidebar is great. On old vector, this space is unused and the table of contents gets lost at the top. Collapsing the user links on the top is also nice, since we don't normally need to click them in the course of regular reading / editing, and having them follow you down as you scroll down the page is potentially useful. The bad of new vector: 1 pixel black-on-gray for a tab is significantly less usable than old vector's shaded tabs. This feels like changing styles for the sake of changing styles, which, unsurprisingly, ended up with something less usable than the original. The ugly: Fixed width. The fixed-width reading view wastes a lot of space, but it is at least usable. If you switch to an editing view, it turns into a total mess. The edit box is compressed into a tiny rectangle, which is certainly not suitable for editing anything other than a stub article. The history view isn't as bad, but it does cause most edit summaries to wrap to a second line, effectively "doubling" the length of the history page. To summarize, this feels like new vector was designed for people to read like a newspaper, not for people to edit like a wiki. It has a number of nice little improvements, but it also has some major issues that prevent deployment at this time. Reaper Eternal (talk) 21:09, 22 September 2022 (UTC)[reply]

    The edit box is compressed into a tiny rectangle, which is certainly not suitable for editing anything other than a stub article. sounds like a user script/CSS interacting badly as I do not experience that issue - i.e., my edit box is a larger width than even the maximum content width. Izno (talk) 21:15, 22 September 2022 (UTC)[reply]

    I just deleted all my user scripts, purged my cache, and tried again, and there was zero difference (other than the items that I'd hidden/added with CSS & JS being present/absent respectively). Reaper Eternal (talk) 21:25, 22 September 2022 (UTC)[reply]

    User:Reaper Eternal/vector.css will not cause this problem, and your JS page looks fine also.

    It may also be a gadget. Did you review those and/or can you list them? Particularly focused on any that might touch or operate on/near the edit box (e.g. wikEd or DOT's syntax highlighter).

    Would you mind uploading a screenshot somewhere just to confirm that what you're seeing is what I think you're seeing? Izno (talk) 21:47, 22 September 2022 (UTC)[reply]

    Other than Twinkle and navigation popups (neither of which affect the editor), I have all major gadgets disabled. I have a few random minor gadgets like the "request confirmation before rollback on mobile devices" gadget. Reaper Eternal (talk) 22:02, 22 September 2022 (UTC)[reply]

17. Oppose. Floating elements, excessive whitespace, and fixed width concern me. Vector 2010 is a good skin that many folks have gotten used to. The status quo seems fine. –Novem Linguae (talk) 21:12, 22 September 2022 (UTC)[reply]

    @Novem Linguae - thanks for your feedback. We know that the current skin meets the needs of many in this community and that gadgets, user scripts, and other customizations have helped in the cases when it didn’t. Our goal here was to make sure that this is the case for everyone using the wikis. The current skin, Vector, has been in use since 2010. When it was developed, it reflected the needs of the readers and editors of the Wikimedia sites in that year. Since then, a lot of new audiences have begun using the Internet and Wikimedia projects and their voices and needs were not included in the development of this skin. Research done with these audiences showed that the Vector skin as it is right now doesn't meet their needs.

    In particular, we found that readers thought that the current skin had too much information density (hence the introduction of fixed width), found it difficult to navigate, were unable to understand the purpose, terminology, and concepts of available tools, found it difficult to search and find the information they were looking for both within the current page (due to difficulties accessing the ToC) as well as across different pages (due to difficulties using the old search bar).

    We built the new skin to tackle these problems specifically, so that everyone could benefit from the wikis - those who have been using the projects for a long time, as well as those who have joined more recently, or have yet to join. OVasileva (WMF) (talk) 22:22, 22 September 2022 (UTC)[reply]

18. Oppose In an example, the contents sidebar does not seem to adequately track the contents while scrolling (and it is not clear how this helps the reader even if it did work) and the resulting 'squished' appearance of the text seems contrary to the goal of effectively sharing information for everyone, per WP:ACCESSIBILITY. While this may be an inconvenience for some, it may also be a more significant barrier for others. Beccaynr (talk) 21:18, 22 September 2022 (UTC)[reply]

    Hey @Beccaynr, thanks for taking the time to comment. I would like to question your assumption: 'squished' appearance of the text seems contrary to the goal of effectively sharing information for everyone.

    Firstly I'm curious if you've had a chance to review the research regarding optimal line length for readable text? Thankfully it has been extensively researched over the past several decades (starting with printed text, and more recently for electronic text), and the findings are quite clear. You can start here if you would like to dig in. We think it's critical to offer the best reading experience, and that we should follow the best practices and well established research on this topic

    As an exercise, I'm curious if you can provide examples of other popular, content websites you are familiar with that do not use limited width for text, so that I may review and learn from them? I have not yet found such examples (and in fact all others I've found have a more narrow width limitation that Vector 2022). I am referring to websites like ProPublica, BBC, Snopes, AVClub, BBC, The Lancet, Reddit, The World Health Organization, Baidu, Medium, and Medium. I also find the same width limitation in books, newspapers, and magazines.

    If you can help me better understand your perspective I would be most appreciative. Thanks, AHollender (WMF) (talk) 22:32, 22 September 2022 (UTC)[reply]

    AHollender (WMF), it seems as if principles of universal design may not have been fully considered, if this proposal is based on research suggesting this appearance works better on non-Wikipedia websites for a "majority" of readers. From my view, principles of universal design may support advertising this more mobile-style appearance, so Wikipedia readers can select this option, instead of setting this new skin as a default. It seems more inclusive to have the familiar version as the default and the new version as an option. My perspective is reinforced by your suggestion [1] that what seems sufficient for a "majority" of readers of non-Wikipedia websites should be considered "optimal" for Wikipedia readers and editors. Your link to research also leaves me less convinced about setting this as a default. Also, for participants who may not be as familiar with discussions here, a review of the WP:BLUDGEON essay might be helpful. Thank you, Beccaynr (talk) 23:18, 22 September 2022 (UTC)[reply]

    I have further expanded on my comments here in the discussion below [2]. Beccaynr (talk) 19:04, 23 September 2022 (UTC)[reply]

19. Oppose I realize now that I've been exposed to Vector 2022 via links I've visited, and every time, I've thought "Ew, it's trying to force mobile." The first response from any reader shouldn't be "Ew." NekoKatsun (nyaa) 21:29, 22 September 2022 (UTC)[reply]

    Hi @NekoKatsun, thanks for this comment. Could you share why you were convinced this was to similar to mobile? SGrabarczuk (WMF) (talk) 21:45, 22 September 2022 (UTC)[reply]

    Sure! In my experience, sites optimized for mobile viewing eliminate/collapse sidebars and headers, presumably to fit more information on a limited screen. The left-hand sidebar being gone, the floating contents button (that does actually cover a little content in the top left), the greatly-reduced information in the header - all of these things look like the mobile version of a web page that's forcing itself to load on desktop.

    I will note that what I'm talking about is apparent when the window isn't the full width of my screen (1920), but unfortunately that's how I usually read and edit Wikipedia, with one window taking up the left half for reference and the other on the right for actually making changes. NekoKatsun (nyaa) 21:58, 22 September 2022 (UTC)[reply]

    Oppose, it does not look good and having to access the TOC via a sidebar just feels clunky and also forces the viewing area to be narrower. Along with that, the purpleish hue on visited links does not look good. I don't care that it's for accessibility, there has to be some alternative. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:39, 22 September 2022 (UTC) Striking my oppose for now so I can formulate a fuller opinion on it as I opposed after only a few minutes of trying it out. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:22, 26 September 2022 (UTC)[reply]

20. Oppose - Looks bad in my opinion, doesn't seem like an improvement. Waxworker (talk) 21:43, 22 September 2022 (UTC)[reply]

    Hi @Waxworker - thanks for your opinion here. Do you think you could give some more details on why you think it's not an improvement over the old Vector skin? OVasileva (WMF) (talk) 13:55, 26 September 2022 (UTC)[reply]

21. Oppose Too narrow and too much annoying white space on both sides. AhmadLX-(Wikiposta) 21:46, 22 September 2022 (UTC)[reply]
22. Oppose The numbers provided by User:BilledMammal are very telling. As for me, I find the TOC being moved to the left sidebar to be unnecessary. Specifically, that move means that I must test an article using __TOC__ in multiple skins which is a waste of time. I would consider supporting if we fixed the whitespace issue and moved the table of contents back into the article content proper - rather than hiding it in the sidebar. ~ Matthewrb ^{Talk to me · Changes I've made} 22:14, 22 September 2022 (UTC)[reply]

    Thanks @Matthewrb. Have you maybe had a chance to read my reply to BilledMammal's comment on the survey? It's important for me to avoid misunderstandings around that specific issue. I must test an article using __TOC__ in multiple skins - could you share more why you feel you must do that? For the limited width, see the new section below (#Update on the fixed width and white space). SGrabarczuk (WMF) (talk) 22:22, 22 September 2022 (UTC)[reply]

    I have read this entire RFC, and I do not find the reasoning in your reply compelling - fully responsive skins have existed for a long time (see Bootstrap for a prime example) so intentionally creating a fixed-with solution is entirely unnecessary when we can create a fully responsive solution that doesn't intentionally waste space. As for the __TOC__, when I sent International Film Music Critics Association Award for Best Original Score for a Video Game or Interactive Media to Featured List, I tested it in Vector, Vector 22, and Timeless. Vector 22 still has a huge gap instead of the table of contents as would be expected. And a reader will have to scroll down on the left sidebar to even access the TOC in that particular article, which is a usability nightmare. ~ Matthewrb ^{Talk to me · Changes I've made} 22:34, 22 September 2022 (UTC)[reply]

23. Oppose - It doesn't look attractive to me, I still prefer the 2010 version. This 2022 version is a perfect description of "from grace to grass" or from "frypan to fire". I'm fine with the legacy version, and everything about it looks convenient and matured. Comr Melody Idoghor (talk) 22:16, 22 September 2022 (UTC)[reply]

    Hi @Idoghor Melody - thanks for your feedback. I just replied to a similar concern above, so I'll quote my comment from there:

    We know that the current skin meets the needs of many in this community and that gadgets, user scripts, and other customizations have helped in the cases when it didn’t. Our goal here was to make sure that this is the case for everyone using the wikis.

    The current skin, Vector, has been in use since 2010. When it was developed, it reflected the needs of the readers and editors of the Wikimedia sites in that year. Since then, a lot of new audiences have begun using the Internet and Wikimedia projects and their voices and needs were not included in the development of this skin. Research done with these audiences showed that the Vector skin as it is right now doesn't meet their needs.

    In particular, we found that readers thought that the current skin had too much information density (hence the introduction of fixed width), found it difficult to navigate, were unable to understand the purpose, terminology, and concepts of available tools, found it difficult to search and find the information they were looking for both within the current page (due to difficulties accessing the ToC) as well as across different pages (due to difficulties using the old search bar).

    We built the new skin to tackle these problems specifically, so that everyone could benefit from the wikis - those who have been using the projects for a long time, as well as those who have joined more recently, or have yet to join. OVasileva (WMF) (talk) 22:30, 22 September 2022 (UTC)[reply]

    @OVasileva (WMF):I feel this is no longer a request for comment to generate consensus if you'll have to persuade editors to buy the idea of the 2022 skin. Allow the community choose what they are convenient with. I don't see any reason why an editor will oppose and they're indirectly being convinced to buy the idea. I might be wrong, but that's how I feel right now. Comr Melody Idoghor (talk) 22:46, 22 September 2022 (UTC)[reply]

24. Oppose. Reaper Eternal's comment above echoes what I was about to write, so I'll not repeat it. The new skin may be decent for reading (despite the survey above) but it's a big step back for editing. The one use case I can see is if the intention is to have one skin for readers and another (supported indefinitely) for editors. However, that risks editors releasing content which doesn't work well in the readers' skin. It's true that most other sites shoehorn their content into a central column, but that's mainly to create artificial sidebars for advertising. We're better than that. Certes (talk) 22:30, 22 September 2022 (UTC)[reply]

    @Certes, thanks for your comments. Thankfully optimal line-length for readability has been researched for several decades now. It is not something we need to guess at, or define on our own. Are you familiar with "Reader mode" in Chrome, Firefox, or Safari? I think these modes usefully demonstrate that limiting line length is not about making space for sidebars or advertisements. Similarly, you can find these best practices followed in printed materials like newspapers, as well as websites without advertising (ProPublica, Ars Technica, AV Club, The Guardian, BBC, etc). AHollender (WMF) (talk) 22:46, 22 September 2022 (UTC)[reply]

    @AHollender (WMF): I'm sorry; are you arguing that Ars Technica and AV Club... don't run ads in their sidebar? They seem to do so on my laptop, though I'm not sure what browser you use and/or ad blocker that you may have installed. — Red-tailed hawk _(nest) 23:10, 22 September 2022 (UTC)[reply]

    @Red-tailed hawk ah I am so sorry, I do have an ad-blocker installed. Thank you so much for pointing that out! I've crossed the names out in the list above. AHollender (WMF) (talk) 02:29, 23 September 2022 (UTC)[reply]

    One point I missed out, which others have made well: the current text links (top right) are much clearer than the new icons, which one has to hover over to find out what a blob on a squiggle means. Icons may have language independence, but this is English Wikipedia. Hiding links such as the sandbox in a drop-down does save space, but that space (top centre) remains white rather than being used for anything better, and creates a risk that new editors will fail to discover critical features such as their user talk page. Certes (talk) 11:21, 23 September 2022 (UTC)[reply]

25. Oppose @Red-tailed hawk: Covered my concerns in the first comment, and only further defined by others here. I am not a fan of the trend towards more whitespace on internet pages, the endless scrolling, and general mobile-ization of pages. Honestly if this was the default when I joined, I probably would not stick around. Kaiser matias (talk) 22:45, 22 September 2022 (UTC)[reply]
26. Oppose if it ain't broke, don't fix it. The legacy just looks better IMO. Iamreallygoodatcheckers^t@lk 22:46, 22 September 2022 (UTC)[reply]
27. Oppose per the above comment by Iamreallygoodatcheckers: If it ain't broke, don't fix it. Legacy looks better, 2022 can strain my eyes. FrederalBacon (talk) 23:10, 22 September 2022 (UTC)[reply]
28. Oppose Too much empty, wasted screen space and too many unnecessary clicks needed to get to basic pages (like the user's Talk and Contribution page). Not an improvement over Vector 2010 at all. Some1 (talk) 23:13, 22 September 2022 (UTC)[reply]
29. Oppose I've never been a fan of using icons for menu items. I can't read icons. It's mystery meat navigation. We have a little bit of that with monobook. Vector makes that worse. Trying to solve some problems by introducing other problems isn't a way forward. --Hammersoft (talk) 23:19, 22 September 2022 (UTC)[reply]
30. Oppose because of technical and UI issues. 1. "This looks squished and hard to read", When I used vector 2022, I had to ZOOM in onto the page to be able to read it properly. reported by another user above has nothing to do with limiting the width, as alleged by SGrabarczuk (WMF). It's caused by an incorrect meta viewport value that's incompatible with the implementation of responsiveness on smaller screens. If you need a way to observe it, open FR Wikipedia on an iPhone and switch to desktop version - the main text is unreadable, and the menus are completely unusable. It's a pure technical bug due to lack of testing, not a limitation of limited-width layouts. 2. The contrast of the links with the background is definitely worse than on the current version and makes them, and consequently heavily wikilinked articles, harder to read. I believe the decision to increase ease of locating wikilinks in favour of overall readibility of the article text was misguided. 3. Location of article contents in the bottom below the menu is counter-intuitive; hiding subsections by default is completely unnecessary - why would two clicks be needed to navigate to a subsection? PaulT2022 (talk) 23:51, 22 September 2022 (UTC)[reply]

    Having said that, I think Vector 2022 is modern and well designed - it's all comparatively minor issues that together make it genuinely worse than the legacy. PaulT2022 (talk) 00:05, 23 September 2022 (UTC)[reply]

    @PaulT2022: just curious, do you find both link colours (blue and purple) difficult to read? Femke (talk) 01:57, 23 September 2022 (UTC)[reply]

    Yes, when in article text: the words stand out too much and I have to make an effort to stop and adapt eye to a sudden bleak word, if it makes sense. It looks ok in signatures on talk pages or references, but it just makes main article text too hard to read.

    I believe that Nature and ProPublica, referenced as model websites in the FAQ below, use more contrast colors, similar to the ones Wikipedia uses currently. If the change to contrast between text and links is absolutely necessary for accessibility, I'd prefer black colour with thin underlining or bold font for "blue" wikilinks instead of light blue - see Bloomberg, Reuters and BBC for example. PaulT2022 (talk) 11:29, 23 September 2022 (UTC)[reply]

    That absolutely makes sense. I have to exert more effort to read the purple than the blue, but good to hear more voices here.

    I love the subtle underlining of the BBC. I imagine bolding would not work in the context of Wikipedia, as links are everywhere and do not need the extra emphasis. Underlining and nonbolded colours with slightly less contrast to prose may work best. I wonder if underlining has been considered as a way to meet accessibility needs (@AHollender (WMF) and @Volker E.)? The Guardian also has little subtle underlining. Femke (talk) 16:31, 23 September 2022 (UTC)[reply]

    @Femke oh yes. What I wrote above applies to blue and purple equally, didn't mean to imply that purple is fine. Sorry for the confusion. (Red too, but there are few red links, so I don't think it really matters.) PaulT2022 (talk) 16:57, 23 September 2022 (UTC)[reply]

    Interesting to hear this - I find them both almost completely indistinguishable from regular text in Vector 2010, and better (but still not great) in Vector 2022, due to the low contrast. I had to use custom css to see visited wikilinks. But I would never call the BBC style "subtle"! Those links are very easily visible. -- asilvering (talk) 04:52, 24 September 2022 (UTC)[reply]

31. STRONG Oppose In the proposed skin the articles have reduced space and the left menu and right sides dominate the screen. This is the opposite of the way it should be. The article should dominate the screen. WhoAmIYouDoNotKnow (talk) 00:09, 23 September 2022 (UTC)[reply]
32. Oppose; there's too much empty space on the left and under the search box. The "hamburger", ellipsis and chevron menus aren't intuitive and are easy to miss – how does a random visitor know what they're for? I understand the need to remove clutter (hint; ever heard of the in-browser "reader view" feature?) but how are random visitors supposed to find this stuff? Navigation frames are 20 years outdated. It's not an improvement over the extant default skin. Baffle☿gab 00:37, 23 September 2022 (UTC)[reply]
33. Oppose Fix the width. Squishing content on computer monitors doesn't make any sense. Everything else about the skin is fine. — PerfectSoundWhatever (t; c) 00:44, 23 September 2022 (UTC)[reply]
34. Oppose Having user links like talk, contributions, preferences, sandbox in a dropdown is just adding an extra click to access commonly used links. The watchlist icon looks like a combination of a browser bookmark and notification sidebar icon. Just call it what it is — watchlist. But the narrow main text width is the big no-go for me. It causes layout issues. Even the example Pluto article shows problems. Scrolling down where there are tables and images, we get jumbled and dislocated tables and images, along with even worse squished text. For layout specifically (and in general) it is displeasing to look at. DB1729^talk 00:46, 23 September 2022 (UTC)[reply]

    On a positive note however, I do think the floating TOC on the left is a good idea. DB1729^talk 01:12, 23 September 2022 (UTC)[reply]

35. Oppose primarily due to fixed width per Reaper Eternal and Certes. It would be good if the proposal pointed out that adding ?useskin=vector-2022 at the end of the URL allows you to preview how it would look on any particular article or device. There are good aspects to the skin, particularly the table of contents. For example I have disabled ToC on articles such as Electoral results for ... because with 65 elections across 17 decades the ToC results in a lot of scrolling to get to the article - tested the same page with a ToC in the new skin and its a big improvement. I access WP via my phone, 13" laptop, desktop with 2 24" screens and desktop with a 50" screen. The new skin is fine on my phone or laptop, it is only when I am using either desktop that it becomes limiting. This is particularly apperent when editing where I have articles side by side. --Find bruce (talk) 00:56, 23 September 2022 (UTC)[reply]
36. Oppose. This layout looks too much like a mobile website, despite the fact mobile Wikipedia has a completely different skin. O.N.R. ^(talk) 00:59, 23 September 2022 (UTC)[reply]
37. Oppose I remember reading about this a year ago and I hated it. I have a desktop computer and the white space is so ridiculous. It feels cheap, like there are are supposed to be advertisements or something to fill in the space. One of the things in favour of this was about how it purportedly was easier to read words with less characters per line. However this negates the fact that in many articles, images and infoboxes already shorten line length. In some articles, infoboxes can take up a significant amount of the page. This means less opportunities for images. It also squishes tables. I would argue that it makes text less readable than the current vector. Not to mention talk pages with discussions that indent the text makes for so much more scrolling. I feel bad for the French Wikipedia. Heartfox (talk) 01:07, 23 September 2022 (UTC)[reply]
38. Regretful oppose. I regretfully find myself in this section, two blocking concerns, and one more major concern.
    • The box-ticking on accessibility wrt link colours. Rather than accessing accessibility with users, a choice has been made to only check the WCAG standards. The physical contrast tested by WCAG is but a proxy for the biophysical or perceived contrast. Those two metrics can differ, with user tests sometimes giving opposite preferences compared to contrast checkers (see Myth 1, and from WebAIM For many of us, some of these combinations are not very readable. That is why 4.5:1 is the minimum required by WCAG.., look at the actual contrast difference of links with the same physical contrast). I'm not the only one that didn't have accessibility problems before, but now struggles to read the visited links. Wikipedia is very link-heavy compared to other websites, and the number one priority should be to make the text of the link readable. Only if that accessibility requirement is met, should others be prioritised. I see a couple of ways forward
      • Different colours can be tried. Is a more reddish purple easier to discern? Pinkish? blueish?
      • A compromise colour can be chosen that does not quite meet the WCAG standards, but which does meet user tests for accessibility
      • I'd even be okay with underlining links if that means the colours can be matched closer to the rest of the prose.
    • The white space on the right. I love the smaller column width, and I'm excited how that will benefit readers, and entice editors to write easier prose (rather than superlong paragraphs that, in the new interface, fall of the screen). However, the white space on the right looks quite ugly. Can't we mimic reddit with a symmetric grey colour around the edges. The article tools for editors are a good solution to dampen the bright white, but most people interacting with Wikipedia are readers.

      Addendum. I've had a look around a large set of other websites. Almost all use white space on the sides. The major reason why that works for them but not in this design is symmetry: the white space (or sometimes grey), is spead equally on both sides. Could this be implemented for logged-out editors/those with the future editing tools collapsed too, @SGrabarczuk (WMF):? I think that may sway 10% of the opposes here. Femke (talk) 11:21, 23 September 2022 (UTC)[reply]

    • Not a blocker for me, but a major drawback is the the fact that the new skin breaks the TOC limit template. (the claim No existing features or tools were removed as a result of the new skin. is still present in the text, despite the fact it I pointed this out). With less space for the TOC, this template is key to hide less important headings. It's used around 20,000 times, and some pages, like WP:FAC become unworkable without. Femke (talk) 02:32, 23 September 2022 (UTC)[reply]

      Thanks Femke I'd missed that change. Find bruce (talk) 03:43, 23 September 2022 (UTC)[reply]

      To be fair, there is some commitment to fix this: phab:T317818. That's the reason this is not a blocker for me. Femke (talk) 11:21, 23 September 2022 (UTC)[reply]

39. Strong oppose - I showed the new view (on a HD desktop screen at 100% scaling) to my family a couple of months ago and they were convinced that I was showing them a mock-up of Wikipedia with ads. Very few changes have been made to Vector 2022 since its initial deployment in 2020, and the way in which the WMF employees seem to consider this a rubber stamp for a done deal makes me sceptical that any problems brought up will be addressed to the satisfaction of the community. (I have copied this over from Wikipedia talk:Requests for comment/Deployment of Vector (2022) since I initially posted this there after getting lost in the maze of the short neutral RfC statement.) Daß Wölf 02:02, 23 September 2022 (UTC)[reply]

    Changed to strong oppose. It seems this design has problems on all layouts. Developers' trying to sidestep the RfC rules and badgering the opposes doesn't bode well either. English Wikipedia readers should not be involuntary beta testers. Daß Wölf 15:16, 24 September 2022 (UTC)[reply]

40. Oppose - for hiding the cross-project links. dwadieff ✉ 03:21, 23 September 2022 (UTC)[reply]
41. Oppose, squishes tables, absent TOC makes infobox way too large, and overall I can't get myself to tolerate it. ɴᴋᴏɴ21 ❯❯❯ talk 03:27, 23 September 2022 (UTC)[reply]
42. Oppose - Regardless of whatever reasons the devs give about fluidity and whatnot, the white space is a huge eyesore and simply intolerable. Nothing I have read from any of the developers' replies have convinced me of its benefits. My greatest peeve, possibly exceeding that of wasted screen space, is the double arrow on the top left. Such a button implies that there's a "main page" to return to, similar to UIs on phones. It gives off the vibes that all articles are simply subsidiaries of the main page. Worst of all - it performs a function that is entirely unexpected - simply collapsing the main menu. As an active editor, it's unlikely I will ever collapse it as I would require access to its functions, leaving the arrows there permanently. Seloloving (talk) 05:03, 23 September 2022 (UTC)[reply]
43. Strong oppose – I have commented multiple times throughout the development process that this redesign is (a) fundamentally misinformed in scopre and (b) a big step backwards. To summarise my criticism, the Vector redesign has been approached as if it is being produced for mobile, touch-enabled devices, despite being a desktop user interface. 5225_C (talk • contributions) 06:06, 23 September 2022 (UTC)[reply]

    A lot of internet traffic comes from both mobile and desktop. The current Vector skin is completely unusable on a mobile device. On the other hand, the newer Vector skin could in theory be used on mobile but it still needs more changes to be fully responsive. I am posting this on timeless, a skin designed for responsive design - regardless of screen size or layout, everything is fully functional (almost) and I prefer it over the mobile front-end. Aasim - Herrscher of Wikis ❄️ 14:47, 23 September 2022 (UTC)[reply]

    @Awesome Aasim: I just tried the new Vector skin (desktop view) logged out on a mobile device. It looks much the same as the old desktop view, except the text column is a good deal narrower (due to the TOC column). Images on both sides of the text create bigger gaps in text as some single words can no longer fit between them. The new design at first glance does look like it was optimised for mobile use, but it seems to be a step back there too. Daß Wölf 15:16, 24 September 2022 (UTC)[reply]

    @Awesome Aasim: The current Vector skin isn't used for mobile devices, they have their own user interface. My criticism is that the new Vector design, which is a desktop interface, appears to be better suited for mobile devices than it does for desktops. It is not fit for purpose. 5225_C (talk • contributions) 10:37, 25 September 2022 (UTC)[reply]

    A lot of modern websites are designed with variable screen size in mind. Google, wikiHow, and Microsoft are a few such sites that are responsive; no matter the screen size or device the site remains mostly usable. Sure the mobile front-end handles mobile devices but like I said before it is still severely limited because of the functions which actually work on mobile. Aasim - Herrscher of Wikis ❄️ 13:56, 25 September 2022 (UTC)[reply]

    “The current Vector skin is completely unusable on a mobile device.”— This is not my experience. For years, I have used desktop vector for reading and editing on mobile, and I’ve found it a much better experience than Minerva. In fact, I have a user script installed that redirects me to desktop when Google sends me to the mobile site. Text is a bit small but I can always zoom or increase the text size. —pythoncoder (talk | contribs) 18:13, 25 September 2022 (UTC)[reply]

    @pythoncoder, how wide is your screen? I certainly had problems when I used Vector 2010. — Qwerfjkltalk 19:57, 25 September 2022 (UTC)[reply]

    Up until recently it was a first-generation iPhone SE with a 2-inch (640-pixel) wide screen. Now it's the iPhone 13 Mini which is a little wider. In either case, I can't say it's problem-free but everything's still usable. Probably comes down to a matter of level of tolerance. That and operating system — I have no idea how it looks/functions on Android. —pythoncoder (talk | contribs) 22:09, 25 September 2022 (UTC)[reply]

44. Strong oppose - Absolutely nothing wrong with the current UI. Replacing clear text buttons with obtuse logo buttons is a massive mistake. Desktop users do not deserve to have to put up with ridiculous mobile phone style UI design. HumanBodyPiloter5 (talk) 08:23, 23 September 2022 (UTC)[reply]

    As it currently stands Wikipedia is one of the few major websites left that retains a clear user interface where every button has a clear purpose that builds trust in readers. In an age where corporate websites constantly seek to erode at the concept of consent itself with obtuse UI and buttons saying "yes" and "later" rather than "yes" and "no", I believe Wikipedia has a strong ethical responsibility to lead by example with a user interface that is clear and free of meaningless iconography. HumanBodyPiloter5 (talk) 11:06, 23 September 2022 (UTC)[reply]

    Ironically, the original draft of this RfC was a choice between "yes" and "later". Certes (talk) 11:10, 23 September 2022 (UTC)[reply]

    Only more reason to oppose the changes more strongly. The rest of the UI changes I do not have particularly strong feelings on, but I am vehemently opposed to hiding basic functionality in drop down menus accessed through opaque abstract symbol buttons. If Wikipedia is intended to share knowledge with the world then such a design choice should be considered anathema. HumanBodyPiloter5 (talk) 11:45, 23 September 2022 (UTC)[reply]

    You also need to remember that mobile exists, and in its current form, the Vector skin is barely usable on mobile. The mobile front-end is even worse, since I do not have access to all the same functions that I would have on desktop. That is what got me to use the Timeless skin instead. Aasim - Herrscher of Wikis ❄️ 14:49, 23 September 2022 (UTC)[reply]

45. Oppose looks inappropriate. The current is much better.--Sakiv (talk) 08:43, 23 September 2022 (UTC)[reply]
46. Oppose. There are many aspects that are an improvement but the flaws more than outweigh them. Article content is our principal focus and this skin reduces the space available for it while significantly increasing dead space and wrapping, which leads to a worse user experience with (among other things) increased scrolling and tables that are much harder to parse. _wjemather^{please leave a message...} 09:04, 23 September 2022 (UTC)[reply]
47. Oppose - I really dislike the new skin. It might just be me having an aversion to change, but I find it more awkward to use, less pleasant to read, and as others have mentioned the screen width is a big issue. As a colourblind person, I really appreciate the change to link colours though! I'd love to see that become standard. - ThatSpiderByte 🕷️ 11:12, 23 September 2022 (UTC)[reply]
48. Oppose – Doesn't work on my browser. If it becomes the default, how will I navigate to preferences to opt-out with no interface? Accessibility concerns should include those of users with older hardware and software, if this is supposed to be the encyclopedia that anyone can read and edit. The for-profit web serves recently developed platforms so that their ads are fed to those who can afford a new computer every year; non-profits shouldn't follow that paradigm. – Reidgreg (talk) 12:43, 23 September 2022 (UTC)[reply]

    Hi Reidgreg - thanks for your feedback here. Can you tell me a little bit more about what you're seeing and why you're unable to access preferences? Which browser/device are you using? OVasileva (WMF) (talk) 14:17, 26 September 2022 (UTC)[reply]

49. Oppose - I just don't like how this looks and never have. It looks like a cheap mobile version, and I don't even like it on mobile - this doesn't feel designed for a desktop at all. Toa Nidhiki05 13:04, 23 September 2022 (UTC)[reply]
50. (edit conflict) Oppose Looks terrible compared to Vector 2010, which IMO should remain the default. Just because something has been around for a while doesn't make it inferior. One thing I got from this RfC was learning about reader mode in my browser (Firefox), but I don't see myself using it. Desktop usuers with larger monitors shouldn't be penalized. Miniapolis 13:10, 23 September 2022 (UTC)[reply]
51. Oppose - The left panel is too big and the right one grossly intrusive. The article itself should dominate, not externals. What would pages like List of birds of South America look like with it? Some family lists within it (e.g. hummingbirds and tanagers) already require significant scrolling. This change looks like it would require 50% more scrolling. Craigthebirder (talk) 13:57, 23 September 2022 (UTC)[reply]

    Indeed, https://en.wikipedia.org/wiki/List_of_birds_of_South_America?useskin=vector-2022 squeezes three columns into two and two columns into one, and four-image-wide galleries into three-wide. Just awful and wasteful of my screen space, forcing more scrolling. Reywas92^Talk 23:34, 26 September 2022 (UTC)[reply]

52. Oppose - the fixed width is a dealbreaker for me. ♠PMC♠ (talk) 14:30, 23 September 2022 (UTC)[reply]
53. Oppose. A fixed-width layout is a regression to how we built websites in the past because we didn't have better tools. On a wide screen, this wastes valuable screen real-estate by preventing me from using my full screen width to view tabular material with long rows (something which I do often). On a narrow screen, this wastes real-estate by wasting both sides on white space which serves no function. -- RoySmith (talk) 15:09, 23 September 2022 (UTC)[reply]

    Just to clarify, I fully understand that for running text, long lines are difficult to read. And it seems like that's the major point this kind of layout is trying to address. I have no complaint there. My complaint is specifically that for tabular material, folding one logical line into several physical lines is terrible. And for me, the inability to drag a window out as wide as I need it to get tabular material laid out properly is deal killer.

    I don't remember where we had this conversation before (somewhere on meta, I would guess), but the idea was kicked around that you should be able to mark up running text vs tabular material. The running text could be rendered with line lengths that were optimum for that, and the tabular material wouldn't be constrained. I remember talking about the CSS overflow property being used to control this, but I'm far from an expert on CSS, so I'll leave it to the experts to figure out how it would be implemented.

    I'm also concerned that the "But you can just go back to the old skin" argument is a red herring. If this is rolled out as the default, it will inevitably become the standard. Other skins will stop being supported. As new features get rolled out (to be sure, some new features like the reply tool and thread subscriptions were awesome improvements), they will only be supported on the "standard" skin. So little by little, it will become impossible to work unless you move to the new standard. -- RoySmith (talk) 19:09, 23 September 2022 (UTC)[reply]

    

    Here's an example of what I mean. This is an article history display with lines that exceed the width available in this skin. To me, it's virtually illegible. I have to force my eyes to scan down the list in logical "one edit per record" order. Sometimes I have to move down one physical line to get to the next logical record, sometimes I have to scan down two lines. I find that very difficult.

    I bought a big monitor to make sure I can always make my windows wide enough to avoid this problem. On tables where even a full width window isn't wide enough, I can drag windows around to make a window which is wider than my physical screen. I slide some of it off the right edge of my desktop, optimizing screen space for the most important information on the left.

    The introductory material on this page says, The new skin does not remove any functionality currently available on the Vector skin. That's simply incorrect. It removes my ability to use the full width of my monitor so I can read wide tables. -- RoySmith (talk) 11:41, 24 September 2022 (UTC)[reply]

    Roy said: My complaint is specifically that for tabular material, folding one logical line into several physical lines is terrible. And for me, the inability to drag a window out as wide as I need it to get tabular material laid out properly is deal killer.

    I agree. Unfortunately, this is becoming increasingly common, and not only in web design. I see it in sloppily constructed Excel files that I get from clients.

    The emphasis on readability as a justification for changing a default seems to focus on text. The issue of graphics (e.g., captions) and tables (e.g., resizing) seems to be addressed mostly by Oppose votes. It would be good to see Support votes address this -- maybe a lot of those users/editors work primarily with running text? Martindo (talk) 00:41, 25 September 2022 (UTC)[reply]

    Wikis are a text-dominant format the world over (despite polled user desire to see more graphics, and despite previous efforts that petered out due to movement of resources at the Foundation). I don't think it's unreasonable to approach the discussion dominantly from that perspective, in any sense whatsoever.

    Regarding actual file display ("images"), we have MediaViewer and the community rejected that implementation of being able to see larger images, so I honestly don't think it's relevant to discuss that as a particular point (and users today still have the normal fallback of clicking through to an image description page). As I've said somewhere else on this page, having a fixed width actually makes it easier to deal with questions of placement of images, even in cases where the issues we have today on some pages simply do not disappear by adding the fixed width.

    Speaking of MediaViewer, the new implementation of video does something quite similar, and while there was some complaint when that was rolled out, it wasn't the same amount or degree. So I don't think that's a serious concern either.

    Regarding tables, I'll probably be leaving a comment later today or earlier tomorrow specifically about tables in my !vote. Izno (talk) 01:02, 25 September 2022 (UTC)[reply]

    At present part of your reply reads:

    the community rejected that implementation of being able to see larger images

    but I noticed that your initial posted version mentioned something like

    "WMF redirected resources".

    Could you briefly summarize that redirection process and decision-making?

    The reason it's relevant to include discussion of graphics is that several Oppose votes are referring to errant display of graphics due to shifting of text to accommodate the forced line width.

    I hear you that the currently proposed change in skin is based on majority preference for text which is the vast majority of content. But let's say that's a 60% preference times 80% usage stat. That makes 48%. Then if you include other factors noted by Oppose votes, you're chipping the approval further away from a majority.

    Meanwhile the pie graph shows "like" running in third place behind plurality "dislike", followed by "neutral". So, depending on which aspect of the change you're addressing, you're not even starting with 60%.

    I don't think anyone is questioning the good will of the developers. The skepticism/dissent/dissatisfaction is rooted in the incompleteness of the proposed change plus the pushiness of making it a default. Martindo (talk) 01:38, 25 September 2022 (UTC)[reply]

    Could you briefly summarize that redirection process and decision-making? Not in any detail; it's just a known fact that WMF has stood up a Multimedia team a few times to improve graphs, maps, images, and the like, and then the people have been reorganized into other groups for one reason or another (when the world wants more of it). In any case, this is separate to MediaViewer having been rejected by English Wikipedia (here's some discussions on it).

    The reason it's relevant to include discussion of graphics is that several Oppose votes are referring to errant display of graphics due to shifting of text to accommodate the forced line width. Yes, I'm aware. As I have already said, the vast majority of pages are improved in regard to issues like MOS:SANDWICH because of the fixed width, for the average use of thumbnail images.

    Your percentages mostly look like bad statistics so much that the general point you might be trying to make is lost.

    As for pushiness of making something a default, consider how nobody cares that Vector is the default skin, but back in 2010 when it was released the wiki had a cow about it. WMF didn't ask to make the change. Everything was back to normal within a year; people who thought Monobook was superior set their preferences for that, and the vast majority of users otherwise use Vector these days. Izno (talk) 02:06, 25 September 2022 (UTC)[reply]

    OK, I've been running with Gadget-wide-vector-2022 for a couple of days. It has made it possible for me to work, but I can see that there's still a lot that needs to get fixed in the skin before it's ready for prime time. I opened 3 bugs yesterday (T318600 • T318633 • T318568). Two of them are annoying, the third (T318600) is a show-stopper for me. But beyond that, the fact that I could find 3 bugs worth opening tickets for (plus a couple of other things I mentioned on this page but didn't open tickets for) in a single day indicates to me that this is beta quality. And until the core dev team agrees to own a full-width solution (so we don't need to depend on a community supported add-on), this is still a hard fail for me. -- RoySmith (talk) 14:14, 27 September 2022 (UTC)[reply]

54. Oppose - new vector just looks like a cheap knock-off similar to many of the mirror sites. There are probably minor improvements that should be made while maintaining/improving the brand, but this effort should be scrapped. Star Garnet (talk) 15:42, 23 September 2022 (UTC)[reply]
55. Oppose. On a widescreen monitor the giant stripes of empty space are almost comical, it looks like missing ad banners that failed to load. But it's actually supposed to look like that. No thanks. Andrew Lenahan - Starblind 15:49, 23 September 2022 (UTC)[reply]
56. Oppose. Before I go into my reasons for opposing, I would like to thank the devs for bringing this to our attention. I still have bitter memories of the way the original Vector was introduced. At the time I still used the old "Classic" skin, and we had little notice about its demise until it was presented as a fait accompli. When I complained about the lack of notice, I was told it had been discussed in full on Gerrit, which the vast majority of users have probably never used.[3] I'm glad that WMF have learned their lesson from that debacle. (As an aside, I still mimic elements from the old classic skin in my personal css/js - e.g. the warmer yellow background colours and the ability to display categories at the top of the page.) With this in mind, I can only oppose, unless the devs/WMF can guarantee that support for all other skins will continue indefinitely for those who choose not to use this skin. SO far support for other skins does not seem to be mentioned anywhere. — Voice of Clam 15:58, 23 September 2022 (UTC)[reply]
57. Oppose. Waste of screen "real estate". Lokys dar Vienas (talk) 16:21, 23 September 2022 (UTC)[reply]
58. Ain't broke, don't fix it. * Pppery * _{it has begun...} 16:58, 23 September 2022 (UTC)[reply]

    Except the current Vector kind of is. Vector 2010 is barely usable on mobile, whereas the current solution with Mobile Front End is even worse since not all features available on desktop are available on mobile. Nevermind some of these features may break with the low RAM mobile devices have, but unifying the experience between mobile and desktop is an important step. The redesigned Vector 2022 is less broke, or two steps forward, one step back. It still is not responsive redesign, but it is a significant step towards getting there. On the other hand, I agree that it feels like there is a lot of wasted space in the margins, even more so than Timeless. Aasim - Herrscher of Wikis ❄️ 20:02, 23 September 2022 (UTC)[reply]

59. Oppose. In Firefox, for example, there are several issues: the left panel is blown out compared to slick current one, the contents are shown lower so one has to scroll down to navigate, tools like sandbox and preferences are hidden in the user menu (requiring extra click) instead of handy display at the top right. To sum up: no clear advantage, instead produces accessibility issues among accustomed editors. As such, should not be forced as default but remain in user preferences for those who want it. Brandmeister^talk 17:18, 23 September 2022 (UTC)[reply]
60. Oppose until the fixed-width, white-space problem is fixed. Everything else looks great, and I like many of the changes, but I find this makes readability worse for me. If we want to allow a preference to allow users to shrink their usable space by choice, as an opt-in, that's fine. And literally every other change looks great. But this is a deal breaker for me. --Jayron32 17:20, 23 September 2022 (UTC)[reply]

    Like what they have with Fandom Desktop? Yeah, I think this is one area of improvement. Being able to expand the text past the margin is something I use on Fandom to reduce scrolling. Aasim - Herrscher of Wikis ❄️ 16:32, 24 September 2022 (UTC)[reply]

61. Oppose The WMF editors have cited Myth #28: White space is wasted space, apparently thinking that a solid block of white on one side of every single article somehow "reduce[s] the amount of text visitors see all at once", " guide[s] your eye from one point to another ... by the designer's intent", "creating the feeling of sophistication and elegance" "essential for a balanced, harmonious layout". I might quote sections of WP:SYNTH at this, were I chastising an errant content creator. ~~ AirshipJungleman29 (talk) 17:29, 23 September 2022 (UTC)[reply]
62. Oppose When last I looked into this issue there was no way for an unregistered user to opt out of the fixed width format. If there were such an opt out, I might be willing to change my opinion. 68.189.242.116 (talk) 17:51, 23 September 2022 (UTC)[reply]
63. Oppose. I'll begin by saying that I spent some significant time reading all the pro and con arguments here, and experimenting with implementing 2022 for myself and looking at a variety of pages. I'll also say that I appreciate the fact that the developers are making a sincere effort to engage with the wishes of the community. But. Like others here, the new version looks to me like it's using white space as a placeholder for advertisements. I don't like how the page title moves down the page as one scrolls down: readers already know perfectly well which article they have chosen to read, and it covers too much of the text that readers have actually come to. I've seen some Featured Articles where editors put a lot of effort into page layout in terms of where images are, and the new skin actually destroys that. (See, for example, the rose images at Sissinghurst Castle Garden.) I don't buy the arguments that the changes make it less cluttered; I actually had more difficulty finding things that I wanted to find, and all that white space doesn't help. It also felt like it was harder for me to read the text, with all the white space around it, like it was harder to keep my eyes on the text. I know that there is survey data, but I don't care if my own eyes tell me something different. Much better to leave the default as is, and treat this as something to opt into, until more issues are addressed. I don't like the idea of going ahead and making this a default to opt out of, while promising that things will get fixed as it goes along – fix it first, when there are issues that are clearly non-trivial. And, sad to say, WMF has had a history of not working closely enough with the experienced members of the community, and that justifies the community taking a strict approach to agreeing to implementation, rather than just trusting a higher authority. --Tryptofish (talk) 18:19, 23 September 2022 (UTC)[reply]

    Hey @Tryptofish, thanks for participating in this discussion. One clarification: the sticky header is only visible for logged-in people, and was added based on community feedback (link). We will soon be decreasing the height of it, so it will cover less of the article (link). AHollender (WMF) (talk) 18:42, 23 September 2022 (UTC)[reply]

64. Oppose Fixed width is unacceptable for all of the reasons outlined above. If you deploy this, it will be huge negative press for the WMF and the project, this is a clear loss of functionality and accessibility. The less wikipedia looks like every other unusable website on the internet, the better. Or are we going to have pop-up windows telling us to sign up for an email list and large bars taking up the bottom one-third of our screen next? This is an encyclopedia, not the Daily Mail or Reddit. - car chasm (talk) 18:26, 23 September 2022 (UTC)[reply]

    I haven’t made a final decision on how I’m going to vote yet, but I do want to say that I’m not totally sold that this’ll lead to bad press. It might actually lead to good press — it’s not that hard to find articles about WP’s design being outdated/bad. (Of course, it’s not like those websites are designed any better…) —pythoncoder (talk | contribs) 18:28, 25 September 2022 (UTC)[reply]

65. Oppose. Too wide for me I though I appreciate the effort that went into this. Perhaps if the width were adjustable… Skeet Shooter (talk) 18:33, 23 September 2022 (UTC)[reply]
66. Oppose I do find text-heavy articles in the 2022 version easier to read because of the reduced width, and having a fixed maximum width means that editors can lay out articles such that the viewing experience will be consistant across all desktop users, as opposed to now where something that looks good in one width might not in another. However, I've found that the fixed width is terrible on project and talk pages. Once you start taking away even more width with progressive indents in discussions, it gets very schrunced. I would support if fixed width were only deployed to the mainspace, but I oppose deploying fixed width anywhere else. The Squirrel Conspiracy (talk) 19:30, 23 September 2022 (UTC)[reply]
67. Oppose per width and link color concerns raised by multiple editors above, as well as the survey data highlighted by BilledMammal. The language changing element is attrocious. Overall, it is not clear to me in the least that this is an actual measurable improvement over, say, Timeless. Ljleppan (talk) 19:50, 23 September 2022 (UTC)[reply]
68. Oppose – same reason as User:Pppery: if it ain't broke, don't "fix" it. Put another way: don't force users to adopt a skin, etc. just because you think it's better – leave the choice to change up to users. Adovcate for it, don't impose it. --IJBall (contribs • talk) 19:51, 23 September 2022 (UTC)[reply]
69. Oppose the width issue is a deal breaker. —Locke Cole • t • c 19:57, 23 September 2022 (UTC)[reply]
70. Oppose
    You lost me with the new "User menu" which adds another level. This requires an extra click when I want to do something I often access – contributions. And it has an entry for uploaded media which takes me out of this project and into another (Commons). This seems oblivious to the fact that media can and is uploaded here and fair use media has to be uploaded here. So, this menu is designed for someone else's workflow, not mine.
    Another point is that I often mentor/assist/train new users and so it's complex and confusing if there are divergent interface choices. I still resent the media viewer interface which is so awful that I have to suppress it in my preferences but then have to help others for whom it is the default.
    Andrew🐉(talk) 20:22, 23 September 2022 (UTC)[reply]
71. Reluctantly Oppose until the skin update is decoupled from the width constraint. Fundamental page layout decisions (such as max width), which are currently made by a community of thousands of talented layout editors, should not be made at the skin level, though a skin feature can result from such decisions. If we do decide we want a default skin that breaks long-standing expectations of layout-designers, the process of skin-updating and -redesign needs to be made accessible to a larger community of skin editors. If we are updating our collective sense of how to support which sorts of readers, that should be its own focused project (and not conceived of or implemented as a simple skin update :) Further discussion below. – SJ + 21:26, 23 September 2022 (UTC)[reply]

    @Beccaynr: puts things excellently below. Please note that page width and margin whitespace are not the same as column width; many content-rich sites address this by finding ways to present and reflow multiple columns. We may be the longest-form website that has this challenge, and it is a worthy one (IHT used to do this in an interesting way, lost when their web team was subsumed into NYT). The current design however says both "Limiting column width is Important and we should break existing assumptions by fiat to fix it" and "You only get one column. Anything else is out of scope for a simple skin update." – SJ + 21:40, 23 September 2022 (UTC)[reply]

72. Oppose. The excessive width constraints and massive white space is nothing but a downgrade. Furthermore, I strongly oppose the use of "sticky" content on any webpage, and I oppose sticky headers in particular. The new skin is not without benefits, but these two issues are both dealbreakers. Thebiguglyalien (talk) 23:00, 23 September 2022 (UTC)[reply]

    Interesting. I kind of like the idea of the sticky headers. I spend a stupid amount of time on my phone scrooooooolllllling to the top of a big page to find the header links. -- RoySmith (talk) 23:24, 23 September 2022 (UTC)[reply]

    @RoySmith: You may be interested in the 'Make headers of tables display as long as the table is in view, i.e. "sticky"' gadget, which can be enabled for any skin in Special:Preferences#mw-prefsection-gadgets, subsection 'Testing and development'. Certes (talk) 07:40, 24 September 2022 (UTC)[reply]

    Thanks for the pointer, but that's table headers, no? I was thinking more of the page headers (Watchlist, Contributions, page history, etc). -- RoySmith (talk) 11:15, 24 September 2022 (UTC)[reply]

73. Oppose Everyone knows the saying "If it ain't broke, don't fix it" and seriously can't see anything wrong with the old skin. As for the new one, sure having the sticky table of contents is good (except for that added scroll bar when the table is too long) as makes it easier for navigating through the article, but overall the sidebar appears to take too much from the article space and this makes the article appear squished. The other thing I don't like it how the languages are displayed. It's much better to have them displayed on the side with the suggested languages appearing first rather than having all languages hidden away in this menu. Alin2808 (talk) 23:38, 23 September 2022 (UTC)[reply]
74. Definitely Oppose The design itself is completely unappealing, the current design, Vector (2010) is fine as is and the dead space is annoying. On top of that, I have questions including how is it going to look visually like on United States network television schedules, and if it’s gonna be forced on everyone logged in or not? Nostalgia Zone (talk) 00:04, 24 September 2022 (UTC)[reply]
75. Oppose with appreciation for the work put into this. Unfortunately, it's not an improvement overall per many of the comments above. I don't find the new format convenient or intuitive. The ToC is particularly inconvenient to the point of being rather annoying. -Ad Orientem (talk) 00:51, 24 September 2022 (UTC)[reply]
76. I oppose this as default due to the width limitation, which causes large amounts of empty space. Tol (talk | contribs) @ 03:26, 24 September 2022 (UTC)[reply]
77. Oppose but willing to reconsider should the width issue be fixed. The bars on both sides of the screen are my primary irritation. thorpewilliam (talk) 03:52, 24 September 2022 (UTC)[reply]

    I will also add the advantages the current default interface has both in terms of familiarity and accessibility. Its age and simplicity means it is accessible without issue even on older machines running unsupported operating systems & browsers and on poor internet connections. I don't know how Vector 2022 compares to this. thorpewilliam (talk) 03:54, 24 September 2022 (UTC)[reply]

78. If that's a definite change, then I oppose. In the meantime, maybe someone can explain to me why the SECOND most popular skin has been deemed best, as if it's a democratic decision (reminds me of some recent US elections). Martindo (talk) 03:54, 24 September 2022 (UTC)[reply]

    @Martindo: can you clarify for me—in the second sentence, which two skins are you referring to as most and second-most popular? — Bilorv (talk) 13:07, 24 September 2022 (UTC)[reply]

    @Bilorv I assume @Martindo is referring to this graph - File:Usage of non-default skins on English Wikipedia.png. From this graph, after Vector 2010 (the default), it seems like Monobook is the second most popular skin, with Vector 2022 coming in third (if I'm interpreting it right). ♠JCW555 (talk)♠ 16:29, 24 September 2022 (UTC)[reply]

    @JCW555: thanks! — Bilorv (talk) 16:44, 24 September 2022 (UTC)[reply]

    Yes. That was the pre-eminent pie graph in the RfC. Martindo (talk) 00:12, 25 September 2022 (UTC)[reply]

    Probably a function of time above all else. Monobook is 15+ years old while vector2022 is from, well, 2022. —pythoncoder (talk | contribs) 18:30, 25 September 2022 (UTC)[reply]

79. Oppose I appreciate the effort put forth by the WMF web team, but I'm not a fan of the new design. The excessive whitespace and shortened line widths are particularly deal-breakers for me, perhaps I would reconsider if the design is made more compact by default. InfiniteNexus (talk) 04:42, 24 September 2022 (UTC)[reply]
80. Oppose for the same reason as HumanBodyPiloter5. I do not approve of the hamburger menu in the context of desktop use, nor the obtusely labeled and unclear icons being chosen in favor of words. I also take issue with the amount of white space on the screen, and the concerns raised by others about the change potentially ruining the placement of images on pages arranged with Vector 2010 in mind. These are exceptionally poor choices for a desktop website; I do not like these "mobile first" kinds of design choices on reddit, I do not like it on Twitter, and I do not like it here. If you must, deploy Vector 2022 on mobile ONLY, but do not push it onto desktop users. ostensibly singular userpage (inquire within) 04:44, 24 September 2022 (UTC)[reply]
81. Oppose, I switched to the skin to try it and was met with massive whitespace to either side of the articles I tested it on; what is the point of that? Also the user menu at the top right, is replaced by icons that aren't clear what they are and some options hidden behind a two stage menu. I had a quick play with the new skin on mobile (where I always use desktop view as the mobile version is horrendous and has less functionality) and it is more usable there, though I don't know any way for a user to set two different skins depending on which device they are using. If it is possible to set Vector 2010 as the default for desktop and Vector 2022 for mobile I could possibly support that but a change to Vector 2022 for all just seems to penalise desktop users - Dumelow (talk) 07:35, 24 September 2022 (UTC)[reply]
82. Oppose My initial reaction was to dislike the narrow content area and large amounts of whitespace, but really liking the TOC in the sidebar. My assumption was that the narrow content area was going to work best at narrow screen widths, so I decided to try playing with window widths to see if that was the case, and came to conclusion that it is bad at all widths on desktop.

    • On a 1920x1080 screen, there are two levels of whitespace padding around the content, the inner layer (which is still treated as part of the actual site, including the TOC and user buttons) and an outer layer (which is pure padding, to enforce a particular screen width). In many of the responses, various other sites which use fixed-max-width layouts have been cited, but from my review of those sites, most of them do not use different colours for the outer layer of padding. From my perspective, showing this additional colour gives the impression that my monitor is unsupported by Wikipedia, so I'm being given the highest supported resolution, with the excess space left as whitespace. If the inner and outer padding both used the same colour, I think this would be less jarring.
    • Using half of a 1920x1080 screen, the TOC is conveniently collapsed, but now the useful sticky headers (the article title, search button, user links) all require scrolling back to the top of the page again. I'm not sure why all of those helpful features are removed when on a narrower screen.
    • Stretching the screen gradually, at about 1000px the TOC returns. However, it also brings with it a horizontal scrollbar, but the only thing it is scrolling is whitespace to the right of the page's content area. (This is presumably just a bug, but is immediately irritating when playing around with splitscreen.) This width also emphasizes just how much whitespace the TOC is adding: At least at larger widths, the TOC having a big gap between its right side and the article body can be hand-waved as filling space around the fixed-width content area. But at the absolute minimum width I can use and still have a TOC, there's about 40px of space between the TOC's scrollbar and the article body (and normally there won't be a scrollbar on the TOC, so the space is usually going to be even larger than that). And that's not even discussing that the TOC isn't using the full vertical space available to it either.
    • Between about 1350px and 1600px, increasing the window width only increases the whitespace on the right side of the page until it is about the same as the width of the left sidebar. What this means is that around 1550px, you get a big left sidebar and big right-hand whitespace, but the two are uneven—it looks like the page is trying to balance the left and right whitespace, but is failing to. The first screen I opened the new layout on was within this range, and the assymmetry is really distracting. Up until the 1350px point, there's a small amount of whitespace padding on the right side, but it just feels like a natural page margin. Within this 1350-1600px range is IMO the worst experience of any screen width.

    Additionally, I find the menu buttons really unintiutive: The ☰ button opens the old sidebar, which pushes the TOC so far down the page it's entirely off the screen, making it seem like it has entirely replaced the TOC. Then the button to close the menu is «, implying the menu should close to the left when it actually closes upwards (although there is no animation for opening or closing it at all, not that there needs to be). The button also vanishes when you start scrolling down the page, reducing its benefit as a navigation tool (not that the current skin does this much better though, where the sidebar is just whitespace anywhere past the start of an article). Also, the "hide" button just makes the TOC disappear entirely—I would expect the re-expand button to be located in the same place as the "hide" button. Unless you happen to spot the new TOC appear next to the article title, it's very easy to press this button and not know how to restore it. And because this new skin is relying so heavily on symbolic representations over words, even if you do spot the button, it's not at all obvious that it corresponds to where the TOC has gone.

    Honestly, the entire menu is somewhat of a relic of the old layout. However, at least when it's there persistently there, it feels like it's just part of the site layout and so contains mostly global navigation buttons. When it's buried under a collapsible menu, and opening it displaces page content rather than loading over it, it feels like it should be specific to the current page, but the majority of the links are still just sitewide links (although there are still a few page-specific ones mixed in there, such as WhatLinksHere and the print/export buttons). I believe I saw elsewhere on this page that there are ongoing discussions about changing the content of that menu, but at least in the current form of the menu, it's problems are only emphasizes when hidden under an expandable menu.

    Overall, I really want to like this new design. It's trying to make better use of the sidebar, and stickying useful features like the search button and TOC. It seems to be trying to mimic many other websites by narrowing the content area, but unlike those sites it has nothing to put in the new space it has created on the left and right sides of the page (other sites typically use this for ads or promoting other pages on the site), making Wikipedia pages feel really squashed and full of wasted space, rather than having healthy margins that provide breathing room. --SnorlaxMonster 10:25, 24 September 2022 (UTC)[reply]

83. Oppose for now. I like how sleek the new interface looks and the back to top button is a really good addition, but there are a few dealbreakers that mean I wouldn't want this to become the default at the moment. I find the narrowness of the page, and especially the editing box, really annoying - having to scroll even more when editing is super time-consuming and just means I won't want to edit so much when I don't have a mouse with me. The other one, which is even more of a dealbreaker than the first, is a few quirks of the new TOC style; although I really like how it follows you down the page, not having it available when you're reading the lead paragraph is frustrating when you're trying to quickly navigate through the page. The other issue is that subsections are pre-collapsed on the TOC sidebar and effectively invisible, which I'm really not a fan of. I won't have a problem supporting this if/when it comes back in the future and takes the things in this discussion onboard. Gazamp (talk) 13:30, 24 September 2022 (UTC)[reply]
84. Oppose makes you feel cramped. --बडा काजी (talk) 14:09, 24 September 2022 (UTC)[reply]
85. Oppose. I strongly dislike the over-reliance on abstract symbols over words for various basic functions. That's particularly unfriendly for new and unregistered users. Nsk92 (talk) 14:14, 24 September 2022 (UTC)[reply]
86. Oppose. Not yet. Too much work left to be done, not customizable enough out-of-the-box, reduces branding (if, for example, a screenshot of an article is shown on TV it's much harder to recognize it's from Wikipedia) and having my contributions and talk page links hidden in a sub-menu greatly annoys me (phab:T302641), actually it bugged me enough to switch back to Vector classic. — Alexis Jazz (talk or ping me) 16:15, 24 September 2022 (UTC)[reply]
87. Oppose The fixed width is ugly as sin, massive wasted whitespace, and the floating elements look annoying as heck. --SilverTiger12 (talk) 17:01, 24 September 2022 (UTC)[reply]
88. Over my dead body. Even on the example page, there was one major glaring usability issue. Namely, that if (god forbid) my mouse cursor happens to be on the left side of the screen, then scrolling the article with my mouse wheel will stop working once the sticky TOC moves into that spot, because it will want to scroll the TOC instead of the article. Beyond that, not having clearly marked tabs at the top of the article is confusing, especially from an editing standpoint. Not having a clear shading difference between article and non-article is also mystyfingly poor design. Keeping the search bar persistent at the top is also horrible. The amount of time I need to search is very small compared to the time I spend reading an article. When I do want to, I can just press one damn key on my keyboard (which I'd have to switch to anyway to actually execute a search) to get the article back to the top. As is, it just takes up valuable screen real estate which is already cramped by tabs, an address bar, a task bar, etc etc. This is especially important for those of us on small displays. All in all, these changes are almost all negatives. And worst of all, if this goes forward, I'll be stuck with them, with as far as I can tell, no ability to change them without the hassle of making an account and figuring out how to change stuff (what can be changed at least). I might soften my stance a bit if there was some way to revert to the current skin and have that choice be remembered in a cookie. 35.139.154.158 (talk) 17:24, 24 September 2022 (UTC)[reply]

    Just wanted to reply to the last part: you can change the skin by going to Preferences -> Appearance and there you can select the skin. Though you need an account for that. Alin2808 (talk) 17:57, 24 September 2022 (UTC)[reply]

    We're living in a world where people are overwhelmed by a simple GDPR notice/checklist. I personally can't be bothered to log in on every device where I use Wikipedia. It's a waste of time and mental effort when I'm not going to be doing any editing, and a possible security risk on public Wi-Fi. We can't pretend the settings are accessible to everyone when the user would have to go through all the steps of creating an account and logging in to use them. That would be a dark pattern. Daß Wölf 18:28, 24 September 2022 (UTC)[reply]

89. Oppose: While I do like the sticky bar at the top, that's about it. Complaints: (1) The purple color for Wikilinks once they've been clicked is much too light and, thus, difficult to see. (2) The Table of Contents sidebar, which not a bad idea in itself, is taking up too much space; moreover, because it too is white, it just bleeds into the article space; at a minimum, a vertical line is needed, and I wouldn't say no to the lightest of grays as a background color. (3) I like the idea of a fixed width, because I think content should look the same across all users; however, this design opts for too narrow of a width, thereby creating far too much unused white space on the right. ~ Silence of Järvenpää 22:37, 24 September 2022 (UTC)[reply]
90. Strong Oppose: I've seen Reidgreg and another user mention that it doesn't work on their browser. The new Table of Contents does not correctly collapse on Goanna browsers like Pale Moon, Basilisk, and Serpent. The collapsible Table of Contents "Brown Bear" demo will actually hide and corrupt the article text on any version of Internet Explorer. The last version of Firefox to support SSE was 45 and it simply does not display the ToC. ArcticFox for older Macs also does not display the ToC. Mypal for Windows XP does not display it. Webpages can be built as documents; the web started as a way to connect hypertext documents. The new ToC is cool, on a new computer, but it converts a simple list structure into an application which ensures that users on older systems will not be able to access Wikipedia, or be able access it as fully.Rjjiii (talk) 00:09, 25 September 2022 (UTC)[reply]

    MediaWiki has a support matrix for minimum compability, below which it is simply infeasible to test and support the long tail of users who decide to use an uncommon or old browser. The vast majority of those browsers listed are probably not above the minimum thresholds, where thresholds are defined.... (I recognize several of those browsers as being rare in use. :)

    If you think any of the browsers that you tried should be within the realm of browsers lying somewhere between A and C, you're welcome to request a change and they may work on the problem as it may indicate a problem in the same version of their upstream rendering systems. (If you're smart enough to try ad hoc arbitrary browsers, I assume you can hunt down the bug in a major browser, which I assume would guess would increase the likelihood of WMF working on that issue.)

    If you can reach the website in XP, I would be both surprised and dismayed. Surprised because the ciphers WMF supports in HTTPS do not generally support XP, and dismayed because you're using an ancient insecure OS that has been out of support nearly a decade. Izno (talk) 01:47, 25 September 2022 (UTC)[reply]

    Exclusion of long-tail is an example of what I called "chipping away at the majority" in my comment on Oppose 54. It should be done sparingly, otherwise it's just a convenient excuse for reducing the denominator of the population being surveyed, thereby increasing the % represented by the numerator of potential supporters. Martindo (talk) 02:31, 25 September 2022 (UTC)[reply]

    I should clarify: in posting about Oppose 54, I suggested that assuming a majority prefer the new text constraints, there are other factors that some of those Support votes might be unhappy with. If the other factors are deemed less significant (or even long-tail), then the actual majority supporting the overall skin would be chipped away.

    In regard to Rjjiii's comment, you're chipping away at the denominator in order to bolster the numerator. Martindo (talk) 02:36, 25 September 2022 (UTC)[reply]

    I am not personally attempting to chip away at some majority, simply explaining the expectations associated with development of this particular top 15 website. Izno (talk) 04:02, 25 September 2022 (UTC)[reply]

    Usage share of operating systems#Desktop and laptop computers - In the United States usage of Windows XP has dropped to 0.38% (of all Windows versions), and its global average to 0.59%, while in Africa it is still at 2.71%, and it still has double-digit share in at least one country. These are readers that we need to consider. BilledMammal (talk) 02:56, 25 September 2022 (UTC)[reply]

    Technical question related to global outreach:

    Page History software is superb in presenting a comparison of changes. If I upload an edit and get a message about "not current version" because another editor has (almost) simultaneously uploaded a different edit, does that mean the content I'm trying to upload is actually the full page (including graphics, which can eat up bandwidth)?

    If so, then design that claims to be "worldwide" or "universal" in usability really needs to look at reliable internet speed stats in less technologically developed countries -- upload speed as well as download.

    Has WMF ever surveyed a large number of countries in this regard by using a standardized speed test site? Martindo (talk) 03:27, 25 September 2022 (UTC)[reply]

    WMF performance work is an ongoing activity that does assess low-speed delivery, but I do not know how routine or systematic the specific activity is of looking at low speed delivery. I do not know what G they test to regularly these days; most recently I can remember 3G tests but I have seen older discussion about 2G tests. This has in fact motivated multiple parts of the mobile and desktop websites. On mobile, I believe the way it works is that we deliver collapsed sections which then load the content on demand. On both, most JavaScript is delivered at the bottom of the page, which motivates quicker loading of the main content. More recently, browser support has motivated lazy loading of images as well. Izno (talk) 04:13, 25 September 2022 (UTC)[reply]

    That's nice? ... the ciphers WMF supports in HTTPS do not generally support XP ... remains a true statement. I can tell you why if you want to know -- they are not secure and supporting them makes all readers less secure. Saying "lots of people in this one place on a map" (and believe me, I've said similar about IE particularly -- how its use displays seasonality correlating to the northern hemisphere school year) doesn't really mean much in this discussion about a long-settled part of development of MediaWiki. Izno (talk) 04:00, 25 September 2022 (UTC)[reply]

    Rjjiii's comment suggests that it is still possible to connect via XP, despite HTTPS issues. @SGrabarczuk (WMF) and OVasileva (WMF): - do you track broad user statistics, such as what browser and OS readers are accessing the site through? If you do, can you provide those figures? BilledMammal (talk) 13:35, 25 September 2022 (UTC)[reply]

    You are looking for Dashiki User Agent Breakdowns. Izno (talk) 16:37, 25 September 2022 (UTC)[reply]

    Let me clarify my post a bit. First, yes it's possible to access Wikipedia with a variety of older systems right now. I view this as a strength of the platform. Second, my issue is not a personal concern. I have access to the latest versions of both Chromium and Firefox on current versions of Windows and Debian. My main concern is for people that have not decided to stick with old computers, but are stuck with old computers. And to a lesser extent accelerating the obsolescence of existing machines and shifting the web further towards a blink-first design. If this does become the default theme, I may create bug reports. However, this issue goes deeper than testing for a specific browser in the long tail. I agree that past a certain point it becomes "infeasible to test" for every browser. This is the reason I am opposed to the more interactive ToC. It is not necessary to test the ToC that the current theme uses because it relies long-established standards.Rjjiii (talk) 03:53, 25 September 2022 (UTC)[reply]

    my issue is not a personal concern As you might be able to tell, I didn't think it was. Which definitely makes it a "I'm going to try to represent some unknown and faceless group". Which is fine, thanks for bringing up the issues, but I don't think it should motivate a strong oppose.

    My main concern is for people that have not decided to stick with old computers, but are stuck with old computers. At the end of the day, the world moves on. Many of the evergreen browsers are able to run even on quite some old machines (my current PC is going on 9 years old -- it was made around the time that Firefox 26 was releasing), and I'm planning soon to resurrect one from 2008 with a copy of Linux and a new hard drive (as soon as I get off my butt to do something that I should have learned a long time ago ;). I find it hard to believe in this day and age that "I'm stuck on an old machine and can't do anything to upgrade" should motivate a strong oppose either. Especially for a non-critical item in the UI -- sure, it is useful to get around the page, but it's not the content at the end of the day.

    One of the ways the WMF can handle this situation, should the WMF decide it is indeed not feasible to support a particular browser/version, is to cut off JavaScript delivery. I have not personally tested that end state, so that might make for some questions also in those browsers. Even grade C is not "pixel-perfect" display, it's "can I use the website", and while a TOC is useful, I do not think it is a required element of display. (Mind you, I would much prefer it to fail gracefully in the absence of JavaScript.) Izno (talk) 04:36, 25 September 2022 (UTC)[reply]

91. Oppose: This wouldn't be the first time a first website introduced a redesign which added a bunch of whitespace for no good reason, and it's just as annoying now as it was all the other times I've seen it happen. The fact that Vector 2022 isn't even beating Monobook in terms of usage really doesn't inspire confidence. I like the idea of the TOC in the sidebar, but I would never trade away the links to other languages for that. There was another comment in this RFC which mentioned something to the effect that Vector 2022 feels like a Wikipedia-rip-off, and it really does feel like that. The nice new white space feels like the perfect place to sneak in some ads. Heck, they might already be there for all I know, and they're just not visible because of my ad-blocker. Telaneo (User talk page) 02:52, 25 September 2022 (UTC)[reply]
92. Strong Oppose: The default fixed-width; the way large/wide images, charts and tables break because of it; the way even small images result in the text swerving through them in an unreadable manner (including in the linked Pluto article, a FA); the use of icons instead of clear text; the ridiculous amount of whitespace (why is there a big blank under the Wikipedia logo?); the weird spacing of the topicon/title/heading elements; the way the actual content is confined to a small amount of screenspace, bringing to mind every other cheap and ad-infested mobile-esque website... and no, "install a gadget" isn't a solution when we're discussing a 'default' skin and the vast majority of casual users won't be doing that. I'm also alarmed at the way this RFC was originally worded as "deploy now or later" and the near-badgering response to some of these oppose votes, but that's not related to my concerns about the skin itself. Blue Edits (talk) 12:18, 25 September 2022 (UTC)[reply]
93. Oppose: My laptop is 1280px wide and the page looks out of ratio especially near the lead; the left sidebar is too wide, making the lead text between it and the infobox feel narrower than normal. Also, I have not been a fan of not very accessible websites using icons in place of text in the main menu; I would prefer the texts "Talk", "History", and "Watchlist" displayed on the top menu navigation bar. I also tried clicking the "Pluto" text in the header thinking it was the search bar (since the search icon was beside it; the line divider to the search icon's right appears like a search input field, making "Pluto" appear like a search placeholder). The left sidebar table of contents should have section numbers in it to distinguish if a section name is wrapped or not; I do not know if a wide section name affects the width of the left sidebar or if nowrap is used. –Sanglahi86 (talk) 13:37, 25 September 2022 (UTC)[reply]
94. Oppose: Absolutely not. I'm not sure what the rush is to a new skin; if it ain't broke, don't fix it. So many websites nowadays are in such a frenzy to do this, essentially screwing over the user in the process. Totally unnecessary Terrible sizing and proportionality throughout. I hope this skin never gets approved. Oppose with all my heart. That Coptic Guy 14:30, 25 September 2022 (UTC)[reply]
95. Strong Oppose: The redesign looks so bad that when I switched, I assumed I'd done something wrong. It seems like a clear step backwards, especially the fixed width. Keep this in the lab until it can be improved. GoPats (talk) 14:58, 25 September 2022 (UTC)[reply]
96. Oppose: A) White space is a waste of space. You already know that the white space can be used for lots of items (links to other items around Wikipedia for instance) instead of hidden. It's redundant to leave parts of a page unused. B) Putting the navigation bar in a dropdown menu is also redudant. The amount of space the navigation bar take on the page is minimal. No need to hide it. C) Depending on what you have your screen set to, it can look wonky. It should look the same on each. D) Where the content is, it look a mobile browser version. If I wanted a mobile browser version, I would just use my phone. E) Picture heavy articles can make text even more squished. Also, articles is a lot of different categories and with a lot of references, make those sections even longer. Even if you adjust the reference list to different sizes, it might not help. Final: Reverting to Monobook would be better than Vector 2022. Instead of various tweaks and updates to legeacy Vector to freshen it up, you made a completely different one that is terrible. That is why I will never use Vector 2022. Mr. C.C.^{Hey yo!}_{I didn't do it!} 17:14, 25 September 2022 (UTC)[reply]
97. Oppose May elaborate later Helloheart (talk) 19:26, 25 September 2022 (UTC)[reply]
98. Oppose I prefer what we have right now. Also, I don't like the fixed width and the loss of ability to check contributions with one click. LEPRICAVARK (talk) 21:08, 25 September 2022 (UTC)[reply]
99. Oppose. I go to the French WP a bunch to find material to translate, and I can't stand the way it looks over there. (I wouldn't put too much stock in that 87% statistic. I don't go to the ancillary pages over there, just the articles, so I didn't realize it was something you could turn off. I just thought the community over there had very different aesthetic tastes and that's what they wanted. I just went and turned it off now that I know you can.) When checking related articles to see if they have English counterparts, it is so much more convenient to do that at Italian WP, which has a very similar layout to ours where the other languages are on the side instead of having to use a drop-down, and having to scroll down a list if it's not listed in the first 5 of 6. Egsan Bacon (talk) 21:29, 25 September 2022 (UTC)[reply]
100. Oppose I prefer the current skin. I've read through the pros and cons above and I'm not convinced that the 2022 skin is overall any improvement. Leaving this aside, from an aesthetic POV, the 2022 one looks almost cartoonish. I also find it more difficult to use in general to find what I need. I understand that some things are better, but overall definitely don't support replacing the current one. As others have said, if it ain't broke don't touch. Takerlamar (talk) 00:22, 26 September 2022 (UTC)[reply]
101. Oppose I published several workarounds to let anonymous users use the old Vector and they just kept breaking them and removing what I posted on Mediawiki. Vectorman007 (talk) 00:27, 26 September 2022 (UTC)[reply]

     I don't understand what you mean -- can you link to workarounds and how they are breaking? – SJ + 15:47, 27 September 2022 (UTC)[reply]

102. Oppose Per all above. TrangaBellam (talk) 08:46, 26 September 2022 (UTC)[reply]
103. Oppose I'm still using the Vector 2022 skin and I don't think it's that bad (I appreciate having the search bar close and having the suggestions show the short description as well) but I agree with those that the limited page width (and excess white space) is not good. Vector 2022 looks ok on my Surface Pro 7 but it does not on a 1920 x 1080 screen. I've been using Vector 2022 with a toggle option to extend the width -Gouleg🛋️ ^harass/_hound 13:22, 26 September 2022 (UTC)[reply]
104. It's not broke, so don't fix it. PS - Why are editors putting 'Support, Oppose, Neutral' in their posts? You're already under the sub-sections of those positions. GoodDay (talk) 13:52, 26 September 2022 (UTC)[reply]
105. Oppose although I personally use the 2022 vector skin, I feel that the 2010 skin is still better than this one as the 2022 one still needs a few improvements, for starters the width limit, and I don’t think we have received any complaints about the 2010 one. The change would receive significant backlash but even if we don’t consider that, the 2022 one still has a bit of work to be done if we are to make this the default skin.  Hamza Ali Shah  ^Talk 17:38, 26 September 2022 (UTC)[reply]
106. Oppose (for now) Entirely too much unnecessary dead space. The devs combined buttons and options into drop-down boxes (presumably to save space and not look so cluttered), but didn't do anything with the extra space. Keep the WP logo the same size. I do like the sticky banner though. I do appreciate the time and effort the devs took into trying to better the project, though. If nothing else, remove the empty space. Cheers! It's me... Sallicio! 18:18, 26 September 2022 (UTC)[reply]
107. Oppose Way too much wasted space, especially in desktop view on mobile in which I sometimes edit. Table of contents to the side is kinda neat, but I think articles actually benefit from a bit of a gap after the lead, as it prevents the reader from being inundated with too much information on one screen, and the ToC headings primes the reader as to what they should expect from the article. I instead support a "reader view" feature in Legacy mode that reduces the width of the body paragraphs to something like A2-sized paper. DigitalIceAge (talk) 18:52, 26 September 2022 (UTC)[reply]
108. Oppose The problems are already pointed out, so just three comments: (1) Replacing flat text menu with hierarchical icons reduces usability among some groups - and thus the accessibility. All our readers naturally can read text, yet they might not have the skills to figure out the mysterious graphic symbols. Did anyone try to test the new layout on an 80-year old? (2) The idea that the text needs to be narrower (and its justifications) is quite strange: if all one needs is a 13-inch monitor, there would be no market for large monitors. I typically work on 40-50 inch screens, and I fail to understand the benefits of wasting by default almost all of this expensive screen space. Whoever uses a large monitor, definitely is able to reduce the window size (note that this approach, unlike the 2022 version, will not waste the space inside the window). (3) The modern phones now had reached the point that allows switching to the (2010) desktop version. The update seems to go backwards, degrading the desktop experience to match the old, non-foldable smartphones. --Викидим (talk) 21:22, 26 September 2022 (UTC)[reply]
109. Oppose Too much wasted space, especially in the top menu. With the new skin I need to click several times to get to any useful page such as my own talk page. This just reduced the usability. Contrary to most other opinions, I do think that the limited width in article space is an improvement, however this should be kept as an opt-in option. Apart from this, I think all other changes are a step backward. The skin does not offer anything really new, and make existing things harder to reach/navigate. Too bad, since the current skin really needs a redesign and this is really a missed opportunity. --Ita140188 (talk) 21:51, 26 September 2022 (UTC)[reply]
110. Oppose The 2022 skin makes the desktop experience look like mobile. The lack of any borders around the article makes it look like an unfinished prototype. Vector Legacy is already fairly minimalistic, but there is no obvious benefit from making it even more minimalist to the point half the screen is blank. It looks far better on mobile, but that just demonstrates that desktop was almost totally ignored. ᴢxᴄᴠʙɴᴍ (ᴛ) 22:41, 26 September 2022 (UTC)[reply]
111. Oppose unless there is an easy toggle for the wide-vector gadget for all users. The amount of white space on the left side of the page to the left of the side bar, within the side bar, on the left between the side bar and text, and on the right is ridiculous. The general design changes are good, but we should not be following this awful trend of bringing mobile to desktop with huge unnecessary spaces between elements. Having worked on many pages with tables and other non-paragraph formatting (WP:FL), it's unacceptable how this forces table cells and columns to be narrower, screwing up the spacing within the tables and around images. Reywas92^Talk 23:29, 26 September 2022 (UTC)[reply]
112. Oppose anything with that unhelpful and cumbersome hiding of both the talk page and one's own contributions button under an extra click. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 06:09, 27 September 2022 (UTC)[reply]
113. Oppose. The fixed width is a major issue for me. With it turned off through custom CSS, I do like it on some screens, but the fixed with is something I don't think I will ever get used to. There are other minor issues I have with the design like the icons up top, but I think these can probably be ironed out. JackWilfred (talk) 10:53, 27 September 2022 (UTC)[reply]
114. Oppose I have used Vector 2022 skins on other sister projects, and as soon as I saw the whitespaces on both sides of my ultrawide screen monitor (32'), I immediately went back to Monobook. I don't think it's benefical at this stage to roll it out to the masses until they reduce the whitespace. OhanaUnited^{Talk page} 14:18, 27 September 2022 (UTC)[reply]
115. Oppose. The reasons for change are unconvincing, and the whitespace and hiding key features make this a poor alternative. StAnselm (talk) 15:50, 27 September 2022 (UTC)[reply]

Neutral

1. I've been using Vector 2022 for several months and have been providing extensive feedback to the developers here, at MediaWiki, and via the office hour video calls. The developers (represented to us by Olga and Szymon) have been very open in explaining their rationales behind the changes they'd like to make, and I think that the skin at this point is a clear improvement over legacy Vector. It's also still clearly a work in progress, with areas for improvement I'll enumerate, and I think if those are addressed before it's deployed, it'll have a more positive reception with both readers and editors. That makes me neutral about current deployment. Pushing me toward a strategic support are the many disappointing knee-jerk opposes above, and pushing me toward strategic opposition is the desire to have some leverage to guide future development, so together they land me back at neutral.
   First, to address the screen-width opposition, I think this discussion would look radically different if everyone was required to use Vector 2022 for a month before !voting. Design changes take some getting used to, and I had an adjustment period myself, but at this point I find the new width to look perfectly natural. The developers have presented substantial evidence that the consensus among usability professionals is to use a narrower screen width, and although there are some attempts to discredit that evidence by Beccaynr et al, I have not seen anyone presenting usability research explicitly favoring a wider width, as I would expect were the research truly disputed.
   Moving on to other issues, moving the article tools to the article toolbar (phab T302073) is a major factor in getting me comfortable with the table of contents occupying the location traditionally used by the left sidebar. The developers are working actively on this, but I'm still a little surprised they didn't resolve it before launching this RfC, as I recommended. There doesn't seem to be too much opposition based on this so far here, but I'd speculate that that may just be because it's getting drowned out by the screen width concerns, and that focus might shift to it in a future version RfC if it's not resolved.
   For the sticky header (phab T283505), I'd like to see additional thought put into which elements are included or excluded. An element that would be useful for me as an editor — my alerts/notices — is not included, whereas another that I suspect is not particularly useful to either readers or editors — the language switcher — is included (although, oddly, only for logged in users at the moment). I don't see a normal use case for why someone would want to switch to another language after they've started scrolling, and I certainly don't see it being such a popular feature as to justify having it be the only element of the header that gets text (e.g. 47 langauges) rather than just the icon.
   My last concern relates to page status indicators, including protection status icons and the FA star/GA plus circle. By commandeering the upper right corner for the language switcher, the new skin pushes the indicator icons down a row, and by moving the page tabs line below the page title line, it pushes them down still further. The developers have explicitly touted how the additional prominence of the language switcher is desirable, but when we have raised concerns about the diminished prominence of the indicator icons, they have declared it outside of the initial scope of the project. That doesn't jive — if you're going to move elements around to reprioritize them, you can't only consider a subset of the elements. Protection icons don't need to be particularly prominent, but they should probably be moved next to the edit button (or integrated with it, as in the pencil-and-lock icon used in the mobile skin) because it's most applicable to those considering editing a page. The GA/FA icons do need to be prominent, because they ought to be a key indicator to readers about the quality of an article, yet currently most readers don't know they exist, and diminishing their prominence by moving them to the developer's chosen position will only make that worse. Given current challenges in the misinformation landscape, emphasizing tools to help readers assess an article's trustworthiness should be (and is on paper) of paramount concern to the WMF, which makes the lack of attention to this issue particularly frustrating. Moving the GA/FA icons directly next to the article title instead of pushing them down would be a better alternative, and there are probably other available solutions I'm not creative enough to envision. This is the issue that the developers seem least interested in addressing — they have committed only to fixing the coordinates display (phab T281974), which is a separate issue (and I'm leaning toward not having them per Xaosflux because they're not fundamentally a page status indicator and thus don't belong outside the normal content area, so I consider that fix less essential anyways). Therefore, I encourage the community to speak up more about the importance of this.
   Overall, if these issues are addressed, it'll move me from my current lukewarm stance to enthusiastic support. In general, I feel that the foundation is often overly cautious in rolling out changes, preferring the slow perfect to the rapid good, but given the particular sensitivity of design changes, it's worth taking the additional time to put the best possible foot forward. Ultimately, I hope that the developers are able to come up with a design sufficiently compelling to overcome the knee-jerk statusquoism some in the community will inevitably have. Regards, {{u|Sdkb}} ^talk 06:51, 24 September 2022 (UTC)[reply]

   I am surprised by comments mentioning variations of "knee-jerk statusquoism" when other comments, such as from Nosebagbear above, include concerns about "major community worktime issues that come from needing to redesign very large numbers of articles to match this layout better." For me, it does feel daunting to consider how many articles will need review and potential adjustment, and I am familiar enough with various articles to consider the impact (e.g. on articles already designed with shorter line lengths thanks to the addition of images, quote boxes, etc).

   My own reaction includes my understanding of principles related to presenting information that I do not see reflected in the new skin. For example, I question the removal of the TOC from the top of the article, because it seems contrary to centralizing the need of the reader to immediately know what the article includes, in multiple formats. We do not have well-developed leads across all articles, and the TOC is another way to present an overview. If we are here to educate, then the impacts on how we present information as an encyclopedia seems to be a critical consideration.

   I think Sj gets at the more existential issue in their comment below, and from my view, some of what seems like "knee-jerk" reactions may be related to this skin being presented as emulating nonencyclopedic websites (e.g. like an online newspaper, etc), as if this is obviously desirable. I was also less attempting to discredit the studies than to critique the validity of what has been offered as applied to what we try to do as an encyclopedia. In the meantime, somewhere in this discussion, although I have not been able to quickly find it, Line length#Electronic text was noted, and the citations seem to suggest mixed results. However, I appreciate your insights very much, Sdkb, and I hope developers will consider the various reasons for resistance, and how even first impressions may create access barriers for both readers and editors. Beccaynr (talk) 16:41, 24 September 2022 (UTC)[reply]

   @Beccaynr, re the ToC, it took me a while to understand the vision the developers have for Vector 2022. The links currently in the left sidebar that editors use frequently are part of the article tools section, and readers don't use any of the left sidebar links much. Once the tools have been moved to a menu similar to what Twinkle currently is, they anticipate that everyone will be able to collapse the left sidebar by default, making the table of contents always appear at the top (just the top left rather than top center). That vision makes sense to me, but it's hard to see currently as it's not realized yet, which I believe is leading to some of the non-width-related opposition. {{u|Sdkb}} ^talk 16:54, 24 September 2022 (UTC)[reply]

   I'm in favor of easy language switching. Like many WP-en editors, I've encountered references to sources in other languages, at least one of which I can read. Some have direct links in the English page content, but in other cases, the switch is: return to main page, enter the other language's WP, do a new search.

   I find it odd that someone so well-informed will use "knee-jerk opposes" as a justification for leaning to Support. This seems unduly exterior-driven, almost a hedge against the risk of forming one's own opinion. OTOH, I admit that my own aversion to the pushiness of making the skin change a default could also be seen as exterior-driven.

   Regarding Beccaynr's salutary distinction between accuracy of stats and applicability, I invoked Jakob Nielsen in my comment on Oppose 4. Namely, he emphasized the importance of letting the user's own combination of device/browser select the parameters for display. The goal of improving readability of text is being undermined by insistence on the means of making the line width fixed for everyone (unless you opt out). Martindo (talk) 02:58, 25 September 2022 (UTC)[reply]

2. I've been using Timeless for a couple of years now and even though Vector 2022 is an improvement over the default skin Timeless looks a little bit better to me:

   Vector skin shortcomings:

   • There's too much white space at the top of the screen
   • Color-wise it's too white and bland
   • It could be a tad wider
   • The user menu at the top looks detached from the page (there's a huge gap between the search bar and the user menu)
   • No related articles at the bottom Artem S. Tashkinov (talk) 13:06, 25 September 2022 (UTC)[reply]

3. I switched to Vector 2022 yesterday. I like the TOC down the side and the overall balance of whitespace. Linked text has insufficient contrast with the white background - the darker blue that was used in whatever skin is the default now has better contrast and is less tiring. I do miss the text links for navigation at the top - when I'm halfway down a Talk page it's not intuitive how to get back to the article. I also miss having a one-click button to see my own contributions. Clayoquot (talk | contribs) 14:34, 25 September 2022 (UTC)[reply]

   Could anyone please help me out by pointing me to some CSS code I can drop into my custom CSS file to make the link olours darker? Clayoquot (talk | contribs) 22:47, 25 September 2022 (UTC)[reply]

   @Clayoquot: You may be interested in User:Anomie/linkclassifier. Certes (talk) 07:30, 26 September 2022 (UTC)[reply]

   Thanks, but I'm looking for something simpler. I just want the link colour used in Vector 2010. Clayoquot (talk | contribs) 16:15, 26 September 2022 (UTC)[reply]

   For the old colours (which also pose an accessibility issue, see phab:T213778)

   a:visited {color: #0b0080;}

   a:link {color: #0645ad;}

   For the settings I'm now trying (darker colour, but with subtle underlining). The purple is still ugly, and the underlining occurs in places it shouldn't, but I think it's the right direction for a WCAG-compliant solution..

   a:visited {color: #7f3ebf;}

   a:link {color: #24478F;}

   a:visited { text-decoration: none; padding-bottom: 1px; border-bottom: 1px solid #DCDCDC ;}

   a:link {text-decoration: none; padding-bottom: 1px; border-bottom: 1px solid #DCDCDC ;} Femke (talk) 16:27, 26 September 2022 (UTC)[reply]

   Thanks! I'm trying the settings you're trying now. Clayoquot (talk | contribs) 01:50, 27 September 2022 (UTC)[reply]

4. Switched to the new skin to give it a fair try past my initial knee-jerk "no" of unfamiliarity. Some thoughts:
   • The page width thing is incredibly frustrating, as everyone else said. Studies or no studies, I don't particularly want to be jammed into it for my own good. Notably, it also forces images, infoboxes, tables, etc into the width, squishing any text next to them. When it's pure text it's okay, but when there's a lot of other page elements it gets very very cramped. The main page especially looks bad. A good first attempt at fixing this might be to move the infobox into the rightwards whitespace. An exception for the mainpage might also be nice.
   • I like the moving sidebar table of contents, and how it highlights which section you're in. I really don't like that the editor tools force it down the page, making me scroll every time I want to interact with it.
   • Don't love how the top page links have been replaced with icons, though I'm sure I'll learn them quickly enough.
   • Going back and forth on whether I like the new prominence of the language switcher - I personally do, as an editor, but I don't know that readers need that very much.
   • Overall appearance is nicer, though the grey box with editor tools looks slightly out of place. Might like it better if all of the whitespace on the sides was the same grey, to seperate it from the article content a little.
   Once I've used it more I'll try to put in an actual !vote. Rusalkii (talk) 04:39, 26 September 2022 (UTC)[reply]
5. Thanks for putting this up for comment. I'm a reader with no interest in making a Wikipedia account, and I only found this discussion through an offsite link. My one "note" is that I think the floating title bar that seems to (currently) only be shown to logged-in users should be universal – I recognize most of the tools there are only of interest to editors, but I think it would be a great benefit for all readers to be able to search without scrolling to the top of the page. Otherwise, this design is fine, probably better than the current skin. I wouldn't complain if you made it a little less white, though. 130.184.252.29 (talk) 17:24, 26 September 2022 (UTC)[reply]
6. Swapped from Oppose (yes I know this in the neutral section however I'd like to make my initial opinion more obvious). I've been using Vector 2022 for a few days now so I can form an opinion other than just an immediate "No it's not what I'm used to". The main thing that bothers me is that, with my current screen, everything is slightly shifted to the right because of the sidebar. Other than that, it's fine. There are a few things I wish could be changed but it's fine for the most part. I don't usually edit from a large, widescreen monitor (largest one I regularly edit from has a resolution of 1280x1024 and is practically a square) so I don't actually notice the width issues. I would probably like it a lot more if this beta/preview were implemented soon as the options there can provide a nice separation between the article content and the tools. The minimalist design takes some getting used to with icons instead of words in some places, and also having to click on buttons like "Page" or "TW" or "More" rather than hover over them. So I'm kinda on the fence at the moment. Heck if they implement a proper dark mode rather than just an inverter that would probably bring me over to support ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:21, 27 September 2022 (UTC)[reply]

Alt proposal: gradual changeover + width toggle

Proposed:

• Vector 2022 is the default for logged-out readers and accounts created after the deployment.
• Vector 2010 remains the default for current accounts.
• A text-width toggle is added to Vector 2022 for both logged-out readers and logged-in readers.

• Support as proposer. I'd rather see something happen than nothing happen. Too little, too late? Maybe, but had to try. Enterprisey (talk!) 05:30, 25 September 2022 (UTC)[reply]

  @Enterprisey: does this "toggle" relying on local storage already exist, and if so is it dependant on some hacky javascript :) ? — xaosflux ^Talk 22:45, 26 September 2022 (UTC)[reply]

  I don't know if it's been written, but it shouldn't be very complicated or hacky, I imagine, just toggling a class. Enterprisey (talk!) 22:57, 26 September 2022 (UTC)[reply]

• Support – second choice ♠JCW555 (talk)♠ 05:58, 25 September 2022 (UTC)[reply]
• Comment - As proposed is the toggle persistent, or would logged-out readers need to press it every time they want to view an article in Vector Legacy? BilledMammal (talk) 13:19, 25 September 2022 (UTC)[reply]

  Persistent. If it's done locally, they would have to press it every time they switch computers, but we can't do anything about that. Enterprisey (talk!) 16:47, 25 September 2022 (UTC)[reply]

• Support with reservations a phased approach like this may be more platable even if it takes longer for registered editors switch over. This would be similar to the introduction of Visual Editor to new users. However, should there be also a persistent toggle for non-logged in users if they want to switch back to Vector 2010? Unlike this proposal, Visual Editor isn't forced down on non-logged in users. (That is if the 'text width' here is referring to the Vector 2022 wide width gadget, and not switching between 2022 and 2010. Sorry for the confusion if so.) – robertsky (talk) 14:28, 26 September 2022 (UTC)[reply]

  Just 2022; clarified in proposal. Enterprisey (talk!) 16:53, 26 September 2022 (UTC)[reply]

• Support - equal first choice. The text-width toggle is a good idea for everyone on every skin no matter what happens, I hope that feature is added. This phased-deployment plan also makes sense. Levivich (talk) 17:00, 26 September 2022 (UTC)[reply]
• Support - While I've already voted in support of the primary RFC, I would support this proposal (which sadly seems to have gone mostly unnoticed) in equal measure as it seems to address the majority of complaints. ThadeusOfNazereth(he/they)^{Talk to Me!} 17:43, 26 September 2022 (UTC)[reply]
• Support (already voted in support of Vector 2022 as proposed, but this is a good compromise - in a few months we'll know who uses which setting and where). I've checked the withgadget=wide-vector-2022 page and I find (by changing the window width) a 100 character line most comfortable in the lead with an infobox, which gives about 140 character line in paragraphs with no side graphics (still OK for casual reading). For me, on a 3200px 13" laptop screen, the problem with limited text line width is not the text(-only) width by itself, it's the fact that most of the width is taken up by our ever-growing infoboxes, navboxes and pictures. On pages with too many pics it actually helps to have a narrower text width so the pictures appear where they've been inserted and do not push one another to where they don't belong. Ponor (talk) 03:22, 27 September 2022 (UTC)[reply]
• Support as second choice. DigitalIceAge (talk) 06:04, 27 September 2022 (UTC)[reply]
• Support if this was an option. I believe that the designers are probably correct about the suitability of the fixed-width for Wikipedia readers, but I think this is one of those cases where making it easy to change would be harmless and preferred by a lot of members. JackWilfred (talk) 11:11, 27 September 2022 (UTC)[reply]

RfC discussion

• I'd like a commitment that the WMF will provide maintenance for the core V22 customisation gadgets/scripts (width, TOC positioning, etc) if the volunteer creators are unable to do so, including ensuring that they continue to work with future V22 changes. While the mediawiki documentation speaks of wanting a more consistent experience between readers and editors, I simply believe that's not going to happen. Our uses are just so different. So ultimately V22 needs to be able to handle both - and that agreement needs to be provided prior to becoming the status quo for readers because it'll be almost impossible to get afterwards. Nosebagbear (talk) 17:45, 22 September 2022 (UTC)[reply]

  Yeah, I've seen the consistent experience argument somewhere already and I agree that it's impossible. Try sitting in front of your laptop/PC and then holding your phone close enough to your face that it occupies the same field of view as your computer screen. Consider also that many people do most of their phone browsing on portrait mode. Anything that looks perfect on that FOV will not work on a desktop screen and vice versa. Daß Wölf 02:20, 23 September 2022 (UTC)[reply]

• One of the main issues I worry about, ironically, is accessibility of the link colours. These were changed to improve accessibility. I've changed the visited link colour in my CSS because I struggled to read them, especially on my watchlist. Given I have good eyesight, I worry about this being a wider issue. The colour can be made a tad bit more dark without failing the WCAG AA accessibility with the black prose (see phab:T213778), but that colour is still too light for me. If this is a problem more people experience, that would be a reason to oppose for me. Femke (talk) 18:50, 22 September 2022 (UTC)[reply]

  I see this too, I notice that especially purple links are significantly more distracting than they used to be and text with a lot of links feels a bit harder to read than it was with a darker link color. The contrast ratio of purple links to the page background is 5.26:1 which fails WCAG AAA on 18px font size, and Wikipedia uses an even smaller 14px font size where contrast matters even more. Blue links are similar, with a 5.36:1 contrast ratio. pfg00 06:19, 26 September 2022 (UTC)[reply]

• Has there been any discussion about using the currently-empty right column to house floating infoboxes instead? I'd be keen to read that back-and-forth, if so. Thanks, — Fourthords | =Λ= | 20:20, 22 September 2022 (UTC)[reply]

  There are some older prototypes pre-V22 development that played around with moving images, infoboxes, and other floating content at high width into those spaces, and the "responsive Vector" gadget available today also does that depending on width. Izno (talk) 20:26, 22 September 2022 (UTC)[reply]

  I'm pretty keen on the new style, and would like to see how that gadget would work! I don't see it at Special:Preferences#mw-prefsection-gadgets; is it available for rank-and-file editors/readers like me to try out? — Fourthords | =Λ= | 13:21, 23 September 2022 (UTC)[reply]

  @Fourthords, if you have the Vector skin on (not 22), Improved appearance for mobile, narrow and wide screens (documentation) is the text you're looking for. Izno (talk) 17:45, 23 September 2022 (UTC)[reply]

  Oh, that's pretty brilliant (if a little glitchy at the moment)! Incorporating those floating ideas (especially the infobox) into this new idea would be pretty great. Thanks for the heads-up! — Fourthords | =Λ= | 19:05, 23 September 2022 (UTC)[reply]

  @Fourthords - in the future, we're hoping to use this as flexible space that can be configurable to hold different things. Most of the current conversations have been around tools - page tools, gadgets like twinkle, languages, etc, although it would be interesting to collaborate with the community on placing content in that space as well. We're currently building out the ability to pin all the page tools in the right sidebar and hope to continue to make more menus pinable as well. You can view the prototype of that here: https://vector-2022.web.app/Moth. This will be available on the new skin in about a month or so. Here's a screenshot:

  

  OVasileva (WMF) (talk) 20:29, 22 September 2022 (UTC)[reply]

  To me, not finding a way to fill it in two years of active use on smaller wikis is a bad omen. After showing this to my family I spent a good minute or two convincing one of my family members that Wikipedia doesn't intend to start serving ads. Daß Wölf 02:14, 23 September 2022 (UTC)[reply]

  @Daß, Wikipedia having ads would go against a core principle of being not-for-profit and keeping information free and accessible. That's why they ask for donations. Hell, Amazon donated a million $1 million. If you look up articles on Wikipedia and their donations. Giving is up substantially compared to when they first started. They are not struggling even with the staff they have to pay. But operating still comes with a cost. Mr. C.C.^{Hey yo!}_{I didn't do it!} 21:22, 26 September 2022 (UTC)[reply]

  Right, and that’s obvious to us, but many readers don’t know about Wikipedia’s nonprofit governing structure, they just click on it because it’s the top result on Google. Other websites have trained readers into thinking that white space on the site will get filled by ads. —pythoncoder (talk | contribs) 14:39, 27 September 2022 (UTC)[reply]

  @Mr C.C.: Sure, that's obvious to us, but not necessarily to the readers, apparently even those with an active Wikipedian in their family. Daß Wölf 14:59, 27 September 2022 (UTC)[reply]

• Regarding the metric specified above in Key Results, referencing https://phabricator.wikimedia.org/T317529, where it said that 87% of users on the pilot wikis continued using the new skin; I'd like them to correlate this metric with how many of them actually know how to change back the skin to the legacy one. _→AzaToth 20:25, 22 September 2022 (UTC)[reply]

  @AzaToth - good point. We wanted to make sure that it's easy for people to switch to the old skin. So in addition to being able to turn the skin off in preferences, we added a bolded link in the sidebar: "Switch to old look" so that will be easy for people to find. OVasileva (WMF) (talk) 20:33, 22 September 2022 (UTC)[reply]

  I didn't notice that link until you now pointed it out, and I was looking around for one. _→AzaToth 20:38, 22 September 2022 (UTC)[reply]

• Comment: It looks like this RFC outcome would change to Snow Support if the WMF would let go of its attachment to white space. See also Duḥkha. – Jonesey95 (talk) 20:39, 22 September 2022 (UTC)[reply]

  I would agree with that comment. — Red-tailed hawk _(nest) 20:49, 22 September 2022 (UTC)[reply]

  The wasted space is certainly a major drawback, and the change might find support without it. Certes (talk) 21:54, 22 September 2022 (UTC)[reply]

• Why was it decided to do an RFC? The editors who will comment on this and end up deciding whether the skin will be used make up less than 0.1% of the daily users of Wikipedia. If the statistics show that Vector 2022 has a significant preference for usage among all users and even provides benefits to the project itself, then that should be clear evidence to implement it. The comments that users are making here are their own and cannot be representative of the entire user base like statistics can. This RFC seems to be about "whether I want my UI to be Vector 2022" and not "will the majority of users like Vector 2022". Measuring the true benefit of Vector 2022 will be impossible to do with an RFC compared to statistics. Editors against its implementation will still have the option to use the old Vector anyways... If users are still not confident that Vector 2022 will be an improvement for enwiki users then an A/B test should be run on enwiki itself to demonstrate its benefits. Lectrician1 (talk) 20:59, 22 September 2022 (UTC)[reply]

  The survey histogram above shows that only 37 users declared the new skin easier to use, compared with 60 for the old skin. It would seem unreasonable to override that result without an endorsement such as a RfC. Certes (talk) 21:52, 22 September 2022 (UTC)[reply]

  @Certes to clarify: the survey collected first-impressions, not usability data. It was invalid for us to ask a question regarding usability, which was of course our mistake. As a generalization I think it's fair to say that people don't like change (including myself). It is never easy to adjust to something new. However the reliable usage data we have, combined with the usability studies we've done, give us confidence that the change will be an improvement.

  Additionally, over the past three years as we've been working on the skin we've realized how brittle and tangled Legacy Vector is from a technical standpoint. There are many great features the readers and community want to see in the future — things like dark mode, improved citation support, better templates, better support for media, etc. These things will be much more difficult to achieve with Legacy Vector. Sometimes I think of it like taking one step back in order to take two steps forward. It is a difficult adjustment, but ultimately if we believe in the growth and long term sustainability of our projects I believe it's a necessary change to make.

  I'm curious how that sits with you? AHollender (WMF) (talk) 22:22, 22 September 2022 (UTC)[reply]

  The main plus for me there would be dark mode. If dark mode really is only possible with narrow text, then personally I'd stick with legacy Vector and the current dark-mode gadget. Certes (talk) 22:29, 22 September 2022 (UTC)[reply]

  I was going to reply to Certes about collecting user data because I was thinking about the difficulty of getting enwiki readers to try the skin out for a period of time since they'd have to get an account. I then remembered about the early adopter wikis. Are there any stats or any sort of reader feedback collected from those wikis about what the readers think about them? —Danre98^{(talk^contribs)} 01:56, 23 September 2022 (UTC)[reply]

  I would really wonder about what those stats would actually mean, even if we do have them - for the longest time I just thought fr-wiki looked awful and was harder to read and there was nothing I could do about it. I didn't realize that it could be avoided by making an account, logging in, and changing my preferences to return to the old version. I don't claim to be some kind of "most typical" reader or anything, but surely this has happened to others as well. -- asilvering (talk) 03:11, 23 September 2022 (UTC)[reply]

  @Danre89 Well if 87% of active editors (not even normal readers) just like on pilot wikis you have kept Vector 2022 instead of opting out of it, I think it's pretty clear that those who did not opt out decided Vector 2022 was better. Furthermore, A/B tests have shown that the user experience for normal readers is significantly more engaging, which should also be clear evidence that readers are enjoying Vector 2022 more as a user experience. Lectrician1 (talk) 14:51, 23 September 2022 (UTC)[reply]

  Lectrician: I think it's pretty clear that those who did not opt out decided Vector 2022 was better...

  This is the same "silent majority" argument promoted back in the days of Richard Nixon. No evidence. Just an assumption that neutrals are happy. Yet, somehow, those who "resist change" are described as having "inertia". Hmm, could it be that those who accept a new default are also experiencing inertia because the hassle of changing back isn't worth the effort? That sounds like compliance to me, not approval. Martindo (talk) 01:15, 25 September 2022 (UTC)[reply]

  @Martindo, The hassle of clicking the 'Switch to old look' link? — Qwerfjkltalk 14:21, 25 September 2022 (UTC)[reply]

  @Lectrician1: Sorry, I didn't get the ping because the Danre89 account is a doppelganger sock. Anywho, Martindo does raise a good point above. Though 87% is a high number, there's lots of people that don't care to change default settings in general (even if it's easy; people can be lazy at times). In addition, the stat doesn't tell how active those editors are (assuming more active editors are more likely to care about a skin change). I do think that stat shows that the skin's reception would at worst be lukewarm overall if deployed here. —Danre98^{(talk^contribs)} 02:09, 26 September 2022 (UTC)[reply]

  @Danre98 @Martindo During the testing the users had the bolded option of "Switch to old look" present at all times in the sidebar... You could have switched back with a single click... Lectrician1 (talk) 02:19, 26 September 2022 (UTC)[reply]

  @Lectrician1: Yes that link exists for easy switching, but would ambivalent or near-ambivalent users click on that link? —Danre98^{(talk^contribs)} 09:59, 26 September 2022 (UTC)[reply]

  @Danre98 If they were used to Vector 2012 and they wanted to switch back because they found Vector 2022 annoying, then they would most definitely look for some way to switch back (especially given the attitudes of editors displayed here that are not okay with Vector 2022). The switch back button was actually so visible because it was bolded that I found it annoying and I looked for a way to get rid of it. Lectrician1 (talk) 12:22, 26 September 2022 (UTC)[reply]

  Also, I don't want to keep on going back and forth about this. It's a past statistical run that seems to demonstrate clear results but clearly you think otherwise. This is why I recommended running an A/B test on enwiki itself for all users to demonstrate whether Vector 2022 has engagement advantages for enwiki and a higher retention rate than Vector 2012. Lectrician1 (talk) 12:26, 26 September 2022 (UTC)[reply]

  @Lectrician1: I see you reply and say that if they wanted to switch back because they found it annoying they would click on the button, which is true. However, my question was about the neutrals, not about the people that oppose the change and actively want to switch back because they find it annoying. My point, and I guess Martindo's point above, is that neutrals (including neutral-ish editors) and supports are grouped together in the not-changed-default category. It should not be assumed that those neutrals (who don't care to click the link because they don't care much one way of the other) support the change. Though in my opinion it is indicative of a certain level of support, it should not be taken to mean that there is 80%ish support (or a similar level of support) for the new skin on the early adopter wikis (also see Egsan bacon's oppose for other reasons why those 87% shouldn't be taken to mean 87% support). —Danre98^{(talk^contribs)} 20:11, 26 September 2022 (UTC)[reply]

• On pages with co-ordinates when using Firefox (e.g. Sundrum Castle), the global symbol overlaps with the horizontal line above it. -Kj cheetham (talk) 21:23, 22 September 2022 (UTC)[reply]

  Yes, this is an issue that is kind of stuck. The editors who have looked at the issue (including me) that would like to move forward with moving them into indicators are generally worried about potential blowback. Izno (talk) 21:29, 22 September 2022 (UTC)[reply]

• I am increasingly getting a feeling of WP:BLUDGEON occuring... -Kj cheetham (talk) 22:40, 22 September 2022 (UTC)[reply]

  I agree: WMF seems to be replying to half of the people in oppose, and frequently restating arguments, both what WP:BLUDGEONING is — PerfectSoundWhatever (t; c) 00:53, 23 September 2022 (UTC)[reply]

  The temptation is very understandable — I can only imagine how frustrating it is to work on a project for two years and then have it rejected out of hand because someone can't be bothered to read about it — but yes, I do get that sense. @OVasileva (WMF) @SGrabarczuk (WMF) @AHollender (WMF), part of how we're able to have norms expecting editors to read discussions is by also having norms about conciseness, including not repeating arguments you've made elsewhere. When someone makes a point you feel you've responded to elsewhere, it's always better to link to that comment/page than to restate yourself. {{u|Sdkb}} ^talk 17:00, 24 September 2022 (UTC)[reply]

  @Sdkb thank you for this information, and apologies for my redundant responses. I will follow that practice going forward. AHollender (WMF) (talk) 14:58, 26 September 2022 (UTC)[reply]

• On a more technical note, is there evidence the more minimalistic tabs at the top and more subtle colours for links is an improvement? -Kj cheetham (talk) 23:12, 22 September 2022 (UTC)[reply]

  @Kj cheetham: About the link colours:

  • The old colours also posed an accessibility issue, as the visited link colour was almost indistinguishable from normal text for some (see phab:T213778)
  • In an example with mostly blue links (two purple links), 63% thought it was an improvement.

  Femke (talk) 16:39, 26 September 2022 (UTC)[reply]

• It just goes to show how stubbornly resistant to change most English Wikipedians are, combined with suspicion of the WMF. Of course the plurality of people, on literally their very first use, said they felt more comfortable using the current skin! They’ve been using it for a decade - we all have! Of course the WMF is pushing us to adopt this - they’ve been working hard on it for 3 years! It’s disheartening to see our response, when it is perfectly clear that a) the WMF has committed to only implementing this if we choose it and b) any individual user can and will be able to use whatever skin they want. Nothing big ever seems to change here, no matter how slowly the change is pushed, unless it changes towards further inaction and bureaucracy. —Ganesha811 (talk) 01:44, 23 September 2022 (UTC)[reply]

  Most editors aren't opposing the skin because "it looks different". Personally, make the width larger, and I would instantly support. — PerfectSoundWhatever (t; c) 01:49, 23 September 2022 (UTC)[reply]

  Was this meant as a reply to a different comment? Your quote/paraphrase isn't in my comment. —Ganesha811 (talk) 21:24, 23 September 2022 (UTC)[reply]

  Your point (a):

  the WMF has committed to only implementing this if we choose it

  OK, let's put aside that "we" means "handful of frequent users/editors" currently participating in the RfC.

  What do you mean "choose"? If it's implemented as default, that's a limitation on choice.

  Personally, I'd be neutral if this was not being presented as a default (and if it was more transparent and/or thorough in terms of other aspects, such as worldwide usability). Martindo (talk) 09:50, 26 September 2022 (UTC)[reply]

• I urge closers to heavily weight WP:READER and User:Barkeep49/Elite when closing the RfC. – Teratix ₵ 01:58, 23 September 2022 (UTC)[reply]

  Similar comments could be made about the way the WMF has handled suggestions on the mw: page for this project. Daß Wölf 02:27, 23 September 2022 (UTC)[reply]

• Looking at the screenshots, I can see where the links to Wikidata/Commons/etc. are when logged in, which looks OK (basically no change). However, they don't seem to appear in the logged out view, which is bad since it re-enforces the idea that there's just Wikipedia, without the sister projects? Readers should be able to access Commons etc. as easily as editors can. Thanks. Mike Peel (talk) 07:11, 23 September 2022 (UTC)[reply]

This is not a one-shot project, and we will continue working on the Vector 2022 skin. First, we will be working on the page tools feature, to be completed in October/November 2022. Then, we will collaborate with the Growth and Editing teams on making it easier to learn about how the wikis work and begin editing. For more details, see the sub-page.

• Minor things I don't like after a day (not width-related): not obvious what the top-left button does, tooltips are not great like "Discuss improvements to the content page" and "The list of pages you are monitoring for changes" for talk page and watchlist, hard to see tab selections, icons rather than text at top-right, extra click to get to own talk page and contributions, different between visited/unvisited links is too subtle for my eyes. I realise this is very much from the point of view of an editor though. I'd also recommend any future RFC is less biased in how it's set up. -Kj cheetham (talk) 17:40, 23 September 2022 (UTC)[reply]
  • P.S. Plus also the lack of section numbers on the new TOC. -Kj cheetham (talk) 10:42, 24 September 2022 (UTC)[reply]
• Thank you to the WMF team for your patience answering everyone's questions. Since visual accessibility has been brought up several times as a point in favour of the new skin, can I ask if there is any accessibility-based reason for the lack of any border whatsoever between the ToC and the main article text in the new Vector skin? It's exactly the same colour background as the scrolling portion of the article (white), and no border line divides the ToC text from the article text either. It seems a strange choice, especially since the logged-in 2022 Vector does have a boundary box around the left-hand menu links. -- asilvering (talk) 23:36, 23 September 2022 (UTC)[reply]
• Some comments - I think the direction this skin is going in is good, but two things concern me and prevent me from supporting the change at this time: the large amount of white space (both the "white" and the "space") and lack of separation between elements (such as separating the header from the body, sidebar from the body, etc.). Don't get me wrong, this skin is a step up in readability, as I fully agree with the limited width (that's a big reason why I use Timeless, so that the lines are shorter), but it just looks bad, in my opinion. I'm no web design whiz, but I played around with the CSS and found that I liked the look much better simply by adding some borders around elements and adding a gray background to the margins at the side. I'd also be supporting with the assumption that a good dark mode is on the way (the current one I enabled in Gadgets is unusable imo edit: I hadn't tried the widget on Vector 2022, oops. It looks fine on the new skin); not just for registered users, dark mode is a fairly ubiquitous feature on the web at this point and many unregistered would use it if they saw a button for it. To reiterate, this skin works functionally but still looks ugly, in my opinion. I wholly support limiting the page width for readability, although perhaps the limitation could be relaxed a bit. ~Bluecrystal004 ^{(talk · contribs)} 01:20, 24 September 2022 (UTC)[reply]

  A follow-up before I go to sleep: I looked at a "prototype" version linked elsewhere in this RFC, and would immediately !vote support if option 9, 6, or 5 were adopted (in descending order of quality). They look good! ~Bluecrystal004 ^{(talk · contribs)} 04:54, 24 September 2022 (UTC)[reply]

• Small point, but I confess I don't understand the rationale for changing the "watchlist" link to a mysterious icon; it would be better to replace the current "alerts" and "notices" icons with those words. Icons have utility in contexts where a common language can't be assumed, but that is not the case with en.wikipedia. I assume that putting the other topline links into a pulldown menu is to save space, but I think this is also misguided. JBritnell (talk)

A tad off topic. But why are editors putting Support or Oppose or (though not yet) Neutral, at the beginning of their stated positions? You've already placed your posts in the so-named subsections, so you don't need to clarify your position. GoodDay (talk) 13:57, 26 September 2022 (UTC)[reply]

Best practice?

I see "best practice" mentioned a lot in response to content width and other elements. But I can't quite agree that it's "best practice" and not just "practice". So let me cynically look at the examples -- websites like The New York Times, Reddit, Medium, YouTube, etc. These are for-profit ad-driven opinion-inciting media sites. Of course they want to maximize content consumption. Of course they want to remove any UI elements that interfere with content delivery. Of course they want to maximum ad space and focus your attention onto it. Of course their deciding factor is "how fast and easy can we move the reader along". These websites are not designed for serving information. They are designed for serving ads. They are designed for instant gratification with easy-to-read text, simple language, colorful images and videos, invisible UI elements, all the responsive fluid UX to lull the reader into endless cycle of scrolling. Their mobile and desktop versions are homogenous to maximize familiarity. So of course these companies brag about their "better user experience" when their metrics are user retention and ads-per-minute. I wasn't going to write this lengthy complaint of modern web design, but then I saw A.H. mention they had adblock enabled. :) This was just too perfect of an example of how these websites have become "the new normal" in a way that no one asked. Users have to resort to tools like adblockers and privacy shields just to make websites usable, but somehow these same websites are also a good example of content presentation? I'm sure WMF/Wikipedia has some goals in parallel, but has anyone asked if a non-profit encyclopedia has the same priorities? Is the point to be like everyone else by maximizing metrics? Is the yardstick for "best practice" really websites that are nothing like an encyclopedia? —  HELLKNOWZ ∣ TALK 12:10, 23 September 2022 (UTC)[reply]

In the case of the NY Times, it's worth considering where they came from. Newspapers are traditionally a narrow-column format. Compared to that history, the layout they're using now is a radical improvement. I've been reading the NY Times on-line since they first went digital (and the dead-tree edition for a long time before that). They've made a few big layout changes over the years. The early versions of the site were a traditional newspaper layout, with a strict boxes-in-columns design. Every time they've done an overhaul, it's been to move further away from the old constraints and embracing more of the freedom current technology makes available. It's been a slow and cautious evolution because the old ways die hard, but it's also always been moving forward. Going to a fixed-width format is a huge step backwards. -- RoySmith (talk) 15:33, 23 September 2022 (UTC)[reply]

@Hellknowz thanks for your response. What do you think about non-profit websites, without ads, like: The World Health Organization, The Lancet, Nature, Academic Journals/PDFs, Gov.uk, Khan Academy, Us.gov, Mozilla, Technical documentation (e.g. React.js), as well as Reader modes in Chrome, Firefox, and Safari?

I think best practices are established by research. I've referenced other websites to give examples of how ubiquitous the implementation of these best practices are. I am sorry if I've confused the point by referencing for-profit websites. AHollender (WMF) (talk) 16:26, 23 September 2022 (UTC)[reply]

I think in the Internet dominated by giant media corporations dictating UX design, these websites have no choice but to follow or be excluded. Serve people what is already familiar. So when you ask experts or look at market trends, you will obviously see whatever trend the trendsetters set. It might be compliant to some list of design choices, but all combined it's the safest blandest design-by-committee mixture for the lowest common denominator. Thus I object to considering it "best" practice. It's just minmaxing user engagement with quantity over quality. —  HELLKNOWZ ∣ TALK 17:40, 23 September 2022 (UTC)[reply]

@Hellknowz Even if this preference is the result of trends in UX design, wouldn't it be better to provide the user with a similar experience as they have on other sites and are used to navigating than deviate from it? As an analogy, you wouldn't want website that looks the same as a phone app. People like conformity in design on the platforms they use. Wikipedia should use the facts of research and modern standards of design so that it continues to be a site people are comfortable with and want to go to. Lectrician1 (talk) 21:22, 23 September 2022 (UTC)[reply]

@Lectrician1: I don't disagree with that. But that still doesn't make it the "best" practice or even a good one. —  HELLKNOWZ ∣ TALK 22:03, 23 September 2022 (UTC)[reply]

Update on the fixed width and white space

First impressions - limited width

It sounds like many of you are supportive of the change except for the concerns around the width of the text. Specifically, we're hearing that many Wikipedians would like for this to be a preference, rather than use the existing gadget. To make this easier, we will begin exploring building a preference for logged-in users. Our team will review this request and add some details on what this might look like early next week.  

In general, we believe that limiting the width of the text is crucial in order to improve the reading experience on the site for our readers and editors. In our initial research for the project, we learned that many readers had difficulties with the site because there was too much information density on the page. This confirmed many of the learnings we had seen from across other websites and best practices for design. There is longstanding research that is clear regarding the optimal line-length for text. If you look around the internet at popular content websites – e.g. ProPublica, BBC, Snopes, AVClub, BBC, The Lancet, Reddit, The World Health Organization, Baidu, Medium – you will find they all have width limitations on the content. We've put together this FAQ to add some detail:

We hope that clarifies some of the issues you have raised. Thank you again for all the comments added so far. SGrabarczuk (WMF) (talk) 22:02, 22 September 2022 (UTC)[reply]

@SGrabarczuk (WMF) with respect, this feels like a re-iteration of the points that were already present above, on the FAQ page, and over on mediawiki's pages on V22 (with the exception of the built-in width bit, which is good). But it doesn't answer the issues of articles currently with wide tables, or those with photos on both sides, or with the current wide-2022 gadget not returning the width to that of Vector2010 (on my particular laptop, it's about 3cm of difference). Nosebagbear (talk) 23:09, 22 September 2022 (UTC)[reply]

For anyone that wants to preview the local gadget (available for logged in users) see the Pluto article above in vector-2022 with the wide view gadget. The gadget may not be perfect, and if you have programming improvements they are certainly welcome with an edit request. — xaosflux ^Talk 23:35, 22 September 2022 (UTC)[reply]

I'm a great fan of the wide gadget, and while I've already !voted support, I think this discussion would be trending differently if this was the default. Anarchyte (talk) 07:10, 23 September 2022 (UTC)[reply]

@Anarchyte I suppose we could force that gadget on for editors or even readers, but I don't think the dev team would like that very much - and for readers that never intend to edit it might not be a good idea. If we forced it on for editors, they could manually opt-out. I think getting a full-width toggle option built in to the skin would be an immensely better way to deal with it though. — xaosflux ^Talk 12:33, 23 September 2022 (UTC)[reply]

Good point. Perhaps a cookie-based setting so that unregistered users can also adjust the width if they want. A toggle somewhere on every page would be much better than forcing readers to register to access Special:Preferences. Anarchyte (talk) 10:04, 24 September 2022 (UTC)[reply]

That rather depends on whether readers could find the option at a glance and recognise it for what it is. Reading the discussion in this RfC today I found out that Fandom has a full-width option, and, having an idea of what I was looking for, I figured out how to switch it on in less than a minute. Unfortunately for them, I had already stopped visiting fandom.com in favour of a 3rd party reader. Daß Wölf 18:59, 24 September 2022 (UTC)[reply]

@SGrabarczuk (WMF): Will this fix the issue I'm having where this skin does not wrap to the width of my phone screen automatically (see here)? Because if this is an issue that'll affect all mobile users, and it's not just me, then it's a serious problem.—Ineffablebookkeeper (talk) ({{ping}} me!) 10:10, 23 September 2022 (UTC)[reply]

I am having this issue on the default skin too. — hako9 (talk) 13:38, 23 September 2022 (UTC)[reply]

The skin actually hasn't had design adjustments for mobile (yet). My understanding is that that is indeed a future goal.

I don't think it's unreasonable to file the task today for that issue. Izno (talk) 17:54, 23 September 2022 (UTC)[reply]

I would like to say that the reason I don't see anyone complaining about the whitespace in, say Google Docs, is because it doesn't look like something's supposed to be there. On Wikipedia that's not what it looks like with Vector 2022, it looks like there's stuff that's supposed to be there and yet it's empty. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:18, 23 September 2022 (UTC)[reply]

@Blaze Wolf, you can't compare Wikipedia to Google Docs in terms of design. That would be like comparing Twitter and Facebook in terms of design. Two separate sites that do their own thing. Even though I rarely click on the side contents beside the article, it's useful to have them there in case I need to. Mr. C.C.^{Hey yo!}_{I didn't do it!} 17:23, 25 September 2022 (UTC)[reply]

@Mr. C.C.: I'm not the one who did. The WMF did. "The overwhelming number of major websites have similar limitations on content width. For example: academic journals like Nature, news websites like ProPublica, government and intergovernmental websites like the United Nations, academic documents like LaTeX, and word processors like Google Docs and Etherpad." (emphais added) ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:38, 25 September 2022 (UTC)[reply]

@Blaze Wolf, I didn't see that. Thanks for pointing that out. UN: It has a lot less white space then Vector 2022. A lot of news media sites have white space. A percentage of them are riddled with ads too. (Not just on white space either). Wikipedia doesn't have to be like every other site out there. They don't need to compare themselves to other sites. That's like using WP:OTHER in various arguments ala deletion discussions. Even though you can use it in certain instances, you should generally avoid that argument. What other sites do for their design has no bearing on what Wikipedia does since. If it did, holding an RfC for this wouldn't exist thus making a core point of Wikipedia, in terms of users/editors, redundant. Mr. C.C.^{Hey yo!}_{I didn't do it!} 19:33, 25 September 2022 (UTC)[reply]

I am wondering why can't it just be like Fandom Desktop, where there is a button to expand the page past its fixth width? Aasim - Herrscher of Wikis ❄️ 16:34, 24 September 2022 (UTC)[reply]

Are there any opinions or study on whether a narrow centered paragraph is easier to read than if it is left or right aligned? — hako9 (talk) 13:41, 23 September 2022 (UTC)[reply]

This argument would be much more convincing if it were supported by empirical evidence. (No, examples of other websites is not evidence that these arguments are true; they are merely evidence that other websites impose this limitation, a decision that could have been made for many reasons.) ElKevbo (talk) 14:39, 23 September 2022 (UTC)[reply]

@ElKevbo, not sure if you saw my comment above so re-posting here: thankfully there is plenty of empirical research [EDIT: updated thanks to the help of others]:

• Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language -- "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
• Effects of Surrounding Information and Line Length on Text Comprehension from the Web (2002), from Canadian Journal of Learning and Technology -- "Comprehension was affected by whitespace; participants had better comprehension for information surrounded by whitespace than for information surrounded by meaningless information", which is more likely to happen if the text stretches to the edge of the browser.
• The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies -- "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
• Shorter Lines Facilitate Reading in Those Who Struggle (2013), from PLOS One -- "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
• The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University -- "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
• The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting -- "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
• Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed -- "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."
• https://baymard.com/blog/line-length-readability
• https://laurenscharff.com/research/textmargin.html
• https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf

Please note: the range of line-lengths studied is somewhat narrow. Some of the research shows certain positive effects of longer line lengths, but those line lengths are significantly less than what results from the maximum width we have in place in Vector 2022. In other words, even with Vector 2022 we are well beyond the maximum recommended range of any of the studies.

AHollender (WMF) (talk) 14:52, 23 September 2022 (UTC)[reply]

@AHollender (WMF): I know I'm not ElKevbo however, the only thing I like about the reduced width is that it reduces eye strain. I see that as a positive of the reduced width. However I feel that the blank space should at least be filled with something that isn't distracting (it being the same color as everything else makes it look like there's stuff meant to be there). Also, while I have seen someone who's normally anon compliment the new TOC, I find it kinda clunky to use since if I close it to increase the viewing space, I have to click the button to open it back up and scroll down (if the section is lower in the article) and then click the section. With the current table of contents I'm able to just go to the TOC and click on where I want it to take me, rather than having to go into a separate "menu". ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:31, 23 September 2022 (UTC)[reply]

Thanks for your note @Blaze Wolf. I'm glad you see the benefits of the reduced width, I also find it easier to read. And I tend to agree with you. So: for logged-in people the article tools will soon fill that space (and will optionally be collapsible) — prototype. We can also continue to explore the option of adding a gray background outside of the content area — prototype (select Option 9 in the bottom right-hand panel). AHollender (WMF) (talk) 15:54, 23 September 2022 (UTC)[reply]

@AHollender (WMF): I really like the options for different bgs and borders. It really makes it look much nicer and helps divide up the different content. I'm a little iffy on the article tools filling the space by default since while it does make it easier to access, it also makes the viewing area look really cluttered. I would say a decent alternative would be to turn the tools into small icons on the side of the screen when collapsed, but that might cause confusion as to what button does what. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 16:03, 23 September 2022 (UTC)[reply]

@AHollender (WMF) the layouts in these prototypes look fantastic! I prefer the first link, but they're all good, it's a huge improvement over what was proposed in the RFC in terms of TOC/menu layout. PaulT2022 (talk) 16:16, 23 September 2022 (UTC)[reply]

@Blaze Wolf @PaulT2022 thanks for your feedback. I realize it's difficult to trust a faceless organization, and people you've never met. But our plan is to continue collaborating with the community and improving the skin. If you check out the project talk page you can see that I'm active every day, talking to people, building new prototypes and mockups based off ideas they have, etc.

Some say the RFC is premature. I think no matter when we ask, no matter how far along the skin is, people will be extremely resistant to change (I myself am resistant to change in aspects of my life). I think if we believe in progress, and believe in the project growing to include newcomers and new features, we have to get over this uncomfortable hump. And yes, of course I am biased and already believe in the approach of progress. But I'm honestly listening to the concerns, taking them into consideration, and trying my best to have a zoomed-out, objective point of view where I consider editors, readers, newcomers, and people who haven't even experienced Wikipedia yet.

I really hope I can build some trust with folks like yourselves, and that you might consider supporting the transition at some point. AHollender (WMF) (talk) 16:36, 23 September 2022 (UTC)[reply]

@AHollender (WMF) thank you! I appreciate the hard work of everyone involved and the patience dealing with "they didn't ask me" comments. I think a premature RFC is still a good idea to nudge those unhappy with the proposal into thinking hard to how make the design upgrade happen, rather than "having ideas" indefinitely. PaulT2022 (talk) 16:53, 23 September 2022 (UTC)[reply]

@AHollender (WMF): I'm glad to hear that. And I do agree it's difficult to trust a faceless organization, especially one that seems to ignore some complaints (mainly regarding the fundraising banners which I presented my firm opinion on). I actually feel that what was shown in the 2nd prototype could open up way more options for customization which is currently very limited. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:02, 23 September 2022 (UTC)[reply]

I suspect would have gotten a more positive response if had waited until the prototype was usable. -Kj cheetham (talk) 17:34, 23 September 2022 (UTC)[reply]

I'm actually a strong Support vote, but I adore (!!!) that Option 9 on the Borders and Backgrounds. It fixes two problems with the V22; a almost distracting amount of white space on very wide monitors (b/c the Option 9 darker color lets you know not to focus on it and makes it less visually interesting); and the current way that on very wide monitors, there is the white background for article, ToC, and (coming soon) article tools, but then it goes to grey randomly at a certain point, which makes it seem like V22 has been poorly designed for wide monitors, when really y'all have been being very intentional. I also really appreciate Option 9 for looking distinct from the massive-whitespace corporate look with the classic Wikipedia grey. Azertygod (talk) 21:38, 23 September 2022 (UTC)[reply]

AHollender (WMF), I appreciate your goal to build trust, and to that end, I encourage consideration of why there is resistance to what appears to be a significant change characterized as something that "could be helpful to editors when making decisions about page layouts." You have suggested that research be reviewed and have stated "thankfully there is plenty of empirical research" with a list of links. I mentioned above that I am less convinced by the research presented, but I am interested in how this new skin reflects principles of universal design, and have tried to suggest a slower rollout, by first offering this new format as an option. Having this new design be opt-in for now could allow for more feedback to be collected and various concerns to be addressed before implementing the new skin as a default. With regard to the research presented above, I disagree that it is "plenty of empirical research", but would like to highlight that there is a reference to the WAI and W3C Web Content Accessibility Guidelines in one of the links.

• The first link is to Peter Orton, (n.d) "Computer text line lengths affect reading and learning", IBM Center for Advanced Learning, which is not peer reviewed and begins by making broad, uncited statements about research related to reading print media, and then describes "two sets of experiments: first a pilot with 16 adult subjects, then a follow up with 114 adult subjects (70 males, 44 females)" using an eye gaze tracking device while they read web material of varying widths. The study is related to designing online learning programs and concludes that additional research is needed.
• The next link is to Edward Scott, May 10, 2022, "Readability: The Optimal Line Length", Baymard Institute blog, advertising products for e-commerce platforms. The promotional blog post does include "The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that, in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)."
• The third link is to Schneps et al., Aug. 5, 2013, "Shorter Lines Facilitate Reading in Those Who Struggle" PLoS ONE, which is peer-reviewed, and focuses on the use of e-readers by people with dyslexia. "Participants were 27 (13 M/14 F) students with lifelong histories of reading struggles." This study notes when it is engaged in speculation and in its conclusion calls for further research.
• The fourth link is to Chaparro & Bernard (January 2002) "The Effects of Line Length on Children and Adults' Online Reading Performance" Software Usability Research Laboratory, Wichita State University. It does not appear to be peer-reviewed and is a study based on "Forty participants (20 adults and 20 children)" who volunteered. The experiment does not test layouts similar to Wikipedia articles and does not account for how Wikipedia articles are typically formatted to assist the reader (e.g. TOC at the top to present an overview of the article, sections and subsections to break up long blocks of text, short paragraphs to do the same, and the use of images, tables, etc). The overview of previous studies discusses mixed results, the study produces mixed results, and the conclusion makes a suggestion instead of calling for additional research.
• The fifth link is Youngman and Scharff (1998) "Text Width and Margin Width Influences on Readability of GUIs" Presented at SWPA. In this study, "Readability was assessed by twenty-seven participants who scanned text excerpts for hidden target words", and the conclusions include "Given that webpages on the Internet can be resized by the reader, future research should investigate proportionally-sized text widths in addition to the fixed text width and margin space conditions used in this experiment."

I think major changes may be easier to support if they are presented not as supported by a collection of small studies that are mostly not peer reviewed, but instead as reflective of principles of universal design. Details such as the use of icons instead of words in the new skin indicate that universal design may not be central to development, and at least from my view, suggests further evaluation is needed as to whether this new design is reflective of best practices before it is deployed as a default. There seem to be ongoing questions about how to improve reader and editor experience and about how quickly changes should be implemented. Beccaynr (talk) 18:50, 23 September 2022 (UTC)[reply]

Thanks for this detailed response @Beccaynr. It's great to see that you're engaged with the research. I appreciate you pointing out the WCAG guideline as well, I find their recommendations are usually well reasoned and useful. I certainly agree that more research is needed. As I was saying in a different thread above, part of what is difficult here is that as far as I have found nobody has studied the kinds of line-lengths many people in this discussion are advocating for. Most studies focus on the 55–100 character per line range. On Legacy Vector, if you are using a large monitor (1920px), you regularly get ~300 characters per line (or more), with a minimum around ~225 (if text is next to an infobox or floated image). The way I've made sense of this is:

• Most of the studies I've found, old and new, while not conclusive (as studies rarely are) advocate for shorter line-lengths (and even when they advocate for longer ones, they're still talking about line lengths shorter than we currently have in Vector 2022).
• I assume it's meaningful that the studies do not include lengths over ~100 characters per line, but of course I cannot be certain as to why that is
• I'm triangulating based on other references (again, maybe flawed, but also somewhat hard to imagine that basically everyone else who does typography in print or on the internet has gotten this wrong).

Here is the literature review we assembled, in case you would like to read further: https://drive.google.com/file/d/19gUtEzZvHE4Mgp02S1D-scPgdIwKpD3r/view?usp=sharing

Until we can conduct more research (specifically for Wikipedia articles, and including line lengths that result in 300+ characters per line), the conclusion I've come to is that we should err on the side of caution, and follow the clues from the existing research, and as you've pointed out the WCAG guidelines. We can always make the text wider if we find that to be beneficial.

May I ask, have you given the limited width a chance for a week or two? I fear that many people are reacting based on their first impressions (and other fears that Wikipedia is simply following trends, or preparing for ads), rather than first taking the time to learn from their own experience. AHollender (WMF) (talk) 19:07, 23 September 2022 (UTC)[reply]

@AHollender (WMF): I would like to says that I think the reason why people are thinking Wikipedia is preparing for ads is because the amount of whitespace mimics the space often used for column ads (I don't know the actual term for ads that are displayed vertically). I don't have a specific example of a website that uses column ads (mainly since I usually use an adblocker) however I do see why people are thinking Wikipedia is preparing for ads. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:36, 23 September 2022 (UTC)[reply]

@Blaze Wolf, it's not just ads in the white space on the sites. It's ads within articles themselves. "Article continues below this ad." Yes, they have to make money, but putting ads in the article when you're trying to read the article is overkill. Not saying Wikipedia would do that, but ads goes against their core value of having free and accessible information. That's why you see them asking for donations. Amazon has shelled out a $1 million donation. It's not like they are in dire straights or anything. Being a not-for-profit, you rely on donations. Mr. C.C.^{Hey yo!}_{I didn't do it!} 20:32, 25 September 2022 (UTC)[reply]

You are welcome, AHollender (WMF), and I am glad you were able to incorporate the WCAG guideline into the FAQ above [4]. I am trying to consider how guidelines interact with what we already do at Wikipedia to support a diverse audience of readers and a diverse community of editors, as well as whether the proposed changes are an improvement and how quickly changes should be made if we do not yet have sufficient data. From my view, Wikipedia in its current default form can be an oasis that promotes a deeper engagement with content, because it is an encyclopedia.

I do not think my own personal preference is as relevant as what is actually best practice, in terms of whatever that means for how Wikipedia presents content and engages its editors. However, I think there is nothing to fear from people with disabilities who have experience with web design that is repellant to their perceptual abilities, or from people concerned about how these changes may undermine the encyclopedic appearance and function of the website. I think erring on the side of caution supports a slower rollout that allows relevant data and feedback to be collected before major changes are imposed by default. Beccaynr (talk) 19:49, 23 September 2022 (UTC)[reply]

AHollender, I've been trying the new skin lately, here (w/ dark mode widget and narrow width) and on fr (their older version). Most of the changes have grown on me. but the lost ability to choose my browser window size is striking, every time. A loss for reading, for research, for browsing user pages and talk pages, for editing. And within that narrower frame, the empty space and loss of functionality in both side panels feels incomplete, like a prototype waiting for the rest of a design to take form. As someone else mentioned above, the fact that nothing has filled those panels in the past two years suggests that the white space will persist unless there's an active contest among people with ideas for making use of it -- similar to discussions many projects have had about how to use their Main Pages.

Beccaynr, I greatly appreciate your comments! Thank you for putting this so clearly. General thoughts in response to a number of things in your dialogue and earlier above:

• Editorial decisions about column + page width should not be backed into via skin redesign. If there is no way to separate the technical clean-up and modernization of the skin from major editorial decisions about width, then the underlying decision shouldn't be made in isolation from the editors.

– Practically: We should have a plan for a) how to value and use screen-space, including making use of margins, b) how to preserve the time of editors and layout designers who will have to compensate for the self-imposed limitations of the new skin, and c) how future skin updates can happen more fluidly (without which problems noted may just stay around forever).

– We should be teaching a new generation of community editors + designers to develop and experiment with skins -- a community not exclusive to staff. Skins should be maintainable by (and collaboratively developed by) that community.

• Let's take the exploration of reading-experience and associated research more seriously. More work could be done, at larger scale, than has been done so far; we know researchers who might be keen to do it; and we are by far the most-read website with long lines of text in the world. We should honor this by studying it, and not immediately revert to the current-design-cycle mean.

– Encyclopedias and dictionaries have long been an exceptional case: designed in part to pack dense information into the standard view even if they have slimmed down overviews, outlines, and introductions with more whitespace. Britannica combined this approach with large side margins for annotations and often length footnotes, in their later print editions before going digital-only.

– If we aren't reaching out to the best groups in the world to collaborate with us on this, as peers and partners, we've lost the central throughline.

• It's true that other online reference works, like online news before them, have honed in on short, bite-sized, narrow-column formats. There are also a lot of other format decisions that we've collectively settled on that differ from almost every other online site (dense in-line links; extensive, granular in-line citations of claims; detailed citation formats; infoboxes and disambiguation papers; banners and hatnotes to denote works in progress; hierarchical categories; shared nav and format templates; a nuanced collaborative style guide). These drew on traditions from scholarly research, law, online hypertext, librarianship. But most broke new ground in clarity, precision, and ease of access, and advanced the state of the art in contextualized knowledge presentation! And notably, in most of these areas we still stand apart, even where our approach is obviously an improvement. So "everyone else is doing it" is a poor indicator indeed.

– People who have been engaged deeply in this work, of structuring and presenting knowledge to others, should be engaged in these elemental decisions about skin and site frameworks. Those design decisions affect all the rest, and should be similarly accessible.

• Finally, I personally very much want a named and addressable right margin in the skin, mainly because I want marginalia and annotations to make their way to the default view. I want this framework to be available to build on. And I want new approaches to multi-column layouts that move the "standard Wikipedia page layout" from single column to multi-column, for screens wider than a phone. Points for departure:

– Britannica for decades had an annotation column in the Macropedia. Many long-lived references, as they aged, added explicit space for marginalia. A number of dense, dynamic websites that expand to fill available browser tab width still limit the central column width, but have engaging and interesting annotation context that is collapsed in narrow view and expanded or default-visible as width allows. Some use extra horizontal space not to showcase ads, but to showcase related work and knowledge, or show a history of recent pages. (compare modern tools for thought like Andy's Working Notes) We should be working and experimenting in that space; the people building those tools are the modern inheritors of the wiki mantle and are certainly drawing on fedwiki and other wiki spaces.

– Many research papers commit to a two-column layout, often to great effect and improved readability (though as with any of this, ymmv). LaTeX and other layout tools have templates for tables/figures spanning multiple columns.

– SJ + 23:37, 23 September 2022 (UTC)[reply]

@SJ: regarding the right margin, did you see the prototype with a grey background? (select option 9 from this link) I personally think it removes the need to "fill" this space in order to differentiate it from the article body text.

I did, and I like that option's visual clarity. But I see a fundamental principle not to waste space, and our default designs should do useful things with extra width when it is available. The current 2022 design has narrow and medium-width modes, it should have a wider mode as well. And we must stop conflating 'amount of screen real estate used' with column-with. – SJ + 16:14, 27 September 2022 (UTC)[reply]

I also agree it's helpful to establish the empirical evidence for shorter lines. Without an accessibility policy-based argument citing clear evidence that narrower columns benefit readers, it'll be hard to overcome the difficulty of finding consensus for changes such as this, particularly given en-wiki's conservatism with regards to bold visual changes. People like what they're used to, and to be fair, Wikipedians are also a crowd particularly used to demanding evidence. I've long presumed shorter lines are more readable (perhaps from personal experience, as a neurodivergent person) and was somewhat surprised when @AHollender (WMF) said there's "plenty of empirical research" but then shared five unconvincing links (I see Beccaynr thought the same as me, and thank them for breaking down each source). The third link is the only serious academic article of the five provided, and I think its finding is significant in terms of the benefit for people with dyslexia, even if it's a small study.

I found the WMF-assembled literature review linked above poorly written. Thankfully, it does point to what looks to be the only academic literature review specifically on line length (although it doesn't actually make this clear)! It's available here via ProQuest, and accessible via the Wikipedia Library for editors with over 500 edits (search "Optimal Line Length in Reading - A Literature Review"). It dates from 2005 and is published in the peer reviewed journal Visible Language. While it'd be preferable to have more a more recent review, it does include a broad range of studies and has a particular focus on electronic devices, which is good. It says: "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)". I think this resolves the discussions above about whether shorter lines and WCAG are simply "practice", rather than evidence-based "best practice".

Given that the new skin preview appears to have lines with ~80-90 cpl (on my device at least), I think it can reasonably be said that the assertion our WMF peers make, that the new skin offers a more accessible and easy reading experience for visitors, is supported by the best available evidence (if anything, it's a compromise with lines longer than "best practice"). I'm not sure I'm fully ready to support the change (I'd like to see what comes out of discussions for a built-in wide width option and clearer backgrounds), but I think the new skin is the way to go in accordance with our community's commitment to being inclusive and accessible. Jr8825 • Talk 06:36, 24 September 2022 (UTC) (edited Jr8825 • Talk 08:32, 24 September 2022 (UTC))[reply]

@ElKevbo @AzaToth @Certes @Hellknowz @PaulT2022 @PerfectSoundWhatever @Find bruce @ThatSpiderByte — with the help of @Beccaynr, @Jr8825, and @Nosebagbear I have updated the list of research regarding line length and readability, towards the top of this thread. I hope the additional research may be helpful. I apologize for not being more thorough in my initial reply. Quite honestly I was scrambling to respond to many comments, and just working too fast. Thanks, AHollender (WMF) (talk) 11:34, 27 September 2022 (UTC)[reply]

Thank you, AHollender (WMF), although it may be helpful to explain how each feature of the new skin reflects Web Content Accessibility Guidelines, per WP:ACCESSIBILITY. This may help avoid potential distractions related to critiquing the reliability and validity of the listed studies, and may help support the development of consensus related to whether and how quickly to implement the new skin. From my view, it may be counterproductive to essentially homebrew a 'best practice' based on a few studies, because a vast amount of research has already been incorporated into existing guidelines for web content. Relying on WCAG does not necessarily lead us to a clear answer, but I think it offers a reasonable starting point for assessing the current default and the new skin, as well as whether and how quickly to make a transition. Beccaynr (talk) 17:22, 27 September 2022 (UTC)[reply]

Gadget-wide-vector-2022

@Xaosflux: what's the status of MediaWiki:Gadget-wide-vector-2022.css? My primary complaint is about the enforcement of a maximum layout width. I installed this and at least on first glance, it looks like it solves the problem. If this was something that I could count on to continue to work (i.e. the Vector team commits to supporting it), I'd probably change from oppose to support. I don't honestly see why this trivial bit of CSS couldn't be the default behavior, but as long as I knew it was stable and supported I'd be satisfied with installing this manually. -- RoySmith (talk) 17:31, 25 September 2022 (UTC)[reply]

@RoySmith it is "community supported" and certainly could break with upstream changes to the skin. It is currently opt-in for registered users only. There is one bug I know of right now (if you collapse the TOC and the sidebar at the same time, when you click the TOC menu icon the popup is offset too far to the right). I expect there is going to be a possible collision with the development suggested above of moving page controls (like "Move", "Delete") in to the right side gutter. I'm quite sure there would be better ways to do this, perhaps with a toggle, if the skin developers would embrace the concept. — xaosflux ^Talk 17:41, 25 September 2022 (UTC)[reply]

I certainly hope they embrace the concept. It would give them what they want (shorter lines of text) while still providing an easy way for people who can't live with that to also get what they want. -- RoySmith (talk) 17:51, 25 September 2022 (UTC)[reply]

Well, with the discovery of Gadget-wide-vector-2022, I'm going to give this another try. I've turned on the new skin in my preferences and I'll see how it goes. I'm not convinced I'll like it, but now that my killer issue seems to be solved, it's worth another look.

I also discovered User:Jdlrobson/vector-max-width-toggle.js and tried that. It's a bit snazzier in that it's got a live toggle button, but seems to just give you some more width, not arbitrary more width, so that seems kind of pointless. -- RoySmith (talk) 20:44, 25 September 2022 (UTC)[reply]

It's not an original thought I know but I really wonder how this RfC could've been so much different had A) @OVasileva (WMF) and @SGrabarczuk (WMF) told people about this gadget in the first place and B) were way more open about the idea of making width options in the opening of the RfC. I tried the wide Vector 2022 gadget for a week or two and was pretty happy with it, but ultimately went back to Monobook due to other issues I have with V2022. ♠JCW555 (talk)♠ 21:05, 25 September 2022 (UTC)[reply]

It may have swayed more people who were primarily thinking from an more "power editor" perspective, but not those who are more considering readers and casual editors. — xaosflux ^Talk 21:19, 25 September 2022 (UTC)[reply]

What do logged out readers think?

One flaw I do see with this RfC is that it has mainly garnered attention from those that are logged in, mainly editors signed up for RfCs. I don't see much about what those that are logged out think. We need to remember that we (the <20% of users that make up >80% of the edits) are deciding something that will affect all readers. If we switch, and a lot of logged out users find the changes jarring, then they may find it harder to use the site. If we don't switch, and a lot of logged out users find it difficult to navigate an article, then they may find it harder to use the site. We also live in a world where misinformation is rampant and sites that look ugly have facts whereas sites that look pretty have fiction. I sometimes find myself Ctrl-F'ing stuff on Wikipedia as well because some Wikipedia articles get very long and it becomes difficult to find information on a specific subtopic of a topic. Aasim - Herrscher of Wikis ❄️ 19:08, 25 September 2022 (UTC)[reply]

I also do wonder if this RfC should maybe be advertised on MediaWiki:Sitenotice and MediaWiki:Anonnotice to try to cast a bigger net than the RfC currently has. Aasim - Herrscher of Wikis ❄️ 19:14, 25 September 2022 (UTC)[reply]

@Awesome Aasim, I was thinking along the same lines. I've only seen onetwo IP editor (there may be more) !vote. — Qwerfjkltalk 20:03, 25 September 2022 (UTC)[reply]

@Qwerfjkl For something that will affect all the readers of the site, we ought to hear their opinion on the new design. This is not something like an infobox where we decide on the fly what parameters should be there or what layout should be used. This is even bigger as it can fundamentally change the usability of the site for better or for worse. We can all have our opinion on the modern web but I think it is important to follow reader expectations. Hell, that is even why I suggested switching to flat icons in the first place (to the dismay of a bunch of experienced editors that hated it). If we do not engineer for the third and fourth decades of the 21st centuries, we could experience drops in readership. To be blunt, Wikipedia needs to change with the times, but it should be the ones leading this change, not lagging behind. Aasim - Herrscher of Wikis ❄️ 23:16, 25 September 2022 (UTC)[reply]

Another problem is that the people who lived with Vector 2022 for many months (in the locales were it was set as the default) aren't going to come across this and voice what I expect would be a large majority of support.

I absolutely hated Vector 2022 at first when I saw it on another country's Wikipedia, and switched it back to the old one, but after browsing Wikipedia some more I realized how indispensible the always-visible ToC was, and how much nicer it was to have consistent page widths, and I ended up opting-in even on en.WP. Polling people for their opinion on a new design is a process with documented flaws; it's like polling people on car features, where you end up with Homer's Car. Preferences are revealed through behavior, not stated. I suspect most people would get used just fine to the new design, like I did, and, like me, would come to absolutely hate the old skin if they tried switching back. I literally can't use Vector legacy anymore. DFlhb (talk) 23:58, 25 September 2022 (UTC)[reply]

@DFlhb That is a really excellent point. One thing I would almost certainly support more strongly than what is being proposed right now is A/B testing, if it is not being done so already.

Here is how this might work: Half of the visitors to EN Wikipedia would get a cookie specifying the new Vector, and half would get a cookie specifying the legacy Vector. As for logged in users using Vector, one third of logged in users would be locked to the old Vector, one third of logged in users would be locked to the new Vector, and one third would have the option to switch between the two as they please. Granted, this may break user scripts, but as user scripts get updated to work on new Vector, this could change. A selection of logged out users would be asked to rate their experience on Wikipedia after some time. It can also be recorded how many users switched from new Vector to another skin, how many switched from old Vector to another skin, and which Vector the control group preferred.

I don't think it is enough to just make observations to determine what people prefer. The charts and data presented by WMF just show that new Vector is used by 36% of all wiki communities and that there are some benefits that new Vector has that legacy Vector does not have. I switched from legacy Vector when Timeless came out in 2018 because legacy Vector did and still does not seem ripe for the changing web and design. Unless if logged out users will be able to comment on whether Vector 2022 should be deployed, this A/B testing before deployment would be far more helpful in giving a definitive answer whether this skin is ready than just opening an RfC. Aasim - Herrscher of Wikis ❄️ 02:51, 26 September 2022 (UTC)[reply]

I added a few images to the top showing Vector 2022 and Vector legacy in desktop and mobile views as would appear on a mobile device (i.e. F12 dev tools then selected the mobile phone/tablet). It becomes quite clear why we do not use Vector legacy as the skin on mobile frontend. On the other hand, Vector 2022 is a good skin candidate for mobile frontend. However, I think in the future mobile frontend can be completely deprecated by Vector 2022. Aasim - Herrscher of Wikis ❄️ 03:18, 26 September 2022 (UTC)[reply]

@Awesome Aasim That would be awesome! It's crazy to me that WMF even went with building a maintaining a separate mobile skin to begin with. You can easily build websites nowadays that function well and look the same for both mobile and desktop. Lectrician1 (talk) 03:22, 26 September 2022 (UTC)[reply]

If we do something that greatly improves Wikipedia to the point other websites follow in our tracks, then we will have done something excellent for the modern web. On the other hand, if we are simply following what for-profit companies like Google and Microsoft say just so we can end up with better usability, then we are not doing much than just copying. I can see in the design that one of the inherent goals of 2022 Vector is responsive design, where changing the size of the window or even the device affects the layout so it remains usable. There are also semi-ambitious goals with progressive web apps and new discussion tools like the one I am using right now. Hopefully we can get to the point where we lead the change, not lag behind it. Aasim - Herrscher of Wikis ❄️ 23:24, 25 September 2022 (UTC)[reply]

Well it's incredibly unscientific, but I shared it around with my friends and asked for their views. People liked it overall and were positive about the new TOC and mobile view. One person said they felt the sidebar was too wide relative to the rest of the page.

However, one thing I have noticed is that the previews are different for logged in users and non-logged in visitors. Notably, there's a sticky top bar with search and other icons when logged in, which isn't present when logged out. Which format is being proposed as final? Jr8825 • Talk 03:15, 26 September 2022 (UTC)[reply]

Hi @Jr8825 - thanks for the question. Right now, the sticky header is only available for logged-in users as a lot of the functions within it - access to the user menu, talk page, history page, etc were build with an editing workflow in mind. That said, we've also discussed implementing it for people that are logged-out as well as a means of introducing them to some of this functionality. OVasileva (WMF) (talk) 12:11, 26 September 2022 (UTC)[reply]

Thanks for clarifying! Jr8825 • Talk 13:57, 26 September 2022 (UTC)[reply]

Readers vs editors

I agree that this is an issue. Most users of Wikipedia are readers—most readers never comment on talk pages, let alone RfCs—most (but not all) changes to Vector 2022 are intended to make the experience better for readers—everyone commenting here is an editor, not a reader. This disconnect *is* a big problem for this RfC and I'm not sure how it can best be addressed. Editors have a lot of power here, naturally—they're the ones who show up to discussions like this. It would be unfair to implement this change unilaterally against the wishes of a clear majority of editors, if it shakes out that way, but it would also be unfair to ignore that editors are a tiny minority of those who use the site. (comment copied from above) —Ganesha811 (talk) 04:24, 26 September 2022 (UTC)[reply]

My reason for the "cautious support" above is that the skin still needs more work in order to be ready for readers on mobile devices, but at the same time it is much much better than the current solution that we have with two separate interfaces, one for desktop and one for mobile. Aasim - Herrscher of Wikis ❄️ 11:50, 26 September 2022 (UTC)[reply]

@SGrabarczuk (WMF): how does the WMF get feedback from readers? S0091 (talk) 19:45, 26 September 2022 (UTC)[reply]

Most articles are not being tested for the variety of screen resolutions and skins. Therefore, the optimal experience for the reader is most likely to see the article as close to the editor's view as possible. A default reading view shall be thus acceptable to the overwhelming majority of editors, and the designers should keep accommodating the editor's requests until they can get almost everyone to switch, even at the cost of theoretically degrading the new reader's experience, since in practice these readers will gain from sharing the interface with the editors. --Викидим (talk) 12:55, 27 September 2022 (UTC)[reply]

Some new user testing

One of the problems with usability testing is that once you understand something, it's impossible to look at it through the eyes of a first-time user again. So to get a fresh perspective, I asked my wife (who reads a lot, but very rarely edits) to try this. Basically I set her up then left her alone for a few minutes. Her first comment was, "The table of contents box is gone". The issue was that it wasn't visible because it was in the left-hand navigation column, but the main menu had taken up the entire visible vertical space, so the TOC wasn't visible until she scrolled down. Beyond that, she said it's "Not much different, but looks kind of modern". She didn't initially have anything to say about the width issue, but when I prompted her to make the window wider, she immediately noted that the text wasn't expanding to use the full width and said, "If you pull your window wide, maybe there's a reason you're doing that". -- RoySmith (talk) 12:47, 26 September 2022 (UTC)[reply]

Old habits, die hard

We've got the three subsections named Support, Oppose & Neutral. There's no need for editors to emphasise their positions with those 'words' in their posts, as their posts are already under those respective subsections. PS - So far, the neutral editors realise this. GoodDay (talk) 14:01, 26 September 2022 (UTC)[reply]

That is a fair point. Although usually most !votes don't have those sections separated so it's probably why we still do it (and also it allows users to indicate whether they strongly oppose/support something or weakly oppose/support something). I notice the same thing at WP:RFAs. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:04, 26 September 2022 (UTC)[reply]

It makes it clearer to see which section the comment is placed in, when the top of the section is off the screen. Also it allows use of strong or weak support/oppose. — Voice of Clam 15:32, 26 September 2022 (UTC)[reply]

Somewhat ironically, you can use the floating ToC for this, as it boldens the section you're in. — Qwerfjkltalk 15:52, 26 September 2022 (UTC)[reply]

Criteria for choosing a default skin: what question are we really trying to answer here?

I see a disturbing number of comments in both the Support/Oppose sections that focus on "this works for me" or "this doesn't work for me". Since any person with an account (i.e. almost everybody commenting here) can set their own skin preference and current Vector is not going away, it seems to me these !votes should not be given much weight. The question we're trying to answer is what skin should be the default for readers and new accounts. To give a related example, it's long been recommended wisdom to avoid "I like it" or "I don't like it" in article deletion discussions. Unless we largely discount comments just expressing their personal preference, this discussion is not a legitimate consensus for or against the default for millions of readers. Steven Walling • talk 02:23, 27 September 2022 (UTC)[reply]

@Steven Walling: I agree and I actually encountered an IP who stated that they mostly just read Wikipedia articles and I asked them if they could use Vector 2022 and they give their opinion on it here since I feel it would be nice to get the opinion of a reader since usually it's pretty hard to get them to participate in an RFC since, well, they prefer just reading the articles. Maybe if it were some sort of poll they would participate but I don't think that's something we can set up on Wikipedia. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 02:27, 27 September 2022 (UTC)[reply]

I'm not sure on what other basis we're supposed to make a decision, though? With normal RfCs, arguments are grounded in the huge body of existing policies and guidelines we've built up on how to write a good and realiable encyclopaedia. We have no policies or guidelines on how to design a good-looking and usable website, because that's not our job, it's the WMF's. I really question the wisdom of putting this to an RfC, really really question making it yes-no, and really really really hope the web team have a back up plan here. Their years of hard work shouldn't be thrown out because a miniscule subset of our users think that wrapping lines of text at a reasonable length is a bad thing. – Joe (talk) 06:21, 27 September 2022 (UTC)[reply]

@Steven Walling: I disagree - I think this is one occasion where WP:ILIKEIT/WP:IDONTLIKEIT is a valid argument. There seems to be a majority of editors above who don't like it, and if this is a representative sample of the majority of users (i.e. day-to-day readers, who don't edit and are probably unaware of the proposed change) then forcing them to use an unpopular skin is not going to go down well. Remember that people without an account make up the vast majority of Wikipedia users, and they have no option to change preferences. — Voice of Clam 07:31, 27 September 2022 (UTC)[reply]

I agree with Voice of Clam here. The skin wastes horizontal space for no good reason on desktop, and non logged in users have no option to avoid it. Newystats (talk) 07:41, 27 September 2022 (UTC)[reply]

But there is really no reason to believe that editors are a representative sample of users. 99% of people who use Wikipedia don't edit, let alone go deep enough to comment on RfCs. Editors are here frequently and use the back end of the site a lot. Our opinions are important, but I'm unconvinced we are similar to most Wikipedia users, who are primarily casual readers. As I understand it, this skin is designed mostly to improve the experience of reading Wikipedia, not editing Wikipedia. The problem is finding a way to judge the opinion of the vast, silent majority: readers. —Ganesha811 (talk) 11:29, 27 September 2022 (UTC)[reply]

Precisely Ganesha811. Editors are very different than casual readers in how we use and view the site, and are not a good representation of what an ideal reading experience looks like. The fact that statistically significant increases in readers efficiently navigating article content happened during randomized tests is way more important than any one person's preference. It proves that how people actually behave when given the new skin was that they can read articles with less wasted scrolling. That means it does a better job of accomplishing our ultimate goal, which is to give people easy access to knowledge. Steven Walling • talk 14:26, 27 September 2022 (UTC)[reply]

I personally feel we are answering more questions about English Wikipedia than about the skin ;) —TheDJ (talk • contribs) 09:28, 27 September 2022 (UTC)[reply]

LOL, true. I agree with Steven: a great number of editors (both supporting and opposing) are answering the question "do you like it?" rather than the question actually posed ("should it be the default"). But we see this phenomenon throughout Wikipedia discussions, it's the familiar downside of democracy. My favorite !votes are the ones that recognize that this is industry-standard practice (that all websites do this), but still don't think we should do it because they personally don't like it. It's the elevation of preference over data, and it's why I said in my !vote I hope the WMF ignores some (many, really) of these !votes, or at least that it doesn't end up making design decisions based on the preferences of editors. Levivich (talk) 14:41, 27 September 2022 (UTC)[reply]

Making Vector 2022 accessible

Government websites in Croatia, and I'm sure in many other countries too, offer users options to resize text, change font or otherwise adapt the view to their needs. For example, visit https://gov.hr or https://vlada.gov.hr and try the links at the top right side of the screen. I've noticed a lot of sites have started offering such features since the late 2010s, this is an important bandwagon to get onto. We need to implement a similar set of options to make our interface (whether Vector 2010 or 2020) accessible to all readers, instead of trying to make an informed guess of which size fits the largest minority.

For instance, I noticed that several months ago the text size was increased in Special:Search results on Vector 2010. To me personally, this is a net negative. Less items fit on each screenful, and it is harder to make out at a glance which lines are article titles and which are context. However, to someone who had problems reading the old text size, this is obviously an improvement. I suggest accomodating both users. Letting unregistered users choose their skin would be an inexpensive way to start. Daß Wölf 14:54, 27 September 2022 (UTC)[reply]

If we were able to deploy new skins, then maybe adding such features would become a bit easier :) —TheDJ (talk • contribs) 15:05, 27 September 2022 (UTC)[reply]

The discussion above seems to suggest otherwise, on both counts. A number of people commented that if this were a set of less drastic changes (mainly not forcing the controversial width change as default), it might not even require an RFC. Adding features like this does not count as "deploying entirely new skins". On the other hand, some skin-deployers suggested that allowing unregistered users to set interface prefs is out of scope for them and not on the roadmap (though @Enterprisey:'s suggestion above seems it may get around the cache multiplication concerns). – SJ + 16:20, 27 September 2022 (UTC)[reply]

@CaptainEek: mentioned Wikiwand, which is fantastic. I use it sometimes. It's one of the reasons that I don't think this change will be great for readers; Wikiwand targets a purely reading audience (and has done for 8 years), it has its own excellent design sense, and it has preserved our current (relatively unusual on the modern web, but effective) full-width text layout. It would be interesting to talk to @Lior Grossman: and their design team about usability and the work they've done over the years to engage with and optimize for their readers. – SJ + 16:28, 27 September 2022 (UTC)[reply]

See, I take the opposite track. The fact that Wikiwand exists signals that our existing interface is *not* reader friendly. So I welcome any improvements in reader quality. CaptainEek ^{Edits Ho Cap'n!}⚓ 16:45, 27 September 2022 (UTC)[reply]