*:Regarding the white space on both sides, have you checked out our [https://vector-2022.web.app/Moss latest prototype] or [[c:File:Vector_2022_with_article_tools_pinned_(1453px).jpg|this image]]? We will be using the white space to the right of the article for article tools (which can also be hidden).
*:Regarding the white space on both sides, have you checked out our [https://vector-2022.web.app/Moss latest prototype] or [[c:File:Vector_2022_with_article_tools_pinned_(1453px).jpg|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, [[User:AHollender (WMF)|AHollender (WMF)]] ([[User talk:AHollender (WMF)|talk]]) 22:07, 22 September 2022 (UTC)
*:I'm curious if that all makes sense, and if you have any other thoughts? Cheers, [[User:AHollender (WMF)|AHollender (WMF)]] ([[User talk:AHollender (WMF)|talk]]) 22:07, 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 <code>__TOC__</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>]] · [[Special:Contributions/Matthewrb | <span style="color:#111eb8;">Changes I've made</span>]]</sup> 22:14, 22 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
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
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!
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
Graphs are unavailable due to technical issues. There is more info on Phabricator and on MediaWiki.org.
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 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.
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.
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]
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; 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]
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]
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. PerryPerryDTalk To Me20: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. — Newslingertalk20: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·des20: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 Jazztalk to me | my contributions21:53, 22 September 2022 (UTC)[reply]
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]
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. --Rschen775418: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. --Rschen775418: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]
@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.
@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.
@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.
Graphs are unavailable due to technical issues. There is more info on Phabricator and on MediaWiki.org.
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]
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]
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.
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]
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.
@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]
@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 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]
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 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.
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. PerryPerryDTalk To Me20:18, 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.
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?
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?
@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]
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 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]
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).
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]
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]
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]
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 WolfTalkBlaze Wolf#654521:39, 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).
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 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. ~ MatthewrbTalk to me · Changes I've made22:14, 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 pinnedOVasileva (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. →AzaToth20: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]
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]
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.
Vector legacy (current default), logged-out
Vector 2022, logged-out
Vector 2022, logged-in
Vector legacy (current default)
Vector 2022, logged-in
.jpg)
.jpg){kind=link}