https://en.wikipedia.org/w/cruft.php?title=Page_name&morecruft_oldversion#Section_name, separating the page and section names that actual users need to have together to create direct links to article sections.
Kindly raze these changes to the ground, salt the earth, and then rehire a team of developers who have actually edited pages before instead of only knowing how to handle generic code borrowed from github. — LlywelynII 15:13, 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.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