The following is a Requests for Comment (RfC) discussion on whether Vector legacy should be restored as the default skin on the desktop English Wikipedia site.
Jump to: | Support | Oppose | Neutral | Alternate proposal | Discussion |
On January 18, 2023, at 15:17 UTC, the Wikimedia Foundation Web team deployed Vector 2022 as the new default skin for all users on the desktop English Wikipedia site, after implementing a set of changes specified by the editors who closed this RfC. This replaced Vector legacy, which has been the default since 2010. Since Vector 2022's deployment, there has been backlash from both users who expressed concerns with the new UI, with complaints at Wikipedia talk:Vector 2022 and mw:Talk:Reading/Web/Desktop Improvements. Many editors were also unaware of this change until the launch, and/or did not participate in the previous RfC. This raised questions as to whether there was consensus to deploy Vector 2022, though the Web Team did engage in a multi-year-long process to research, design, collect feedback, and iterate on the redesign.
Please note that registered users can change their skin by going to the Appearance tab in Special:Preferences. Anonymous users do not have the ability to change their skin. For a list of frequently asked questions, please see Wikipedia talk:Vector 2022/FAQ and mw:Reading/Web/Desktop Improvements/Frequently asked questions.
While most experienced editors are already familiar with what makes for a strong argument, this RfC saw a large influx of new editors, most of whom are readers who wanted to make their voices heard. Many of these readers are not familiar with Wikipedia's policy of consensus. The strongest arguments are those based on our policies and guidelines, while the weakest are those based on subjective opinion, and here is where we should start our discussion. This request for comment came soon after the change of the default skin, and many !votes were based on personal opinions about how Vector 2022 was better or worse than Vector 2010. While these are usually considered weaker arguments, they were not entirely discarded but were not given as much weight as other points.
There was an extensive discussion of the surveys and research presented by the Wikimedia Foundation (WMF) to support the proposed changes. While some participants believe the surveys organized by the WMF were skewed positively toward the new skin (such as by removing answers containing foul language), others saw the surveys as a reason to support the deployment of the skin. Those in favor of maintaining Vector 2022 also commented on the fact that the skin has been active on a number of smaller Wikipedias with varying degrees of acceptance.
As some participants noted, it's likely that very few of those commenting in this RfC have any experience with UI design and, as such, the opinions presented here are only that, opinions. The only concrete facts we have are the studies presented by some, which, for the most part, agreed with the changes brought by the new Vector.
Another point of contention was the fact that, while it is trivial for registered users to change back to the old skin if they dislike the changes, unregistered users do not enjoy that option. Many of those supporting the rollback were sympathetic editors who saw this as problematic. The only refutation offered to this was that the new skin was shown to be, according to the aforementioned studies and surveys, an improvement for readers, especially due to the reduced text width.
One of the most common points raised by those supporting the rollback to Vector 2010 was related to all the problems, bugs, and other issues that showed up when the new skin was deployed. Some of these problems were known since the previous RfC, which happened late last year, with the closing statement making it clear that the deployment of Vector 2022 depended on some of these problems being fixed beforehand. Many participants saw this as a failure by the WMF to follow our procedures.
Throughout the discussion, users posted links to Phabricator tickets showing that many of the problems being complained about were being worked on. During the time the RfC remained open, WMF employees also posted several replies, which included a list of concerns they had addressed and would be addressing in the future. Not only did these fixes mean the WMF eventually managed to comply with the conditions of the previous RfC's close, but it also raised the question of how strong each of the !votes focused exclusively on these issues were.
That is not to say that those opposing the rollback presented solely strong arguments. Besides the "I like it" style !votes, there were also fait accompli (or sunk cost fallacy) arguments, meaning that, since the change has already happened, there is no point in going back. Some also argued that choices like this are outside the community’s hands, per WP:CONEXCEPT.
At first glance, we have a clear numerical advantage for those supporting the rollback to the old skin, but many of these !votes were based exclusively on specific issues with Vector 2022, such as fixed text width, the large amount of whitespace, and the overuse of icons, as well as some accessibility issues. Others commented on bugs they encountered while using the skin. The WMF has fixed several of these issues–for example, the fixed width toggle not persisting–and more changes are likely to come.
Taking into account all that has been discussed above, we see no consensus to rollback the default skin on the English Wikipedia to Vector 2010. While those in support of rolling back had a numerical majority, their arguments were relatively weak and the WMF's changes to Vector 2022 since its deployment has addressed the concerns of many. Since we see the changes made by the WMF as compliance with the previous RfC, this means the previous close stands.
With regards to the second question presented in this RfC, arguments presented by both sides were very similar to the first question, in that some like the new limited width and others do not. Some of those supporting an unlimited width noted that many articles contain galleries, tables, etc., and were negatively affected by the new width. There was a lot of discussion on whether scientific papers reached any form of consensus on the best width, with both sides presenting studies with opposing views on the issue. The large amount of whitespace was one of the main concerns of those who supported the rollback of Vector 2022. Since the arguments are equal in strength, there is rough consensus to make unlimited width the default.
As we well know, consensus can change, and one of the suggestions made during this discussion was to open a new RfC in six months' time, after readers and editors have had time to adjust to the new skin. Editors interested should try and work alongside the WMF to acquire statistics, such as additional surveys, that could be used as the basis for the new RfC. This would also allow for more focused questions to be asked to participants, such as how to present the table of contents, one of the more contentious changes to the design, or if the default width should remain as is or be changed back to fixed-width.
Signed,
Isabelle Belato 🏳🌈 01:46, 16 March 2023 (UTC)
— Ingenuity (talk • contribs) 01:47, 16 March 2023 (UTC)
Should Wikipedia return to Vector 2010 as the default skin? ~ HAL333 20:32, 19 January 2023 (UTC)
Note: This RfC was moved from Wikipedia:Village pump (proposals) on January 21, 2023, with this edit. This page's discussions were moved to the /Discussion subpage on February 14, 2023, with this edit. InfiniteNexus (talk) 07:18, 20 February 2023 (UTC)
If all the concerns outlined above are satisfactorily addressed[...], the editors wrote. The WMF has not done this. Instead they added a button readers would need to push on every single page, every single time the readers follow a link or come in from Google or navigate to our site. This is comically inadequate, and it's hard for me to understand why readers would actually do so, instead of being frustrated into giving up and unhappily accepting what they find an inferior viewing experience. As 24.251.3.86 said on mediawiki, it's "far too burdensome to be useful or practical, and as such, basically may as well not exist for all the good it does." --Kizor 01:57, 20 January 2023 (UTC)
readers would need to push on every single page, every single time the readers follow a link or come in from Google or navigate to our siteThis is false. The toggle stays, at least for me. Aaron Liu (talk) 02:05, 20 January 2023 (UTC)
incognitois probably the issue, I assume this is implemented with cookies. I'm not sure whether or not this is a problem for the ethos goals though I'm more inclined towards "this is a problem". Aaron Liu (talk) 02:18, 20 January 2023 (UTC)
despite a community wide discussion that found there was no consensus for such a change. The ONUS was on the WMF to convince the community and they failed.- from the closure of the community wide RfC:
we see community support to roll out the change(though it should be noted that is preceded by
[i]f all the concerns outlined above are satisfactorily addressed then).— Qwerfjkltalk 20:44, 19 January 2023 (UTC)
there are privacy issues that prevent allowing IPs to choose a skin
and in our view no further RfC would be requiredAaron Liu (talk) 02:11, 20 January 2023 (UTC)
, then everything is useless.@Aaron Liu Lemonaka (talk) 02:17, 20 January 2023 (UTC)in our view no further RfC would be required
I'm sorry that the personal tools menu is causing you frustration. Out of curiosity, which tool in that menu do you use most often, and how many times per visit/session would you say you use it?I've never bothered to track how many times I click on each link, but I assume you mean from the drop-down menu. That would easily be my 'Contributions' link. I actually have a shortcut in my browser, I use it so often. Beyond me why anyone would want it to be hidden in a dropdown. I mentioned the watchlist in that previous RfC. Why use a symbol instead just calling it a 'Watchlist'? BTW, "Frustration"? I currently choose not to use V22, so it's not causing me any frustration. How are you doing? I suppose I am "frustrated" and opposed in general to the notion that replacing perfectly descriptive text with vague and ambiguous symbols is somehow an improvement. Are the symbols designed for illiterates or mind readers?
I think the closers of the last RfC identified that the main cause for opposition was the limited line-length (which you mentioned was your "big no-go").Like I said in the previous RfC, right after "no-go", the problem is the reduced width breaking the layout of tables and images, evident on countless articles including in the article the WMF chose to present to us as an example for that RfC. How tables are positioned on the page in relation each other has nothing to do with "reading experience". Implementing a skin that misplaces countless images and tables is sloppy and careless. When I raised this concern on another thread, the response was this,[1] implying the idea is for us (regular editors) to fix the problems the new skin has created. (I have no interest in doing that, fwiw) DB1729talk 15:46, 26 January 2023 (UTC)
It actively disrupts my reading and so it takes me longer to understand the content.Well you're among the minority of people then. I'm not saying that your opinion cannot be weighed I'm just saying that they decided to cater to most people.
Wikipedia has NO other means to receive bug reportsYou might be interested in our phabricator. Aaron Liu (talk) 15:16, 29 January 2023 (UTC)
Web pages aren't like the old iOS phone apps that were simply scaled up to fit onto on iPad screenBut that's exactly the point. Properly responsively designed pages shouldn't look like old iOS phone apps scaled to fit on a larger display, but Vector 2022 does look like that. That's a major part of the criticism that it looks like it was designed for a phone. Trynn (talk) 22:23, 28 February 2023 (UTC)
tc
16:17, 20 January 2023 (UTC)"makes every article look like a stub". Æo (talk) 15:16, 21 January 2023 (UTC)
advice or opinions of one or more Wikipedia contributors, as stated in {{essay}}. It's something to consider, but by no means is it mandated. —Tenryuu 🐲 ( 💬 • 📝 ) 23:55, 22 January 2023 (UTC)
?useskin=vector
to the url) but this doesn't propagate when clicking links. Should be easily be fixable IMO, so please do that. 90.231.239.98 (talk) 10:20, 22 January 2023 (UTC)"Many of the opposes below seem to fall into the "it's time for a change" category, but change for the sake of change alone is rarely a good thing. This is not an e-commerce or social media site; it's an encyclopedia. Readers come here for the article content, not for what some might call cutting-edge web design."Applause! The same as I think: there seems to be more attention on the "user's experience" than on the contents of the encyclopedia, while a great number of articles are in a wretched state. Æo (talk) 15:49, 22 January 2023 (UTC)
…
button, which makes things more inconvenient than they were before for no clear reason. I mean, look at the official screenshot — there's plenty of space to make the login button be one click away.≡
button by default. —pythoncoder (talk | contribs) 04:52, 23 January 2023 (UTC)why did it take 12 years to solveWinter, I guess.
work...better in mobile than actual mobileOn a phone, I don't think that's true. On table, well, ignoring the obvious editor improvements (since this is separate from the skin and people had been using the desktop skin on mobile to edit for years), the only improvements I see that can be seen as designed for mobile is just the iconifying, which I don't have much of a gripe with on desktop either. In fact with the pagetools rollout there are content flashes and crashes on way too small screens including tablets which might actually make v10 or mineurva more desirable on mobile. Aaron Liu (talk) 02:33, 29 January 2023 (UTC)
only knowing how to handle generic code borrowed from githuban insult. Aaron Liu (talk) 23:11, 29 January 2023 (UTC)
Log in
out of when the non-avian dinosaurs roamedGood one! Aaron Liu (talk) 16:53, 3 February 2023 (UTC)
there's no catch-all fix for this, but the sidebar ToC could highlight those sections which are partially/fully visible
harder to navigate, especially for people with disabilitiesI disagree. Besides tab navigation which got better, the buttons are a lot larger than text and are easier to click on. That outweighs needing to click multiple times. Aaron Liu (talk) 14:46, 5 February 2023 (UTC)
p { max-width: 45em; }
li, dd { max-width: 43em; }
blockquote p { max-width: 37em; }
form p, form li { max-width: none; }
it is unsalveageable and its core problems fundimentially poison it at the root, but you never actually listed what you thought were its core problems. Can you elaborate on this? I'm intrigued. Also, there is literally zero chance that a refined version of V2022 isn't deployed within eighteen months if they revert back to V2010. It'll probably be deployed by 2024. Cessaune [talk] 13:19, 9 February 2023 (UTC)
this had a consistency issue and I like the old desktop interface as it makes sense for editing on a computer and browsing articles
I WOULD NOT EVEN WANT TO USE IT ON MY PHONE Pondekuda46 (talk) 16:25, 13 February 2023 (UTC)
foundation doesn’t listen, doesn’t care, and doesn’t take it backEver heard of Wikipedia:Superprotect? Aaron Liu (talk) 17:41, 15 February 2023 (UTC)
from the readers' perspective, the sidebar is not a place for useful links. Most readers focus on the content area.This explanation makes perfect sense when you consider that editors can see translation links in the header. But only them. For the average reader, the tippy-top of the page is also not a home for useful links. Mebigrouxboy (talk) 05:30, 25 February 2023 (UTC)
ivory towercomment above is representative of the rollout process. I endorse 331dot's comment as well. ThadeusOfNazereth(he/him)Talk to Me! 21:09, 19 January 2023 (UTC)
tc
20:05, 26 January 2023 (UTC)
tc
20:11, 26 January 2023 (UTC)
tc
20:28, 26 January 2023 (UTC)
tc
21:38, 21 January 2023 (UTC)
tc
22:10, 21 January 2023 (UTC)
tc
22:34, 21 January 2023 (UTC)
tc
10:43, 22 January 2023 (UTC)It's objectively true that the white space serves no useful purpose.
used for the eyes' resting spots, so this claim is contentious. —Tenryuu 🐲 ( 💬 • 📝 ) 17:09, 23 January 2023 (UTC)
tc
17:20, 20 January 2023 (UTC)a pop-up window with the first few sentences of text accompanied by the infobox image (assuming there is one)is actually from a different feature which users can toggle at Preferences → Appearance → Reading preferences = Enable page previews. I believe it is enabled for unregistered users by default. —Tenryuu 🐲 ( 💬 • 📝 ) 00:12, 21 January 2023 (UTC)
This question is outside of the scope of what the community controls. See WP:CONEXCEPT.Rejecting this proposal on the grounds that it would violate WP:CONEXCEPT without the WMF claiming that CONEXCEPT applies is premature. If the WMF does make that claim then we can discuss this proposal on that basis, determining whether they are correct and if so whether an IAR exception applies, but until then we should proceed on the basis that it is subject to consensus. BilledMammal (talk) 14:57, 9 February 2023 (UTC)
encourage the WMF to implement this even if the en.wiki community disapprove. The old skin is embarrassing and backwards. The new one is better. We are not professional UI designers. See this comment by Joe Roe in the 2022 RfC also. — Bilorv (talk) 23:58, 21 January 2023 (UTC)
Should Wikipedia return to Vector 2010 as the default skin?As such the scope of the consensus that forms around this one will be as a result of the rollout of Vector 2022 a few days ago. Either a consensus will be found to keep V22 as the skin, or a consensus will be found to return to V10 as the skin, or unlikely no-consensus will be found. Sideswipe9th (talk) 01:32, 23 January 2023 (UTC)
You are cross, clearly. I kind of understand why, and I have some sympathies. But uh, my friends, the best critique we can come up with is: there hath been too much white space painted upon this veranda, and it looks like a wolf in a mobile telephone’s clothing? And now we want to burn the entire thing to the ground to prove that we have control over the sheeple? Well shoot, where I come from we call that boneheaded. If someone can show me research saying that line-length should be unlimited, or a credible design guide that says white space is bad, or find a popular text-based website that don't have a limited width, I will gladly eat my proceeding paragraphs of word pudding :)
WCAG 4 LIFE <3 <3 <3 <3 2600:1700:9FFC:34B0:3178:F130:73A8:2D06 (talk) 02:01, 23 January 2023 (UTC)
While, yes, support for going back is running higher here, the margin is far too narrow to suggest that the community is of the carefully considered opinion that a mistake has been made. If we really want a discussion like this to be seen as reflective of genuine community consensus, the right thing for those who have started this RFC to do would be to withdraw it immediately, and promise to hold it a year from now. Daniel Case (talk) 03:21, 24 January 2023 (UTC)
Why isn't it possible to use the visual editor here like in articles? Using visual editor opens up access and a voice to many more people.
no consensus for such a change, many, if not most, of the opposing views supported the change if some usability changes were done, and they are being rolled out (the right bar was rolled out just this week). Betseg (talk) 05:03, 27 January 2023 (UTC)
There have been quotes from the developers brought up elsewhere in this discussion indicating that one of the design guidelines was to bring the desktop design closer to mobile design standards.[citation needed] where?
Should I be constantly resizing my window as I go from site to site?– Of course not (and nor should you have to create an account or download an extension on every site for the same control) but if you actually believe that a particular line width is the best for your reading experience, why on earth would you need to? It seems to me that any need to contantly adjust when going from site to site can only be the result of overbearing web design, which v22 is a clear example of.
Most people aren't aware of the readability improvements from shorter lines...so I guess it's your duty as a web developer to take their ability to read in a certain way away from them, for their own good, of course? I find this attitude very worrying.
Data from Fandom indicates they see little use of their full-width toggle (less than 1%). I expect we will see similar results here too.I read
a mechanism [must be] available to achieve the following: [...] Width is no more than 80 characters or glyphs (40 if CJK).It seems to me that this requirement is automatically fulfilled by the native mechanism (window resizing) unless the site has styling that obstructs this method. In any case, it is possible to provide a non-native mechanism for this within v10 without forcing it on users by default. small jars
tc
17:34, 29 January 2023 (UTC)
"People hate change [...] Anytime we changed anything, there would be an outpour of negative feedback. This would mostly dissipate after the initial launch [...] Neigh sayers are usually the vocal minority, and will adapt"; this is quite stereotypical (and I see it has been repeated in many opposing comments) and disrespectful of critical views, which in many cases are very thoughtful considerations. I agree on
"how disassociated that side menu is from the content"; please see #Bring back the TOC. Æo (talk) 17:01, 30 January 2023 (UTC)
The majority of respondents reported that the new experience is easier to use or that the new and old experience are equally easy to use.The statement was true, but incredibly misleading; 60 users found Vector 2010 easier to use, 49 found Vector 2010 and Vector 2022 equally easy to use, and just 37 found Vector 2022 easier to use. BilledMammal (talk) 18:20, 6 February 2023 (UTC)
focusing on the text rather than having tons of useless wikigeek links on the side– Would we have that text in the first place without "wikigeeks"? The tools for improving Wikipedia should be exposed to every reader. Your comment only serves to demonstrate that v22 promotes a wikiconsumerist attitude and discourages boldness. small jars
tc
15:59, 26 February 2023 (UTC)"But I cannot deny that Vector 2010 is... well, very 2010. Wikipedia should evolve with the times, content wise but also in terms of UI and looks."I personally find the mobile-esque V22 to be more awkward and clumsy than V10, which in turn is wieldy and sleek. Evolution is not always in the right direction, and may sometimes turn out to be an involution. Æo (talk) 14:49, 1 March 2023 (UTC)
tc
17:38, 20 January 2023 (UTC)tc
16:20, 20 January 2023 (UTC)Only UI designers are qualified to objectively evaluate the merits of thisOnly artists can critique art, only game developers can critique games, movie directors can critique movies, writers can critique books, and so on. The general user who has to experience that has no say at all? Apple is only limited width for a section, google uses full width at 1080p when you search(and their email is always full width), nyt and wapo uses much more as well. Wikipedia is the most constricted version of any I have encountered, and has no mechanisms for using that extra space either, even fandom will fill the voids at the edges with wiki-art and ads. At ratios higher than 16:9 1080p, it becomes a tiny island in a sea of blindingly bright whitespace, with a practically invisible toggle that doesn't even work when logged out nestled in the corner of all that whitespace. Deadoon (talk) 11:45, 20 January 2023 (UTC)
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.Aaron Liu (talk) 15:31, 20 January 2023 (UTC)
If you prefer full width, there's a button to toggle that.
The groups seems quite small (~20 participants per group), especially that it was a questionnaireMost studies sadly, regardless of field, tend to have small groups. It's often expensive to get funding for larger groups, which puts them out of reach of many researchers. The major exception that I'm aware of is clinical trials in medicine, which can have group sizes in the low to mid hundreds.
em
units, there's no exact mapping from em
to CPL, as the rendered size of 1em
is relative with regards to the font-size
being applied to the element, but it is not relative with regards to font-family
. By default (ie, no font-size
override set) 1em
is the equivalent of 16 pixels on the user's device, regardless of what font-family
they are using.ch
value for max-width
or min-width
. That unit is always relative in size to the 0
glyph of the font-family
that is being used to render the output on a user's device. Theoretically there's no technical reason why the WMF couldn't expose a setting to both logged in and logged out editors that would directly and accurately allow them to set an exact number of CPL, by giving them direct control of the ch
value which is applied to the relevant max-width
properties. The only real "gotcha" to watch out for with ch
values is that some fonts like Helvetica or Georgia do not have fixed-width characters, so you will on occasion get uneven line justification. But again, the font-family
could be exposed as a setting to the user, which gets applied at rendering time. Exposing either or both of these settings will not affect page caching, because CSS interpretation and rendering is always done on the user's device. If the WMF have considered this as an option though, and ruled it out, I would be interested to know why, as I've not seen it discussed on either of these two RfCs.ch
value for max-width
, and font-family
value), similar in style to the patch being trialled by Jdlrobson in phab:T91201, that gives the user (whether logged in or out) direct control over the maximum number of characters per line. This would be instead of or supplementary to the straight on/off toggle for limited content width. This allows non-technical users to easily set an exact line length dependent on their needs, in a unit that is relative to the font being used to render the content.There is just one thing to change and you are done.Ok, pretend for a moment you've never made a website before, maybe even never programmed anything before. How do you know there's a property to change that will fix the problem you are having? How do you know what that property is? How do you know what value to set that property to? Assuming you can figure out that there is a
max-width
property you can set, how do you make sure that you're only overriding it for the main content area, and not any of the other defined areas on the site like the TOC sidebar or header? How do you know that HTML tags have optional class or ID parameters? How do you know how to limit your max-width
override to the specific subset of classes and IDs that only affect the primary content area?These decisions shouldn't be based on the personal design preferences of a small fraction..." describes the shift to V22 as the default pretty well. Tim O'Doherty (talk) 15:51, 25 January 2023 (UTC)
could vote-> could vote in a way that is binding. And if it is not, as that is the de facto state of the large rfc, there is no reason for this to 'double up' a previous, wider consensus. — Ixtal ( T / C ) ⁂ Non nobis solum. 14:44, 20 January 2023 (UTC)
Due to the sheer length and size of this page, discussions have been moved to a subpage, and only their titles have been kept below as a list. Please add new comments on the subpage, and not below. Thank you.
References