Update as of Oct 19: The Web team has posted this section below highlighting the team's main takeaways from the discussion and the next steps the team will undertake.
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).
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. Updates on reimplementing the Graph extension, which will be known as the Chart extension, can be found 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.
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Overall, there is a positive reception to the changes. Supporters were enthusiastic in their appreciation of the UX improvements, and most editors currently opposed expressed specific and narrowly-scoped concerns, rather than wholesale objections to Vector 2022.
The most substantial concern, and the only clear blocker, was the issue of fixed-width. The idea of using a community-maintained gadget is deemed insufficient. It should be possible to achieve a full-width experience using a WMF-maintained toggle, which is clearly visible and available to both logged-out and logged-in users. There were also notable concerns about non-intuitive icons in the sticky header and the behaviour of the language selector, which we believe need to be addressed to achieve a firm consensus.
If all the concerns outlined above are satisfactorily addressed then we see community support to roll out the change, and in our view no further RfC would be required, although the Web team is free to hold one if they wish. Since the discussion was dominated by fixed-width we can’t say for sure if the other concerns are blockers. As such, our close aims to be conservative, given also the scale of the change and that each opposing editor likely did not list every concern which they agreed with if it was already raised by others. We encourage the Web team to be sure they have addressed the community’s concerns on these issues before moving forward. If the Web team wishes to roll out without addressing one of the above issues then we would encourage either a specific discussion on that issue or a second RfC as they originally planned.
Finally, we appreciate the Web team’s participation in this discussion and note their commitment to the continued support of Vector 2022. We also noted other legitimate concerns by editors, for example unresolved bugs (particularly relating to the TOC) and comments about link colours. We won’t enumerate them all, because we’re sure the Web team has read them. We hope the team will take these into account and continue to work with editors to ensure Vector 2022 is a success.
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 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]
Frankly, it does look like it's run by nerds. The defensive "thank you for asking that question" stance in the surprisingly large number of rebuttals to Oppose comments is one hint. A bigger hint is that there isn't much granularity or transparency in regard to the "facts" that support this decision. I clicked the bold "details on the data analysis" and went to the separate page which merely clarified bullet 4 in the Key Results section (top of this RfC page) as "searches initiated". Why is that necessarily salutary? It could be the reverse: search errors are more frequent (i.e., repeating a search counts as initiated) or info within the page is less readable (i.e., user needs to search via algorithm rather than own eyes). In other words, there seems to be a bubble effect or group-think about surveys which assumes/presumes a correct way to frame Key Results. See also the manipulation-by-conflation of survey stats pointed out by BilledMammal (graphs) and Red-Tailed Hawk (data) in Oppose #3. Martindo (talk) 08:01, 24 September 2022 (UTC)[reply]
Stats are more impressive when given in context, which typically moves the POV closer to balance/NPOV. For example:
Currently, the skin is the default on more than 30 projects of various sizes, accounting for a bit more than 1 billion pageviews per month.
Wow! But wait, what is the total number of pageviews per month for the entire wikipedia across all projects?
Desktop @Lectrician1 wrote that "the simplified user interface with the sidebar hidden by-default,..". I wonder if it will stay hidden by default .An EN trial of T219759 "Increase visibility of "Donate to Wikipedia" desktop web sidebar item" in December 2018 increase up donations by 165 %. The Phab is part of "EPIC Desktop improvement visual refinement/cohesion, and cleanup" which is tagged Vector 2022
Apple IOS (his is not included, but I just want to mention it) T288285 "As a donor I want to be able to make an easy and convenient donation via Apple Pay in the Wikipedia app" is marked as High
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]
True. Even an oligarchy is subject to popular will to some extent. If they foster a situation that devolves into starvation (or serious impediments to usability/popularity/revenue in the case of WMF), they will be unseated one way or the other. It is simple wisdom and self-preservation to take the pulse of the populace. The next step is to ask whether the information offered in the request for support is accurate and fairly interpreted, or merely spun/obfuscated. Martindo (talk) 08:09, 24 September 2022 (UTC)[reply]
Media viewer is a global default despite the best efforts of the German Wikipedia which forced the creation of superprotect. We can ask nicely, but we have no control over how the devs and sysadmins do their jobs. Per WP:CONEXCEPT "These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features" (emphasis added). Changing the skin clearly falls under the list of things that does not need community approval and something that we can not bind the WMF on under existing policy. If we reject new vector it will be implemented as the global default in a number of years without an opt-out for us. -- GuerilleroParlez Moi10:03, 23 September 2022 (UTC)[reply]
By this reasoning alone, you could have prefixed your message with "Oppose" as well (with a meaning like "I don't like this, but I have no choice"). So if I understand correctly, there is something beyond "they can do so" that made you support rather than oppose. If you could point that out, and even if it's just "looks better", I think that would improve the overview. ~ ToBeFree (talk) 18:33, 23 September 2022 (UTC)[reply]
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 with the limited width. 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]
Strong support I mostly use Wikipedia on my laptop in large windows; but when I make the windows smaller, the always-visible sidebar makes it practically unusable. It's also hard to overstate just how much better the 2022 layout is, for example on the iPad (without Safari's forced desktop view); previously, each section needed to be expanded manually, and it behaved like a true mobile site; with the 2022 design it behaves far better. I initially didn't like the 2022 design on another early-deployment Wikipedia, but I've since turned it back on and it just looks cleaner. Also absolutely love the ToC sidebar; makes it far easier to navigate articles. Fantastic change. DFlhb (talk) 22:18, 22 September 2022 (UTC)[reply]
To add context to what I said above, after using Vector 2022 full-time over the past few days: I absolutely hated Vector 2022 at first when I saw it on another country's Wikipedia, and switched it back to the old one, but after browsing Wikipedia some more I realized how indispensible the always-visible ToC was, and how much nicer it was to have consistent page widths, and I ended up opting-in even on en.WP. I suspect most people would get used just fine to the new design, like I did, and, like me, would come to absolutely hate the old skin if they tried switching back. I literally can't use Vector legacy anymore. DFlhb (talk) 00:00, 26 September 2022 (UTC)[reply]
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]
Strong support - like DFlhb, I mostly use Wikipedia on my laptop and my iPad; V22 is a much better expereince on both, particularly the latter. It truly feels like it was designed for a variety of devices, and the lack of unnecessary (and, frankly, ugly) gradients make it look much cleaner. I personally find the fixed width much easier to read - as long as the gadget to disable it is easily accessible (and as long as the toolbar split happens soon-ish), I think this is ready for wider deployment. Remagoxer(talk)23:00, 22 September 2022 (UTC)[reply]
Support: It's fine if we have a couple bugs here and there. As a whole, the skin is better based on the survey results, if we count people that liked Vector 2010 better because of resistance to change and nostalgia as neutrals. WP:PERFECTION. Sungodtemple (talk) 23:33, 22 September 2022 (UTC)[reply]
Seriously, you are going to present that as quantitative info? What's the standard for "resistance"? Where's the evidence of "nostalgia"? See the Oppose #3 discussion about manipulation of stats (conflating neutral with like to negate a plurality of don't like).
The deployment page says:
vast new audiences have begun using the Internet and Wikimedia projects. Research done with these audiences showed that the current default skin doesn't meet their needs.
Well, as we say in Wikipedia, CITATION NEEDED. Which audiences? What research? I would specifically like to know how the claim of universality/global outreach is addressed. Mention is made of WP French or Portuguese moving forward happily with the new look. How exactly were the new audiences tallied? Number of countries? Countries weighted by population? Majority of languages that have their own WP? None of this is transparent, most is simply declared. I think the most relevant way to address "vast new audiences" would be to look at access device & platform, with a sharp eye toward realistic (not max advertised by local ISPs) bandwidth in sample countries around the world.
I give more credence to Support votes who honestly say "I like it" and give an example of why than I do to votes that offer statistical tricks or unproven claims about who prefers what (e.g., "most" of the people participating are old hands). Martindo (talk) 10:41, 24 September 2022 (UTC)[reply]
Very weak support: I understand that they're looking for a more unified visual experience across platforms and screens, though I wish the look were "unifying" more around the traditional desktop experience and less around the mobile experience. It's a little odd how the designers seem determined to tell those of us who want to view and edit Wikipedia in a landscape orientation rather than portrait that we're somehow using our monitors (or our eyes?) incorrectly. I'll like the new one much, much better once the tools can be put in the right sidebar and I have less blank space on my screen. -Bryan Rutherford (talk) 23:45, 22 September 2022 (UTC)[reply]
Support: I've been using Vector 2022 ever since something with the logo was changed several months ago. The TOC is really useful when navigating pages, and search is more prominent. The sticky header is useful as well. I also think that hiding the user menu declutters the page and only adds a negligible amount of time when navigating. I also actually like the reduced width (except perhaps when editing. This is okay as long as there is an opt out for editors) for readability after using the skin for a while and agree that it probably is best practice. There's also significant technical benefit with other features to potentially come with it. Icons significantly reduce space that's needed for links, are intuitive, and website users will be able to become familiar with them. Opposers currently mention a chart that has an invalid question--of course the old one should be easier to use when a user first views it, and it should not prevent the skin from being deployed. That said, I think the link color change is OK and doesn't detract from site usability much, but I'm not sure how much readers might care it's because accessiblity. Given concerns down below, I think that this site should have a way to enable the wide vector gadget by default with it: including width limitations with the skin proposal makes getting consensus for it much too hard. It's already hard enough to get a design change through because there will usually be a negative response at first. I'll probably comment again after more people give their thoughts. —Danre98(talk^contribs)00:50, 23 September 2022 (UTC)[reply]
Support may or may not use it myself as an editor but as a reader, the sticky header and sidebar TOC are substantial improvements. Net positive change. – Teratix₵01:43, 23 September 2022 (UTC)[reply]
Support. The new table of contents is excellent. Also per Ganesha811. Also... I hated the new design when I first saw it years ago. Since then, I've grown to like it quite a bit. The fundamentals of the design haven't changed, which means only one thing... good ol' change aversion. I suggest editors in the oppose section reconsider whether they're assessing the design based on accepted design principles. Which, by the way, have nothing to do with "mainstream/modern/recent web design". People have known limited text width increases readability for ages: a very old trick for increasing your reading speed is by practicing on newspaper columns. There's a reason every website with an ounce of design thinking has fixed-width text - the eye wasn't meant to jump, like, one foot after reading each line. Enterprisey (talk!) 03:01, 23 September 2022 (UTC)[reply]
Support. Having a max width is a good thing, in my view. I agree with some of the concerns that there is too much white space in some places. See screenshot for one thing that stuck out to me. Overall, I support. Scroll bar; only part of the TOC visible on screen. Blank space below it where the rest of the TOC would fit. Why not show more of the TOC there?Adumbrativus (talk) 04:38, 23 September 2022 (UTC)[reply]
Support Been using it for months and feels almost like its never been any different. Paint that nuclear power plant so we can get back to infighting about the color of the bikeshed please. —TheDJ (talk • contribs) 10:12, 23 September 2022 (UTC)[reply]
SupportIff support for the other skins isn't going away. I think it's ugly, and i have no intention of using it myself, but if the statistics and reviews show that it's "better" for today's new users, why not? Happy days ~ LindsayHello 11:22, 23 September 2022 (UTC) Have to move from my first response; amusingly, i agree with the statement immediately below ~ the enhancements cannot be understated: I've been using it on and off for a while (before and after this RfC), and i seriously think that they are not enhancements, and we can do ~ and already do ~ far better as a default or introduction to our site. Happy days ~ LindsayHello11:38, 25 September 2022 (UTC)[reply]
Strong Support The enhancements to readability cannot be understated. I think a period of adjustment is inevitable but the end result is worthwhile. Much better for navigability as well. Clarysandy (talk) 12:41, 23 September 2022 (UTC)[reply]
Support I was initially a little apprehensive of the new skin but after testing it out for myself, I find aspects such as the TOC sidebar and sticky header significantly improve navigation and usability. I also think an increase to font size would further improve readability and address concerns about whitespace. Alduin2000 (talk) 12:53, 23 September 2022 (UTC)[reply]
I support implementing the improved UI, after mucking about with it for the better part of a day. None of my typical activities are diminished in any way, and some were improved. Do it to it. — Fourthords | =Λ= |13:26, 23 September 2022 (UTC)[reply]
Strong support I've closely followed improvements of the skin and there's no aspect of it that I don't love. There are still a few rough corners and it might have been better if this RfC came later, but the overall direction is good and has my strong support. I don't understand complaints about "wasted space" (doesn't cost a thing, helps your eyes!), and I'm sure that in the future that space could be filled in with infoboxes and images, preventing current clashes and squeezes. Ponor (talk) 14:09, 23 September 2022 (UTC)[reply]
Pardon the cliche, but everything has its limits. Excessive white space typically means more scrolling, which tires eyes, hand(s), and brain. (See Oppose 62.)
I don't think esthetics are changing in favor of more white space. If anything, the trend is in the other direction: more clutter to "capitalize" on "real estate". So, the addition of white space may indeed be a relief to older users like myself, but then we're dissed as "nostalgic" or "resistant" -- you can't have it both ways. The younger generation(s) raised to be comfortable browsing on cell phones don't value it as much. If there's a study that specifically contrasts device type in regard to the appeal of white space, let's see a link for it.
Although I Oppose a new default, I agree that worldwide increase in cell phone browsing should be addressed as a key usability issue. However, the huge rise in such browsing in the global south needs to be coupled with serious consideration of bandwidth available to such users. Otherwise, re-design simply continues to favor developed countries. Martindo (talk) 00:53, 25 September 2022 (UTC)[reply]
Support: I was pleasantly surprised when Vector 2022 was introduced as an opt-in, and I already view it as vastly superior to the 2010 Vector, even in its current—still somewhat flawed–state. I've been using it for over a year now, and my contributions have exponentially increased during that time—a testament to the new skin's utility. I particularly enjoy the decreased page width as it allows for a much more comfortable reading experience. Simplification of buttons and sidebars and the removal of outdated design elements like blue vector gradients contribute to a more unified, organized, and contemporary look. I'm frankly baffled to see how strongly editors are defending the old Vector's grotesquely large page width; "Humans are resistant to change" rings true, doesn't it? The same flock of vocal conservative editors are the reason why the main page will remain unchanged for the next 30 years and why this proposal will probably end up being rejected. Wikipedia is finally approaching basic aestheticism, something that's been long overdue. Throast{{ping}} me! (talk | contribs) 14:28, 23 September 2022 (UTC)[reply]
Strongly support (logged out) // oppose (logged in; possibly out-of-date feedback) -- As a logged out user, I love this change. Nav gets out of the way (I can see content right from the top), but I can also jump immediately to whatever section is relevant, and the fixed width makes the reading experience easier + more consistent. As a logged in user (today's the first time in months), the Main Page / Contribute / Tools sidebar entries hide the Nav ToC, and that is a strict regression from the current setup. In order to see the article sections, or to jump to a specific section, I have to scroll down the page to access the nav. EDIT: It looks like my opposition will be addressed by "[EPIC] Article Tools". mhlinder (talk) 14:33, 23 September 2022 (UTC)[reply]
Neutral/Cautious support - there are still problems with responsive design on mobile. Despite this, I think that the new skin is a significant improvement on not-at-all-responsive Vector 2010. When proper responsive design is added to Vector, it will render the mobile front-end entirely obsolete. Aasim - Herrscher of Wikis ❄️ 14:41, 23 September 2022 (UTC)[reply]
Support, but I hope that methods for opting-out or changing the skin are displayed prominently for users the first time they see the new interface. Not everyone likes change, and if there is a technical way to display the simple instructions in the FAQ here once this is rolled out, I expect it would reduce any stress or friction resulting from this deployment.~TPW14:44, 23 September 2022 (UTC)[reply]
Strongly Support I have been using Vector 2022 for a few days and it is vastly superior to the old Vector. The TOC on the sidebar is a game changer and brings in line the desktop experience with the mobile experience. The white space is also a great feature, brings much needed breathing room for the content and makes reading wikipedia articles much easier and feel less like a chore. It would be helpful to have a more traditional hamburger menu that includes the table of contents like the mobile app. There's no easy way to hide the TOC in the middle of an article and access it easily again. I also wonder how necessary the main wikipedia menu really will be after the page tools are added on the right. The TOC & remaining main wikipedia navigation links could live in the same hamburger menu. While I understand the desire to solicit feedback on the design, I will be very disappointed and frustrated if the WMF takes the feedback of a few loud and disgruntled editors as reason to not go forward with this implementation. The vast majority of readers will be positively impacted by these changes, and most of them will not be seeking out an RFC to comment on Ha2772a (talk) 17:09, 23 September 2022 (UTC)[reply]
Some good suggestions here, even though I vote Oppose. I, for one, would like to see easy (not merely easiER) navigation between different language versions. Like others who speak English and foray into reading/editing the WP-En history of a country that generally uses a different language, I occasionally find references to their language's version of WP. In some cases, there is a direct link to the corresponding article in the other language, but in many cases I have to go back to Main Page, then select the other WP, then search a relevant term. Martindo (talk) 00:19, 25 September 2022 (UTC)[reply]
Support: I have been using it for a while now, and it's an improvement. I would, however, like to see easy-to-use options allowing the user to adjust the width. MichaelMaggs (talk) 17:37, 23 September 2022 (UTC)[reply]
Strong support: I hope to come back and provide proper reasoning, but I encourage the WMF to implement this even if the en.wiki community disapprove, a huge departure from my usual disdain for all things WMF. However, the en.wiki community have been so obstinately and consistently opposed to any non-trivial design improvements, be they the Main Page or the sidebar or whatever, that I am unhappy but not at all surprised to see the knee-jerk opposition to this longstanding project. It is natural that this happens because people don't like change, and our core community consists mostly of people who have been here for half of Wikipedia's history, as we have been steadily getting worse at new editor retention for many years. But spending 10 minutes looking at the skin and describing what differences feel strange at first is not a substitute for professional web design.Some criticisms like the TOC limit removal are completely valid, but these are just ways to improve Vector 2022; that WP:FAC would need redesigning if this were not fixed is not a reason to hold all readers back. I've been using Vector 2022 since I saw it was possible to and I wouldn't seek to deny that it takes getting used to and can be improved, but it is quite simply less embarrassing than the 2000s-era skin we use currently. — Bilorv (talk) 22:33, 23 September 2022 (UTC)[reply]
Back with a little more: the skin is a clear improvement in showing all relevant information and links as the reader scrolls down—search, the ToC, the title, and editor links (talk page, history, my watchlist, my contribs etc.) The design modernises the site and makes it look less like a dull ancient tome, including the deliberate whitespace, which also has the effect of improving readability. Our poor sidebar, which has been reformed but never properly fixed, is rightly sidelined.Through months of using it, I've found pros and cons as an editor when compared to the previous interface, but I stuck with it because (naively) I thought that it being clearly better for the reader meant it would inevitably be implemented on en.wiki. Unfortunately, paid WMF members who presumably have web design and accessibility expertise, as well as literature searches and testing/focus group results, have decided to get the opinion of amateurs who take one look and go "nah, it doesn't look like what I have now". The Wikimedia community is king and our consensus-making process usually works better than the alternative. But I think most of us recognise that you shouldn't consult us over bugfixes, over legal matters and over security decisions. You should not consult us over this technical improvement where have an informed opinion requires surprisingly much knowledge, and where minute concerns about editor preferences override the silent majority of non-editor readers. — Bilorv (talk) 19:42, 27 September 2022 (UTC)[reply]
Strong support: The skin isn't perfect. But it is a massive upgrade from Legacy Vector. I've seen lots of concerns about the width, but after a few months on Vector 2022, it's actually not that big of a difference. This skin and its ease of use will make it easier for readers to become editors, especially after the reorganization of the menus and page tools. All of the other changes just make sense. ~BappleBusiness[talk]01:16, 24 September 2022 (UTC)[reply]
Support - I installed the skin a few weeks ago to try it out, and once the novelty shock wore off, I liked it. I did tweak the width to shrink the right-side spacing a bit, but actually ended up changing it less than I thought I would - leaving it mostly there, along with the other changes, makes things more readable in general even if it doesn't maximize use of my screen width. I'm in favor overall. --PresN02:20, 24 September 2022 (UTC)[reply]
Support - tbh still looks like it's 5 years out-of-date to me, but it's better than the 15 year out-of-date design we currently have. I will still use the legacy one because that's what I'm used to, but I understand that the new one implements basics of web design (frankly, basics of web design from five+ years ago). My colleagues who think that white space or fixed width reading lines are bad should be, well, ignored. Web design isn't something to be decided by a vote. Levivich (talk) 02:51, 24 September 2022 (UTC)[reply]
Nope, and nope. You're confusing "usability feedback" with "usability". We learn about web design in the same way we learn about other things: with controlled double-blind studies. Levivich (talk) 14:54, 25 September 2022 (UTC)[reply]
FWIW, I think V22 should use a serif font for text. I guess best practice is split on the issue (e.g. NYTimes and Nature use a serif font; WaPo and Science use a sans-serif font) and I don't really expect this change to be made, but I just wanted to throw out my support for serifs: they're easier to read for small-sized text IMO (but not sure what the research says about it). Levivich (talk) 20:01, 28 September 2022 (UTC)[reply]
Prior to high resolution displays, generally sans serif fonts were favoured, because the serifs did not display well at monitor resolutions. However, designers started making serif typeface designs that took into account pixelization effects. High resolution displays, typically on phones or tablets, fare better at rendering serifs. Serifs were traditionally used in long printed passages because the serifs aid in tracking the lines of text. However it's a balance, as overly ornate ones can add visual clutter. isaacl (talk) 20:21, 28 September 2022 (UTC)[reply]
Support – Like many of the other editors writing here, I thought the new skin was horrible at first due to the reduced line width and empty space. After just a few days using it, I totally reversed my opinion, and came to love that design choice because it's simply a huge improvement for readability (along with the sticky ToC, which I also like). Wikipedia's current visual style is dated, ugly, and frankly just embarassing for a website of its prominence, and stretching lines of text across the entire screen is a major contributor to this. I am dismayed to see opposition from editors who seem to have only glanced at the screenshots and rejected the skin outright without giving it a chance. For the sake of our readers now and in the future, I hope we won't be stuck with the status quo for another 20 years. — Goszei (talk) 05:41, 24 September 2022 (UTC)[reply]
Strong Support — Since it's been like 12 years since we actually had really any update with considering Vector, I believe we should move on to a better version of Wikipedia now. We all do deserve a change sometime and I think this is a perfect opportunity since the team has worked on this for about 3 years, I don't see why should this be opposed. Rejoy2003 06:04, 24 September 2022 (UTC)[reply]
Support After a week or so of use I've found the sticky header and the index in the sidebar reduce scrolling. I'm taking advantage of foreign-language wikipedias more frequently.--AntientNestor (talk) 07:23, 24 September 2022 (UTC)[reply]
Weak support - The current default skin has already been in use for a long time and not really changed. I would like to see some change, but not necessarily this skin. 141Pr08:27, 24 September 2022 (UTC)[reply]
Support - Though I'm not immediately a fan of the limited width or empty white space (it's difficult to tell where the article ends and empty space begins, and is awkward that when scrolled down beyond the sidebar content the article content is off-centred in whitespace), I support modernizing the UI in line with broader web trends. Even though many of us are used to the existing UI, WP is for readers, and readers on the web expect (and deserve) a different (modernized, improved) experience than they had 12+ years ago. -M.nelson (talk) 12:00, 24 September 2022 (UTC)[reply]
Strong support: I didn't like this skin last year but the concerns I noted to the development team have since been addressed. (Concerns included the positioning of coordinates and overlapping text when using a big font.) Reasons I now like it: I recently got some progressive glasses and a wide body of text is no longer practical to view on the Internet (or even sometimes in a book). This is because the portion of the lens for intermediate distances is confined to a small area in the centre of the lens, and material on the perimeter is distorted, meaning with this type of glasses the entire head has to be moved to read material on the perimeter of a wide page. Not a comfortable way to read text! Also on a wide page it's difficult to find the correct line when moving from one line to the next. So TLDR, for me the limited width of the text is a feature, not a bug. Adapting to the new locations of my favorite features (Twinkle, the clock, the table of contents) has gone quite quickly. So, I now think the new Vector is the way to go. — Diannaa (talk) 14:37, 24 September 2022 (UTC)[reply]
Support Is it fantastic? No. I’m not a fan of the line width changes, and the design overall isn’t great. But, I suspect a large portion of my dislike is simply resistance to change, and I’ll get used to it. Looking at it rationally, it’s fine. I can always opt out if I dislike it. Although, to me, it’s not easier to read, it does seem to be based on actual evidence, and will probably be better for the majority of people. ThePlatypusofDoom(talk)
Support - I really love the redesign, especially the new ToC and the floating top-bar, and I'm excited for the coming Article tools on the right sidebar. I do think it needs some more polishing, but the way that happens is by really taking it to wide deployment; and most of the friction is just temporary. The one thing I'd like to see from one of the prototypes is the classic grey for all the non-article areas of the screeen. including both sidebars, as in Option nine from this prototype https://di-visual-design-borders-bgs.web.app/Zebra, which seems to reduce air strain on very wide monitors by using a gentler background that focuses attention on the article. Azertygod (talk) 15:48, 24 September 2022 (UTC)[reply]
Support I was leaning to oppose but given how it looks like after I switched to Vector 2022, I feel I like it. It however needs some improvements that several editors have pointed to above. Nothing is perfect, not even at the peak of its success. ─ The Aafī(talk)
Weak support The old Vector is definitely too wide, which makes it uncomfortable to read. I use the new Vector myself, though I'm not sure if it's for everyone. — W.andrea (talk) 21:51, 24 September 2022 (UTC)[reply]
Support Current vector has far too much text and is hard to read for a long time (and I have good eyesight). It desperately needs updating. I currently use Timeless which makes the text a bit bigger and limits the width, and it really makes viewing Wikipedia much prettier and nicer - I think Timeless does a lot better job because it greys out the extra space and makes it symmetrical unlike in Vector 2022. I think improving symmetry would definitely be nice for the new skin. Galobtter (pingó mió) 23:25, 24 September 2022 (UTC)[reply]
Support. While not perfect, I've come around to the changes proposed here – let's not let perfect be the enemy of good. The narrower width makes it easier to follow long passages of text, and the floating sidebar and header are useful ideas. Clear WMF support to fix bugs after deployment will be essential, however. RunningTiger123 (talk) 23:50, 24 September 2022 (UTC)[reply]
Support. While I found the line width extremely jarring when I first switched over about a year ago, I now can't go without it. Other changes such as the buttons and the top right and the floating top bar would also be helpful for our readership. Yeeno (talk) 04:06, 25 September 2022 (UTC)[reply]
I've been using it for some time, and think it's generally an improvement. Those who don't like the fixed width can switch back to the old skin. I'd like a toggle for that, though, as well as a persistent search field. Sandstein 07:16, 25 September 2022 (UTC)[reply]
Support. I turned it on earlier to try the editing experience, given the concerns listed below, and within an hour it felt comfortable and natural. Personally I will probably continue to use Legacy Vector, since that's what I've always used, but it's easy to see how a new user starting on Vector 2022 would stick with it (much like I did with Legacy Vector). Having said that, I'm uneasy about setting this as the default skin for all logged in accounts – I'd prefer enabling it as the default for logged-out users and new users, and for the already existing accounts have something like a CentralNotice banner linking to a way to switch to it. Giraffer(talk·contribs)11:59, 25 September 2022 (UTC)[reply]
Support. While I have concerns with the new layout (primarily, I dislike 'information minimalism' when it comes to menus, and the changes to the header menu lean close to so minimalist they don't deliver the information they're designed to deliver), I generally prefer it over the existing template, I am glad to read that it may make dark mode simpler to implement, and the sticky menu and sticky table of contents on the sidebar are brilliantly useful. I also have concern that the present slightly dark underline is not enough to make it clear which tab is presently focused, but overall find the new tab design much more attractive. The prominent language-change button is also much more user friendly. JTdale🗩14:19, 25 September 2022 (UTC)[reply]
Support, echoing in particular TheDJ. This is largely a coat of paint; we'll get past its growing pains (already mentioned elsewhere) in exchange for a slightly more modern design. Let's do this again next decade, too. :) {{Nihiltres |talk |edits}}16:05, 25 September 2022 (UTC)[reply]
Support I did not like the width at first...at all..., but when I returned to Vector 2010 after using 2022 for a couple days, I immediately noticed how much harder I had to work my eyes to keep up with the wide text. I think my kneejerk reaction was just resistance to change. I implore people who oppose to give Vector 2022 a little time before coming to any conclusions. TarkusABtalk/contrib17:38, 25 September 2022 (UTC)[reply]
Support. Even though this is now a numbered list, I hope this RFC will not turn into mere vote counting (did we make sure eveysone's voice is heard... logged-off users?). People tend to be against new things, and those who are against tend to make effort having their voice heard. I hope that those who oppose the reduced text width will be satisfied with an additional setting. There are a lot of websites mentioned that have limited content width, I would add stackexchange (no ads!). My Full Support for Vector 2022+. It's design at its greatest and a breath of fresh air. PhilipPirrip (talk) 17:54, 25 September 2022 (UTC)[reply]
I agree. Most users of Wikipedia are readers—most readers never comment on talk pages, let alone RfCs—most (but not all) changes to Vector 2022 are intended to make the experience better for readers—everyone commenting here is an editor, not a reader. This disconnect *is* a big problem for this RfC and I'm not sure how it can best be addressed. Editors have a lot of power here, naturally—they're the ones who show up to discussions like this. It would be unfair to implement this change unilaterally against the wishes of a clear majority of editors, if it shakes out that way, but it would also be unfair to ignore that editors are a tiny minority of those who use the site. —Ganesha811 (talk) 04:22, 26 September 2022 (UTC)[reply]
Support. As a reader of wikipedia on a large display, I often have to make my window smaller because the content is too wide to naturally read otherwise. Limiting the width is a massive improvement, and the other changes are nice too. The only negative I notice is that the 'hide' button on the TOC causes it to move to a position that is unintuitive to me, I would expect it to collapse in place but instead it moves next to the article title with a button I would likely never click if I didn't know what it did. 70.28.60.254 (talk) 19:07, 25 September 2022 (UTC)[reply]
I agree about the TOC hiding being weird. When I tried it, I expected it would collapse to a single line with a "show" link, and I could just toggle back and forth between the two in-place. Instead, it just went away. Out of the corner of my eye, I could see that something had happened somewhere else on the page. After a few attempts, I finally figured out that it morphed into the dotted hamburger menu, but it's still unintuitive and surprising. -- RoySmith(talk)21:29, 25 September 2022 (UTC)[reply]
Support. Most features except the maximum width seem broadly acceptable. For the maximum width, I believe that it improves readability and it's worth attempting to standardize the experience across users who may have very different screen widths. 🌊PacificDepthstalk|contrib08:51, 26 September 2022 (UTC)[reply]
Support. I've been using the new skin for a few months now and it's definitely an improvement. Oppose arguments based on takes like "white space is wasted space" should be given very little weight, since the WMF has already rebutted them with the empirical research and design expertise linked above. Really, I question the wisdom of putting questions like this to a bunch of amateur encyclopaedia-writers all together, but here we are... – Joe (talk) 09:56, 26 September 2022 (UTC)[reply]
Support: I have been using Vector 2022 for a while now and I like how it looks. It provides a more modern look for Wikipedia. I found that I can scroll less thanks to the sticky bar and the table of contents on the side. However, I understand other people's concerns, mainly about page width and whitespace. I personally find the page easier to read with the smaller page width, but to address these concerns, I would appreciate a width setting, similar to the one on Fandom. Finding ways to fill the whitespace (like putting page tools on the right, similar to the Timeless skin) would also be appreciated. Otherwise, I think it's time to roll it out. Good job to the creators! Aditoo17 [💬|✒] 10:32, 26 September 2022 (UTC)[reply]
Support. Deploy it already. Whoever doesn't like it can disable it. It's an improvement. Also, I'm tired of people asking me why does the English Wikipedia looks old-fashioned than Hebrew and French. Honestly, this actually happens every few days. --Amir E. Aharoni (talk) 14:29, 26 September 2022 (UTC)[reply]
Support Net positive for the general reader. Editors always have the choice of going back to classic vector if they don't like it. The skin is responsive which makes it usable on mobile, a big win over Vector-2010. Sticky TOC is another improvement. Being deployed as default on English Wikipedia would hopefully mean improvements such as native support for configurable page width and dark mode would be considered in the future. – SD0001 (talk) 14:48, 26 September 2022 (UTC)[reply]
Support: Been in the industry for more than 22 years. Spent several years at Google during the early 2010s and helped usher in Material Design. Excellent product improvements here. Highly recommend implementing them. We need to move forward with UX improvements on Wikipedia. — Preceding unsigned comment added by 73.100.215.54 (talk) 09:44, September 26, 2022 (UTC)
Support - I agree with others that this is overall a much-needed improvement and refresh of the current default setting. I sympathize with people who dislike the screen width limitations, but I find it much easier as a reader and as an editor have not encountered any issues. ThadeusOfNazereth(he/they)Talk to Me!17:41, 26 September 2022 (UTC)[reply]
Support The data from the key results make it clear that overall right now that the new skin is an improvement, both for readers and the editors who have tried it and mostly stuck to using it. The fact that the team at the WMF has been responsive to feedback and diligently fixing bugs also gives me a lot of confidence that it will continue to improve over time. A lot of opposition seems to revolve around not personally preferring the increased whitespace/how width is handled, but since you can go back to the old look any time if you prefer that it's not very convincing argument for how millions of readers should experence Wikipedia. For readers, it's very uncontroversial and universally known that increased whitespace / less focus on the sidebar filled with tons of esoteric links will improve readability of the content, which you can see is true from things like the 50% increase in use of the TOS to navigate more quickly. In short, it's clearly better for readers, who are the primary audience of a default skin. Steven Walling • talk17:45, 26 September 2022 (UTC)[reply]
Support I won't personally be using it, since I am used to and prefer the 2010 skin. But the focus of Wikipedia is on our readers. This new version is better for our readers. Wikipedia has a top notch design team that worked hard on making a modern interface. The internet changes, and so must we. CaptainEekEdits Ho Cap'n!⚓17:50, 26 September 2022 (UTC)[reply]
I'll also add that today I discovered a website called Wikiwand, which explicitly sets out to make Wikipedia easier to read and use and claims a large userbase. To me, that is a big sign that our current interface is not working for readers. CaptainEekEdits Ho Cap'n!⚓00:17, 27 September 2022 (UTC)[reply]
Great point -- the existence of these sites (there are several!) is a very strong sign that many readers would welcome visual changes. ~ L 🌸 (talk) 17:09, 4 October 2022 (UTC)[reply]
Support Whitespace is not an issue for me because my zoom is set at 120%. I did test it out switching back forth with both my zoom and old vs. new and overall I find the 2022 version "cleaner". Having a drop-down to get to my talk page will take some getting used to and perhaps something the WMF should consider changing given, as editors, communication is a key component to what we do. However, the sticky headers and TOC are cool features. I did notice those features where not present in draft space though, which is another recommendation. S0091 (talk) 18:48, 26 September 2022 (UTC)[reply]
Support While I appreciate that editors in the oppose section don't personally like the fixed width, I'm yet to see any convincing argument that the new skin would be worse for readers or new editors, which is really what this RfC is about. Folks who like the current Vector skin can continue using it. Sam Walton (talk) 11:13, 27 September 2022 (UTC)[reply]
Strong support: I have been using the new design as well as following its development for a while, and I find it greatly improves Wikipedia and other projects. Very good work. It should definitely be the default. ~ nicolas (talk) 11:21, 27 September 2022 (UTC)[reply]
Strong support: The changes in this skin definitely improve overall user experience in my opinion. I also feel like it opens up a lot of possibilities for the future when it comes to adding/modifying features. Above all, this is making reading articles a pleasant experience and finding things you are looking for where they should be. Apart from visual design that can be polished and iterated, strongly support this proposal. Nirzardp (talk) 13:05, 27 September 2022 (UTC)[reply]
Support: As a longtime reader, one of the main issues in reading long articles is that you can't use navigation box to quickly go between sections since the former would be so far above, hampering reading experiences and forcing editors to make accommodations by removing texts which might otherwise be pertinent for the article's narrative flow; in turn becoming perennial headaches and debates among editors while sucking away valuable time in the process. The movable navigational box therefore can finally tackle the issue and help Wikipedia to realize its maximum potential. However there is a caveat that an extra click is needed to go to random page or see my contributions. I would certainly like a dark mode feature to be added as well. 45.136.197.235 (talk) 15:58, 27 September 2022 (UTC)[reply]
Support: Editors can opt-out of the new skin. Given the skin is widely adopted across other language projects, I think it's essential that we maintain cohesiveness in the Wikipedia experience across projects. I believe having this skin rolled out on English Wikipedia, will lead to lots of valuable feedback due to wider use, and will only get better. Jdlrobson (talk) 16:58, 27 September 2022 (UTC)[reply]
Support (reader/designer): I definitely prefer the new version much more, the width of text is easier to read and the content navigation column on the left makes it easier to jump between sections when you're deeper in the page. — Preceding unsigned comment added by 68.173.123.4 (talk) 18:06, 27 September 2022 (UTC)[reply]
Support: As a web designer, I appreciate the ability to know what part of a page I'm in and its relationship to the table of contents. The new design allows that. It circles back to the web's original focus: the document. — Preceding unsigned comment added by Windmill5000 (talk • contribs) 19:18, 27 September 2022 (UTC)[reply]
Strong Support: I’m a big fan of the new skin, especially the sticky table of contents. Visually it’s incredible to see where you are in an article without having to scroll all the way up in a longer article, it makes this skin feel fresh but also familiar. A feature that I didn’t know would impact my browsing experience too is how prominent the language switching tool became. Out of curiosity, I often check what an article looks like in multiple languages, and as a beginner to editing it’s unlocked a lot of serendipitous discoveries. The max width size is also a big improvement to my reading experience; it’s almost akin to reading a book where the type setting had really been considered. Because of this, the changes feel very intuitive. —Public Park (talk) 00:07, 28 September 2022 (UTC)[reply]
Support: The new table of contents is great. It makes sense now that it stays on the page as you scroll. The articles are easier to read with more white space. Change is necessary to grow! Gmdreyer (talk) 01:45, 28 September 2022 (UTC)[reply]
Support: Though I'd strongly encourage reducing more of the top-edges whitespace, e.g. as my condensed version tries to do, so that more content is "above the fold". And perhaps include other ideas from that CSS? Also, an idea: I wonder if we could make the site-sidebar appear beside (left of) the TOC if there's enough window-width for it (i.e. so that the ToC can be at the top, even with the site-sidebar visible)? Re: max-width: I like how wide-tables (example) overflow the fixed-width, and if we could do the same for images I'd be very happy. (disclaimer: I've previously worked with the Web team.) Quiddity (talk) 02:00, 28 September 2022 (UTC)[reply]
Support (reader/designer): The Vector 2022 skin is an improvement to the Wikipedia user reading experience. I am a web designer and developer and spend most of my days working out the best ways to present users with experiences and dynamic information. I am also a daily Wikipedia reader. The reasons for my vote to support implementing the Vector 22 skin are: Readability. There is a consensus in the design community on ideal paragraph line length to promote ease of reading that is related to the horizontal scanning motion of the eyes. Applying a maximum width to the body text achieves ideal readability, and the white gutter space on larger screen sizes promotes visual focus. (https://practicaltypography.com/line-length.html, https://eric.ed.gov/?id=EJ749012) Accessibility. The sticky / persistent Contents panel allows users accessing Wikipedia on screen readers and other assistive technology devices to navigate the content more effectively. The constant indication of where the reader is in relation to the page contents, as well as the persistence of the main page header, serve as reinforcement reminders for readers who may be prone to distraction. Localization. The increased visual prominence of the language selection dropdown menu emphasizes Wikipedia's commitment to providing free information to people all over the world in over 300 languages, and encourages flow of information across language divisions (https://wiki.riteme.site/wiki/Special:SiteMatrix). 12.245.94.94 (talk) 05:38, 28 September 2022 (UTC)[reply]
Support The lack of a modern interface presents an issue for Wikipedia in its goal of being the widely-read go-to internet encyclopedia. Everyone tends to hate UX changes until they get used to them; users tend to complain for about a week until they come to prefer the new version. An interface that is more in line with other, modern interfaces can only be a good thing for Wikipedia. Endwise (talk) 08:33, 28 September 2022 (UTC)[reply]
Support Overall an improvement on the current skin, and I don't mind the width, but I do agree with some of the other points of criticism raised in this discussion, eg. 1) the sidebar should open on mouse hover, and should overlay content rather than pushing it off-screen; 2) it should be more obvious where the TOC has gone when hidden; 3) the language switcher shouldn't be more prominent than the edit button; and 4) I'd prefer to have my talk page and contributions more easily accessible (if more room is needed in the top bar, surely "alerts" and "notifications" could be combined?). None of this moves me to oppose making this skin the default, but I hope the developers address some of these issues (especially the first two) prior to deployment. Sojourner in the earth (talk) 20:03, 28 September 2022 (UTC)[reply]
@Sojourner in the earth thanks for your valuable feedback. Regarding #2, if I understand you correctly, we will be fixing that soon (T311160). #1 will be sort of addressed in T317899 (in the sense that the main menu opens as a floating menu), but not exactly what you're suggesting. You can view both of those changes in the prototype here.
Support: Delete Vector 2010 and never look back. No opt-in skin will ever get as many eyeballs on it to identify and address issues as a new default. It's a 1.0. it's been very thoughtfully designed with readers in mind for over three years. If we implement now, a year from now (maybe even less than for big bugbears) most issues will be resolved. For folks still on the fence, don't just try it for a few days. Settle in and really get to know what it's like. Ckoerner (talk) 20:48, 28 September 2022 (UTC)[reply]
Support (moved from oppose). This is a half-step in the right direction. I hope to see some graphical improvements: basically allowing infoboxes, graphs, and pictures to float right into the whitespace. --JackFromWisconsin (talk | contribs) 13:14, 29 September 2022 (UTC)[reply]
Support - I was certain I'd dislike it, but I actually think it's quite nice and will probably switch to it at some point. Certainly there are technical details that have been pointed out as potenialities for improvement in both this section and the Oppose section, but I don't see anything that I'd consider to be a showstopper, or anything that negates the improvements in navigability. /Tpdwkouaa (talk) 16:30, 29 September 2022 (UTC)[reply]
Support (reader) - I like the new interface a lot. It's cleaner and makes it easier to focus on the content. I like how the table of contents remains in view as I scroll down the page. I understand people always find changes grating, especially with tools and spaces they have been using without change for years. But eventually I think people would get used to this and appreciate the improvements. 73.47.246.161 (talk) 19:18, 29 September 2022 (UTC)[reply]
Support - I like the new interface, but I think the more important thing here is for the Wikipedia platform to grow and evolve, progress is important especially for educational resources as they try to reach as many people and impact as many lives as possible. I support its adoption. MFA graduate (talk) 20:32, 29 September 2022 (UTC)[reply]
Support per CaptainEek. In addition, I've been using this skin since not long after its release and have been thrilled with most of the changes. I absolutely love where the table of contents fits in, and the reduced reading width matches how I read much of the rest of the internet on my computer. It's time to make it the default experience for readers. Ed[talk][majestic titan]00:08, 30 September 2022 (UTC)[reply]
If you are able to use it regardless, then why does this need to be enforced on many users who don't want it? Whether or not this is enforced as default is not going to affect whether you can use it. Tvx1 10:27, 30 September 2022 (UTC)[reply]
Perhaps the question (genuine rather than rhetorical) is whether we want editors (who are likely to opt out, because the skin wasn't designed for us) to have a different experience from readers. Certes (talk) 16:09, 6 October 2022 (UTC)[reply]
I’m even more a reader than an editor and I strongly disagree the proposed skin offers a better experience. Tvx1 22:28, 6 October 2022 (UTC)[reply]
Support - The new skin is miles better in usability as a reader and feels much cleaner and more organized than the clunky mess that is default Vector. Given that the web-team has been very proactive with listening to issues related to fixed width, removing it in editing mode, history mode (and other namespaces on a per-wiki basis [per wikisource] ) I personally don't see any issue with enabling it by default. Regards, Sohom Datta (talk) 00:34, 1 October 2022 (UTC)[reply]
Additionally, I feel the current oppose comments are coming for editors who are primarily editors (cause obviously), whereas the target audience of the skins would primarily not be power-users, but people who spend 90% of their time reading the wiki and maybe occasionally editing it.
That being said, I do get why a narrower screen might freak out certain editors (who want to efficiently read the most amount of text so that they can quickly identify faults in the article). Sohom Datta (talk) 00:43, 1 October 2022 (UTC)[reply]
As far as I can see, the proposal is to impose the new skin as the default skin for everyone. So no, there is no specific target audience. An even just for reading the new skim is not demonstratedly better. Tvx1 10:37, 1 October 2022 (UTC)[reply]
How can you not see a problem here. There are so many people against making this the default. So how can you support imposing this on half of the community who clear do not wish it? And the consession regarding width are a joke. The only place where they should budge, reading mode, is the one where they refuse to do so. Tvx1 10:46, 1 October 2022 (UTC)[reply]
Support Cleaner and more modern design, and it even hides the left panel entirely when the window size is shrunken. The table of contents are always accessible on the left-hand side of the page, and the search bar is so much better, not to mention it now shows images and short descriptions of article. Power users who don't like 2022 Vector can always change it in preferences anyway. Huge upgrade. Theknine2 (talk) 14:20, 1 October 2022 (UTC)[reply]
Eventually, but only after the bugs have been fixed (such as the coordinates placement that is downright embarrassing). Zerotalk01:11, 2 October 2022 (UTC)[reply]
Adding, also there are some basic design flaws. For example, when I'm scrolled to the top I see "Read, Edit, View History, (blue star), More (with pull-down)", but when I scroll down and get the sticky top bar, I see "(nonobvious icon), (clock icon), (black star), (human icon with pull-down)", even though there is more room on the sticky bar. Things with the same function should have the same appearance! For heaven's sake change the icons to matching text so that nobody has to click or mouse-over them to find out what they mean. Zerotalk04:01, 4 October 2022 (UTC)[reply]
Support I have been using it and I like it. It's a big change so i expect bugs. It seems to crash on Edge occassionally. On Chrome, editor menus page. more, tw don't play well together (can't open more). I wonder if fundraising realises that it might decrease down donations over the long term.Our brand is our site LOOKS like it is shabby, old fashioned, designed by ASD/Nerds/Honest clever people (or in the oft repeated words of the CEO "humble" = poor = needy = give us money because we can't find our car keys? But they haven't much choice as readers are declining. Possibly asking for a donation that is 1/3 of a days wage in India, and then bring up a shame type banner if they don't, might be an issue? Wakelamp d[@-@]b (talk) 13:31, 2 October 2022 (UTC)[reply]
Support. One, I have been using it for a month or so and it is overall better, I'm not changing back. Two, while good enough for old users, it probably is a better default for new users. — Preceding unsigned comment added by Nabla (talk • contribs) 08:08 October 2, 2022 (UTC)
Support Vector 2022 is a real improvement. I do however understand that some people may have different preferences in terms of font size, width, color scheme,... I personaly would welcome a future iteration of Vector 2022 that would come with an easy interface to change the defaults (font size, width, color scheme...). For example, Gmail comes with quick settings that allow users to change the "density" of the interface from "confortable" to "compact" and therefore adjust the view of your inbox to your personnal taste/needs. Why is this not an option here in Wikipedia? (ps: i am not a tech guy :-)) --Afernand74 (talk) 15:18, 2 October 2022 (UTC)[reply]
Support: I am a Wikipedia reader and this is a much improved reading experience. Seems like obvious progress to me. I run a 20 person design team. — Preceding unsigned comment added by 98.113.184.61 (talk) 18:51 October 2, 2022 (UTC)
Support At first my reaction to the skin was negative, and like others I didn't like the change to the page width. However, having given it a chance, the skin has grown on me, and I can see that the width changes do improve readability. One thing I have done, is modify my css slightly, to turn the white into tones of grey. It makes it easier on my eyes. Just wondering if any testing has been done on the colour palette? --Chris08:29, 4 October 2022 (UTC)[reply]
Support (reader/designer): Hello, I am a Senior UX Designer with 10+ years of experience designing digital interfaces and a longtime and consistent Wikipedia reader. For full transparency, I have been a WMF contractor on the Growth team a few years ago. With regard to the RFC, I wholeheartedly support the introduction of the new Vector 2022 skin as I think it greatly improves the overall user experience. The added white space, the reduced text content width to support industry best practices, and especially the redesigned ToC, all make for a more clear and pleasant reading. Also, I strongly support the design of the sticky header which gives prominence to the global search feature and brings a better composition to the features for logged in users. I will definitely miss the old and familiar logo, but that's for the better! A few UI issues have been mentioned in the comments above, including the affordance of the expanded menu icon, the inability to bring back the side ToC once hidden, and minor spacing and alignment fixes, but that should not impede the transition. In conclusion, Wiki deserves such a modern UI and I can't wait to browse articles on the new skin -- great job Design team! — Preceding unsigned comment added by 2.39.22.60 (talk) 09:10 October 4, 2022 (UTC)
Support: Having used the theme for a while now, I quite like it. I don't really get the objections to fixed page width but I would support a button to turn that off, since it seems to be a major sticking point for others. I especially like the sidebar TOC. Beyond just "I like it", I think it's important for Wikipedia to periodically update so that it looks like a serious and relevant website in relation to the rest of the web. I also think UI, like all things, has to develop incrementally, so my question is not "is this perfect?" but rather, "does this move Wikipedia toward a more modern look without introducing truly site-breaking bugs?" and my answer to that question is yes. ~ L 🌸 (talk) 17:06, 4 October 2022 (UTC)[reply]
Support Not perfect, but it is an improvement and it can be improved further. I wouldn't dismiss the concerns of others, but there generally seems to be a lot of resistance to change in UI which fades away fast. Each time Twitter has done a small change like modified one icon or the font, there has been resistance for some time, until everyone has just got used to it. Reddit changed their interface and currently just very small percentage (<5 %) opt to use the old skin, despite a lot of initial criticism. --Fix&Support (talk) 21:10, 4 October 2022 (UTC)[reply]
Support. Agree with Sdkb's I think that the skin at this point is a clear improvement over legacy Vector. It's also still clearly a work in progress, with areas for improvement I'll enumerate, and I think if those are addressed before it's deployed, it'll have a more positive reception with both readers and editors. In particular I strongly encourage the devs to consider the fixed-width toggle option so many are asking for (see, eg, how this works on fandom wiki). Come on, you know most people will never use this function, and Wikipedia will read the way you want it to for almost everyone. I didn't even know fandom wiki had this feature until someone mentioned it in this discussion. You can have your cake and eat it too: just do it. Personally, I really do not like Vector 2022, and won't use it unless there are some significant changes (or I take the time to write some custom css to fix some of the design choices that make it much harder for me to use and see if I can arrive at some reasonable compromise). But my personal opinion on it doesn't actually matter, since I can easily continue to use the old skin. Do I think the new one is very likely to be better for most readers in general? Yes, I do. And while I share many of the concerns raised by the Opposes, a great many of them are concerns only relevant to powerusers, not to the question of whether Vector 2022 should be the default for the vast majority of Wikipedia's readers. -- asilvering (talk) 22:24, 4 October 2022 (UTC)[reply]
Support: For my main Wiki editing, I have stuck with Monobook all these years (though new tool incompatibilities have been fraying that preference recently). Switched to V22 for a trial 10 days ago... and have stayed with it. There are elements I don't particularly like (the icons), and I have raised concerns at Mediawiki about the Add languages button: both its current empty content and whether its target aspirations involve the Content Translation tool. Definitely wrinkles needing attention but by and large the basics look ok and it can provide a platform for enhancement. AllyD (talk) 14:00, 5 October 2022 (UTC)[reply]
Support Been using Vector 2022 since it became to avalible opt in and frankly find it difficult to go back to legacy. I see it as a vast improvement personally (although they still might be some hiccups to work out) Cakelot1 (talk) 12:11, 6 October 2022 (UTC)[reply]
Support: I support the introduction of this new Vector 2022 skin, as the changes makes the content much more readable and the visual hierarchy of information now better matches the relative importance of the different content on each page. The improved prominence of the table of contents and max width make it easier to read, digest, and navigate longer articles and, I believe, better maps to the way the vast majority of users interact with wikipedia. The usage data confirms the improvement so it has my vote. As stated above, it looks like a good next step that's also a good starting point for future improvements. I've been a digital interface designer for over 11 years and now lead a team of designers, and I would gladly approve this work for release were it proposed by my team. — Preceding unsigned comment added by Uxdiogenes (talk • contribs) 09:52 October 7 (UTC) 2022
Support: Clear improvements with the readability and navigation. The condensed width makes this easier to read on desktop. And the persistent navigation should make it easier to quickly find the relevant sections of a long wikipedia entry. — Preceding unsigned comment added by Kathleenwarner (talk • contribs) 04:18 October 7 (UTC) 2022
Support: It’s a lot better than what exists now. Making Wikipedia easier to navigate as the rest of the web evolves is an important part of keeping this site accessible to all. As a UX designer who has been designing websites for longer than I’d like to admit, I’m in full support of this change. Cattsmall (talk) 21:14, 8 October 2022 (UTC)[reply]
I am personally not enthusiatic about the fixed width, but there's overwhelming research-based evidence as why this is important in modern web applications. There's definitely readability improvements and better navigation structure in the new Vector which collectively outweigh the perceived shortcomings. With the renewed commitment by the Web team to make the page width natively customizable, and the very fact that there's entirely an option for editors to not use the new skin, I think this change is overall good and ready for English Wikipedia.
It's natural to be resistant to change, but it's equally important to understand that things still have to change to meet evolving readers' need. Wikipedia look has to evolve, the way it evolved away from formely beloved MonoBook (currently used by mere 2% of editors; many of them inactive). For analogy, when Twitter made their recent major redesign I detested it with all my heart, and resorted to Chrome extension to keep the old layout, before they essentially pulled the plug to fully kill the extension itself. Gradually I become accustomed to the new style to the extent that I think I'd not to switch back to the old one even if it were there. Here, people have the option of keeping the old Vector if they wish, or even CologneBlue or Timeless. For the default experience, however, the new Vector is better. – Ammarpad (talk) 19:44, 9 October 2022 (UTC)[reply]
Strong support. I've been using Vector 2022 as my primary skin for well over a year now, and I'm confident it's a major improvement in usability (and esthetic appeal, although that's subjective and less important). A limited line-width is a near-universal best practice in design; I applied one in my custom CSS way back in 2015 (I reluctantly got rid of it in 2019 because I wanted to stay in touch with the default experience). The more-prominent search bar, the floating table of contents, and putting the "article mode" tabs below the title are also important improvements. I also applaud the Web test for taking a deliberative, consensual approach to building and deploying this; the Foundation has failed plenty of times in this respect, but we* also succeed, and this is a good example of that. Neil Shah-Quinn (talk) 21:55, 9 October 2022 (UTC)[reply]
* "We" because I work for the Foundation. I do not work with the Web team, and I learned about this RfC on the Community Portal, which I visit pretty regularly.
Support. I think the Vector 2022 is a well-considered step in the important direction of helping people who are new, and newer, to the Movement intuitively find and discover information they find useful while also piquing their curiosity about the origins of that information and the potential for them to participate in the production and maintenance of it. Note: I work for the Foundation.. Stussll (talk) 23:17, 10 October 2022 (UTC)[reply]
Support Being able to access the sidebar without scrolling to the top is massive. This a win overall and seems like the minimal amount of cleanup that can be done.: — Preceding unsigned comment added by 2601:645:8000:c0f0:218f:85c0:1554:8007 (talk)
Ultimately, support making this skin the default (and the narrow version the default default). I think enough has been said about why. I don't particularly agree with several suggested issues below, such as iconography and "2-steps to get to my user page"; as a Timeless user, I adjusted and don't really feel bothered at all. I bring issues that I think need to be sorted before full deployment, in no particular order:
Coordinates placement in Vector 22. I think this issue is something we could deal with fully as the community without a need for resolution of that task directly if we're willing to accept the coordinates living in a slightly different place in all skins, but I wouldn't hate to see resolved the fact that we're placing content in a metadata location as discussed recently on that task.
The responsiveness of tables in the narrower content display. This has a solution in two skins already (Minerva and Timeless both do Something) even though for some reason additional work is suggested. I don't really understand why. Maybe the option to use full width will diminish the issue.
Moving of article tools to the right. I appreciate greatly what Timeless provides access to on the right sidebar, and I think the approach could go even further if that bar were allowed to flex fully and fill up column-first such that we had hundreds of tools available in that space. (Maybe going so far even as to de-center the whole reading experience such that there is no whitespace on the left and all the space on the right becomes space for tools. Maybe a dream. :)
Support: I support the change for the new Vector 2022. The sidebar in particular is a huge step forward in usability and modern web design. I recommend also considering a faster way to get the sidebar back after you have disabled it (such as a hamburger menu that is accessible persistently on the page). As a PM and designer, I feel that this design was well-researched and documented. Designseattle (talk) 04:34, 11 October 2022 (UTC)[reply]
Conditional support, the condition being full width as the default. I use a large screen, and I personally use Vector 2022 with full width restored, having previously used MonoBook. feminist (talk)16:53, 13 October 2022 (UTC)[reply]
Support, I think this RFC is very showing of some of the editing community's disconnect to your average reader at times. I think this is a brilliant choice for reading, and what most people fail to realise is that [2.5x more people read the English Wikipedia on mobile than on desktop https://stats.wikimedia.org/#/wiki.riteme.site/reading/unique-devices/normal%7Cline%7C2-year%7Caccess-site~mobile-site*desktop-site%7Cmonthly], which means most visitors are already on width-limited screens and we really *should* have more content that considers this. People have also mentioned that the new skin is too "mobile-like" for a desktop site, which I think is irrelevant given that it's been a design trend for over ten years and has been proven to assist usability and accessibility (excluding Windows 8, of course). I would like to see a width toggle for those who prefer, or an option to open tables in a full screen view to browse them easier (I think I might've seen something like this on Fandom). I do like the limited width as it does make it slightly easier to read. Asking some of my non-editor friends, they said that they found it easier to read too, especially a friend who has difficulty reading did prefer that they had to do less work following the line on their larger desktop screen, and it also provides the sticky TOC on the left sidebar, which I also like and find extremely useful. All this being said, I still prefer the Vector 2010 skin for *editing* as it is more functional as an editing tool, but for reading? Vector 2022 is excellent, even better if there were the aforementioned toggles, and options to change the screen tint/font size etc. in future would be even better (a la Google Books). I appreciate the team can only do so much, and I've seen how carefully they've been treading already and I hope they don't see this wave of complaints over fairly minor issues as disheartening. Looking forward to seeing this going live! ✨ Edtalk! ✨ 04:13, 14 October 2022 (UTC)[reply]
Support as I think this will be more reader friendly, especially the sticky TOC. Basically I agree with User:Bilorv above that WMF should implement this regardless of the outcome of this RFC. The bugs mentioned is not much of an issue for the average reader. People using widescreen monitors are bound to be very less in number compared to "normal" desktop and mobile users. Where I am from, most people interact with Wikipedia from mobile only. I hope that one day this becomes the default for mobile. The current mobile apps are terrible for editing and mobile web is just about average. Legacy vector is not good in mobile desktop view, this skin is much better for that purpose. BTW couldn't we have thought of a unique name for this skin rather than "<current_skin> <current_year>"?ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:19, 14 October 2022 (UTC)[reply]
Support, this is a major improvement to the technical foundation enabling further innovation and increasing user satisfaction. Is a software ever perfect for everyone in every situation? No! What Vector 2022 achieves though, is improving the experience in various cases while not leaving the acommodated users behind where possible. It enables further features like dark mode, improves accessibility in different corners and does also provide cleaner interfaces for gadget or user script/style authors, to customize it. Without it, innovation will be massively slowed down and there will be lesser users working happily on the Wikimedia projects. Disclaimer: I'm the co-author of dark mode gadget on enwiki in my free time as volunteer, have been driving numerous accessibility, user-interface standardization and design system projects at the Wikimedia Foundation. There I'm part of the Design System team working on new Codex library, that is in use by the search experience in Vector 2022. Volker E. (talk) 11:15, 21 October 2022 (UTC)[reply]
Support, Look, I miss WinAmp, GeoCities, MySpace, and Ask Jeeves as much as the next person at times. Those were neat things, and they had sleek interfaces that I got very familiar with. Some very cool stuff indeed. I must admit, I do not like change in general. For me it can be very difficult. But when I think about things that seem to survive for decades (or more :-), it's things that change and EvOlvE. And look, folks, it's no secret that some of us are slowlyyy getting older here. Shall we cling onto what's comfortable to us at the expense of youngsters (who may want to participate) feeling more welcome (as the research data has shown)? I don't think we should do that. Indeed I think it would be counter productive to the longevity of our project here. We should try to be flexible. And if anything, we should hope that the interface changes more frequently in the future! Let's welcome the newcomers with open arms and an interface that evolves with their needs : ) Long live Wikipedia! — Preceding unsigned comment added by 2600:1700:9ffc:34b0:7028:7587:82e2:8c4b (talk) 12:21 October 21, 2022 (UTC)
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]
in the editing mode, the limited width is disabled - both in VisualEditor and the wikitext editor. That seems to be an effective solution At least in VisualEditor mode I would find this worse, since now the text I wanted to edit is in a different location. --Rschen775400:12, 23 September 2022 (UTC)[reply]
@SGrabarczuk (WMF)is it disabled in VE, though? Editing that page, it seems to have identical width constraints as in read mode. (I haven't been paying attention to design discussions for this lately -- I know there was a back-and-forth about the accuracy of VE as a preview being affected by an inconsistency there...) DLynch (WMF) (talk) 19:07, 26 September 2022 (UTC)[reply]
That article looks better with the new skin; in the old skin, the massive table rather resembles an Excel spreadsheet instead of an encyclopedia article. Enterprisey (talk!) 04:14, 23 September 2022 (UTC)[reply]
@Xaosflux - thanks for flagging this. We didn't crop the images - this is just due to the size of my window when I was taking the screenshot - should roughly correspond to the width of the right and left sidebars at 1400px (most 13 inch screens). We can potentially add some additional images for screens of different sizes or highlight/bold the "try it out" link to encourage people clicking on that. OVasileva (WMF) (talk) 19:07, 22 September 2022 (UTC)[reply]
For reference, this is how the Pluto article looks for me, it has a width of 4K.
@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]
This should be a good motivation for editors to stop assuming they can put stuff next to eachother and that it will look the same in all screen resolutions:) —TheDJ (talk • contribs) 08:47, 23 September 2022 (UTC)[reply]
Even accepting this argument at face value (which I strongly disagree with): Pluto is a FA. How many more instances of this are there on the English Wikipedia? At a minimum, we would need to go around and change all these, or otherwise we have a bunch of articles looking like this. --Rschen775418:07, 23 September 2022 (UTC)[reply]
Yes, some articles look like a scrapbook with too many diagrams, tables and pictures next to each other. There should be an option to put (at least some of) these *into* the right margin (→Marginalia of tufte or classicthesis LaTeX styles). Ponor (talk) 14:22, 23 September 2022 (UTC)[reply]
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. Updates on reimplementing the Graph extension, which will be known as the Chart extension, can be found 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]
It does say later on that most of the respondents that said the old skin is easier to use also mentioned it is because of nostalgia / resistance to change. Sungodtemple (talk) 23:30, 22 September 2022 (UTC)[reply]
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.
Re point 2: that's actually confirmation of BilledMammal's point: if the benchmark for whether or not the feature is a success is whether or not it results in a decrease in scrolling, you are taking for granted that decrease in scrolling = improved experience. Now, that's obviously going to be the case pretty often, but it does depend on the methods used to achieve it, and how any downsides from that weigh up against the benefit of less scrolling. (To take it to a humorously-intended extreme to illustrate what I mean: if you build things so that, once readers have scrolled down, they quite literally cannot go back up, that's going to reduce scrolling to the top by quite a bit! But it's rather hard to argue it's going to improve the experience of most readers) AddWittyNameHere01:40, 23 September 2022 (UTC)[reply]
@SGrabarczuk (WMF), how many unfinished responses were there? If there were a significant number, how do the numbers change - e.g. for the "which skin is easier to use" question - when the unfinished responses are added in? Enterprisey (talk!) 03:55, 23 September 2022 (UTC)[reply]
I actually find this kind of statistical misrepresentation disgusting. As for first-use statistics, we are aiming for a skin that clearly and demonstrably improves on the old one. The only acceptable response to this result is longer tests, showing reversal of preference following subjects’ extended use of both skins, not a suggestion that there will be tests once we gratefully accept our new skin. — HTGS (talk)03:44, 28 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]
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 — ProPublica, BBC, Snopes, AVClub, BBC, The Lancet, Reddit, The World Health Organization, Baidu, Medium, or any other that you would like to choose — you will find that they all have width limitations on their content. If you look at newspapers, books, and magazines, you will find the width of the text all falls within the same range. The approach is standardized for good reason. This is not something we are reinventing, or making a guess at. It is a clearly established best practice. Thanks, AHollender (WMF) (talk) 21:22, 22 September 2022 (UTC)[reply]
I appreciate these responses. Without support from empirical testing - not just opinions - I am not willing to change my !vote. I appreciate that you may not want to look for and provide links to that research for one editor. I am simply extremely wary of changes or decisions made in web design at this scale that is not well supported by empirical research. ElKevbo (talk) 21:45, 22 September 2022 (UTC)[reply]
@ElKevbo thankfully there is plenty of empirical research [EDIT: updated list with the help of editors]:
Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language -- "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies -- "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
Shorter Lines Facilitate Reading in Those Who Struggle (2013), from PLOS_One -- "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University -- "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting -- "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed -- "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."
Please note: the range of line-lengths studied is somewhat narrow. Some of the research shows certain positive effects of longer line lengths, but those line lengths are significantly less than what results from the maximum width we have in place in Vector 2022. In other words, even with Vector 2022 we are well beyond the maximum recommended range of any of the studies. AHollender (WMF) (talk) 02:54, 23 September 2022 (UTC)[reply]
I think there is confusion of means and goal here. The goal is usability/readability and the debate is actually focused on forcing vs choosing. I read Nielsen's book way back when and IIRC, a key principle he advocated was letting the user's device/browser modify the parameters of the display.
IMO, those advocating a forced default are saying either (or both) of the following:
1. users don't know what's good for them, look at all the research that supports shorter line width!
2. users don't know how to adjust basic preferences to fit known generalizations about readability
Quite a number of votes here, both Oppose and Support, address the issue of choosing, but I don't see the developers doing that. Mostly they seem to be defending the means because they assume (perhaps correctly) that a large fraction of worldwide users agree with the goal. Martindo (talk) 00:31, 25 September 2022 (UTC)[reply]
@Privybst, just to be sure we both understand the context. If it's a no-go for you, meaning, your personal experience, you can opt out and never see it again. We're fine with that, and we don't consider this as a major blocker preventing from enabling Vector 2022 for all the Vector legacy users. However, if you try to use it for a few moments and point out some specific issues, we will be able to address them. Perhaps there's something that could be improved. SGrabarczuk (WMF) (talk) 19:55, 22 September 2022 (UTC)[reply]
No, I believe that the new skin has a very big issue with dead space, which makes navigation extremely difficult and inconvenient. Of course, I opted out globally, but instead, users who want to use this skin have to opt it in. The whole question is what will be the default, especially for unregistered users. Privybst (talk) 20:12, 22 September 2022 (UTC)[reply]
I noticed dead space between the contents frame at left and the main body. I use a MacMini linked to a TV, so any forcing of display dimensions could be problematic for me. Martindo (talk) 03:56, 24 September 2022 (UTC)[reply]
You can't opt out if you're not logged in though. And you've even hidden the login button to make it harder for people to log in. - Nikki (talk) 23:50, 29 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]
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.
@AzaToth thanks for replying. Honestly, we are following the well established research regarding optimal line-length. I am not coming up with some definition on my own. Have you read the research yet?
It looks like we will end up building an official toggle for full-width (see below). My initial opposition to that is nothing personal, it's just because it goes against the research. Again, reference books, magazines, other websites — I honestly believe it is a standard practice for a good reason. AHollender (WMF) (talk) 22:40, 22 September 2022 (UTC)[reply]
@AHollender (WMF) - I did read the research (the formally cited one that's 17 years old, plus a bunch of others I found myself). I struggled to find any research that was a) genuinely analogous to Wikipedia (that is, no ads, a need for a tool sidebar, moderate page hangtime, images on both sides) and b) a decent statistical sample. I did find a 2013 study that had most of the above, but only with 24 participants. Could you point me to a modern or modernish piece of research with the above - I certainly imagine I didn't do an exhaustive literature review! Nosebagbear (talk) 15:30, 23 September 2022 (UTC)[reply]
Hey @Nosebagbear, so part of what is difficult here is that as far as I have found nobody has studied the kinds of line-lengths many people in this discussion are advocating for. Most studies focus on the 55–100 character per line range. On Legacy Vector, if you are using a large monitor, you regularly get ~300 characters per line, with a minimum around ~225 (if text is next to an infobox or floated image). So, the way I've made sense of this is:
Most of the studies I've found, old and new, advocate for shorter line-lengths (and even when they advocate for longer ones, they're still talking about line lengths shorter than we currently have in Vector 2022)
I assume it's meaningful that the studies do not include lengths over ~100 characters per line, but of course I cannot be certain as to why that is
I'm triangulating based on other references (again, maybe flawed, but also somewhat hard to imagine that basically everyone else who does typography in print or on the internet has gotten this wrong). The intro to this study articulate this pretty well.
Ultimately I think what is needed is more research, specifically for Wikipedia articles, and including line lengths that result in 300+ characters per line. Until then, the conclusion I've come to is that we should err on the side of caution, and follow the established best practices. We can always make the text wider if we find that to be beneficial — we are certainly not opposed to that.
@AHollender (WMF) - thank you for your quick and detailed response. In that review, it does write "The format of Wikipedia is similar to other web pages that use different fonts, font sizes, whitespace, etc...so the recommendations from this literature can still support", but your above on characters would seem to indicate that that paragraph is not so justified in that regard. Shaikh's work was also interesting in that it suggested it was mid-length that people didn't like, with both shorter and long-length being okay. I wonder whether that is more relevant here - short-length means that eyes can just look forwards and move down. Long-length means that much less downwards (and scrolling) is needed, with midlength just being worst of both worlds.
.
On a different note, I don't know whether it would have fallen into this particular lit review (as it's much more purely Wikipedia focused), but did the team consider how to handle the major community worktime issues that come from needing to redesign very large numbers of articles to match this layout better (most notably those with wide tables, now both looking odd and jutting well below) and articles with images on both sides (there are smaller scale ones, as well, such as where TOC was moved from the normal place on V10) Nosebagbear (talk) 16:31, 23 September 2022 (UTC)[reply]
Hey @Nosebagbear, apologies for the delay. I think that the overall experience of reading a Wikipedia article is similar to the experience of reading other webpages such that the research is applicable. However there are some differences, which we can take into account. I wrote about that here: Why not to choose "the simplest" solution. Three things I've noticed in some of the comments on this page (not your comments), which are interesting to me:
People thinking that Wikipedia is vastly different from every other website such that we shouldn't even begin to consider the research, general typographic recommendations, or examples of other websites, because they bare absolutely no relevance
Nobody has offered up research indicating that 200, 300, or more characters per line is good for readability/usability. Nobody has provided a single example of other popular content websites (non-profit, government, or otherwise), that don't have maximum width limitations on their text. It's helpful to question the research that recommends shorter line lengths, but if there was a valid counterargument I think there would at least be some proof for that.
People thinking that by making some changes to the interface, we're enviably going to end up entirely corrupting the experience, and that we might as well be some evil tech company who mines user data and litters the site with ads
I think there is a lot of nuance here. I agree that Wikipedia is very different in so many (great) ways from the rest of the internet. And at the same time, when it comes to text settings, it's not necessarily that different. We should probably increase the font-size a bit (this has been studied specifically using Wikipedia pages, and we had a great discussion about that following the prototype proposed here), and have a max-width as to avoid super long lines of text. I honestly think in this case it's not so complicated.
Regarding "the major community worktime issues that come from needing to redesign very large numbers of articles to match this layout better". I doubt my answer will be satisfactory, but here is how I think about it. Firstly, for anyone using English Wikipedia on a laptop these issues are already present. It seems that many editors have large monitors. We don't have screen resolution data for Wikipedia specifically, but as far as we can tell from the data that is online (example), most people do not. So regardless of whether or not there is a width limitation on the content this is an issue we need to fix at a systematic, template level. Are we making the formatting issue (specifically for tables) worse for people with large monitors with Vector 2022? Yes, I don't think there is anyone trying to deny that. For a while I've thought that we should invest more in the formatting of articles (both in terms of templates/software, and in terms of cultivating a sort've designer/layout editor role within the community).
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?
Could you clarify "we" and "observed"? Specifically list the number of the decision makers, as well as ALL combinations of browser/processor/display unit that were surveyed. I'm wondering if there is a pro-laptop-class bias in the assertion about popularity (I mean "second most popular") that is a justification for the change. Martindo (talk) 04:01, 24 September 2022 (UTC)[reply]
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]
NP Alex! I should have also mentioned in my initial comment that there are some aspects of Vector 2022 that I do like, like the scrollable TOC (though it is a bit janky sometimes). But if I had to choose between them, I'd rather have full-width text. SGrabarczuk's comment below does assuage some of my concerns. ♠JCW555(talk)♠ 00:15, 24 September 2022 (UTC)[reply]
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]
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]
@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 ProPublica, BBC, Snopes, AVClub, BBC, The Lancet, Reddit, The World Health Organization, Baidu, Medium, and Medium. I also find the same width limitation in books, newspapers, and magazines.
AHollender (WMF), it seems as if principles of universal design may not have been fully considered, if this proposal is based on research suggesting this appearance works better on non-Wikipedia websites for a "majority" of readers. From my view, principles of universal design may support advertising this more mobile-style appearance, so Wikipedia readers can select this option, instead of setting this new skin as a default. It seems more inclusive to have the familiar version as the default and the new version as an option. My perspective is reinforced by your suggestion [1] that what seems sufficient for a "majority" of readers of non-Wikipedia websites should be considered "optimal" for Wikipedia readers and editors. Your link to research also leaves me less convinced about setting this as a default. Also, for participants who may not be as familiar with discussions here, a review of the WP:BLUDGEON essay might be helpful. Thank you, Beccaynr (talk) 23:18, 22 September 2022 (UTC)[reply]
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#6545 21:39, 22 September 2022 (UTC) Striking my oppose for now so I can formulate a fuller opinion on it as I opposed after only a few minutes of trying it out. ― Blaze WolfTalkBlaze Wolf#654516:22, 26 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. ~ MatthewrbTalk to me · Changes I've made22: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. ~ MatthewrbTalk to me · Changes I've made22: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]
@OVasileva (WMF):I feel this is no longer a request for comment to generate consensus if you'll have to persuade editors to buy the idea of the 2022 skin. Allow the community choose what they are convenient with. I don't see any reason why an editor will oppose and they're indirectly being convinced to buy the idea. I might be wrong, but that's how I feel right now. Comr Melody Idoghor(talk)22:46, 22 September 2022 (UTC)[reply]
Oppose. Reaper Eternal's comment above echoes what I was about to write, so I'll not repeat it. The new skin may be decent for reading (despite the survey above) but it's a big step back for editing. The one use case I can see is if the intention is to have one skin for readers and another (supported indefinitely) for editors. However, that risks editors releasing content which doesn't work well in the readers' skin. It's true that most other sites shoehorn their content into a central column, but that's mainly to create artificial sidebars for advertising. We're better than that. Certes (talk) 22:30, 22 September 2022 (UTC)[reply]
@Certes, thanks for your comments. Thankfully optimal line-length for readability has been researched for several decades now. It is not something we need to guess at, or define on our own. Are you familiar with "Reader mode" in Chrome, Firefox, or Safari? I think these modes usefully demonstrate that limiting line length is not about making space for sidebars or advertisements. Similarly, you can find these best practices followed in printed materials like newspapers, as well as websites without advertising (ProPublica, Ars Technica, AV Club, The Guardian, BBC, etc). AHollender (WMF) (talk) 22:46, 22 September 2022 (UTC)[reply]
One point I missed out, which others have made well: the current text links (top right) are much clearer than the new icons, which one has to hover over to find out what a blob on a squiggle means. Icons may have language independence, but this is English Wikipedia. Hiding links such as the sandbox in a drop-down does save space, but that space (top centre) remains white rather than being used for anything better, and creates a risk that new editors will fail to discover critical features such as their user talk page. Certes (talk) 11:21, 23 September 2022 (UTC)[reply]
Oppose@Red-tailed hawk: Covered my concerns in the first comment, and only further defined by others here. I am not a fan of the trend towards more whitespace on internet pages, the endless scrolling, and general mobile-ization of pages. Honestly if this was the default when I joined, I probably would not stick around. Kaiser matias (talk) 22:45, 22 September 2022 (UTC)[reply]
Oppose Too much empty, wasted screen space and too many unnecessary clicks needed to get to basic pages (like the user's Talk and Contribution page). Not an improvement over Vector 2010 at all. Some1 (talk) 23:13, 22 September 2022 (UTC)[reply]
Oppose I've never been a fan of using icons for menu items. I can't read icons. It's mystery meat navigation. We have a little bit of that with monobook. Vector makes that worse. Trying to solve some problems by introducing other problems isn't a way forward. --Hammersoft (talk) 23:19, 22 September 2022 (UTC)[reply]
Oppose because of technical and UI issues. 1. "This looks squished and hard to read", When I used vector 2022, I had to ZOOM in onto the page to be able to read it properly. reported by another user above has nothing to do with limiting the width, as alleged by SGrabarczuk (WMF). It's caused by an incorrect meta viewport value that's incompatible with the implementation of responsiveness on smaller screens. If you need a way to observe it, open FR Wikipedia on an iPhone and switch to desktop version - the main text is unreadable, and the menus are completely unusable. It's a pure technical bug due to lack of testing, not a limitation of limited-width layouts. 2. The contrast of the links with the background is definitely worse than on the current version and makes them, and consequently heavily wikilinked articles, harder to read. I believe the decision to increase ease of locating wikilinks in favour of overall readibility of the article text was misguided. 3. Location of article contents in the bottom below the menu is counter-intuitive; hiding subsections by default is completely unnecessary - why would two clicks be needed to navigate to a subsection? PaulT2022 (talk) 23:51, 22 September 2022 (UTC)[reply]
Having said that, I think Vector 2022 is modern and well designed - it's all comparatively minor issues that together make it genuinely worse than the legacy. PaulT2022 (talk) 00:05, 23 September 2022 (UTC)[reply]
Yes, when in article text: the words stand out too much and I have to make an effort to stop and adapt eye to a sudden bleak word, if it makes sense. It looks ok in signatures on talk pages or references, but it just makes main article text too hard to read.
I believe that Nature and ProPublica, referenced as model websites in the FAQ below, use more contrast colors, similar to the ones Wikipedia uses currently. If the change to contrast between text and links is absolutely necessary for accessibility, I'd prefer black colour with thin underlining or bold font for "blue" wikilinks instead of light blue - see Bloomberg, Reuters and BBC for example. PaulT2022 (talk) 11:29, 23 September 2022 (UTC)[reply]
That absolutely makes sense. I have to exert more effort to read the purple than the blue, but good to hear more voices here.
I love the subtle underlining of the BBC. I imagine bolding would not work in the context of Wikipedia, as links are everywhere and do not need the extra emphasis. Underlining and nonbolded colours with slightly less contrast to prose may work best. I wonder if underlining has been considered as a way to meet accessibility needs (@AHollender (WMF) and @Volker E.)? The Guardian also has little subtle underlining. Femke (talk) 16:31, 23 September 2022 (UTC)[reply]
@Femke oh yes. What I wrote above applies to blue and purple equally, didn't mean to imply that purple is fine. Sorry for the confusion. (Red too, but there are few red links, so I don't think it really matters.) PaulT2022 (talk) 16:57, 23 September 2022 (UTC)[reply]
Interesting to hear this - I find them both almost completely indistinguishable from regular text in Vector 2010, and better (but still not great) in Vector 2022, due to the low contrast. I had to use custom css to see visited wikilinks. But I would never call the BBC style "subtle"! Those links are very easily visible. -- asilvering (talk) 04:52, 24 September 2022 (UTC)[reply]
@AHollender (WMF): you may have missed my ping. It would be a real shame if the new skin creates a larger accessibility problem than it solves... I've been using subtle underlining now for a couple of days, and I find it quite neat. I'm sure an expert can make this look good. Femke (talk) 16:30, 29 September 2022 (UTC)[reply]
Hey @Femke, I think it's great that you're passionate about accessibility. I have seen your multiple comments about this on the RFC. I think it's most useful for you to continue the current conversation rather than starting multiple new threads about this in various places. It makes it difficult for myself and others to engage with, and doesn't give new participants the opportunity to see the full context. AHollender (WMF) (talk) 17:08, 29 September 2022 (UTC)[reply]
Apologies, I'm quite new at phab, and wasn't sure if it's appropriate to continue replying there after it's been closed. I also wanted to make sure I understand other people's accessibility needs before commenting there again. Femke (talk) 18:14, 29 September 2022 (UTC)[reply]
STRONG Oppose In the proposed skin the articles have reduced space and the left menu and right sides dominate the screen. This is the opposite of the way it should be. The article should dominate the screen. WhoAmIYouDoNotKnow (talk) 00:09, 23 September 2022 (UTC)[reply]
Oppose; there's too much empty space on the left and under the search box. The "hamburger", ellipsis and chevron menus aren't intuitive and are easy to miss – how does a random visitor know what they're for? I understand the need to remove clutter (hint; ever heard of the in-browser "reader view" feature?) but how are random visitors supposed to find this stuff? Navigation frames are 20 years outdated. It's not an improvement over the extant default skin. Baffle☿gab00:37, 23 September 2022 (UTC)[reply]
Oppose Having user links like talk, contributions, preferences, sandbox in a dropdown is just adding an extra click to access commonly used links. The watchlist icon looks like a combination of a browser bookmark and notification sidebar icon. Just call it what it is — watchlist. But the narrow main text width is the big no-go for me. It causes layout issues. Even the example Pluto article shows problems. Scrolling down where there are tables and images, we get jumbled and dislocated tables and images, along with even worse squished text. For layout specifically (and in general) it is displeasing to look at. DB1729talk00:46, 23 September 2022 (UTC)[reply]
Oppose primarily due to fixed width per Reaper Eternal and Certes. It would be good if the proposal pointed out that adding ?useskin=vector-2022 at the end of the URL allows you to preview how it would look on any particular article or device. There are good aspects to the skin, particularly the table of contents. For example I have disabled ToC on articles such as Electoral results for ... because with 65 elections across 17 decades the ToC results in a lot of scrolling to get to the article - tested the same page with a ToC in the new skin and its a big improvement. I access WP via my phone, 13" laptop, desktop with 2 24" screens and desktop with a 50" screen. The new skin is fine on my phone or laptop, it is only when I am using either desktop that it becomes limiting. This is particularly apperent when editing where I have articles side by side. --Find bruce (talk) 00:56, 23 September 2022 (UTC)[reply]
Oppose I remember reading about this a year ago and I hated it. I have a desktop computer and the white space is so ridiculous. It feels cheap, like there are are supposed to be advertisements or something to fill in the space. One of the things in favour of this was about how it purportedly was easier to read words with less characters per line. However this negates the fact that in many articles, images and infoboxes already shorten line length. In some articles, infoboxes can take up a significant amount of the page. This means less opportunities for images. It also squishes tables. I would argue that it makes text less readable than the current vector. Not to mention talk pages with discussions that indent the text makes for so much more scrolling. I feel bad for the French Wikipedia. Heartfox (talk) 01:07, 23 September 2022 (UTC)[reply]
Regretful oppose. I regretfully find myself in this section, two blocking concerns, and one more major concern.
The box-ticking on accessibility wrt link colours. Rather than accessing accessibility with users, a choice has been made to only check the WCAG standards. The physical contrast tested by WCAG is but a proxy for the biophysical or perceived contrast. Those two metrics can differ, with user tests sometimes giving opposite preferences compared to contrast checkers (see Myth 1, and from WebAIMFor many of us, some of these combinations are not very readable. That is why 4.5:1 is the minimum required by WCAG.., look at the actual contrast difference of links with the same physical contrast). I'm not the only one that didn't have accessibility problems before, but now struggles to read the visited links. Wikipedia is very link-heavy compared to other websites, and the number one priority should be to make the text of the link readable. Only if that accessibility requirement is met, should others be prioritised. I see a couple of ways forward
Different colours can be tried. Is a more reddish purple easier to discern? Pinkish? blueish?
A compromise colour can be chosen that does not quite meet the WCAG standards, but which does meet user tests for accessibility
I'd even be okay with underlining links if that means the colours can be matched closer to the rest of the prose.
The white space on the right. I love the smaller column width, and I'm excited how that will benefit readers, and entice editors to write easier prose (rather than superlong paragraphs that, in the new interface, fall of the screen). However, the white space on the right looks quite ugly. Can't we mimic reddit with a symmetric grey colour around the edges. The article tools for editors are a good solution to dampen the bright white, but most people interacting with Wikipedia are readers.
Addendum. I've had a look around a large set of other websites. Almost all use white space on the sides. The major reason why that works for them but not in this design is symmetry: the white space (or sometimes grey), is spead equally on both sides. Could this be implemented for logged-out editors/those with the future editing tools collapsed too, @SGrabarczuk (WMF):? I think that may sway 10% of the opposes here. Femke (talk) 11:21, 23 September 2022 (UTC)[reply]
Not a blocker for me, but a major drawback is the the fact that the new skin breaks the TOC limit template. (the claim No existing features or tools were removed as a result of the new skin. is still present in the text, despite the fact it I pointed this out). With less space for the TOC, this template is key to hide less important headings. It's used around 20,000 times, and some pages, like WP:FAC become unworkable without. Femke (talk) 02:32, 23 September 2022 (UTC)[reply]
Strong oppose - I showed the new view (on a HD desktop screen at 100% scaling) to my family a couple of months ago and they were convinced that I was showing them a mock-up of Wikipedia with ads. Very few changes have been made to Vector 2022 since its initial deployment in 2020, and the way in which the WMF employees seem to consider this a rubber stamp for a done deal makes me sceptical that any problems brought up will be addressed to the satisfaction of the community. (I have copied this over from Wikipedia talk:Requests for comment/Deployment of Vector (2022) since I initially posted this there after getting lost in the maze of the short neutral RfC statement.) DaßWölf02:02, 23 September 2022 (UTC)[reply]
Changed to strong oppose. It seems this design has problems on all layouts. Developers' trying to sidestep the RfC rules and badgering the opposes doesn't bode well either. English Wikipedia readers should not be involuntary beta testers. DaßWölf15:16, 24 September 2022 (UTC)[reply]
Oppose - Regardless of whatever reasons the devs give about fluidity and whatnot, the white space is a huge eyesore and simply intolerable. Nothing I have read from any of the developers' replies have convinced me of its benefits. My greatest peeve, possibly exceeding that of wasted screen space, is the double arrow on the top left. Such a button implies that there's a "main page" to return to, similar to UIs on phones. It gives off the vibes that all articles are simply subsidiaries of the main page. Worst of all - it performs a function that is entirely unexpected - simply collapsing the main menu. As an active editor, it's unlikely I will ever collapse it as I would require access to its functions, leaving the arrows there permanently. Seloloving (talk) 05:03, 23 September 2022 (UTC)[reply]
Strong oppose – I have commented multiple times throughout the development process that this redesign is (a) fundamentally misinformed in scopre and (b) a big step backwards. To summarise my criticism, the Vector redesign has been approached as if it is being produced for mobile, touch-enabled devices, despite being a desktop user interface. 5225C (talk • contributions) 06:06, 23 September 2022 (UTC)[reply]
A lot of internet traffic comes from both mobile and desktop. The current Vector skin is completely unusable on a mobile device. On the other hand, the newer Vector skin could in theory be used on mobile but it still needs more changes to be fully responsive. I am posting this on timeless, a skin designed for responsive design - regardless of screen size or layout, everything is fully functional (almost) and I prefer it over the mobile front-end. Aasim - Herrscher of Wikis ❄️ 14:47, 23 September 2022 (UTC)[reply]
@Awesome Aasim: I just tried the new Vector skin (desktop view) logged out on a mobile device. It looks much the same as the old desktop view, except the text column is a good deal narrower (due to the TOC column). Images on both sides of the text create bigger gaps in text as some single words can no longer fit between them. The new design at first glance does look like it was optimised for mobile use, but it seems to be a step back there too. DaßWölf15:16, 24 September 2022 (UTC)[reply]
@Awesome Aasim: The current Vector skin isn't used for mobile devices, they have their own user interface. My criticism is that the new Vector design, which is a desktop interface, appears to be better suited for mobile devices than it does for desktops. It is not fit for purpose. 5225C (talk • contributions) 10:37, 25 September 2022 (UTC)[reply]
A lot of modern websites are designed with variable screen size in mind. Google, wikiHow, and Microsoft are a few such sites that are responsive; no matter the screen size or device the site remains mostly usable. Sure the mobile front-end handles mobile devices but like I said before it is still severely limited because of the functions which actually work on mobile. Aasim - Herrscher of Wikis ❄️ 13:56, 25 September 2022 (UTC)[reply]
“The current Vector skin is completely unusable on a mobile device.”— This is not my experience. For years, I have used desktop vector for reading and editing on mobile, and I’ve found it a much better experience than Minerva. In fact, I have a user script installed that redirects me to desktop when Google sends me to the mobile site. Text is a bit small but I can always zoom or increase the text size. —pythoncoder (talk | contribs) 18:13, 25 September 2022 (UTC)[reply]
Up until recently it was a first-generation iPhone SE with a 2-inch (640-pixel) wide screen. Now it's the iPhone 13 Mini which is a little wider. In either case, I can't say it's problem-free but everything's still usable. Probably comes down to a matter of level of tolerance. That and operating system — I have no idea how it looks/functions on Android. —pythoncoder (talk | contribs) 22:09, 25 September 2022 (UTC)[reply]
Strong oppose - Absolutely nothing wrong with the current UI. Replacing clear text buttons with obtuse logo buttons is a massive mistake. Desktop users do not deserve to have to put up with ridiculous mobile phone style UI design. HumanBodyPiloter5 (talk) 08:23, 23 September 2022 (UTC)[reply]
As it currently stands Wikipedia is one of the few major websites left that retains a clear user interface where every button has a clear purpose that builds trust in readers. In an age where corporate websites constantly seek to erode at the concept of consent itself with obtuse UI and buttons saying "yes" and "later" rather than "yes" and "no", I believe Wikipedia has a strong ethical responsibility to lead by example with a user interface that is clear and free of meaningless iconography. HumanBodyPiloter5 (talk) 11:06, 23 September 2022 (UTC)[reply]
Only more reason to oppose the changes more strongly. The rest of the UI changes I do not have particularly strong feelings on, but I am vehemently opposed to hiding basic functionality in drop down menus accessed through opaque abstract symbol buttons. If Wikipedia is intended to share knowledge with the world then such a design choice should be considered anathema. HumanBodyPiloter5 (talk) 11:45, 23 September 2022 (UTC)[reply]
You also need to remember that mobile exists, and in its current form, the Vector skin is barely usable on mobile. The mobile front-end is even worse, since I do not have access to all the same functions that I would have on desktop. That is what got me to use the Timeless skin instead. Aasim - Herrscher of Wikis ❄️ 14:49, 23 September 2022 (UTC)[reply]
Oppose. There are many aspects that are an improvement but the flaws more than outweigh them. Article content is our principal focus and this skin reduces the space available for it while significantly increasing dead space and wrapping, which leads to a worse user experience with (among other things) increased scrolling and tables that are much harder to parse. wjematherplease leave a message...09:04, 23 September 2022 (UTC)[reply]
Oppose - I really dislike the new skin. It might just be me having an aversion to change, but I find it more awkward to use, less pleasant to read, and as others have mentioned the screen width is a big issue. As a colourblind person, I really appreciate the change to link colours though! I'd love to see that become standard. - ThatSpiderByte🕷️11:12, 23 September 2022 (UTC)[reply]
Oppose – Doesn't work on my browser. If it becomes the default, how will I navigate to preferences to opt-out with no interface? Accessibility concerns should include those of users with older hardware and software, if this is supposed to be the encyclopedia that anyone can read and edit. The for-profit web serves recently developed platforms so that their ads are fed to those who can afford a new computer every year; non-profits shouldn't follow that paradigm. – Reidgreg (talk) 12:43, 23 September 2022 (UTC)[reply]
Hi Reidgreg - thanks for your feedback here. Can you tell me a little bit more about what you're seeing and why you're unable to access preferences? Which browser/device are you using? OVasileva (WMF) (talk) 14:17, 26 September 2022 (UTC)[reply]
Oppose - I just don't like how this looks and never have. It looks like a cheap mobile version, and I don't even like it on mobile - this doesn't feel designed for a desktop at all. ToaNidhiki0513:04, 23 September 2022 (UTC)[reply]
(edit conflict) Oppose Looks terrible compared to Vector 2010, which IMO should remain the default. Just because something has been around for a while doesn't make it inferior. One thing I got from this RfC was learning about reader mode in my browser (Firefox), but I don't see myself using it. Desktop usuers with larger monitors shouldn't be penalized. Miniapolis13:10, 23 September 2022 (UTC)[reply]
Oppose - The left panel is too big and the right one grossly intrusive. The article itself should dominate, not externals. What would pages like List of birds of South America look like with it? Some family lists within it (e.g. hummingbirds and tanagers) already require significant scrolling. This change looks like it would require 50% more scrolling. Craigthebirder (talk) 13:57, 23 September 2022 (UTC)[reply]
Oppose. A fixed-width layout is a regression to how we built websites in the past because we didn't have better tools. On a wide screen, this wastes valuable screen real-estate by preventing me from using my full screen width to view tabular material with long rows (something which I do often). On a narrow screen, this wastes real-estate by wasting both sides on white space which serves no function. -- RoySmith(talk)15:09, 23 September 2022 (UTC)[reply]
Just to clarify, I fully understand that for running text, long lines are difficult to read. And it seems like that's the major point this kind of layout is trying to address. I have no complaint there. My complaint is specifically that for tabular material, folding one logical line into several physical lines is terrible. And for me, the inability to drag a window out as wide as I need it to get tabular material laid out properly is deal killer.
I don't remember where we had this conversation before (somewhere on meta, I would guess), but the idea was kicked around that you should be able to mark up running text vs tabular material. The running text could be rendered with line lengths that were optimum for that, and the tabular material wouldn't be constrained. I remember talking about the CSS overflow property being used to control this, but I'm far from an expert on CSS, so I'll leave it to the experts to figure out how it would be implemented.
I'm also concerned that the "But you can just go back to the old skin" argument is a red herring. If this is rolled out as the default, it will inevitably become the standard. Other skins will stop being supported. As new features get rolled out (to be sure, some new features like the reply tool and thread subscriptions were awesome improvements), they will only be supported on the "standard" skin. So little by little, it will become impossible to work unless you move to the new standard. -- RoySmith(talk)19:09, 23 September 2022 (UTC)[reply]
Here's an example of what I mean. This is an article history display with lines that exceed the width available in this skin. To me, it's virtually illegible. I have to force my eyes to scan down the list in logical "one edit per record" order. Sometimes I have to move down one physical line to get to the next logical record, sometimes I have to scan down two lines. I find that very difficult.
I bought a big monitor to make sure I can always make my windows wide enough to avoid this problem. On tables where even a full width window isn't wide enough, I can drag windows around to make a window which is wider than my physical screen. I slide some of it off the right edge of my desktop, optimizing screen space for the most important information on the left.
The introductory material on this page says, The new skin does not remove any functionality currently available on the Vector skin. That's simply incorrect. It removes my ability to use the full width of my monitor so I can read wide tables. -- RoySmith(talk)11:41, 24 September 2022 (UTC)[reply]
Roy said: My complaint is specifically that for tabular material, folding one logical line into several physical lines is terrible. And for me, the inability to drag a window out as wide as I need it to get tabular material laid out properly is deal killer.
I agree. Unfortunately, this is becoming increasingly common, and not only in web design. I see it in sloppily constructed Excel files that I get from clients.
The emphasis on readability as a justification for changing a default seems to focus on text. The issue of graphics (e.g., captions) and tables (e.g., resizing) seems to be addressed mostly by Oppose votes. It would be good to see Support votes address this -- maybe a lot of those users/editors work primarily with running text? Martindo (talk) 00:41, 25 September 2022 (UTC)[reply]
Wikis are a text-dominant format the world over (despite polled user desire to see more graphics, and despite previous efforts that petered out due to movement of resources at the Foundation). I don't think it's unreasonable to approach the discussion dominantly from that perspective, in any sense whatsoever.
Regarding actual file display ("images"), we have MediaViewer and the community rejected that implementation of being able to see larger images, so I honestly don't think it's relevant to discuss that as a particular point (and users today still have the normal fallback of clicking through to an image description page). As I've said somewhere else on this page, having a fixed width actually makes it easier to deal with questions of placement of images, even in cases where the issues we have today on some pages simply do not disappear by adding the fixed width.
Speaking of MediaViewer, the new implementation of video does something quite similar, and while there was some complaint when that was rolled out, it wasn't the same amount or degree. So I don't think that's a serious concern either.
Regarding tables, I'll probably be leaving a comment later today or earlier tomorrow specifically about tables in my !vote. Izno (talk) 01:02, 25 September 2022 (UTC)[reply]
At present part of your reply reads:
the community rejected that implementation of being able to see larger images
but I noticed that your initial posted version mentioned something like
"WMF redirected resources".
Could you briefly summarize that redirection process and decision-making?
The reason it's relevant to include discussion of graphics is that several Oppose votes are referring to errant display of graphics due to shifting of text to accommodate the forced line width.
I hear you that the currently proposed change in skin is based on majority preference for text which is the vast majority of content. But let's say that's a 60% preference times 80% usage stat. That makes 48%. Then if you include other factors noted by Oppose votes, you're chipping the approval further away from a majority.
Meanwhile the pie graph shows "like" running in third place behind plurality "dislike", followed by "neutral". So, depending on which aspect of the change you're addressing, you're not even starting with 60%.
I don't think anyone is questioning the good will of the developers. The skepticism/dissent/dissatisfaction is rooted in the incompleteness of the proposed change plus the pushiness of making it a default. Martindo (talk) 01:38, 25 September 2022 (UTC)[reply]
Could you briefly summarize that redirection process and decision-making? Not in any detail; it's just a known fact that WMF has stood up a Multimedia team a few times to improve graphs, maps, images, and the like, and then the people have been reorganized into other groups for one reason or another (when the world wants more of it). In any case, this is separate to MediaViewer having been rejected by English Wikipedia (here's some discussions on it).
The reason it's relevant to include discussion of graphics is that several Oppose votes are referring to errant display of graphics due to shifting of text to accommodate the forced line width. Yes, I'm aware. As I have already said, the vast majority of pages are improved in regard to issues like MOS:SANDWICH because of the fixed width, for the average use of thumbnail images.
Your percentages mostly look like bad statistics so much that the general point you might be trying to make is lost.
As for pushiness of making something a default, consider how nobody cares that Vector is the default skin, but back in 2010 when it was released the wiki had a cow about it. WMF didn't ask to make the change. Everything was back to normal within a year; people who thought Monobook was superior set their preferences for that, and the vast majority of users otherwise use Vector these days. Izno (talk) 02:06, 25 September 2022 (UTC)[reply]
OK, I've been running with Gadget-wide-vector-2022 for a couple of days. It has made it possible for me to work, but I can see that there's still a lot that needs to get fixed in the skin before it's ready for prime time. I opened 3 bugs yesterday (T318600• T318633• T318568). Two of them are annoying, the third (T318600) is a show-stopper for me. But beyond that, the fact that I could find 3 bugs worth opening tickets for (plus a couple of other things I mentioned on this page but didn't open tickets for) in a single day indicates to me that this is beta quality. And until the core dev team agrees to own a full-width solution (so we don't need to depend on a community supported add-on), this is still a hard fail for me. -- RoySmith(talk)14:14, 27 September 2022 (UTC)[reply]
What happened with T318600 is a perfect example of why a community supported add-on is not an acceptable solution to the fixed-width issue.
I found a bug in how TOCs interact with fragments in URLs. It turned out this was User:Gary/comments in local time.js interacting badly with the skin's TOC scrolling algorithms. Gary's script inserts additional content via DOM manipulation. This is something lots of scripts do, so I assume similar problems will exist in other user scripts which do similar things.
The bug was summarially closed as "invalid". In other words, "Not our code, so not our problem". If that's the attitude that WMF is going to take, then if we want something to work, we need to make sure it's their code, so when it breaks, it is their problem. -- RoySmith(talk)13:32, 28 September 2022 (UTC)[reply]
Oppose - new vector just looks like a cheap knock-off similar to many of the mirror sites. There are probably minor improvements that should be made while maintaining/improving the brand, but this effort should be scrapped. Star Garnet (talk) 15:42, 23 September 2022 (UTC)[reply]
Oppose. On a widescreen monitor the giant stripes of empty space are almost comical, it looks like missing ad banners that failed to load. But it's actually supposed to look like that. No thanks. Andrew Lenahan - Starblind15:49, 23 September 2022 (UTC)[reply]
Oppose. Before I go into my reasons for opposing, I would like to thank the devs for bringing this to our attention. I still have bitter memories of the way the original Vector was introduced. At the time I still used the old "Classic" skin, and we had little notice about its demise until it was presented as a fait accompli. When I complained about the lack of notice, I was told it had been discussed in full on Gerrit, which the vast majority of users have probably never used.[3] I'm glad that WMF have learned their lesson from that debacle. (As an aside, I still mimic elements from the old classic skin in my personal css/js - e.g. the warmer yellow background colours and the ability to display categories at the top of the page.) With this in mind, I can only oppose, unless the devs/WMF can guarantee that support for all other skins will continue indefinitely for those who choose not to use this skin. SO far support for other skins does not seem to be mentioned anywhere. — Voice of Clam15:58, 23 September 2022 (UTC)[reply]
@SGrabarczuk (WMF): Thanks for clarifying this, and stating that support for other skins will continue. I have therefore withdrawn my oppose. Incidentally I meant indefinite in the same way as an indefinite block - not necessarily forever, but with no specific time limit in mind. — Voice of Clam10:34, 30 September 2022 (UTC)[reply]
Hi @Voice of Clam. Thank you for describing your concern. It's also nice of you to see some progress in the way we work with/inform the communities! Indeed, things have evolved.
Our approach to skins is only to make the new default, and let others live with their non-default choices.
We will support Vector legacy long years from now. Currently, we support Modern, CologneBlue, and Monobook, and Timeless. (Even though the first two aren't in preferences - we only don't encourage more people to select these options.) We hide skins on the preferences page due to drastically low usage, and don't plan on skipping, so Monobook would have to go before Vector legacy. Neither of these is going anywhere. If I recall correctly, we have only removed skins once, in 2013. These were used by 0.53% of active users and 0.31% of inactive users. This is incomparable to the usage of Monobook.
Anyway, there's no policy regarding the removal of skins. We're open to define the criteria but that would require a separate discussion.
What's more, working on Vector 2022, we did clean-up which otherwise wouldn't be possible. We centralized the legacy skins' code, standardized markup, made it easier to roll out new changes to old skins, removed never used options, and removed 75% of the PHP code of these skins - all without any changes to their usability. This makes the maintenance easier, and potentially even longer if needed. Let me make this super clear: apart from building Vector 2022, we in fact improved Monobook! (To me, registered in early 2010, this sounds mind-blowing.)
We will not guarantee that we will continue this support indefinitely, though. I'd be happy if you considered redefining your expectations about us all in the distant future :) I don't even know how to define indefinitely without the risk of being unreliable. Code depends on external factors that are beyond our influence.
(Thanks to Jon (WMF) for helping with this answer.)
Except the current Vector kind of is. Vector 2010 is barely usable on mobile, whereas the current solution with Mobile Front End is even worse since not all features available on desktop are available on mobile. Nevermind some of these features may break with the low RAM mobile devices have, but unifying the experience between mobile and desktop is an important step. The redesigned Vector 2022 is less broke, or two steps forward, one step back. It still is not responsive redesign, but it is a significant step towards getting there. On the other hand, I agree that it feels like there is a lot of wasted space in the margins, even more so than Timeless. Aasim - Herrscher of Wikis ❄️ 20:02, 23 September 2022 (UTC)[reply]
Oppose. In Firefox, for example, there are several issues: the left panel is blown out compared to slick current one, the contents are shown lower so one has to scroll down to navigate, tools like sandbox and preferences are hidden in the user menu (requiring extra click) instead of handy display at the top right. To sum up: no clear advantage, instead produces accessibility issues among accustomed editors. As such, should not be forced as default but remain in user preferences for those who want it. Brandmeistertalk17:18, 23 September 2022 (UTC)[reply]
Oppose until the fixed-width, white-space problem is fixed. Everything else looks great, and I like many of the changes, but I find this makes readability worse for me. If we want to allow a preference to allow users to shrink their usable space by choice, as an opt-in, that's fine. And literally every other change looks great. But this is a deal breaker for me. --Jayron3217:20, 23 September 2022 (UTC)[reply]
Like what they have with Fandom Desktop? Yeah, I think this is one area of improvement. Being able to expand the text past the margin is something I use on Fandom to reduce scrolling. Aasim - Herrscher of Wikis ❄️ 16:32, 24 September 2022 (UTC)[reply]
Oppose The WMF editors have cited Myth #28: White space is wasted space, apparently thinking that a solid block of white on one side of every single article somehow "reduce[s] the amount of text visitors see all at once", " guide[s] your eye from one point to another ... by the designer's intent", "creating the feeling of sophistication and elegance" "essential for a balanced, harmonious layout". I might quote sections of WP:SYNTH at this, were I chastising an errant content creator. ~~ AirshipJungleman29 (talk) 17:29, 23 September 2022 (UTC)[reply]
Oppose When last I looked into this issue there was no way for an unregistered user to opt out of the fixed width format. If there were such an opt out, I might be willing to change my opinion. 68.189.242.116 (talk) 17:51, 23 September 2022 (UTC)[reply]
Oppose. I'll begin by saying that I spent some significant time reading all the pro and con arguments here, and experimenting with implementing 2022 for myself and looking at a variety of pages. I'll also say that I appreciate the fact that the developers are making a sincere effort to engage with the wishes of the community. But. Like others here, the new version looks to me like it's using white space as a placeholder for advertisements. I don't like how the page title moves down the page as one scrolls down: readers already know perfectly well which article they have chosen to read, and it covers too much of the text that readers have actually come to. I've seen some Featured Articles where editors put a lot of effort into page layout in terms of where images are, and the new skin actually destroys that. (See, for example, the rose images at Sissinghurst Castle Garden.) I don't buy the arguments that the changes make it less cluttered; I actually had more difficulty finding things that I wanted to find, and all that white space doesn't help. It also felt like it was harder for me to read the text, with all the white space around it, like it was harder to keep my eyes on the text. I know that there is survey data, but I don't care if my own eyes tell me something different. Much better to leave the default as is, and treat this as something to opt into, until more issues are addressed. I don't like the idea of going ahead and making this a default to opt out of, while promising that things will get fixed as it goes along – fix it first, when there are issues that are clearly non-trivial. And, sad to say, WMF has had a history of not working closely enough with the experienced members of the community, and that justifies the community taking a strict approach to agreeing to implementation, rather than just trusting a higher authority. --Tryptofish (talk) 18:19, 23 September 2022 (UTC)[reply]
Hey @Tryptofish, thanks for participating in this discussion. One clarification: the sticky header is only visible for logged-in people, and was added based on community feedback (link). We will soon be decreasing the height of it, so it will cover less of the article (link). AHollender (WMF) (talk) 18:42, 23 September 2022 (UTC)[reply]
Oppose Fixed width is unacceptable for all of the reasons outlined above. If you deploy this, it will be huge negative press for the WMF and the project, this is a clear loss of functionality and accessibility. The less wikipedia looks like every other unusable website on the internet, the better. Or are we going to have pop-up windows telling us to sign up for an email list and large bars taking up the bottom one-third of our screen next? This is an encyclopedia, not the Daily Mail or Reddit. - car chasm (talk) 18:26, 23 September 2022 (UTC)[reply]
I haven’t made a final decision on how I’m going to vote yet, but I do want to say that I’m not totally sold that this’ll lead to bad press. It might actually lead to good press — it’s not that hard to find articles about WP’s design being outdated/bad. (Of course, it’s not like those websites are designed any better…) —pythoncoder (talk | contribs) 18:28, 25 September 2022 (UTC)[reply]
Oppose I do find text-heavy articles in the 2022 version easier to read because of the reduced width, and having a fixed maximum width means that editors can lay out articles such that the viewing experience will be consistant across all desktop users, as opposed to now where something that looks good in one width might not in another. However, I've found that the fixed width is terrible on project and talk pages. Once you start taking away even more width with progressive indents in discussions, it gets very schrunced. I would support if fixed width were only deployed to the mainspace, but I oppose deploying fixed width anywhere else. The Squirrel Conspiracy (talk) 19:30, 23 September 2022 (UTC)[reply]
Oppose per width and link color concerns raised by multiple editors above, as well as the survey data highlighted by BilledMammal. The language changing element is attrocious. Overall, it is not clear to me in the least that this is an actual measurable improvement over, say, Timeless. Ljleppan (talk) 19:50, 23 September 2022 (UTC)[reply]
Oppose – same reason as User:Pppery: if it ain't broke, don't "fix" it. Put another way: don't force users to adopt a skin, etc. just because you think it's better – leave the choice to change up to users. Adovcate for it, don't impose it. --IJBall (contribs • talk) 19:51, 23 September 2022 (UTC)[reply]
Oppose You lost me with the new "User menu" which adds another level. This requires an extra click when I want to do something I often access – contributions. And it has an entry for uploaded media which takes me out of this project and into another (Commons). This seems oblivious to the fact that media can and is uploaded here and fair use media has to be uploaded here. So, this menu is designed for someone else's workflow, not mine. Another point is that I often mentor/assist/train new users and so it's complex and confusing if there are divergent interface choices. I still resent the media viewer interface which is so awful that I have to suppress it in my preferences but then have to help others for whom it is the default. Andrew🐉(talk) 20:22, 23 September 2022 (UTC)[reply]
Reluctantly Oppose until the skin update is decoupled from the width constraint. Fundamental page layout decisions (such as max width), which are currently made by a community of thousands of talented layout editors, should not be made at the skin level, though a skin feature can result from such decisions. If we do decide we want a default skin that breaks long-standing expectations of layout-designers, the process of skin-updating and -redesign needs to be made accessible to a larger community of skin editors. If we are updating our collective sense of how to support which sorts of readers, that should be its own focused project (and not conceived of or implemented as a simple skin update :) Further discussion below. – SJ +21:26, 23 September 2022 (UTC)[reply]
@Beccaynr: puts things excellently below. Please note that page width and margin whitespace are not the same as column width; many content-rich sites address this by finding ways to present and reflow multiple columns. We may be the longest-form website that has this challenge, and it is a worthy one (IHT used to do this in an interesting way, lost when their web team was subsumed into NYT). The current design however says both "Limiting column width is Important and we should break existing assumptions by fiat to fix it" and "You only get one column. Anything else is out of scope for a simple skin update." – SJ +21:40, 23 September 2022 (UTC)[reply]
Oppose. The excessive width constraints and massive white space is nothing but a downgrade. Furthermore, I strongly oppose the use of "sticky" content on any webpage, and I oppose sticky headers in particular. The new skin is not without benefits, but these two issues are both dealbreakers. Thebiguglyalien (talk) 23:00, 23 September 2022 (UTC)[reply]
Interesting. I kind of like the idea of the sticky headers. I spend a stupid amount of time on my phone scrooooooolllllling to the top of a big page to find the header links. -- RoySmith(talk)23:24, 23 September 2022 (UTC)[reply]
Since they've made the TOC sticky, they could make it easy to jump to the top by adding a jump-to-top link there, without needing sticky headers. - Nikki (talk) 00:47, 30 September 2022 (UTC)[reply]
Hey @Nikki the first link in the table of contents, (Top), is a jump-to-top link. In our conversations with community some folks wanted their tools right there, without having to first click a link and scroll to the top. Does that clarify things? AHollender (WMF) (talk) 03:29, 30 September 2022 (UTC)[reply]
Oppose Everyone knows the saying "If it ain't broke, don't fix it" and seriously can't see anything wrong with the old skin. As for the new one, sure having the sticky table of contents is good (except for that added scroll bar when the table is too long) as makes it easier for navigating through the article, but overall the sidebar appears to take too much from the article space and this makes the article appear squished. The other thing I don't like it how the languages are displayed. It's much better to have them displayed on the side with the suggested languages appearing first rather than having all languages hidden away in this menu. Alin2808 (talk) 23:38, 23 September 2022 (UTC)[reply]
Definitely Oppose The design itself is completely unappealing, the current design, Vector (2010) is fine as is and the dead space is annoying. On top of that, I have questions including how is it going to look visually like on United States network television schedules, and if it’s gonna be forced on everyone logged in or not? Nostalgia Zone (talk) 00:04, 24 September 2022 (UTC)[reply]
Hi @Nostalgia Zone - just to clarify, the skin will not be forced on logged-in users. You can switch to any other skin (including the current Vector, Monobook, etc) in preferences or via the link in the main menu. OVasileva (WMF) (talk) 10:55, 28 September 2022 (UTC)[reply]
Oppose with appreciation for the work put into this. Unfortunately, it's not an improvement overall per many of the comments above. I don't find the new format convenient or intuitive. The ToC is particularly inconvenient to the point of being rather annoying. -Ad Orientem (talk) 00:51, 24 September 2022 (UTC)[reply]
I will also add the advantages the current default interface has both in terms of familiarity and accessibility. Its age and simplicity means it is accessible without issue even on older machines running unsupported operating systems & browsers and on poor internet connections. I don't know how Vector 2022 compares to this. thorpewilliam (talk) 03:54, 24 September 2022 (UTC)[reply]
If that's a definite change, then I oppose. In the meantime, maybe someone can explain to me why the SECOND most popular skin has been deemed best, as if it's a democratic decision (reminds me of some recent US elections). Martindo (talk) 03:54, 24 September 2022 (UTC)[reply]
Oppose I appreciate the effort put forth by the WMF web team, but I'm not a fan of the new design. The excessive whitespace and shortened line widths are particularly deal-breakers for me, perhaps I would reconsider if the design is made more compact by default. InfiniteNexus (talk) 04:42, 24 September 2022 (UTC)[reply]
@InfiniteNexus thanks for your reply. I'm trying to connect with some editors to better understand their perspective on this. I have a hunch that on a deeper level (beyond typography preferences, etc.) we all share some common goals. So, this is kind of an experimental but, if you're willing to engage...From the data we see people searching more, and using the table of contents more to explore articles more deeply. We don't see any decline in any datapoints. Ultimately this means more readers will be exploring and reading more Wikipedia content with Vector 2022. If we zoom out and look a the big picture, is that not the overarching goal here? To share knowledge with the world and have them come engaged with it? Plus you can always use original Vector, or even use a gadget to make the text full width : ) AHollender (WMF) (talk) 18:20, 28 September 2022 (UTC)[reply]
@AHollender (WMF): Here's the problem: I, like many editors, use Vector classic as a guide when formatting and positioning things on articles, in order to ensure everything is presented properly in an aesthetically pleasing way to most readers. Changing the default skin breaks all of that. Infoboxes that had been carefully designed to end right before the TOC does will clash with the text below the lead. Tables set to a certain width to ensure it doesn't take up too much of the screen will now take up most of the usable space. Text that had been split into reasonably-sized paragraphs to improve readability will now end up with super long paragraphs, thereby forcing us to re-split the paragraphs. So on and so forth, you get the idea. Again, I really do appreciate the effort your team has put forth, but it's a no for me unless the long-established pagewidth is retained, as a default option. InfiniteNexus (talk) 03:33, 29 September 2022 (UTC)[reply]
Oppose for the same reason as HumanBodyPiloter5. I do not approve of the hamburger menu in the context of desktop use, nor the obtusely labeled and unclear icons being chosen in favor of words. I also take issue with the amount of white space on the screen, and the concerns raised by others about the change potentially ruining the placement of images on pages arranged with Vector 2010 in mind. These are exceptionally poor choices for a desktop website; I do not like these "mobile first" kinds of design choices on reddit, I do not like it on Twitter, and I do not like it here. If you must, deploy Vector 2022 on mobile ONLY, but do not push it onto desktop users. ostensibly singular userpage (inquire within) 04:44, 24 September 2022 (UTC)[reply]
Oppose, I switched to the skin to try it and was met with massive whitespace to either side of the articles I tested it on; what is the point of that? Also the user menu at the top right, is replaced by icons that aren't clear what they are and some options hidden behind a two stage menu. I had a quick play with the new skin on mobile (where I always use desktop view as the mobile version is horrendous and has less functionality) and it is more usable there, though I don't know any way for a user to set two different skins depending on which device they are using. If it is possible to set Vector 2010 as the default for desktop and Vector 2022 for mobile I could possibly support that but a change to Vector 2022 for all just seems to penalise desktop users - Dumelow (talk) 07:35, 24 September 2022 (UTC)[reply]
Oppose My initial reaction was to dislike the narrow content area and large amounts of whitespace, but really liking the TOC in the sidebar. My assumption was that the narrow content area was going to work best at narrow screen widths, so I decided to try playing with window widths to see if that was the case, and came to conclusion that it is bad at all widths on desktop.
On a 1920x1080 screen, there are two levels of whitespace padding around the content, the inner layer (which is still treated as part of the actual site, including the TOC and user buttons) and an outer layer (which is pure padding, to enforce a particular screen width). In many of the responses, various other sites which use fixed-max-width layouts have been cited, but from my review of those sites, most of them do not use different colours for the outer layer of padding. From my perspective, showing this additional colour gives the impression that my monitor is unsupported by Wikipedia, so I'm being given the highest supported resolution, with the excess space left as whitespace. If the inner and outer padding both used the same colour, I think this would be less jarring.
Using half of a 1920x1080 screen, the TOC is conveniently collapsed, but now the useful sticky headers (the article title, search button, user links) all require scrolling back to the top of the page again. I'm not sure why all of those helpful features are removed when on a narrower screen.
Stretching the screen gradually, at about 1000px the TOC returns. However, it also brings with it a horizontal scrollbar, but the only thing it is scrolling is whitespace to the right of the page's content area. (This is presumably just a bug, but is immediately irritating when playing around with splitscreen.) This width also emphasizes just how much whitespace the TOC is adding: At least at larger widths, the TOC having a big gap between its right side and the article body can be hand-waved as filling space around the fixed-width content area. But at the absolute minimum width I can use and still have a TOC, there's about 40px of space between the TOC's scrollbar and the article body (and normally there won't be a scrollbar on the TOC, so the space is usually going to be even larger than that). And that's not even discussing that the TOC isn't using the full vertical space available to it either.
Between about 1350px and 1600px, increasing the window width only increases the whitespace on the right side of the page until it is about the same as the width of the left sidebar. What this means is that around 1550px, you get a big left sidebar and big right-hand whitespace, but the two are uneven—it looks like the page is trying to balance the left and right whitespace, but is failing to. The first screen I opened the new layout on was within this range, and the assymmetry is really distracting. Up until the 1350px point, there's a small amount of whitespace padding on the right side, but it just feels like a natural page margin. Within this 1350-1600px range is IMO the worst experience of any screen width.
Additionally, I find the menu buttons really unintiutive: The ☰ button opens the old sidebar, which pushes the TOC so far down the page it's entirely off the screen, making it seem like it has entirely replaced the TOC. Then the button to close the menu is «, implying the menu should close to the left when it actually closes upwards (although there is no animation for opening or closing it at all, not that there needs to be). The button also vanishes when you start scrolling down the page, reducing its benefit as a navigation tool (not that the current skin does this much better though, where the sidebar is just whitespace anywhere past the start of an article). Also, the "hide" button just makes the TOC disappear entirely—I would expect the re-expand button to be located in the same place as the "hide" button. Unless you happen to spot the new TOC appear next to the article title, it's very easy to press this button and not know how to restore it. And because this new skin is relying so heavily on symbolic representations over words, even if you do spot the button, it's not at all obvious that it corresponds to where the TOC has gone.
Honestly, the entire menu is somewhat of a relic of the old layout. However, at least when it's there persistently there, it feels like it's just part of the site layout and so contains mostly global navigation buttons. When it's buried under a collapsible menu, and opening it displaces page content rather than loading over it, it feels like it should be specific to the current page, but the majority of the links are still just sitewide links (although there are still a few page-specific ones mixed in there, such as WhatLinksHere and the print/export buttons). I believe I saw elsewhere on this page that there are ongoing discussions about changing the content of that menu, but at least in the current form of the menu, it's problems are only emphasizes when hidden under an expandable menu.
Overall, I really want to like this new design. It's trying to make better use of the sidebar, and stickying useful features like the search button and TOC. It seems to be trying to mimic many other websites by narrowing the content area, but unlike those sites it has nothing to put in the new space it has created on the left and right sides of the page (other sites typically use this for ads or promoting other pages on the site), making Wikipedia pages feel really squashed and full of wasted space, rather than having healthy margins that provide breathing room. --SnorlaxMonster10:25, 24 September 2022 (UTC)[reply]
Oppose for now. I like how sleek the new interface looks and the back to top button is a really good addition, but there are a few dealbreakers that mean I wouldn't want this to become the default at the moment. I find the narrowness of the page, and especially the editing box, really annoying - having to scroll even more when editing is super time-consuming and just means I won't want to edit so much when I don't have a mouse with me. The other one, which is even more of a dealbreaker than the first, is a few quirks of the new TOC style; although I really like how it follows you down the page, not having it available when you're reading the lead paragraph is frustrating when you're trying to quickly navigate through the page. The other issue is that subsections are pre-collapsed on the TOC sidebar and effectively invisible, which I'm really not a fan of. I won't have a problem supporting this if/when it comes back in the future and takes the things in this discussion onboard. Gazamp (talk) 13:30, 24 September 2022 (UTC)[reply]
Oppose. I strongly dislike the over-reliance on abstract symbols over words for various basic functions. That's particularly unfriendly for new and unregistered users. Nsk92 (talk) 14:14, 24 September 2022 (UTC)[reply]
Oppose. Not yet. Too much work left to be done, not customizable enough out-of-the-box, reduces branding (if, for example, a screenshot of an article is shown on TV it's much harder to recognize it's from Wikipedia) and having my contributions and talk page links hidden in a sub-menu greatly annoys me (phab:T302641), actually it bugged me enough to switch back to Vector classic. — Alexis Jazz (talk or ping me) 16:15, 24 September 2022 (UTC)[reply]
Over my dead body. Even on the example page, there was one major glaring usability issue. Namely, that if (god forbid) my mouse cursor happens to be on the left side of the screen, then scrolling the article with my mouse wheel will stop working once the sticky TOC moves into that spot, because it will want to scroll the TOC instead of the article. Beyond that, not having clearly marked tabs at the top of the article is confusing, especially from an editing standpoint. Not having a clear shading difference between article and non-article is also mystyfingly poor design. Keeping the search bar persistent at the top is also horrible. The amount of time I need to search is very small compared to the time I spend reading an article. When I do want to, I can just press one damn key on my keyboard (which I'd have to switch to anyway to actually execute a search) to get the article back to the top. As is, it just takes up valuable screen real estate which is already cramped by tabs, an address bar, a task bar, etc etc. This is especially important for those of us on small displays. All in all, these changes are almost all negatives. And worst of all, if this goes forward, I'll be stuck with them, with as far as I can tell, no ability to change them without the hassle of making an account and figuring out how to change stuff (what can be changed at least). I might soften my stance a bit if there was some way to revert to the current skin and have that choice be remembered in a cookie. 35.139.154.158 (talk) 17:24, 24 September 2022 (UTC)[reply]
Just wanted to reply to the last part: you can change the skin by going to Preferences -> Appearance and there you can select the skin. Though you need an account for that. Alin2808 (talk) 17:57, 24 September 2022 (UTC)[reply]
We're living in a world where people are overwhelmed by a simple GDPR notice/checklist. I personally can't be bothered to log in on every device where I use Wikipedia. It's a waste of time and mental effort when I'm not going to be doing any editing, and a possible security risk on public Wi-Fi. We can't pretend the settings are accessible to everyone when the user would have to go through all the steps of creating an account and logging in to use them. That would be a dark pattern. DaßWölf18:28, 24 September 2022 (UTC)[reply]
Oppose: While I do like the sticky bar at the top, that's about it. Complaints: (1) The purple color for Wikilinks once they've been clicked is much too light and, thus, difficult to see. (2) The Table of Contents sidebar, which not a bad idea in itself, is taking up too much space; moreover, because it too is white, it just bleeds into the article space; at a minimum, a vertical line is needed, and I wouldn't say no to the lightest of grays as a background color. (3) I like the idea of a fixed width, because I think content should look the same across all users; however, this design opts for too narrow of a width, thereby creating far too much unused white space on the right. ~ Silence of Järvenpää22:37, 24 September 2022 (UTC)[reply]
Strong Oppose: I've seen Reidgreg and another user mention that it doesn't work on their browser. The new Table of Contents does not correctly collapse on Goanna browsers like Pale Moon, Basilisk, and Serpent. The collapsible Table of Contents "Brown Bear" demo will actually hide and corrupt the article text on any version of Internet Explorer. The last version of Firefox to support SSE was 45 and it simply does not display the ToC. ArcticFox for older Macs also does not display the ToC. Mypal for Windows XP does not display it. Webpages can be built as documents; the web started as a way to connect hypertext documents. The new ToC is cool, on a new computer, but it converts a simple list structure into an application which ensures that users on older systems will not be able to access Wikipedia, or be able access it as fully.Rjjiii (talk) 00:09, 25 September 2022 (UTC)[reply]
MediaWiki has a support matrix for minimum compability, below which it is simply infeasible to test and support the long tail of users who decide to use an uncommon or old browser. The vast majority of those browsers listed are probably not above the minimum thresholds, where thresholds are defined.... (I recognize several of those browsers as being rare in use. :)
If you think any of the browsers that you tried should be within the realm of browsers lying somewhere between A and C, you're welcome to request a change and they may work on the problem as it may indicate a problem in the same version of their upstream rendering systems. (If you're smart enough to try ad hoc arbitrary browsers, I assume you can hunt down the bug in a major browser, which I assume would guess would increase the likelihood of WMF working on that issue.)
If you can reach the website in XP, I would be both surprised and dismayed. Surprised because the ciphers WMF supports in HTTPS do not generally support XP, and dismayed because you're using an ancient insecure OS that has been out of support nearly a decade. Izno (talk) 01:47, 25 September 2022 (UTC)[reply]
Exclusion of long-tail is an example of what I called "chipping away at the majority" in my comment on Oppose 54. It should be done sparingly, otherwise it's just a convenient excuse for reducing the denominator of the population being surveyed, thereby increasing the % represented by the numerator of potential supporters. Martindo (talk) 02:31, 25 September 2022 (UTC)[reply]
I should clarify: in posting about Oppose 54, I suggested that assuming a majority prefer the new text constraints, there are other factors that some of those Support votes might be unhappy with. If the other factors are deemed less significant (or even long-tail), then the actual majority supporting the overall skin would be chipped away.
I am not personally attempting to chip away at some majority, simply explaining the expectations associated with development of this particular top 15 website. Izno (talk) 04:02, 25 September 2022 (UTC)[reply]
Page History software is superb in presenting a comparison of changes. If I upload an edit and get a message about "not current version" because another editor has (almost) simultaneously uploaded a different edit, does that mean the content I'm trying to upload is actually the full page (including graphics, which can eat up bandwidth)?
If so, then design that claims to be "worldwide" or "universal" in usability really needs to look at reliable internet speed stats in less technologically developed countries -- upload speed as well as download.
WMF performance work is an ongoing activity that does assess low-speed delivery, but I do not know how routine or systematic the specific activity is of looking at low speed delivery. I do not know what G they test to regularly these days; most recently I can remember 3G tests but I have seen older discussion about 2G tests. This has in fact motivated multiple parts of the mobile and desktop websites. On mobile, I believe the way it works is that we deliver collapsed sections which then load the content on demand. On both, most JavaScript is delivered at the bottom of the page, which motivates quicker loading of the main content. More recently, browser support has motivated lazy loading of images as well. Izno (talk) 04:13, 25 September 2022 (UTC)[reply]
That's nice? ... the ciphers WMF supports in HTTPS do not generally support XP ... remains a true statement. I can tell you why if you want to know -- they are not secure and supporting them makes all readers less secure. Saying "lots of people in this one place on a map" (and believe me, I've said similar about IE particularly -- how its use displays seasonality correlating to the northern hemisphere school year) doesn't really mean much in this discussion about a long-settled part of development of MediaWiki. Izno (talk) 04:00, 25 September 2022 (UTC)[reply]
Rjjiii's comment suggests that it is still possible to connect via XP, despite HTTPS issues. @SGrabarczuk (WMF) and OVasileva (WMF): - do you track broad user statistics, such as what browser and OS readers are accessing the site through? If you do, can you provide those figures? BilledMammal (talk) 13:35, 25 September 2022 (UTC)[reply]
Let me clarify my post a bit. First, yes it's possible to access Wikipedia with a variety of older systems right now. I view this as a strength of the platform. Second, my issue is not a personal concern. I have access to the latest versions of both Chromium and Firefox on current versions of Windows and Debian. My main concern is for people that have not decided to stick with old computers, but are stuck with old computers. And to a lesser extent accelerating the obsolescence of existing machines and shifting the web further towards a blink-first design. If this does become the default theme, I may create bug reports. However, this issue goes deeper than testing for a specific browser in the long tail. I agree that past a certain point it becomes "infeasible to test" for every browser. This is the reason I am opposed to the more interactive ToC. It is not necessary to test the ToC that the current theme uses because it relies long-established standards.Rjjiii (talk) 03:53, 25 September 2022 (UTC)[reply]
my issue is not a personal concern As you might be able to tell, I didn't think it was. Which definitely makes it a "I'm going to try to represent some unknown and faceless group". Which is fine, thanks for bringing up the issues, but I don't think it should motivate a strong oppose.
My main concern is for people that have not decided to stick with old computers, but are stuck with old computers. At the end of the day, the world moves on. Many of the evergreen browsers are able to run even on quite some old machines (my current PC is going on 9 years old -- it was made around the time that Firefox 26 was releasing), and I'm planning soon to resurrect one from 2008 with a copy of Linux and a new hard drive (as soon as I get off my butt to do something that I should have learned a long time ago ;). I find it hard to believe in this day and age that "I'm stuck on an old machine and can't do anything to upgrade" should motivate a strong oppose either. Especially for a non-critical item in the UI -- sure, it is useful to get around the page, but it's not the content at the end of the day.
One of the ways the WMF can handle this situation, should the WMF decide it is indeed not feasible to support a particular browser/version, is to cut off JavaScript delivery. I have not personally tested that end state, so that might make for some questions also in those browsers. Even grade C is not "pixel-perfect" display, it's "can I use the website", and while a TOC is useful, I do not think it is a required element of display. (Mind you, I would much prefer it to fail gracefully in the absence of JavaScript.) Izno (talk) 04:36, 25 September 2022 (UTC)[reply]
This page that you linked ( https://www.mediawiki.org/wiki/Compatibility#Browsers ) seems to indicates that WP is tested for IE 11. Is Vector 2022 meant to work on IE 11? Many of the links (View Source, Talk, History, etc) don't work on IE 11. This is also true for FF 39+ but I believe you (and the linked page) are saying that only the article is expected to display. Rjjiii (talk) 01:46, 28 September 2022 (UTC)[reply]
As you can see at mw:Compatibility#Special treatment for IE11, that browser is no longer a main consideration for design, but the rationale is intended to be for JavaScript reasons, which I don't think are causing the issue here, which I can reproduce in the Edge emulator for IE11. I can workaround the issue by tabbing to those links. Taking a look under the hood, I'd guess the issue is that the skin has set the container .mw-article-toolbar-container to display: flow-root, which is not supported by any grade C browsers. I don't know if the issue described impacts them all. That's probably worth a WP:Bug report, @SGrabarczuk (WMF)?
The table of contents being absent is almost definitely caused by IE11 being incompatible with the JavaScript used here, but also something to draw WMF attention to just in case I guess.
but I believe you (and the linked page) are saying that only the article is expected to display. Yes, that's basically what the "Basic (Grade C)" section says at the very end. Izno (talk) 03:08, 28 September 2022 (UTC)[reply]
Thanks for the explanation. I see the same behavior now when tabbing. After tabbing through the links, I also found that the area just above the links can be clicked to open the pages.
I don't believe that JavaScript makes the ToC display or not. I'm not sure how to test it in IE, but in Firefox 45 if I set "javascript.enabled" to false, test that with a simple JavaScript demo, and then reload the page: the ToC is still unavailable. FF 45 also triggers the same link behavior where the location of some links is a narrow, non-visible line just above the link text's location regardless of JavaScript availability.
A followup on legacy browsers: whatever the WMF has changed recently fixed the broken links on older browsers issue when I tested FF 45, IE, and KM 76. I looked into the ToC being invisible on older browsers some more. This was a conscious design decision. The CSS makes heavy use of the CSS grid layout. The ToC and some other elements are disabled intentionally. Here is the CSS for ToC, currently starting on line 2853:
.mw-table-of-contents-container {
display:none
}
@supports (display:grid) {
.mw-table-of-contents-container {
display:block
}
}
MDN lists the minimum browser versions for display:grid
Oppose: This wouldn't be the first time a first website introduced a redesign which added a bunch of whitespace for no good reason, and it's just as annoying now as it was all the other times I've seen it happen. The fact that Vector 2022 isn't even beating Monobook in terms of usage really doesn't inspire confidence. I like the idea of the TOC in the sidebar, but I would never trade away the links to other languages for that. There was another comment in this RFC which mentioned something to the effect that Vector 2022 feels like a Wikipedia-rip-off, and it really does feel like that. The nice new white space feels like the perfect place to sneak in some ads. Heck, they might already be there for all I know, and they're just not visible because of my ad-blocker. Telaneo (User talk page) 02:52, 25 September 2022 (UTC)[reply]
Strong Oppose: The default fixed-width; the way large/wide images, charts and tables break because of it; the way even small images result in the text swerving through them in an unreadable manner (including in the linked Pluto article, a FA); the use of icons instead of clear text; the ridiculous amount of whitespace (why is there a big blank under the Wikipedia logo?); the weird spacing of the topicon/title/heading elements; the way the actual content is confined to a small amount of screenspace, bringing to mind every other cheap and ad-infested mobile-esque website... and no, "install a gadget" isn't a solution when we're discussing a 'default' skin and the vast majority of casual users won't be doing that. I'm also alarmed at the way this RFC was originally worded as "deploy now or later" and the near-badgering response to some of these oppose votes, but that's not related to my concerns about the skin itself. Blue Edits (talk) 12:18, 25 September 2022 (UTC)[reply]
Oppose: My laptop is 1280px wide and the page looks out of ratio especially near the lead; the left sidebar is too wide, making the lead text between it and the infobox feel narrower than normal. Also, I have not been a fan of not very accessible websites using icons in place of text in the main menu; I would prefer the texts "Talk", "History", and "Watchlist" displayed on the top menu navigation bar. I also tried clicking the "Pluto" text in the header thinking it was the search bar (since the search icon was beside it; the line divider to the search icon's right appears like a search input field, making "Pluto" appear like a search placeholder). The left sidebar table of contents should have section numbers in it to distinguish if a section name is wrapped or not; I do not know if a wide section name affects the width of the left sidebar or if nowrap is used. –Sanglahi86 (talk) 13:37, 25 September 2022 (UTC)[reply]
Oppose: Absolutely not. I'm not sure what the rush is to a new skin; if it ain't broke, don't fix it. So many websites nowadays are in such a frenzy to do this, essentially screwing over the user in the process. Totally unnecessary Terrible sizing and proportionality throughout. I hope this skin never gets approved. Oppose with all my heart. That Coptic Guy14:30, 25 September 2022 (UTC)[reply]
Strong Oppose: The redesign looks so bad that when I switched, I assumed I'd done something wrong. It seems like a clear step backwards, especially the fixed width. Keep this in the lab until it can be improved. GoPats (talk) 14:58, 25 September 2022 (UTC)[reply]
Oppose: A) White space is a waste of space. You already know that the white space can be used for lots of items (links to other items around Wikipedia for instance) instead of hidden. It's redundant to leave parts of a page unused. B) Putting the navigation bar in a dropdown menu is also redudant. The amount of space the navigation bar take on the page is minimal. No need to hide it. C) Depending on what you have your screen set to, it can look wonky. It should look the same on each. D) Where the content is, it look a mobile browser version. If I wanted a mobile browser version, I would just use my phone. E) Picture heavy articles can make text even more squished. Also, articles in a lot of different categories and with a lot of references, make those sections even longer. Even if you adjust the reference list to different sizes, it might not help. Final: Reverting to Monobook would be better than Vector 2022. Instead of various tweaks and updates to legeacy Vector to freshen it up, you made a completely different one that is terrible. That is why I will never use Vector 2022. Mr. C.C.Hey yo!I didn't do it!17:14, 25 September 2022 (UTC)[reply]
Oppose. I go to the French WP a bunch to find material to translate, and I can't stand the way it looks over there. (I wouldn't put too much stock in that 87% statistic. I don't go to the ancillary pages over there, just the articles, so I didn't realize it was something you could turn off. I just thought the community over there had very different aesthetic tastes and that's what they wanted. I just went and turned it off now that I know you can.) When checking related articles to see if they have English counterparts, it is so much more convenient to do that at Italian WP, which has a very similar layout to ours where the other languages are on the side instead of having to use a drop-down, and having to scroll down a list if it's not listed in the first 5 of 6. Egsan Bacon (talk) 21:29, 25 September 2022 (UTC)[reply]
Oppose I prefer the current skin. I've read through the pros and cons above and I'm not convinced that the 2022 skin is overall any improvement. Leaving this aside, from an aesthetic POV, the 2022 one looks almost cartoonish. I also find it more difficult to use in general to find what I need. I understand that some things are better, but overall definitely don't support replacing the current one. As others have said, if it ain't broke don't touch. Takerlamar (talk) 00:22, 26 September 2022 (UTC)[reply]
Oppose I published several workarounds to let anonymous users use the old Vector and they just kept breaking them and removing what I posted on Mediawiki. Vectorman007 (talk) 00:27, 26 September 2022 (UTC)[reply]
Oppose I'm still using the Vector 2022 skin and I don't think it's that bad (I appreciate having the search bar close and having the suggestions show the short description as well) but I agree with those that the limited page width (and excess white space) is not good. Vector 2022 looks ok on my Surface Pro 7 but it does not on a 1920 x 1080 screen. I've been using Vector 2022 with a toggle option to extend the width -Gouleg🛋️ harass/hound13:22, 26 September 2022 (UTC)[reply]
It's not broke, so don't fix it. PS - Why are editors putting 'Support, Oppose, Neutral' in their posts? You're already under the sub-sections of those positions. GoodDay (talk) 13:52, 26 September 2022 (UTC)[reply]
Oppose although I personally use the 2022 vector skin, I feel that the 2010 skin is still better than this one as the 2022 one still needs a few improvements, for starters the width limit, and I don’t think we have received any complaints about the 2010 one. The change would receive significant backlash but even if we don’t consider that, the 2022 one still has a bit of work to be done if we are to make this the default skin. Hamza Ali Shah Talk17:38, 26 September 2022 (UTC)[reply]
Oppose (for now) Entirely too much unnecessary dead space. The devs combined buttons and options into drop-down boxes (presumably to save space and not look so cluttered), but didn't do anything with the extra space. Keep the WP logo the same size. I do like the sticky banner though. I do appreciate the time and effort the devs took into trying to better the project, though. If nothing else, remove the empty space. Cheers! It's me... Sallicio!18:18, 26 September 2022 (UTC)[reply]
Oppose Way too much wasted space, especially in desktop view on mobile in which I sometimes edit. Table of contents to the side is kinda neat, but I think articles actually benefit from a bit of a gap after the lead, as it prevents the reader from being inundated with too much information on one screen, and the ToC headings primes the reader as to what they should expect from the article. I instead support a "reader view" feature in Legacy mode that reduces the width of the body paragraphs to something like A2-sized paper. DigitalIceAge (talk) 18:52, 26 September 2022 (UTC)[reply]
Oppose The problems are already pointed out, so just three comments: (1) Replacing flat text menu with hierarchical icons reduces usability among some groups - and thus the accessibility. All our readers naturally can read text, yet they might not have the skills to figure out the mysterious graphic symbols. Did anyone try to test the new layout on an 80-year old? (2) The idea that the text needs to be narrower (and its justifications) is quite strange: if all one needs is a 13-inch monitor, there would be no market for large monitors. I typically work on 40-50 inch screens, and I fail to understand the benefits of wasting by default almost all of this expensive screen space. Whoever uses a large monitor, definitely is able to reduce the window size (note that this approach, unlike the 2022 version, will not waste the space inside the window). (3) The modern phones now had reached the point that allows switching to the (2010) desktop version. The update seems to go backwards, degrading the desktop experience to match the old, non-foldable smartphones. --Викидим (talk) 21:22, 26 September 2022 (UTC)[reply]
Oppose Too much wasted space, especially in the top menu. With the new skin I need to click several times to get to any useful page such as my own talk page. This just reduced the usability. Contrary to most other opinions, I do think that the limited width in article space is an improvement, however this should be kept as an opt-in option. Apart from this, I think all other changes are a step backward. The skin does not offer anything really new, and make existing things harder to reach/navigate. Too bad, since the current skin really needs a redesign and this is really a missed opportunity. --Ita140188 (talk) 21:51, 26 September 2022 (UTC)[reply]
Note: the option 9 in the prototypes already looks a lot better in my opinion. I still have some problems with it:
more links should be accessible without needing extra clicks, such as personal talk page
the bar under the title is ugly and weirdly placed.
when scrolling down, some icons/links disappear and are replaced by some of the links in the bar under the title. This is confusing and reduced usability.
lots of things change position as the page is scrolled, for example the search bar from the center to the left, which is not good design in my opinion
Oppose The 2022 skin makes the desktop experience look like mobile. The lack of any borders around the article makes it look like an unfinished prototype. Vector Legacy is already fairly minimalistic, but there is no obvious benefit from making it even more minimalist to the point half the screen is blank. It looks far better on mobile, but that just demonstrates that desktop was almost totally ignored. ᴢxᴄᴠʙɴᴍ (ᴛ) 22:41, 26 September 2022 (UTC)[reply]
Oppose unless there is an easy toggle for the wide-vector gadget for all users. The amount of white space on the left side of the page to the left of the side bar, within the side bar, on the left between the side bar and text, and on the right is ridiculous. The general design changes are good, but we should not be following this awful trend of bringing mobile to desktop with huge unnecessary spaces between elements. Having worked on many pages with tables and other non-paragraph formatting (WP:FL), it's unacceptable how this forces table cells and columns to be narrower, screwing up the spacing within the tables and around images. Reywas92Talk23:29, 26 September 2022 (UTC)[reply]
Oppose anything with that unhelpful and cumbersome hiding of both the talk page and one's own contributions button under an extra click. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 06:09, 27 September 2022 (UTC)[reply]
Oppose. The fixed width is a major issue for me. With it turned off through custom CSS, I do like it on some screens, but the fixed with is something I don't think I will ever get used to. There are other minor issues I have with the design like the icons up top, but I think these can probably be ironed out. JackWilfred (talk) 10:53, 27 September 2022 (UTC)[reply]
Oppose I have used Vector 2022 skins on other sister projects, and as soon as I saw the whitespaces on both sides of my ultrawide screen monitor (32'), I immediately went back to Monobook. I don't think it's benefical at this stage to roll it out to the masses until they reduce the whitespace. OhanaUnitedTalk page14:18, 27 September 2022 (UTC)[reply]
Oppose On my laptop the layout looked reasonable, and I was in support, but having a look at the fixed width on a wider screen, I'm opposed. The white space is ugly and looks like a design flaw. Curiocurio (talk) 19:26, 27 September 2022 (UTC)[reply]
Oppose: I genuinely wanted to like this new version and although I appreciate all the time and work put into it and I do think it is important to keep progressing and growing, I echo a lot of what has already been stated above. I only use Wikipedia on my laptop so I cannot speak to the mobile experience, but I would like to see further work done on issues raised above before it is deployed as the default where it could potentially turn off readers and potential editors. It does not feel ready to be pushed as the default setting. Aoba47 (talk) 00:03, 28 September 2022 (UTC)[reply]
Strong oppose: The fixed width is a major problem, but the biggest no-no for me is how much the left-hand vertical side menu intrudes into the space of the article being read, and affects the general readability of it. Go to Vector 2010, switch to Vector 2022, and tell me you don't notice it. Wikipedia is far-and-above primarily about the articles and content, not the menu options, especially to casual readers. The intrusive nature of this menu is simply unacceptable to force on anyone. It wouldn't be hard to fix. But until it is, it's a strongest possible no from me.— Crumpled Fire • contribs • 00:35, 28 September 2022 (UTC)[reply]
Strong oppose. V22 is not an improvement, and is largely worse. Basic design principles seem to be put second to... I can’t even tell what problems the new skin actually solves; the inter-language menu is easier to find? The soft grey background and thin blue line around the main content in Old Vector serves to visually distinguish it from the site and wiki information. This has been changed to a white-on-white everything for no clear reason, this plus the additional whitespace makes the whole thing feel amateurish and unfinished. The lack of thought towards interface design seems to extend to the symbols for the TOC and the Main menu; when both are closed it is unintuitive which is which, and so design is not welcoming to anyone who hasn’t already become familiar with the layout (so: the opposite of stated goal of being designed for newcomers). Possibly this has been fixed in the last week before asking for the change, but when I use a narrow window on desktop I’m given a massive Main menu that obscures all content below the fold every time I click to a new page. Even assuming this has been fixed, it uses a massive amount of space (horizontal as well as vertical), and seems like a poor design choice cribbed from mobile. I also dislike the semantic implication of putting the Article/Talk and View/Edit (etc.) options below the title, rather than above and around it. Largely I am happy with Vector (legacy), and would prefer to see minor fixes to that skin (perhaps the Main menu could follow the user when scrolling down the page). It is also entirely unclear that V22 has been tested on common devices, as using a late model iPhone the mobile website scrolls horizontally for no reason. Wikipedia is a work in progress, but this skin reeks of an unfinished and a skin unready for deployment to a website with billions of users. — HTGS (talk)03:24, 28 September 2022 (UTC)[reply]
Oppose – Too much wasted space. I can understand the extra space on the left, we're getting a navigation aid in exchange. But why are we wasting space on the right? Do you know better than the reader how big a margin they want? And sticky headers are a bad idea, see this discussion: [4]GA-RT-22 (talk) 20:43, 28 September 2022 (UTC)[reply]
Oppose As per issues raised previously the fixed-width line with the white space looks untidy, Wikipedia:Whitespace agrees. Every person readsdifferently even though a study may say its the most efficient doesn't mean the reader wants it that way. Paulpat99 (talk) 22:15, 28 September 2022 (UTC)[reply]
Oppose. I will admit that UI/UX design changes often face a lot of resistance. However, in this case I really think the product is not ready for prime-time. Everyone above has mentioned about the width issues particularly on widescreen displays and the inconsistent experience between sections of the site. I however, want to talk about the "184 Languages" available link. Arguably, the most visible portion of the screen after the article name is currently captured by the "xx Languages" link by way of its positioning. Top right of the screen and you will see that your eyes naturally gravitate towards that position without trying much. It is further made possible by the font size and the bolding. Clicking on that link takes one towards a labrynth of mismashed pages, some on legacy, some not - just a weird experience down from there on. The problem is further compounded by the fact that there are some translation and page creation in these languages that open up and that is another set of experiences that we do not control but will but the second or third link that readers would land-on. Really need to ask the question if that is the most prominent link that we need to be showcasing. Do we have some metrics that say that the same reader is looking for the article in multiple language WPs? Should base this decision choice on solid available user metrics before going with this change. Ktin (talk) 23:39, 28 September 2022 (UTC)[reply]
Conditional oppose. So long as logged-out users can disable this with one click (as they currently can with VisualEditor, MediaViewer and MobibleFronted) I don't see a problem. But if there's a button to do that, I can't find it. No reader should be forced to create an account just to turn this "upgrade" off. Suffusion of Yellow (talk) 00:21, 29 September 2022 (UTC)[reply]
Hello @Suffusion of Yellow. Thank you for providing us with the reasons why you've chosen the conditional oppose option. We may consider making this link a single-click thing for logged-in users. But regarding logged-out users, see this diff. In short, this is impossible, never was, and it's beyond our discussion to wonder if it ever would be. Unfortunately, requiring this to be possible is not a realistic expectation. I'm really sorry, because this isn't obvious for anyone. SGrabarczuk (WMF) (talk) 00:58, 29 September 2022 (UTC)[reply]
@SGrabarczuk (WMF): "Impossible" is a state of mind. :-) Indeed, it would seem we are talking about a significant increase in cache server resources. How significant? Has this been analyzed, or is that just a guess? I mean, you are already storing two copies (mobile and non-mobile), IIUC. Would storing a third really break the camel's back? Alternatively, would having Vector-2010 users bypass the cache (as all logged in user already do) cause significant server load? Suffusion of Yellow (talk) 23:00, 29 September 2022 (UTC)[reply]
Oppose. Overall, I think it looks a bit nicer, and I really like the contents on the left side. That really helps. However, there are other problems. (a) I do NOT like how the other language wiki options are hidden. (b) Having buttons rather than words for things like watchlist etc. is unnecessary. I fear it discourages their use ie discourages people from becoming editors. (c) I prefer the grey bar down the left rather than unstructured white space. I've been trying to use Vector 2022 recently. I switched back to Vector 2010 on this very page and realised it was visually easier to navigate the list of comments when they close to a visible edge. It's not as pretty, but it's easier. OsFish (talk) 06:22, 29 September 2022 (UTC)[reply]
Oppose – Too much wasted space, especially on the right side. Looks imbalanced and it's an eyesore. And the fixed width is a dealbreaker for me. - Ïvana (talk) 01:20, 30 September 2022 (UTC)[reply]
I came here expecting to support, as I've never thought Vector serves readers particularly well. However, this has far too many major issues to deploy, most obviously overriding the width preferences of the 99.9% of readers who aren't logged in, but also the mystery-meat icons, hiding the login button, the removal of elements from the sidebar with no indication to readers as to where they've gone…
I know the devs, and the WMF in general, get frustrated at the inherent conservatism of English Wikipedia, but it exists for a reason. English Wikipedia gets more readers than all the others combined; when we have around 850 million unique devices viewing our content, then even if 90% of readers aren't bothered by a change that still means upwards of 80 million people are going to be confused or upset. Readers don't use Wikipedia in the same way they use other websites, and knowing where to find things and which button does what is more important than on websites like Britannica; the fact that we largely look and feel the same in 2022 as we did in 2005 is a valued feature, not a problem that needs to be addressed. ‑ Iridescent05:01, 1 October 2022 (UTC)[reply]
Oppose Just leave Vector legacy as the default skin for now. Many of the users above in this section have pointed out different concerns about the new skin. I also didn't like it (mobile interface of the new skin). Try to fix that first. Volten001☎06:22, 1 October 2022 (UTC)[reply]
What happens with all the "how to use Wikipedia" material out there? The publishers are going to curse our little discussion here that they were never aware of. This little discussion involving only a few hundred editors has the potential to vastly alter how millions of people per participant interact with Wikipedia, and it really isn't clear yet that it will certainly be an improvement. Remember, for every participant at this point, there are over 4 million users. The national parliaments of most countries have less people per politician. Also, doing this all at once risks creating unwanted media attention. Mako001 (C) (T) 🇺🇦 14:07, 1 October 2022 (UTC)[reply]
And it hasn’t been as id for more than 12 years. Vector legacy had multiple tweaks throughout the years and non-visible technical updates as well. Tvx1 17:44, 1 October 2022 (UTC)[reply]
To quote Pythoncoder above: I haven’t made a final decision on how I’m going to vote yet, but I do want to say that I’m not totally sold that this’ll lead to bad press. It might actually lead to good press — it’s not that hard to find articles about WP’s design being outdated/bad. (Of course, it’s not like those websites are designed any better…). —Danre98(talk^contribs)20:52, 1 October 2022 (UTC)[reply]
Oppose. I've been following this discussion for a while now but I didn't want to jump to conclusions on anything too quickly.
Changes in Vector 2022 that I don't have a problem with
The reduced width of the text, in principle. I don't have a problem with reading text in the current skin, but I'm on a laptop screen, and I find that large screens do indeed hurt readability.
The breakage of page layouts that were created with the assumption that the page would be read with Vector or MonoBook. This is the Wikipedia equivalent of "Best viewed in Chrome" — it's just bad design practice. It also leaves out the users of Timeless, Modern, and CologneBlue (though maybe not that last one because who knows how many people still use it).
The breakage of gadgets that were designed for Vector or other skins. The WMF can't be held responsible for the vast array of user-generated modifications to the site design. It would be nice for the WMF to provide some support in that area but I don't consider it necessary.
Coordinate placement. That's an English Wikipedia extension, right? Not a deal-breaker. (EDIT: Please correct me if I'm wrong about this.)
Changes in Vector 2022 that I do have a problem with
The off-center appearance. I know the text of the article is centered, but with the sidebar and/or contents in the picture, it just looks bad.
The sidebar being hidden under a hamburger menu. Hamburger menus represent one of the worst trends in web design in the time since Vector debuted in 2010. I am of course speaking of "mobile-first" design, which is better described as "desktop-last". The desktop site has the space, so why not use it? Maybe move the contents over to the right?
Everyone else is talking about the whitespace on the sides, but what really gets on my nerves is the whitespace on the top. I mean, you've got all that empty space, and what do you do with it? Nothing. It's simply incomprehensible that "create account" is easily visible but "log in" is hidden under a mysterious dot-dot-dot menu.
The hieroglyphics in the top bar. I thought this redesign was supposed to make Wikipedia easier to use?
I said earlier that the redesign may not lead to negative press coverage. But you know what might? Showing images with the search bar. Because inevitably, some of those images are going to be porn, and that's going to lead to another round of negative media coverage like when Trump's page was getting vandalized with such images.
In my opinion, the negatives outweigh the positives. However, I do not believe these problems are insurmountable. I encourage the WMF developers to listen to the English Wikipedia community's feedback and come back in a year or two once the issues are resolved. ★★☆☆☆, needs improvement —pythoncoder (talk | contribs) 21:14, 1 October 2022 (UTC)[reply]
Oppose I can't get past the horrid use of real estate, and all the blank space on my screen. It makes it tougher for me to read, with so much fewer characters per line. It seems we are designing the website for monitors that are taller than they are wider - which are rare. Also, I switch between languages frequently, and loosing the list of languages on the left is frustrating - especially when 40% of the screen is white space, with lots of space to put languages. Nfitz (talk) 03:59, 2 October 2022 (UTC)[reply]
Oppose. I recognize we need to move forward with UI, but this feels like a step backwards. While the skin adds certain readability and accessibility principles, it's also a whole lot of bad practices no one asked for. I've been using it for 2 weeks before !voting and with some modified CSS to see if it's workable (which I shouldn't have needed to do). At first I would have reluctantly supported the switch, but the more I use it and the more I read WMF's stance on UI, the less I am confident with this whole web design direction. Editors are treated as second class citizens to readers. The skin is bland and empty and lacks features it should have done 10 years ago. It's like every good feature and improvement comes with two steps backwards in some other area. Accessibility isn't actual accessibility as you cannot even change the colors or text size. I'm not sure there's anything else to be said about whitespace and content width. It has 0 customization and, no, WMF's comment that "technical users can make their gadgets to customize" is not customization and is a sad indication of afairs. I don't have the energy to list all the problems and dubious design choices since 1) there are so many and 2) it's so trimmed and bland, it doesn't even matter. Today, the last straw was when I used the home/end buttons to move the cursor in the search bar and it turns out these buttons have been remapped to the search results dropdown (I wonder what accessibility guidelines say about that one?). — HELLKNOWZ∣TALK11:11, 2 October 2022 (UTC)[reply]
There is already a fix for the home/end coming this or next week. See T314728. Note that this isn't a skin issue, but a control issue and present in multiple skins (and also in other places than just search). —TheDJ (talk • contribs) 10:12, 3 October 2022 (UTC)[reply]
@TheDJ: Thanks for letting me know and anyone looking at this. That said, this doesn't happen with the search bar on current Vector. As a side note, this is still just one symptom of everything I mention versus quality. Stuff like this should have been fixed looong before a question of publicly deploying the skin would come up. — HELLKNOWZ∣TALK15:42, 3 October 2022 (UTC)[reply]
Oppose, at least for now. There are positive steps here. The "sticky" ToC is actually rather nice (and that's a surprise to me, I usually hate "sticky" elements on web pages). And the layout in general is reasonably nice looking. But too many steps backwards. First, don't replace text with icons. We've already got the "emoji" idiocy, and those things make communications less clear (unless combined with text, in which case they are useless clutter). Let's not add to that. Text is the clearest form of communication, and also the most accessible for those who use assistive technology. Also, give a way to close or disable that "following" bar at the top; that is an annoying and distracting "sticky" element. In addition, some elements really did not make intuitive sense—when I wondered, for example, "How would I delete or protect this page?" (don't worry, I'm not going to actually do it!), it took me a fair bit of clicking around to figure out that this option would be under the "More" menu.But the biggest issue is fixed-width. I think Beccaynr has already done an excellent job in their source analysis of explaining why I'd be skeptical about what's been said about that, so I won't belabor it here. But I didn't get two 28-inch monitors because I wanted not to use the whole thing, and presumably no one else did either. If that were offered as an opt-in (not opt-out) feature, I might be substantially more inclined to support, but I think most websites use such a layout, not because they think it is tremendously kind to their readers, but to reserve space for ads. Obviously, that is not a concern for us, so we can and should use the whole available area. As an example, I tried out reading the discussion around "support" #11 on both the old and new version (and on Monobook, which I normally use and will continue to anyway). On Monobook and standard Vector, the entire discussion fits easily on my screen. On the new Vector, I have to scroll in order to read the whole thing. That is a step backward, not forward.So, this is not a "never, scrap this whole idea", but is a "not now". Remove fixed-width (or make it opt-in), replace icons and hidden stuff with good old plain text, and such, and I would probably be a lot more inclined to support next time around. We do not need, and should not want, to look like a clone of Twitbookinstatube. SeraphimbladeTalk to me03:36, 4 October 2022 (UTC)[reply]
Regretfully, weak oppose for now. You can win me over to Support by providing not-logged-in readers with a cookie-based toggle to "switch to old look" (and back again), and measuring the results. Yes we have supportive opt-out data from other wikis, but users without accounts don't yet have that choice to opt out. (Aside: can you also instrument to measure when users enable their browser's reading mode? I suspect the numbers would be small.) Caveats: (a) I haven't read all the posts on this long page; there might be a good argument here that changes my mind. (b) I don't see this !vote as mutually exclusive with also supporting / commenting at the alt proposal (short answer - I'd like to see both a "switch to old look" and a separate width selector). P.S. shout out to WAID and Peter, I would love to have used Discussion Tools to post a numbered entry here, but had to do a whole-section edit instead. ⁓ Pelagic ( messages ) 09:48, 4 October 2022 (UTC)[reply]
Oppose because of the hard limit on the screen width. As I've got gradually deteriorating eyesight, I now insist on at least 2x1080p screens for work (I've currently got a 2K and a 1080p) and I use the same for editing. Ritchie333(talk)(cont)23:20, 4 October 2022 (UTC)[reply]
Oppose. When I go to my user talk page in the new skin[5], I see rather prominently "Add languages", a bold blue drop down which does absolutely nothing. Same for others[6]. Same for article talk pages[7], and so on[8]. Apparently every freaking talk page has a large blue drop down at the top which does absoletuly nothing. And we are to believe that this is thoroghly tested and deployment-ready? Fram (talk) 13:55, 5 October 2022 (UTC)[reply]
I suspect you have disabled "Use a compact language list, with languages relevant to you." at the bottom of the preferences tab (which is used by <1% of traffic). I've raised a bug for the language team to look at. https://phabricator.wikimedia.org/T319690
@Jdlrobson:, thanks, but even when I reenable this, I get on all millions of talk pages a very rarely used user preference (keyboard language settings and so on), which belongs in preferences and not prominently at the top of every one of the millions of talk pages, where we can't actually add any languages and where the language dropdown, which may be useful on articles (though too prominently placed for my taste), is a large design element with no or extremely little actual use. What is good for pages may be bad for talk pages (any namespace), and this is a very clear example, and looks like a serious oversight or carelessness from the design team (and the testing team, if any). Reminds me too much of the flaws in Visual Editor, Flow, ... when the WMF thought it was ready for widespread use. Fram (talk) 09:44, 7 October 2022 (UTC)[reply]
Thanks. I don't get why they try to do completely different things (1 = read this article in another language, 2 = change my editing preferences to another keyboard or similar, 3 = change the menus to the language of my liking, and apparently 4 = start the content translation tool (which is disabled on enwiki) all from the same place, on all pages, even though they have vastly different applications: some of them, as seen here, are not needed on millions of pages at all, but are somewhat important on content pages (though not as prominently as they are in the new skin); while some of them are only needed very occasionally, just like other preferences, and should be part of the preferences, not part of a dropdown shown so dominantly on every page. Just because they both have "language" in the description doesn't mean they belong together. For a new skin which supposedly is about improved UX, this is very poorly thought out. Fram (talk) 13:29, 7 October 2022 (UTC)[reply]
@Fram I think I'm in the minority, but on articles I don't really like giving our readers such a high prominence passthough to other projects - where the article quality could be vastly different. As a casual reader, my impression would be that that pull down would show me this article translated to said language -- not a completely different article on this subject written in another language. — xaosfluxTalk13:43, 7 October 2022 (UTC)[reply]
Agreed. I don't get why they believe this to be so important that it needs to be the one thing that is the most accessible of all, and if so why they then pollute it with unrelated stuff, making things more complicated instead of more intuitive. Fram (talk) 13:53, 7 October 2022 (UTC)[reply]
Oppose, primarily on account of the extra clicking needed to access the important links at the top of the screen. I've always hated the hide-and-seek game of finding important links on other MediaWiki-based sites. Also, the fixed whitespace to the right of the article makes it feel cramped compared to the header and footer which extend all the way to the right. Even sites that restrict the main-body width try to make it roughly match the width of the header and footer, at least when combined with a sidebar. LegionMammal978 (talk) 01:04, 6 October 2022 (UTC)[reply]
Oppose: As the user of a UW4K display as the primary interface for all interactions on Wikipedia, my immediate concern is that Vector (2022) does not respect the wishes of the end-user because the design philosophy regarding the text-to-whitespace ratio is essentially "I know better than you; you think you want more text, but you actually don't, I'll decide how much text you actually want to see", in a sense. At least make the readable width user-adjustable through an option slider tucked away or something, and respect the intelligence of your reader. Monobook respected the reader's choice, Vector (2010) respected the reader's choice, Vector (2022) does not; with the earlier skins, if a user personally preferred a smaller readable width (and that's perfectly fine, every person's reading preferences are different), they had the choice to view Wikipedia in a smaller Windowed browser instance; what's the choice available for the other category of user, if they use Vector (2022)? Make a user account and switch to Vector (2010)? As a software developer, my job is, also, to cherrypick arbitrary metrics to justify various front-end changes to my users, and I think I'm very adept at it; I note that the Vector (2022) team arbitrarily chooses to showcase 87% of active users continuing to use the new skin, but why not satisfaction surveys of non-logged in users? Why not measures of the time to navigate between interlanguage links? Why not the time to navigate for users over the age of 65 who have never seen a hamburger UI menu before? Why not any of the hundreds of other potential measures of success? Focusing on showcasing a measure that is relevant to only a small portion of users doesn't seem like very good coverage of the actual cross-section of Wikipedia users. "The skin does not negatively affect pageviews, edit rates, or account creation." - That's because everyone still needs to grit their teeth to use the new UI; what are they going to do, not browse Wikipedia to look up the plot to a 1997 TV show? How is this even a metric? --benlisquareT•C•E17:19, 7 October 2022 (UTC)[reply]
Oppose: I especially dislike the new sidebar TOC. I prefer the old TOC below the article's lede. The full, uncollapsed TOC under the lede is an essential feature for having a clear, immediate "mapping" of the structure of an article (or a talkpage discussion) and of its contents. The new TOC does not perform such function as well as the old one.--Æo (talk) 15:55, 10 October 2022 (UTC)[reply]
I experimented a bit with the new graphics and I have to say that I not only oppose the new TOC, but I oppose the implementation of Vector 2022 altogether. It's simply a step backwards. Vector 2010 is better in every respect.--Æo (talk) 14:51, 23 October 2022 (UTC)[reply]
Oppose Mainly on width issues. I mainly write art history articles with lots of images and this will not be good for them. I actually am ok with the sticky TOC, but the left column is too wide. Also ok with hiding other language versions. Johnbod (talk) 18:26, 11 October 2022 (UTC)[reply]
Oppose per width and TOC. There is way too much opposition here about the width, until this is fixed this RfC is deadlocked, which means that there is no consensus for a change. If it is passed and implemented regardless then a review should take place. No consensus presently exists, and the amount of editor dislike will translate into millions of readers being confused at the change and, tragically, lessen Wikipedia readership. I use Monobook, which I would say is a far superior and understandable default option (and contains the Wikipedia logo, something lost on default). Randy Kryn (talk) 10:37, 13 October 2022 (UTC)[reply]
Oppose due to the fixed width issue and a lack of ability for logged out users to easily switch back. I also don't understand the argument that language is easier--the collapsing seems to make it more difficult? Bestagon ⬡ 19:48, 13 October 2022 (UTC)[reply]
As usual with website "updates", meaningless change for change's own sake. But obviously, this is a kangaroo court, so I should probably spend my time learning how to revert to the old look instead. Mr.choppers | ✎ 01:46, 14 October 2022 (UTC)[reply]
Oppose As someone visually impaired who uses zoom options with my browser, I can't imagine this being remotely an improvement based on what is presented here. Just a complete addition of worthless whitespace. Parabolist (talk) 09:07, 15 October 2022 (UTC)[reply]
Oppose as someone using the desktop version on mobile this is just rubbish. Extra white space only cramps the text, and zooming in on the text to overcome this means that articles no longer have a toc at all. From a less personal view having a fixed width website in 2022 is laughable, in fact it was laughable 10 years ago. Why on earth are we overriding user preference? One of the things Wikipedia has done well is to auto-format pages depending on the screen used, and now that all goes away. I guess I should change this to weak oppose as editors can always change this in their preferences, but why have certain editors having a worse experience until someone tells them to just stop using the default skin. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 20:57, 15 October 2022 (UTC)[reply]
Oppose: This skin's name is bad, this skin's implementation is bad, and the team behind it is bad. My recommendation is to throw away all three. As I said elsewhere, this request for comments is a sham. It doesn't matter how many people object or raise issues, the default site-wide skin change will be pushed through after Wikimedia Foundation Inc. gets its veneer of community consultation. The organization is deeply corrupt and is in serious need of reform. --MZMcBride (talk) 00:55, 16 October 2022 (UTC)[reply]
Oppose: The fixed-width issue and the inability for logged-out users to switch back are big roadblocks, imho. I also find the empty (and, thus, pointless) "Add languages" drop-down option on talk pages to be super annoying, and I agree with Seraphimblade that replacing text with hieroglyphics icons is not a good idea.--Gen. Quon[Talk](I'm studying Wikipedia!)00:31, 17 October 2022 (UTC)[reply]
Oppose: Makes it harder to find everything currently in the sidebar, most importantly language switching, while still requiring scrolling to the top, infact it requires more scrolling in that case than our current default. Also it just doesn’t look good, and I’ve never had issues with our current vector’s design. MRN2electricboogaloo (talk) 16:03, 17 October 2022 (UTC)[reply]
Oppose: This skin makes me want to reduce my window size so that it stops wasting so much space. That's not a feature. RAN1 (talk) 17:41, 19 October 2022 (UTC)[reply]
Oppose. In my opinion, this default design is mobile-focused, rather than in-depth reading. Squishing the text makes things longer and wastes a lot of space, even though it's part of the mid-2010s CSS styling trend. And I feel that the methodology for the 87% of users continuing to use Vector 2022 is flawed. What I understand from the phab task is that the skin was turned on for everyone, and only those who had significant disagreements switched back. It implies that 87% of users like the change, or are more positive than neutral about it. But what I can guess is that there could be additional reasons for why users didn't switch back. SWinxy (talk) 22:30, 19 October 2022 (UTC)[reply]
Oppose The narrower width and the table of content issue is horrible and certainly not the "default look" millions of people who read WP while not being logged in should see. Causes more problems than it solves. ~StyyxTalk?21:48, 24 October 2022 (UTC)[reply]
Oppose until fullwidth is the default. Other than problems with the layout of some pages, a fixed-width option would be fine, but it's unacceptable to deprive users of control over line width that they already have, just because the designers think they know what's best for readers better than readers themselves do. Other than that, it has some minor improvements, like the togglability of the sidebar, and some other minor drawbacks such as the floating title, made redundant by the tab <title>. I would also warn against evaluating it in terms of its vague "modern" feel: Wikipedia should not be a brand, so we should only evaluate it in terms of its practical effects on readers and editors, not in terms of what will draw attention and create a good "image". As for desktop-mobile unification, I also think that having two different skins for two different platforms, mobile and desktop, is an unambiguously good thing. I can't understand why people would see the ability to have different, bespoke systems working in different contexts as a problem. small jarstc22:12, 27 October 2022 (UTC)[reply]
Strong oppose: it looks like a mobile site (just like Windows 8 was bad, among other things, for behaving like a mobile/tablet OS), it wastes too much screen space, adding too much whitespace, making much less content visible without scrolling, which will degrade reading experience of any decent length articles. It will break articles with a lot of images and wide tables (e.g. opinion polls). I see some people pushing it parrot that some research points that fixed width is better for reading, but the vast whitespace between the main text and other elements makes it harder for eyes to grab some visual anchors, making it actually harder to read. I keep getting lost (and annoyed) when trying to read on other wikis (while not logged in) where it was already forced upon. I would like to propose an alternative of 1) adding a skin-switching widget and 2) making the useskin parameter persistent (by adding it to href attributes of links and action attributes of forms). I guess that a relatively simple MediaWiki extension could be written which would do that, at least the second part (persistence of the useskin parameter). Niokog (talk) 10:42, 28 October 2022 (UTC)[reply]
I've been using Vector 2022 for several months and have been providing extensive feedback to the developers here, at MediaWiki, and via the office hour video calls. The developers (represented to us by Olga and Szymon) have been very open in explaining their rationales behind the changes they'd like to make, and I think that the skin at this point is a clear improvement over legacy Vector. It's also still clearly a work in progress, with areas for improvement I'll enumerate, and I think if those are addressed before it's deployed, it'll have a more positive reception with both readers and editors. That makes me neutral about current deployment. Pushing me toward a strategic support are the many disappointing knee-jerk opposes above, and pushing me toward strategic opposition is the desire to have some leverage to guide future development, so together they land me back at neutral.First, to address the screen-width opposition, I think this discussion would look radically different if everyone was required to use Vector 2022 for a month before !voting. Design changes take some getting used to, and I had an adjustment period myself, but at this point I find the new width to look perfectly natural. The developers have presented substantial evidence that the consensus among usability professionals is to use a narrower screen width, and although there are some attempts to discredit that evidence by Beccaynr et al, I have not seen anyone presenting usability research explicitly favoring a wider width, as I would expect were the research truly disputed.Moving on to other issues, moving the article tools to the article toolbar (phab T302073) is a major factor in getting me comfortable with the table of contents occupying the location traditionally used by the left sidebar. The developers are working actively on this, but I'm still a little surprised they didn't resolve it before launching this RfC, as I recommended. There doesn't seem to be too much opposition based on this so far here, but I'd speculate that that may just be because it's getting drowned out by the screen width concerns, and that focus might shift to it in a future version RfC if it's not resolved.For the sticky header (phab T283505), I'd like to see additional thought put into which elements are included or excluded. An element that would be useful for me as an editor — my alerts/notices — is not included, whereas another that I suspect is not particularly useful to either readers or editors — the language switcher — is included (although, oddly, only for logged in users at the moment). I don't see a normal use case for why someone would want to switch to another language after they've started scrolling, and I certainly don't see it being such a popular feature as to justify having it be the only element of the header that gets text (e.g. 47 langauges) rather than just the icon.My last concern relates to page status indicators, including protection status icons and the FA star/GA plus circle. By commandeering the upper right corner for the language switcher, the new skin pushes the indicator icons down a row, and by moving the page tabs line below the page title line, it pushes them down still further. The developers have explicitly touted how the additional prominence of the language switcher is desirable, but when we have raised concerns about the diminished prominence of the indicator icons, they have declared it outside of the initial scope of the project. That doesn't jive — if you're going to move elements around to reprioritize them, you can't only consider a subset of the elements. Protection icons don't need to be particularly prominent, but they should probably be moved next to the edit button (or integrated with it, as in the pencil-and-lock icon used in the mobile skin) because it's most applicable to those considering editing a page. The GA/FA icons do need to be prominent, because they ought to be a key indicator to readers about the quality of an article, yet currently most readers don't know they exist, and diminishing their prominence by moving them to the developer's chosen position will only make that worse. Given current challenges in the misinformation landscape, emphasizing tools to help readers assess an article's trustworthiness should be (and is on paper) of paramount concern to the WMF, which makes the lack of attention to this issue particularly frustrating. Moving the GA/FA icons directly next to the article title instead of pushing them down would be a better alternative, and there are probably other available solutions I'm not creative enough to envision. This is the issue that the developers seem least interested in addressing — they have committed only to fixing the coordinates display (phab T281974), which is a separate issue (and I'm leaning toward not having them per Xaosflux because they're not fundamentally a page status indicator and thus don't belong outside the normal content area, so I consider that fix less essential anyways). Therefore, I encourage the community to speak up more about the importance of this.Overall, if these issues are addressed, it'll move me from my current lukewarm stance to enthusiastic support. In general, I feel that the foundation is often overly cautious in rolling out changes, preferring the slow perfect to the rapid good, but given the particular sensitivity of design changes, it's worth taking the additional time to put the best possible foot forward. Ultimately, I hope that the developers are able to come up with a design sufficiently compelling to overcome the knee-jerk statusquoism some in the community will inevitably have. Regards, {{u|Sdkb}}talk06:51, 24 September 2022 (UTC)[reply]
I am surprised by comments mentioning variations of "knee-jerk statusquoism" when other comments, such as from Nosebagbear above, include concerns about "major community worktime issues that come from needing to redesign very large numbers of articles to match this layout better." For me, it does feel daunting to consider how many articles will need review and potential adjustment, and I am familiar enough with various articles to consider the impact (e.g. on articles already designed with shorter line lengths thanks to the addition of images, quote boxes, etc).
My own reaction includes my understanding of principles related to presenting information that I do not see reflected in the new skin. For example, I question the removal of the TOC from the top of the article, because it seems contrary to centralizing the need of the reader to immediately know what the article includes, in multiple formats. We do not have well-developed leads across all articles, and the TOC is another way to present an overview. If we are here to educate, then the impacts on how we present information as an encyclopedia seems to be a critical consideration.
I think Sj gets at the more existential issue in their comment below, and from my view, some of what seems like "knee-jerk" reactions may be related to this skin being presented as emulating nonencyclopedic websites (e.g. like an online newspaper, etc), as if this is obviously desirable. I was also less attempting to discredit the studies than to critique the validity of what has been offered as applied to what we try to do as an encyclopedia. In the meantime, somewhere in this discussion, although I have not been able to quickly find it, Line length#Electronic text was noted, and the citations seem to suggest mixed results. However, I appreciate your insights very much, Sdkb, and I hope developers will consider the various reasons for resistance, and how even first impressions may create access barriers for both readers and editors. Beccaynr (talk) 16:41, 24 September 2022 (UTC)[reply]
@Beccaynr, re the ToC, it took me a while to understand the vision the developers have for Vector 2022. The links currently in the left sidebar that editors use frequently are part of the article tools section, and readers don't use any of the left sidebar links much. Once the tools have been moved to a menu similar to what Twinkle currently is, they anticipate that everyone will be able to collapse the left sidebar by default, making the table of contents always appear at the top (just the top left rather than top center). That vision makes sense to me, but it's hard to see currently as it's not realized yet, which I believe is leading to some of the non-width-related opposition. {{u|Sdkb}}talk16:54, 24 September 2022 (UTC)[reply]
I'm in favor of easy language switching. Like many WP-en editors, I've encountered references to sources in other languages, at least one of which I can read. Some have direct links in the English page content, but in other cases, the switch is: return to main page, enter the other language's WP, do a new search.
I find it odd that someone so well-informed will use "knee-jerk opposes" as a justification for leaning to Support. This seems unduly exterior-driven, almost a hedge against the risk of forming one's own opinion. OTOH, I admit that my own aversion to the pushiness of making the skin change a default could also be seen as exterior-driven.
Regarding Beccaynr's salutary distinction between accuracy of stats and applicability, I invoked Jakob Nielsen in my comment on Oppose 4. Namely, he emphasized the importance of letting the user's own combination of device/browser select the parameters for display. The goal of improving readability of text is being undermined by insistence on the means of making the line width fixed for everyone (unless you opt out). Martindo (talk) 02:58, 25 September 2022 (UTC)[reply]
I've been using Timeless for a couple of years now and even though Vector 2022 is an improvement over the default skin Timeless looks a little bit better to me:
Vector skin shortcomings:
There's too much white space at the top of the screen
Color-wise it's too white and bland
It could be a tad wider
The user menu at the top looks detached from the page (there's a huge gap between the search bar and the user menu)
RelatedArticles is disabled on Vector (and thus Vector 2022) because previously the English Wikipedia community asked for it to be turned off.
The feature is enabled/disabled on Timeless skin only because communities have requested it (for example it was added as part of phab:T181242 and German disabled it in phab:T278611)
I switched to Vector 2022 yesterday. I like the TOC down the side and the overall balance of whitespace. Linked text has insufficient contrast with the white background - the darker blue that was used in whatever skin is the default now has better contrast and is less tiring. I do miss the text links for navigation at the top - when I'm halfway down a Talk page it's not intuitive how to get back to the article. I also miss having a one-click button to see my own contributions. Clayoquot (talk | contribs) 14:34, 25 September 2022 (UTC)[reply]
For the old colours (which also pose an accessibility issue, see phab:T213778)
a:visited{color:#0b0080;}
a:link{color:#0645ad;}
For the settings I'm now trying (darker colour, but with subtle underlining). The purple is still ugly, and the underlining occurs in places it shouldn't, but I think it's the right direction for a WCAG-compliant solution..
I noticed that I don't have a one-click way to get to a user's contributions from the user's Talk page, and the way to get to the user contributions page is poorly labelled. We need the links to Email this User, User Contributions, and Block Log to be prominent from both user pages and user talk pages. Clayoquot (talk | contribs) 23:51, 27 September 2022 (UTC)[reply]
These links are covered up by the TOC in the sidebar. TOCs should never cover up the usual list of sidebar links in Talk pages in any namespace, even if the user's preference is to display the TOC in the sidebar of articles. Editors rarely use TOC links in Talk pages. Headings in Talk pages tend to be written hastily and crappily so they are often not meaningful.
I'll probably stay in Neutral instead of Oppose because clearly a lot of good work has gone into this and I don't want to discourage the designers. However at this point I do prefer the old skin for tasks other than reading articles. Clayoquot (talk | contribs) 15:46, 29 September 2022 (UTC)[reply]
Hey @Clayoquot, thanks for your feedback on this. What you're suggesting will be fixed soon (see T302073). The prototype only shows the change on main namespace pages, but you can imagine how it will work on User pages (with the relevant tools — User contributions, Email this user, etc. — directly exposed in the right sidebar). Does that make sense? AHollender (WMF) (talk) 18:01, 29 September 2022 (UTC)[reply]
One data point about one person's preferences, FWIW: I've switched back to Vector 2010, mostly because of link colouring (I tried Femke's overrides but it made wp:redlinks not red so it still wasn't optimal) and placement of the Watchlist and Contributions links. Good luck! Clayoquot (talk | contribs) 13:50, 8 October 2022 (UTC)[reply]
Switched to the new skin to give it a fair try past my initial knee-jerk "no" of unfamiliarity. Some thoughts:
The page width thing is incredibly frustrating, as everyone else said. Studies or no studies, I don't particularly want to be jammed into it for my own good. Notably, it also forces images, infoboxes, tables, etc into the width, squishing any text next to them. When it's pure text it's okay, but when there's a lot of other page elements it gets very very cramped. The main page especially looks bad. A good first attempt at fixing this might be to move the infobox into the rightwards whitespace. An exception for the mainpage might also be nice.
I like the moving sidebar table of contents, and how it highlights which section you're in. I really don't like that the editor tools force it down the page, making me scroll every time I want to interact with it.
Don't love how the top page links have been replaced with icons, though I'm sure I'll learn them quickly enough.
Going back and forth on whether I like the new prominence of the language switcher - I personally do, as an editor, but I don't know that readers need that very much.
Overall appearance is nicer, though the grey box with editor tools looks slightly out of place. Might like it better if all of the whitespace on the sides was the same grey, to seperate it from the article content a little.
Further thoughts: not being able to see the table of contents immediately gets more furstrating the more I interact with it. The fixed width is fine with plain text, maybe growing on me, but is awful on the main page (which incidentally has weird white space at the top due to not having a title) and frustrating when there's a lot of non-text content. I also don't like that the table of contents doesn't take up the full height of the page, and isn't auto-expanded.
Stylistically it's... probably better? I don't like "modern" website design but I think the average reader does, and this avoids most of the really bad things about it. Rusalkii (talk) 03:45, 1 October 2022 (UTC)[reply]
Thanks for putting this up for comment. I'm a reader with no interest in making a Wikipedia account, and I only found this discussion through an offsite link. My one "note" is that I think the floating title bar that seems to (currently) only be shown to logged-in users should be universal – I recognize most of the tools there are only of interest to editors, but I think it would be a great benefit for all readers to be able to search without scrolling to the top of the page. Otherwise, this design is fine, probably better than the current skin. I wouldn't complain if you made it a little less white, though. 130.184.252.29 (talk) 17:24, 26 September 2022 (UTC)[reply]
Swapped from Oppose (yes I know this in the neutral section however I'd like to make my initial opinion more obvious). I've been using Vector 2022 for a few days now so I can form an opinion other than just an immediate "No it's not what I'm used to". The main thing that bothers me is that, with my current screen, everything is slightly shifted to the right because of the sidebar. Other than that, it's fine. There are a few things I wish could be changed but it's fine for the most part. I don't usually edit from a large, widescreen monitor (largest one I regularly edit from has a resolution of 1280x1024 and is practically a square) so I don't actually notice the width issues. I would probably like it a lot more if this beta/preview were implemented soon as the options there can provide a nice separation between the article content and the tools. The minimalist design takes some getting used to with icons instead of words in some places, and also having to click on buttons like "Page" or "TW" or "More" rather than hover over them. So I'm kinda on the fence at the moment. Heck if they implement a proper dark mode rather than just an inverter that would probably bring me over to support ― Blaze WolfTalkBlaze Wolf#654513:21, 27 September 2022 (UTC)[reply]
I'm not going to oppose the change, but I trialed it and found it very annoying and hard to get used to. Like others I use a large desktop screen. (Although I'm editing on a laptop at the moment at only 3024 × 1964.) So the familiar three-column layout of the references was reduced to just two. The edit article button being lower than the edit first section one took a lot of getting used to. And the fact that the layout changed when you went to edit sort of defeated a major rationale for the new skin, namely being able to see the layout at edit time. The biggest obstacle was the loss of the WikEd editor, forcing the use of the older 2010 editor. This meant that I lost a lot of my editing features, like the ability to change case and see ndashes. It was this that eventually had me revert back to the old skin. Hawkeye7(discuss)23:31, 30 September 2022 (UTC)[reply]
Neutral. After reading the above, I'm kind of 50/50 on Vector 2022 (which is currently used on the MediaWiki documentation wiki, the WMF Governance Wiki, and several foreign-language editions of Wikipedia) becoming the default skin for the English Wikipedia. AKK70002:29, 4 October 2022 (UTC)[reply]
Neutral, changed from oppose. I still don't think the problems you're trying to solve are well-defined, and I don't think this will solve them, but I no longer feel that it is actively harmful. --3mi1y (talk) 20:20, 9 October 2022 (UTC)[reply]
Vector 2022 is the default for logged-out readers and accounts created after the deployment.
Vector 2010 remains the default for current accounts.
A text-width toggle is added to Vector 2022 for both logged-out readers and logged-in readers. To clarify, logged-out readers will be able to choose a full-width version of Vector 2022, but they will not be able to choose Vector 2010.
These two comments—[9], [10]—apply: there would have to be a significant increase in cache server resources to avoid affecting performance for non-logged in users, as there would now be two possible versions of each page for them. If the change is done with Javascript then the cache doesn't have to be split, but then the layout may visibly change appearance as the Javascript code runs. isaacl (talk) 22:40, 28 September 2022 (UTC)[reply]
Not really, as long as the layout change only requires a few CSS rules, there are ways that can be delivered to logged-out users on top of the cached parser output, conditional on the existence of a cookie in the HTTP request. It may be difficult but not impossible – sadly it seems @OVasileva (WMF) and team don't want to explore such ideas. – SD0001 (talk) 04:57, 29 September 2022 (UTC)[reply]
Right, that's what I'm thinking. Even if the solution required briefly showing the page with a max width, I imagine the type of user to request a wide view, being more "technical", would also be more tolerant of such an issue. Enterprisey (talk!) 05:06, 29 September 2022 (UTC)[reply]
Some logic processing is always going to be slower than none at all, and this is multiplied by the large number of anonymous requests arriving constantly. The degree to which a user's experience is affected by shifting layout can vary based on various factors, but I don't see any reason to assume that anonymous readers choosing a wide view would be more technical (beyond being able to follow instructions to change a setting), or more tolerant of layout transformations post-load. isaacl (talk) 15:48, 29 September 2022 (UTC)[reply]
My understanding of the diffs is that they can't do a CSS toggle for logged out users because they serve logged out users cached snapshots. (So it requires doubling the cache, which, tho expensive [millions?], the WMF can easily afford, but that's beyond what these WMF staffers can accomplish. For them, out-of-budget = "impossible"), as someone said in response to SOY elsewhere on this page. Levivich (talk) 20:45, 30 September 2022 (UTC)[reply]
Most everything is doable—it's just a question of how much it will cost in terms of resources, and the opportunity cost of not being able to use those resources elsewhere. If we're going to introduce a feature that requires re-engineering the caching servers, is one that largely benefits anonymous editors (versus readers) top priority? isaacl (talk) 23:52, 30 September 2022 (UTC)[reply]
Isaacl, Enterprisey Let's please be clear that 'doable' here means 'much easier than doubling the cache'. And since encouraging readers to create accounts is by and large a good thing (multiple reasons), I'd even prefer to see the "logged-out width toggle" set the pref while walking the reader through a single-popup account-creation, then taking them back to the page they had been reading. Now rather than driving away the small % of readers who won't like the switch, we're taking advantage of the change to get them accounts. – SJ +18:59, 6 October 2022 (UTC)[reply]
Sure, I didn't say anything about doubling the cache. Everything has its costs, and opportunity costs to account for. Your suggestion touches on an area I'd prefer to be worked on: ways to encourage anonymous users to create accounts, whereby they can do their configuration in the same way as everyone else. isaacl (talk) 20:49, 6 October 2022 (UTC)[reply]
Comment - As proposed is the toggle persistent, or would logged-out readers need to press it every time they want to view an article in Vector Legacy? BilledMammal (talk) 13:19, 25 September 2022 (UTC)[reply]
Support with reservations a phased approach like this may be more platable even if it takes longer for registered editors switch over. This would be similar to the introduction of Visual Editor to new users. However, should there be also a persistent toggle for non-logged in users if they want to switch back to Vector 2010? Unlike this proposal, Visual Editor isn't forced down on non-logged in users. (That is if the 'text width' here is referring to the Vector 2022 wide width gadget, and not switching between 2022 and 2010. Sorry for the confusion if so.) – robertsky (talk) 14:28, 26 September 2022 (UTC)[reply]
Support - equal first choice. The text-width toggle is a good idea for everyone on every skin no matter what happens, I hope that feature is added. This phased-deployment plan also makes sense. Levivich (talk) 17:00, 26 September 2022 (UTC)[reply]
Support - While I've already voted in support of the primary RFC, I would support this proposal (which sadly seems to have gone mostly unnoticed) in equal measure as it seems to address the majority of complaints. ThadeusOfNazereth(he/they)Talk to Me!17:43, 26 September 2022 (UTC)[reply]
Support (already voted in support of Vector 2022 as proposed, but this is a good compromise - in a few months we'll know who uses which setting and where). I've checked the withgadget=wide-vector-2022 page and I find (by changing the window width) a 100 character line most comfortable in the lead with an infobox, which gives about 140 character line in paragraphs with no side graphics (still OK for casual reading). For me, on a 3200px 13" laptop screen, the problem with limited text line width is not the text(-only) width by itself, it's the fact that most of the width is taken up by our ever-growing infoboxes, navboxes and pictures. On pages with too many pics it actually helps to have a narrower text width so the pictures appear where they've been inserted and do not push one another to where they don't belong. Ponor (talk) 03:22, 27 September 2022 (UTC)[reply]
Support if this was an option. I believe that the designers are probably correct about the suitability of the fixed-width for Wikipedia readers, but I think this is one of those cases where making it easy to change would be harmless and preferred by a lot of members. JackWilfred (talk) 11:11, 27 September 2022 (UTC)[reply]
I have mixed feelings. This is better than simply making 2022 the default, but I think it's a problem to expect readers to deal with opting out of or in to something. --Tryptofish (talk) 19:17, 28 September 2022 (UTC)[reply]
Conditional support only if WMF also sets it up so that statistics are available for who clicked the toggle, and acts accordingly. --Rschen775405:29, 29 September 2022 (UTC)[reply]
Support This seems like a reasonable compromise, provided there's also some metrics gathered so that future direction becomes clearer. GoPats (talk) 13:20, 29 September 2022 (UTC)[reply]
Strong oppose Gradual deployment does not resolve the fundamental flaws and there should not be any fixed width at all.Tvx1 11:50, 1 October 2022 (UTC)[reply]
Support in the interest of making some progress, per all of the reasons I support Vector (2022) as the default for all. — Bilorv (talk) 15:36, 2 October 2022 (UTC)[reply]
Support; also want "switch to old/new look", to distinguish between the width issue versus other reasons for preferring old Vector. But reading the links provided by isaacl above, doing it server-side and scalably appears to be way outside current budget. We should consider whether "flash of narrow text" may be acceptable as Enterprisey suggests, or the possible utility of a per-view (client-side) choice "I want to read this specific page wide, even if it's not persistent across page loads". ⁓ Pelagic ( messages ) 11:42, 4 October 2022 (UTC)[reply]
Cheeky questions about cache layer and anticipated popularity: if Vector 2022 is overwhelmingly preferred by readers, and very few choose the wide or 2010 options, then wouldn't that result in relatively few alternate pages being cached? Or if you choose not to cache them (per cscott), wouldn't the performance hit be equivalent to the same number of readers registering for accounts so that they can change their preference? If you're wrong about the popularity of the new look, would you have to emergency-yank the choice before the servers are brought to their knees? ⁓ Pelagic ( messages ) 11:42, 4 October 2022 (UTC)[reply]
I'd like a commitment that the WMF will provide maintenance for the core V22 customisation gadgets/scripts (width, TOC positioning, etc) if the volunteer creators are unable to do so, including ensuring that they continue to work with future V22 changes. While the mediawiki documentation speaks of wanting a more consistent experience between readers and editors, I simply believe that's not going to happen. Our uses are just so different. So ultimately V22 needs to be able to handle both - and that agreement needs to be provided prior to becoming the status quo for readers because it'll be almost impossible to get afterwards. Nosebagbear (talk) 17:45, 22 September 2022 (UTC)[reply]
Yeah, I've seen the consistent experience argument somewhere already and I agree that it's impossible. Try sitting in front of your laptop/PC and then holding your phone close enough to your face that it occupies the same field of view as your computer screen. Consider also that many people do most of their phone browsing on portrait mode. Anything that looks perfect on that FOV will not work on a desktop screen and vice versa. DaßWölf02:20, 23 September 2022 (UTC)[reply]
@Nosebagbear thank you for bringing this up. Gadgets are currently under the ownership of the community and the gadget creators. However, we can commit to ensuring continuous support in the future. Specifically we commit to:
Working in collaboration with gadget creators or other interested developers to fix gadgets by providing support and guidance. This could include anything from advising on why a certain gadget does not work to providing specific code snippets as fix suggestions
Proposing alternative solutions where possible. While the WMF cannot take ownership of gadgets directly, in some cases we can recreate the gadget functionality and take over the ownership of the code, promoting it from a gadget to a feature
Proposing ideas for necessary gadgets or building new gadgets based on the needs of the communities
Creating new stable APIs to meet gadget developers needs for long term future-proofed code
One of the main issues I worry about, ironically, is accessibility of the link colours. These were changed to improve accessibility. I've changed the visited link colour in my CSS because I struggled to read them, especially on my watchlist. Given I have good eyesight, I worry about this being a wider issue. The colour can be made a tad bit more dark without failing the WCAG AA accessibility with the black prose (see phab:T213778), but that colour is still too light for me. If this is a problem more people experience, that would be a reason to oppose for me. Femke (talk) 18:50, 22 September 2022 (UTC)[reply]
I see this too, I notice that especially purple links are significantly more distracting than they used to be and text with a lot of links feels a bit harder to read than it was with a darker link color. The contrast ratio of purple links to the page background is 5.26:1 which fails WCAG AAA on 18px font size, and Wikipedia uses an even smaller 14px font size where contrast matters even more. Blue links are similar, with a 5.36:1 contrast ratio. pfg0006:19, 26 September 2022 (UTC)[reply]
Has there been any discussion about using the currently-empty right column to house floating infoboxes instead? I'd be keen to read that back-and-forth, if so. Thanks, — Fourthords | =Λ= |20:20, 22 September 2022 (UTC)[reply]
There are some older prototypes pre-V22 development that played around with moving images, infoboxes, and other floating content at high width into those spaces, and the "responsive Vector" gadget available today also does that depending on width. Izno (talk) 20:26, 22 September 2022 (UTC)[reply]
Oh, that's pretty brilliant (if a little glitchy at the moment)! Incorporating those floating ideas (especially the infobox) into this new idea would be pretty great. Thanks for the heads-up! — Fourthords | =Λ= |19:05, 23 September 2022 (UTC)[reply]
@Fourthords - in the future, we're hoping to use this as flexible space that can be configurable to hold different things. Most of the current conversations have been around tools - page tools, gadgets like twinkle, languages, etc, although it would be interesting to collaborate with the community on placing content in that space as well. We're currently building out the ability to pin all the page tools in the right sidebar and hope to continue to make more menus pinable as well. You can view the prototype of that here: https://vector-2022.web.app/Moth. This will be available on the new skin in about a month or so. Here's a screenshot: Vector 2022 with article tools pinnedOVasileva (WMF) (talk) 20:29, 22 September 2022 (UTC)[reply]
@Daß, Wikipedia having ads would go against a core principle of being not-for-profit and keeping information free and accessible. That's why they ask for donations. Hell, Amazon donated a million $1 million. If you look up articles on Wikipedia and their donations. Giving is up substantially compared to when they first started. They are not struggling even with the staff they have to pay. But operating still comes with a cost. Mr. C.C.Hey yo!I didn't do it!21:22, 26 September 2022 (UTC)[reply]
Right, and that’s obvious to us, but many readers don’t know about Wikipedia’s nonprofit governing structure, they just click on it because it’s the top result on Google. Other websites have trained readers into thinking that white space on the site will get filled by ads. —pythoncoder (talk | contribs) 14:39, 27 September 2022 (UTC)[reply]
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]
@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.
The main plus for me there would be dark mode. If dark mode really is only possible with narrow text, then personally I'd stick with legacy Vector and the current dark-mode gadget. Certes (talk) 22:29, 22 September 2022 (UTC)[reply]
I was going to reply to Certes about collecting user data because I was thinking about the difficulty of getting enwiki readers to try the skin out for a period of time since they'd have to get an account. I then remembered about the early adopter wikis. Are there any stats or any sort of reader feedback collected from those wikis about what the readers think about them? —Danre98(talk^contribs)01:56, 23 September 2022 (UTC)[reply]
I would really wonder about what those stats would actually mean, even if we do have them - for the longest time I just thought fr-wiki looked awful and was harder to read and there was nothing I could do about it. I didn't realize that it could be avoided by making an account, logging in, and changing my preferences to return to the old version. I don't claim to be some kind of "most typical" reader or anything, but surely this has happened to others as well. -- asilvering (talk) 03:11, 23 September 2022 (UTC)[reply]
@Danre89 Well if 87% of active editors (not even normal readers) just like on pilot wikis you have kept Vector 2022 instead of opting out of it, I think it's pretty clear that those who did not opt out decided Vector 2022 was better. Furthermore, A/B tests have shown that the user experience for normal readers is significantly more engaging, which should also be clear evidence that readers are enjoying Vector 2022 more as a user experience. Lectrician1 (talk) 14:51, 23 September 2022 (UTC)[reply]
Lectrician: I think it's pretty clear that those who did not opt out decided Vector 2022 was better...
This is the same "silent majority" argument promoted back in the days of Richard Nixon. No evidence. Just an assumption that neutrals are happy. Yet, somehow, those who "resist change" are described as having "inertia". Hmm, could it be that those who accept a new default are also experiencing inertia because the hassle of changing back isn't worth the effort? That sounds like compliance to me, not approval. Martindo (talk) 01:15, 25 September 2022 (UTC)[reply]
@Lectrician1: Sorry, I didn't get the ping because the Danre89 account is a doppelganger sock. Anywho, Martindo does raise a good point above. Though 87% is a high number, there's lots of people that don't care to change default settings in general (even if it's easy; people can be lazy at times). In addition, the stat doesn't tell how active those editors are (assuming more active editors are more likely to care about a skin change). I do think that stat shows that the skin's reception would at worst be lukewarm overall if deployed here. —Danre98(talk^contribs)02:09, 26 September 2022 (UTC)[reply]
@Danre98 If they were used to Vector 2012 and they wanted to switch back because they found Vector 2022 annoying, then they would most definitely look for some way to switch back (especially given the attitudes of editors displayed here that are not okay with Vector 2022). The switch back button was actually so visible because it was bolded that I found it annoying and I looked for a way to get rid of it. Lectrician1 (talk) 12:22, 26 September 2022 (UTC)[reply]
Also, I don't want to keep on going back and forth about this. It's a past statistical run that seems to demonstrate clear results but clearly you think otherwise. This is why I recommended running an A/B test on enwiki itself for all users to demonstrate whether Vector 2022 has engagement advantages for enwiki and a higher retention rate than Vector 2012. Lectrician1 (talk) 12:26, 26 September 2022 (UTC)[reply]
@Lectrician1: I see you reply and say that if they wanted to switch back because they found it annoying they would click on the button, which is true. However, my question was about the neutrals, not about the people that oppose the change and actively want to switch back because they find it annoying. My point, and I guess Martindo's point above, is that neutrals (including neutral-ish editors) and supports are grouped together in the not-changed-default category. It should not be assumed that those neutrals (who don't care to click the link because they don't care much one way of the other) support the change. Though in my opinion it is indicative of a certain level of support, it should not be taken to mean that there is 80%ish support (or a similar level of support) for the new skin on the early adopter wikis (also see Egsan bacon's oppose for other reasons why those 87% shouldn't be taken to mean 87% support). —Danre98(talk^contribs)20:11, 26 September 2022 (UTC)[reply]
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]
The temptation is very understandable — I can only imagine how frustrating it is to work on a project for two years and then have it rejected out of hand because someone can't be bothered to read about it — but yes, I do get that sense. @OVasileva (WMF) @SGrabarczuk (WMF) @AHollender (WMF), part of how we're able to have norms expecting editors to read discussions is by also having norms about conciseness, including not repeating arguments you've made elsewhere. When someone makes a point you feel you've responded to elsewhere, it's always better to link to that comment/page than to restate yourself. {{u|Sdkb}}talk17:00, 24 September 2022 (UTC)[reply]
The old colours also posed an accessibility issue, as the visited link colour was almost indistinguishable from normal text for some (see phab:T213778)
It just goes to show how stubbornly resistant to change most English Wikipedians are, combined with suspicion of the WMF. Of course the plurality of people, on literally their very first use, said they felt more comfortable using the current skin! They’ve been using it for a decade - we all have! Of course the WMF is pushing us to adopt this - they’ve been working hard on it for 3 years! It’s disheartening to see our response, when it is perfectly clear that a) the WMF has committed to only implementing this if we choose it and b) any individual user can and will be able to use whatever skin they want. Nothing big ever seems to change here, no matter how slowly the change is pushed, unless it changes towards further inaction and bureaucracy. —Ganesha811 (talk) 01:44, 23 September 2022 (UTC)[reply]
the WMF has committed to only implementing this if we choose it
OK, let's put aside that "we" means "handful of frequent users/editors" currently participating in the RfC.
What do you mean "choose"? If it's implemented as default, that's a limitation on choice.
Personally, I'd be neutral if this was not being presented as a default (and if it was more transparent and/or thorough in terms of other aspects, such as worldwide usability). Martindo (talk) 09:50, 26 September 2022 (UTC)[reply]
Looking at the screenshots, I can see where the links to Wikidata/Commons/etc. are when logged in, which looks OK (basically no change). However, they don't seem to appear in the logged out view, which is bad since it re-enforces the idea that there's just Wikipedia, without the sister projects? Readers should be able to access Commons etc. as easily as editors can. Thanks. Mike Peel (talk) 07:11, 23 September 2022 (UTC)[reply]
This is not a one-shot project, and we will continue working on the Vector 2022 skin. First, we will be working on the page tools feature, to be completed in October/November 2022. Then, we will collaborate with the Growth and Editing teams on making it easier to learn about how the wikis work and begin editing. For more details, see the sub-page.
Minor things I don't like after a day (not width-related): not obvious what the top-left button does, tooltips are not great like "Discuss improvements to the content page" and "The list of pages you are monitoring for changes" for talk page and watchlist, hard to see tab selections, icons rather than text at top-right, extra click to get to own talk page and contributions, different between visited/unvisited links is too subtle for my eyes. I realise this is very much from the point of view of an editor though. I'd also recommend any future RFC is less biased in how it's set up. -Kj cheetham (talk) 17:40, 23 September 2022 (UTC)[reply]
Thank you to the WMF team for your patience answering everyone's questions. Since visual accessibility has been brought up several times as a point in favour of the new skin, can I ask if there is any accessibility-based reason for the lack of any border whatsoever between the ToC and the main article text in the new Vector skin? It's exactly the same colour background as the scrolling portion of the article (white), and no border line divides the ToC text from the article text either. It seems a strange choice, especially since the logged-in 2022 Vector does have a boundary box around the left-hand menu links. -- asilvering (talk) 23:36, 23 September 2022 (UTC)[reply]
Some comments - I think the direction this skin is going in is good, but two things concern me and prevent me from supporting the change at this time: the large amount of white space (both the "white" and the "space") and lack of separation between elements (such as separating the header from the body, sidebar from the body, etc.). Don't get me wrong, this skin is a step up in readability, as I fully agree with the limited width (that's a big reason why I use Timeless, so that the lines are shorter), but it just looks bad, in my opinion. I'm no web design whiz, but I played around with the CSS and found that I liked the look much better simply by adding some borders around elements and adding a gray background to the margins at the side. I'd also be supporting with the assumption that a good dark mode is on the way (the current one I enabled in Gadgets is unusable imo edit: I hadn't tried the widget on Vector 2022, oops. It looks fine on the new skin); not just for registered users, dark mode is a fairly ubiquitous feature on the web at this point and many unregistered would use it if they saw a button for it. To reiterate, this skin works functionally but still looks ugly, in my opinion. I wholly support limiting the page width for readability, although perhaps the limitation could be relaxed a bit. ~Bluecrystal004 (talk · contribs)01:20, 24 September 2022 (UTC)[reply]
A follow-up before I go to sleep: I looked at a "prototype" version linked elsewhere in this RFC, and would immediately !vote support if option 9, 6, or 5 were adopted (in descending order of quality). They look good! ~Bluecrystal004 (talk · contribs)04:54, 24 September 2022 (UTC)[reply]
Small point, but I confess I don't understand the rationale for changing the "watchlist" link to a mysterious icon; it would be better to replace the current "alerts" and "notices" icons with those words. Icons have utility in contexts where a common language can't be assumed, but that is not the case with en.wikipedia. I assume that putting the other topline links into a pulldown menu is to save space, but I think this is also misguided. JBritnell (talk)
A tad off topic. But why are editors putting Support or Oppose or (though not yet) Neutral, at the beginning of their stated positions? You've already placed your posts in the so-named subsections, so you don't need to clarify your position. GoodDay (talk) 13:57, 26 September 2022 (UTC)[reply]
I see "best practice" mentioned a lot in response to content width and other elements. But I can't quite agree that it's "best practice" and not just "practice". So let me cynically look at the examples -- websites like The New York Times, Reddit, Medium, YouTube, etc. These are for-profit ad-driven opinion-inciting media sites. Of course they want to maximize content consumption. Of course they want to remove any UI elements that interfere with content delivery. Of course they want to maximum ad space and focus your attention onto it. Of course their deciding factor is "how fast and easy can we move the reader along". These websites are not designed for serving information. They are designed for serving ads. They are designed for instant gratification with easy-to-read text, simple language, colorful images and videos, invisible UI elements, all the responsive fluid UX to lull the reader into endless cycle of scrolling. Their mobile and desktop versions are homogenous to maximize familiarity. So of course these companies brag about their "better user experience" when their metrics are user retention and ads-per-minute. I wasn't going to write this lengthy complaint of modern web design, but then I saw A.H. mention they had adblock enabled. :) This was just too perfect of an example of how these websites have become "the new normal" in a way that no one asked. Users have to resort to tools like adblockers and privacy shields just to make websites usable, but somehow these same websites are also a good example of content presentation? I'm sure WMF/Wikipedia has some goals in parallel, but has anyone asked if a non-profit encyclopedia has the same priorities? Is the point to be like everyone else by maximizing metrics? Is the yardstick for "best practice" really websites that are nothing like an encyclopedia? — HELLKNOWZ∣TALK12:10, 23 September 2022 (UTC)[reply]
In the case of the NY Times, it's worth considering where they came from. Newspapers are traditionally a narrow-column format. Compared to that history, the layout they're using now is a radical improvement. I've been reading the NY Times on-line since they first went digital (and the dead-tree edition for a long time before that). They've made a few big layout changes over the years. The early versions of the site were a traditional newspaper layout, with a strict boxes-in-columns design. Every time they've done an overhaul, it's been to move further away from the old constraints and embracing more of the freedom current technology makes available. It's been a slow and cautious evolution because the old ways die hard, but it's also always been moving forward. Going to a fixed-width format is a huge step backwards. -- RoySmith(talk)15:33, 23 September 2022 (UTC)[reply]
I think best practices are established by research. I've referenced other websites to give examples of how ubiquitous the implementation of these best practices are. I am sorry if I've confused the point by referencing for-profit websites. AHollender (WMF) (talk) 16:26, 23 September 2022 (UTC)[reply]
I think in the Internet dominated by giant media corporations dictating UX design, these websites have no choice but to follow or be excluded. Serve people what is already familiar. So when you ask experts or look at market trends, you will obviously see whatever trend the trendsetters set. It might be compliant to some list of design choices, but all combined it's the safest blandest design-by-committee mixture for the lowest common denominator. Thus I object to considering it "best" practice. It's just minmaxing user engagement with quantity over quality. — HELLKNOWZ∣TALK17:40, 23 September 2022 (UTC)[reply]
@Hellknowz Even if this preference is the result of trends in UX design, wouldn't it be better to provide the user with a similar experience as they have on other sites and are used to navigating than deviate from it? As an analogy, you wouldn't want website that looks the same as a phone app. People like conformity in design on the platforms they use. Wikipedia should use the facts of research and modern standards of design so that it continues to be a site people are comfortable with and want to go to. Lectrician1 (talk) 21:22, 23 September 2022 (UTC)[reply]
@Hellknowz can you clarify what would qualify as a best-practice in your opinion? As far as I know the Web Content Accessibility Guidelines are the most well know, and well respected guidelines regarding web design (they are what we, ourselves, cite in WP:Acessibility). The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that: "in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)". Is that satisfactory?
Additionally, if you could provide any research (or even examples of websites), demonstrating that 200–300+ characters per line are optimal for reading, that would be very much appreciated and helpful in this discussion. AHollender (WMF) (talk) 20:46, 27 September 2022 (UTC)[reply]
Not sure where best to put this comment, so here it is anyway. From personal experience, I like a narrower page width for ease of reading, and a reasonable default font size. A very wide page makes it difficult to find the start of the next line, and yes, my vision is failing and it is getting harder to focus. Some other people also have this problem. For editing I like the edit window to contain as much as reasonably possible so I don't have to scroll so much to see what else is in the section I am editing, but I also don't want to have to scroll to get the to the toolbars above and below the edit window, and I really don't want to have to scroll sideways, so for editing I prefer not to waste whitespace at all. For reading, whitespace down the sides is not a problem. It might be interesting to get a survey on visual acuity versus text width preferences. Having an option to toggle between fixed width and filling the page seems a reasonable compromise if technically practicable. I have no objection to scrolling when reading. · · · Peter Southwood(talk): 12:09, 28 September 2022 (UTC)[reply]
About privacy, does Vector 2022 have tracking pixels, work well with TOR (letterboxing etc), or make it harder to [[11]]?
I ask as the WMF foundation:Cookie statement advises that WMF "actively collects some types of information with a variety of commonly-used technologies. These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage." Wakelamp d[@-@]b (talk) 04:55, 4 October 2022 (UTC)[reply]
@AHollender (WMF): I don't wish to bog down the discussion with my own opinions, but I can elaborate, sure. I suppose thanks for even paying attention to my rant (I know I could have written it as actual feedback instead). Firstly, I should clarify that I am not talking just or specifically about fixed width. I mentioned the content width concern because it is the one most-commonly mentioned by others, which consequently means you replied to it the most with the "best practice" responses (if you pardon my crude summary of your answers). But I did say "and other UI elements". I didn't say "best practice for text width". In fact, among my rant on websites, I do list a lot of UX choices: instant gratification, easy-to-read text, simple language, colorful images and videos, invisible UI elements, responsive fluid UX, removal of UI elements, mobile and desktop homogeneity, and of course ads serving as center pieces to the detriment of all other elements. This isn't an exhaustive list by any means (for example, clickbait), but those are the parallels to V22 that stand out. In fact, I don't even specifically mention fixed width and simply bundle it together with what is best summarized as RoySmith's "newspaper column" example - something literally designed to be read/scanned fast.
Now, I am reiterating all of this to make it clear I'm not talking just about fixed width. I would say fixed width is may be 10% of my concerns. I even avoided making any concrete examples because that'll just distract from the main point. My concern--specifically what I believe to be a root cause of the UX problems--is the assumptions made about the "best practices". It seems to me that because websites are compliant to stuff like WCAG and they all look the same, then these websites must be automatically placed under the best practice umbrella. Grossly simplifying, The New York Times has WCAG 1.4.8 compliant text, therefore NYT is doing best practices. But there are a lot of UX elements and choices and the vast majority are not covered by WCAG. The vast majority of their design decisions are based on heavily-guarded analytics specific to their business model. Some compliance rules necessarily overlap with usability and thus user engagement gives "best practices" even more "authenticity". So I know why websites like NYT are doing what they are doing - to sum up my rant more objectively: they are a business and they make money from ads (and subscriptions/products), which are shown by analytics to be most efficient under their current design. I know why every other website is following the same trend - they need to look familiar to the "big boys" to acquire and retain their users. I'm going to don my cynical hat again, but if these websites could make higher profits (gain more users) without WCAG compliance and if they could get away with the backlash, then I'm sure most would catapult that WCAG into the stratosphere. (I don't need to look further for an example than US websites simply blocking EU visitors rather than be compliant to GDPR.)
In short, I disagree that modern web is a benchmark for best practices. Some elements are, but certainly not anything close to how V22 appears to be an "average of the web". V22 follows WCAG and that's good. But, as far as I can tell, the rest of design choices for V22 are essentially "because everyone else is doing it". And "everyone else" seems to be websites that are not encyclopedias and are in fact for-profit businesses with very specific content churning goals. "Medium gets clicks, so we should look like Medium." And I do apologize for belittling and dismissing what is basically years of work and not even providing any actual concrete examples. I work with UI and design myself and I know how useless "I don't like anything" feedback is. Hopefully, I can communicate the larger concern that I believe the "best practices" seems to have included not just the good parts of compliance and usability, but then also vacuumed up all the bad and useless ones too.
I'm sorry if I can't explain this better. I started writing something that would have concrete examples but it just turned into a point-by-point rant every time. Full-width text is evidently the most polarizing issue, which is in itself tragicomic. So read the rest at your own risk. :) My overall sentiment is that it's so bland there's nothing wrong. Nothing could be wrong because it doesn't attempt to do or be anything. It's the most watered-down version it could be. And what can you really say about water? If you give me water, well, it's water. I could tell you lots of things if you gave me some chicken soup or may be a beer. Hell, if you gave me some Baltic porter, we'd both know what the intent was. We could discuss all sorts of finer points of bike sheds imperial stouts. But all we have is water. It's perfectly compliant to be used by everyone everywhere at all times for all purposes with no additives or modifications with no risks or exceptions. Can I provide a better practice that that? No, of course not. How can I provide examples of better water? All research says water is good for you. Look at all these companies selling water. We even have water as public utility. Clearly, the only option is water. — HELLKNOWZ∣TALK13:08, 28 September 2022 (UTC)[reply]
@Hellknowz, no, I don't think it's the "big boys" — it's hundreds of years of fine typesetting: that's why we rarely print or write in landscape (and why we distinguish portrait and landscape to begin with); check your books and see how many characters per line they have (any ads?), check stackexchange.com (no ads!) and you'll find a 100 character line, no one complaining; the Typographers’ Bible is typeset at approx. 65 cpl. These are all professional standards, set long before our times. Ponor (talk) 13:31, 28 September 2022 (UTC)[reply]
So you can have your own opinion about design and layout, but arguing that industry-wide best practices are not best practices is like arguing against science. These best practices are the product of research, the application of the scientific method, and it's been studied, by scientists and other professionals, for like 100 years (probably longer). It's not just the collection of some people's opinions... it's based on research, not opinion.
"everyone else" seems to be websites that are not encyclopedias and are in fact for-profit businesses is not accurate and has been addressed multiple times in this discussion. Have you looked at britannica.com, science.org, nature.com? They all use white space, limited width, sticky navigation, etc. Levivich (talk) 16:56, 28 September 2022 (UTC)[reply]
Autism spectrum causes some additional UX issues (Caveat "If you know a person with autism, you know one person with autism."). This table from here is a summary, but more details
Reluctance to change. Often due to a very rational personal cost/benefit/risk calculation.
Preference for Function over form. Using Linux an example "The command line trades away discoverability, in exchange for efficiency and flexibility" [4]. Able to cope with far more static information than normal. BUT people become power users/editors because of the discoverability, (for instance, all the js we add as menus, would highly interest some potential editors if it was viewable to all, and greyed out), but WMF must cope with Power users/Editors and minimalists/readers[5] YMMV Wakelamp d[@-@]b (talk) 10:39, 13 October 2022 (UTC)[reply]
It sounds like many of you are supportive of the change except for the concerns around the width of the text. Specifically, we're hearing that many Wikipedians would like for this to be a preference, rather than use the existing gadget. To make this easier, we will begin exploring building a preference for logged-in users. Our team will review this request and add some details on what this might look like early next week.
In general, we believe that limiting the width of the text is crucial in order to improve the reading experience on the site for our readers and editors. In our initial research for the project, we learned that many readers had difficulties with the site because there was too much information density on the page. This confirmed many of the learnings we had seen from across other websites and best practices for design. There is longstanding research that is clear regarding the optimal line-length for text. If you look around the internet at popular content websites – e.g. ProPublica, BBC, Snopes, AVClub, BBC, The Lancet, Reddit, The World Health Organization, Baidu, Medium – you will find they all have width limitations on the content. We've put together this FAQ to add some detail:
Why have you replaced the area used for content by an empty space?
Reading efficiently and comfortably is crucial to most people using our projects. Our goal here is to improve the readability of the content. There are several factors that affect it – i.e. font size, contrast, font, line length, and empty space.
Shorter lines
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.
The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that, in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)." (edited 18:56, 23 September 2022)
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 ProPublica, 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.
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.
@SGrabarczuk (WMF) with respect, this feels like a re-iteration of the points that were already present above, on the FAQ page, and over on mediawiki's pages on V22 (with the exception of the built-in width bit, which is good). But it doesn't answer the issues of articles currently with wide tables, or those with photos on both sides, or with the current wide-2022 gadget not returning the width to that of Vector2010 (on my particular laptop, it's about 3cm of difference). Nosebagbear (talk) 23:09, 22 September 2022 (UTC)[reply]
I'm a great fan of the wide gadget, and while I've already !voted support, I think this discussion would be trending differently if this was the default. Anarchyte (talk) 07:10, 23 September 2022 (UTC)[reply]
@Anarchyte I suppose we could force that gadget on for editors or even readers, but I don't think the dev team would like that very much - and for readers that never intend to edit it might not be a good idea. If we forced it on for editors, they could manually opt-out. I think getting a full-width toggle option built in to the skin would be an immensely better way to deal with it though. — xaosfluxTalk12:33, 23 September 2022 (UTC)[reply]
Good point. Perhaps a cookie-based setting so that unregistered users can also adjust the width if they want. A toggle somewhere on every page would be much better than forcing readers to register to access Special:Preferences. Anarchyte (talk) 10:04, 24 September 2022 (UTC)[reply]
That rather depends on whether readers could find the option at a glance and recognise it for what it is. Reading the discussion in this RfC today I found out that Fandom has a full-width option, and, having an idea of what I was looking for, I figured out how to switch it on in less than a minute. Unfortunately for them, I had already stopped visiting fandom.com in favour of a 3rd party reader. DaßWölf18:59, 24 September 2022 (UTC)[reply]
I would like to say that the reason I don't see anyone complaining about the whitespace in, say Google Docs, is because it doesn't look like something's supposed to be there. On Wikipedia that's not what it looks like with Vector 2022, it looks like there's stuff that's supposed to be there and yet it's empty. ― Blaze WolfTalkBlaze Wolf#654513:18, 23 September 2022 (UTC)[reply]
@Blaze Wolf, you can't compare Wikipedia to Google Docs in terms of design. That would be like comparing Twitter and Facebook in terms of design. Two separate sites that do their own thing. Even though I rarely click on the side contents beside the article, it's useful to have them there in case I need to. Mr. C.C.Hey yo!I didn't do it!17:23, 25 September 2022 (UTC)[reply]
@Mr. C.C.: I'm not the one who did. The WMF did. "The overwhelming number of major websites have similar limitations on content width. For example: academic journals like Nature, news websites like ProPublica, government and intergovernmental websites like the United Nations, academic documents like LaTeX, and word processors like Google Docs and Etherpad." (emphais added) ― Blaze WolfTalkBlaze Wolf#654518:38, 25 September 2022 (UTC)[reply]
@Blaze Wolf, I didn't see that. Thanks for pointing that out. UN: It has a lot less white space then Vector 2022. A lot of news media sites have white space. A percentage of them are riddled with ads too. (Not just on white space either). Wikipedia doesn't have to be like every other site out there. They don't need to compare themselves to other sites. That's like using WP:OTHER in various arguments ala deletion discussions. Even though you can use it in certain instances, you should generally avoid that argument. What other sites do for their design has no bearing on what Wikipedia does since. If it did, holding an RfC for this wouldn't exist thus making a core point of Wikipedia, in terms of users/editors, redundant. Mr. C.C.Hey yo!I didn't do it!19:33, 25 September 2022 (UTC)[reply]
Are there any opinions or study on whether a narrow centered paragraph is easier to read than if it is left or right aligned? — hako9 (talk) 13:41, 23 September 2022 (UTC)[reply]
This argument would be much more convincing if it were supported by empirical evidence. (No, examples of other websites is not evidence that these arguments are true; they are merely evidence that other websites impose this limitation, a decision that could have been made for many reasons.) ElKevbo (talk) 14:39, 23 September 2022 (UTC)[reply]
@ElKevbo, not sure if you saw my comment above so re-posting here: thankfully there is plenty of empirical research [EDIT: updated thanks to the help of others]:
Optimal Line Length in Reading - A Literature Review (2005), from the peer reviewed journal Visible Language -- "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)".
The influence of reading speed and line length on the effectiveness of reading from screen (2001), from International Journal of Human-Computer Studies -- "A line length of 55 cpl appears to support e!ective reading in terms of both rate and comprehension. However, as the line lengths used in this study were spread across a wide range, there may be a more optimal setting than this. By varying the range and extremes of line lengths in future research, it may be possible to more precisely identify an optimal format and to explore the relative contributions of mechanical and cognitive factors."
Shorter Lines Facilitate Reading in Those Who Struggle ( 2013), from PLOS One -- "short lines reduce the number of regressions, and generally improve reading speed and comprehension, simply by reducing the probability that crowded text in locations previously fixated can be perceived."
The Effects of Line Length on Children and Adults' Online Reading Performance (2002), from Software Usability Research Laboratory (SURL) at Wichita State University -- "This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl)".
The Effects of Line Length on Children and Adults' Perceived and Actual Online Reading Performance (2003), from Proceedings of the Human Factors and Ergonomics Society Annual Meeting -- "No differences were found for either reading time or efficiency for either adults or children. However, adults preferred shorter line lengths to full-screen line lengths." and "The narrowest line length condition was perceived as promoting the highest amount of reader concentration, while the medium line-length condition was considered to be the most optimally presented length for reading."
Reading Online Text: A Comparison of Four White Space Layouts (2004), unclear if this was peer reviewed -- "Results from this study showed that the manipulation of the Margin white space affected both reading speed and comprehension; participants read the Margin text slower, but comprehended more than the No Margin text. In general, the results favored the use of Margins."
Please note: the range of line-lengths studied is somewhat narrow. Some of the research shows certain positive effects of longer line lengths, but those line lengths are significantly less than what results from the maximum width we have in place in Vector 2022. In other words, even with Vector 2022 we are well beyond the maximum recommended range of any of the studies.
@AHollender (WMF): I know I'm not ElKevbo however, the only thing I like about the reduced width is that it reduces eye strain. I see that as a positive of the reduced width. However I feel that the blank space should at least be filled with something that isn't distracting (it being the same color as everything else makes it look like there's stuff meant to be there). Also, while I have seen someone who's normally anon compliment the new TOC, I find it kinda clunky to use since if I close it to increase the viewing space, I have to click the button to open it back up and scroll down (if the section is lower in the article) and then click the section. With the current table of contents I'm able to just go to the TOC and click on where I want it to take me, rather than having to go into a separate "menu". ― Blaze WolfTalkBlaze Wolf#654515:31, 23 September 2022 (UTC)[reply]
Thanks for your note @Blaze Wolf. I'm glad you see the benefits of the reduced width, I also find it easier to read. And I tend to agree with you. So: for logged-in people the article tools will soon fill that space (and will optionally be collapsible) — prototype. We can also continue to explore the option of adding a gray background outside of the content area — prototype (select Option 9 in the bottom right-hand panel). AHollender (WMF) (talk) 15:54, 23 September 2022 (UTC)[reply]
@AHollender (WMF): I really like the options for different bgs and borders. It really makes it look much nicer and helps divide up the different content. I'm a little iffy on the article tools filling the space by default since while it does make it easier to access, it also makes the viewing area look really cluttered. I would say a decent alternative would be to turn the tools into small icons on the side of the screen when collapsed, but that might cause confusion as to what button does what. ― Blaze WolfTalkBlaze Wolf#654516:03, 23 September 2022 (UTC)[reply]
@Blaze Wolf @PaulT2022 thanks for your feedback. I realize it's difficult to trust a faceless organization, and people you've never met. But our plan is to continue collaborating with the community and improving the skin. If you check out the project talk page you can see that I'm active every day, talking to people, building new prototypes and mockups based off ideas they have, etc.
Some say the RFC is premature. I think no matter when we ask, no matter how far along the skin is, people will be extremely resistant to change (I myself am resistant to change in aspects of my life). I think if we believe in progress, and believe in the project growing to include newcomers and new features, we have to get over this uncomfortable hump. And yes, of course I am biased and already believe in the approach of progress. But I'm honestly listening to the concerns, taking them into consideration, and trying my best to have a zoomed-out, objective point of view where I consider editors, readers, newcomers, and people who haven't even experienced Wikipedia yet.
@AHollender (WMF) thank you! I appreciate the hard work of everyone involved and the patience dealing with "they didn't ask me" comments. I think a premature RFC is still a good idea to nudge those unhappy with the proposal into thinking hard to how make the design upgrade happen, rather than "having ideas" indefinitely. PaulT2022 (talk) 16:53, 23 September 2022 (UTC)[reply]
@AHollender (WMF): I'm glad to hear that. And I do agree it's difficult to trust a faceless organization, especially one that seems to ignore some complaints (mainly regarding the fundraising banners which I presented my firm opinion on). I actually feel that what was shown in the 2nd prototype could open up way more options for customization which is currently very limited. ― Blaze WolfTalkBlaze Wolf#654518:02, 23 September 2022 (UTC)[reply]
I'm actually a strong Support vote, but I adore (!!!) that Option 9 on the Borders and Backgrounds. It fixes two problems with the V22; a almost distracting amount of white space on very wide monitors (b/c the Option 9 darker color lets you know not to focus on it and makes it less visually interesting); and the current way that on very wide monitors, there is the white background for article, ToC, and (coming soon) article tools, but then it goes to grey randomly at a certain point, which makes it seem like V22 has been poorly designed for wide monitors, when really y'all have been being very intentional. I also really appreciate Option 9 for looking distinct from the massive-whitespace corporate look with the classic Wikipedia grey. Azertygod (talk) 21:38, 23 September 2022 (UTC)[reply]
(in reply to the original comment[12]) AHollender (WMF), I appreciate your goal to build trust, and to that end, I encourage consideration of why there is resistance to what appears to be a significant change characterized as something that "could be helpful to editors when making decisions about page layouts." You have suggested that research be reviewed and have stated "thankfully there is plenty of empirical research" with a list of links. I mentioned above that I am less convinced by the research presented, but I am interested in how this new skin reflects principles of universal design, and have tried to suggest a slower rollout, by first offering this new format as an option. Having this new design be opt-in for now could allow for more feedback to be collected and various concerns to be addressed before implementing the new skin as a default. With regard to the research presented above, I disagree that it is "plenty of empirical research", but would like to highlight that there is a reference to the WAI and W3C Web Content Accessibility Guidelines in one of the links.
The first link is to Peter Orton, (n.d) "Computer text line lengths affect reading and learning", IBM Center for Advanced Learning, which is not peer reviewed and begins by making broad, uncited statements about research related to reading print media, and then describes "two sets of experiments: first a pilot with 16 adult subjects, then a follow up with 114 adult subjects (70 males, 44 females)" using an eye gaze tracking device while they read web material of varying widths. The study is related to designing online learning programs and concludes that additional research is needed.
The next link is to Edward Scott, May 10, 2022, "Readability: The Optimal Line Length", Baymard Institute blog, advertising products for e-commerce platforms. The promotional blog post does include "The Web Accessibility Initiative (WCAG) guideline 1.4.8 states that, in order to be accessible to all users, lines of text should be 80 or fewer characters (or 40 or fewer characters if the text is Chinese, Japanese, or Korean)."
The third link is to Schneps et al., Aug. 5, 2013, "Shorter Lines Facilitate Reading in Those Who Struggle" PLoS ONE, which is peer-reviewed, and focuses on the use of e-readers by people with dyslexia. "Participants were 27 (13 M/14 F) students with lifelong histories of reading struggles." This study notes when it is engaged in speculation and in its conclusion calls for further research.
The fourth link is to Chaparro & Bernard (January 2002) "The Effects of Line Length on Children and Adults' Online Reading Performance" Software Usability Research Laboratory, Wichita State University. It does not appear to be peer-reviewed and is a study based on "Forty participants (20 adults and 20 children)" who volunteered. The experiment does not test layouts similar to Wikipedia articles and does not account for how Wikipedia articles are typically formatted to assist the reader (e.g. TOC at the top to present an overview of the article, sections and subsections to break up long blocks of text, short paragraphs to do the same, and the use of images, tables, etc). The overview of previous studies discusses mixed results, the study produces mixed results, and the conclusion makes a suggestion instead of calling for additional research.
The fifth link is Youngman and Scharff (1998) "Text Width and Margin Width Influences on Readability of GUIs" Presented at SWPA. In this study, "Readability was assessed by twenty-seven participants who scanned text excerpts for hidden target words", and the conclusions include "Given that webpages on the Internet can be resized by the reader, future research should investigate proportionally-sized text widths in addition to the fixed text width and margin space conditions used in this experiment."
I think major changes may be easier to support if they are presented not as supported by a collection of small studies that are mostly not peer reviewed, but instead as reflective of principles of universal design. Details such as the use of icons instead of words in the new skin indicate that universal design may not be central to development, and at least from my view, suggests further evaluation is needed as to whether this new design is reflective of best practices before it is deployed as a default. There seem to be ongoing questions about how to improve reader and editor experience and about how quickly changes should be implemented. Beccaynr (talk) 18:50, 23 September 2022 (UTC) - comment updated to promote readability of the discussion after AHollender (WMF) made substantial changes to their original comment, to which this comment was written as a reply. Beccaynr (talk) 15:58, 28 September 2022 (UTC)[reply]
Thanks for this detailed response @Beccaynr. It's great to see that you're engaged with the research. I appreciate you pointing out the WCAG guideline as well, I find their recommendations are usually well reasoned and useful. I certainly agree that more research is needed. As I was saying in a different thread above, part of what is difficult here is that as far as I have found nobody has studied the kinds of line-lengths many people in this discussion are advocating for. Most studies focus on the 55–100 character per line range. On Legacy Vector, if you are using a large monitor (1920px), you regularly get ~300 characters per line (or more), with a minimum around ~225 (if text is next to an infobox or floated image). The way I've made sense of this is:
Most of the studies I've found, old and new, while not conclusive (as studies rarely are) advocate for shorter line-lengths (and even when they advocate for longer ones, they're still talking about line lengths shorter than we currently have in Vector 2022).
I assume it's meaningful that the studies do not include lengths over ~100 characters per line, but of course I cannot be certain as to why that is
I'm triangulating based on other references (again, maybe flawed, but also somewhat hard to imagine that basically everyone else who does typography in print or on the internet has gotten this wrong).
Until we can conduct more research (specifically for Wikipedia articles, and including line lengths that result in 300+ characters per line), the conclusion I've come to is that we should err on the side of caution, and follow the clues from the existing research, and as you've pointed out the WCAG guidelines. We can always make the text wider if we find that to be beneficial.
May I ask, have you given the limited width a chance for a week or two? I fear that many people are reacting based on their first impressions (and other fears that Wikipedia is simply following trends, or preparing for ads), rather than first taking the time to learn from their own experience. AHollender (WMF) (talk) 19:07, 23 September 2022 (UTC)[reply]
@AHollender (WMF): I would like to says that I think the reason why people are thinking Wikipedia is preparing for ads is because the amount of whitespace mimics the space often used for column ads (I don't know the actual term for ads that are displayed vertically). I don't have a specific example of a website that uses column ads (mainly since I usually use an adblocker) however I do see why people are thinking Wikipedia is preparing for ads. ― Blaze WolfTalkBlaze Wolf#654519:36, 23 September 2022 (UTC)[reply]
@Blaze Wolf, it's not just ads in the white space on the sites. It's ads within articles themselves. "Article continues below this ad." Yes, they have to make money, but putting ads in the article when you're trying to read the article is overkill. Not saying Wikipedia would do that, but ads goes against their core value of having free and accessible information. That's why you see them asking for donations. Amazon has shelled out a $1 million donation. It's not like they are in dire straights or anything. Being a not-for-profit, you rely on donations. Mr. C.C.Hey yo!I didn't do it!20:32, 25 September 2022 (UTC)[reply]
@Mr. C.C. "Not saying Wikipedia would do that, " It's basically what WMF do now with the banner ads. if you don't then when you scroll down you get another guilt banner that takes up 1/2 the screen. The reason it is in English is that WMF found people gave more - The median donation is I think $14, so the end result is that we make the vast majority feel bad (guilt plus reminder of their poverty) so the Middle Class will give more,Wakelamp d[@-@]b (talk) 04:58, 13 October 2022 (UTC)[reply]
@Wakelamp, I rarely see that. Plus, they're asking for donations not an ad. It's not taking up white space on the sides of screens nor are the in the middle of article. Not the same thing at all. Mr. C.C.Hey yo!I didn't do it!06:08, 13 October 2022 (UTC)[reply]
You are welcome, AHollender (WMF), and I am glad you were able to incorporate the WCAG guideline into the FAQ above [13]. I am trying to consider how guidelines interact with what we already do at Wikipedia to support a diverse audience of readers and a diverse community of editors, as well as whether the proposed changes are an improvement and how quickly changes should be made if we do not yet have sufficient data. From my view, Wikipedia in its current default form can be an oasis that promotes a deeper engagement with content, because it is an encyclopedia.
I do not think my own personal preference is as relevant as what is actually best practice, in terms of whatever that means for how Wikipedia presents content and engages its editors. However, I think there is nothing to fear from people with disabilities who have experience with web design that is repellant to their perceptual abilities, or from people concerned about how these changes may undermine the encyclopedic appearance and function of the website. I think erring on the side of caution supports a slower rollout that allows relevant data and feedback to be collected before major changes are imposed by default. Beccaynr (talk) 19:49, 23 September 2022 (UTC)[reply]
AHollender, I've been trying the new skin lately, here (w/ dark mode widget and narrow width) and on fr (their older version). Most of the changes have grown on me. but the lost ability to choose my browser window size is striking, every time. A loss for reading, for research, for browsing user pages and talk pages, for editing. And within that narrower frame, the empty space and loss of functionality in both side panels feels incomplete, like a prototype waiting for the rest of a design to take form. As someone else mentioned above, the fact that nothing has filled those panels in the past two years suggests that the white space will persist unless there's an active contest among people with ideas for making use of it -- similar to discussions many projects have had about how to use their Main Pages.
Beccaynr, I greatly appreciate your comments! Thank you for putting this so clearly. General thoughts in response to a number of things in your dialogue and earlier above:
Editorial decisions about column + page width should not be backed into via skin redesign. If there is no way to separate the technical clean-up and modernization of the skin from major editorial decisions about width, then the underlying decision shouldn't be made in isolation from the editors.
– Practically: We should have a plan for a) how to value and use screen-space, including making use of margins, b) how to preserve the time of editors and layout designers who will have to compensate for the self-imposed limitations of the new skin, and c) how future skin updates can happen more fluidly (without which problems noted may just stay around forever).
– We should be teaching a new generation of community editors + designers to develop and experiment with skins -- a community not exclusive to staff. Skins should be maintainable by (and collaboratively developed by) that community.
Let's take the exploration of reading-experience and associated research more seriously. More work could be done, at larger scale, than has been done so far; we know researchers who might be keen to do it; and we are by far the most-read website with long lines of text in the world. We should honor this by studying it, and not immediately revert to the current-design-cycle mean.
– Encyclopedias and dictionaries have long been an exceptional case: designed in part to pack dense information into the standard view even if they have slimmed down overviews, outlines, and introductions with more whitespace. Britannica combined this approach with large side margins for annotations and often length footnotes, in their later print editions before going digital-only.
– If we aren't reaching out to the best groups in the world to collaborate with us on this, as peers and partners, we've lost the central throughline.
It's true that other online reference works, like online news before them, have honed in on short, bite-sized, narrow-column formats. There are also a lot of other format decisions that we've collectively settled on that differ from almost every other online site (dense in-line links; extensive, granular in-line citations of claims; detailed citation formats; infoboxes and disambiguation papers; banners and hatnotes to denote works in progress; hierarchical categories; shared nav and format templates; a nuanced collaborative style guide). These drew on traditions from scholarly research, law, online hypertext, librarianship. But most broke new ground in clarity, precision, and ease of access, and advanced the state of the art in contextualized knowledge presentation! And notably, in most of these areas we still stand apart, even where our approach is obviously an improvement. So "everyone else is doing it" is a poor indicator indeed.
– People who have been engaged deeply in this work, of structuring and presenting knowledge to others, should be engaged in these elemental decisions about skin and site frameworks. Those design decisions affect all the rest, and should be similarly accessible.
Finally, I personally very much want a named and addressable right margin in the skin, mainly because I want marginalia and annotations to make their way to the default view. I want this framework to be available to build on. And I want new approaches to multi-column layouts that move the "standard Wikipedia page layout" from single column to multi-column, for screens wider than a phone. Points for departure:
– Britannica for decades had an annotation column in the Macropedia. Many long-lived references, as they aged, added explicit space for marginalia. A number of dense, dynamic websites that expand to fill available browser tab width still limit the central column width, but have engaging and interesting annotation context that is collapsed in narrow view and expanded or default-visible as width allows. Some use extra horizontal space not to showcase ads, but to showcase related work and knowledge, or show a history of recent pages. (compare modern tools for thought like Andy's Working Notes) We should be working and experimenting in that space; the people building those tools are the modern inheritors of the wiki mantle and are certainly drawing on fedwiki and other wiki spaces.
– Many research papers commit to a two-column layout, often to great effect and improved readability (though as with any of this, ymmv). LaTeX and other layout tools have templates for tables/figures spanning multiple columns.
Hello @Sj. Apologies for my delayed response here. Thanks for trying out the skin, and for your feedback.
Regarding your comments about line length (doing my best to repeat as little of what I've already said): the WCAG says "Lines should not exceed 80 characters or glyphs". There has been a good amount of research done within the 55–120 characters per line range, with some mixed results but most recommendations towards the lower end of that range. Last week @OVasileva (WMF) and myself met with Mary Dyson (a PhD researcher who has published over 40 research papers regarding typography and readability) and asked her why nobody has studied line lengths in the 200–300 characters per line range. She told us that she thinks it's because it's evident that text becomes difficult to read at those lengths (so why would anybody study that). We are interested in finding the upper limit of the readable range, so we also asked her if, for the purposes of being thorough, she would be interested in studying longer line lengths, and she said she would. So we are taking the research seriously, and are interested in doing more research (including instrumenting the full-width toggle we're adding, and analyzing the usage), though currently we have no reason to question the WCAG guideline, nor the individual opinions of 15 WMF designers, nor the several other design and typography professionals we've been advised by. Also, interestingly, most editors opposing the fixed-width are not saying longer lines are easier to read (as you seem to be saying, which the WCAG and Mary Dyson disagree with), they are saying they don't like wasted space, or they are annoyed by the fact that the formatting of articles will change (which is already happening anyways for the majority of readers, who are on mobile phones and laptops).
Wikipedia is different than many sites (as you and others have pointed out) but that doesn't mean it is different in regard to what a readable line-length is. We agree with you that higher information density is probably more appropriate for an encyclopedia than for many/most other reading experiences, which is why the max-width we've chosen results in line lengths above the recommended value, to strike a reasonable balance between scanning and in-depth reading. We are already pushing the limit there. But there is indeed a limit, research, and recommendations, and we have to balance the uniqueness of our need with the fact that 200+ characters per line is not a good reading experience for most people. Also to note: we are not suggesting changing anything on the list you provided, "(dense in-line links; extensive, granular in-line citations of claims; detailed citation formats; infoboxes and disambiguation papers; banners and hatnotes to denote works in progress; hierarchical categories; shared nav and format templates; a nuanced collaborative style guide)". Nor are we suggesting that we should blindly follow trends, or do what others are doing for the sake of fitting in (we've referenced other websites in this discussion not as a reason for our decision, but to illustrate how others follow the guidelines). We should be unique in ways, and that's wonderful, but there should be sensible limitations to these uniquenesses, and there's currently no good reason, or research, as to why we should be drastically unique regarding line length. We think we, as a community, should embrace the WCAG guidelines, and the existing research, until we have reason to believe otherwise. I think we should also embrace the fact that most readers are reading on narrower screens, and nudge editors towards having common experiences with readers (even if that means people, like yourself, find the website awkward looking, or incomplete). If editors want to opt-out of that, I think that's their choice, but I don't think it's a user-centered approach, because they are distancing themselves from the experiences of most users.
I reckon editors (who may not use the phrase 'user-centered' or see readers as 'users' rather than fellow knowledge-seekers) would very much like to have more common experiences with readers. Please make it easier for editors to emulate a range of readers experiences, on mobile and otherwise.
Limiting the default experience of the new skin for people with wide screen preferences would mainly detract from the experience of readers with wide screens, not editors.
A forced downgrade of screen information density for editors who have already developed skin preferences may not be an effective way to say "let's all improve the narrow-screen experience". More successful might be a mobile emulator and a public statement along the lines of "contribs to mobile skin design: now more fun, faster review time, and less frustrating!" ;) – SJ +04:50, 22 October 2022 (UTC)[reply]
Regarding the right margin, as I imagine you've seen by now there will soon be an option for article tools to appear there (link to prototype). I imagine that as the skin continues to develop, and we hopefully embody the experimental spirit you speak of, we will - as a community - think of other uses of that space for logged-in and logged-out people. We have to start somewhere, even if it's not perfect.
AHollender (WMF) Thanks for the reply! Something I wrote must have come across the wrong way; I don't find wide lines easier to read, I find wide pages easier to use. As does anyone who chooses a wide tab or page.
Whitespace
Large empty margins are not a good experience. Readers opting for a wide tab / screen have made a choice which we should respect. An ideal skin would have wide / normal / narrow versions.
Columns
We need multi-column layouts. (ample examples in print and online formats)
We need images and tables to be able to make use of available screen space, incl. spanning margins and multiple columns.
A short menu of infrequently-used tools is not a good use of extra columns or margins. Better uses: things that are informationally rich, scaling with the density of the article — Second (and third) content columns; marginalia and comments; footnotes and citations; &c. (ample examples)
For narrow screens: our mobile default still doesn't handle images, tables, or TOC well. Let's honor and find ways to translate great current article layouts rather than procrustinating them.
Research
As you say, we don't need research into "do people prefer 100-character lines to 1000-character lines when reading two paragraphs". There's nothing wrong with existing studies of readability, they just asked a narrowly limited range of questions.
A relevant tradeoff to explore, for different screen geometries + sizes, would be something like: multi-narrow-column vs. two-medium-column vs. single-wide-column vs. single-medium-column.
What do people prefer for different sorts of reading/research; for texts of a few column-inches / a few page-inches / a few pages / many pages? How does this change with screen width (for a fixed font size)? With reading + searching for keywords vs reading for full comprehension? With rich embedded media? What do people prefer for editing? (add an advisor from the University of Writing?) &c.
Maintenance
Thank you for making it easier for people to contribute to skin maintenance and design. As readers and writers move to narrower screens, as you point out, communities can help address their own changing interface needs.
In the past, community contributions to those areas of development has been ... frustrating. (cf. mobile categories! simple, popular, actively blocked for over a decade) Unblocking community contribs returns compounding benefits. Many thanks for the refactoring and cleanup in the upgrade, and for your active engagement. – SJ +04:50, 22 October 2022 (UTC)[reply]
Hey @Sj, thanks for the additional context — I think I better understand your perspective now. Here are a few thoughts that come to mind:
It seems like you're suggesting: an interface that takes up more of the screen is automatically better than one that takes up less of the screen (e.g. "I find wide pages easier to use", and "Large empty margins are not a good experience"). I disagree with that as a principle, and don't think we should make an attempt to fill the screen just for the sake of the screen being filled. Instead we should focus on what is valuable to people using the site. If the screen is filled okay, if it's not also okay; the amount of the screen that is filled is not an indication of a good/bad interface. It's contextual to the interface, and the person using it. I have not seen, in any design guidelines, WCAG recommendations, research, or otherwise, a principle regarding filling all available space. Additionally, we heard several times that people prefer focused interfaces, with whitespace around the content (one reference: reader modes in Chrome, Firefox, and Safari).
Vector 2022 is a multi-column layout, with the table of contents in one column, and the article in another (and soon with a third column optionally for article tools, but also customizable via gadgets to experiment with other content). Previously the table of contents was presented inline, making it only available at one part of the page, and creating a bunch of dead space next to it. So we are already taking advantage of a multi-column approach here (whereas Legacy Vector does not), and improving on the page layout of Legacy Vector. Additionally Vector 2022 uses CSS grid, making further experiments with additional columns much easier than they would be in Legacy Vector.
Multi-column layouts for text, which you reference, are possible with pagination (such as academic journal articles, printed newspaper articles, etc.). Seeing as Wikipedia articles aren't paginated I'm curious how you see this working? Can you share relevant examples of other reading experiences that have multi-column layouts without pagination?
Something like putting the infobox and images in a separate column could work, and might be an improvement, but wouldn't result in the interface taking up more width on the screen.
Something like adding citations to the side of the article would indeed make the interface take up more space, and the amount of information presented more dense, but is that what most people want? My instinct is no. I think it would be interesting to test, and I can definitely see it being something expert researchers like. But I tend to think the progressive disclosure approach (i.e. hover cards for links and citations) is probably better for most people.
Something like a minimap of the page (which many code editors have), personal notes (which some advanced reading tools have), might be cool for a small percentage of expert users, but likely not the general audience.
I would guess that people would be more interested in seeing related articles or content, which I imagine a lot of editors would dislike.
But again, I don't think there should be any pressure to fill the space just because it's there.
"A short menu of infrequently-used tools is not a good use of extra columns or margins" — the majority of editors we talked to use these tools frequently, and want them accessible at all times.
"We need images and tables to be able to make use of available screen space" — I think it's a nice feature to have, but doesn't benefit the majority of people. See https://phabricator.wikimedia.org/T318768#8312886. This is a feature for a small percentage of people who have large screens, and possibly discourages us from coming up with appropriate solutions for smaller screens (because editors who are creating the wide tables on wide screens don't realize they are suboptimal for most people).
I'm curious if that all makes sense to you. The only reason why Legacy Vector takes up the entire screen and Vector 2022 does not is because the line length in Legacy Vector is detrimentally long. Given that you don't think lines should be that long, and you think the interface should be multi-column (which Vector 2022 is), I'm not sure I understand your oppose vote at this time. Curious to learn more about your perspective, and see particular examples that would help me have a more concrete understanding of what you're envisioning for Wikipedia.
@AHollender (WMF), though I agree with the comment about that level of multi-column not being the right fit for web display in the general, you should look into column-span. I think we do a decent job of providing the right number of headings that someone could probably experiment with this one in a gadget or script. Izno (talk) 23:10, 22 October 2022 (UTC)[reply]
The goals (of vector 2022) are to make Wikimedia wikis more welcoming and to increase the utility amongst readers and maintain utility for existing editors. We measure the increase of trust and positive sentiment towards our sites, and the utility of our sites (the usage of common actions such as search and language switching) '
It nicely sums up the concerns of the editors, s
Utility Editors
Concerns are being expressed about utility by editors. Is increasing existing editor utility a goal of UX/WMF? I couldn't find any mention of editor efficiency, saving/reducing editor time, decreasing editor stress in phabricator. How will you measure if utility is maintained?
80 Char. IDEs such as used by WMF editors are information dense, and have far longer lines. Why doesn't this cause problems for WMF Devs?
You commented that "If editors want to opt-out of that, I think that's their choice, but I don't think it's a user-cantered approach, because they are distancing from the experiences of most users." This surprised me, it implies that experienced editors have the same needs as readers and should concentrate on the presentation layer, Is that what you meant? When you reviewed to make certain they were the same, were any experienced editor user journeys a concern?
Welcoming
WMF/Dev uses an inclusive design process. Concerns have been raised by WMF about past en RfCs, that they are not reflective of all en Editors, of diversity, and of other Wikis. IF en were in contact with more editors would you place more importance on RfCs?
Have you made any special allowances/surveyed ASD/hyperlexic editors and readers?
Do you think that Wiki's UX is implicitly unwelcoming to diverse?
Utility readers :
The reviews in 2013/2015 of the vector 2012 implementation showed no or negative statistics after implementation. How has that informed your design? https://handwiki.org/wiki/Software:VisualEditor
You mention readers but they seem passive/, and not differentiated. I can't find the personas, but for students/high users did you use learning design(LI LDX readX) especially for memory retention to inform your UX?
@SJ: regarding the right margin, did you see the prototype with a grey background? (select option 9 from this link) I personally think it removes the need to "fill" this space in order to differentiate it from the article body text.
I did, and I like that option's visual clarity. But I see a fundamental principle not to waste space, and our default designs should do useful things with extra width when it is available. The current 2022 design has narrow and medium-width modes, it should have a wider mode as well. And we must stop conflating 'amount of screen real estate used' with column-width. I want wide screens with multiple columns – like every broadsheet, magazine, dictionary, or encyclopedia ever. – SJ +16:14, 27 September 2022 (UTC) + 04:52, 22 October 2022 (UTC)[reply]
I also agree it's helpful to establish the empirical evidence for shorter lines. Without an accessibility policy-based argument citing clear evidence that narrower columns benefit readers, it'll be hard to overcome the difficulty of finding consensus for changes such as this, particularly given en-wiki's conservatism with regards to bold visual changes. People like what they're used to, and to be fair, Wikipedians are also a crowd particularly used to demanding evidence. I've long presumed shorter lines are more readable (perhaps from personal experience, as a neurodivergent person) and was somewhat surprised when @AHollender (WMF) said there's "plenty of empirical research" but then shared five unconvincing links (I see Beccaynr thought the same as me, and thank them for breaking down each source). The third link is the only serious academic article of the five provided, and I think its finding is significant in terms of the benefit for people with dyslexia, even if it's a small study.
I found the WMF-assembled literature review linked above poorly written. Thankfully, it does point to what looks to be the only academic literature review specifically on line length (although it doesn't actually make this clear)! It's available here via ProQuest, and accessible via the Wikipedia Library for editors with over 500 edits (search "Optimal Line Length in Reading - A Literature Review"). It dates from 2005 and is published in the peer reviewed journal Visible Language. While it'd be preferable to have more a more recent review, it does include a broad range of studies and has a particular focus on electronic devices, which is good. It says: "studies concluded that moderate line length in between 50 to 70 cpl [characters per line] are the easiest to read and users do not prefer extreme line lengths (very short or very long) while reading from screen. There was no significant effect of line length found on comprehension, though fast readers benefit from narrow columns with short lines due to specific reading patterns (with one contradictory finding)". I think this resolves the discussions above about whether shorter lines and WCAG are simply "practice", rather than evidence-based "best practice".
Given that the new skin preview appears to have lines with ~80-90 cpl (on my device at least), I think it can reasonably be said that the assertion our WMF peers make, that the new skin offers a more accessible and easy reading experience for visitors, is supported by the best available evidence (if anything, it's a compromise with lines longer than "best practice"). I'm not sure I'm fully ready to support the change (I'd like to see what comes out of discussions for a built-in wide width option and clearer backgrounds), but I think the new skin is the way to go in accordance with our community's commitment to being inclusive and accessible. Jr8825 • Talk 06:36, 24 September 2022 (UTC) (edited Jr8825 • Talk08:32, 24 September 2022 (UTC))[reply]
Thank you, AHollender (WMF), although it may be helpful to explain how each feature of the new skin reflects Web Content Accessibility Guidelines, per WP:ACCESSIBILITY. This may help avoid potential distractions related to critiquing the reliability and validity of the listed studies, and may help support the development of consensus related to whether and how quickly to implement the new skin. From my view, it may be counterproductive to essentially homebrew a 'best practice' based on a few studies, because a vast amount of research has already been incorporated into existing guidelines for web content. Relying on WCAG does not necessarily lead us to a clear answer, but I think it offers a reasonable starting point for assessing the current default and the new skin, as well as whether and how quickly to make a transition. Beccaynr (talk) 17:22, 27 September 2022 (UTC)[reply]
Also, AHollender (WMF), to promote readability of this discussion, I encourage a review of WP:TALK#REPLIED, e.g. if anyone has already replied to or quoted your original comment, changing your comment may deprive any replies of their original context, and this should be avoided. Once others have replied, or even if no one's replied but it's been more than a short while, if you wish to change or delete your comment, it is commonly best practice to indicate your changes. This includes changes made to the FAQ [14] and to your 14:52, 23 September 2022 comment. There are guidelines for how to note and explain changes at WP:TALK#REPLIED. Thank you, Beccaynr (talk) 16:28, 28 September 2022 (UTC)[reply]
Thank you AHollender (WMF), and I wish our guidelines were more easily accessible, especially for large discussions like this. I think it would help (especially for closers who will review the discussion) to update your comments to more clearly reflect when and how changes were made, so the discussion that follows is easier to understand. Thanks again, Beccaynr (talk) 17:00, 28 September 2022 (UTC)[reply]
Thank you, AHollender (WMF), and I added similar markup to the FAQ [15], which was changed after my comment highlighting a relevant portion of the WCAG [16], to help promote readability of the discussion.
I also continue to think it could help this RfC if there was more information about the research relied upon (not academic studies - the user testing) and the accessibility standards applied. I do not feel as if I have the time or familiarity with the tech to review each feature of the current default and new skin according to WCAG guidelines, but my hope is that WMF employees could more specifically demonstrate how the new skin is an improvement, before it is set as a default.
Also, Wikipedia is more than articles, and I have been thinking about how new features such as the short TOC bar on the left will interact with discussion boards that tend to have long TOCs, such as AfD, or AN/I. From my view, it has not been made clear why the need for some scrolling requires a major revamp, or how scrolling will be substantially reduced by the new skin. The new TOC box seems to require scrolling on pages with longer TOCs, because the new skin removes an ability to quickly assess the contents of the pages with one glance - it seems that instead, everyone must find the TOC box, understand what information it provides, and scroll through it, just to understand the basic overview of the contents of a page. Beccaynr (talk) 17:37, 3 October 2022 (UTC)[reply]
Regarding the TOC & discussion boards, can you review this conversation (which resulted in T317818)?
Regarding Vector 2022 and accessibility — I think it makes sense to have a dedicated page/section addressing this. I've made a note to add that to our project page on MediaWiki. High level:
Regarding screen readers and other assistive technology: we on par with Legacy Vector, and in some areas doing better than Legacy Vector (as a result of the restructured source order/DOM)
Regarding readability: Vector 2022 is more accessible than Legacy Vector in terms of line-length, and link colors. There was significant support from community members regarding increasing the font-size from 14px to 16px (which we have not yet done). There is (surprisingly) no WCAG recommendation for font-size, but according to this research it would be an accessibility improvement if we did it at some point. Some questions have been raised regarding whether or not there are accessibility issues with having white sidebars (vs. gray), which we are looking into.
Are there any other areas/features specifically that you are thinking about regarding accessibility?
To all the WMF people involved here, I hate put it this way, but you’re all looking at this width issue from a completely wrong and inappropriate point of view. You are looking for a figure that would make the the text readable to greatest demographic, presented as all here, of the visitors.
However, that is NOT what you and us need. What you need to implement is the technical system that serves that same all best. A fixed-width of prose that all should be able to read is not the same thing as the preferred way of all to read prose. Some like it even smaller than the average best of your studies, others prefer wider sentences. Everyone has their own personal preferred balance of width and required scrolling. So the best practice is a technical system of unlimited width that scales itself to the the visitors’ wishes. And the beauty is, we already have that in place today in Vector legacy. All one has to do to make prose the desired width is simply change the width of the browser screen. That’s nothing more than a click and drag exercise. Alternatively one can change their screen resolution if one prefers full screen mode.
I simply cannot understand that we have guidelines that preach not to apply fixed sizes to images, but rather led the built-in scaling do its work, and at the same time now you’re preaching for a completely opposite philosophy regarding prose size. Please DO NOT EVER remove or limit the fantastic auto-scaling we have now. You’re proposing a solution for a problem that does not exist.Tvx1 11:43, 1 October 2022 (UTC)[reply]
@Xaosflux: what's the status of MediaWiki:Gadget-wide-vector-2022.css? My primary complaint is about the enforcement of a maximum layout width. I installed this and at least on first glance, it looks like it solves the problem. If this was something that I could count on to continue to work (i.e. the Vector team commits to supporting it), I'd probably change from oppose to support. I don't honestly see why this trivial bit of CSS couldn't be the default behavior, but as long as I knew it was stable and supported I'd be satisfied with installing this manually. -- RoySmith(talk)17:31, 25 September 2022 (UTC)[reply]
@RoySmith it is "community supported" and certainly could break with upstream changes to the skin. It is currently opt-in for registered users only. There is one bug I know of right now (if you collapse the TOC and the sidebar at the same time, when you click the TOC menu icon the popup is offset too far to the right). I expect there is going to be a possible collision with the development suggested above of moving page controls (like "Move", "Delete") in to the right side gutter. I'm quite sure there would be better ways to do this, perhaps with a toggle, if the skin developers would embrace the concept. — xaosfluxTalk17:41, 25 September 2022 (UTC)[reply]
I certainly hope they embrace the concept. It would give them what they want (shorter lines of text) while still providing an easy way for people who can't live with that to also get what they want. -- RoySmith(talk)17:51, 25 September 2022 (UTC)[reply]
Well, with the discovery of Gadget-wide-vector-2022, I'm going to give this another try. I've turned on the new skin in my preferences and I'll see how it goes. I'm not convinced I'll like it, but now that my killer issue seems to be solved, it's worth another look.
It's not an original thought I know but I really wonder how this RfC could've been so much different had A) @OVasileva (WMF) and @SGrabarczuk (WMF) told people about this gadget in the first place and B) were way more open about the idea of making width options in the opening of the RfC. I tried the wide Vector 2022 gadget for a week or two and was pretty happy with it, but ultimately went back to Monobook due to other issues I have with V2022. ♠JCW555(talk)♠ 21:05, 25 September 2022 (UTC)[reply]
It may have swayed more people who were primarily thinking from an more "power editor" perspective, but not those who are more considering readers and casual editors. — xaosfluxTalk21:19, 25 September 2022 (UTC)[reply]
First of all, thank you @RoySmith for your willingness to try out different options!
@JCW555, yeah, I understand. Sometimes, I too wonder how something could have gone differently, if only... This helps make conclusions and learn. But even if you predict and mitigate something, it may still be an issue. In #Responses to common questions from the Web team, we did write "gadgets and user scripts have been built [...], including restoring full width [...] Check out the repository". But you're right, feedback we're gathering now is definitely a message to us that we should put more focus on this detail when communicating about Vector 2022. (Actually, I'll emphasize this part of the description up there right now.)
Regarding the second thing - sadly, options are more painful for engineers than useful for the communities. In result, decisions to provide an option or make something a preference are never taken lightly. Instead, we do our best to make the optimal choices for the default version, and what we present to the enwiki community is as far from happy chaos as it gets. (@xaosflux made a good point as well. Thank you for that!) SGrabarczuk (WMF) (talk) 03:38, 28 September 2022 (UTC)[reply]
@OVasileva (WMF), @SGrabarczuk (WMF), given the state of this RfC, would it be possible to add a toggle button, something like , in the right margin next to the languages menu perhaps, that will allow people to expand content width to (full size) minus (whatever space you need for right hand-side margin stuff) and remember the two settings separately for main pages and talk pages (cookie only, sitewide?). Ponor (talk) 12:58, 28 September 2022 (UTC)[reply]
One flaw I do see with this RfC is that it has mainly garnered attention from those that are logged in, mainly editors signed up for RfCs. I don't see much about what those that are logged out think. We need to remember that we (the <20% of users that make up >80% of the edits) are deciding something that will affect all readers. If we switch, and a lot of logged out users find the changes jarring, then they may find it harder to use the site. If we don't switch, and a lot of logged out users find it difficult to navigate an article, then they may find it harder to use the site. We also live in a world where misinformation is rampant and sites that look ugly have facts whereas sites that look pretty have fiction. I sometimes find myself Ctrl-F'ing stuff on Wikipedia as well because some Wikipedia articles get very long and it becomes difficult to find information on a specific subtopic of a topic. Aasim - Herrscher of Wikis ❄️ 19:08, 25 September 2022 (UTC)[reply]
@Qwerfjkl For something that will affect all the readers of the site, we ought to hear their opinion on the new design. This is not something like an infobox where we decide on the fly what parameters should be there or what layout should be used. This is even bigger as it can fundamentally change the usability of the site for better or for worse. We can all have our opinion on the modern web but I think it is important to follow reader expectations. Hell, that is even why I suggested switching to flat icons in the first place (to the dismay of a bunch of experienced editors that hated it). If we do not engineer for the third and fourth decades of the 21st centuries, we could experience drops in readership. To be blunt, Wikipedia needs to change with the times, but it should be the ones leading this change, not lagging behind. Aasim - Herrscher of Wikis ❄️ 23:16, 25 September 2022 (UTC)[reply]
Another problem is that the people who lived with Vector 2022 for many months (in the locales were it was set as the default) aren't going to come across this and voice what I expect would be a large majority of support.
I absolutely hated Vector 2022 at first when I saw it on another country's Wikipedia, and switched it back to the old one, but after browsing Wikipedia some more I realized how indispensible the always-visible ToC was, and how much nicer it was to have consistent page widths, and I ended up opting-in even on en.WP. Polling people for their opinion on a new design is a process with documented flaws; it's like polling people on car features, where you end up with Homer's Car. Preferences are revealed through behavior, not stated. I suspect most people would get used just fine to the new design, like I did, and, like me, would come to absolutely hate the old skin if they tried switching back. I literally can't use Vector legacy anymore. DFlhb (talk) 23:58, 25 September 2022 (UTC)[reply]
@DFlhb That is a really excellent point. One thing I would almost certainly support more strongly than what is being proposed right now is A/B testing, if it is not being done so already.
Here is how this might work: Half of the visitors to EN Wikipedia would get a cookie specifying the new Vector, and half would get a cookie specifying the legacy Vector. As for logged in users using Vector, one third of logged in users would be locked to the old Vector, one third of logged in users would be locked to the new Vector, and one third would have the option to switch between the two as they please. Granted, this may break user scripts, but as user scripts get updated to work on new Vector, this could change. A selection of logged out users would be asked to rate their experience on Wikipedia after some time. It can also be recorded how many users switched from new Vector to another skin, how many switched from old Vector to another skin, and which Vector the control group preferred.
I don't think it is enough to just make observations to determine what people prefer. The charts and data presented by WMF just show that new Vector is used by 36% of all wiki communities and that there are some benefits that new Vector has that legacy Vector does not have. I switched from legacy Vector when Timeless came out in 2018 because legacy Vector did and still does not seem ripe for the changing web and design. Unless if logged out users will be able to comment on whether Vector 2022 should be deployed, this A/B testing before deployment would be far more helpful in giving a definitive answer whether this skin is ready than just opening an RfC. Aasim - Herrscher of Wikis ❄️ 02:51, 26 September 2022 (UTC)[reply]
I added a few images to the top showing Vector 2022 and Vector legacy in desktop and mobile views as would appear on a mobile device (i.e. F12 dev tools then selected the mobile phone/tablet). It becomes quite clear why we do not use Vector legacy as the skin on mobile frontend. On the other hand, Vector 2022 is a good skin candidate for mobile frontend. However, I think in the future mobile frontend can be completely deprecated by Vector 2022. Aasim - Herrscher of Wikis ❄️ 03:18, 26 September 2022 (UTC)[reply]
@Awesome Aasim That would be awesome! It's crazy to me that WMF even went with building a maintaining a separate mobile skin to begin with. You can easily build websites nowadays that function well and look the same for both mobile and desktop. Lectrician1 (talk) 03:22, 26 September 2022 (UTC)[reply]
If we do something that greatly improves Wikipedia to the point other websites follow in our tracks, then we will have done something excellent for the modern web. On the other hand, if we are simply following what for-profit companies like Google and Microsoft say just so we can end up with better usability, then we are not doing much than just copying. I can see in the design that one of the inherent goals of 2022 Vector is responsive design, where changing the size of the window or even the device affects the layout so it remains usable. There are also semi-ambitious goals with progressive web apps and new discussion tools like the one I am using right now. Hopefully we can get to the point where we lead the change, not lag behind it. Aasim - Herrscher of Wikis ❄️ 23:24, 25 September 2022 (UTC)[reply]
"we lead the change, not lag behind it" This is impossible. As we serve the English Wikipedia market, with very long term stability, long term support for ancient browsers, a very conservative, vocal, diverse and inconsistent user group and all of that on an NGO budget, we inevitably will always lag behind. —TheDJ (talk • contribs) 08:53, 28 September 2022 (UTC)[reply]
I don't think it is fair to provide support for legacy browsers solely because less than 1% of everyone uses them. Windows XP was discontinued almost a decade ago and now has security vulnerabilities, even the newest Chrome does not work on Windows XP, same problem with Vista. The least I can probably expect is that people may be viewing Wikipedia on Windows 7 still because Windows 7 still has business support for volume licenses. A lot of earlier macOS and iOS versions that are no longer supported also have low number of people using them. Linux's marketshare is also small compared to macOS and Windows. It is quite ludicrous to provide support to browsers that are barely, if ever used. Aasim - Herrscher of Wikis ❄️ 22:47, 1 October 2022 (UTC)[reply]
Well it's incredibly unscientific, but I shared it around with my friends and asked for their views. People liked it overall and were positive about the new TOC and mobile view. One person said they felt the sidebar was too wide relative to the rest of the page.
However, one thing I have noticed is that the previews are different for logged in users and non-logged in visitors. Notably, there's a sticky top bar with search and other icons when logged in, which isn't present when logged out. Which format is being proposed as final? Jr8825 • Talk03:15, 26 September 2022 (UTC)[reply]
Hi @Jr8825 - thanks for the question. Right now, the sticky header is only available for logged-in users as a lot of the functions within it - access to the user menu, talk page, history page, etc were build with an editing workflow in mind. That said, we've also discussed implementing it for people that are logged-out as well as a means of introducing them to some of this functionality. OVasileva (WMF) (talk) 12:11, 26 September 2022 (UTC)[reply]
I agree that this is an issue. Most users of Wikipedia are readers—most readers never comment on talk pages, let alone RfCs—most (but not all) changes to Vector 2022 are intended to make the experience better for readers—everyone commenting here is an editor, not a reader. This disconnect *is* a big problem for this RfC and I'm not sure how it can best be addressed. Editors have a lot of power here, naturally—they're the ones who show up to discussions like this. It would be unfair to implement this change unilaterally against the wishes of a clear majority of editors, if it shakes out that way, but it would also be unfair to ignore that editors are a tiny minority of those who use the site. (comment copied from above) —Ganesha811 (talk) 04:24, 26 September 2022 (UTC)[reply]
My reason for the "cautious support" above is that the skin still needs more work in order to be ready for readers on mobile devices, but at the same time it is much much better than the current solution that we have with two separate interfaces, one for desktop and one for mobile. Aasim - Herrscher of Wikis ❄️ 11:50, 26 September 2022 (UTC)[reply]
Most articles are not being tested for the variety of screen resolutions and skins. Therefore, the optimal experience for the reader is most likely to see the article as close to the editor's view as possible. A default reading view shall be thus acceptable to the overwhelming majority of editors, and the designers should keep accommodating the editor's requests until they can get almost everyone to switch, even at the cost of theoretically degrading the new reader's experience, since in practice these readers will gain from sharing the interface with the editors. --Викидим (talk) 12:55, 27 September 2022 (UTC)[reply]
I disagree. Why would an editor's viewpoint be prioritized for readers? We are a specialized subclass of Wikipedia users. If Vector 2022 works for us as editors is a separate question from whether Vector 2022 works for most Wikipedians as readers. Both are important, but they are not the same. —Ganesha811 (talk) 11:27, 29 September 2022 (UTC)[reply]
I do not expect an average editor to test each change using the alternative interface (for example, I certainly do not test anything in a truly disastrous mobile UI, which is the one that IMHO should be changed ASAP, the desktop can wait for years). Therefore, almost every article will look its best through the lens of an interface that is used by the vast majority of editors. Ergo, the way to improve the reader's experience goes through convincing editors to switch without forcing it (and thus causing them to flip back to the old one); thus the new interface should be indisputably better than the old one. This is not the case now, as about half of the commenters think that the proposed new state of Vector is inferior to the old one. One problem pointed out is trivial to solve (multiple-level iconic menus instead of the flat text ones in the old version, at the very least allow us to switch back just the menus), one is harder (excessive margins), but both can be solved. For margins, one possible direction of making them useful is clear: nobody objects to large margins in a scientific printed book, as the space can be used for notes, in our case pointers to the talk page discussions and other proposals might be very valuable for the editors. For the avoidance of doubt, I looked at the work already being done to utilize the margins and liked it. IMO, it should be just finished first, before the switch. --Викидим (talk) 19:37, 1 October 2022 (UTC)[reply]
I'll toss out something that I suspect most people will find shocking and even heretical. Right now, editors are more important than readers. We're one of the top 10 websites in the world. We're not hurting for readers. Is somebody in danger of not meeting their quarterly performance goal to get our MAUs up? Is our ad revenue flagging? Is our projected IPO price not meeting the street's expectations?
On the other hand, every metric about editors is heading downward. Most of our essential processes are barely staffed. AfC is backed up for months. GA reviews are backed up for months. DYK is at the point where a couple of people are shouldering most of the load. AfDs often can't attract enough participants that they have to get relisted a couple of times. We can't twist people's arms to get them to become admins. It's a real concern that ACE won't get enough candidates to fill all the slots. We've got plenty of socks and spammers and UPEs. If editor numbers fall much more, that's all we'll have, and then nobody will care what a nice-looking skin we've got.
That's a fair point, and I generally agree that a strong editor base is the most important thing to keeping Wikipedia healthy. Is it relevant to choosing a new skin, though? I think the things most likely to lead to editor retention are improvements to talk pages, reply tools, mobile editing, gadgets and scripts to automate fiddly tasks, etc - all things that, as you probably know, we have repeatedly expressed to the WMF that they should be prioritizing. The skin won't make much of a difference one way or another, I expect. Hopefully, the WMF can walk and chew gum at the same time, and the adoption of a skin that may benefit readers more than editors is not taking away from work in those areas. —Ganesha811 (talk) 21:13, 1 October 2022 (UTC)[reply]
One of the problems with usability testing is that once you understand something, it's impossible to look at it through the eyes of a first-time user again. So to get a fresh perspective, I asked my wife (who reads a lot, but very rarely edits) to try this. Basically I set her up then left her alone for a few minutes. Her first comment was, "The table of contents box is gone". The issue was that it wasn't visible because it was in the left-hand navigation column, but the main menu had taken up the entire visible vertical space, so the TOC wasn't visible until she scrolled down. Beyond that, she said it's "Not much different, but looks kind of modern". She didn't initially have anything to say about the width issue, but when I prompted her to make the window wider, she immediately noted that the text wasn't expanding to use the full width and said, "If you pull your window wide, maybe there's a reason you're doing that". -- RoySmith(talk)12:47, 26 September 2022 (UTC)[reply]
We've got the three subsections named Support, Oppose & Neutral. There's no need for editors to emphasise their positions with those 'words' in their posts, as their posts are already under those respective subsections. PS - So far, the neutral editors realise this. GoodDay (talk) 14:01, 26 September 2022 (UTC)[reply]
That is a fair point. Although usually most !votes don't have those sections separated so it's probably why we still do it (and also it allows users to indicate whether they strongly oppose/support something or weakly oppose/support something). I notice the same thing at WP:RFAs. ― Blaze WolfTalkBlaze Wolf#654515:04, 26 September 2022 (UTC)[reply]
It makes it clearer to see which section the comment is placed in, when the top of the section is off the screen. Also it allows use of strong or weak support/oppose. — Voice of Clam15:32, 26 September 2022 (UTC)[reply]
I see a disturbing number of comments in both the Support/Oppose sections that focus on "this works for me" or "this doesn't work for me". Since any person with an account (i.e. almost everybody commenting here) can set their own skin preference and current Vector is not going away, it seems to me these !votes should not be given much weight. The question we're trying to answer is what skin should be the default for readers and new accounts. To give a related example, it's long been recommended wisdom to avoid "I like it" or "I don't like it" in article deletion discussions. Unless we largely discount comments just expressing their personal preference, this discussion is not a legitimate consensus for or against the default for millions of readers. Steven Walling • talk02:23, 27 September 2022 (UTC)[reply]
@Steven Walling: I agree and I actually encountered an IP who stated that they mostly just read Wikipedia articles and I asked them if they could use Vector 2022 and they give their opinion on it here since I feel it would be nice to get the opinion of a reader since usually it's pretty hard to get them to participate in an RFC since, well, they prefer just reading the articles. Maybe if it were some sort of poll they would participate but I don't think that's something we can set up on Wikipedia. ― Blaze WolfTalkBlaze Wolf#654502:27, 27 September 2022 (UTC)[reply]
I'm not sure on what other basis we're supposed to make a decision, though? With normal RfCs, arguments are grounded in the huge body of existing policies and guidelines we've built up on how to write a good and realiable encyclopaedia. We have no policies or guidelines on how to design a good-looking and usable website, because that's not our job, it's the WMF's. I really question the wisdom of putting this to an RfC, really really question making it yes-no, and really really really hope the web team have a back up plan here. Their years of hard work shouldn't be thrown out because a miniscule subset of our users think that wrapping lines of text at a reasonable length is a bad thing. – Joe (talk) 06:21, 27 September 2022 (UTC)[reply]
@Steven Walling: I disagree - I think this is one occasion where WP:ILIKEIT/WP:IDONTLIKEIT is a valid argument. There seems to be a majority of editors above who don't like it, and if this is a representative sample of the majority of users (i.e. day-to-day readers, who don't edit and are probably unaware of the proposed change) then forcing them to use an unpopular skin is not going to go down well. Remember that people without an account make up the vast majority of Wikipedia users, and they have no option to change preferences. — Voice of Clam07:31, 27 September 2022 (UTC)[reply]
I agree with Voice of Clam here. The skin wastes horizontal space for no good reason on desktop, and non logged in users have no option to avoid it. Newystats (talk) 07:41, 27 September 2022 (UTC)[reply]
But there is really no reason to believe that editors are a representative sample of users. 99% of people who use Wikipedia don't edit, let alone go deep enough to comment on RfCs. Editors are here frequently and use the back end of the site a lot. Our opinions are important, but I'm unconvinced we are similar to most Wikipedia users, who are primarily casual readers. As I understand it, this skin is designed mostly to improve the experience of reading Wikipedia, not editing Wikipedia. The problem is finding a way to judge the opinion of the vast, silent majority: readers. —Ganesha811 (talk) 11:29, 27 September 2022 (UTC)[reply]
Precisely Ganesha811. Editors are very different than casual readers in how we use and view the site, and are not a good representation of what an ideal reading experience looks like. The fact that statistically significant increases in readers efficiently navigating article content happened during randomized tests is way more important than any one person's preference. It proves that how people actually behave when given the new skin was that they can read articles with less wasted scrolling. That means it does a better job of accomplishing our ultimate goal, which is to give people easy access to knowledge. Steven Walling • talk14:26, 27 September 2022 (UTC)[reply]
Completely agree. I understand why the WMF's putting this up for a vote (to avoid backlash and accusations of elitism, and also to collect feedback for improvement), but user testing is the only criteria that really matters here. If users navigate better, and don't get turned off by the new skin (higher bounce rate, lower engagement, lower time spend on the site), then the new skin's a go; those should really be the criteria highlighted by the WMF team.
And on the ILIKEIT/IDONTLIKEIT debate: though I tried to make my Support comment more substantive than that, IMO ILIKEIT is a better argument than IDONTLIKEIT. ILIKEIT means there's no reason to block deployment in that user's eyes, which is a valid argument in favor. IDONTLIKEIT is less legitimate (note, I don't say all Oppose comments are less legitimate) since people can indeed just switch whenever they want. I especially feel that WP:BROKE is simply not a valid argument. DFlhb (talk) 23:30, 27 September 2022 (UTC)[reply]
I think when the RFC gets closed, anything that might create problems for readers will be assessed and weighted and used for feedback for improving Vector 2022 in the future, regardless on whether the skin gets deployed or not. On the other hand, the problems that this skin solves for readers will be weighted to determine whether the skin gets deployed or not. If there is not a significant benefit to readers and it just creates another headache, then the skin will not be deployed until the headaches get fixed. If there is significant benefit to readers then the skin will be deployed, however the points raised by editors here will be used to improve the skin in future versions. I mentioned that A/B testing among both readers and editors is paramount in determining this; I don't think questions about design, especially skins are good questions for RfCs because there will always be those that point out that the changes are a "solution looking for a problem" or "I don't like the design". If you don't like the skin, and you are logged in, note absolutely nothing will (or should, I honestly don't know. @OVasileva (WMF) or @SGrabarczuk (WMF) will the deployment affect current user's preferences?) happen to how Wikipedia appears to you after deployment. Granted, if the Vector Legacy skin gets removed from preferences (which it probably will not be until the number of active users using Vector Legacy drops below 1%) tough luck for those who still use it. But I do not think we should be thinking about if we like it or don't like it. We should be thinking about if logged out users like it or don't like it, as they are the ones that have no choice but to go with our decision. Aasim - Herrscher of Wikis ❄️ 01:26, 28 September 2022 (UTC)[reply]
I think regardless of how this RfC is closed, there will definitely be a part II to this RfC (presumably after the width option is implemented that @SGrabarczuk (WMF) mentioned above). Me personally, I see the potential that Vector 2022 has, but there's things here that make me think that this is a version 0.7–0.8 of a prototype. Something that's quite far along but is not ready yet for the primetime. Width preferences aside, people have mentioned that things that used to take one click takes two or more in Vector 2022, accessibility concerns, things like icons, etc. I know the WMF has mentioned that user menus will be customizable in the future but I feel like that should be in the skin before it's ready to be deployed, you know? Like I said, Vector 2022's getting there, but is it fully ready yet? I don't think so. ♠JCW555(talk)♠ 02:08, 28 September 2022 (UTC)[reply]
Perfect is the enemy of the good. The current Vector skin is far from perfect but it worked for a decade without much fuss. Now, Wikipedia has this problem that other websites were having that the mobile frontends are not doing mobile users much justice since the mobile frontends (including ours) often contain watered down features that are okay but not as powerful as their desktop counterparts. Mobile currently does not support the VisualEditor, the VisualEditor in source mode, dozens of user scripts, and dozens of other features that work on desktop. The Vector 2022 skin is a needed skin to bring Wikipedia into the modern times. And WMF should seek ways to redesign their pages even after to close this gap. Aasim - Herrscher of Wikis ❄️ 20:31, 28 September 2022 (UTC)[reply]
All of that can easily be achieved by developing a technically more modern skin, that is otherwise not visually different from the current. Vector 2022 is NOT at all needed to achieve what you want to. Tvx1 10:37, 4 October 2022 (UTC)[reply]
What? The point is that the vast majority of Wikipedia's visitors/users are readers who do not edit and therefore cannot easily contribute to this discussion. Of course editors are also readers, but we make up a very small minority of said readership. Remagoxer(talk)14:50, 4 October 2022 (UTC)[reply]
This is a much better way of expressing what I tried to argue in my support—that the WMF should rollout this skin and should not have made this RfC. (Opportunities for community testing and feedback: yes. And this has been happening. An RfC as to whether to implement the skin: no.) — Bilorv (talk) 15:43, 2 October 2022 (UTC)[reply]
Joe, I don't think that "wrapping lines of text at a reasonable length is a bad thing" (and the subset is far from minuscule). I think forcing wrapping at a fixed preset arbitrarily chosen "reasonable" length is a bad thing. I want the text to wrap where I want it to wrap by adjusting my browser window and/or screen resolution to what is the optimal size for me. And that's what all these others seem to want to. Let the readers themselves decide how wide they want their screen and text lines to be. Don't force a size on them. Tvx1 10:31, 4 October 2022 (UTC)[reply]
Statistics is not science. And nothing of what you say changes the fact that Vector legacy already allows every visitor to achieve that ideal width by simply adjusting their browser window. A preset fixed width is just not necessary.Tvx1 18:47, 15 October 2022 (UTC)[reply]
LOL, true. I agree with Steven: a great number of editors (both supporting and opposing) are answering the question "do you like it?" rather than the question actually posed ("should it be the default"). But we see this phenomenon throughout Wikipedia discussions, it's the familiar downside of democracy. My favorite !votes are the ones that recognize that this is industry-standard practice (that all websites do this), but still don't think we should do it because they personally don't like it. It's the elevation of preference over data, and it's why I said in my !vote I hope the WMF ignores some (many, really) of these !votes, or at least that it doesn't end up making design decisions based on the preferences of editors. Levivich (talk) 14:41, 27 September 2022 (UTC)[reply]
When you state that "I don't like this theme because X", the unsuitability of it for ALL users is implied. Otherwise it would be a support !vote instead, saying something like "while I personally don't enjoy it and plan to switch away from it, I think it would be a net positive". It would be Wikilawyering to suggest that simply because people didn't mention it, it's not included in the assertion. ᴢxᴄᴠʙɴᴍ (ᴛ) 03:30, 28 September 2022 (UTC)[reply]
WP:NOTDEMOCRACY. Consensus is evaluated not by the number of votes but by the strength of arguments. That is why I assessed the skin not based on whether I liked it or not but whether it seems like a skin that can resolve the mobile/desktop divide that only gets worse every single year with non-responsive sites like Wikipedia. To me, it seems like it can solve this, but there will need to be more work done to responsify the new Vector 2022 skin. Aasim - Herrscher of Wikis ❄️ 19:59, 28 September 2022 (UTC)[reply]
Can't blame you for the lack of imagination; you did go to Yale, right?[FBDB] Imagine making a decision about the default skin for readers based on research about readers' preferences, instead of based on one's own aesthetic preference. For example, if an editor's preferred layout was not the preference of the majority of readers, imagine the editor actually putting aside their personal preference, and instead making a choice based on the data, instead of the editor's opinion. It's easy if you try. Levivich (talk) 19:21, 28 September 2022 (UTC)[reply]
Oh, I agree, it would be terrible if, in deciding the default skin for readers, the WMF ignored what the community of readers think. 😇 Levivich (talk) 19:32, 28 September 2022 (UTC)[reply]
Thank you. BTW, I hadn't seen your clarification when I posted. "Flawed research" would be an excellent reason to oppose, if that were the case. The reason I'm supporting is not because I personally like the design, but because I've reviewed the WMF's research and it looked good to me (not that I'm in any way qualified to judge, but that never stops me). Levivich (talk) 19:44, 28 September 2022 (UTC)[reply]
Joking aside, I don't see this RfC as asking editors to evaluate the research findings. It's asking editors to evaluate the update and give our input. And I think that it's entirely reasonable for someone to say "I looked carefully at this, and I see problems with it, so I don't want it to be the new default. I recognize that there is research supporting the change, but I have to believe what my own eyes are telling me." (There's a good example of that at oppose number 63.) --Tryptofish (talk) 19:58, 28 September 2022 (UTC)[reply]
@Voice of Clam, you just can't go off "I like it" or "I don't like it." That's like when some people say "rap sucks" or "Nickelback sucks." You can say that all you want. But when you're in a discussion, give actual reasons and points as to why you like or don't like it. That's why this RfC exists. Simply saying "I like it" doesn't help. Mr. C.C.Hey yo!I didn't do it!21:18, 5 October 2022 (UTC)[reply]
@Mr. C.C.: - you seem to have misunderstood my point. I have deliberately not said whther I like it or not. My initial opposition was for other reasons. My argument is that other users !votes based on WP:ILIKEIT or otherwise, which generally state their reasons, should not be discounted as I believe they represent the silent majority of users who aren't editors. — Voice of Clam21:41, 5 October 2022 (UTC)[reply]
Government websites in Croatia, and I'm sure in many other countries too, offer users options to resize text, change font or otherwise adapt the view to their needs. For example, visit https://gov.hr or https://vlada.gov.hr and try the links at the top right side of the screen. I've noticed a lot of sites have started offering such features since the late 2010s, this is an important bandwagon to get onto. We need to implement a similar set of options to make our interface (whether Vector 2010 or 2020) accessible to all readers, instead of trying to make an informed guess of which size fits the largest minority.
For instance, I noticed that several months ago the text size was increased in Special:Search results on Vector 2010. To me personally, this is a net negative. Less items fit on each screenful, and it is harder to make out at a glance which lines are article titles and which are context. However, to someone who had problems reading the old text size, this is obviously an improvement. I suggest accomodating both users. Letting unregistered users choose their skin would be an inexpensive way to start. DaßWölf14:54, 27 September 2022 (UTC)[reply]
The discussion above seems to suggest otherwise, on both counts. A number of people commented that if this were a set of less drastic changes (mainly not forcing the controversial width change as default), it might not even require an RFC. Adding features like this does not count as "deploying entirely new skins". On the other hand, some skin-deployers suggested that allowing unregistered users to set interface prefs is out of scope for them and not on the roadmap (though @Enterprisey:'s suggestion above seems it may get around the cache multiplication concerns). – SJ +16:20, 27 September 2022 (UTC)[reply]
Great. If all the armchair wikimedia developers could get to work and actually make some contributions to the highly complex system, that be great. —TheDJ (talk • contribs) 17:55, 27 September 2022 (UTC)[reply]
That raises a wider question, perhaps better discussed separately: what's the best way forward for MediaWiki? There are many outstanding bugs and enhancement requests, even after eliminating those which conflict with others or are not technically feasible. Do editors with suitable skills and experience need to move on from generating and improving content to become software developers, or would it be better to spend a little more of the $200m annual income on addressing the outstanding software issues on a professional basis? Certes (talk) 08:45, 28 September 2022 (UTC)[reply]
The meaningless icons are a big issue here. "Hamburgers" and other similar UI elements are a bad habit from developing for tiny mobile phone screens that seeps insidiously into desktop web design. At present in the Vector 2022 design there is a very clear button when the contents of an article is present in the sidebar marked "Contents [hide]", but once one has clicked the "[hide]" button it is not at all obvious how to get the contents to reappear in the sidebar, when a clear button saying "Contents [show]" could easily be left in place. It is even worse with the main toolbar in the sidebar, which is hidden by default behind one of these opaque "hamburger" buttons, which could very easily be replaced with an intuitive button marked "Menu [show]" or "Menu [hide]". If this opaque mobile-phone-minded UI design was removed from Vector 2022 and replaced with simple, legible, intuitive text buttons then I would be far more likely to support the switch. We keep hearing about how this new UI is aimed at new users, and yet design choices like this only serve to confuse new users and push them away from the site, either actively (because they could not achieve the things they wanted without having to undergo a ridiculous game of cat and mouse working out what icon does what, which could be particularly intimidating for someone who is inexperienced with computers and the internet) or passively (by obfuscating the existence of features that users may otherwise interact with). Making the site more accessible should be the primary goal of any UI overhaul, but the inclusion of these design elements does not give me faith that the new UI will be successful at doing so. If a new UI can implement features that make it easy to adjust text size, or the colour of links, or anything else that could affect accessibility, then that would be great, but the first step in such accessibility features has to be making sure that users can find the options to begin with. HumanBodyPiloter5 (talk) 01:35, 29 September 2022 (UTC)HumanBodyPiloter5 (talk) 01:41, 29 September 2022 (UTC)[reply]
It seems to be broken if you're scrolled partway down the page. On screen sizes where that button can get hidden, there's more than enough space for a small '[show]' link on the side of the page, and on smaller sizes there is an always visible button. Is there any reason not to put it there? It seems simpler than designing a notice to tell people where it went pfg0019:48, 2 October 2022 (UTC)[reply]
@Pfg00 yes, on smaller screen widths the collapsed table of contents indicator (and icon itself) is broken in the prototype. In production you can see how it works (though there is not yet the tooltip-like indicator when you collapse it).
Regarding your question: there's more than enough space for a small '[show]' link on the side of the page, and on smaller sizes there is an always visible button. Is there any reason not to put it there? — can you clarify what you mean? Put what where? And are you talking about only for larger screen widths?
Possibly relevant information: the interface label "show" can be customized per-Wiki, and will be of varying lengths depending on the language.
@AHollender, I believe Pfg00 is suggesting that when hiding the ToC, instead of the tooltip-like indicator, a small '[show]' link should be used instead (floating on the screen). This would (presumably) be for all widths. — Qwerfjkltalk16:06, 3 October 2022 (UTC)[reply]
"[show]" button around where the "[hide]" button was. this might not work as you explained with different languages having longer messages and might be affected by browser text scaling
TOC icon to replace the [hide] button when the toc is closed.
The "[show]" button usually changes to a hide button in-place when clicked, and it breaks user expectations to have it do something completely different. Alternatively, an "X" button could be used along with the notice message like in the demo, as it's more clear that it will cause something to go away and show up somewhere else.
> In production you can see how it works (though there is not yet the tooltip-like indicator when you collapse it).
In production, if you're logged out and scrolled halfway down the page and press [hide], the TOC just disappears with no indication of where it went. The prototype has a bug where the indicator isn't properly visible. For the prototype to be implemented, it would have to be fixed to explain to the user that they need to scroll to the top of the page and press the button left of the title to get the toc back, or it would have to get rid of the "[hide]" button when you're scrolled partway down the page. pfg0019:40, 4 October 2022 (UTC)[reply]
Hey @Pfg00, yes currently the indicator is incorrectly positioned in the prototype. Here is how things will look soon, if you collapsed the table of contents while logged-out and scrolled down the page:
@CaptainEek: mentioned Wikiwand, which is fantastic. I use it sometimes. It's one of the reasons that I don't think this change will be great for readers; Wikiwand targets a purely reading audience (and has done for 8 years), it has its own excellent design sense, and it has preserved our current (relatively unusual on the modern web, but effective) full-width text layout. It would be interesting to talk to @Lior Grossman: and their design team about usability and the work they've done over the years to engage with and optimize for their readers. – SJ +16:28, 27 September 2022 (UTC)[reply]
I agree with this perspective. I used WikiWand occasionally several years ago and being reminded of it now and using it reinforces my belief that a full-width (or at least less white space) version of Vector 2022 is the way to go. Vector 2010 is nice, but it is dated, and in an internet era where appearances matter, we can't keep relying on a decade old skin. I'd argue that improving our appearance may even lead to more registrations. Anarchyte (talk) 05:41, 28 September 2022 (UTC)[reply]
I concur with CaptainEek that it demonstrates people hate our interface so much they'll go to the effort of making entire websites to replace it. Also, it doesn't have a full-width text layout, in the sense that it adds quite a bit of whitespace on the left and right sides (although it allows more words per line if you zoom out); in the one article I spot-checked (2014–15 Football League Cup), the resulting text width is closer to Vector 2022's than Vector 2010's. Enterprisey (talk!) 06:12, 28 September 2022 (UTC)[reply]
Wikiwand does not exist to show off a superior visual experience, however much they may claim do do so. Wikiwand exists purely as a vehicle to display advertisements, from which they make their money. Try opening up Wikiwand's page for Geneva (their choice of example) in one tab and the Wikipedia article in another. Flip between the two and you will find no advantage in reading Wikiwand, only the flashing of annoying ads.
Interestingly, what Wikiwand does state is that their revenue method is used in preference to that of WMF's, whom they point out as nagging readers for donations while claiming to be just "a small non-profit".Loopy30 (talk) 11:43, 28 September 2022 (UTC)[reply]
That's quite beside the point. The fact that wikiwand exists and people use it is because wikipedia's interface is not up to the mark. Unlike wikipedia, wikiwand does not get donations. How else would you expect them to offset development and hosting costs? – SD0001 (talk) 12:07, 28 September 2022 (UTC)[reply]
It is not beside the point. It shows that Wikiwand's primary goal is making a profit, not just enough "to offset costs", and so much so that they can afford to donate/pay a 30% cut to the WMF. Wikipedia's stated goal is to present the reader with free articles as a non-profit. We should not expect that the design employed to display these articles should be the same, or that Wikwand's should somehow be preferable, as their goals for the reader differ based on their respective revenue models. This goal, how to best display the article text, images and menu items, is the point. Loopy30 (talk) 13:23, 28 September 2022 (UTC)[reply]
Who cares what Wikiwand's primary goal is? It's besides the point because the point is that people use Wikiwand, and they don't do so because they want to look at advertisements, they do so despite the advertisements. People prefer Wikiwand--with its advertisements--over Wikipedia!. That's saying something. The readers who use Wikiwand would rather have ads than look at our website. Think about that, let that sink in. Wikiwand's been around for years, from which I infer it actually makes a profit, which means it has enough readers that advertisers actually want to spend money to advertise there. In other words, it's showing ads and it's successful! That's a huge and damning indictment of Wikipedia's design: it's so bad, there are people would rather look at ads if it means a better layout--enough people to run a business at a profit! Levivich (talk) 17:04, 28 September 2022 (UTC)[reply]
That's not a very strong argument. Suppose you run a SUV dealership in rural north Scotland, and another dealership exclusively selling convertibles opens down the road and takes 5% of your business. Would you then conclude that you should retire SUVs and start selling convertibles, and that Scots have no need for SUVs? DaßWölf16:20, 1 October 2022 (UTC)[reply]
I've never used Wikiwand until I just tried it a few minutes ago. I agree is looks really nice. If they've already created a front end which appears to meet most of the requirements outlined above, why do we need to compete with them? Why not just have a banner at the top of every wikipedia page saying, "If you want to try a more modern look, we recommend wikiwand.com". I'm dead serious. Quoting from our mission statement:
The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally."
How does investing our time and money to build the best editing platform possible and then taking advantage of third parties like wikiwand to provide a better reader experience not meet that goal? -- RoySmith(talk)17:46, 28 September 2022 (UTC)[reply]
As much as we like forks like WikiWand it is never going to happen since third party adverts often personalize to the reader. I can say that there is a better use of the blank edges, like having portlets there. Timeless has a portlet on both the left and the right side. I can't figure out why WMF hasn't gone the route of deploying Timeless across Wikimedia rather than just reinventing the wheel only for everyone to hate it. Aasim - Herrscher of Wikis ❄️ 20:35, 28 September 2022 (UTC)[reply]
Enterprisey, Wikiwand keeps expanding the width of the central column... Here's what they look like to me:
Cheers, – SJ +21:01, 30 September 2022 (UTC)[reply]
I've never used Wikiwand before. So I took a few minutes to look through an article and play with some a couple of the settings. They have some issues themselves.
Adjustable font size is all well and fine, but it can be hard for eyes to adjust. Even though it's not, it looked blurred at first.
Being able to adjust width is not a good thing for Wikiwand considering the amount of ads. It's not just ads on the side, but after every section. I get that's a source of their revenue, but for site that's a Wikipedia reader site, it takes away from the reason they exist. If they didn't have ads after each section of an article, it wouldn't be a big deal for those that make want to it wider or narrower. That obviously wouldn't be an issue for Wikipedia, but it doesn't make for a good case when discussing Wikiwand. You can't adequately judge width no matter what you set it at.
Shrink TOC is a terrible feature. Just have a hide feature instead.
What Wikiwand does has no bearing on Wikipedia. What they do won't necessarily work for Wikipedia. It's not to say somethings can't be considered, just that if it will be best for Wikipedia. Mr. C.C.Hey yo!I didn't do it!20:21, 2 October 2022 (UTC)[reply]
In the context of WP:AINT - Web team's thoughts on why the current skin needs to change
Hey everyone, thank you for all the discussions and support/oppose/neutral comments so far! We've noticed a number of these that generally say "WP:AINT" ("the current Vector works and does not need changes"). We've written a shorter comment on this earlier in the discussion and so as not to repeat ourselves too much we wanted to start this section with some of the points brought up there.
The current skin, Vector, was launched over 12 years ago. It has served us well, so there might be an argument for not changing it on an individual level. If you individually choose to keep using Vector legacy using GlobalPreferences, or if you use Monobook, Timeless, etc., you will not see the change. We respect that. We only want to introduce a new default, and understand that some people will choose not to use it, as is the case with our many skins right now.
Why is a new default needed? A lot of the patterns you see us using in this skin might seem like a general push for modernization for the sake of change - that is not the intent at all. WP:AINT says "if something is slightly broken in a way that you care about, and fixing it improves the encyclopedia a little, then feel free to fix it." We believe this applies to the situation here. There are many ways in which the Vector skin is broken for a large number of people.
Since 2010, new people have begun using Wikipedia (either because of their age, or because they now have internet access where they previously didn't). The more time goes by, the more new users' needs are different from the needs of the Internet users in 2010. We built the new skin to tackle the problems they really have, to make sure that everyone can benefit from the wikis - existing readers and communities, as well as people that have yet to join the project. See also a blog post about our motivation published a couple of months ago.
We started the project with research into the way people were using desktop right now and we learned a lot. In particular, our research showed us the following ways in which the current skin wasn't working for people:
There was too much information on the page: Too much information density on the page made it difficult for people to focus on a particular reading or editing task
The hierarchy of tools was confusing: Readers were unable to understand the purpose, terminology, and concepts of available tools such as the main menu, user tools, and page tools.
Too much scrolling for editors and readers: Readers found it difficult to navigate the page and spent a lot of time scrolling. Editors and other contributors wanted easier access to tools they used frequently without scrolling to the top of the page
Search was hard to find and use: Readers found it difficult to search for information that is relevant to them.
People didn't know they can switch languages: Multilingual readers were not aware of language switching functionality, even if they used different Wikipedias frequently
It was hard to read: Research into the width of the content indicated that Wikipedia's character count per line was more than three times the recommended value.
We tried to fix these issues in building the new skin. We're learning from new technology and strides made in usability during the past decade, and we also want to make sure we're building something that is usable to most people - both new audiences and the people that have been on the projects for much longer. Hope this helps give some context on our perspective.
Regarding switching languages, from what I can see the 2010 UI has a clear list of different languages displayed in the sidebar, while the 2022 UI only has the words "[number] languages" written in English at the top. I am unsure how this is more helpful in making someone who cannot read English aware that other languages are available than the current UI. The only clue to someone who cannot read English that this might be a tool for switching languages is a single "文" symbol, which is a lot less helpful than a section of the page clearly having "العربية" and "Español" and "中文" as clickable options. HumanBodyPiloter5 (talk) 17:48, 28 September 2022 (UTC)HumanBodyPiloter5 (talk) 17:51, 28 September 2022 (UTC)[reply]
Regarding the "hierarchy of tools", these are significantly harder to understand if they are buried behind meaningless symbols like "hamburgers" rather than plain text. The only part of the English Wikipedia where people not being able to read English should be a concern is the language selection tools, we don't need opaque symbols hiding information. HumanBodyPiloter5 (talk) 17:48, 28 September 2022 (UTC)[reply]
Regarding information density, this is an encyclopaedia, not a tabloid. People come here expecting dense information. If you want to give people tools to adjust the density of the information on screen, then I would be all for that, but "simplification" for simplification's sake can easily be counter-productive, especially when it involves meaningless "hamburger" symbols. A clear button saying "hide sidebar" in actual English or something to that effect would be far more helpful and far less likely to drive away new users unfamiliar with the arbitrary nonsense that mobile phone app designers keep festooning on the internet. HumanBodyPiloter5 (talk) 17:48, 28 September 2022 (UTC)HumanBodyPiloter5 (talk) 17:57, 28 September 2022 (UTC)[reply]
"Density" refers to the layout, not the content. It's dense content, not densely laid-out. People do not expect a dense layout; they expect the opposite, as research shows, and that's why everyone else on the web uses non-dense layouts with white space and limited-width lines and such. Although, a "hide sidebar" button is a standard feature that should be included in V22. Levivich (talk) 18:51, 28 September 2022 (UTC)[reply]
I agree that people should be able to adjust the density of the layout to meet their liking, and that doing so can have significant accessibility benefits if done correctly. I fundamentally oppose obfuscating parts of the layout by default behind opaque symbols that many users may not even realise can be interacted with. Give people clearly labelled options to hide the sidebar or to otherwise customise the UI, and then the revision will be far more likely to garner my support. HumanBodyPiloter5 (talk) 21:11, 28 September 2022 (UTC)[reply]
(e/c) With regard to "We only want to introduce a new default, and understand that some people will choose not to use it, as is the case with our many skins right now.": Please see my reason for opposing, which as far as I can see has not been picked up on yet. If the WMF can guarantee that support for other skins will be maintained indefinitley, I would be a lot happier. What I don't want to see happening is in two or three years time, legacy vector being withdrawn in the same way that the old classic skin was. — Voice of Clam21:16, 28 September 2022 (UTC)[reply]
To quote from your oppose: I can only oppose, unless the devs/WMF can guarantee that support for all other skins will continue indefinitely for those who choose not to use this skin. What you're asking for, a guarantee of indefinite backward compatibility, is unworkable. If you want Wikipedia.com to incorporate new web technologies as they are developed -- for example, if you want Wikipedia.com to keep pace with web accessibility requirements, or if you want it to continue to work with new browsers and new devices when they're invented -- then that means that at some point, when the new technology clashes with the old technology, they have to abandon the old technology. They cannot guarantee support for legacy skins indefinitely. That doesn't mean they can't continue it for a while, or that they can't phase it out better than they did with the classic skin, but at some point, it has to go. It's inevitable and unavoidable. Levivich (talk) 22:00, 28 September 2022 (UTC)[reply]
@Voice of Clam - thanks for making your concern clearer. Yes, I can confirm we commit to continuing support of the current Vector, as well as all other skins into the future and have absolutely no plans on turning it off. The transition will be similar to when the current Vector became the default skin but a number of users continued (and still continue) to use Monobook. A lot of the more technical work done in this project benefitted all skins and made support all other skins a lot easier from the technical side to maintain.
That said as @Levivich mentions, there are some limits which we look at for support to be dropped, namely among usage and technology. When a skin becomes used in the low hundreds of users, dropping usage may be recommended. This will not however be done overnight - we would make sure to study what people are getting out of that skin and to see if we can serve that need in a different skin.
However, the legacy Vector skin would not be anywhere near this consideration in the foreseeable future. If we take Monobook as an example again, we don't predict even beginning conversation on disabling the Vector skin within the next decade. OVasileva (WMF) (talk) 08:13, 29 September 2022 (UTC)[reply]
EditThis’s version of MediaWiki is so old that it precedes the 2013 skin purge. I tried using the Classic Skin and the sidebar isn’t placed properly anymore. So at some point I guess it just broke in new browsers. —pythoncoder (talk | contribs) 21:35, 8 October 2022 (UTC)[reply]
This does not work, I can understand the perspective but if you guys seriously need to make a new skin that will someday become the main skin, At least make it look functional and appealing to all, and on top of that how is it going to look like on articles that are more visually focused. Nostalgia Zone (talk) 22:20, 28 September 2022 (UTC)[reply]
Regarding the search, I suspect the frustration about it is that the search engine is so broken as to be practically unusable except in the most simple search tasks. I often need to resort to Google search within wikipedia.org to find what I need. Instead of moving the search bar to the left and making it bigger, it would be more useful to address the real problem, which is creating a better search engine. --Ita140188 (talk) 06:55, 29 September 2022 (UTC)[reply]
Well, you wanted to change something, you requested feedback, you got that feedback. Vector 2022 is not good and people are against it, so if you want to change then just read everything people said against it and work on improving it.
As for my responses to each point: 1 and 6 "too much information on the page/hard to read" - never found this to be the case. I rather appreciate the text to not be crammed and I think people agree with this.
2 and 5 "hierarchy of tools/switch languages" - and the new version improves this, how? by making it more confusing? In the case of language switch, you think that people will find it easier to guess where the languages are hidden?
3 "Too much scrolling" - sure, regarding the ToC and tools, but it's annoying and rather distracting the way it is in the current 2022 version.
Thanks for this post @SGrabarczuk (WMF). 2010 was way before the transition to "mobile first". "Mobile first" means that we should be adapting for devices of different screen sizes, not having two separate sites, one for mobile and one for desktop. I am looking forward to the day where the experience on Wikipedia uses proper responsive design, not some half-baked mobile front end that does not give mobile users the same experience as on desktop.
I also want to know - will all logged-in users using Vector Legacy be force switched to Vector 2022? This is something that is going to be quite a bit jarring. I see a reassurance for those using Monobook, Timeless, and Minerva but I do not see a reassurance for Vector Legacy users. Aasim - Herrscher of Wikis ❄️ 16:03, 29 September 2022 (UTC)[reply]
It’s my understanding that Vector Legacy users would be switched over to Vector 2022 if the skin change is made. I have Vector Legacy as my GLOBAL default so that might make things work differently but I’m not sure —pythoncoder (talk | contribs) 21:39, 8 October 2022 (UTC)[reply]
I'm going to echo the comments of the others here. Can't say I agree with any of the identified "problems". Never felt anything like 1. Moreover that situation also depends on the subject. Some articles are more extensive than others and a new skin isn't going to change that. @2, the fantastic hierarchy of tools in the current skin is one of the things that made me an editor in the first place. @3 Limiting the width in a new skin only makes this worse. @4 I had no issue whatsoever finding the search box in its instinctive top right position on my very first visit to Wikipedia and never had any issue afterwards either. @5 The new skin makes that actually worse by reducing the languages presence to one non-intuitive button. @User:6 Squishing sentences on even more lines makes things even harder to read.|6 Squishing sentences on even more lines makes things even harder to read.
So al in all, I don't see anywhere near improvement through this skin to justify making this the default. It's already deployed as an option and if there's is a particular set of people preferring it they can use it as their personal default. There is no reason for applying this with brute force to everyone, considering more people don't like it than people that do. I'm also concerned about the "research". How was this conducted and who was the target audience and how extensive was it and what was it's worldwide spread. I cannot remember any survey on the matter having taken place on this wiki.Tvx1 10:46, 30 September 2022 (UTC)[reply]
I just checked Encyclopedia Brittanica, one other major encyclopedia site, and they have a fully responsive layout and they have a fixed width [17] on its articles. It seems as if WMF is just looking at Brittanica and using that to base their redesign. That is where they probably got their left ToC and fixed width from. I think it actually makes it easier to follow, provided that the ToC is also accessible from the dropdown on the top on mobile. Aasim - Herrscher of Wikis ❄️ 18:49, 29 September 2022 (UTC)[reply]
I'd have to strongly disagree on the Encyclopedia Britannica example being a reason for Wikipedia to adopt fixed width. The EB site looks awful to me, using only about 30-35% of the screen width. I definitely wouldn't support WP looking similar to that, at least not without the option to toggle full width. GoPats (talk) 18:54, 29 September 2022 (UTC)[reply]
I'd suggest to look at our Alexa rank and then at Britannica's. Should we really be copying a competitor on life support? DaßWölf16:38, 1 October 2022 (UTC)[reply]
Alexa rank was discontinued recently. However SimilarWeb shows that EB ranks at 12 million worldwide and 3 million in the US for the month of July 2022. Wikipedia on the other hand ranks number 10 worldwide and 9 in the US. The reason that Wikipedia ranks higher than Brittanica is not because of its design but because of its actual content and how it covers a variety of different topics. If our devices that we are using are constantly changing, we ought to make sure that we update our site so they behave nicely on all devices. No more of this "mobile front end" nonsense, just a navigable Wikipedia that can be relied and depended on. Aasim - Herrscher of Wikis ❄️ 22:26, 1 October 2022 (UTC)[reply]
The mobile screenshots seem misleading to me. The screenshot of the current skin does not match what I see on my phone and gives the impression that the new skin (which really needs a proper name, it's not even anything like Vector - if anything it's more like Timeless and Minerva) displays the content better when it's actually the current skin which displays the content better. Here's screenshots of how it displays by default in a private tab on my phone:
Current skin
New skin
In both cases, the header and sidebar are too small to read or use. The page content starts at the same position down the page but that is because of the difference in banner heights - the one shown for the current skin is larger than the one shown for the new skin, which means without the banners, the page content will start further down the page for the new skin. With the current skin, the page title is an appropriate size, but in the new skin the page title is approximately the same size as the normal text and is hard to pick out at a glance. With the current skin, the page doesn't use the full width of the screen for the text, but the new skin gives the text even less horizontal space.
- Nikki (talk) 01:37, 30 September 2022 (UTC)[reply]
Strange. That's not at all how the mobile version looks to me.
The differing text size, is the browser automatically enlarging the text of what it thinks you might find important (based on a algorithm). This is called "text size inflation", and applied by mobile devices to desktop websites (you switched to the desktop website, and are not on the mobile domain) which are not suitable for mobile view. Remember, this is NOT proposed as a mobile skin (yet), it is a desktop skin, and so when you choose the desktop site, using this desktop skin, you will get a desktop resolution of the website and the device will pick the items it thinks are important and enlarge them. To have it behave like the last mobile screenshot as presented in the proposal, you have to go to the Mobile website AND use the skin override parameter (which no one will do), but its a nice preview of the direction things are going and how this eventually could also be used as a mobile website. —TheDJ (talk • contribs) 11:25, 30 September 2022 (UTC)[reply]
My mobile browser doesn't appear to use text size inflation, but it also has a problem in that new Vector's sidebar is significantly wider at the expense of the text column. FWIW I tend to use desktop view on my phone, because I find its tiny text somewhat less of a hassle than m.wikipedia's oversize text. DaßWölf16:50, 1 October 2022 (UTC)[reply]
It's not wrong. File:Pluto-enwiki-VectorMobile.png shows the minerva skin, not vector. The only way to access the vector skin on mobile is to set ?useskin=vector in the URL (similarly ?useskin=vector-2022 for new vector) – that is what the pictures in the RFC lead show. – SD0001 (talk) 18:35, 1 October 2022 (UTC)[reply]
Yes. This is on purpose because I see Vector 2022 potentially gaining responsive design fully deprecating the mobile front end. I wanted to show that if the current Vector was attempted to be made responsive it would require a lot more work to do. The new Vector does not have this problem. Aasim - Herrscher of Wikis ❄️ 22:16, 1 October 2022 (UTC)[reply]
In that case, that explains pretty well why I can't reproduce that screenshot. No reader will actually navigate to en.m.wikipedia.org/...?useskin=vector. This is not where the "Desktop view" link goes. I've removed the screenshots as IMO the RfC should stick to showing what the skin does rather than what it might one day do (and mistakenly portraying it as something it already does). DaßWölf16:07, 2 October 2022 (UTC)[reply]
Hey, I'm hoping this might clarify things a bit. Vector 2022 has been designed to be responsive, all the way down to mobile screen widths. We have not yet added <meta name="viewport" content="width=device-width,initial-scale=1">, however if we did then when you clicked "View desktop site" from your mobile device, Vector 2022 would indeed look like the screenshot below. (You can try this out for yourself by adding the meta tag above to the <head> element in your developer tools).
I'm not suggesting we change the screenshots at the top of the RfC, however I thought you folks might be interested in knowing that it would be easy for us to achieve this, if we decided we wanted to.
Vector 2022 on a mobile device (if we added initial-scale=1)
It's a bit complicated, but Vector 2022 can be run in a responsive or non-responsive mode. We currently show it in non-responsive as editors have complained about "mobile-ification" of the skin.
You can see the responsive-version on test.wikipedia.org
@AHollender (WMF) So there is a responsive Vector available? I think this should be the default. I see responsive design as a feature, not a failure. Provided that all the same tools that work on Vector desktop work on Vector mobile I see no reason to at least give it a shot.
I would also see if something can be done about "You are currently using a browser which is not officially supported by this editor." when using VisualEditor on mobile. An ideal responsive design should serve everyone, not just desktop and not just mobile. Aasim - Herrscher of Wikis ❄️ 03:12, 4 October 2022 (UTC)[reply]
@Awesome Aasim yes, Vector 2022 is fully responsive as you can see by resizing your desktop/laptop screen all the way down to 500px (or smaller). I agree that the responsive version should be what you get if you request the desktop site from a mobile device. I have started a discussion about this on phabricator: T319305. AHollender (WMF) (talk) 15:10, 4 October 2022 (UTC)[reply]
I've noticed a few bugs with Vector 2022 since I've started using it as my primary skin since I first opposed so I could form an actual opinion. One thing I noticed is that when following a link to a specific comment in a section, Vector 2022 will go to that comment, and then randomly just scrolls up or down the page to a completely different place, which makes it rather difficult to follow a large conversation (such as in this RFC). ― Blaze WolfTalkBlaze Wolf#654515:40, 3 October 2022 (UTC)[reply]
This generally happens whenever there is a centralnotice active (whenever stuff needs to be dynamically collapsed or shown). However on long pages like this, you are more likely to notice it, as the page takes longer to download and to render, leaving more potential time for 'conflict' between the scroll to the offset and the correction of the offset due to a collapsed item.
Possibly the sticky header, which animates late and is also at the top and adds additional offset, might make it a bit more visually noticeable, esp if initially by chance the offset was correct when you first saw it, and then the header overlapped it. But that is really just chance, in the past it would have just been above the scroll viewport. —TheDJ (talk • contribs) 18:19, 3 October 2022 (UTC)[reply]
I have. In fairness, we could be talking about two bugs (one Vector 2022, one not) that appear to cause the same behavior, but based on my intuition and TheDJ's comment, I don't think that's very likely. Enterprisey (talk!) 05:44, 4 October 2022 (UTC)[reply]
Let's talk about anything related to Vector 2022 or the Web team, for example:
What should be fixed/developed before making Vector 2022 the new default skin
The team's plans for the upcoming weeks and months
Or even this RfC itself.
We don't have any specific agenda or slides prepared. Nothing more than humans hanging out informally. Of course, bear in mind that both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply for such meetings. Also, Zoom is not subject to the WMF Privacy Policy.
Screenshots of Vector Skin at 120% (page with tables) 20221022Screenshots of Vector Skin at 100% (page with tables) 20221022
I am voting to support the change. But may I note that *both* Vector skins are quite poor while dealing with zoom. I usually use *browser* zoom at 120% (all sites, I am not getting younger...) at that zoom WP / Vector works mostly fine. But at 100% or 80% sometimes weird things happen. Namely, I enlarge the window, but the text may get smaller and in narrower column(s), up to (or down to) a thin column in the middle with lots of white space both sides, except in the top of the page (tools, title and so on across the screen). I have a vague understanding that programming for the web is a nightmare, but if one of the world's top sites can not handle zooming a page... - Nabla (talk) 22:38, 5 October 2022 (UTC)[reply]
Yup, this is pretty much exactly what people were asking for, thanks!
As a minor point, I think it makes more sense to put on the top control line (with the notifications, alerts, watchlist, and user menu). It's more of a global control rather than a per-article thing, so lumping it with Edit, View history, etc isn't the right abstraction.
I'm not sure I like the double-arrow icon. There's two states the window can be in: "constrained line length" and "unlimited line length", and the icon should change to indicate which action will happen ("switch to constrained" vs "switch to unlimited") when you click it. Maybe an arrow pointing one way in one state and the other way in the other state? Not sure how LTR vs RTL languages will interact with that.
Also, when the window is narrow enough that there's no difference between the two modes, the control should visibly show that it's disabled. Otherwise you just keep clicking on it and it doesn't (apparently) do anything.
But, these are all nits. The basic concept looks good and works well.
@NGC 54, @Xaosflux, @RoySmith - thanks for bringing this up! We'll publish some more details on the prototype tomorrow, as well as potential next steps for implementation, and what would make this idea a success. Just wanted to add a quick note that this is just a quick prototype @AHollender (WMF) made to discuss what's possible and that the developers haven't began working on this yet. The flash appearing here on pageload would not be present in the production version and there might also be other types of issues due to the prototype environment as well. That said, any and all feedback is appreciated! OVasileva (WMF) (talk) 15:26, 6 October 2022 (UTC)[reply]
Hey everyone - thank you all for engaging with this RfC and continuing the conversation! Wanted to make a quick announcement with some more details on the toggle discussed above.
We’ve been reading through a lot of the feedback and it seems that a majority (roughly 78%) of the concerns people have with the new skin are around the fixed width of the content. While we still believe that fixed with is necessary to improve the overall usability of the site, we recognize that some of you still prefer the full width and that the current gadget provides insufficient support for this:
The gadget is not future-proof enough for the support of customizable width and difficult for non-technical members of the community to use. The English Wikipedia community would prefer a specific setting or toggle that is a part of the core experience
The gadget is not available for logged-out users
With these concerns in mind, the Web team has decided to go forward with building a toggle which will allow for turning the fixed width on and off from any page within the site. The prototype for this toggle is available here: https://di-full-width-toggle.web.app/Galaxy (note that this is just a design prototype - it might have certain issues and it's possible the design might change during implementation).
The estimated timeline for this feature is by the end of October/early November 2022. Once development of the feature is completed, we will add it to the new skin and begin measuring how it is used, so that we can discuss further improvements of the toggle in the future. Thank you and looking forward to hearing your feedback on this. OVasileva (WMF) (talk) 16:52, 7 October 2022 (UTC)[reply]
OVasileva, I like this a lot—it keeps all the benefits of Vector 2022 without the issues that come with fixed width, and people who like the fixed width can keep it on. I could definitely support making Vector 2022 the default once this feature is enabled.
I do have one other potential favor to ask: On Cirrus cloud, I used larger images to allow readers to see details within the clouds. On Vector 2022 with fixed width enabled, this squishes the text a fair bit. Would it be possible for us (as editors editing wikicode—not readers changing preferences) to move specific images into the free space on the right? For example, the picture of various types of cirrus clouds in the lead section could easily be moved right a bit, same with the gallery of cloud species below it in the "Description" section. I can try to make a mockup of what I'm saying if it is hard to understand what I'm asking for, but I'm not a graphic / web designer. Thanks a lot for this! Reaper Eternal (talk) 17:51, 7 October 2022 (UTC)[reply]
This is a good improvement, but on my 13-inch screen, it only makes the text about half an inch wider on the right. There's still a half-inch more white space on the right side than in the current vector, and the enormous blank space on the left is maintained. I like having a wider screen especially for tables so info within cells can take up the full width without line breaks that put even more emptiness into other cells. Reywas92Talk18:19, 7 October 2022 (UTC)[reply]
Love this! Thankyou so much for listening to the community and providing future readers/editors with the option to toggle the width! Coldbolt (talk) 18:24, 7 October 2022 (UTC)[reply]
@AHollender (WMF) Terrific! I must say I like each of the options that I find it difficult to give a definite preference. At the moment I'd have to say either white or grey, though perhaps if the gradient didn't follow as you scrolled down the pager (as in, it's white at the very top then fades to grey as you move down the page) it could be my preference. Hard to say, but certainly looks great. thorpewilliam (talk) 02:04, 8 October 2022 (UTC)[reply]
I like the gradient background! The white background is an improvement compared to the striped greywhite we have now. The grey feels old. For all options, the top-right menus are too far to the right / the entire page is too far to the left. Femke (talk) 08:43, 8 October 2022 (UTC)[reply]
As another Vector 2022 Opposer who didn't get around to commenting above, I also like this a lot more. I still don't like it, but it's significantly less bad now.
Usability feedback: I had some trouble finding the button, even knowing it was there. I poked around in Tools, the menu next to the Wikipedia logo, the user menu, and stared at the table of contents for a while before finally seeing it (right next to Tools). I'm unsure to what extent this is a problem with me vs the design. 3mi1y (talk) 02:59, 8 October 2022 (UTC)[reply]
I must admit, the width toggle helps the Vector 2022 skin a little bit but at the same time though, it looks godawful on more visual articles especially on United States network television schedules when the colors are way too bright and the color for articles that you already read looks and sounds as appealing as a bad marching band. Also, editing just looks like a pain to deal with. In conclusion, You can all convince all you want but, I’m sticking to Vector legacy. Fix it, that’s all I have to say. Nostalgia Zone (talk) 17:56, 8 October 2022 (UTC)[reply]
This width toggle could be a little bit more streamlined. Fandom Desktop has the arrows change direction while at the same time using an animation between expanding and contracting the width. There should also be scrolling animations upon clicking one of the ToC links so the reader knows exactly where they are going. This streamlines the experience a lot. Aasim - Herrscher of Wikis ❄️ 22:22, 9 October 2022 (UTC)[reply]
The width toggle which I am assuming is marked by the arrow pointing left and right, appears to require that Javascript be active, which is unfortunate. I do, however, appreciate the effort being made to respond to the expressed preferences of the community. 68.189.242.116 (talk) 21:15, 15 October 2022 (UTC)[reply]
The toggle is great news, @Olga! I'm all for giving our readers more choice in how they display the content. And as for measuring how it is used – I hope you instrument the heck out of it. Sure, there is existing research about line length and readability. But Wikipedia is in a special position to research at scale how readers actually choose the text width in practice, when given a choice. Do they toggle it for some content or types of pages and then switch back? How does it correlate with viewport size, zoom factor, and screen resolution? There are so many aspects you could examine. ⁓ Pelagic ( messages ) 03:20, 21 October 2022 (UTC)[reply]
It will probably correlate with the number of right- (and even left-) floated thumbnails and large tables in the article, things that can make articles unreadable at small widths. Minerva gets around this with vertical image layouts and side scrolling tables, but I'm not sure if "Vector 2022" has these features. small jarstc21:34, 27 October 2022 (UTC)[reply]
I hope you are aware that almost all desk- and lap-top users already have access to an established, intuitive form of width control: they can simply resize their windows, as I myself do to enhance my comfort whenever I am reading text online. All limiting the width is doing is taking away this freedom from users, and in that light I don't really see why it's necessary. The gadget is better than nothing, (I hope it will be available to all logged-out users) but it's a compromise that makes the currently trivial problem of width control just a bit more frustrating and prone to bugs. I think I read that tests were performed to determine whether fixed page width was beneficial for readers: if so, would the participants have been under the impression that they would be allowed to resize the window at their leisure as part of the experiment? small jarstc21:18, 27 October 2022 (UTC)[reply]
@SmallJarsWithGreenLabels thanks for your thoughts. There is extensive research about line length and readability, which demonstrates two things: shorter line lengths are easier for reading, and most people won't manually adjust their browser width even if it it improves their reading experience (link to some). Therefore the WCAG has a guideline about line length (link to guideline), which we should follow. Have you read through the research, and the guideline? And even if most people did adjust their browser width, we wouldn't want to put people in a position where they have to make a manual adjustment every time they visit our website just to have a good reading experience. To make an analogy: it's like running a restaurant and making the temperature extremely cold, and reasoning: "well people can put on lots of extra layers when they come here if they want to be at a comfortable temperature, but if we make the restaurant a normal temperature by default we deprive them of the opportunity to be extremely cold". We know what temperature is comfortable for most people, and we know what line length is comfortable for most people, so we set the width of the content accordingly. Cheers, AHollender (WMF) (talk) 12:48, 28 October 2022 (UTC)[reply]
A little off topic, but this is something that I raised on Meta several years ago.
I have been using Timeless for several years and it feels very polished and has much better responsive design than Vector 2022 has ever had. I still support the deployment of Vector 2022, I just wonder why couldn't we decide on a different skin that editors would not come to hate?
I am guessing WMF wanted to develop a facsimile to Timeless but then they ended up falling short and now 50% of editors hate it.
I don't think the other skins end up well advertised. All you get is an update to Wikipedia:Skin and at best an announcement at Wikipedia:Village pump (technical) but I have not seen skins be advertised as widely, aside from two skins: Vector, and Vector 2022 (which I think should get a new name). Having the skin "vector 2022" is a bit misleading as it makes it seem like it is a different version of Vector, whereas in fact it is a whole new skin. Aasim - Herrscher of Wikis ❄️ 21:25, 17 October 2022 (UTC)[reply]
Completely agree on the name. Vector 2022 is about as different from Vector 2010 as Vector 2010 is from Monobook. A talk with the branding team might have helped things here. —pythoncoder (talk | contribs) 23:17, 17 October 2022 (UTC)[reply]
The naming implies that Vector 2022 is being marketed as a replacement for the Vector most of us currently use, now rebranded "legacy" or "2010" in an attempt to make it appear obsolescent. The two skins are very different and deserve different names, but that would suggest a commitment to supporting both, when some might prefer to get rid of the current skin. Certes (talk) 08:51, 18 October 2022 (UTC)[reply]
I love it, @Aasim. I've tried living with other skins, including Vector 2022, but keep returning to Timeless. Timeless gives me the best responsive adaptation across desktop, tablet and mobile. I'm hoping Vector 2022 will get there, but the text is tiny on iOS and there seems to be a roadblock around enabling the viewport setting to overcome this. If I was desktop-only, I'd probably just use the site default. For reading (not editing) at phone sizes, Minerva and the iOS app are both great! (Unless you want to use suppressed features like navigating a topic by its Navbox.) The AMC team did some fantastic work adding "advanced" features to Minerva; I wish they had the time/funding to go further. The remaining niggles cause me to jump back from mobile to desktop. I've said right from the beginning that they should have built on Timeless not old-Vector, but skins are complex and there may be some hidden technical debt that the dev's can see and we can't. ⁓ Pelagic ( messages ) 00:14, 21 October 2022 (UTC)[reply]
Clarification: "viewport setting to overcome this" is mentioned above by Jon and Alex as T319305. But I thought there was another phab ticket having more discussion? ⁓ Pelagic ( messages ) 00:23, 21 October 2022 (UTC)[reply]
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. If this is the planned solution, it would be a bit of a squeaky wheel system as anons are both less likely to voice concerns and unable to load gadgets (without browser add-ons) in a persistent way. (which &withgadget= is not) So if the holes in Vector-2022 are supposed to be filled with gadgets, shouldn't gadgets be made available to anons? And I'm not just saying that as the author of AnonLoader, IMHO gadgets should be made available to anons, the method to achieve it can be debated. But I think it should happen. — Alexis Jazz (talk or ping me) 10:54, 16 October 2022 (UTC)[reply]
If anons want to load gadgets, they should create an account or use browser extensions. There aren't really any high-traffic websites out there that allow you to personalise the appearance without even creating an account. – SD0001 (talk) 14:07, 16 October 2022 (UTC)[reply]
I mean the only time that a website allows logged out customization is with changing light/dark mode, but even then it just defaults to what the user set on their PC's preferences. Aasim - Herrscher of Wikis ❄️ 21:22, 17 October 2022 (UTC)[reply]
Just as last time on Zoom, we'd like to talk about anything related to Vector 2022 or the Web team, for example:
What should be fixed/developed before making Vector 2022 the new default skin
The team's plans for the upcoming weeks and months
Or even this RfC itself.
We don't have any specific agenda or slides prepared. Nothing more than humans hanging out informally. Both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply for such meetings. Also, Discord is not subject to the WMF Privacy Policy. If you prefer not to use Discord, don't worry, we'll keep having meetings on Zoom as well.
=== Is An Output of this RfC needed? ===
The RfC is long, but there is no definite outcome, and it now takes too much time to read.
No consensus is needed, but there is a process within Consensus_decision-making where after a discussion, a summary is created and then this is is discussed again. Te difficulty with a large public consultation, even with good intent, is that a risk is not understood (because a clear understanding has not been reached), or the RfC is perceived as a sham (because an expectation is raised unrealistically), or those who are quiet have been ignored. The closest thing to such a summary with dev, is a simple issues list created by dev with
Issue number
a very short word summary statement of an issue
Dev comment
Dev provides Status already in this release/added to this release/post/release due x/never/confirm community need/ more info/dev process modified/wont
Dev specifies benefit/importance
And an update is done to each RfC comment to have have a tag to he relevant issue
They can be created in phab, but that is too much overhead, is part of a perceived WMF land, and not wiki,
This issues list is then discussed again. The important thing is honesty. if it is not possible say it. Or if you are not convinced arrange a time for another RfC post go live,
There is a history of misunderstanding/poor communication/open distrust,
And the de facto dev process seems to be waterfall with very irregular releases
The communication strategy is unclear (elicitation, change management, honest community engagement, evidence based decision making/eye tracking, UAT feedback, post implementation review, budget, prioritization, set release dates, AMA with IT, and roadmap/strategic planning one/five/ten year). Wakelamp d[@-@]b (talk) 14:26, 18 October 2022 (UTC)[reply]
Although the RfC isn’t closed yet, it’s nearing four weeks, and some of you requested that we provide a quick summary of our take on the RfC and next steps prior to closure. Firstly, we want to sincerely thank you all for all your thoughts, questions, bug reports, ideas for improvements, and other engagement with this RfC. We were so happy to see so many of you engage with the ideas presented, ask questions about the features and the data, and flag issues we hadn't previously noticed. This is helping us to make the skin better for all of our readers and communities.
TLDR
It seems that most people here either approve of or don't object to most features of the proposal, but the biggest issue is the fixed width of the page. Following suggestions from many of you, we have already begun working on configuration of the limited width for both logged-in and logged-out users that will allow to turn the limited width off. The first step, a preference that allows to turn off the limited width, will be available on English Wikipedia tomorrow, on Thursday, October 20.
Summary of the RfC
Going through the support comments, we've noted the following main themes. It’s important to note that many of the main themes of support comments are directly conflicting with oppose comments (for example we see many support comments based on the limited width and many oppose comments based on the limited width). Thus, our approach for moving forward is to lean towards configurability of elements rather than removal.
Improved readability due to the limited width and overall cleaner interface
The table of contents is more useful and usable
The skin is easier to use across a number of different devices with different screen resolutions
The sticky header allows for less scrolling to the top of the page
Improved navigation through simplification of buttons and menus
More modern look and feel
Going through the oppose comments, we've noted the following themes:
Limited width It looks like 79% of the ~160 oppose comments mentioned the limited width as their main reason for opposition. Of these comments, many indicated the need to be able to set the width of the page as an individual preference. Others focused on a general idea of a toggle that would also allow logged-out users to expand the width when preferred. With these concerns in mind, we have decided to go forward with building a toggle which will allow for turning the limited width on and off from any page within the site for both logged-out and logged-in users. The prototype for this toggle is available (note that this is just a prototype and may have bugs and limitations that won't be present in the real code). The development schedule for this is as follows:
Building a preference. This week, we are releasing a use preference which allows logged-in users to turn the limited width off without requiring a gadget (T319447). It will be available in the appearance section of the preferences page on English Wikipedia starting tomorrow, October 20. Check it out on Wikipedia in Italian.
Building a toggle. By early November, we will release a toggle for the limited width that will allow both logged-out and logged-in users to turn the width on and off per page (T319449). Once deployed, we will study the usage of the toggle and discuss any changes necessary based on the result.
In addition to that:
We have received feedback that some of the users like the limited width of the page, but have concerns about the color of the introduced space itself, requesting for a clearer definition between the content and tools areas. We are exploring options that will allow for this and will have an update next week.
We are continuing the work of the page/article tools feature which will separate page navigation from global navigation and allow for the pinning of the tools menu in the right sidebar. This feature is currently in active development - see a prototype here.
General skepticism of the necessity for change. It looks like 19% of the ~160 oppose comments mentioned their sense that the current Vector works well enough and no change is necessary. We have commented on this previously and would like to once again encourage folks to read over our research with readers and editors. WP:AINT says "if something is slightly broken in a way that you care about, and fixing it improves the encyclopedia a little, then feel free to fix it." We think this applies to the situation here. There are many ways in which the old Vector skin is broken for a large number of people, and our research includes what they said doesn't work for them, and the ways in which we tried to address it.
Issues with the language selector. It looks like 5% of ~160 oppose comments mentioned issues with the language selector. We are currently working with the Language team and will address the following:
Providing better communication for when a page is not supported in other languages (T316559)
Language button showing an empty popup when no languages are available and the compact language list is disabled (T319690)
We think the list above addresses the main concerns from the RfC. As a clear next step, we will continue with the completion of the tasks mentioned above prior to continuing the deployment conversations.
Good response. I'm glad to see the WMF is listening to the community's feedback here. Reading through the RFC, I get a sense that while the community is evenly split on the redesign for the time being, a lot of the opposers' complaints seem fixable. I look forward to seeing the revised product. —pythoncoder (talk | contribs) 01:45, 20 October 2022 (UTC)[reply]
Don't forget that the language selector is just plain "wrong". It combines two completely unrelated functions (changing a preference for input language/keyboard vs. switching to another language version of the article your reading), which should never be combined in one dropdown. The second function belongs only on articles, not on talk pages, where it "never" can be used: whether it needs to be this prominent on articles is highly debatable, I doubt that it is the most important button people need, but it is preented as such. The other function simply belongs in preferences, along with all the other ones. The dropdown needs to be removed from all pages where it has no urgent function (i.e. everything but articles at the most). That it doesn't work in combination with the compact language list is just a nice bonus, but not the main issue. (Oh, and I gad no idea there would be a numerical breakdown of the oppose reasons, as I for one didn't bother repeating the other reasons I also agreed with, but just added additional ones) Fram (talk) 10:11, 20 October 2022 (UTC)[reply]
I agree that it is weird that non-content namespaces where there is basically no interwiki translations ever, get such a big button that is so inviting for people to click. It doesn't really make sense and I think is gonna be a source of confusion, with ppl expecting google translate-like translations of discussions. However interlanguage translations are technically possible, so if not on that spot on those pages, where would they live in case they are present ???? Would love to see thoughts of the design team about this, it seems the current languages functionality was very much targeting articles and didn't consider other page types like talk pages very well. —TheDJ (talk • contribs) 10:26, 20 October 2022 (UTC)[reply]
Hey @TheDJ, right so for pages that don't support interlanguage links the plan is to present a compact version of the language menu button in the same location (screenshot below, phab task). We discussed moving the language menu button elsewhere in those cases (because it's arguably much less important) — discussion 1, discussion 2 — and decided that keeping the button in a consistent location was important. Does that make sense and seem alright to you? Also yes, the Vector 2022 interface is more anchored around the article experience than the original Vector. Of course we're trying to accommodate all pages and use cases as best as possible, but it is indeed a bit more opinionated in that sense (which is intentional).
Two versions of language menu button in Vector 2022
Nope, not better at all, thanks for trying though. You haven't adressed the fact that the contents of the button are a mishmash of utterly unrelated things, which is confusing as heck: and the main functionality of the button (go to another language version of the page) doesn't work on talk pages, so the claim that you need to keep it there "for consistency" is not really supported by the inconsistency inherent in the button. It's just a shitty design decision which looks as if no one bothered to test this on anything but articles, and now won't be turned back out of fear of losing face. The end result is the opposite, making the impression of the WMF worse by sticking to poor decisions because, well, because nothing really. Fram (talk) 13:48, 21 October 2022 (UTC)[reply]
Hi @Fram, the idea with the updated/consolidated language menu is that it is now containing all language related functionalities: switching to other language versions of a page, creating translations, switching the interface language settings (maybe even the "Edit interlanguage links" function should be there as well). I understand that from your perspective some of these functionalities are unrelated, and that you're frustrated that we've gathered them into a single menu. I will share your feedback with the language team. We did already explore separating the interface language settings functionality and placing it elsewhere, however perhaps that's worth exploring again. Cheers, AHollender (WMF) (talk) 15:01, 21 October 2022 (UTC)[reply]
I like this plan, and also like all language-related functions being bundled in a single menu. Switching input methods may not happen often, but it's key that it be easy-to-change since many editors use public computers and aren't logged in. DFlhb (talk) 01:35, 3 November 2022 (UTC)[reply]
Regarding limited width, will the toggle for logged-out users be persistent and what will the default be? For the default, I would suggest A-B testing; seeing which users are most likely to switch from, and implementing the other as the default. BilledMammal (talk) 10:19, 20 October 2022 (UTC)[reply]
Hey @BilledMammal - thanks for your questions. The toggle will be persistent for logged-in users only and per-page for logged-out users. This is once again due to caching as well as optimizing for the best readability. The default will be the fixed width, but we will be measuring the usage of the toggle and will review based on how frequently it is used. OVasileva (WMF) (talk) 14:16, 25 October 2022 (UTC)[reply]
Can confirm I have the checkbox for "Enable limited width mode" now. Am excited about the impending on-page toggle.
@Pelagic - the page tools are currently in active development. We plan to have them in production up by the end of the calendar year, and hopefully a bit sooner, by the end of November. OVasileva (WMF) (talk) 14:12, 25 October 2022 (UTC)[reply]
When was it announced that there would be a count of all the issues reported in the comments to decide which are the most urgent? As Fram mentioned, if I knew this before I would have explicitly repeated again all the issues that I found that were already highlighted in other comments. --Ita140188 (talk) 07:39, 21 October 2022 (UTC)[reply]
I agree with comments above (Fram, Ita140188, etc.). In my opposition comment I only mentioned the TOC, which I consider the chief mistake in the new design, but I also agree with the problems highlighted by other comments, and I agree with those who have commented "if ain't broke, don't fix it". In general, as pointed out by many, it seems that the design is a try to impose a mobile style, and in general I oppose the switch to Vector 2022 altogether. I also see that here there is another avalanche of criticism against the new TOC and width, expressed by users coming from Wikipedias of all languages. As some have said, hybrid designs between the old and new Vector, with the old and new TOC, such as this one, would be the best solution. Æo (talk) 15:20, 21 October 2022 (UTC)[reply]
I'm very disappointed to see all the work done by the community in the RfC reduced to two sets of small changes.
No mention of the problems with the TOC (which works poorly on long articles and pages, and breaks the TOC limit)
no mention of taking away the impression that the design may prepare for ads.
No mention that the link colour is difficult to see (and according to feedback elsewhere, the two colours are indistinguiable for people with common forms of colour blindness).
No mention of the confusion many people have with the hamburger-style icons, rather than having words or at least icons that aren't all variations of three horizontal lines. Femke (talk) 07:25, 22 October 2022 (UTC)[reply]
I fully support breaking the ToC limit; it's implemented in most pages as a way of not having a full viewport-height taken up by the ToC. There's no reason why a sidebar ToC would need to be limited; that would just reduce navigability and accessibility. DFlhb (talk) 01:37, 3 November 2022 (UTC)[reply]
Right, my bad. I meant TOC_limit, which results in an incomplete outline; not collapsing, which is a helpful feature. The autocollapse behavior on the new sidebar ToC works well IMO. DFlhb (talk) 18:25, 3 November 2022 (UTC)[reply]
In addition, the issue of whether sufficient credible, valid, and transparent research (both in studies, which we have been asked to review and have since extensively questioned, as well as user-testing, which has also been questioned) exists to support the new skin as well as making it the default does not seem to have been addressed in the summary. I also asked for an assessment of the new features according to WCAG, but this also does not appear to have been addressed during this discussion. However, additional support for concerns related to the TOC appears to have been produced [18]. This discussion appears to outline how implementing this under-construction skin as a default will be a significant change, and seems to support a slower approach, such as making this new skin available but not yet the default setting, while the many concerns raised continue to be addressed. Beccaynr (talk) 15:07, 22 October 2022 (UTC)[reply]
I haven't seen a lot of feedback above about the new language bar, want to see if I'm in the minority here with a concern. When looking at an article (Picking a possibly controversial one here, but on purpose both because it is a main page item, and because it is controversial: e.g. 2022 Russian invasion of Ukraine). As a "reader" when I see the language box on the top, my first inclination is: this will let me read "this article" translated' to my chosen language. And if this is what it did, this high-prominence placement of this control seems like a great idea. However, that isn't what this control does. It instead send the reader to a different article on "this topic" in my chosen language. As another example take our article, S-50 (Manhattan Project). I can say, wow they have this in Galician, but looking at w:gl:Proxecto S-50 is certainly very far from the "featured article" quality, or even a translation of that content. I'm not saying there is anything specifically wrong with glwiki's article, but it is certainly not a "read this in my language" exit point that I'm expecting. I fully support linking topics in other projects, but think the old style was more informative that you are leaving the English Wikipedia. Any thoughts? — xaosfluxTalk13:49, 21 October 2022 (UTC)[reply]
This hadn't occurred to me before, but I think you're right to raise it as an issue. I don't think that the old Vector is significantly more informative that you're leaving English wikipedia though (it just says "languages"). -- asilvering (talk) 15:03, 21 October 2022 (UTC)[reply]
Right, but I don't think most readers are aware that en.wikipedia and fr.wikipedia are entirely different things, let alone that readers are looking at where the hyperlink goes. (And if you're using a phone browser, which very many readers are, this info isn't as easy to spot, either.) -- asilvering (talk) 04:45, 23 October 2022 (UTC)[reply]
I think the language bar would make sense if we had I18n and one large Wikipedia community. We already have I18n for MediaWiki, Meta, and Commons. Although to be fair the language bar on Fandom wikis has the same behavior; rather than translating the page it goes to the wiki that has that page in that language. Aasim - Herrscher of Wikis ❄️ 20:09, 21 October 2022 (UTC)[reply]
When you roll this skin out, whether with or without the community's consent, please don't call it "Vector". It's a new skin. Some people prefer it to Vector, others don't, but either way it's not Vector any more than it is Minerva, MonoBook or Timeless. Giving it a name that's already in use for an existing skin just causes confusion. I understand that spinning the current Vector as "legacy" will make it easier to withdraw support quickly but it really isn't an obsolete version of the new creation; it's a separate skin which the vast majority of desktop readers currently use and are used to, and which many of us wish to continue using. Certes (talk) 11:09, 24 October 2022 (UTC)[reply]
FYI There are unfortunately technical constraints for renaming it which I've captured in phab:T319066 - the main downside of renaming is all gadgets/user scripts cease to work across all projects until they've been renamed/adjusted to check the new skin key. Jdlrobson (talk) 20:27, 24 October 2022 (UTC)[reply]
Yes, we should have spotted earlier that skin key "vector" and user-facing name "Vector" refer to two different skins, which will cause confusion. Certes (talk) 21:52, 24 October 2022 (UTC)[reply]
MOS:SANDWICH on De Boom Die Alles ZagNo sandwich in legacy Vector
As me and Styyx discovered, because Vector 2022 removes the TOC from the actual article, it creates issues regarding MOS:SANDWICH, such as on the last DYK (as of writing this) De Boom Die Alles Zag. Because of this, there are probably hundreds, if not thousands, of articles that now have issues regarding MOS:SANDWICH because of this removal of the TOC from the article body. This definitely needs to be remedied before Vector 2022 (or I guess Tensor since I like the suggestion of this new name above) is rolled out. ― Blaze WolfTalkBlaze Wolf#654516:35, 24 October 2022 (UTC)[reply]
Sandwiches have been a problem on Timeless for years. I remember adjusting a few images myself to make sure that the images do not cause readability problems on timeless. I wonder if an update to the manual of style might be needed to account for different screen sizes. Aasim - Herrscher of Wikis ❄️ 16:05, 25 October 2022 (UTC)[reply]
Everyone on narrower screens or in some of the different skins was already experiencing this. Ppl have been telling editors for years to consider narrow layouts. Maybe this is a good wake up call to stop assuming things about layout. —TheDJ (talk • contribs) 16:19, 25 October 2022 (UTC)[reply]
This. You should say, "Here's an image which goes along with this piece of text. Put it someplace that makes sense". Where that is exactly will be a function of your window size, font size, and 37 other things. We're not very far away from machine translation being good enough that browsers will be translating on the fly and text layout direction (i.e. left-to-right vs right-to-left) will be fluid. Write your content then get out of the way and let the software worry about the layout. -- RoySmith(talk)19:42, 25 October 2022 (UTC)[reply]
"Write your content then get out of the way and let the software worry about the layout" This. I dunno why Wikipedia doesn't do this. Plenty of other websites have the software resize and move the images and text according to the screen and/or window size. (or I could be completely wrong and am just assuming things since I have only ever gone to other websites with a bunch of words and pictures together on my 1280x1024 ancient monitor) ― Blaze WolfTalkBlaze Wolf#654519:56, 25 October 2022 (UTC)[reply]
"I dunno why Wikipedia doesn't do this." Because the way wikipedia builds pages is pretty much the same as it was 20 years ago. We've made some incremental changes, but it's like putting lipstick on a pig. No disrespect to the V2022 team. They've made some improvements, but they're fundamentally hobbled by needing to maintain backwards compatibility with a 20 year old system. -- RoySmith(talk)20:40, 25 October 2022 (UTC)[reply]
I think there needs to be CSS that makes the content adapt to their screen size. Take the infobox as an example on Timeless. On full width the infobox snaps to the right, but after some point the infobox snaps and stays to the center. Adapting to the screen size is a must. Sure on WMF's end all they may need to do is add a couple tags and CSS to make the article and history pages responsive, but there might need to be more work to be done to make the images "snap" similar in this manner.
For this image example, after some point the image should be pushed to a newline or be snapped to the center. No more sandwiches, as delicious a grilled cheese sandwich can be. Aasim - Herrscher of Wikis ❄️ 12:22, 26 October 2022 (UTC)[reply]
Yes, those of us who know our way around Wikipedia can make the new skin work, more or less, with some JavaScript and CSS – or simply revert to another skin. My concern is for the casual visitor who doesn't have those tweaks available due to being logged out, or hasn't invested the time in finding them and frankly can't reasonably be expected to do so. Certes (talk) 21:55, 28 October 2022 (UTC)[reply]
Certes, not sure why the "I'm alright, Jack" summary.. Technically AnonLoader could offer a Vector-2022-inline-toc gadget, but it's rather uncertain AnonLoader will ever be deployed. Vector-2022 will be deployed sooner or later, that much is clear. The sticky sidebar ToC, no matter how much we hate it, is here to stay. So whatever is done next should take that into consideration. — Alexis Jazz (talk or ping me) 09:16, 29 October 2022 (UTC)[reply]
I simply meant that I'm not affected personally as I'll manage whatever the default skin, but I was attempting to consider readers' needs. Certes (talk) 09:27, 29 October 2022 (UTC)[reply]
This is indeed another big problem created by the removal of the perfectly functional former in-article TOC, which has been turned into a horrible sidebar user menu. This is another element indicative that the quality of the articles is considered less important than the so-called "user (mobile) experience".--Æo (talk) 19:06, 27 October 2022 (UTC)[reply]
Agreed. I honestly feel like the in-article TOC should be added back and the sidebar TOC removed since it causes some articles to now violate the Manual of Style. It doesn't really work that well anyway for article navigation since instead of conveniently being located at the top of the article at the bottom of the lead, it's now in a sidebar, placed underneath the side menu. ― Blaze WolfTalkBlaze Wolf#654519:11, 27 October 2022 (UTC)[reply]
@Blaze Wolf @Æo I suggest reading through this thread, where we've extensively discussed the position of the table of contents. I also suggest reading through the user testing results and community feedback, both of which support the updated location of the TOC. Lastly, if I understand the comments above, people are saying: the layout issues are happening regardless of the location of the TOC, and need to be fixed. I don't think your perspective that the TOC is to blame for layout issues is shared by others. AHollender (WMF) (talk) 19:30, 27 October 2022 (UTC)[reply]
@AHollender (WMF): I'm sorry but I really do not have the time, patience, or attention span to read through that entire thread. I also noticed at the very bottom of the thread you linked, an IP user (not a user who has been here a while, an IP) stated that they do not like the TOC being pushed to the very bottom of the sidebar, something I agree with and makes the TOC practically useless on some shorter articles since it takes less time to scroll through the actual article than to scroll through the sidebar to get to the TOC. I feel that there should at least be an option to add the TOC back to the article since that is what some users prefer. While it doesn't entirely fix issues regarding the MOS (that should definitely be fixed, either that or the MOS needs to be rewritten/reworked according to modern standards and modern hardware/software) it will at least please those who prefer it in the article. IT should also be moved to the top of the sidebar regardless so that it can actually be used more easily similar to how it was before Vector 2022. ― Blaze WolfTalkBlaze Wolf#654519:45, 27 October 2022 (UTC)[reply]
(edit conflict) It's a fact that the side TOC will cause accessibility issues around SANDWICHING at the beginning of some articles, including in articles that did not have these problems before. But
The new skin resolves sandwiching in the body of the article, because the smaller width will push sandwiched images further apart
The smaller range of widths makes it easier to test out whether images will sandwich, as we take away the need to fix sandwiching on very wide screens.
Overall, the new skin improves sandwiching problems in my experience.
As for Fancy TOC on the DYK, there is some work planned to make the TOC configurable phab:T317818. Hopefully so that {{TOC limit}} works. Would DYK be able to use that template instead?
As for the scrolling to the TOC, I think the article tools on the right (end Nov/begin Dec) should solve that, as the remaining tools are not really used by anybody and can be collapsed by default. —Femke 🐦 (talk) 19:48, 27 October 2022 (UTC)[reply]
"The new skin resolves sandwiching in the body of the article, because the smaller width will push sandwiched images further apart" Huh? How would a smaller width push the sandwiched images further apart? Wouldn't that just push them closer together?
"The smaller range of widths makes it easier to test out whether images will sandwich, as we take away the need to fix sandwiching on very wide screens." why are there sandwiching problems to begin with on very wide screens? The images would be father apart so the text wouldn't be quished inbetween 2 images. As for the {{TOC limit}} template I have no clue since I don't manage DYK. I only discovered the issue yesterday when I went to check on my own DYK and noticed a large blank box from {{Fancy TOC}} not having a TOC anymore since I use Vector 2022. ― Blaze WolfTalkBlaze Wolf#654519:54, 27 October 2022 (UTC)[reply]
Because the text is spread over more lines on a smaller screen, it takes up more vertical space. That way, images are pushed further away vertically, so they are less likely next to each other.
It's true however that on wide screens, sandwiching poses less of an accessibility problem than on small screens because the horizontal space between images is larger. —Femke 🐦 (talk) 20:06, 27 October 2022 (UTC)[reply]
Apart from images, templates will also be affected. Articles with very long templates in the lede, many images and tables, such as articles about states, will be completely disrupted. Considering that such articles always also have very long TOCs, these too will be sandwiched into that messy sidebar menu.--Æo (talk) 20:12, 27 October 2022 (UTC)[reply]
The problem has already been raised several times throughout the discussion, but by opening this section I want to highlight that an alternative solution for the TOC is imperative. Can you (developers) imagine big articles with lots of images, templates and tables like "Pope Benedict XVI", "Donald Trump" or "China" or big discussion boards like the Wikipedia:Reliable sources/Noticeboard when the new interface will be imposed on them? The articles' layout will be destroyed, the entire structure of sections and subsections will be unclear, and everything will be unexplorable. Therefore, I suggest that you either leave the TOC as it is now or you implement a hybrid TOC system like Sushi or Song.--Æo (talk) 00:36, 16 November 2022 (UTC)[reply]
I agree. I've opened several phab tickets on various aspects of the TOC. The latest bug I was trying to characterize had to do with what happened when mouse focus switched from the navigation panel to the TOC panel as you scrolled vertically and the TOC was long enough that it had its own scroll bar. I finally came to the conclusion that there was some timing-dependent aspect to it. If you stopped scrolling for a moment then picked up again, you got a different behavior than if you scrolled continuously. That's when I decided I'd sunk enough time into this and switched back to legacy.
I really gave it my best shot and used it for over a month. But in the end, I just needed to get stuff done and the fancy TOC scrolling stuff kept doing things wrong and getting in my way. -- RoySmith(talk)01:07, 16 November 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Vector legacy (current default), logged-out
Vector 2022, logged-out
Vector 2022, logged-in
Vector 2022, logged-in, wide screen
Vector 2022, logged-in, 4K display
Vector legacy (current default)
Vector 2022, logged-in
Vector 2022 as the screen is resized
Vector legacy on mobile in desktop view
Vector 2022 on mobile in desktop view
Support, works a lot better for me than 2010 Vector on my tablet. — Qwerfjkltalk 06:13, 23 September 2022 (UTC)
.jpg)
icon.My last concern relates to page status indicators, including protection status icons and the FA star/GA plus circle. By commandeering the upper right corner for the language switcher, the new skin pushes the indicator icons down a row, and by moving the page tabs line below the page title line, it pushes them down still further. The developers have explicitly touted how the additional prominence of the language switcher is desirable, but when we have raised concerns about the diminished prominence of the indicator icons, they have declared it 
pencil-and-lock icon used in the mobile skin) because it's most applicable to those considering editing a page. The GA/FA icons do need to be prominent, because they ought to be a key indicator to readers about the quality of an article, yet currently most readers don't know they exist, and diminishing their prominence by moving them to the developer's chosen position will only make that worse. Given current challenges in the misinformation landscape, emphasizing tools to help readers assess an article's trustworthiness should be (and is on paper) of paramount concern to the WMF, which makes the lack of attention to this issue particularly frustrating. Moving the GA/FA icons directly next to the article title instead of pushing them down would be a better alternative, and there are probably other available solutions I'm not creative enough to envision. This is the issue that the developers seem least interested in addressing — they have committed only to fixing the coordinates display (phab T281974), which is a separate issue (and I'm leaning toward not having them per Xaosflux because they're not fundamentally a page status indicator and thus don't belong outside the normal content area, so I consider that fix less essential anyways). Therefore, I encourage the community to speak up more about the importance of this.Overall, if these issues are addressed, it'll move me from my current lukewarm stance to enthusiastic support. In general, I feel that the foundation is often overly cautious in rolling out changes, preferring the slow perfect to the rapid good, but given the particular sensitivity of design changes, it's worth taking the additional time to put the best possible foot forward. Ultimately, I hope that the developers are able to come up with a design sufficiently compelling to overcome the knee-jerk statusquoism some in the community will inevitably have. Regards, {{u|Sdkb}} talk 06:51, 24 September 2022 (UTC)
, in the right margin next to the languages menu perhaps, that will allow people to expand content width to (full size) minus (whatever space you need for right hand-side margin stuff) and remember the two settings separately for main pages and talk pages (cookie only, sitewide?). Ponor (talk) 12:58, 28 September 2022 (UTC)
Imagine not caring what the community thinks. (Or, perhaps, imagine flawed research.) --Tryptofish (talk) 19:28, 28 September 2022 (UTC)
.jpg)
Cheers, – SJ + 21:01, 30 September 2022 (UTC)
Current skin
New skin
.png)
_Wikipedia_Banner_fundraising_24th_September_2022_01.png){kind=link}
_Wikipedia_Banner_fundraising_24th_September_2022_02.png){kind=link}
