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

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 22:34, 22 September 2022

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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

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

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

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

About this RfC

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)[reply]

Support

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

Support - While I still think there are issues (width being the primary one), it's about time we updated the default skin. Vector 2010 is starting to show its age. Anarchyte (talk) 16:24, 22 September 2022 (UTC)[reply]
Strong Support - the 2022 skin is not perfect, but the 2010 skin is much farther from perfect. The English Wikipedia community is conservative by nature, but I hope we will adopt this needed change to benefit readers and editors alike. —Ganesha811 (talk) 16:28, 22 September 2022 (UTC)[reply]
Andre🚐 16:28, 22 September 2022 (UTC)[reply]
Support not interested in using it myself, but I do think it is likely to be more user-friendly for beginners. (t · c) buidhe 16:44, 22 September 2022 (UTC)[reply]
Strongly Support My only skin for all my accounts on all Wikimedia wikis. Zippybonzo | Talk (he|him) 17:01, 22 September 2022 (UTC)[reply]
Support at this time. Will keep monitoring. --SarekOfVulcan (talk) 17:17, 22 September 2022 (UTC)[reply]
Support: I have been using it for a while now, I think that it is an improvement overall and think it would benefit logged-out readers in particular to have this as default. Terasail ^[✉️] 17:37, 22 September 2022 (UTC)[reply]
Support. It's a more simple design than the previous skin. Agusbou2015 (talk) 18:41, 22 September 2022 (UTC)[reply]
Support; I'm using it for almost a year now on all projects, and find it clearly fit for use as default skin for all users—including particularly unregistered readers. —MisterSynergy (talk) 19:02, 22 September 2022 (UTC)[reply]
Support - Not anywhere near perfect, but good enough. Schierbecker (talk) 19:09, 22 September 2022 (UTC)[reply]
Strong support: Vector 2022 is an extreme improvement in readability and look that is strongly needed in 2022. People come to Wikipedia because they know it has the information they're looking for. The only reason they might go to another website is because that site might present the information in a more digestible way. The current unconstrained width of Wikipedia with its extremely long line lengths makes reading uncomfortable and you feel like you're thrown a ton of information at once. Vector 2022 solves all of this and has been a great experience to use. Second, the simplified user interface with the sidebar hidden by-default, the user-account menu in the upper right being collapsed, and the new languages browser allow the user to not be distracted by elements that they 99% likely do not use yet still provides great iconology to promote to users that the features are still available. I especially like the larger "Create account" button. The positive effects of these changes is supported by the proposal's statement above, "There is observational evidence of increases in pageviews and account creation across partner communities.", which should be a green flag to the community that these changes will actually grow the movement. Finally, it's table contents improvements are life-changing compared to the old table contents which looks awful and has been an extreme pain to users for a number of years because it completely blocks the flow of the article. The proposal above states that through testing this has had the dramatic benefits of "decreases scrolling to the top of the page by 16%" and "Readers and editors jumped between sections 50% more". Vector 2022's improvements will show to typical readers that Wikipedia is an evolving resource and not just a static resource that looks like it's from 2010 and run by nerds. Lectrician1 (talk) 20:19, 22 September 2022 (UTC)[reply]
Support We don't own Wikipedia and the WMF can do whatever it wants on techincal matters --Guerillero ^{Parlez Moi} 20:22, 22 September 2022 (UTC)[reply]
This page is a request for comment, WMF Is asking the community for their opinion on the changes. If WMF were to truly do whatever it wants with no control, we would not be at this point today at all. PerryPerryD Talk To Me 20:24, 22 September 2022 (UTC)[reply]
Support. The table of contents on the left side of the Vector 2022 skin is a much better use of space than the blank bar in the Vector legacy skin. Being able to see where you are in the article and being able to jump from section to section without needing to scroll around is a massive usability improvement for our readers. — Newslinger talk 20:28, 22 September 2022 (UTC)[reply]
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)[reply]
Very weak support I could potentially get used to it with MediaWiki:Gadget-wide-vector-2022.css in place, but it wasn't obvious to be at first what the very top-left button did in terms of the left-hand side-bar. -Kj cheetham (talk) 20:57, 22 September 2022 (UTC) P.S. I don't like how it takes two clicks to get to pages like Contributions or my own Talk page though. -Kj cheetham (talk) 20:59, 22 September 2022 (UTC) P.P.S. Just noticed there even seems to be extra whitespace at the very bottom of the pages for some reason too! I also think the visuals of the tabs are worse than the previous Vector. This skin has potential, but it needs more work.[reply]
Sure, I use monobook anyway so I don't really care about the aesthetics personally. As a matter of web design, I think it implements a number of improvements such as a sticky TOC that will help readers navigate and a more minimalist design that modern readers will be more familiar with. If the devs think it's ready to deploy, then go for it, but I'll probably still use monobook myself. — Wug·a·po·des 20:57, 22 September 2022 (UTC)[reply]
Strong support the improvements made through Vector 2020, while not yet perfect, are definitely a step in the right direction and are better than the status quo of Vector 2010. Although I was sceptical of Vector 2020 when it was first an option, I now have it as my skin on all wikis as I find it much easier to use and less cluttered. I do have the gadget that removes the narrowed viewing space, but for readers I definitely see the benefits of this. Dreamy Jazz ^{talk to me | my contributions} 21:53, 22 September 2022 (UTC)[reply]
As long as an easy way (a gadget is one) exists for disabling the width limitation, support per the arguments provided in the proposal. ~ ToBeFree (talk) 22:03, 22 September 2022 (UTC)[reply]
Strong support I mostly use Wikipedia on my laptop in large windows; but when I make the windows smaller, the always-visible sidebar makes it practically unusable. It's also hard to overstate just how much better the 2022 layout is, for example on the iPad (without Safari's forced desktop view); previously, each section needed to be expanded manually, and it behaved like a true mobile site; with the 2022 design it behaves far better. I initially didn't like the 2022 design on another early-deployment Wikipedia, but I've since turned it back on and it just looks cleaner. Also absolutely love the ToC sidebar; makes it far easier to navigate articles. Fantastic change. DFlhb (talk) 22:18, 22 September 2022 (UTC)[reply]
Support. I think articles are a bit easier to read with this skin. Overall, it looks cleaner while still "feeling" like Wikipedia. As far as default display design changes go, this is pretty mild and hard to find fault with. Pyrrho the Skipper (talk) 22:23, 22 September 2022 (UTC)[reply]

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)[reply]
The width of the screen is a deal-breaker for me. I have opted out of Vector 2022 globally because of this. --Rs chen 7754 18:04, 22 September 2022 (UTC)[reply]
- I am also concerned that the screenshots at the top of the RFC do not adequately illustrate this problem, and this is not clearly disclosed in the RFC descriptions either. --Rs chen 7754 18:06, 22 September 2022 (UTC)[reply]
  @Rschen7754, could you elaborate if this is more about your personal preference (which is fine, that's why there's a gadget disabling the limited width for individual users) or anything broader? Note that it's been working on 30 different wikis, so I'd really like to figure out what issue related to the limited width you're most concerned about. SGrabarczuk (WMF) (talk) 18:17, 22 September 2022 (UTC)[reply]
  - Look at pages like this - the limited ability to use the screen width means a lot more scrolling to use the table. Not to mention that for editors, the limited screen width is a significant handicap. --Rs chen 7754 18:25, 22 September 2022 (UTC)[reply]
    @Rschen7754, there are at least two different issues to unpack: wide tables that get narrowed down, and the editing experience. We need a bit of time to address the first issue. Regarding the second one, in the editing mode, the limited width is disabled - both in VisualEditor and the wikitext editor. That seems to be an effective solution. What do you think? SGrabarczuk (WMF) (talk) 18:50, 22 September 2022 (UTC)[reply]
    
    @SGrabarczuk (WMF): in the live version, the right-side whitespace gutter is about the same size as the left side gutter on my screen, but in the screen shot File:Screenshot of English Wikipedia Pluto article in Vector 2022 skin.png the right-side gutter appears to be cropped to about half of that width. — xaosflux ^Talk 18:38, 22 September 2022 (UTC)[reply]
    Compare to File:Pluto full screen vector 2022 2022-09-22.png. — xaosflux ^Talk 18:41, 22 September 2022 (UTC)[reply]
    @Xaosflux - thanks for flagging this. We didn't crop the images - this is just due to the size of my window when I was taking the screenshot - should roughly correspond to the width of the right and left sidebars at 1400px (most 13 inch screens). We can potentially add some additional images for screens of different sizes or highlight/bold the "try it out" link to encourage people clicking on that. OVasileva (WMF) (talk) 19:07, 22 September 2022 (UTC)[reply]
    For reference, this is how the Pluto article looks for me, it has a width of 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)[reply]
    
    @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)[reply]
    Out of curiosity, how does it look with the article tools pinned on a 1453 px-wide screen? — Red-tailed hawk _(nest) 19:45, 22 September 2022 (UTC)[reply]
    
    Yes, thank you for the updates. — xaosflux ^Talk 20:08, 22 September 2022 (UTC)[reply]
    @Red-tailed hawk, both the table of contents and the article tools menu can be "pinned" or hidden, so there are a few different options for how can look. However here's the direct comparison of what I shared above:
    
    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)[reply]
    
    @SGrabarczuk (WMF):, sorry to join this thread - happy for it to move to discussion. I gave new vector another go on en-wiki and tried different variations of the gadgets/scripts in the repository (the wide-2022 gadget, and Quiddity's, and both), but none of them were widening it out to the full width (assuming I still want the sidebar, which of course I do). This rather stresses my point in discussion. We need full width control, ability to have TOC in the sidebar, on the page, or in both.
    
    With regard to new editors (really the nexus of this RfC), Vector2022 causes major problems for articles with wide tables, and articles with pictures on both sides. I've not seen any solution to the first in place yet and any solution to the latter looks like it will take a huge amount of community time. Nosebagbear (talk) 20:39, 22 September 2022 (UTC)[reply]
Oppose. First, the most important thing to consider is the experience of the reader, and per a survey conducted by the WMF they find new format skin harder to use than the current skin as can be seen on the graph below. This means that we should reject the change at least until there is an easy way for non-logged in readers to revert back semi-permanently to the current skin.

The chosen width of the page is another issue; it is important to consider how the width affects the perception of Wikipedia, as we want to be perceived as a broadsheet, not as a tabloid, and this width change is unlikely to have a positive impact on this perception. It has also resulted in a unsightly gap between the left hand navigation bar and the content, while reducing the space available for content that need to utilize large amounts of space on the page, such as larger tables, charts, and panoramas.

Elsewhere on the page, the position of coordinates and icons have been usurped. While it is possible that this decision is an improvement, these content decisions should not be made without closer discussion with enwiki, and we should not approve the implementation of this skin until we are satisfied with the new location for coordinates, or until the decision to usurp their position is reversed.

Other issues also exist. For example, there has been no investigation of what highly used scripts will be broken, and the testing of the various features has been insufficient at times, with features such as the sticky header only being tested in such a way to see whether they are in use, rather than whether they improve the user experience. BilledMammal (talk) 19:12, 22 September 2022 (UTC)[reply]

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

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

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

@BilledMammal, thank you for bringing this up.

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.
I would also like to gently push back against your example of the sticky header. The data shows that the sticky header decreases scrolling to the top of the page by 16%. This is behavior that is due to people using the sticky header, but is not just showing that people are using it - they could use it and still scroll just as much as before. In that case, we would not consider the feature a success.

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

Oppose until the developers can assure us that the fixed width/width limitation will be removed in the near future and is not deeply baked into the layout or otherwise unfixable. I accept that the new skin cannot be perfect but this violation of a fundamental usability principle does not inspire confidence so I have to know that this is a problem that can and will be addressed. ElKevbo (talk) 19:28, 22 September 2022 (UTC)[reply]
@ElKevbo, why do you consider this a violation of a fundamental usability principle? What principle are you referring to? I'd be grateful if you could elaborate. SGrabarczuk (WMF) (talk) 19:39, 22 September 2022 (UTC)[reply]
Not forcing unnecessary white space around the contents of a webpage and wasting available screen space is a pretty old and fundamental design principle for webpages. I'm sure that you can find a lot of information if you look for "fluid" designs and look into some of the history of HTML and CSS that emphasized this idea; for example, "Use a liquid layout" is one of the design guidelines explicitly enumerated by Jakob Nielsen all the way back in 2001. ElKevbo (talk) 20:14, 22 September 2022 (UTC)[reply]
It's funny that you're referencing a recommendation for home pages, which is closer to Google or in the time of that advice, our main page.

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

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

(My enumeration.) Note how items 1, 3, and 4 all point to a better experience for our readers. Izno (talk) 20:40, 22 September 2022 (UTC)[reply]
@ElKevbo thanks for your concern. To note: the article you pointed out is from 2001, at which time the most common monitor size was 1024x768 (link). To put it simply: people had not started to study, or design for, how to handle text on large monitors because they were not in use. Today research on this point, line length for optimally readable text, is very clear. If you look around the internet at popular content websites — The New York Times, The Lancet, Reddit, The World Health Organization, Baidu, Medium, or any other that you would like to choose — you will find that they all have width limitations on their content. If you look at newspapers, books, and magazines, you will find the width of the text all falls within the same range. The approach is standardized for good reason. This is not something we are reinventing, or making a guess at. It is a clearly established best practice. Thanks, AHollender (WMF) (talk) 21:22, 22 September 2022 (UTC)[reply]
I appreciate these responses. Without support from empirical testing - not just opinions - I am not willing to change my !vote. I appreciate that you may not want to look for and provide links to that research for one editor. I am simply extremely wary of changes or decisions made in web design at this scale that is not well supported by empirical research. ElKevbo (talk) 21:45, 22 September 2022 (UTC)[reply]
Oppose No-go for me because of the width of the screen. Privybst (talk) 19:35, 22 September 2022 (UTC)[reply]
@Privybst, just to be sure we both understand the context. If it's a no-go for you, meaning, your personal experience, you can opt out and never see it again. We're fine with that, and we don't consider this as a major blocker preventing from enabling Vector 2022 for all the Vector legacy users. However, if you try to use it for a few moments and point out some specific issues, we will be able to address them. Perhaps there's something that could be improved. SGrabarczuk (WMF) (talk) 19:55, 22 September 2022 (UTC)[reply]
No, I believe that the new skin has a very big issue with dead space, which makes navigation extremely difficult and inconvenient. Of course, I opted out globally, but instead, users who want to use this skin have to opt it in. The whole question is what will be the default, especially for unregistered users. Privybst (talk) 20:12, 22 September 2022 (UTC)[reply]
No. (The new Vector is probably technically superior, but the change from the full width main text weakens the brand recognition.) Vecr (talk) 19:33, 22 September 2022 (UTC)[reply]
"Brand recognition" feels like a weird argument here - are we anticipating that people will stop recognising Wikipedia and using it on that basis? Nosebagbear (talk) 19:52, 22 September 2022 (UTC)[reply]
Limiting line length for optimal readability is (somewhat ironically, given the many comments opposing it here) the most well researched topic out of any of the changes we're making. Best practices are clearly established across industries: from websites, to newspapers, to magazines, to books. I invite you to take a look around the internet — The New York Times, The Lancet, Reddit, The World Health Organization, Baidu, Medium, or any other content site of your choosing — to see similar width limitations. Thankfully for us and our readers this is not something we are reinventing, or making a guess at. It is a clearly established best practice. See: Line length#Electronic text, and the referenced articles. AHollender (WMF) (talk) 21:26, 22 September 2022 (UTC)[reply]
Oppose I agree with several people above regarding the screen width, and if the survey results cited by BilledMammal are legit then that is another reason not to move forward with this. PCN02WPS (talk | contribs) 19:45, 22 September 2022 (UTC)[reply]
Rework As of right now, the skin has the major issue of dead space. Everything is too spaced out and it makes navigating hard, especially on 4:3 ratio screens. Until this problem is fixed, I highly advise to not roll out the skin. ElusiveTaker (talk) 19:49, 22 September 2022 (UTC)[reply]
Hell no!. I may be opposing on limited information, but having just compared the 2022 version alongside the 2010 version among other defects I found the weird, faint, purplish colour/font of some Wikilinks and "edit source" all but unreadable. I also fail to understand why the column width of the 2022 version is significantly narrower than that of 2010 - it looks for all the world like a bug, which I assume it isn't. By all means let us have Vector 2022 as an option, but this is not what we (or, at least, I) want new readers or editors to experience. Gog the Mild (talk) 19:54, 22 September 2022 (UTC)[reply]
The wikilink adjustment actually increases accessibility against the surrounding text; WCAG specifically has a recommendation on it. (NB, I don't like it either, but I have not quite 20/20 vision and no color deficiencies. I assume you are the same.)

I have responded above about the fixed width. Izno (talk) 20:50, 22 September 2022 (UTC)[reply]
I don't really care what policies it ticks, you are proposing that the default version of Wikipedia be one which I assume many users will, like me - this is not hyperbole - find near unreadable and which you do not like yourself! (I assume that you will be voting oppose?) Why should we ram these defects down new users' throats?

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

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

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

Are support voters going to be similarly badgered over their opinions. I do not see badgering here. I do see several corrections of matters of fact and a marked restraint on commenting on matters of opinion for the majority of opposers so far (to wit, I did not attempt to invalidate that you hold an opinion you do). In fact, I made reference to my comment above because I did not want you to assume either a) that I had deliberately not responded to that comment, or b) that I was badgering; badgering would be me posting the exact same comment or having the exact same discussion with every separate user. This is a discussion. If you believe the supports have been inappropriately discussed with, you are more than free to have one in the context of their comment, but I doubt the whataboutism was anything other than rhetorical. --Izno (talk) 21:37, 22 September 2022 (UTC)[reply]
Oppose - The limited width is a no-no for me. _→AzaToth 20:15, 22 September 2022 (UTC)[reply]
Hey @AzaToth, have you had a chance to look at any of the research regarding line-length and reading comfort and comprehension (link to start with)? Thankfully it has been well researched over the past several decades (starting with printed text, and more recently for electronic text). And the findings are quite clear. We think it's critical to offer the best reading experience, based on the research available, to the majority of our readers. People who don't want the optimal reading experience are free to make the text full-width. I'm curious if you have any thoughts once you've had a chance to look through the materials. Thanks, AHollender (WMF) (talk) 21:33, 22 September 2022 (UTC)[reply]
I think we have opposing definition of "optimal reading experience"; I don't feel having to move my eyes back all the time increase the reading experience. And as I showed in File:Screenshot of English Wikipedia Pluto article in Vector 2022 skin - 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)[reply]
Oppose I have used vector 2022 for a while, I found many MANY bugs and issues with it, all that would easily be noticed by people that dont have a wikipedia account, which would cause people to dislike wikipedia more. PerryPerryD Talk To Me 20:18, 22 September 2022 (UTC)[reply]
Please point to specific issues that you think should block deployment. Izno (talk) 20:24, 22 September 2022 (UTC)[reply]
Sure, For 1, the most noticeable, is the fixed screen display, considering that most monitors run at different scales of 1440p, 1080p, fewer, or less (My own monitor runs at 1366x769), Almost every new user to Wikipedia will think "This looks squished and hard to read", When I used vector 2022, I had to ZOOM in onto the page to be able to read it properly.

