Wikipedia:Requests for comment/Deployment of Vector (2022)

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)

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).

• Top of an article
• 
  Vector legacy (current default), logged-out
• 
  Vector 2022, logged-out
• 
  Vector 2022, logged-in
• 
  Vector 2022, logged-in, wide screen

• A section of an article
• 
  Vector legacy (current default)
• 
  Vector 2022, logged-in

About this RfC

Current usage of non-default skins on English Wikipedia as of August 30. The number for Vector 2022 is growing

This is an RfC written by the Web team at the Wikimedia Foundation, 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!

Key Results (summarized by the web team)

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.

Discussion

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)

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.")

• 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)
• 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)
• Support Andre🚐 16:28, 22 September 2022 (UTC)
• 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)
• Strongly Support My only skin for all my accounts on all Wikimedia wikis. Zippybonzo | Talk (he|him) 17:01, 22 September 2022 (UTC)
• Support at this time. Will keep monitoring. --SarekOfVulcan (talk) 17:17, 22 September 2022 (UTC)
• 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)
• Support. It's a more simple design than the previous skin. Agusbou2015 (talk) 18:41, 22 September 2022 (UTC)
• 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)
• Support - Not anywhere near perfect, but good enough. Schierbecker (talk) 19:09, 22 September 2022 (UTC)
• 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)
• 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)

  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)

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

  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)

• 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)
• 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. I believe it should be enabled globally as soon as possible. Betseg (talk) 20:52, 22 September 2022 (UTC)
• 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.
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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.

  

  Scroll bar; only part of the TOC visible on screen. Blank space below it where the rest of the TOC would fit. Why not show more of the TOC there?

  Adumbrativus (talk) 04:38, 23 September 2022 (UTC)
•  Support, works a lot better for me than 2010 Vector on my tablet. — Qwerfjkltalk 06:13, 23 September 2022 (UTC)
• 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)
• Support A strong improvement in reader experience (I already used it in Vietnamese Wikipedia) Thingofme (talk) 08:41, 23 September 2022 (UTC)
• Support. Love the new TOC. I also want to figure out how to enable pinned tools.. 0xDeadbeef 09:21, 23 September 2022 (UTC)

  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)

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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 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 timely look. I'm frankly baffled to see how strongly editors are defending the old Vector's garishly large page width; "Humans are resistant to change" rings true, doesn't it? The same flock of 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)
• 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)
• 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)
• 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)

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)

• 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)
• 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)
  • 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)

    @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)

    • 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)

      @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)

      • • 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)

        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)

      @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)

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

      @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)

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

      File:Screenshot of English Wikipedia Pluto article in Vector 2022 skin - 2180px.png

      2180px width screen of Pluto

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

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

      

      Vector 2022 screenshot width comparison

      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.

      

      Vector 2022 with article tools pinned

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

      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)

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

      @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:

      

      Vector 2022 with article tools pinned (1453px)

      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)

      @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)

      

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

      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)

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

      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)

• 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)

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

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)

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)

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)

@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)

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)

@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)

• 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)

  @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)

  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)

  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)

  @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)

  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)

  @ElKevbo thankfully there is plenty of empirical research:

  • https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf
  • https://baymard.com/blog/line-length-readability
  • https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0071161
  • https://www.researchgate.net/publication/252707646_The_Effects_of_Line_Length_on_Children_and_Adults'_Online_Reading_Performance
  • https://laurenscharff.com/research/textmargin.html

  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)

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

  @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)

  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)

• 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)

  "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)

• 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)
• 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)
• 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)

  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)

  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)

  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)

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

  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)

  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 - 2180px.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)

  @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)

  @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)

• 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)

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

  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)

  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)

  @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)

• 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)

  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)

  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)

  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)

• 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)

  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)

• 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)
• Oppose. Too much whitespace wasting screen real estate. Useight (talk) 20:55, 22 September 2022 (UTC)
• 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)

  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)

  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)

  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)

  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)

• 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)

  @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)

• 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)

  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)

  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)

• 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)

  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)

  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)

• 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)
• Oppose - Looks bad in my opinion, doesn't seem like an improvement. Waxworker (talk) 21:43, 22 September 2022 (UTC)
• Oppose Too narrow and too much annoying white space on both sides. AhmadLX-(Wikiposta) 21:46, 22 September 2022 (UTC)
• 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)

  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)

  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)

• 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)

  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)

  @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)

• 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)

  @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)

  @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)

  @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)

  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)

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

  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)

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

  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)

• 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)
• 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)
• 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)
• 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)

  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)

• 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)
• 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)
• 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)
• 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)

  • 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)

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

    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)

• 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)
• Oppose - for hiding the cross-project links. dwadieff ✉ 03:21, 23 September 2022 (UTC)
• 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)
• 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)
• 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)

  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)

• 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)

  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)

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

  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)

  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)

• Oppose looks inappropriate. The current is much better.--Sakiv (talk) 08:43, 23 September 2022 (UTC)
• 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)
• 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)
• 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)
• 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)
• (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)
• Oppose The only redesign element that I like in vector 2022 is the floating toc. Also, the width of left panel is too big, especially for smaller screens. And, the new skin doesn't show elements added by scripts like User:Lourdes/AfDList or User:ZLEA/Dashboard. — hako9 (talk) 13:18, 23 September 2022 (UTC)
• 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)
• Oppose - the fixed width is a dealbreaker for me. ♠PMC♠ (talk) 14:30, 23 September 2022 (UTC)
• 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)
• 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)
• 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)
• 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.[2] 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)

Support after the implementation of a built-in width option

• Support - Second choice. ♠JCW555 (talk)♠ 22:27, 22 September 2022 (UTC)

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)

  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)

• 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)
• 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)

  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)

  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)

  @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:

  

  Vector 2022 with article tools pinned

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

  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)

• 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)

  @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)

  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)

• 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)

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

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

• 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)

  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)

  @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)

  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)

  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)

  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)

  @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)

• 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)

  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)

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

  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)

• 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)
• 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)

  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)

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

  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)

• 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)

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)

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)

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:

Why have you replaced the area used for content by an empty space?

Reading efficiently and comfortably is crucial to most people using our projects. Our goal here is to improve the readability of the content. There are several factors that affect it – i.e. font size, contrast, font, line length, and empty space.

Shorter lines

1. When reading short lines, readers don't move their eyes too much, use the eye's muscles less intensively, thus avoiding eye strain.
2. Narrow paragraphs allow readers to memorize new information better.
3. On websites, there should be between 35 and 100 characters per line. Numbers closer to the smaller end are preferred.
4. 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.

Empty (white) space

1. White space is used for the eyes' resting spots. It helps readers focus on content and increases content comprehension by 20%.
2. People are able to focus more easily without the distraction of sidebars or other elements.
3. We are using some of this space for other functionality. We have made the sidebar sticky, and have placed the table of contents next to the content. Also, limiting the content area gives us new options for the more distant future. Community members have suggested to put infoboxes, images, or references there. As a separate project, we will consider ways of using this space.

See also:

• UX Myth #28: White space is wasted space

Why can't we leave it for readers to narrow their browser windows down?

Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. Wikis should be good-looking immediately, in their basic form.

Some tables and templates don't fit within the limited width

We should make sure that all of our content is as responsive as possible to accommodate all visitors. A large percentage of our users, who don't have large screens and are accessing Wikipedia from their laptops, already had issues with tables and templates even before the change.

Why didn't you make it a setting from the beginning?

We wanted this to be default for everyone. We are building a common experience that is shared between editors and readers. This could be helpful to editors when making decisions about page layouts. Currently an editor might be editing a page at a width of 1500px, while a reader reads it at a width of 1200px. By implementing a limited width we don't remove this discrepancy (because there would still be variation below the max-width, for people with narrower screens), however we would be greatly limiting the range of variation.

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)

@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)

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)

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)

@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)

@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)

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

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)

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)

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)

@ElKevbo, not sure if you saw my comment above so re-posting here: thankfully there is plenty of empirical research:

• https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf
• https://baymard.com/blog/line-length-readability
• https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0071161
• https://www.researchgate.net/publication/252707646_The_Effects_of_Line_Length_on_Children_and_Adults'_Online_Reading_Performance
• https://laurenscharff.com/research/textmargin.html

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)

@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)

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)