2. Some bugs I've noticed are in the Preferences buttons, in vector 2022 some buttons can appear to have 2 options selected at once in situations where that isn't possible, i.e. the layout preference.
3. The sudden change may cause severe issues and bugs to scripts and plugins that rely on the design itself. PerryPerryD Talk To Me 20:28, 22 September 2022 (UTC)[reply]
Thanks @PerryPerryD for this comment. For our convenience, I'll address these issues using a numbered list, too:
"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?

Any chance that might have been GlobalPreferences, not local preferences?

We've been working on this skin since three years, and all the time, we've been collaborating with the technically skilled volunteers quite closely. Most popular gadgets and user scripts have been fixed quickly. We may have missed something, though. Have you noticed anything being broken in particular?

SGrabarczuk (WMF) (talk) 20:45, 22 September 2022 (UTC)[reply]
@PerryPerryD, thanks for testing the skin. Would you like to help us identify the bugs? I'd be grateful if you could share what you've noticed so far. SGrabarczuk (WMF) (talk) 20:28, 22 September 2022 (UTC)[reply]
@PerryPerryD thanks for your comments and concerns. I would like to question your assumption: Almost every new user to Wikipedia will think "This looks squished and hard to read". 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? Even if we were to ignore the research for a moment, I have not yet found any other websites that don't use limited width (and in fact all others I've found have a more narrow width limitation that Vector 2022). I am referring to websites like The New York Times, The Guardian, The Washington Post, The Lancet, Reddit, The World Health Organization, Baidu, 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) 21:51, 22 September 2022 (UTC)[reply]
Leaning Oppose - I guess I just don't get why a screen width preference isn't a built-in option without needing gadgets/scripts, and I'm puzzled that the developers/planners of Vector 2022 are seemingly either flat out unwilling to or just very hesitant to implement such an option. When FANDOM announced that they were redesigning their website, the biggest feature requested was a full-width option, and FANDOM did it. When TV Tropes redesigned their website, people wanted a wide load option, and they made it an option. Why the seeming resistance? Also since I'm a Monobook user, I like how the buttons are actual words as opposed to just icons. ♠JCW555 (talk)♠ 20:22, 22 September 2022 (UTC)[reply]
Registered users can continue to use legacy vector or even monobook and use the full width of their displays. Unregistered users neither have preferences nor user scripts to fiddle with the width. For whom should there be a width preference in the skin? —MisterSynergy (talk) 20:43, 22 September 2022 (UTC)[reply]
I mean, other people here and over at MediaWiki have commented that they'd use Vector 2022 if it had a full-width option. ♠JCW555 (talk)♠ 20:59, 22 September 2022 (UTC)[reply]
Oppose, bordering on a strong oppose. I think the 2022 skin is unattractive, increases dead space, is more unpleasant for reading, and shouldn't be dumped on readers and editors alike. I would rather we improve any shortcomings within legacy than try this. I also agree with User:JCW555 that it is bizarre how the 2022 developers are hesitant to give a wideform option, and the amount of formatting that will need to be reworked for image-heavy articles will be a nightmare. Frankly, the skin itself is not a compelling reason to make such a significant switch for little to no real benefits. Kazamzam (talk) 20:41, 22 September 2022 (UTC)[reply]
In my skim of the wiki when reviewing in this skin, I have seen fewer issues with image-heavy articles, not greater. MOS:SANDWICH basically disappears with a fixed width, as does the effect of image-stacking that pushes images out of the vicinity of the text they go with. Izno (talk) 20:48, 22 September 2022 (UTC)[reply]
Oppose, for now. I don't find it that much better in terms of readability. The width issue concerns me right now as well. If we can change that preference I'll likely vote in support. SEMMENDINGER (talk) 20:50, 22 September 2022 (UTC)[reply]
Hey @Semmendinger 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:54, 22 September 2022 (UTC)[reply]
Oppose. Too much whitespace wasting screen real estate. Useight (talk) 20:55, 22 September 2022 (UTC)[reply]
Oppose primarily due to fixed width - Here are my general thoughts after testing new vs old vector. The good of new vector: The table of contents staying visible in the left sidebar is great. On old vector, this space is unused and the table of contents gets lost at the top. Collapsing the user links on the top is also nice, since we don't normally need to click them in the course of regular reading / editing, and having them follow you down as you scroll down the page is potentially useful. The bad of new vector: 1 pixel black-on-gray for a tab is significantly less usable than old vector's shaded tabs. This feels like changing styles for the sake of changing styles, which, unsurprisingly, ended up with something less usable than the original. The ugly: Fixed width. The fixed-width reading view wastes a lot of space, but it is at least usable. If you switch to an editing view, it turns into a total mess. The edit box is compressed into a tiny rectangle, which is certainly not suitable for editing anything other than a stub article. The history view isn't as bad, but it does cause most edit summaries to wrap to a second line, effectively "doubling" the length of the history page. To summarize, this feels like new vector was designed for people to read like a newspaper, not for people to edit like a wiki. It has a number of nice little improvements, but it also has some major issues that prevent deployment at this time. Reaper Eternal (talk) 21:09, 22 September 2022 (UTC)[reply]
The edit box is compressed into a tiny rectangle, which is certainly not suitable for editing anything other than a stub article. sounds like a user script/CSS interacting badly as I do not experience that issue - i.e., my edit box is a larger width than even the maximum content width. Izno (talk) 21:15, 22 September 2022 (UTC)[reply]
I just deleted all my user scripts, purged my cache, and tried again, and there was zero difference (other than the items that I'd hidden/added with CSS & JS being present/absent respectively). Reaper Eternal (talk) 21:25, 22 September 2022 (UTC)[reply]
User:Reaper Eternal/vector.css will not cause this problem, and your JS page looks fine also.

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

Would you mind uploading a screenshot somewhere just to confirm that what you're seeing is what I think you're seeing? Izno (talk) 21:47, 22 September 2022 (UTC)[reply]
Other than Twinkle and navigation popups (neither of which affect the editor), I have all major gadgets disabled. I have a few random minor gadgets like the "request confirmation before rollback on mobile devices" gadget. Reaper Eternal (talk) 22:02, 22 September 2022 (UTC)[reply]
Oppose. Floating elements, excessive whitespace, and fixed width concern me. Vector 2010 is a good skin that many folks have gotten used to. The status quo seems fine. –Novem Linguae (talk) 21:12, 22 September 2022 (UTC)[reply]
@Novem Linguae - thanks for your feedback. We know that the current skin meets the needs of many in this community and that gadgets, user scripts, and other customizations have helped in the cases when it didn’t. Our goal here was to make sure that this is the case for everyone using the wikis. The current skin, Vector, has been in use since 2010. When it was developed, it reflected the needs of the readers and editors of the Wikimedia sites in that year. Since then, a lot of new audiences have begun using the Internet and Wikimedia projects and their voices and needs were not included in the development of this skin. Research done with these audiences showed that the Vector skin as it is right now doesn't meet their needs.

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

We built the new skin to tackle these problems specifically, so that everyone could benefit from the wikis - those who have been using the projects for a long time, as well as those who have joined more recently, or have yet to join. OVasileva (WMF) (talk) 22:22, 22 September 2022 (UTC)[reply]
Oppose In an example, the contents sidebar does not seem to adequately track the contents while scrolling (and it is not clear how this helps the reader even if it did work) and the resulting 'squished' appearance of the text seems contrary to the goal of effectively sharing information for everyone, per WP:ACCESSIBILITY. While this may be an inconvenience for some, it may also be a more significant barrier for others. Beccaynr (talk) 21:18, 22 September 2022 (UTC)[reply]
Hey @Beccaynr, thanks for taking the time to comment. I would like to question your assumption: 'squished' appearance of the text seems contrary to the goal of effectively sharing information for everyone.

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

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

If you can help me better understand your perspective I would be most appreciative. Thanks, AHollender (WMF) (talk) 22:32, 22 September 2022 (UTC)[reply]
Oppose I realize now that I've been exposed to Vector 2022 via links I've visited, and every time, I've thought "Ew, it's trying to force mobile." The first response from any reader shouldn't be "Ew." NekoKatsun (nyaa) 21:29, 22 September 2022 (UTC)[reply]
Hi @NekoKatsun, thanks for this comment. Could you share why you were convinced this was to similar to mobile? SGrabarczuk (WMF) (talk) 21:45, 22 September 2022 (UTC)[reply]
Sure! In my experience, sites optimized for mobile viewing eliminate/collapse sidebars and headers, presumably to fit more information on a limited screen. The left-hand sidebar being gone, the floating contents button (that does actually cover a little content in the top left), the greatly-reduced information in the header - all of these things look like the mobile version of a web page that's forcing itself to load on desktop.

I will note that what I'm talking about is apparent when the window isn't the full width of my screen (1920), but unfortunately that's how I usually read and edit Wikipedia, with one window taking up the left half for reference and the other on the right for actually making changes. NekoKatsun (nyaa) 21:58, 22 September 2022 (UTC)[reply]
Oppose, it does not look good and having to access the TOC via a sidebar just feels clunky and also forces the viewing area to be narrower. Along with that, the purpleish hue on visited links does not look good. I don't care that it's for accessibility, there has to be some alternative. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 21:39, 22 September 2022 (UTC)[reply]
Oppose - Looks bad in my opinion, doesn't seem like an improvement. Waxworker (talk) 21:43, 22 September 2022 (UTC)[reply]
Oppose Too narrow and too much annoying white space on both sides. AhmadLX-(Wikiposta) 21:46, 22 September 2022 (UTC)[reply]
Hey @AhmadLX, thanks for your comment. I'm curious if you've had a chance to review 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. I realize this is a big change from what you are used to, but we feel really strongly that we should follow the best practices and well established research on this topic. I also would invite you to take a look around the internet at other popular content websites, to see whether or not they have width limitations. As far as I have been able to find almost all do.

Regarding the white space on both sides, have you checked out our latest prototype or this image? We will be using the white space to the right of the article for article tools (which can also be hidden).

I'm curious if that all makes sense, and if you have any other thoughts? Cheers, AHollender (WMF) (talk) 22:07, 22 September 2022 (UTC)[reply]
Oppose The numbers provided by User:BilledMammal are very telling. As for me, I find the TOC being moved to the left sidebar to be unnecessary. Specifically, that move means that I must test an article using __TOC__ in multiple skins which is a waste of time. I would consider supporting if we fixed the whitespace issue and moved the table of contents back into the article content proper - rather than hiding it in the sidebar. ~ Matthewrb ^{Talk to me · Changes I've made} 22:14, 22 September 2022 (UTC)[reply]
Thanks @Matthewrb. Have you maybe had a chance to read my reply to BilledMammal's comment on the survey? It's important for me to avoid misunderstandings around that specific issue. I must test an article using __TOC__ in multiple skins - could you share more why you feel you must do that? For the limited width, see the new section below (#Update on the fixed width and white space). SGrabarczuk (WMF) (talk) 22:22, 22 September 2022 (UTC)[reply]
I have read this entire RFC, and I do not find the reasoning in your reply compelling - fully responsive skins have existed for a long time (see Bootstrap for a prime example) so intentionally creating a fixed-with solution is entirely unnecessary when we can create a fully responsive solution that doesn't intentionally waste space. As for the __TOC__, when I sent International Film Music Critics Association Award for Best Original Score for a Video Game or Interactive Media to Featured List, I tested it in Vector, Vector 22, and Timeless. Vector 22 still has a huge gap instead of the table of contents as would be expected. And a reader will have to scroll down on the left sidebar to even access the TOC in that particular article, which is a usability nightmare. ~ Matthewrb ^{Talk to me · Changes I've made} 22:34, 22 September 2022 (UTC)[reply]
Oppose - It doesn't look attractive to me, I still prefer the 2010 version. This 2022 version is a perfect description of "from grace to grass" or from "frypan to fire". I'm fine with the legacy version, and everything about it looks convenient and matured. Comr Melody Idoghor (talk) 22:16, 22 September 2022 (UTC)[reply]
Hi @Idoghor Melody - thanks for your feedback. I just replied to a similar concern above, so I'll quote my comment from there:

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

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

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

We built the new skin to tackle these problems specifically, so that everyone could benefit from the wikis - those who have been using the projects for a long time, as well as those who have joined more recently, or have yet to join. OVasileva (WMF) (talk) 22:30, 22 September 2022 (UTC)[reply]
Oppose. Reaper Eternal's comment above echoes what I was about to write, so I'll not repeat it. The new skin may be decent for reading (despite the survey above) but it's a big step back for editing. The one use case I can see is if the intention is to have one skin for readers and another (supported indefinitely) for editors. However, that risks editors releasing content which doesn't work well in the readers' skin. It's true that most other sites shoehorn their content into a central column, but that's mainly to create artificial sidebars for advertising. We're better than that. Certes (talk) 22:30, 22 September 2022 (UTC)[reply]

Support after the implementation of a built-in width option

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

RfC discussion

I'd like a commitment that the WMF will provide maintenance for the core V22 customisation gadgets/scripts (width, TOC positioning, etc) if the volunteer creators are unable to do so, including ensuring that they continue to work with future V22 changes. While the mediawiki documentation speaks of wanting a more consistent experience between readers and editors, I simply believe that's not going to happen. Our uses are just so different. So ultimately V22 needs to be able to handle both - and that agreement needs to be provided prior to becoming the status quo for readers because it'll be almost impossible to get afterwards. Nosebagbear (talk) 17:45, 22 September 2022 (UTC)[reply]
One of the main issues I worry about, ironically, is accessibility of the link colours. These were changed to improve accessibility. I've changed the visited link colour in my CSS because I struggled to read them, especially on my watchlist. Given I have good eyesight, I worry about this being a wider issue. The colour can be made a tad bit more dark without failing the WCAG AA accessibility with the black prose (see phab:T213778), but that colour is still too light for me. If this is a problem more people experience, that would be a reason to oppose for me. Femke (talk) 18:50, 22 September 2022 (UTC)[reply]
Has there been any discussion about using the currently-empty right column to house floating infoboxes instead? I'd be keen to read that back-and-forth, if so. Thanks, — Fourthords | =Λ= | 20:20, 22 September 2022 (UTC)[reply]
There are some older prototypes pre-V22 development that played around with moving images, infoboxes, and other floating content at high width into those spaces, and the "responsive Vector" gadget available today also does that depending on width. Izno (talk) 20:26, 22 September 2022 (UTC)[reply]

@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)[reply]

Regarding the metric specified above in Key Results, referencing https://phabricator.wikimedia.org/T317529, where it said that 87% of users on the pilot wikis continued using the new skin; I'd like them to correlate this metric with how many of them actually know how to change back the skin to the legacy one. _→AzaToth 20:25, 22 September 2022 (UTC)[reply]
@AzaToth - good point. We wanted to make sure that it's easy for people to switch to the old skin. So in addition to being able to turn the skin off in preferences, we added a bolded link in the sidebar: "Switch to old look" so that will be easy for people to find. OVasileva (WMF) (talk) 20:33, 22 September 2022 (UTC)[reply]
I didn't notice that link until you now pointed it out, and I was looking around for one. _→AzaToth 20:38, 22 September 2022 (UTC)[reply]
Comment: It looks like this RFC outcome would change to Snow Support if the WMF would let go of its attachment to white space. See also Duḥkha. – Jonesey95 (talk) 20:39, 22 September 2022 (UTC)[reply]
I would agree with that comment. — Red-tailed hawk _(nest) 20:49, 22 September 2022 (UTC)[reply]

The wasted space is certainly a major drawback, and the change might find support without it. Certes (talk) 21:54, 22 September 2022 (UTC)[reply]
Why was it decided to do an RFC? The editors who will comment on this and end up deciding whether the skin will be used make up less than 0.1% of the daily users of Wikipedia. If the statistics show that Vector 2022 has a significant preference for usage among all users and even provides benefits to the project itself, then that should be clear evidence to implement it. The comments that users are making here are their own and cannot be representative of the entire user base like statistics can. This RFC seems to be about "whether I want my UI to be Vector 2022" and not "will the majority of users like Vector 2022". Measuring the true benefit of Vector 2022 will be impossible to do with an RFC compared to statistics. Editors against its implementation will still have the option to use the old Vector anyways... If users are still not confident that Vector 2022 will be an improvement for enwiki users then an A/B test should be run on enwiki itself to demonstrate its benefits. Lectrician1 (talk) 20:59, 22 September 2022 (UTC)[reply]
The survey histogram above shows that only 37 users declared the new skin easier to use, compared with 60 for the old skin. It would seem unreasonable to override that result without an endorsement such as a RfC. Certes (talk) 21:52, 22 September 2022 (UTC)[reply]
@Certes to clarify: the survey collected first-impressions, not usability data. It was invalid for us to ask a question regarding usability, which was of course our mistake. As a generalization I think it's fair to say that people don't like change (including myself). It is never easy to adjust to something new. However the reliable usage data we have, combined with the usability studies we've done, give us confidence that the change will be an improvement.

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

I'm curious how that sits with you? AHollender (WMF) (talk) 22:22, 22 September 2022 (UTC)[reply]
The main plus for me there would be dark mode. If dark mode really is only possible with narrow text, then personally I'd stick with legacy Vector and the current dark-mode gadget. Certes (talk) 22:29, 22 September 2022 (UTC)[reply]
On pages with co-ordinates when using Firefox (e.g. Sundrum Castle), the global symbol overlaps with the horizontal line above it. -Kj cheetham (talk) 21:23, 22 September 2022 (UTC)[reply]
Yes, this is an issue that is kind of stuck. The editors who have looked at the issue (including me) that would like to move forward with moving them into indicators are generally worried about potential blowback. Izno (talk) 21:29, 22 September 2022 (UTC)[reply]

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. The New York Times, 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

When reading short lines, readers don't move their eyes too much, use the eye's muscles less intensively, thus avoiding eye strain.
Narrow paragraphs allow readers to memorize new information better.
On websites, there should be between 35 and 100 characters per line. Numbers closer to the smaller end are preferred.
The overwhelming number of major websites have similar limitations on content width. For example: academic journals like Nature, news websites like The New York Times, government and intergovernmental websites like the United Nations, academic documents like LaTeX, and word processors like Google Docs and Etherpad.

Empty (white) space

White space is used for the eyes' resting spots. It helps readers focus on content and increases content comprehension by 20%.
People are able to focus more easily without the distraction of sidebars or other elements.
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.

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)[reply]

@@ Line 201: / Line 201: @@
 *'''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 <code><nowiki>__TOC__</nowiki></code> 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. ~ [[User:Matthewrb | <span style="color:#5e0231;">Matthewrb</span>]] <sup>[[User talk:Matthewrb | <span style="color:#e6af4b;">Talk to me</span>]] &middot; [[Special:Contributions/Matthewrb | <span style="color:#111eb8;">Changes I've made</span>]]</sup> 22:14, 22 September 2022 (UTC)
 *:Thanks @[[User:Matthewrb|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. {{tq|I must test an article using <nowiki>__TOC__</nowiki> 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]]). [[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] ([[User talk: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 (front-end framework)|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 <code><nowiki>__TOC__</nowiki></code>, 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. ~ [[User:Matthewrb | <span style="color:#5e0231;">Matthewrb</span>]] <sup>[[User talk:Matthewrb | <span style="color:#e6af4b;">Talk to me</span>]] &middot; [[Special:Contributions/Matthewrb | <span style="color:#111eb8;">Changes I've made</span>]]</sup> 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. '''''[[user:Idoghor Melody|<span style="font-family:Segoe print; color:blue; text-shadow:blue 0.9em 0.9em 0.9em;">Comr Melody Idoghor</span>]]''''' [[User talk:Idoghor Melody|<span style="color:Navy">'''''(talk)'''''</span>]] 22:16, 22 September 2022 (UTC)
 *:Hi @[[User:Idoghor Melody|Idoghor Melody]] - thanks for your feedback.  I just replied to a similar concern above, so I'll quote my comment from there: