Jump to content

Wikipedia:Requests for comment/Rollback of Vector 2022/Discussion

Add links
From Wikipedia, the free encyclopedia

The following discussion 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.


General discussions

[edit]

General comments

[edit]
  • Comment. I don't yet know what I think about the new skin yet; I'm actually trying it out instead of insulting the developers or thinking I'm smarter than them or cursing at them or any of this other unreasonable hostility. But what makes you think that this RFC will be more representative than the one they already did? Especially since people are more likely to complain than praise. 331dot (talk) 20:51, 19 January 2023 (UTC)[reply]
  • Revert to MonoBook, my favorite skin Why stop at 2010 vector? I use MonoBook which was the default before 2010 Vector, so let's go back to my favorite skin. It's also still the default on BulbaPedia, one of the largest Pokemon wikis, so at least one other large community agrees with me that Vector 2010 was inferior to MonoBook. This is all tongue-in-cheek, of course, because none of this affects me as a MonoBook user. I didn't like Vector 2010, so I changed the settings to use a skin I did like; I don't see how that's not a solution if the complaints are mostly aesthetic. — Wug·a·po·des​ 21:15, 19 January 2023 (UTC)[reply]
Wugapodes A big complaint I see is that IPs or users who rarely edit don't want to(for some reason) have to log in to use their preferred skin. I have to log in to my bank website every day to see how much of my money they have, I don't see how this is different. 331dot (talk) 21:19, 19 January 2023 (UTC)[reply]
I'm a strong proponent of unregistered editing, but if a reader feels so strongly about the aesthetics of a website, creating an account to save their preferences seems like a reasonably common trade-off all things considered. Unregistered editing comes with many, more serious trade-offs that those editors must accept---disclosure of IP info, unstable attribution, susceptibility to range blocks, limited participation in project governance---so I don't think adding "susceptible to decennial skin changes" is something I find too onerous to put on unregistered editors. — Wug·a·po·des​ 21:44, 19 January 2023 (UTC)[reply]
I'm not going to create an account just to "fix" what was never broken. 73.8.230.57 (talk) 01:58, 21 January 2023 (UTC)[reply]
Wikipedia is the free encyclopedia, no one should be forced to "become a member" (so to say) to read it properly. Clearly a lot of people are not comfortable with having to get an account, there are probably many different reasons (none of which I'm likely to be able to related to) but their reasons clearly exist and are important to them.★Trekker (talk) 15:18, 21 January 2023 (UTC)[reply]
@StarTrekker, they're forced to "become a member" to change the appearance of the site if they don't like it. — Qwerfjkltalk 19:26, 21 January 2023 (UTC)[reply]
I don't see what this comment is for. They aren't disagreeing with that. They're saying that you SHOULDN'T be forced to create an account. Aaron Liu (talk) 19:51, 21 January 2023 (UTC)[reply]
@Qwerfjkl And that is a major problem. It's becoming very clear WMF are not remotely interested in being benevolent dictators. They have become tyrants who rule by dictate. We must have a distributed Wikipedia with local storage. Centralized power will always become corrupt. Always. Humans just can't help themselves. Either the future is distributed, or we have no future worth living. Centralized information can always be changed or taken away. 2600:1700:1471:2550:6002:A2:F43C:2665 (talk) 22:20, 10 February 2023 (UTC)[reply]
I don't agree with any of this. WMF generally does a good job of keeping the pease. Situations like this they tend to get irritating, but, at the end of the day, nothing major is being jeopardized. To say that Centralized power will always become corrupt—WMF isn't corrupt. They are a non-profit, and aren't selling anything or employing ads beyond the occasional your money would be appreciated. WMF's goal isn't to make money, which is the number one corrupting factor. To say WMF is biased or WMF is being unfair or WMF is being illogical could be true, but they definitely aren't tyrants. If they fail to uphold the consensus that this RfC comes to, then maybe you could make that argument. They have generally upheld majority consensus in big issues like this, though, so I'm hinging on that happening here. Cessaune [talk] 23:30, 10 February 2023 (UTC)[reply]
To digress on an already overloaded page, I fear that some in the WMF do see making money as a major goal. Certes (talk) 23:48, 10 February 2023 (UTC)[reply]
Likely, but it's not the same as Youtube or Facebook or Reddit ,for example. Cessaune [talk] 00:11, 11 February 2023 (UTC)[reply]
No one is being "forced" to do anything. By your argument, anyone who wanted to use the scripts available for highlighting which users are Admins are "forced" to create an account in order to use that script. Disliking the fix-width text is fine, but claiming anyone is twisting your arm to make an account over it is rather overstating the severity of the issue. — The Hand That Feeds You:Bite 17:58, 23 January 2023 (UTC)[reply]
Corporate policy at work is 'no personal accounts on corporate computers' - and getting a corporate account is very nearly impossible. This isn't a case of 'do not want'; it's a case of 'not allowed by policy'. 192.157.110.190 (talk) 02:15, 20 January 2023 (UTC)[reply]
That's a thin reasoning. You can always use "Bill from Corporation ACME" as your username. I don't think the community will find fault in this username scheme unless you are WP:COI. – robertsky (talk) 03:16, 20 January 2023 (UTC)[reply]
Corporation might not like that though. "Only authorized people are allowed to represent the company" sort of thing. Anomie⚔ 15:36, 20 January 2023 (UTC)[reply]
+1 for monobook. Everything is where I expect it to be. But in all honesty thats probably a little bit of 'get off my lawn' coming through. --(loopback) ping/whereis 09:25, 21 January 2023 (UTC)[reply]
Another +1 for Monobook. I have found it the most useful skin by far since I joined in 2009. All controls are immediately accessible. Only the default font size could be a little bigger. Incidentally, I found that local (intranet-type) wikis often stick to Monobook. It's not about esthetics, it's about functionality. --Schlosser67 (talk) 11:39, 23 January 2023 (UTC)[reply]
Just out of curiosity: I've seen a lot of mentions of MonoBook (42 hits) and Timeless (17 hits)... but is anyone here still on Modern or CologneBlue? —pythoncoder (talk | contribs) 03:45, 26 January 2023 (UTC)[reply]
@Pythoncoder Modern and CologneBlue are no longer settable in Preferences, although you can still set it using the ?useskin URL param. Aasim - Herrscher of Wikis ❄️ 16:55, 21 February 2023 (UTC)[reply]
are no longer settable in Preferences[citation needed] —pythoncoder (talk | contribs) 17:05, 21 February 2023 (UTC)[reply]
I'm still on Modern although I have been experimenting with V22. Nthep (talk) 11:55, 7 March 2023 (UTC)[reply]
  • Comment: I think the RFC asks the wrong question. As I said in the previous RFC, if the WMF would just make "wide mode" the default instead of opt-in, there would be much wider acceptance of Vector 2022. As it stands, if IP readers want "wide mode", they have to click the toggle (if it appears for them; it does not appear in some wide browser windows) on every page. There is no persistent "wide mode" for logged-out readers. If "wide mode" becomes the default, an IP reader who wants a persistent narrower mode will only have to shrink their browser window. – Jonesey95 (talk) 21:18, 19 January 2023 (UTC)[reply]
....which kinda goes to the root of the problem here in that there is no single change that every user will approve of. Improvements can always be made. Suggestions offered. This isn't the end, it's the beginning. People could at least try it out, the WMF says most of its testing showed that people got used to it after a few days. People use it for five minutes and see a single change they don't like and then curse the developers or say they are stupid. 331dot (talk) 21:22, 19 January 2023 (UTC)[reply]
They needed/need to seek more and more specific feedback and integrate that into the design process. Nothing about curse or stupid. Some people might be quicker to get angry due to past history of WMF ivory tower and high-handedness incidents and that such seems to becoming systemic. North8000 (talk) 21:35, 19 January 2023 (UTC)[reply]
Fair enough- and I thank you for your civility- but asking for broad community input on every minor change is a recipe for disaster and obstruction to changes. I saw far more complaints that Wikipedia appears like it was designed in the 1990s than calls to keep it the same. 331dot (talk) 21:39, 19 January 2023 (UTC)[reply]
The absurd amount of white space in Vector 2022 is, and always has been, the primary objection to it. I haven't done a full count, but the first ten out of ten Oppose comments in the RFC mentioned the width problems, and they have not been fixed adequately. Many of us have tried to advise the WMF that making the white-space version opt-in rather than (sometimes) opt-out would greatly improve acceptance of the new skin, but our words fell on stubborn ears, unfortunately. As a result, we get lots of drama instead of a few fun, geeky conversations about how to tweak tools and menus to make them compatible with the new skin. – Jonesey95 (talk) 01:11, 20 January 2023 (UTC)[reply]
Yes, asking for input for every minor change would be needlessly bothersome - but changing the default skin for the entire site is not a minor change. WalnutBun (talk) 01:54, 20 January 2023 (UTC)[reply]
The problem is that the WMF has a pretty terrible record for adequately maintaining their development projects (VisualEditor, Page Curation, the mobile version, etc.). I am afraid that if we politely lodge our complaints without making a ruckus like this, they'll never fix anything and we'll be stuck with this new default skin that even many opposing the rollback agree has some issues. I'm pretty sure I'm not the only one. —Compassionate727 (T·C) 06:05, 21 January 2023 (UTC)[reply]
  • This isn't a minor change at all. Nothing close to previous changes in usability in my opinion. So to sit up and spout platitudes isn't helpful at all. Sorry.
    I find several style choices make the new version nigh un-usable, or at the least un-helpful and counter-intuitive. And I'd like to consider myself fairly computer saavy enough to navigate a webpage. I really dislike the moving of the table of contents (especially for talk pages). I never thought I'd see the day where the focus of a change to Wikipedia was to reduce navigation ability. - jc37 21:55, 19 January 2023 (UTC)[reply]
    @Jc37, but the point of moving the ToC is to aid navigation ability (as I'm sure is mentioned in the RfC). — Qwerfjkltalk 22:01, 19 January 2023 (UTC)[reply]
    I am happy to believe that was the intent. But's it's a pretty decent fail in my opinion, if that was the intent. So many of the changes seem to be to hide useability from the user. extra clicks, extra motion. This is not how to encourage people to engage in your website. - jc37 22:08, 19 January 2023 (UTC)[reply]
  • WP:CONEXCEPT remains pertinent reading from the first RFC, even if you happen to believe that RFC displayed no consensus for a rollout. Izno (talk) 22:17, 19 January 2023 (UTC)[reply]
    Yes, but one would hope they would use CONEXCEPT sparingly. I'm not sure that's been the case in the last 2 years. As they say, ultimate power only exists so long as you rarely use it. — Shibbolethink (♔ ♕) 18:07, 20 January 2023 (UTC)[reply]
  • Comment – I'm frustrated that WT:VECTOR2022 was not notified of this RfC. An RfC was already being drafted at WT:VECTOR2022#‎Requests for comment/Reverse deployment of Vector (2022) before HAL333 jumped the gun and started the RfC themselves. InfiniteNexus (talk) 00:46, 20 January 2023 (UTC)[reply]
  • Notice a post from a WMF account, Wikipedia:Village Pump (technical)#Vector 2022 Post-Deployment Update from WMF team. 331dot (talk) 01:32, 20 January 2023 (UTC)[reply]
  • This is a clear case of WP:CONEXCEPT per meta:Limits_to_configuration_changes. Anyways, Timeless or bust. Legoktm (talk) 07:49, 20 January 2023 (UTC)[reply]
    @Legoktm The swahili wikipedia already did this. They successfully passed an rfc to revert this because they didn't have the manpower to update help images. And WMF's response was not to immediately deny per your link, their response was to "discuss it". So I think this is an exception to that since the default skin IS being changed. Aaron Liu (talk) 12:46, 20 January 2023 (UTC)[reply]
    @Aaron Liu: to clarify, I think this should fall under CONEXCEPT. The WMF has recently decided to hypocritically switch its longstanding stance on this position after most recently using it to deny switching to a volunteer-driven skin, for reasons I've elaborated elsewhere. Legoktm (talk) 18:48, 20 January 2023 (UTC)[reply]
  • Here's what I'd suggest: at least temporarily bring back the old one, and have for a time on the main page at the top (like those "please donate" messages) a message saying "do you think wikipedia should use the new or old skin" (and include a link to the new/old versions). If the majority is new, change to the new version; if the majority want the old version, go with the old version. BeanieFan11 (talk) 16:30, 20 January 2023 (UTC)[reply]
  • Do an A/B test. We can simply A/B test Wikipedia with the new skin vs the old skin, and specifically ask readers which skin they prefer in an up-or-down manner. If the answer is the new skin, then it would not make sense to switch back from the new skin. If the answer is the old skin, then it would make sense to switch back to the old skin. An A/B test should not be challenging to implement whatsoever (just randomly assign 20 of the top-viewed pages of the past week and you should get a good enough sample), so I hope that this information would be clarifying. — Red-tailed hawk (nest) 17:05, 20 January 2023 (UTC)[reply]
    There was some sort of survey at mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey but the results seem to have been obfuscated by WMF. Aaron Liu (talk) 17:07, 20 January 2023 (UTC)[reply]
    I'm aware of that, which is why I'm asking for a straight up-down A/B test and survey. — Red-tailed hawk (nest) 18:04, 20 January 2023 (UTC)[reply]
    More than just obfuscation, the page is full of contradiction. "Insufficient usage: respondents taking the survey were only allowed a single pageview and a static screenshot of the new experience, which is likely insufficient to be able to answer questions around usability" followed a bit later by "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.". On one hand, they are telling us they doubt of their result being meaningful, on the other hand they have been using the same result to justify the push for Vector 2022. I don't really know what to think of that, I want to trust the WMF to do the right thing but ever since I started to take a look inside (Wikipedia and the WMF are some of the most opaque organizations I've ever seen) they keep giving me reason to not trust them. DerpFox (talk) 02:18, 21 January 2023 (UTC)[reply]
  • The issue of wasted spaced will be mostly moot after the pagetools deployment. Look at Vietnamese Wikipedia Ladsgroupoverleg 05:47, 21 January 2023 (UTC)[reply]
    Wait just a cotton-picking minute! Are you telling me the vast void on the right actually has an envisioned purpose, and they just decided to put it there before they had the thing ready to go in it? Why in the world would the powers that be make such a decision? Seems to me a lot of this brouhaha could have been avoided just by waiting to do the narrow pages at the same time as the tools. Smh. Ntsimp (talk) 17:33, 21 January 2023 (UTC)[reply]
    Woah, what??? THat space is supposed to be used???
    These look like regular links on the left sidebar, why do we have to move them to the right? Aaron Liu (talk) 19:53, 21 January 2023 (UTC)[reply]
    Hi @Aaron Liu - thanks for the question. We've just deployed this and I'll be posting a longer update in a little bit but wanted to give you a quick answer here too. In Vector legacy, the left sidebar/main menu showed tools that were both relevant to the page as a whole (global navigation such as main page, random) as well as tools that were only used for the page itself (related changes, permanent link, etc). More page-specific tools were available in the more menu in the top right as well, which meant that page-specific tools were split across two separate menus. Many new editors found this confusing. Currently, we've collected them in a single menu and separated them from the links that work across the entire website so that readers and new editors will have an easier time being able to distinguish what each link does. If you're curious, more info is also available on the project page. OVasileva (WMF) (talk) 00:01, 24 January 2023 (UTC)[reply]
  • Seriously, why is the "Log in" button buried under a mystery menu when there's plenty of empty space nearby? —pythoncoder (talk | contribs) 06:55, 21 January 2023 (UTC)[reply]
  • Comment: Just wanted to mention while a lot of focus seems to be on text line width, I think contrast is just as big of an issue. The old Vector has different tones of white and grey that help to frame the content. The new look is almost entirely #fff white with around 40% of the space being completely empty. It's extremely harsh on the eyes, especially since there's no option for a dark theme. --Darksal Axe (talk) 11:35, 21 January 2023 (UTC)[reply]
    Very much agree with this sentiment. The grey sidebar with blue border surrounding the article on top left and bottom is very important to the look and identity of Wikipedia, and losing it is a big shame. AsmodeanUnderscore (talk) 16:28, 21 January 2023 (UTC)[reply]
    There was a great mockup of some different ways to tweak Vector 2022 to make this more distinguished. I like #9 personally. Ckoerner (talk) 15:33, 23 January 2023 (UTC)[reply]
    Although I dislike V22 layout overall, I like #9 proposal the most. I'm one of the advocates for a light grey background to non-article areas. Can any push an RFC for this, if necessary? Thanks. 37.134.90.176 (talk) 08:35, 26 January 2023 (UTC)[reply]
    I'm surprised to see here: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Visual_Refinements#Borders_and_Backgrounds_2 that most votes in June/July 2022 survey were to #9 option, but they actually deployed V22 with full white #1 (minimalist). As I and many suspected, Surveys and RFC and consensus, etc., were only pantomime. The move was decided largely in advance. This upsets me. This is why I'm so critical. 37.134.90.176 (talk) 09:01, 26 January 2023 (UTC)[reply]
    Anyway, to call survey results totalling only 41+15+6+18+7+23+16+16+58 = 200 respondents for that point its a bad taste joke. Is this what you call "we've carried out surveys" and "we've calling for consensus"??? I can't believe it. 37.134.90.176 (talk) 09:12, 26 January 2023 (UTC)[reply]
    I gather from this phab task (scroll down to the most recent comments) that the background colour is still under discussion. @AHollender (WMF): There seems to be a lot of support for Zebra #9; what are the chances of it being deployed in the near future, or at least tested further? Sojourner in the earth (talk) 09:42, 26 January 2023 (UTC)[reply]
    Did any realized that Phabricator in itself has all-page light grey background??? So, Why what is "good" to Phabricator its "bad" to Wikipedia? As far I know, there is no known discussion to make Phabricator all-white background in order to be "consistent"... 37.134.90.176 (talk) 12:01, 30 January 2023 (UTC)[reply]
    Because it shouldn't be, like structurediscussions boards there should be contrast between separate comments. Also because phabricator hasn't been maintained for 1.5 years. Aaron Liu (talk) 13:20, 30 January 2023 (UTC)[reply]
    Maybe you didn't catch the irony. Of course, the current color scheme for Phabricator suits fairly good to its purpose. The key word here is "consistent": the user who opened T259240 argued to set the new Wikipedia skin all-white with this only conclussion. And WMF agreed upon him, and now all is white bed sheet. Zebra #9 proposal was very similar to current Phabricator's look, but it was deprecated by WMF. Aside personal tastes, high contrast all-white RGB hurts the eyes of many, due to the blue wavelength. It's about visual ergonomy and comfort. There are plenty of studies about this point (many more than that advocating for narrow texts on desktop PC, for sure). Please read Biological effects of high-energy visible light. Thank you. 37.134.90.176 (talk) 15:19, 30 January 2023 (UTC)[reply]
  • Structure of this page: I presume, disucssions will be eventually archived. Maybe it would be clearer if only signatures should be place here, perhaps +a link to a disucssion which represents each one's opinion. Also, where do we place our signatures? The anchors direct us at the top of each section: so, it is normal to add every new opinion+signature at top. Thank you Sarri.greek (talk) 14:28, 21 January 2023 (UTC)[reply]
NO, you always add things at the bottom just like any regular talk page.
  • Comment There are positives and negatives to the new theme. Making small changes to it may be better than reverting entirely. The two largest improvements are placing the contents on the sidebar, and limiting the width of lines. It's now far easier to jump between sections of articles. Limited line widths are more readable, there's extensive research supporting this. The largest downside is lack of color. While flat UIs are all the rage, color and shading make it easier for your eyes to find things on the page. The resulting look is less "clean" and "modern" but faster to use. The Quirky Kitty (talk) 14:23, 21 January 2023 (UTC)[reply]
  • Comment: I do not see them rolling back to Vector2010: the Vector2022 skin has already been put in place in many, many versions of Wikipedia. Same goes for making changes to Vector2022 (e.g. in the width): other communities already use the current Vector2022 and are used to it. Veverve (talk) 13:03, 22 January 2023 (UTC)[reply]
    @Veverve WP:FAIT accompli is never an accepted argument. Aaron Liu (talk) 14:26, 22 January 2023 (UTC)[reply]
    Be aware that the arbitration statement you cited applies specifically to editors making edits, and not to Wikimedia or office actions. 🌈WaltCip-(talk) 15:48, 22 January 2023 (UTC)[reply]
    We should not accept fait accompli as an argument, even if ArbCom's words of wisdom do not apply here. Certes (talk) 15:53, 22 January 2023 (UTC)[reply]
    According to this and this comment, respectively from the French and from the Swedish Wikipedia, Vector 2022 caused strong grassroots opposition from the respective communities, which were largely ignored. Æo (talk) 20:09, 22 January 2023 (UTC)[reply]
    According to T317529, there was a 3.81% among editors and 13.43% among active editors on frwiki. I couldn't find any data for svwiki. Note that the definition is number of users who optout vector2022 out of editors who edited at least 1 edits or [for "active editors"] 5 edits on its wiki between 2021-11-01 and 2022-08-31. Aaron Liu (talk) 21:12, 22 January 2023 (UTC)[reply]
    Wait a second. I think you meant the Swahili Wikipedia(swwiki) not the Swedish Wikipedia. I admit that swwiki wholey opposed the change after the change was enacted. However WMF has not denied to change them. THeir latest message was 6 days ago We have discussed internally and have prepared a few options for moving forward. We've written up these options for next steps and plan on sharing them with the Swahili community on the Swahili Wikipedia Village Pump as well as scheduling a meeting with the community where we can make a plan on moving forward together. How does this sound? replying to something one and a half month ago which does make me question their good faith, but the swwiki matter is still inconclusive since swwiki has not replied since. Aaron Liu (talk) 21:22, 22 January 2023 (UTC)[reply]
I am wondering how many times the ones who prefer the Vector 22 already enjoyed not having to scroll all the way up through all sections but were able to just click on the top button in the left sidebar.Paradise Chronicle (talk) 19:42, 22 January 2023 (UTC)[reply]
I have set Vector 2010 as my interface in global preferences, but when I am logged out I am forced to use Vector 2022, and I continue to think that the new lateral ToC is the foremost problem (or on par with the width problem) of the new interface. The new ToC does not provide a clear overview of the articles' structure, I have to scroll and click continuously to view the collapsed subsections, and I never use the "top" button to jump to the lede. The new ToC is a disaster. This or this version of V22 with *both* the fixed in-article ToC and the sticky ToC following the screen would be much better. Æo (talk) 19:58, 22 January 2023 (UTC)[reply]
First of all all I see here is you criticizing the TOC's treatment of long tocs and collapsing headers. I get the impression that you don't think any of the rest is a problem, so if that's not what you think, please let me know.
Secondly don't you also have to scroll down in Sushi? Song doesn't demonstrate what will happen for long TOCs but I'm assuming it'll also get a scrollbar. you have to scroll and click either way. If you're talking about the collapsible headers, the TOC automatically expands the headers if the TOC is short so you won't have to click on short articles/pages(such as this one). It only collapses when the TOC is long enough and I don't see a better solution for long pages. Are you saying that you think there should be a preference of some sort to always auto-expand? Aaron Liu (talk) 21:03, 22 January 2023 (UTC)[reply]
@Aaron Liu: In my opinion, with the new lateral sticky ToC there is a sort of disarticulation of the correspondence between the sticky ToC itself (with its subsections) and the article (and its subsections), apart from the informative, illustrative, and structural problems already underlined in my previous comment(s) (i.e. the ToC under the lede as in V2010 has informative, illustrative and structural functions: general overview of the article and division of the text lead from the text body, as pointed out by StarTrekker here and by Dc.samizdat here). With both V2010 and V2022 I have to scroll the article (which is obvious, and I have nothing against it and I do not mind doing it); with V2022 I have to scroll *both* the article and the sticky ToC, and I have to click on the sticky ToC's sections to see if they have subsections. The ToC as a real ToC should be under the lead and always fully expanded and with sections numbered; as pointed out by Dc.samizdat in his linked comment, the new lateral sticky ToC is something completely different, and I would say that it is no longer a ToC. Something in the wake of the Sushi and Song versions of V2022 would solve at least part of V2022's problems.
As for the other problems beyond the ToC, the serious ones in my opinion are the limited width and the hidden toolbar (which has been replaced by the sticky ToC), and also the "article/page" and "talk" buttons which should be put back over the page's title and not under it. The languages menu and the new user buttons in the upper right corner of the screen are not a big problem and may be even better than their V2010 versions (the user buttons in particular; I have not experimented and thought much about the languages menu). The only things that I like about V2022 are the new colour palette and the new logo in the upper left corner of the screen. Æo (talk) 21:47, 22 January 2023 (UTC)[reply]
And I remember that the Chinese Wikipedia already had both the classic in-article ToC *and* a blue arrow that appeared in the lower right corner of the screen when the ToC was off-screen and allowed to jump directly to the top of very long pages.--Æo (talk) 21:02, 22 January 2023 (UTC)[reply]
A variation of these arrows also appear in the WP:TEAHOUSE Aaron Liu (talk) 21:07, 22 January 2023 (UTC)[reply]
wait, actually, the arrows are {{Skip to top and bottom}} on this Wikipedia. Aaron Liu (talk) 16:12, 24 January 2023 (UTC)[reply]
comment Most of users who commented here are login users. Please be careful when make a conclusion, login user can change back to vector-legacy by setting preference, while IP users cannot. Please take a look of the misleading of the statistics. Lemonaka (talk) 20:18, 22 January 2023 (UTC)[reply]
  • We began by considering the current default experience on desktop (Vector) and asking ourselves: in what ways can we improve upon this?. From Research and design: Phase 1. Please don't ask yourselves. Ask the users, employing proper sampling, testing and analysis. Hint 1: if there is no groundswell against the existing regime, ask yourselves something else. Hint 2: if there is no clear benefit fo users, stop there. Hint 3: if there is no perceived benefit but there is an actual one, change user perceptions before forcing a new default. Thanks. 24.103.63.182 (talk) 20:45, 22 January 2023 (UTC)[reply]
  • Comment: This RfC has seen a lot of people give their opinion but is no closer to consensus than before it started. When you get rid of all the personal skin preferences and the appeals to/insults of various persons/orgs, there are only a few things I see as really being argued over: 1) Whose opinions matter? IPs? Devs? The WMF? How can this be gauged? 2) Was the previous decision justified, and if not, is the result just an unchangeable fait accompli? And 3) How painful/difficult would it be to reverse the decision? Without these core things being settled I don't see anyone getting the consensus, though tbh the Vector 2010 side (my side) has the most to lose by not presenting a compelling case. --Jeremy Jeremus (talk) 17:43, 23 January 2023 (UTC)[reply]
Answers are in the comment above yours. The hints offered have universal application. 71.105.141.131 (talk) 17:49, 23 January 2023 (UTC)[reply]
  • Comment: What about Timeless? I didn't even know Timeless existed until like right now, but it seems to me to largely do all the things Vector 2022 does, while having been made first, specifically for the purpose of fixing the problems with Vector, and seemingly has none of the problems that Vector 2022 appears to have?
    Is there a good reason for not talking about making the default skin Timeless beyond "nobody's seriously brought it up"? Was there some previous discussion about it in ye olden days of 20-whatever that I missed? Please ping on reply. casualdejekyll 23:03, 23 January 2023 (UTC)[reply]
    @Casualdejekyll: The WMF has recently decided to hypocritically switch its longstanding stance on this position after most recently using it to deny switching to a volunteer-driven skin, for reasons I've elaborated elsewhere. —Legoktm Aaron Liu (talk) 01:27, 24 January 2023 (UTC)[reply]
    @Aaron Liu - This might be a little "wishful thinking" of me, but do you think the community would accept starting an RfC on setting Timeless to the default skin on enwiki? In the very near future? casualdejekyll 14:29, 24 January 2023 (UTC)[reply]
    It’s certainly more likely than accepting v22, but I don’t think the WMF would accept that, unlike v22. Aaron Liu (talk) 14:44, 24 January 2023 (UTC)[reply]
    Well, my "hot take" is that the WMF made their bed, so they must lie in it. If enwiki consensus can pick between v10 and v22, then it must be able to pick Timeless.
    I think such an RfC is worth considering once / if this one runs its course - it will take significant preperation work to launch a proper proposal on it which I might start myself soon (but no promises, I have a tendency to promise I'll write something on wiki and then not write it, unfortunately) casualdejekyll 18:07, 24 January 2023 (UTC)[reply]
    @Casualdejekyll: I agree with you, the WMF has changed the rules of the game and as such, if the community can decide between Vector variants, then it should also have the power to pick Timeless (I fully disagree with this on principle, but the ship has sailed).
    That said, in my opinion (developer hat on), Timeless is not ready to be the default skin today, my estimate is that it's 6 months of engineering work away (e.g. Jorm has some tweaks he recommends). I think an RfC would be better framed as "Invest in Timeless so it can become the default skin". Happy to work with you and others on this.
    Fundamentally getting editors to accept a new skin is a PR battle. The fact that Timeless was created by a volunteer Wikipedian, who wanted to make a better skin for Wikipedia, and embraced by volunteers rather than being pushed by WMF should give a significant advantage. I hope. Legoktm (talk) 19:29, 25 January 2023 (UTC)[reply]
    I agree with this. As someone who's been using Timeless for quite some time, it's a great skin, but not without its issues (e.g. article content falls below infoboxes after publishing an edit). I would immediately prefer it over Vector 22 being the default skin, although it definitely needs tweaking. XtraJovial (talk • contribs) 20:26, 4 February 2023 (UTC)[reply]
  • Comment. Everyone here has the right to an opinion, but I find it alarming how many individuals seem to be opposed to the rollback under reasons such as "you'll get used to it", "we can't roll it back" or "you people need to stop being opposed to progress". These arguments range from simply incorrect (#2) to passive-aggressive personal attacks (#3). We need to focus on what's really important here - the question of if this change is beneficial to the reading and editing experience here on Wikipedia. DarkSide830 (talk) 08:15, 24 January 2023 (UTC)[reply]
    Yes, that's level-headed. I hope more people can grasp that. -- HLachman (talk) 12:33, 24 January 2023 (UTC)[reply]
  • Comment. Here's an article on ycombinator that may provide relevant insights: Whitespace killed an enterprise app. Wikipedia is mentioned positively (but that was before the recent Vector rollout). -- HLachman (talk) 12:33, 24 January 2023 (UTC)[reply]
  • Comment. The desire to improve and make Wikipedia more readable is laudable. However, these changes clearly lacked consensus. I did not know about them until they were implemented. I think a wiser way to go about it is to make improvements incrementally; making design decisions one by one, seeking community input, implementing them piecemeal, and getting feedback on each individual design piece. Also it would be beneficial in starting with making limited and optional rollouts by first going to Beta, and testing there what level of adoption and acceptance they get. This wholesale change was too big and sudden to work well. It is more difficult to have a nuanced and constructive conversation about how to refine a change, when there are many happening at once. If changes had been implemented bit by bit, it would be easier to refine and yet keep the good parts. Al83tito (talk) 17:05, 24 January 2023 (UTC)[reply]
    I like the idea of incremental updates. The comp I see is the omnibus bills that the US Congress passes (bear with me please, this is NOT a FORUM comment). In theory, it can only take 51% of people being supportive of 51% of a change to generate a "consensus", as I believe occurs in the case of these bills. This generates change, but can get less desirable elements to come into effect simply because of a narrow consensus in favor of other elements that have been attached to them. What is clear is a more drawn-out process to vet specific changes was needed, and more input requested into each change rather than more or less just requiring this 51% in support of 51% issue from happening. DarkSide830 (talk) 22:44, 24 January 2023 (UTC)[reply]
  • Longer time to change language.
- In Vector 2010 I do: move the mouse wheel, and see ALL language links. I can also start typing the first letters of the language name on the page and the selected link will be highlighted and the window will scroll to it.
- In Vector 2020 I have to: move the mouse to the right place on the screen and click the icon. As a result, I will see a TINY window with a list of languages that I have to scroll through to see them all. This may make sense on a mobile device, but on PC it's just sub-optimal, wasting the user's time. Freja Draco (talk) 18:03, 25 January 2023 (UTC)[reply]
"By making all design elements (menus, buttons, links, etc.) flat, distinguishing what function an element serves may become more difficult, for example, determining whether an element is a button or an indicator.[22][23] Research has shown that flat design is more popular with young adults than older adults. Research also showed that, while young people seem faster at navigating flat designs, they also have trouble with understanding the user interface.[24] In 2013 Jakob Nielsen, an expert in user interface design and usability, dubbed flat design as a «threat to tablet usability» (...) Nielsen group conducted research in 2017 that showed that use of interfaces using flat design was 22% slower on average". Freja Draco (talk) 18:24, 25 January 2023 (UTC)[reply]
  • Probably would've been better to examine some parts of this separately. The sidebar is much wider than it needs to be, with far to much white space, and frankly imo the old vector was already inferior to monobook in that regard. The TOC also has problems, which others have likewise already elaborated on. On the whole not to my taste, but since I'm going to keep using custom css either way it's of minimal personal consequence, and the very fact that I'm commenting here means I'm not a representative user. From a limited and unscientific survey I conducted of more typical users the inclination is to the older vector, albeit somewhat weakly. Perhaps if the situation were reversed there would be the same level of preference for the familiar over the new. It is rather embarrassing that the only non-technical way for users to choose skins is by using preferences with an account. 74.73.224.126 (talk) 01:23, 27 January 2023 (UTC)[reply]
  • Comment Is there a date voting ends on this? --Aaron106 (talk) 03:12, 27 January 2023 (UTC)[reply]
    First of all, no. Secondly, please read WP:!VOTE. Last but not least, what a coincidence, we're both Aarons! wooooooo Aaron Liu (talk) 03:15, 27 January 2023 (UTC)[reply]
  • Less information density. Wikipedia is not a showcase of a company that is just supposed to look nice and impress the recipient. Wikipedia is an encyclopedia, it is a source of information, so if there is less of this information in the same space, both in the menu area and in the content, it completely misses the purpose of its existence. Freja Draco (talk) 12:51, 28 January 2023 (UTC)[reply]
  • Comment I don't think I've ever seen a case where a website changes their design then rolls back to their old one. I highly doubt that WMF will revert back back to Vector 2010 regardless of the outcome of this RfC. Some1 (talk) 01:39, 29 January 2023 (UTC)[reply]
  • Fix it. Rollback doesn't have to mean abandon. Address the issues raised by the community and get it to a state where people can be happy with it. --Frogging101 (talk) 00:59, 2 February 2023 (UTC)[reply]
  • Comment In order to better evaluate the new skin in a more objective manner, can someone provide a link for the original approved Statement of Requirements that listed the deficiencies of the then current default skin (V2010) that these new changes were meant to correct? This would allow us to compare how well the new skin (V2022) meets those benchmarks. Loopy30 (talk) 02:20, 10 February 2023 (UTC)[reply]
    @Loopy30 An informal closure review along with the quoted "requirements" were discussed at User talk:ProcrastinatingReader § Review of your closure Aaron Liu (talk) 02:28, 10 February 2023 (UTC)[reply]
    No, I am not looking for the reaction by en-wp editors to either the roll-out (this page) or to read the request to review the closure of the previous RfC on its deployment (the link you provided above). Instead, I am looking for a (short?) list of those elements of V2010 that were identified as being broken or in need of further development with the rationale of why these shortfalls needed to be addressed by a new skin (V2022). As we are being told that this skin has been three years in development, I would guess that the WMF approval date of this document was sometime about ~2018. Loopy30 (talk) 02:52, 10 February 2023 (UTC)[reply]
    Ah. I don't see some concentrated document but I do see snippets at mw:Reading/Web/Desktop Improvements § Currently, the interface… and mw:Winter § Purpose Aaron Liu (talk) 13:10, 10 February 2023 (UTC)[reply]

Publicizing this RfC

[edit]

I've notified Wikipedia talk:Vector 2022, Wikipedia:Village pump (policy), Wikipedia:Village pump (technical), and Wikipedia:Village pump (WMF), but most users do not watch those pages. How can this RfC be publicized to as many users as possible? I'm thinking mass messages to all active Wikipidia users, is that feasible? InfiniteNexus (talk) 01:17, 20 January 2023 (UTC)[reply]

Also notified Wikipedia talk:Requests for comment/Deployment of Vector (2022). InfiniteNexus (talk) 01:33, 20 January 2023 (UTC)[reply]
And mw:Talk:Reading/Web/Desktop Improvements. Not sure if notifying WP:AN is in order. InfiniteNexus (talk) 05:08, 20 January 2023 (UTC)[reply]
WP:AN would make sense to me. — Shibbolethink (♔ ♕) 18:00, 20 January 2023 (UTC)[reply]
I've posted there, and I've also asked them about potential mass messages to publicize this RfC. See WP:AN#Wikipedia:Vector 2022 has an RFC. InfiniteNexus (talk) 05:05, 21 January 2023 (UTC)[reply]
NO, do not use mass message to publicize this rfc, that is using a hammer to crack a nut that will result to the displeasure of many.
There's an essay at WP:Publicising discussions. I have already done {{Centralized discussion}} and I started a discussion for adding it to watchlist notices(the latter of which one editor objected to). I don't think this warrants a site notice though. Aaron Liu (talk) 01:23, 20 January 2023 (UTC)[reply]
I'm aware of the essay, but I'd argue this is an exceptional case since it literally affects the entire community and the millions of users who use the English Wikipedia. The closest comparison I can think of is ArbCom elections, which also uses MMS, but even that does not have as large of an impact as a UI change. InfiniteNexus (talk) 01:33, 20 January 2023 (UTC)[reply]
This RfC isn't THAT significant. Just following the guidance under "...affecting the whole community" and "General..." would be enough. Aaron Liu (talk) 01:41, 20 January 2023 (UTC)[reply]
It is extremely significant. It affects every single page view by every single user, whether logged in or not. That's billions of impressions daily. This is far more significant/important than whatever esoteric internal governance issues appear to be the subject of the other RFC solicitations linked at the top of this page.
Consider that most internal decisions presumably don't have tons of people creating new accounts just to argue against the decision. IWantTheOldInterfaceBack (talk) 02:12, 20 January 2023 (UTC)[reply]
Yes but mass messaging and 100% sitenotices would spam every user. Your proposal below is better. Aaron Liu (talk) 02:23, 20 January 2023 (UTC)[reply]
If not all active users, at least everyone with extended-confirmed permissions or above who has made at least 5 edits within the past three months. Heck, we could even just reuse the mailing list for last year's ArbCom elections. Any other method would be too passive, and we can see how that approach failed last time. InfiniteNexus (talk) 04:19, 20 January 2023 (UTC)[reply]
Fully agree. These changes effect everyone and everyone should get a chance to weigh in on it. I still support a site-wide poll for the next week to get the best possible data about where users' stand. 2600:1700:1471:2550:4102:7C99:2804:8FC3 (talk) 21:09, 20 January 2023 (UTC)[reply]
I was that editor 😲 Terasail[✉️] 21:55, 20 January 2023 (UTC)[reply]
yes 🤓 Aaron Liu (talk) 01:58, 21 January 2023 (UTC)[reply]
YES, notify everyone, this is extremely important and all editors should be made aware that they get a say.★Trekker (talk) 22:03, 20 January 2023 (UTC)[reply]
Proposal: use some mechanism (perhaps a random number generator?) to send an alert to 1 out of 100 pageviews soliciting feedback. Qualitative feedback is far more useful than the design team's dubiously meaningful statistics anyway! IWantTheOldInterfaceBack (talk) 02:10, 20 January 2023 (UTC)[reply]

@InfiniteNexus: In my opinion, this RfC was a bit rushed and not well-thought-out. It would have been better to plan carefully how to advertise it to all users, both registered and unregistered. Also, while RfCs are not polls, I think that it would have been better if the comments were split into two sections, support and oppose, and numbered as it was in the previous RfC. Æo (talk) 16:20, 20 January 2023 (UTC)[reply]

I agree. Separating into sections was what we were planning to do, as being discussed on WT:VECTOR2022, but then another editor jumped the gun and created this RfC without even consulting WT:VECTOR2022. If they had, they would've noticed the discussion where the RfC was being drafted. This was the format that was being planned, which is far superior in my opinion. It was also intended to be hosted on a standalone page, but I'll save my comments on that matter at Wikipedia talk:Village pump (proposals)#Move Vector RFC to subpage. InfiniteNexus (talk) 16:29, 20 January 2023 (UTC)[reply]
What's stopping us from switching this RfC to a support/oppose/discussion format? It's still new and managably small, reordering the !votes into categories would be a bit of work but I could do it. Plus it would probably solve the issue of people mistaking question #2 for where to weigh in on #1 - that's rapidly become a problem. --Kizor 17:44, 20 January 2023 (UTC)[reply]
The only thing I can think of is the sheer volume of new responses causing Edit conflicts. Aaron Liu (talk) 17:55, 20 January 2023 (UTC)[reply]
I've worked in articles for ongoing disasters that had far greater volume of edits than this. The volume here is not ideal but it's manageable. Move a couple dozen at a time, incorporate the edits that happened during the switchover. There'd be a bit of disruption during this, but a lot less, I think, than from leaving things as is. We need to take action to differentiate question #2 and any & all further questions from the main event. Should I get cracking? --Kizor 18:05, 20 January 2023 (UTC)[reply]
InfiniteNexus and another user have proposed to move the RfC into a separate page (cfr.). I think you should reorganise the comments while moving them there. Æo (talk) 18:14, 20 January 2023 (UTC)[reply]
I think we should keep those jobs separate. Trying to do both at once would probably lead to more disruption, not less, and take longer, meaning more potential edit conflicts, meaning more time spent sorting those out, meaning more potential edit conflicts, et al. This may not be rocket science, but it still calls for keeping payloads small. Also, do you know how long it'll take to get the support to go through with the move? --Kizor 18:43, 20 January 2023 (UTC)[reply]
I don't think that the move will require many support votes to be done, after all a formal RfC in the style of the previous one is what they were planning since before this RfC was opened. But, if InfiniteNexus agrees, proceed with the reorganisation. Then this entire page will likely become a redirect. Æo (talk) 19:09, 20 January 2023 (UTC)[reply]
InfiniteNexus is in favor. I'm pulling the trigger on this change. Brace yourselves. --Kizor 19:32, 20 January 2023 (UTC)[reply]
Thank you and @InfiniteNexus for cleaning this entire thing up! Aaron Liu (talk) 01:58, 21 January 2023 (UTC)[reply]
I had to do plenty of cleaning my own mess up, thank Red-tailed Hawk for cleaning up after me. --Kizor 02:31, 21 January 2023 (UTC)[reply]
Happy to help. InfiniteNexus (talk) 04:13, 21 January 2023 (UTC)[reply]
I do have some concerns on Question #2 though. CUrrently it's awkwardly under discussion which means that subscribing you to discussion also subscribes to future !votes. It also isn't really discussion. I'm not sure to move it above discussion or below though. Aaron Liu (talk) 02:08, 21 January 2023 (UTC)[reply]
I got nothin', you're the smart one and I don't know anything about subscribing. --Kizor 02:31, 21 January 2023 (UTC)[reply]
Since the RfC has its own subpage now, maybe the second question can be a level 2 heading above §Discussion? That way comments about the second question can go under §Discussion. —Tenryuu 🐲 ( 💬 • 📝 ) 02:44, 21 January 2023 (UTC)[reply]
Ok, now I've done that, now the looooong title of that section just looks weird. However the q#2 part can't be dropped bc of how many people talk about it. Would moving the rest of the header to the body and signing it with @IWantTheOldInterfaceBack's signature be a good course of action? Aaron Liu (talk) 02:57, 21 January 2023 (UTC)[reply]
I'm not a regular at RfCs, so I'm not sure what the convention is behind how headings should be formatted or what they should contain, but it's not the longest I've seen, so I'm not bothered by it. ¯\_(ツ)_/¯ —Tenryuu 🐲 ( 💬 • 📝 ) 03:08, 21 January 2023 (UTC)[reply]
The current title is fine, I don't see a need to change it. InfiniteNexus (talk) 04:13, 21 January 2023 (UTC)[reply]
I've finished inspecting the work and contacted all users whose formatting I changed or who should be asked where they'd like their remarks to go. --Kizor 02:32, 21 January 2023 (UTC)[reply]
Note that this rfc was not from infinite nexus but from Hal 333 without much communication or deliberation. Aaron Liu (talk) 16:30, 20 January 2023 (UTC)[reply]

Note: feel free to reword the text to question #2 for clarity if necessary (of course without changing the substantive meaning). I'm not super familiar with all the jargon used around here and I've been using "skin", "design", and "interface" interchangeably. IWantTheOldInterfaceBack (talk) 18:22, 20 January 2023 (UTC)[reply]

I think it was great as-is. But I just changed "the new design" to "Vector 2022" to be a bit more future-proof and remove any need to debate skin vs design vs interface. — Shibbolethink (♔ ♕) 18:25, 20 January 2023 (UTC)[reply]

I originally reached this page through the Vector 2022 article, that had a useful link at the top. This link has now been removed by Epicgenius with the explanation "Remove links to internal discussion pages. This is almost definitely a violation of WP:SELFREF. It's dubious whether this topic should even have an article, but that's another discussion." I've read WP:SELFREF and it doesn't seem to apply to this case. Should the link be reinstated? I think it's a good way to get more people involved in the RfC. Rizzardi (talk) 08:23, 23 January 2023 (UTC)[reply]

The link has since been reinstated, but in the "response" section due to NPOV concerns. Aaron Liu (talk) 13:04, 23 January 2023 (UTC)[reply]
The link has been removed again, this time by BlankpopsiclesilviaASHs4. I really don't want to start a revert war, but this feels like an attempt to hide the fact that there's an ongoing discussion. Rizzardi (talk) 13:14, 23 January 2023 (UTC)[reply]
That "removal" was what I just said, they reinstated it in a different part of the article due to NPOV concerns. I'm not sure about this actually. Aaron Liu (talk) 13:16, 23 January 2023 (UTC)[reply]
I've just (re)checked the "response" section of the article Vector 2022, there's a link that points to the original RfC, but there's nothing pointing to this page. Am I missing something? Rizzardi (talk) 13:48, 23 January 2023 (UTC)[reply]
Ah, nevermind then. I think a link to this rfc can also be added in the responses section. Aaron Liu (talk) 14:09, 23 January 2023 (UTC)[reply]
Thanks for the ping, but I do think a link to a discussion page violates WP:CANVASS as well as WP:SELFREF. In particular, SELFREF very much applies because Mentioning that the article is being read on Wikipedia, or referring to Wikipedia policies or technicalities of using Wikipedia, should be avoided in the article namespace where it is unnecessary. ... Mentioning the Wikipedia community, or website features, can confuse readers of derived works. It would be acceptable as an external link, but not while the discussion is ongoing.
I see @Kizor restored the link here with an edit summary that read, in part, It's in Wikipedia's best interest to get eyeballs on a change to the viewing experience of hundreds of millions of readers, To me, this seems like a very blatant violation of WP:CANVASS, since we do not link internal Wikimedia discussions in this way, especially not active discussions. A better way to attract input is via Wikipedia:Centralized discussion, although this RFC is already linked there. – Epicgenius (talk) 22:19, 23 January 2023 (UTC)[reply]
I don't think the link was spamming, campaigning, vote-stacking, stealth canvassing, or soliciting support other than by posting direct messages. Therefore, I don't think the link was a violation of WP:CANVASS. That said, another editor re-removed the link, and I'm not gonna force it. --Kizor 01:54, 24 January 2023 (UTC)[reply]
The closest thing I can think of is that articles are off-wiki which counts it as WP:STEALTH canvassing? Aaron Liu (talk) 13:55, 24 January 2023 (UTC)[reply]
Would it be problematic to just have a banner placed on the homepage? I understand this is a bit unconventional, but this seems like a situation where we should want as many opinions factored in as possible, and this would be the best way to get everyone (both editors and not) to be able to know there is a discussion ongoing. DarkSide830 (talk) 03:23, 25 January 2023 (UTC)[reply]
It falls under WP:INAPPNOTE's spamming. Aaron Liu (talk) 12:40, 25 January 2023 (UTC)[reply]
[edit]

mw:Reading/Web/Desktop Improvements/Features/Limiting content width#Research

Although I personally believe that this research may not be specific enough for encyclopedic text-types and that the way Wikipedia is used by most readers may actually suffer from limiting line width (see my !vote above), I would of course be happy to be shown wrong, and in general !voters in Question 2 may want to read up on this research. ☿ Apaugasma (talk ☉) 22:47, 20 January 2023 (UTC)[reply]

Your side comment is important. If they asked for feedback on this specific issue they would have info relevant to reading and editing an electronic encyclopedia and even more specifically reading and editing Wikipedia instead of going by self-interpreting other less applicable studies. North8000 (talk) 05:16, 21 January 2023 (UTC)[reply]

Selection bias

[edit]

Having mostly registered editors decide which skin is best for unregistered editors doesn't seem to be the right discussion to have. Even if there are IP editors coming to the discussions to express their opinion, the comments would be biased because people who hate the new skin generally have more interest in navigating to the discussions about the new skin than readers who would find Vector 2022 better. 0xDeadbeef→∞ (talk to me) 05:32, 21 January 2023 (UTC)[reply]

It's worse than that, because this is attracting regular editors + previously unregistered editors who disliked the new look so strongly that they made the effort to make an account and track down this page. The WMF have already said that they will be conducting proper, statistically-backed UX research on the impact of this change, which makes this discussion doubly redundant. – Joe (talk) 05:57, 21 January 2023 (UTC)[reply]
Except their statistical criteria are "heads we win, tails you lose". It's rigged from the start so the WMF will be "right" and spared the humiliation of having to backtrack on the redesign. They aren't honestly trying to evaluate whether the changes are beneficial and popular. 2600:1700:1471:2550:4920:A572:D62A:79E4 (talk) 03:11, 24 January 2023 (UTC)[reply]
There isn’t much reason to distrust the data right now. Aaron Liu (talk) 13:47, 24 January 2023 (UTC)[reply]
@Aaron Liu, is the data for any kind of statistical test publicly available? TheMissingMuse (talk) 05:02, 25 January 2023 (UTC)[reply]
@TheMissingMuse There is a bunch at mw:Reading/Web/Desktop_Improvements/Repository, including an anon survey at mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey. However the latter is quite a bit obfuscated. Regardless there are still other things in there such as mw:Reading/Web/Desktop Improvements/Repository/Sticky Header and Table of Contents User Testing and mw:Reading/Web/Desktop Improvements/Repository/Hureo User Research Report (latter is third-party). Aaron Liu (talk) 12:30, 25 January 2023 (UTC)[reply]
I don't think surveys are good measures. In order to evaluate the impact, you would need things like bounce rate, session duration, and other behavioral metrics gathered in an A/B test or in pre/post metrics. TheMissingMuse (talk) 16:36, 25 January 2023 (UTC)[reply]
Bounce rate? Session duration? Why would we care about that? This is Wikipedia, we are not a for-profit advertising-supported website. We're not social media. We're not trying to "keep" visitors on the website. Hell, much of our content is served via other websites (Google, Siri), we don't care how long people browse our website, just that it serves its purpose. Wikipedia's design is about usability, not stickiness. (That's why it's never looked like other websites.) If a reader gets to the one page they need, looks at the infobox for five seconds, and then leaves, that's a great success for Wikipedia: it means we've helped someone quickly find the knowledge they were looking for. Bounce rate isn't a problem for Wikipedia, and session duration is irrelevant: whether short or long, either might be good depending on what the reader wants. Levivich (talk) 01:25, 26 January 2023 (UTC)[reply]
@Levivich, we are in full agreement. This is about usability, not about business metrics. That's why I specifically noted that behavioral metrics, including ones that highlight how readers use the site, are important. If you know of any A/B test that illuminates usability for the theme (as opposed to a single feature which can be implemented on any theme) I would love to see them. Maybe you are suggesting that an A/B test is not a good way of evaluating usability? Regardless, the new theme has serious usability issues, to the point of breaking the usability of sw.wikipedia.org. TheMissingMuse (talk) 19:24, 26 January 2023 (UTC)[reply]
AB tests don’t have to use social media metrics. Why would the metrics you cited be about usability? Aaron Liu (talk) 19:44, 26 January 2023 (UTC)[reply]
@TheMissingMuse: I understand the value of A/B testing a single feature; for example, the language switcher, you can test whether people use it more often or not. I haven't seen any A/B tests of the entirety of V22 against V10, but I also don't understand how such an A/B test would be performed. How would success be measured, on Wikipedia? Unlike e-commerce websites, it's not like we can measure whether people buy our product more. Unlike advertising-supported websites, we aren't trying to keep our visitors on our website for as long as possible. In the case of Wikipedia, because of the kind of website it is, if a reader stays on a page for a very long time, we don't know if that's because they think our article is fascinating and they're reading every word, or if it's because they can't find what they're looking for. So we don't know if session duration is good or bad. Same for clickthrough or bounce rate. Really, the only way we know if our website was helpful to the reader is by asking the reader--e.g., a survey. (Not a self-selecting survey like this one, but an randomized, scientific survey, conducted by professional researchers who are trained in conducting surveys and writing survey questions, etc.) Levivich (talk) 19:45, 26 January 2023 (UTC)[reply]
The utility of A/B testing is not limited to e-commerce websites. The value of A/B testing applies to any hypothesis driven endeavor. There are plenty of usability metrics that can be tracked to validate that a particular design decision yields improved usability. This is not a mysterious conundrum, and it is precisely the kind of process one would expect from a professional software engineering program. TheMissingMuse (talk) 21:18, 26 January 2023 (UTC)[reply]
What usability metric would you use to measure the usability of an entire Wikipedia skin, as opposed to a single feature? Levivich (talk) 21:28, 26 January 2023 (UTC)[reply]
That's a good question. Since the WMF rolled out the entire skin instead of feature by feature, I assume they have already answered this for themselves in some manner. I have yet to find any indication that they have, but that's not to say that they did not. TheMissingMuse (talk) 21:33, 26 January 2023 (UTC)[reply]
As for A/B tests of the entire skin, there was a mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey Aaron Liu (talk) 01:08, 27 January 2023 (UTC)[reply]
Yeah, I read that. My impression was very similar to that of @Loopy30. https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Rollback_of_Vector_2022&oldid=prev&diff=1135840899
Instead of discussing that survey respondents who had a preference preferred the old skin 60:37, they instead chose to misrepresent the survey data to bolster the case that the new skin was better. TheMissingMuse (talk) 20:46, 27 January 2023 (UTC)[reply]
I agree. It's the closest to a full AB test we have though. Aaron Liu (talk) 20:59, 27 January 2023 (UTC)[reply]
Sure, but the data in that link suggest that Vector 2022 made things worse, not better. That's despite what the prose in the report suggests. TheMissingMuse (talk) 23:48, 27 January 2023 (UTC)[reply]
Not really. The plurality of the surveyed found the old skin easier to USE but the other headers don't have similar plurality misrepresentation and do favor the new skin. Still the first entry calls the entire thing into question Aaron Liu (talk) 00:04, 28 January 2023 (UTC)[reply]
Their previous "proper" qualitative research included hardly any desktop users. It also focused on users from countries where mobile usage is prevalent, which makes even less sense, since those users will overwhelmingly interact with WP through the mobile app or the mobile site, which already had a different, perfectly fine skin.
Maybe WMF should ask the actual people affected what they think? A small popup or maybe a small banner in the header like the one for donations? 89.102.98.143 (talk) 21:52, 24 January 2023 (UTC)[reply]
No, all of their research was based on desktop users. Aaron Liu (talk) 00:57, 25 January 2023 (UTC)[reply]
No that's simply untrue, which you would know if you actually read the research in question. The user testing with groups in India and Africa both had only a small portion of desktop users, with some laptop users. Are you seriously trying to argue that people who "have access to a laptop at the library" count as desktop users? 89.102.98.143 (talk) 21:51, 2 February 2023 (UTC)[reply]
I wouldn't count laptops as mobile devices. I get your point about wording and desktops, I was just referring to personal computers when I said desktop. Because laptop users won't use mobile apps or mobile sites. Aaron Liu (talk) 13:10, 3 February 2023 (UTC)[reply]
I wonder if there should've been a central notice displayed to all readers (including unregistered ones) informing them about the discussion of the planned redesign? I mean, we already promote less important things like Wikimania or the photo of the year contest that way. At the very least it might have left regular readers less shocked when the redesign actually happened. —pythoncoder (talk | contribs) 07:00, 21 January 2023 (UTC)[reply]
There absolutely should have been a notice. As a regular reader this change came entirely out of the blue. DutriusTwo (talk) 16:11, 21 January 2023 (UTC)[reply]
This would have been my preference. I use wikipedia every day, and to be blindsided by this is shocking. 2601:645:0:41C0:D1A0:EB6A:A0C7:18BD (talk) 19:59, 21 January 2023 (UTC)[reply]
There should have been a notice and an opt-in option 2 years ago when they started testing that design live. As I said, a couple of times already, I come from the French Wikipedia, and at that time I created an account just to op-out and track a page (that was really well hidden) to know what the f... was happening. We've never been informed publicly about the creation of a new design or that we were a test wiki. We just were forced the design on us, all our pleas to revert fell into deaf ears. Same for the same critics about Vector 2022 as are shown today, very few things have, in fact, changed since that test. Add to that the awful communication from WMF, we were told that the new design was meant to be rolled out on all Wikipedia "soon" not that we were a test wiki, I had to search for that info. The WMF served us the same "studies" and justification with the understatement that the new design was a fait accompli, and it was better and no matter what would be said nothing would change. I can also add the very strange tactic used by the WMF to test Vector 2022 on communities on big enough communities to be stylistically relevant but with enough people who don't speak English and holding every single talk about the design solely in English, so they won't be able to voice an opinion. Now they use the French Wikipedia and other test wikis as example to how well Vector 2022 was received. DerpFox (talk) 07:07, 24 January 2023 (UTC)[reply]

Well we can always advertise the RFC at Mediawiki:sitenotice and MediaWiki:Anonnotice.©Geni (talk) 18:31, 25 January 2023 (UTC)[reply]

There are proposals at #Publicizing this RfC and WP:AN#Wikipedia:Vector 2022 has an RFC, but neither has gained traction. InfiniteNexus (talk) 06:40, 26 January 2023 (UTC)[reply]

Question for the Web team

[edit]

@OVasileva (WMF), SGrabarczuk (WMF), and AHollender (WMF): I've just been told that if this RfC ends with consensus to roll back Vector 2022, or it becomes evident that there is no consensus to use Vector 2022, the WMF will likely refuse to honor the community's will because of point four of WP:CONEXEMPT, which states that WMF actions are outside of Wikipedians' control and there is nothing we can do about it. Is that true? InfiniteNexus (talk) 07:07, 21 January 2023 (UTC)[reply]

As to me one should respect the outcome of an RfC if there is one. I am not surprised that the community doubles down on the outcome even though several of the opposes are from "new accounts". You could have made a second RfC and seen where it leads to. This is just a consensus kind of reasoning and not an answer to the quality of your work, which in my personal view, (despite an initial hesitation) is rather helpful for the editors. Paradise Chronicle (talk) 09:22, 21 January 2023 (UTC)[reply]
New accounts could be longtime IP users who are forced to make an account to revert these horrible changes. 73.8.230.57 (talk) 01:19, 22 January 2023 (UTC)[reply]
@OVasileva (WMF): Hi there, could you please respond to my question? Thank you. InfiniteNexus (talk) 01:22, 24 January 2023 (UTC)[reply]
@OVasileva (WMF), @SGrabarczuk (WMF), can you confirm whether or not community feedback on rolling back Vector 2022 is being considered? TheMissingMuse (talk) 05:00, 25 January 2023 (UTC)[reply]
I was obviously hoping for a response from the WMF, but their defining silence speaks volumes. Very concerning. InfiniteNexus (talk) 06:45, 28 January 2023 (UTC)[reply]
Perhaps you meant deafening, though if this is some play on words I apologise. —Tenryuu 🐲 ( 💬 • 📝 ) 07:28, 28 January 2023 (UTC)[reply]
Yes, that was a typo (autocorrect, sigh). InfiniteNexus (talk) 20:05, 28 January 2023 (UTC)[reply]
Well, it looks to me that WMF staff explicitly avoid answering questions related to the community consensus and decision-making processes here at enwiki. I see people answering technical questions and collecting feedback, but I have yet to see actual answers to the main question: does this RfC even matter? I can imagine that people at WMF can't even decide what to do here. If they go WP:CONEXEMPT route, they risk eroding good faith, if they state they will comply they risk eroding authority. There is possibly also some sunk-cost perceptions towards Vector 2022. I expect them to continue evading answering these questions until either this RfC dies out or they are forced to actually decide what to do. RoadTrain (talk) 23:21, 30 January 2023 (UTC)[reply]
It definitely does matter, the Foundation has been forced to back down before by the community. The WordsmithTalk to me 23:28, 30 January 2023 (UTC)[reply]
Technhically speaking, I think WMF can refuse to back down. But there are costs to that because Wikipedia is one of those projects that depend entirely on the voluntary comminity participation. If you disrespect the community, the project will die eventually. So my point is that they will avoid giving any clear answers while it's possible. RoadTrain (talk) 00:10, 31 January 2023 (UTC)[reply]

So people may not like it - now what?

[edit]

One thing I wonder is would it be too much to allow for skin preferences to have skin preferences for logged in readers? Like storing the status of the limited width and even the currently selected skin? Fandom is able to do that with no problem with their Fandom Desktop skin's limited width and dark mode options, so I'd figure if there is a way to do that, or even have that for MediaWiki, it would alleviate all the concerns that there currently are with Vector 2022 and lack of choice for anonymous readers. Aasim - Herrscher of Wikis ❄️ 07:48, 21 January 2023 (UTC)[reply]

That's the default now, isn't it? And a reason many readers are suddenly making accounts. —Femke 🐦 (talk) 09:57, 21 January 2023 (UTC)[reply]
@Awesome Aasim, logged-in readers? That's already the case. — Qwerfjkltalk 13:09, 21 January 2023 (UTC)[reply]
Ahh - I meant logged out. But the rest of my point remains the same. Aasim - Herrscher of Wikis ❄️ 13:18, 21 January 2023 (UTC)[reply]
@Awesome Aasim, in that case - yes, it's too much. There's a comment that explains it better, but in essence it would be to expensive on account of the cache required to avoid a flash of unstyled content. — Qwerfjkltalk 19:31, 21 January 2023 (UTC)[reply]
I think a good approach that can be done in the future is kind of like modern SNS and news sites. Rather than loading the skin all over again, it just loads the text, and maybe changes the buttons based on the text present. Granted it will break every single user script, but for logged out users this solution may work fine. That will also allow for caching of page content asked for via the MediaWiki API while enabling dynamic loading of the page. Sure on first load the skin will have to load and then readers would have to put up with a loading bar or loading screen while the page content loads, but the skin interface could also be cached. Aasim - Herrscher of Wikis ❄️ 00:34, 22 January 2023 (UTC)[reply]
That's how skins basically work we're just faster. You just described wikitext. Aaron Liu (talk) 14:20, 22 January 2023 (UTC)[reply]
What I am describing is dynamic loading of the page using JavaScript. So clicking on Apple would just load the text from the MediaWiki API and then replace the #mw-content-text with that and the title with the displayed title. If I am not mistaken currently the page is loaded largely by PHP before the page gets sent off to the browser. The use of JavaScript like this to load contents can possibly make the site one step closer towards PWA. Aasim - Herrscher of Wikis ❄️ 23:07, 23 January 2023 (UTC)[reply]
So we’re moving processing to the frontend… interesting proposal Aaron Liu (talk) 01:21, 24 January 2023 (UTC)[reply]
PWA, meaning progressive web app? Why would you want that? I don't want everything to be served in mysterious, de-empowering ways by javascript. It's not necessary, this is just a kind of techno fetishism.  Card Zero  (talk) 16:51, 24 January 2023 (UTC)[reply]
I agree that turning Wikipedia into a web app has little if not none benefits, but I do like the idea of moving rendering to the frontend. This can probably effect ip prefs. Aaron Liu (talk) 17:01, 24 January 2023 (UTC)[reply]
Wikipedia is a web app already, by most definitions. What did you mean by turning WP into a web app? 89.102.98.143 (talk) 20:16, 24 January 2023 (UTC)[reply]
By what definition is Wikipedia an app? Aaron Liu (talk) 23:51, 24 January 2023 (UTC)[reply]
By the same one as Reddit, Twitter, Discord, Gmail, Google Maps, any phpBB forum and mostly anything that's not a simple blog? You can interact with people here, the back-end looks pretty much like you would expect for an app? I'd like to see a definition that doesn't include Wikipedia. 89.102.98.143 (talk) 22:35, 2 February 2023 (UTC)[reply]
I'd say only the editing part of Wikipedia is an app. The rest doesn't require any interaction and it's server-side rendering Aaron Liu (talk) 13:14, 3 February 2023 (UTC)[reply]
The progressive in PWA stands for progressive enhancement, i.e. the app works as much as possible without JS, but is enhanced when JS is available. There is nothing de-empowering about having more of the rendering running on a device you control, just the opposite. It would probably even save some significant bandwidth, meaning less server costs and more battery-life. You would still need the back-end to provide services like search.
On a related note, the performance of mobile devices has increased by a few orders of magnitude, so maybe it's time for WP to consider moving the bulk of the rendering to the client. This should also make the back-end simpler, probably more like the smartphone app back-end. 89.102.98.143 (talk) 20:12, 24 January 2023 (UTC)[reply]
Yeah, and for those few times when JavaScript is not working there can be a fallback directory where pages are rendered in the backend, but then you lose all IP preferences that way. Aasim - Herrscher of Wikis ❄️ 15:57, 25 January 2023 (UTC)[reply]

If we end up reverting this skin change, can I still opt back into Vector 2022 as a logged-in user? --🌈WaltCip-(talk) 15:01, 21 January 2023 (UTC)[reply]

@WaltCip, yes.— Qwerfjkltalk 19:32, 21 January 2023 (UTC)[reply]

What if any changes did the WMF make in response to the RfC closure conditions?

[edit]

We need more discussion about the conditions which the WMF had to meet in order to comply with the RfC closure. This is an issue of fundamental importance, since e.g. if the conditions were hypothetically met, then that would mean that the WMF team complied with our procedures in all respects, and therefore there would be no real grounds for objecting to the rollout. (I don't think there can be any serious doubt about the closure itself at this point.)

From reading the closure, I extracted the following two conditions:

  • 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.

The closers added that they could not determine whether or not the issues in the second point were also blockers.

They conclude that If all the concerns outlined above are satisfactorily addressed then we see community support to roll out the change.

They also mentioned other legitimate concerns by editors, for example unresolved bugs (particularly relating to the TOC) and comments about link colours, but these were not considered to be potential blockers, since they were not included in the concerns outlined above (emphasis added).

So, as someone who has not seriously tested the new interface, and has not previously been participating in these discussions:

  • Did they address any of these points?
  • Did they attempt to address them?
  • Was any of this announced or made available anywhere before the rollout occurred?
  • Did the team have any discussions with editors about whether any changes they made were sufficient?

It may be that some of this is obvious (I've made some inferences myself, of course), but either way the answers to these questions need to be clearly laid out in detail.

ETA: Wikipedia:Vector 2022 claims The RfC concluded that the skin may be adopted provided that a way to configure the page width is available for logged-in and logged-out users, which is clearly incorrect based on what I've described. This description appears to be framed more narrowly than the first condition (which does mention a toggle but also refers more generally to the issue of fixed-width), and it misses the second condition entirely. Sunrise (talk) 10:48, 21 January 2023 (UTC)[reply]

I did not know what the icons were at the time of that RfC, but as of now it looks pretty intuitive to me. But that is obviously subjective. As for the page width, there is an icon on bottom right. 0xDeadbeef→∞ (talk to me) 11:36, 21 January 2023 (UTC)[reply]
There are screenshots at WP:V22RFC and it appears these haven't changed. Aaron Liu (talk) 19:57, 21 January 2023 (UTC)[reply]
According to the RFC close, the "only clear blocker" was the fixed-width issue. The WMF addressed this by creating a user preference for logged-in users and a toggle for logged-out users. See Summary and next steps from the Web team. Whether or not this was a "satisfactory" response is obviously a matter of opinion. Many of the other concerns raised are being actively worked on, and since these were not represented as "clear blockers" to deployment, the WMF have (in my view) done nothing contrary to the RFC result. Sojourner in the earth (talk) 12:36, 21 January 2023 (UTC)[reply]
I should add that I don't believe the WMF ever needed community consensus in the first place, per WP:CONEXEMPT. The lengthy consultation was a huge concession and a show of good faith on their part; it's just unfortunate that the final stage of that consultation was framed as an RfC, which was the wrong format for that kind of discussion. This current RfC also has no validity, in my opinion, hence I'm refraining from casting a !vote. Sojourner in the earth (talk) 13:38, 21 January 2023 (UTC)[reply]
Just asking: What format would you think to be appropriate? Aaron Liu (talk) 19:58, 21 January 2023 (UTC)[reply]
Just an informal discussion, advertised through watchlists and CENT, soliciting feedback on the new design. Sojourner in the earth (talk) 21:19, 21 January 2023 (UTC)[reply]
@Sojourner in the earth I'd personally taken the use of an RfC as acceptance of community consensus on the issue. They did more than enough discussion with experienced editors beforehand to be aware of the nature of RfCs. That's not committed them to it for perpetuity, so I believe they can have the rollout reverted for failure to meet the RfC's obligations - but !votes premised on any other grounds (of which there are quite a few) I don't believe are on safe policy grounds.
The non-perpetual toggle is, in functional terms, non-viable. I'd love to see some stats of those who read, say, 20 articles, and click the toggle on all of them.
I believe it could also be questioned whether the general VPT discussion met the minimum criteria of specific discussions on the other "possible-blocker" points. Nosebagbear (talk) 22:17, 23 January 2023 (UTC)[reply]
I think you may be putting more emphasis on the first word, only clear blocker, and not enough on the second, only clear blocker. In my view, the latter is more accurate, as the closers made it clear there were additional issues and that they couldn't determine whether or not they were blockers as well. Furthermore, these additional issues are included as part of the quote If all the concerns outlined above are satisfactorily addressed then we see community support to roll out the change.
Also, I would strongly disagree with framing cooperation and attempting to follow our established processes as "concession". Certainly the WMF may choose to disregard consensus (although the community can also take other actions in response to that), but regardless, my interest here is in whether the WMF followed consensus in this instance. RfCs are effectively the only broadly accepted method for this context (absent proposing and adopting another method of DR), so that part is fine, but it's possible the team may have misread or misinterpreted the RfC closure. Sunrise (talk) 23:41, 21 January 2023 (UTC)[reply]
The "toggle" is non-persistent for logged out users, imagine if numlock turned off every time you pressed another button, that is the level of anti-use design that button has. It is a temporary and must be reapplied every new page viewed. It has low contrast, as it is a thin shape that fits in the corner, has same coloring as the whitespace, and blends into the taskbar and scroll bars. Hard to see, missing core functionality, and is placed away from all other active elements of the page. Deadoon (talk) 11:37, 22 January 2023 (UTC)[reply]
The way I see it is that a blocker means that the WMF must address that specific point at least to get consensus. To get a firm consensus, they have to make headway with the other two issues too (which I don't think has happened?), but they need not be both completely solved. Given that the fixed-width is not completely solved yet (80% there?), I do not think the criteria for consensus are quite met. —Femke 🐦 (talk) 12:53, 21 January 2023 (UTC)[reply]
The toggle is not persistent for IP users - 99% of our users. Furthermore, it's a mystery meat navigation button hidden in a location far from anything else. So no, I do not think this was meaningfully addressed. IWantTheOldInterfaceBack (talk) 13:13, 21 January 2023 (UTC)[reply]
As someone with a browser window that is 1,230 pixels wide, I have never seen this toggle on a Wikipedia page except in screen shots. Nevertheless, the content is restricted to a band in the middle of the page and I am unable to make it nearly as wide as content in Vector 2010 without major changes to my personal CSS. I have done my best to communicate this problem to the WMF developers (see T326887, including providing the screen shots linked from that ticket), but they have not made enough progress to meet the conditions of the RFC. It's too bad, because Vector 2022 with my customizations to remove excessive white space in many places has become a pretty nice skin. – Jonesey95 (talk) 17:50, 23 January 2023 (UTC)[reply]
As far as I can tell they haven't done a thing and I have most certainly noticed. It's absolutely disgraceful that this problem is still not resolved. Are WMF really hoping they can just ignore this and everyone will just accept it? Because that's not happening. This change is horrible, and Wikipedia is worse for it. Fix it. 2600:1700:1471:2550:82D:A299:5C4B:30F8 (talk) 19:31, 31 January 2023 (UTC)[reply]
What they changed to “fix” the fixed-with fix was to fix an “unfix the width” toggle to the bottom right. Aaron Liu (talk) 19:38, 31 January 2023 (UTC)[reply]

The difference between reading an encyclopedia article and reading a book or news article

[edit]

When you are reading a book, or a news article, you are generally reading from beginning to end. Skimming is less important. Comprehension matters a lot. When reading an encyclopedia article, skimming comes into play much more. Yes, sometimes we read them closely, start to finish. But other times we are looking for one particular fact about something. What's the molecular weight of iron? Who was the leading Union general in the Battle of Gettysburg? Who were the leaders of the 1607 expedition to settle Jamestown? In these cases, which involve skimming for a particular factoid, reading speed' matters much more than reading comprehension, because you are only seeking to comprehend one piece of information, and you are seeking to locate this needle amidst the haystack of other information which is irrelevant to your current inquiry. The massive sea of whitespace which now exists on the right side of the screen cuts the amount of text on the screen at a time in half or more, and thus slows the speed of skimming by half or more. Thus, reading an encyclopedia entry is different in qualitative nature than reading a book or newspaper article, and I posit that studies and metrics about tradeoffs for those other forms of media are irrelevant when it comes to an encyclopedia in particular. IWantTheOldInterfaceBack (talk) 17:56, 21 January 2023 (UTC)[reply]

...and thus slows the speed of skimming by half or more.‹The template Fake citation needed is being considered for merging.› [citation needed] Thus, reading an encyclopedia entry is different in qualitative nature than reading a book or newspaper article,‹The template Fake citation needed is being considered for merging.› [citation needed]
Actual studies: 1991 study Kolers et al. (1981) suggested that narrow columns might improve skimming because they eliminate the need for lateral eye movements. The shorter line lengths in the book condition (60 compared to 85 characters on-screen) may have facilitated skimming from the book., 2001 study A medium line length (55 characters per line) appears to support effective reading at normal and fast speeds., 2015 study called "Significance of Line Length for Tablet PC Users" is worthy of a lengthier quote, as it summarizes prior research:

On screen readability has variant line length because of multiple sizes of screens. Weber conducted a study on “Line length of newspapers and books” and found that in newspapers and books the line length need to be four inches and it should never exceed than six inches [2]. According to Tinker et al., the best line length for reading books and other information need to be between 3 and 3.5 inches [1]. Moreover, they found that if the line length exceeds 7.5 inches, it becomes very difficult for the reader to find the next line after finishing the first line. Ducknicky et al. were the first to find out the optimal line length for onscreen readability [3]. They went on saying that if the text is stretched to full screen it becomes easier to read than the text only filled one third of the screen. Dyson et al. shows that the reading efficiency of the readers increases by more number of letters per line [4]. Bernard et al. examined three different line lengths (3.3, 5.7 and 9.6 inches) with same Fig. 1. Sample of different line lengths Significance of Line Length for Tablet PC Users 589 size of text that was 12 points in times new roman [5]. The results of the experiments performed by Shaikh were similar with the study conducted on difference of reading speed for efficiency conducted by Shaikh [6]. The study investigated the line length for reading online newspapers and books vs. paper based reading. On the other front, in most of the studies it can be seen that longer line lengths lead towards faster and efficient reading while medium line lengths lead towards the average reading. In view of this the readers preferred line length between 90 CPL to 120 CPL.

Now ask yourself how many characters per line (CPL) you're comfortable with--the "full width" of Vector 2010? If you're not sure, just copy and paste one line from your screen now into www.wordcounter.net and see how many characters it is. I bet it's like 150+, maybe even 200+... far, far longer than any research has ever recommended. Levivich (talk) 18:31, 21 January 2023 (UTC)[reply]
Now ask yourself how many characters per line (CPL) you're comfortable with--the "full width" of Vector 2010? Yes, even on my widescreen. Clearly many agree with me. You completely ignored everything I wrote to cite a bunch of studies addressing topics that I already explained the irrelevance of. IWantTheOldInterfaceBack (talk) 18:43, 21 January 2023 (UTC)[reply]
A handful of people disliking the new design is not a valid reason for changing the default skin back. There is actual science behind the new design, as Levivich just showed. 0xDeadbeef→∞ (talk to me) 18:47, 21 January 2023 (UTC)[reply]
Wikipedia is not a book or a newspaper, so the science about reading books and newspapers is irrelevant. IWantTheOldInterfaceBack (talk) 18:49, 21 January 2023 (UTC)[reply]
The 2015 study was specifically about tablet PCs, and the 2001 study was specifically for reading from screen.. Where are you getting the "science about reading books and newspapers" from? 0xDeadbeef→∞ (talk to me) 18:53, 21 January 2023 (UTC)[reply]
Wikipedia is not a newspaper or a book with linearly read texts. Wikipedia is a source of information that you need to be able to navigate quickly. Wikipedia contains tables and mathematical formulas, contains extensive lists of categories, often requiring a large width. However, if someone wants to reduce the width of the displayed columns, they can always just shrink the browser window, using the universal solutions of their operating system and not having to learn specific "inventions" of a given page, such as a special expansion button. Freja Draco (talk) 17:46, 25 January 2023 (UTC)[reply]
Yes reading speed matters but the studies clearly also address speed. That's what he is trying to prove with the studies. Aaron Liu (talk) 20:00, 21 January 2023 (UTC)[reply]
You might have just convinced me and probably also the RfC closers. I do not understand much of what you say here but it sounds much better than the arguments of the ones who want to return to vector 2010. Paradise Chronicle (talk) 18:44, 21 January 2023 (UTC)[reply]
The comment before was meant for Levivich.Paradise Chronicle (talk) 18:46, 21 January 2023 (UTC)[reply]
I've read the 2015 study; I'd like to raise two points about it: 1) it's aimed specifically at portable devices (Tablet PCs), where the screen width is limited by physical constraints. Also, 2) the study partecipants were asked to choose among different line lengths *up to* 120 characters, and a quarter of them still opted for the longest line size available. The study doesn't indicate that 120 is the recommended line length (indeed, as you quote, "if the text is stretched to full screen it becomes easier to read than the text only filled one third of the screen."). Rizzardi (talk) 18:55, 21 January 2023 (UTC)[reply]
a quarter of them still opted for the longest line size available means 75% opted for a line length shorter than 120 CPM, which suggests we should have a line length shorter than 120 CPM. No, the study doesn't indicate that 120 CPM is the recommended line length. The 2015 study says The results of the study revealed that 90 characters per line (CPL) were preferred by most of the participants. Nonetheless, some participants falling between the ages of 35 and 40 years preferred 60 CPL. And also that On the other front, in most of the studies it can be seen that longer line lengths lead towards faster and efficient reading while medium line lengths lead towards the average reading. In view of this the readers preferred line length between 90 CPL to 120 CPL. So... 60 CPL for some participants between 35-40, 90 CPL for most, 120 CPL for faster reading. And that's just one study, specifically for tablets. If you look at all studies, it's consistently in the 55-85 or so range: never like 150 CPL or anything like that. I'm not aware of any study that even tested above 120. What I was responding to, though, was the OP. There is no science that supports the claim by the OP that fixed width "slows the speed of skimming by half or more" or that reading an encyclopedia entry is different from reading a magazine article or a book or something else (people skim all sorts of materials, not just encyclopedia articles). It's true that longer is better for skimming than shorter (studies have shown that), but it's also relative, the study that found longer is better for skimming also found the optimal length for skimming was 55 CPL, which they call 'medium' length. This other study brings it up to 120 CPL, but we're still way below Vector 2010's unlimited width. The reason every publisher in the world uses fixed width is because every study in history supports it. Levivich (talk) 19:09, 21 January 2023 (UTC)[reply]
@Levivich: if legacy Vector's line width is far above 120 CPL, and there is no study that has tested CPL above 120, the conclusion should not be that studies support abandoning line widths above 120 CPL. This simply does not follow. Rather, the studies support nothing about it, because they haven't tested it. There are a great many things in this world about which we still do not have any scientific research-based knowledge, and in such cases we must look to other things.
One of them is established usage, which often has been shaped into something fairly efficient by mere 'evolutionary factors'. Another is common sense. Line lengths of 90-120 CPL were found to increase reading speed when compared to smaller line lengths, so perhaps we wouldn't go far wrong in suspecting that this gain would be preserved with +120 line lengths. Of course, people do skim encyclopedia articles more often than they skim novels; this far common sense can really be trusted. Also, OP's claim that limiting line width slows the speed of skimming by half or more was based on the fact that it cuts the amount of text on the screen at a time in half or more: now this does not necessarily follow, but obviously making the reader skim one part of the text before they can scroll down to skim another part will make the process somewhat slower.
True, there is no science to back this up, but it is based in common sense, and this common sense is used in a situation where we do not have immediate access to relevant scientific analysis. I think that precisely in such situations, it is important not to pretend that we have scientific answers to everything, and throw away common sense in the process. Nothing more dangerous then claiming science backs up an argument when in fact the science is lacking or ambiguous. I'm not necessarily saying that this is the case here (we might just choose to trust the web team), but we should be wary about that. ☿ Apaugasma (talk ☉) 23:37, 21 January 2023 (UTC)[reply]
making the reader skim one part of the text before they can scroll down to skim another part will make the process somewhat slower I disagree. No matter the line width, the reader will skim a certain amount of characters before scrolling down to skim another part. Line width doesn't play into this. Aaron Liu (talk) 00:10, 22 January 2023 (UTC)[reply]
They will skim more characters before scrolling if there are more characters viewable at the same time, and if their skimming speed is high enough this will significantly impact the amount of characters skimmed per second. It should be a common experience: having to scroll down to look for something (think a graph or infobox, which naturally has a very high skimming speed) vs seeing it at a glance because it is in the upper part of the screen. ☿ Apaugasma (talk ☉) 00:50, 22 January 2023 (UTC)[reply]
The 2015 study found that 75% or more of participants preferred a line length shorter than 120 CPL. I don't see why they would need to repeat the study with a longer line length. Here's a question: can anyone show me an article complaining about Wikipedia's new design having a short line length? If it really was this big of a problem, wouldn't somebody in the media say so? I see lots of media reports reviewing the new design favorably (or saying it just isn't a big change at all), I haven't yet come across anyone in the media complaining about line length or too much whitespace. Levivich (talk) 05:25, 22 January 2023 (UTC)[reply]
I just think it's clear that the research cited until now is far from conclusive about what is best for our actual use case as Wikipedia (none of it even comes close to considering everything that is important for us), and the way that the research is cited (to the point of being cherry-picked) as if everything in it supports this design decision comes over as rather tendentious, whence my skepticism. The question about media reactions is an entirely different but equally interesting tack, and deserves its own subsection in this discussion. ☿ Apaugasma (talk ☉) 09:58, 22 January 2023 (UTC)[reply]
Indeed. Also the 1981 study predates real-world windowing interfaces. IIRC, application windows on mini-computer and mainframe terminals were resizable, and I believe Visicalc on Apple ProDOS (probably the most popular micro-computer application of the time) had a resizable window. The omission of the fact that application (and later system) windows are resizable as a simple user action is mystifying, especially for the later studies. The only justification being that the later studies were focused on mobile interfaces, where window resizing is moot in the vast majority of cases. The argument for making any skin a user preference is exactly because users may prefer to use desktops. Optimizations of mobile interfaces have very little bearing on this. 204.19.162.34 (talk) 16:30, 22 January 2023 (UTC)[reply]
Window resizing is irrelevant here, we’re talking about the benefits and detriments of line widths itself without user modification. Aaron Liu (talk) 19:30, 22 January 2023 (UTC)[reply]
Ok, so I don't like a line width and I change it by resizing the window, not exactly an advanced operation. Except if I want to increase line width to fit my screen/window with the new skin, because it is more comfortable and productive for me. Is there an option to do that? There is always an option to decrease. 24.103.63.182 (talk) 20:12, 22 January 2023 (UTC)[reply]
There is, but it isn't implemented very well. It's in the bottom right corner of the entire page, in the right grey margin. If you don't see it zoom out. Since you aren't logged in you'll need to press it on every single page/refresh which is a very strong argument against the skin. Aaron Liu (talk) 21:33, 22 January 2023 (UTC)[reply]

You can eat your cake and have it. You can use the full available width and have text in small columns that can be read in one eye fixation, fall into the sharp seeing Fovea_centralis. The solution is to have text in many narrow columns. The eye will be able to read a whole chunk of words in parallel, then move to the next chunk. Reading speed will go up. And full screenwidth is available. See real life example, from Queen Elizabeth II Uwappa (talk) 19:11, 21 January 2023 (UTC)[reply]

Not sure why you'd go with such small columns but here's a better example (columns are about 45-55 CPL, resize your screen to see them change):

You can eat your cake and have it. You can use the full available width and have text in small columns that can be read in one eye fixation, fall into the sharp seeing Fovea_centralis. The solution is to have text in many narrow columns. The eye will be able to read a whole chunk of words in parallel, then move to the next chunk. Reading speed will go up. And full screenwidth is available. See real life example, from Queen Elizabeth II Uwappa (talk) 19:11, 21 January 2023 (UTC)

Levivich (talk) 19:32, 21 January 2023 (UTC)[reply]

Why such small columns? Because the Fovea_centralis is very small. With such small column the eye can read all text of it in one eye fixation, then move on to the next chunk to read all of that. Uwappa (talk) 19:49, 21 January 2023 (UTC)[reply]

For me I have to move down my eye a lot which actually makes it more tiring. Aaron Liu (talk) 19:54, 21 January 2023 (UTC)[reply]
This is more annoying to read than the two-column version Levivich provided. —Tenryuu 🐲 ( 💬 • 📝 ) 19:58, 21 January 2023 (UTC)[reply]

The Fovea_centralis is round, a kind of circle shape. Read multiple lines of a small column with one eye fixation, no movement yet. The move will be horizontal, to the next column. Uwappa (talk) 20:03, 21 January 2023 (UTC)[reply]

  1. Yes you can read three lines without moving your eye but it is common to automatically move your eye down after finishing a line. Most people will move the eye down a lot
  2. It's annoying to read because there are a lot of broken sentences which means a lot more breaks in flow/logic
Aaron Liu (talk) 20:12, 21 January 2023 (UTC)[reply]
Presumably this would be less annoying with the columns tens of lines long instead of two as in these examples (at least they are two lines long on my desktop screen). Even then, it does feel like the worst of both world. Columnar pagination is much more difficult for the web, where you can scroll and there are infinitely many different screen sizes, than it is for printed media. IWantTheOldInterfaceBack (talk) 20:14, 21 January 2023 (UTC)[reply]
I believe that these tables were formatted specifically for v22 with limited line width which is an incredibly bad idea by Wikipedia's own policies. Screenie on v22 w/ limited width Aaron Liu (talk) 20:28, 21 January 2023 (UTC)[reply]
Vector 2010 is compatible with any line width because the line width is directly related to the window width, while getting the same level of control is a challenge for readers under Vector 2022. It is not our or the WMFs role to constrain readers to one reading experience, even if backed up by science. I hate that kind of we know what's best attitude. This is a problem of freedom, not optimisation.–small jars tc 20:24, 21 January 2023 (UTC)[reply]
For an example with more lines per column, see real life example, from Queen Elizabeth II. Feel free to test that example with different window widths and see how the columns dynamically use the available space. Freedom is not a worry. You can have any layout you want by creating your own stylesheet. Uwappa (talk) 20:37, 21 January 2023 (UTC)[reply]
99% of readers never create an account, and of those who do probably 90% are not technically proficient enough to create their own CSS stylesheet. This RFC primarily concerns non-account readers. IWantTheOldInterfaceBack (talk) 20:39, 21 January 2023 (UTC)[reply]
STILL, these column widths are WAY TOO SHORT to read comfortably. Aaron Liu (talk) 20:44, 21 January 2023 (UTC)[reply]
Thank you for your suggestion. I already know about common.css. I am only considering the freedom of logged out readers. Personally, I will continue to use MonoBook. small jars tc 20:44, 21 January 2023 (UTC)[reply]
"You can just make your own stylesheet" is not a reasonable solution. That's like if Ford suggested customers simply upholster the seats themselves if they dislike the options WizWorldLIVE (talk) 00:09, 22 January 2023 (UTC)[reply]
@SmallJarsWithGreenLabels, the point is that the default look should be helpful ( "look good" ). If you want to change the appearance, then just create an account. — Qwerfjkltalk 20:50, 21 January 2023 (UTC)[reply]
I want all readers to be able to change the appearance in the easiest way possible. The easiest way possible to change the line width is to change the window width. Vector 2022 makes this method impossible. How is this helpful? What does "looking good" have to do with being helpful? small jars tc 20:54, 21 January 2023 (UTC)[reply]
I see, nevermind, I misunderstood your comment. — Qwerfjkltalk 20:57, 21 January 2023 (UTC)[reply]
Would [Firefox Reader View] be an option for the 99%? Uwappa (talk) 21:03, 21 January 2023 (UTC)[reply]
@Uwappa, no, that won't be accessible for most readers. — Qwerfjkltalk 21:12, 21 January 2023 (UTC)[reply]
Right - more generally, anything that requires a browser plugin will not work for most users. IWantTheOldInterfaceBack (talk) 01:30, 22 January 2023 (UTC)[reply]
@Uwappa: Just tried this. Galleries and IPA failed to render properly on the first article I tested. The line-width starts much narrower than Vector 2022, but Firefox does provide detailed controls to change this and the font size. small jars tc 21:16, 21 January 2023 (UTC)[reply]
Yes. Mobile devices present the option to switch between "Desktop" and "Mobile" view at the very bottom of the screen. Switching to "Desktop" on a small screen makes for an agonizing experience. There is a failure to understand that the opposite may be true too: forcing a quasi-"Mobile view" on a larger (say 12"+ landscape) screen may have equally agonizing results for many users. 204.19.162.34 (talk) 16:52, 22 January 2023 (UTC)[reply]
@SmallJarsWithGreenLabels, agreed. Sm8900 (talk) 18:23, 12 February 2023 (UTC)[reply]
I read the article you linked and the available articles or abstract from its citations. The study you cited is also changing font size making the increase of characters harder to read because the words were smaller. The articles that favor shorter line width are those done on mobile devices (either phones or tablets) those that were done on larger screens favored longer lines. "Lines of full and two-thirds screen width were read, on average,
25% faster than lines of one-third screen width." 71.194.60.172 (talk) 01:23, 31 January 2023 (UTC)[reply]
Sorry but I don't see anything about changing font size. All three articles favor shorter line width and only the last study was on mobile devices.Aaron Liu (talk) 13:37, 31 January 2023 (UTC)[reply]

Reviews of Vector 2022

[edit]

If this change is so bad, where are the negative reviews in the media?

  • Popular Science [2]

    The changes, which are rolling out to the desktop version of the site starting this week, make for a cleaner, easier reading experience...But even as Wikipedia’s content has been kept up-to-date, its appearance hasn’t been. It’s had largely the same look and layout since 2003, though updates in 2005 and 2011 stopped it from looking like Geocities, and kept it readable as screens got larger and higher-resolution. The latest tweaks aren’t huge and certainly don’t change the overall “black and blue text on a white background” look of the site that everyone knows and tolerates, but they will make it easier to use...As well as generally embracing a slightly more modern, minimalist design, there are two big features of note. The first is the new table of contents sidebar...The second big change is the new language drop-down inline with the article title...In addition to these changes, Wikipedia said that it is changing its default font-size and setting a maximum line length to make long articles easier to read—especially on bigger screens....While the sum total of the changes might be small, all in all, they make for a nicer-looking Wikipedia that still maintains the site’s character—for better or worse. At the current rate, we can expect the mobile site to be updated in 2033.

  • Gizmodo [3]

    Try and Spot the Differences in Wikipedia's First New Look in 11 Years...At first glance most folk would struggle to see any real changes to the old formula...The most obvious change was the top logo has been made smaller...There are a few noticeable changes that do add a bit of functionality. The header and a few other widgets are also set to scroll along with the user, making it easier to see what page you’re currently reading and also search for a new page. The language selection bar now sits at the level of the title as well, making it easier to switch to another language version of Wikipedia midway through the page...There’s a few other changes meant to increase readability. The site now has a smaller maximum text width...

  • Fast Company [4]

    You may not have noticed Wikipedia’s decade-in-the-making update...With a focus on usability and access, the update introduces a variety of new features, including: An improved search experience...leading to a 30% increase in user searches, according to tests. More prominently placed language-switching tools...An updated sticky header...with a decreased scroll rate of more than 15%. A table of contents that provides context on the article and the ability to navigate to chapters throughout the page...But the website, bless it, still looks a lot like it did when it started: black text on a white background, blue-purple links, no fancy animations. It’s fast and legible. And yes, it has those unmissable top banners asking for donations, but it’s still ad-free...As with all redesigns on the internet—indeed, as with any significant change anywhere on Wikipedia—predictably, someone will not be happy...Ultimately, amid disagreement over the amount of white space, the design team has made it default as of Wednesday, but added a toggle to switch back to the old design...

  • Business Insider [5]

    It's not just you — Wikipedia looks different...Wikipedia got its first desktop interface update in over a decade that includes improved search...It's not a jarring difference, but you'll probably notice a lot more white — the gray background elements and shading are largely gone...New features in the update include an "improved search experience"...Commonly used links, like Search and Sections, move as users who are logged in scroll through the page...language-switching tools are "more prominently-placed,"...

  • Slate [6]

    Wikipedia’s Redesign Is Barely Noticeable. That’s the Point...The Wikipedia editors are waiting to hear you scream...For all the hype, Vector 2022 isn’t dramatically different...Wikipedia is still Wikipedia, just with more whitespace, a more prominent search bar and language switcher, and a sticky table of contents. There’s also a collapsible sidebar and maximum line width, which make the site more clean and less cluttered...it doesn’t look all that different than it did 23 years ago, when it was run by a few guys in an office in Florida. The text-heavy website resembles an email inbox, or Craigslist, or Old Reddit. It’s a barrage of straightforward white and blue text, a rather unsightly assemblage of lines and squares...Crotchety Wikipedia veterans practically yelled “too much white space!” in unison while starry-eyed progressives condemned the kneejerk resistance to change. A few clever thinkers crafted a compromise plan. In the end, the 165 people who voted to oppose the redesign outnumbered the 153 supporters. Nevertheless, it’s happening...The design team took some of the advice, adding a toggle to appease the whitespace-haters...Wikipedians, characteristically skeptical, aren’t the only online community that has put forth a big fat resistance to redesign...To an outsider, the meticulous, sometimes combative arguments about, say, moving a button five pixels to the left seem pointless. I beg of thee, please, touch grass! But to many, Wikipedia is sort of a home on the internet. And people want to live somewhere nice...

  • TechCrunch [7]

    Wikipedia gets its first makeover in over a decade… and it’s fairly subtle...an updated interface aimed at making the site more accessible and easier to use with additions like improved search, a more prominently located tool for switching between languages, an updated header offering access to commonly used links, an updated table of contents section...The changes being introduced are not very dramatic — in fact, they may not even be immediately noticed by some users...Other changes to the site include the addition of a collapsible sidebar for a more distraction-free reading experience and a change to the maximum line width. The foundation explained that limiting the width of long-form text makes for a more comfortable reading experience and improves retention of the content. However, a toggle is available for logged-in and logged-out users on every page if the monitor is 1600 pixels or wider, allowing users to increase the width of the page. Logged-in users can also set a width in their preferences page...Given the size of Wikipedia’s readership, it’s clear the organization was careful not to make disruptive changes...

  • Mashable [8]

    Yes, Wikipedia looks weird. Don’t freak out. A thing changed! Argh!...Perhaps your brain rejected all the new white space, or the way the "sticky" new table of contents hovers while you scroll. But also maybe you just hate change. There's no right way to react to a thing happening on the internet, so whining and nitpicking, along with inexplicable fear,(Opens in a new window) are to be expected at a time like this...But nothing has fundamentally changed...And once you get used to the new maximum line width, users of monitors with high resolutions might appreciate not having to read single lines of text as long as the entire Gettysburg Address...So if this gets you fired up, and you just need the old Wikipedia back, well, join one of the long, long, discussion threads about that. Or, since this is Wikipedia after all, just customize your experience, and leave the Wikipedians to their weirdly aggressive arguments about steam engines.

  • Digital Trends [9] (Spanish edition; translations via Google Translate)

    It's an updated interface intended to make the site more accessible and user-friendly with additions like improved search, a more prominent tool for switching between languages, an updated header offering access to commonly used links, an updated table of contents section content for Wikipedia articles and other design changes for a better reading experience.

  • The Express Tribune [10]

    ...first makeover on a desktop after almost a decade....The new additions have included an improved search, a more prominently located tool for switching between languages, an updated header offering access to commonly used links, an updated table of contents section for Wikipedia articles, and other design changes and improvements for a better reading experience...Though subtle, the changes were deemed necessary by the foundation to keep up with the next generation of internet users, especially those unfamiliar with the internet...Due to the large viewership size of the website, major changes would have been disruptive and an annoyance to adapt to the change...

  • India Times [11]

    Wikipedia's First Makeover In A Decade Makes Reading And Navigation Easier...Wikipedia's updated features include improved search, a tool to switch between languages, a new header that leads to commonly visited links, a new table of contents section and other design tweaks to add to Wikipedia's readability...The thing about these new changes at Wikipedia is that not all people might notice them at first glance...

  • The Indian Express [12]

    ...The new updated interface emphasises on usability and ease of sharing knowledge...What’s new?...new search experience...language-switching tools...updated sticky header...Table of contents...

  • Businessworld [13]

    The desktop edition of Wikipedia has undergone a number of minor modifications, including an updated sticky header and the left-side panel of article subheadings shifting as you scroll down...A number of small changes have been made to Wikipedia's desktop version...the language switcher...search function...

  • ABP News [14]

    ...Some of the notable changes that the design overhaul brings are a collapsible sidebar and the default font size that has been made larger, to reduce the strain on readers' eyes...

  • Jagran Prakashan [15]

    ...Popular information provider Wikipedia gets a UI revamp after over 10 years, adds different tools to enhance reading experience...a clean, minimalistic look...Speaking of improvements, users of Wikipedia's desktop version will now have access to a table of contents, a tool for switching languages, new options for line width and font size, a collapsible sidebar, and more along with a better search experience...

  • Sportskeeda [16]

    ...In addition to simplifying usability, the update modernizes the platform's iconic design. However, users will find the design changes to be minimal, keeping the online encyclopedia close to what they are familiar with...Wikipedia will now feature an easier-to-access navigation module that allows users to easily switch to a new language from a database containing 300 dialects for their convenience. The article space now features a maximum line width, ensuring that users have a comfortable reading experience...The update, which is currently being rolled out, also brings an improved search experience, a new collapsible sidebar to minimize any distraction caused by a long menu, and an updated header that moves along with the reader and eliminates the need to scroll up multiple times...Although subtle, the latest update has given the desktop website a much-needed facelift, which will surely boost its popularity...

  • News.am [17]

    Wikipedia changes its design for 1st time in 12 years...The new design is called Vector 2022. It features the table of contents of articles was moved to the left side of the page, which accelerated the navigation through the materials. There is a dynamic setting maximum line width. The new feature is needed for better display of content on widescreen monitors. In addition, designers moved the language switch button to a more prominent place - in the upper right corner...According to Mashable, some of the changes were not easy for the developers and caused heated arguments in the group.

  • How-To Geek [18]

    Wikipedia Has a Fresh New Look...Wikipedia has largely looked the same for the last decade, with no major variations to its design. Now, though, Wikipedia has rolled out what might be its largest redesign ever. Wikipedia is rolling out a new, more modernized design...The more important change that you’ll notice, though, is the reduced line width, which is vastly reduced to improve readability on wider screens — a helpful change for all those ultrawide monitor owners. The new layout also makes it easier to both navigate through articles and read articles in other languages...

  • Tech Spot [19]

    New Wikipedia design improves access to the world's knowledge: An improved look that doesn't remove any previous functionality...The improved desktop interface features a new "table of contents" navigation panel that remains visible as users scroll down the page, a more prominently-placed link to find and switch the available languages an article is written in, a maximum line width which should make long texts more comfortable to read and easier to retain.

  • The Shortcut [20]

    The world's largest online encyclopedia looks a tiny bit different...The Wikimedia Foundation has rolled out the first big redesign to the desktop interface of Wikipedia in 12 years, and while it’s not exactly a mind-blowing do-over, some subtle changes have been made to the hugely popular online encyclopedia...Perhaps the most obvious change is the site’s shorter line width. Wikipedia articles now appear at a maximum width that better centers their content on the screen, which will hopefully make for a more comfortable reading experience and better retention of content...

  • Mezha.Media (Ukraine) [21]

    ...The changes are not radical...Among the innovations: improved search, a more visible tool for switching between languages, updated article title and its content section, etc.

  • There are more, like [22], [23], [24], and [25].

Notice that most reviews say the changes are minor. To the extent they give an opinion, the reviews are positive, and I cannot find a single RS review making a complaint about the line width... many don't even mention it at all. Levivich (talk) 17:33, 22 January 2023 (UTC)[reply]

I wasn't aware that Wikipedia bases internal decisions on what journalists think. IWantTheOldInterfaceBack (talk) 18:04, 22 January 2023 (UTC)[reply]
Jimbo Wales did once. That's why he lost his privileges. --Kizor 18:29, 22 January 2023 (UTC)[reply]
The "reviews" seem to be based closely on WMF press releases, which obviously present a positive view of the changes. Actual readers I've spoken with unanimously prefer the previous appearance, though not violently so. Certes (talk) 18:39, 22 January 2023 (UTC)[reply]
I have to wonder - are any of the "reviews" cited above (ooooo, yes, I am using scare-quotes!) coming from actual editors? Any of these "reviewers" ongoing participants in the Wikipedia Experiment?... I kind of doubt it. And personally I don't care what an outside reviewer has to say about this change. I only care about what my fellow participant-editors have to say, here on this page and the many other pages like Wikipedia talk:Vector 2022, the many Vector 2022 subsections at Wikipedia:Village pump (technical), the many, many subsections at Wikipedia:Help desk and elsewhere where the debate is raging on.
Btw, does it bother any of the other previously-registered accounts/named accounts that this New! Improved! Vector is now forcing IPs to register an account in order to ameliorate their desired experience? I sure as hell bothers me. Shearonink (talk) 15:36, 23 January 2023 (UTC)[reply]
I'm not bothered if no reviews are from editors, because we are a small minority of Wikipedia users and have a Preferences page. I am bothered if the reviews are not from readers, or are from someone who doesn't remember Vector 2010 or know how to view a page with it now for comparison. Certes (talk) 15:47, 23 January 2023 (UTC)[reply]
Good point. Yeah, at least from regular users/actual readers, the people who use Wikipedia on an ongoing basis, not writers who seem to regard Wikipedia as some kind of strange beast. Shearonink (talk) 15:56, 23 January 2023 (UTC)[reply]
If this was an article at AfD, I think we would need to consider WP:ADMASQ and the guidelines at WP:NCORP that are designed to help protect the encyclopedia from low-quality websites churning PR copy. Perhaps reputable news outlets will examine this situation in greater depth, and ask what appear to be unanswered questions about accessibility and the impact on unregistered users, and fisk the "research" relied upon for the changes. It apparently seems easy to snark on anonymous editors and users trying to communicate their concerns, but maybe actual journalism will garner some respect. Beccaynr (talk) 18:57, 22 January 2023 (UTC)[reply]
Popular Science is not actual journalism? Levivich (talk) 19:37, 22 January 2023 (UTC)[reply]
That report does not appear to be an in-depth review of the changes, and instead discusses Wikipedia generally and seems to rely on "Wikipedia recommends", "Wikipedia said" and "Wikipedia also claims" for a superficial overview of the announced changes. Overall, I do not think the initial flurry of reports about what Wikipedia says and claims brings much substance to this challenging discussion. There seems to be much that could be examined in-depth by independent and reliable sources, but it may take some time, if it ever happens. Beccaynr (talk) 19:54, 22 January 2023 (UTC)[reply]
I believe every word of Popular Science I quoted above is in the author's own voice, not "Wikipedia said". Levivich (talk) 20:00, 22 January 2023 (UTC)[reply]
The quote above includes "Wikipedia said that it is changing its default font-size and setting a maximum line length to make long articles easier to read", which seems to refer to one of the more contentious issues in this discussion. Sources that are often disregarded at AfD as superficial coverage do not seem as helpful as sources with greater depth, e.g. examining the research, accessibility issues, and other concerns raised during discussions about the new skin. In the meantime, we can use the press release "Wikipedia Gets a Fresh New Look: First Desktop Update in a Decade Puts Usability at the Forefront" (WMF, 18 Jan 2023) to help distinguish independent secondary coverage from the PR churn. Beccaynr (talk) 20:29, 22 January 2023 (UTC)[reply]
You're right, I missed that sentence. Everything else, though, is the author's voice. Good idea about comparing sources to the PR itself. Here's WP:DUPDET for PopSci and the PR: [26] I don't think it's fair to call the PopSci article churnalism. The point, however, is that if the limited width or other changes were as big of a problem as some editors suggest, somebody in the media would be saying that. Levivich (talk) 20:36, 22 January 2023 (UTC)[reply]
It might be too early to make that call. Presumably, an article going into the downsides (real or otherwise) would require more effort to write than regurgitating a press release. (I, respectfully, disagree with your assessment of the Popular Science article, and I think the Slate article was mostly written before the roll-out.) —Compassionate727 (T·C) 20:48, 22 January 2023 (UTC)[reply]
Counter example, every critical review of mass effect 3 was positive, with some having minor issues. User reviews were pretty mediocre to bad, with one major reason being the ending being a massive middle finger to the concept the series had built upon to that point that your actions have long lasting consequences. Fallout 4 suffered from serious issues plaguing it's game design simply to give the player and reviewers in their short time with the game a taste of power. It made an category of equipment overpowered, and a supposedly powerful weapon useless. General users and critics aren't the same audience, and something tailored towards critics with press releases telling them "it's good and barely different" they might just tow that line to avoid being the contrarian that disses on Wikipedia and end up not getting that early press release next time something happens. Oh yeah, then you had the diablo 3 thing in 2012, Mass positive response from critics, with few dissenters, still widely disliked by general players. Deadoon (talk) 19:24, 22 January 2023 (UTC)[reply]
Weren't Mass Effect 3, Fallout 4, and Diablo III, all huge commercial successes, among the best-selling video games in history, with the first two also winning a number of industry awards? What evidence is there that these games were widely disliked? Levivich (talk) 19:36, 22 January 2023 (UTC)[reply]
Well, for the first two, see their Steam pages for starters. Although 75-80% positive reviews overall is not exceptionally bad, it is pretty mediocre, especially when compared to ratings for earlier titles in those series. I generally avoid buying games rated that poorly, I have found them to be not worth my money. —Compassionate727 (T·C) 19:48, 22 January 2023 (UTC)[reply]
The steam release was done much later in 2020, when ea moved many games to steam. It is not the original release which had serious negative response, it is the fixed version which solved the problem the community had with the game on launch that led to the original negative user reviews that can be found on metactitic. Deadoon (talk) 19:54, 22 January 2023 (UTC)[reply]
Well, that just makes its poor ratings even harder to justify. —Compassionate727 (T·C) 20:00, 22 January 2023 (UTC)[reply]
The steam reviews are the best representation of the user's general opinion of the game in it's current state. However the current state was not the state that the original critics which reviewed mass effect 3 had. They reviewed it in it's launch state, which was poorly received. The reviews of wikipedia in it's launch state are still highly relevent to it's current state as no major changes have occured thus far. My whole point was the release states of mass effect 3 and diablo 3 were very poorly recieved by general playerbase, but the critic reviewers were very positive about them. The fallout 4 comment was primarily about the side effects of the critic pandering leading to power armor being overtuned, and miniguns being undertuned to give the player a taste of power, but not allow them to steam roll the whole game with starting gear. Deadoon (talk) 20:10, 22 January 2023 (UTC)[reply]
Fallout 4 I made no claim it was widely disliked. It was actually reasonably well liked, but suffered as a whole due to it's pandering to critics. The others can be seen on metacritic and from articles speaking of their respective incidents.
Mass effect 3 had completely remade the ending sequence due to discontent and backlash from the general community.
Diablo 3 has some of the most divisive user reviews of all time. Basically it wasn't what many players considered diablo, had serious issues due to being early always on drm, and did not really fit in with the themes of prior titles. Deadoon (talk) 19:51, 22 January 2023 (UTC)[reply]
ME3 has 6.0 user score on Metacritic. That's not "widely disliked". But I am not at all persuaded by Metacritic's user score. Diablo 3 sold over 30 million copies, but has a low 4.6 user score on Metacritic based on 10,000 ratings. Ten thousand out of thirty million? Those are the ten thousand players who hated the game. The other 29,990,000 didn't bother to rate it on Metacritic, but they did buy the game. Levivich (talk) 20:07, 22 January 2023 (UTC)[reply]
Seriously? There is an entire article on mass effect 3 controversies involving the ending among other problems. I only mentioned metacritic to give you a simple single number comparison.
And yet here we are in an article that has only a few hundred respondents on a website with a few hundred million page views a day. Only a small subset of any group will actually put in the effort to give a review. 10k reviews should be a pretty decent indication of common user response. Deadoon (talk) 20:20, 22 January 2023 (UTC)[reply]
Not if the 10k are self-selected. And yeah, the respondents on this page are in no way indicative of the general public, nor even indicative of editors in general. Nor are editors indicative of readers. We are a tiny little self-selected subgroup, just like Metacritic and Steam reviewers. Levivich (talk) 20:23, 22 January 2023 (UTC)[reply]
What you just said is that user reviews are pointless and should be ignored because they chose to review their products themselves? Only journalists which have financial incentives to have their announcements out immediately to ensure they get the first day ad revenue spike should be listened to. I'm sorry but what? That is about the most anti-consumer stance I have read in a while. Deadoon (talk) 20:52, 22 January 2023 (UTC)[reply]
Why are we comparing huge, complex games to a single trivial, but annoying aesthetic change to Wikipedia? Apples to oranges. Plus games tend to get review-bombed for stupid reasons, whereas this is pretty clearly a case of people just not liking it. (Off-topic but the “problems” with Fallout 4 are seriously overblown) Dronebogus (talk) 20:31, 23 January 2023 (UTC)[reply]
@Dronebogus: Deadoon was pointing out that good critical reception is not necessarily an indicator of good popular reception. It got off-topic when we started arguing about whether or not the examples he cited had, in fact, been poorly received by the public. —Compassionate727 (T·C) 22:07, 23 January 2023 (UTC)[reply]
Then I agree with his argument even though it was a bad analogy. Dronebogus (talk) 22:09, 23 January 2023 (UTC)[reply]
Unfortunately most tech websites regurgitate PR releases to bulk out content. The similarity of talking points and phrasing show that's likely the case with these reports. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:01, 22 January 2023 (UTC)[reply]
You believe Popular Science and Gizmodo regurgitate press releases under their own bylines? Are you really suggesting that the opinions written in those articles under those bylines are not the opinions of the authors, and they only wrote it because it was in a WMF press release? I find that very hard to swallow. Levivich (talk) 20:08, 22 January 2023 (UTC)[reply]
When they closely paraphrase the WMF talking points? Yes. And I find it very easy to swallow, the tech web has been in poor shape for awhile. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:13, 22 January 2023 (UTC)[reply]
I think you quoted a mix. The Slate article is clearly an actual article. The India Times and News.am are clearly regurgitated press releases. The Popular Science article looks to me like one too, with some trivia thrown in beef up with its length. —Compassionate727 (T·C) 20:13, 22 January 2023 (UTC)[reply]
I agree with that, a mix. But... nobody wrote one complaining about too much white space? Levivich (talk) 20:19, 22 January 2023 (UTC)[reply]
Well, it has only been a couple of days. We might get some yet. —Compassionate727 (T·C) 20:27, 22 January 2023 (UTC)[reply]
I think that journalists are used to very short lines because newspapers are usually formatted in narrow columns. This might explain why the changes introduced by the new skin seem very minor to most of them - it makes Wikipedia look more like a newspaper, which suits them fine. Rizzardi (talk) 17:00, 23 January 2023 (UTC)[reply]
Newspapers also adopted the good limited text width graphic design gizmo. It’s because they’re accustomed to the good limited with brings. Aaron Liu (talk) 17:09, 23 January 2023 (UTC)[reply]
Also mass dumping references is never very convincing. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:14, 22 January 2023 (UTC)[reply]
Uh huh. During the course of this conversations, editors have, in turn, discounted scientific studies, discounted WMF's testing, discounted the last RFC results, discounted media reports... why, it seems the only reliable source is their own opinion. Levivich (talk) 20:22, 22 January 2023 (UTC)[reply]
  • Scientific studies: see my response to Gnom above about data vs preferences and how they aren't one and the same.
  • WMF testing: the WMF obfuscated the results by filtering out responses containing "offensive language" and in another part of their results lumped neutral and positive feedback together to manufacture a narrative that the feedback didn't actually support. Until the WMF reveals the impact of the offensive-language-containing feedback (presumably overwhelmingly negative) all their feedback data must be treated as suspect.
  • RFC results: There were more opposers than supporters, and there was particular vituperation at the fixed width issue. The closer of the RFC ignored this to manufacture a consensus in favor of Vector 2022 that didn't exist, and even then the closer conceded that fixed-width was a blocking issue. This has emphatically not been resolved - the toggle is a mystery-meat button hidden in the least likely spot far from everything else, it is invisible on screens below 1600px, and it is not persistent. There were several other issues which were also mentioned as potential blockers - these have not been resolved either.
  • Media reports - completely irrelevant. This is for us to decide, not a few outside journalists with their own interests and motives.
IWantTheOldInterfaceBack (talk) 21:05, 22 January 2023 (UTC)[reply]
You mean the media reports based on the foundations press release, which was based off of internal polls that would be best described as inconclusive with them taking every effort possible to discredit negative findings, and a rfc that was closed as mostly negative that never had it's main concerns actually solved? Seriously that survey they did showed more people liked the old one and they were taking every effort possible to spin it against them it was 60-37/65-44 in favor of vector 10, additionally that survey had removed 75% of all responses, meaning it could have been gamed as well. Deadoon (talk) 21:06, 22 January 2023 (UTC)[reply]
Oh, god, Wikipedia is a self-government project, why should we ask journalists for advice instead of making a consensus locally? Lemonaka (talk) 20:11, 22 January 2023 (UTC)[reply]
This whole affair has been a massive opportunity for the WMF to undermine the concept of self governance. Look out for language like “vocal minority” when they come to evaluate the legitimacy of this RFC. small jars tc 21:49, 22 January 2023 (UTC)[reply]
@SmallJarsWithGreenLabels, how exactly is this a massive opportunity? Anyway, it will hardly be the WMF who closes this RfC. — Qwerfjkltalk 21:57, 22 January 2023 (UTC)[reply]
  • I agree with people above who have pointed out that many of these articles look more like rephrased versions of a WMF press release than independent critical appraisals. It’s also possible that people who work for publications like Gizmodo and Digital Trends have a bias in favor of trendy new styles. Honestly, I would be more inclined to look at Twitter to gauge the general public’s reactions reactions, see e.g. [twitter.com/search?q=%22Wikipedia%20redesign%22&f=live this search], where there are at least as many people complaining about as celebrating the change. (The spam filter won’t let me add the actual link, but I give permission to anyone who is able to circumvent this to edit my comment and then delete this parenthetical.) 70.172.194.25 (talk) 20:19, 22 January 2023 (UTC)[reply]
    I’m looking at that page right now and if anything it seems like reaction is more negative than positive over there. But maybe that’s Twitter being Twitter. —pythoncoder (talk | contribs) 23:46, 22 January 2023 (UTC)[reply]
    By a pretty large margin, too, much larger than in this RfC. I've read a few hundred, I'd guess it's about 4:1 against. The inefficient use of space is, unsurprisingly, by far the most salient issue. —Compassionate727 (T·C) 00:27, 23 January 2023 (UTC)[reply]
    The exact search term seems surprisingly salient, though. [twitter.com/search?q=Wikipedia%20skin&src=typed_query&f=live] seems to be a lot more evenly split, although I'm struggling to ignore the vast amount of unrelated stuff. —Compassionate727 (T·C) 00:35, 23 January 2023 (UTC)[reply]
Journalism today is broken. It's pointless to gauge anything from news media anymore. Way too much paid reviews, bias, poor journalistic ethics, etc. I mean the claim that the new design is barely noticeable is laughable. It's objectively false. 2600:1700:1471:2550:2195:BD59:6E8E:AB0C (talk) 01:49, 23 January 2023 (UTC)[reply]
While it's very surprising, most people (admittingly students) I asked about the new skin didn't realize the change at first glance until they look at the old vector skin. I don't know why people think this way either, but it's true. I didn't show the max width or TOC though as I showed the main page on an iPad. Aaron Liu (talk) 02:50, 23 January 2023 (UTC)[reply]
Yeah, the changes are going to be a lot less noticeable if you are browsing on a mobile device, as most readers do. —Compassionate727 (T·C) 04:33, 23 January 2023 (UTC)[reply]
If you're on mobile you'll only see the difference if you use the desktop view switch. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:46, 23 January 2023 (UTC)[reply]
I was talking about using v22 on an iPad. Aaron Liu (talk) 19:05, 23 January 2023 (UTC)[reply]
Journalism was never good. Dronebogus (talk) 20:34, 23 January 2023 (UTC)[reply]
So what if the media likes it? Surely Wikipedia is the authority on it, we as Wikipedians should be the ones to decide it ourselves. We are the ones whom it affects the most, and we should be the ones to vote on it; we shouldn't go off of what "the media" wants, we should go off of what Wikipedians want. Tim O'Doherty (talk) 20:39, 23 January 2023 (UTC)[reply]
AMEN BROTHER! Dronebogus (talk) 20:44, 23 January 2023 (UTC)[reply]
Facepalm Facepalm — Rhododendrites talk \\ 21:10, 23 January 2023 (UTC)[reply]
Why should it be a facepalm? God forbid anybody on an RfC present an opinion on something... Tim O'Doherty (talk) 22:13, 23 January 2023 (UTC)[reply]
My guess is there's a facepalm because:
1. Wikipedia is not a democracy.
2. The media doesn't want anything, they are just observing the skin and reporting on its changes.
3. Despite the storming-the-Bastille sentiment, It's still not clear whether the outcome of this RfC reflects how all Wikipedians (including readers) feel, or if it just reflects a subset of editors who are passionate about the subject. With that in mind, even if this RfC gains a consensus to support the rollback, it's not likely that will be sufficient to spur WMF into any sort of action. 🌈WaltCip-(talk) 13:35, 24 January 2023 (UTC)[reply]
1. Yes, Wikipedia is not a democracy, but what is the point of this RfC if the results don't matter anyway? I'm not advocating polling, I'm saying what Wikipedians want should be respected; I don't think that we should take a headcount, I just think what the community decides through discussion should be taken into account.
2. Again, I'm aware the media (that is, the media as a bodiless, abstract entity) doesn't want anything itself, but if that's so, why was the point "if this change is so bad, where are the negative reviews in the media?" made in the first place? It implies that the media should accurately reflect what Wikipedians want (a very wrong assumption given the current state of this RfC) which, as I have said, is not true. It also might be construed as "polling is a substitute for discussion" as it takes a sample of articles from the net and shows them as "this sample shows positive reviews towards V22, hence it should be the default" without discussion from anywhere at all.
3. My third and final reason as to why I stand by my original comment is similar to the first. If the WMF don't respect it, what is the point of this RfC if the results don't matter anyway? Tim O'Doherty (talk) 20:25, 24 January 2023 (UTC)[reply]
See, I simply don't get this. I can see the argument that the changes were good, or that they weren't a complete overhaul of the system, but the overall sentiment that seems to be present here is that little clearly changed, which simply doesn't track IMO. DarkSide830 (talk) 07:49, 24 January 2023 (UTC)[reply]
Almost every article is just a regurgitation of the talking points of a press release. Even though the articles are positive, the comments for the articles are overwhelmingly negative about the redesign and rejecting the idea that it is a small change. 71.194.60.172 (talk) 00:44, 31 January 2023 (UTC)[reply]
I was looking for something else, but I just found this on a tech blog. Not journalism, but nevertheless an example of negative reception by someone whose job is to write about stuff like this. —Compassionate727 (T·C) 18:34, 9 February 2023 (UTC)[reply]

@Levivich: I think the answer to your question is that news magazines are not really oriented towards giving accurate assessments of user interface changes on websites, and also, there are a bunch of websites, so you can find a bunch of authoritative-looking URLs to back up any subjective opinion. See: [27] [28] [29] [30] jp×g 08:29, 30 January 2023 (UTC)[reply]

Strange pattern in recent opposes

[edit]

I am noticing that the last 14 consecutive opposes (as of oppose #140) have all been from IPs or new accounts. This is not a bad thing in itself - I've actually praised the participation of IPs and new accounts like myself in the RFC - but up until this recent string of opooses, we'd only been 10-20% of participants on both sides. Between this and some similarities in content and formatting among these 14 opposes, it makes me wonder if something is going on. IWantTheOldInterfaceBack (talk) 19:02, 24 January 2023 (UTC)[reply]

I noticed the same. I already reported it a few minutes ago on Fram's talk page here, as they already deleted some of those comments here. They are all weirdly similar in style.
@Avilich: You have been tagging some of those comments as suspicious; notice that one of the new accounts has deleted some of your tags a few minutes ago.--Æo (talk) 19:23, 24 January 2023 (UTC)[reply]
I noticed this at this very moment, and was about to reinstate the tags. Avilich (talk) 19:25, 24 January 2023 (UTC)[reply]
Increasing awareness of the vote will bring more people out who aren't regular participants. I didn't want to be an IP so I dug out my account to vote, but I basically never sign into Wikipedia, despite using it daily. Ocdtrekkie (talk) 19:48, 24 January 2023 (UTC)[reply]
That makes sense at the individual level, but the pattern is exceptionally strong, especially since so many of the recent opposes are using similar formatting and almost identical languages (your oppose is not one of the ones with such language). It also started very suddenly. Were you made aware of this RFC by some link or discussion on an external site urging you to vote? IWantTheOldInterfaceBack (talk) 19:55, 24 January 2023 (UTC)[reply]
I don't think they're part of whatever's been happening, they don't use the high-level vocabulary and doesn't talk about designering. Aaron Liu (talk) 12:34, 25 January 2023 (UTC)[reply]
At least 3 of the recent string of opposes have claimed that they design websites for a living. Makes me wonder if this RFC has been linked on some UX or web design forum. IWantTheOldInterfaceBack (talk) 20:05, 24 January 2023 (UTC)[reply]
This, this and this coming in within an hour of each other is a bit much. Add how this editor, identifying themselves as "James M." is followed by an extremely similar comment from this editor identifying themselves as "JD M" and yeah, we're being bombarded by a sockpuppeted or canvassed attempt to skew the discussion. --Kizor 20:30, 24 January 2023 (UTC)[reply]
Now that you mentioned it, from the start I thought it was strange that so many newly registered users came to an obscure page like this one to vote against an obvious improvement, and that they are making sure their voice is being heard by leaving tens of messages where there should be one. Sorry to say, but this whole RFC VOTE is a joke. 2604:CA00:168:403A:0:0:1061:E10 (talk) 20:29, 24 January 2023 (UTC)[reply]
Says the SPA? Dronebogus (talk) 20:33, 24 January 2023 (UTC)[reply]
Why are you doing this? --Kizor 20:34, 24 January 2023 (UTC)[reply]
A bit like yourself, then? Tim O'Doherty (talk) 20:35, 24 January 2023 (UTC)[reply]
Most of those "newly registered users" are only registered because they detest Vector 2022 for whatever reason and can't easily or practically change it back to Vector Vanilla otherwise. That they're finding this isn't a coincidence; they're likely coming across this while finding ways to allow unregistered users to change back. What you see as an "obvious improvement" others see as a pointless and more-difficult-to-navigate UI. —Jéské Couriano (No further replies will be forthcoming.) 22:06, 24 January 2023 (UTC)[reply]
You're correct, it's bizarre. May be worth looking into. Tim O'Doherty (talk) 21:12, 24 January 2023 (UTC)[reply]
All I'm saying is: look no further than https://en.wikipedia.org/w/index.php?limit=250&offset=&target=IWantTheOldInterfaceBack&title=Special:Contributions/IWantTheOldInterfaceBack (bizzare it is, indeed)— Preceding unsigned comment added by 2604:ca00:16c:40c0::1061:198a (talk) 16:57, 24 January 2023 (UTC)[reply]
Commendable whataboutery. Why are you acting as if your own user contributions are some sort of holy grail of diversity? Tim O'Doherty (talk) 15:42, 25 January 2023 (UTC)[reply]
Due to the large number of new and occasional editors coming to this page I do not think that tagging individual comments / !votes with the note about few edits outside this area is helpful. I would suggest adding a notice along the following lines to the top of the page instead so that people reading the page (and obviously those closing the RfC) can see it.
People reading this RfC should be aware that there will be contributions from:
  • IP address users who have not previously edited who either like or dislike Vector 2022
  • People who created accounts so that they can change to Vector 2010 or customise Vector 2022
  • People who have not recently been active on Wikipedia
  • People who have read about the discussion elsewhere and come here to comment
Please be patient with those who may not be familiar with Wikipedia policies and processes and remember to WP:Assume Good Faith.
Gusfriend (talk) 07:32, 25 January 2023 (UTC)[reply]
Problem is all these !votes follow patterns. Aaron Liu (talk) 12:50, 25 January 2023 (UTC)[reply]
There will be a natural correlation between having a new account and disliking Vector 2022, because the easiest way to suppress the change involves creating an account, whereas those who like Vector 2022 can enjoy it without logging in. Certes (talk) 20:55, 25 January 2023 (UTC)[reply]
No that's not the pattern I was talking about. I was talking about the pattern of talking about designering, claiming accessibility and over-sophisticated vocabulary. They are also in a certain cluster of time. Aaron Liu (talk) 21:58, 25 January 2023 (UTC)[reply]
Didn't this get mentioned on some tech/design site? I remember seeing some of the opinions given mention it. —Tenryuu 🐲 ( 💬 • 📝 ) 22:23, 25 January 2023 (UTC)[reply]
Really? This entire section has been about trying to find which site it's from or what's happening, what site is it? Aaron Liu (talk) 22:27, 25 January 2023 (UTC)[reply]
Oppose #158 mentions a Mashable article, which I presume is this one. —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 25 January 2023 (UTC)[reply]
AFAIK Mashable isn't designer-oriented. Aaron Liu (talk) 00:04, 26 January 2023 (UTC)[reply]
  • Some people in this RFC have spoken about the vast majority of unregistered readers whose opinions were allegedly not considered before rollout, those who have no platform to propely express their views. Little do IPs or new users know that they are commenting in an ivory tower insiders only RFC where they get slapped with trailer text displaying their second class status, nevermind the fact that a large chunck of IPs nowadays get reassigned within a few days. If we want this to be an insiders only RFC, put this page under semi protection instead of inviting everyone to comment and sneering at them afterwards. If this RFC has any legitimate claim about representing a broad spectrum of users, all such trailer text after comments should be removed. Otherwise why would any IPs and new users be encouraged to participate in such a toxic environment? ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:12, 25 January 2023 (UTC)[reply]
    @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: No, that's not what we are doing here, and Wikipedia has specific policies against mistreating anons. We aren't indiscriminately sneering at all the IPs. What we were worrying about was an incident of WP:CANVASSING since these IPs and new accounts all talked about working as a designer and commented in a very short span of time. There was also an incident of sockpuppetry since both signed themselves as James M/JDM and an incident of attempted votestacking here is the removal of this obvious votestacking. No, we are not and will not discriminate against anon opinions. Aaron Liu (talk) 15:23, 25 January 2023 (UTC)[reply]
    A ctrl+F for "has made few or no other edits" in this page gives 58 results, some for comments on 20th. Seems like someone has tagged every new user instead of doing so only to suspected socks. Socks should have their comments removed or stricken, tagging every new user and treating them as a likely sock gives the impression that they are not welcome to comment. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:01, 25 January 2023 (UTC)[reply]
    The template is not for socks but for suspected canvassing, coi, votestacking, etc. I do agree that at least a quarter of these uses are unneeded. Aaron Liu (talk) 16:15, 25 January 2023 (UTC)[reply]
    @Aaron Liu: before I get cracking on the changes, which ones here do you think should have the tag removed? --Kizor 16:20, 25 January 2023 (UTC)[reply]
    Off the top of my head I can think of the tag on Ocdtrekkie and the tag on IWantTheOldInterfaceBack Aaron Liu (talk) 16:32, 25 January 2023 (UTC)[reply]
    I went ahead and removed the tags for IPs and editors not associated, or suspected to be associated, with yesterday's incident. AIUI, the "has made few or no other edits" tag is a way to say "Uh, dude? WTF are you doing?", not something to apply as a matter of course to newcomers not suspected of misconduct. The page that tag links to says as much: "If [...] some editors directed you to this page [...] they are encouraging you to familiarize yourself with the Wikipedia guidelines about conflicts of interest and advocacy." We have no reason to suspect most of the newcomers here of anything, and tugging them on the sleeve and questioning their motives and goals is pointless and uncivil. Not to mention WP:BITEy, when a lot of people are encouraging outside perspectives or even saying those are the only perspectives that matter.
    However, someone who's not me should review the ones I left in place, in particular the ones for opposes 141.156.130.5, 23.31.229.50, 2600:1700:2f70:ed50:cc6f:e67:289b:1968, 170.149.100.107 (though I think that tag should stay), 170.64.77.163, and Dchlr23. I'm a bit wound up, may be jumping at shadows, and I distrust my own motives since I'm in favor of support and might stand to advance my cause by leaving warnings in place. @Aaron Liu:, could I ask you to do that, please? I hate to impose further, but I don't know another editor who's as well suited for the task. You're up to speed on the issue, plus you favor oppose and we need to take particular care to be fair. --Kizor 19:26, 25 January 2023 (UTC)[reply]
    Sure, I’ll get to it today. Aaron Liu (talk) 19:35, 25 January 2023 (UTC)[reply]
    Removed from 141.156. I'm also unsure about 170.149, and 170.64 seems to be already removed(which was what I was about to do). Additionally I'm also unsure about Dchlr23, their comment lines up with the other SPAs but they also corrected an error in another page about an hour after the comment. Aaron Liu (talk) 20:41, 25 January 2023 (UTC)[reply]
    (edit conflict)@Kizor, @Aaron Liu: You should also check User:Fon E. Noel NFEBE who has not made any other edits except deleting some tags. Æo (talk) 20:44, 25 January 2023 (UTC)[reply]
    How are we going to tag them? Aaron Liu (talk) 20:49, 25 January 2023 (UTC)[reply]
    @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: That's a fair point. The tagging was only on the suspect comments last I looked, I'll return it to that. D'you think it'd be appropriate to delete very-likely-socks' contributions outright or move them to the talk page? @Aaron Liu:, what about you? --Kizor 16:20, 25 January 2023 (UTC)[reply]
    Thanks for removing the WP:BITEy tags. I'm fine with outright removal of confirmed or very-likely sock comments. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:09, 25 January 2023 (UTC)[reply]
    Don't forget breaking the formatting of 75% of this page for seventeen minutes by mishandling a </small>, and completely forgetting about question #2 until just now! :D --Kizor 17:32, 25 January 2023 (UTC)[reply]
    Suspected sockpuppets should not have their comments stricken or removed. If they are confirmed to have engaged in sockpuppetry, the comments should be tagged with {{csp}} or {{csm}}. InfiniteNexus (talk) 06:45, 26 January 2023 (UTC)[reply]
    Striking confirmed socks is common practice at least at AfD Aaron Liu (talk) 12:44, 26 January 2023 (UTC)[reply]
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, Aaron Liu, Æo, and Kizor: Why is it that all of the {{spa}} tags appear to have been removed from the support section but not from the oppose section? Graham (talk) 02:03, 26 January 2023 (UTC)[reply]
Because there are no weird patterns in the support section. Aaron Liu (talk) 12:45, 26 January 2023 (UTC)[reply]
In my opinion, a WP:SPI on that January 23-24 series of similar votes might help determine who's who so as to strike possible multiple votes from the same person. Æo (talk) 15:18, 26 January 2023 (UTC)[reply]
I've already opened one Wikipedia:Sockpuppet investigations/Dan Phiffer and the clerk is only requesting a check on JDM since the IPs apparently aren't related Aaron Liu (talk) 15:21, 26 January 2023 (UTC)[reply]
@Graham11 the SPA tags have been removed from everyone now. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:33, 26 January 2023 (UTC)[reply]
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ Could you restore the tags that were in place after my Edit around 20:41, 2023-01-25? Aaron Liu (talk) 18:49, 2 February 2023 (UTC)[reply]
@Aaron Liu: they were actually removed by Tenryuu [31]. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:21, 3 February 2023 (UTC)[reply]

Tools to the right

[edit]

I note differences of opinion about the changes - there always will be. However, I see no advantage in having the Tools on the right margin, but I do see a loss of presentation style in some articles (eg those wth side info panels). Wikipedia is now more difficult to read. Shipsview (talk) 12:04, 25 January 2023 (UTC)[reply]

I am continuing to experiment with V2022 (when I am logged out), but I continue to prefer the organisation of menus in V2010. The hidden toolbar, now partially moved to the right, and the general reorganisation of menus in V2022 (which include the ToC, transformed into a sticky menu) is quite simply a big mess. And no, I am not an old man, so the argument put forward by many opposers of the rollback that supporters are mostly oldies clinging to the past and loath to change are completely wrong and misleading.--Æo (talk) 16:16, 25 January 2023 (UTC)[reply]
I'm an 'old man' (mid 60s) and I really like the improvements I'm seeing - especially with the Tools menu on the right. Nick Moyes (talk) 22:34, 29 January 2023 (UTC)[reply]

Some opposes and supports with same argument

[edit]
Moved from https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements

It is notable that at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Rollback_of_Vector_2022
many 'supports' and 'opposes' have the same rationale: that this vector is not perfect, that it is on trial, and is undergoing changes. The 'oppose-rollback' think that making it default, is a chance to make it better. The 'support-rollback' like me, think that a published, default skin is supposed to have been already tested and perfected.
The reason I opt for the 'support' interpretation is that this vector is not the work of fellow volunteers. It is a paid product, expected to be tested, finished, polished, with manual, translations, with intermediate steps of application at communitites or ages or minorities, not so much used to internet changes. If the goal is to have a very new vector in 5 years, in the years between, there could be smaller steps.
Also, the 'letter of announcement' The Vector 2022 skin as default could change its wording in such communities, inviting them to try out some new buttons or changes, and see how it goes. (from el.wiktionary,Central) Sarri.greek (talk) 08:35, 26 January 2023 (UTC)[reply]

If you think Vector 2010 is "perfected", I have news for you. BappleBusiness[talk] 22:00, 26 January 2023 (UTC)[reply]
New skin I also like better....but its very bad for accessibility for thoses with motor function problems.....as in thoses that cant use a mouse. Moxy- 13:16, 27 January 2023 (UTC)[reply]
@Moxy - thanks for the feedback. Have you also experienced issues with using a mouse? So far we have gotten only one report on issues with using a mouse that we have not been able to replicate internally or across other feedback methods. Our quality analyst uses a mouse for testing as well, to make sure that we are covering all possible scenarios. Any additional information will help us identify whether this is indeed an issue from our side. OVasileva (WMF) (talk) 16:17, 27 January 2023 (UTC)[reply]
I use tab mosts times to navigate...that this version does not support....as in I get to the TOC by using tab..but cant open the TOC onces there.Moxy- 00:57, 29 January 2023 (UTC)[reply]
Wait wut ? I tested this just now, and it works for me (using enter and/or space both navigate to the section in question once focused from the ToC). Do you have more details on this problem ? Which browser are you experiencing this on ? Is it an issue on all pages ? Which specific key sequences are you using ? Is this when the ToC is collapsed or uncollpased ? This shouldn't be a problem and this functionality was well tested multiple times, so I'd like to file a bugreport to make sure the problem is fixed ASAP. —TheDJ (talk • contribs) 19:54, 29 January 2023 (UTC)[reply]
If I understand correctly, the concern being expressed was for those who have difficulty with fine-motor control. Things like hovering over a specific target is more difficult. Has keyboard-based navigation also been tested (and compared across different skins)? isaacl (talk) 17:19, 27 January 2023 (UTC)[reply]
Hi @Isaacl - thanks for the question! Yes, keyboard navigation was tested as part of the accessibility testing of the Vector legacy and Vector 2022 skins performed by the American Foundation for the Blind. The results are available in this report on the project page. OVasileva (WMF) (talk) 20:16, 27 January 2023 (UTC)[reply]
Another supposed "results" page. Basically, some favorable "impressions" that the new skin "appears" to be working, countered by things that apparently don't, with exhortations to fix them. I suppose one can list that page under § "Neutral", above. 208.253.152.74 (talk) 22:00, 27 January 2023 (UTC)[reply]
No, it would be under support. It's generally good with a lot of suggestions. Aaron Liu (talk) 22:08, 27 January 2023 (UTC)[reply]
On second thought, it would be under none of the above. It evaluates how good the skin is, not whether or not it should replace the old one. It doesn't compare against the old one. Aaron Liu (talk) 22:11, 27 January 2023 (UTC)[reply]
Actually, WMF asked whether 4 different things got better compared to before, and only for 2 out of 4 does the WMF state that the new skin was considered an improvement. Nemo 11:07, 28 January 2023 (UTC)[reply]
I don't see the 4 specific points anywhere in T323634 Aaron Liu (talk) 14:49, 28 January 2023 (UTC)[reply]
Makes one wonder what exactly the so-called "results" page is doing here. Well, apart from the vague content. 65.88.88.237 (talk) 17:19, 28 January 2023 (UTC)[reply]
How was it vague? It's exactly what the blind foundation answered Aaron Liu (talk) 23:02, 29 January 2023 (UTC)[reply]
"Results" usually means something more objective and concrete than "impressions". But if impressions are to be the accepted metric, it would seem that negative ones inform the consensus here. 204.19.162.34 (talk) 01:39, 30 January 2023 (UTC)[reply]

A clarification from me (Sarri.greek) +I have already voted to rollback. I do not care about commercial aesthetics (we have no customers here): all skins look ok for me. I care for functionlity: as a wiktionarian I cannot work with Vector2022, because it does not have proper, immediately visible Contents, because we cannot operate Appendices witout _ _TOC___, and because we rely heavily on visible, and available at our fingertips languages Dictionaries are not encyclopaedias. We have Sections of 10 languages in one page. We neeed visible Contents (having also side Contents does not bother us). Sarri.greek (talk) 12:18, 28 January 2023 (UTC)[reply]

@Sarri.greek, then just switch back to the old skin. what's the problem? — Qwerfjkltalk 14:11, 28 January 2023 (UTC)[reply]
Also, this discussion is about the use of Vector 22 on enwiki, not Wiktionary. — Qwerfjkltalk 14:19, 28 January 2023 (UTC)[reply]
@Qwerfjkl, Vector 22 is deployed on many language locales, not just en.wiki. Part of the problem with Vector 22 is that it has broken UX for other locales, most notably sw.wiki. TheMissingMuse (talk) 17:40, 28 January 2023 (UTC)[reply]
@TheMissingMuse, yes, but this discussion is specifically about V22 on enwiki. — Qwerfjkltalk 19:12, 28 January 2023 (UTC)[reply]
I think it is reasonable for other wikis that dislike the new skin to be interested in this discussion. On its own, English Wikipedia is probably the only project with enough clout to force the WMF to bend on this. If we are able to force a rollback, that will set a precedent that other wikis can use. —Compassionate727 (T·C) 19:20, 28 January 2023 (UTC)[reply]
@Qwerfjkl, I think you're reading something that isn't there. The RfC is not about en.wiki. It's about the default skin. Here is the text of the RfC: "Should Wikipedia return to Vector 2010 as the default skin?" It's true that the change at en.wiki prompted the RfC, but this RfC applies to all locales. TheMissingMuse (talk) 06:44, 1 February 2023 (UTC)[reply]
@TheMissingMuse, the enwiki community doesn't have the authority to affect other wikis. That would need to happen on metawiki. — Qwerfjkltalk 08:14, 1 February 2023 (UTC)[reply]
It is there, on the top of the page: 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 Aaron Liu (talk) 15:21, 1 February 2023 (UTC)[reply]
Ι have done so, I switched Qwerfjkl, thank you (I have never known anything about 'skins' before, I am computer-idiot). As for wiktionary -being an outsider: Here I come as your guest and reader. Our thoughts (of administrators, and I hope of all editors) are not just for ourselves. We have readers who do not wish to take usernames. Also, as I pointed out at 1st edit, why switch when nothing was wrong with previous situation? Technical improvements could be done backstage without massive disruption. Some improvements = additions (not subtractions) could be added. Everyone would be happy. People are the key factor and our focus. Sarri.greek (talk) 14:23, 28 January 2023 (UTC)[reply]
then just switch back to the old skin. what's the problem? is a common theme among the opposes. That presupposes that the new skin is 'better' and it's a personal choice to switch back. But that's not the view of most of the supports which is that making an objectively inferior skin the default is nonsensical. And that's the real nub of the argument: is it or is it not inferior? Switching back doesn't address the fundamental difference of opinion here. (Also, as editors it means we have to format articles taking account of how it looks in two skins which isn't practicable.) DeCausa (talk) 19:51, 28 January 2023 (UTC)[reply]
Plus IPs can’t even do that. Dronebogus (talk) 19:57, 28 January 2023 (UTC)[reply]
@DeCausa, this is specifically in response to I do not care about commercial aesthetics (we have no customers here): all skins look ok for me. I care for functionlity: as a wiktionarian I cannot work with Vector2022 i.e. this is from an editor (personal) viewpoint, which has different priorities to readers (@Dronebogus and IPs) . Of course making an objectively inferior skin default is nonsensical; the problem is that this is subjective. I feel the new skin is better, perhaps it is even objectively better, but if an editor finds another skin more useful, then they are free to use it.
You don't have to worry about just 2 skins; a large number of viewers see the mobile site, so that also has to be considered. And of course, content can appear differently depending on viewport size, browser etc. — Qwerfjkltalk 23:43, 28 January 2023 (UTC)[reply]
To be honest I wasn't particularly adressing your post. What you said conveniently summarised many of the opposed responses, which are based on that fallacy. The mobile site v desktop is something we already consider. But switching back to the old now means it's x3. There's minor differences in all browsers but the whitespace and width issues etc of the new skin is orders of magnitude hugely more. DeCausa (talk) 23:51, 28 January 2023 (UTC)[reply]
@DeCausa, interestingly, a common theme amongst supports is why switch when nothing was wrong with previous situation?
This was explicitly addressed in the first RfC. In short, there are issues with V10 that V22 doesn't have. If you want more details, then I'm sure it won't be hard to find them (I can't remember them off the top of my head). — Qwerfjkltalk 09:47, 29 January 2023 (UTC)[reply]
I know them well. I don't need "more details"...as though I'm speaking from ignorance. There's disagreement on that...hence this RfC. DeCausa (talk) 09:51, 29 January 2023 (UTC)[reply]

What can we do if WMF again ignores community opinion and statistics?

[edit]

In their survey:

https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Repository/Sentiment_Survey

testers said:

- 60 - the old experience as easier to use
- 37 - the new skin easier to use
- 49 - both skins equally

So they concluded that: "Overall, users’ feelings towards the perceived usability of the new skin were positive ( with an average of 6.4/10)."

What ist not true and inconsistent with the results obtained.

The rejection of the vast majority of answers also raises serious doubts, where one of the reasons was foul language, są from 550 responses they saved only 152. And 60 + 34 + 46 = 146, not 152. So what about missing 6 votes? We do not have access to raw data.

In general, it looks a bit like the method of counting votes in the Belarusian presidential election.


A serious reservation is also raised by the lack of information on what devices the testers were working on? Were they phones, tablets, PCs? The needs of a desktop user are fundamentally different from the expectations of a person with a phone and a different form of the interface will be satisfactory for him, which we have reported many times, for example in this RFC.

In Requests for comment/Deployment of Vector (2022)

https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_%282022%29

community said:

- 154 votes for and
- 162 votes against new skin
- 9 neutral

Despite the lack of consensus, WFM implemented a new skin.


In this RFC we have now:

- 276 votes for vector 2010
- 200 votes vor vector 2022

Despite this, representatives of WMF seem to still strive to preserve the new skin. And I'm afraid they'll claim that adding a page width switch solves any reported issues and nullifies our objection


What can we do if this happens again?

Of course, we can vote with our wallets. But the conclusions of the polls and votes presented above are clearly wrong, if they do not even indicate intentional manipulation. Does Wikipedia have any control mechanisms at all when the "rulers" decide to act against the will of the community? Can WMF representatives just say that black is white? Is there no procedure for reporting erroneous official decisions? What are the mechanisms to protect WMF against possible corruption? Is there a no-confidence mechanism? Freja Draco (talk) 10:40, 1 February 2023 (UTC)[reply]

  1. @Freja Draco, this can be considered to fall under WP:CONEXCEPT - In particular, the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, and the sister wikis, are largely separate entities. These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features (see meta:Limits to configuration changes), or accepting or rejecting some contributions, even if their actions are not endorsed by editors here.
    This RfC could reasonably closed as no consensus, meaning that the new skin would stay (WP:NOTAVOTE). — Qwerfjkltalk 11:10, 1 February 2023 (UTC)[reply]
So 47% in previous RFC makes consensus but 57% in this RCF doesn't? Freja Draco (talk) 11:37, 1 February 2023 (UTC)[reply]
@Freja Draco, WP:NOTAVOTE. That's up to the closers to determine. It could also reasonably be closed as rollback V22. — Qwerfjkltalk 11:45, 1 February 2023 (UTC)[reply]
In the spirit of WP:NOCON, I assume a close of no consensus would default to an (advice of) rollback. We usually default to the status quo ante. Unless the closers determine that the requirements (one or three depending on the read of that close) for a consensus of the previous RfC were met of course. I must say, I share concerns about interpreting research in an overly optimistic fashion. Femke (alt) (talk) 12:47, 1 February 2023 (UTC)[reply]
Well, if we cant vote for it, then why did WMF declareed in the previous RFC that: If the community decides against deploying the skin, no deployment will be made? Freja Draco (talk) 14:38, 1 February 2023 (UTC)[reply]
The community closers determined that the community decided for deploying the skin after a persistent max width toggle is added. That shaky consensus interpretation was the closers' error, the WMF assumed it was right and uncontroversial. It’s an rfc not a vote, and it still decides. Aaron Liu (talk) 14:41, 1 February 2023 (UTC)[reply]
I disagree with that interpretation of the close. I feel that they gave one blocker (WMF must do this at least), and then 2 options to achieve firm consensus (WMF can choose which route to take to consensus). Femke (alt) (talk) 15:13, 1 February 2023 (UTC)[reply]
To add, the closers of the previous RfC disagree with that interpretation, per User_talk:ProcrastinatingReader#Review_of_your_closure. Both indicate in that discussion that the conditions of the close have not been met. Quoting PR: IMO the issues we said had to be satisfactorily addressed were not, and on some of the issues it doesn't appear like any attempt was made to make any further changes in response to RfC feedback. This implies a no consensus close of this discussion should result in a rollback or advice to rollback in the spirit of WP:NOCON. —Femke 🐦 (talk) 17:05, 1 February 2023 (UTC)[reply]
Hmm, good find! Aaron Liu (talk) 00:41, 2 February 2023 (UTC)[reply]
@Aaron Liu: Like I said in my !vote above, I've conducted and closed a lot of RFCs in my time. Some of them were among the most controversial we've had on enwiki but my closures have always been upheld, so I think I'm a fairly good judge of consensus. For the previous RFC, I spent time reading the entire thing and could not make any other determination other than that it was wrongly decided. If I had seen the close happen, I would have challenged it immediately at WP:AN. The closers openly state that they can't be sure if some (pretty solid) arguments raised by the opposition are actual blockers, but instead of making an attempt to find out they dismissed those concerns and decided that after the one issue they highlighted was fixed (which it wasn't), a second RFC to explore whether the remaining issues were an obstacle. The consensus wasn't just shaky as you say, it was fabricated. The WordsmithTalk to me 15:37, 1 February 2023 (UTC)[reply]
I agree with this. Aaron Liu (talk) 15:55, 1 February 2023 (UTC)[reply]
The WMF is awash with money, and lots of non-editors (and editors who like Vector 2022) will continue donating. Our only effective sanction is to stop editing en masse. This would hurt readers more than the WMF, and doesn't seem justified just for an unwanted skin change. However, if you're looking for a nuclear option, that's it. Certes (talk) 15:19, 1 February 2023 (UTC)[reply]
I really don't think we are at that point. Boycotting WMF seems a bit extreme. Cessaune [talk] 15:27, 1 February 2023 (UTC)[reply]
@Cessaune: We do know that mass resignations are a tactic that's forced the WMF to back down in the past. It's basically the only thing that has. The WordsmithTalk to me 15:39, 1 February 2023 (UTC)[reply]
There is an even bigger problem with an RfC and even these surveys, and that it essentially is a volunteer response sample. It is a bigger form of selection bias that means any consensus cannot be generalized to the entire community. Anyone that feels strongly opposed to this skin will submit their "vote" to the RfC or survey. Anyone that feels neutral to the skin or even likes the skin will do nothing. Anyone that really likes the skin and is likely logged in and thus an "editor" will also submit their "vote" to the RfC or survey. Graphic design is best left up to professional web designers, like those the WMF has employed as well as the countless volunteers with the qualifications. If the changes were incremental, rather than all at once, maybe the community would have felt more neutral about the changes. This also explains why there is a big shock when updating from an out of support version of Windows to the latest version; too many changes and not at all incremental. Aasim - Herrscher of Wikis ❄️ 16:21, 1 February 2023 (UTC)[reply]
This is not about graphic design, but about fixing something that is not broken, from the usability standpoint. Professionals can design all they want, but if the result is not comfortable to users, the design means nothing. It was asked previously whether there is something wrong technically or security-wise with Vector 2010. Or is it being superceded by other, necessary mw software? If such is the case, by all means fix it, if possible without affecting usability (user interface) elements. If that is impossible, communicate it to users, as such fix definitely would fall under WP:CONEXCEPT.
Other than that, an interface that millions of people use daily cannot be the plaything, or the employment opportunity of designers.
Nobody should force a user to do a so-called "upgrade". The members of the current global technology oligopoly seem to know that. Those that produce the content of Wikipedia should deserve the option. Do not force V22 and then "improve" it. For many editors there is already an improved skin, Vector 2010. 172.254.255.250 (talk) 16:53, 1 February 2023 (UTC)[reply]
"Graphic design is best left up to professional web designers, like those the WMF has employed as well" Why do you think than none of us are a professional webmasters? Fo example: I have over 20 years of experience in creatin websites, frontend and backend. And as a professional, I rate this project as tragic on the desktop. Just 10 years ago, every book and every web design tutorial advised: make everything on a website accessible in as few steps as possible. Unfortunately, for the last few years, design has been mainly done by people raised on mobile phones who do not even understand the paradigm of working on a PC. So their philosophy is: mobile firs and f... the rest! Professional web designers could make a trully responsive layout, which on large screens would use the available space to display easily accessible menus and on small screens it would collapse them into hidden drop down menus opened after clicking. Professional web designers could make make a page that uses only one html and different skins are obtained using css (look for csszengarden.com for example) which would perfectly solve the problem of reducing the number of files on cache servers. Freja Draco (talk) 20:34, 1 February 2023 (UTC)[reply]
You are making a lot of sense Freja Draco. Shearonink (talk) 01:58, 2 February 2023 (UTC)[reply]
Maybe it is because I am a Gen Z but it is the expectation now that content works on both mobile and desktop without any fuss. The same tools that work on desktop must work on mobile, and vice versa. According to this, over 43% of devices run Android, which is a mobile operating system. 30% of devices on the other hand run Windows. If you are not designing with mobile devices in mind, you are missing out on a lot of market share.
Vector 2022 is a step in the right direction, since it takes hints from responsive design and mobile screen sizes (though that has not been thoroughly factored in). On the other hand, I see no prospect of mobile readers ever using Vector 2010. I anticipate Vector 2022 will replace Minerva as the default skin on mobile, and, as Mobile Frontend gets phased out, eventually all the requests to en.m.wikipedia.org will just forward to en.wikipedia.org. There are a few more tweaks that need to be made in order to get Vector 2022 to work on mobile without the frontend (see phab:T319305 and phab:T106463) but overall, this is a better skin than Vector 2010. When WMF adds stuff like dark mode and additional tools for readers that outperform the current skin I am using, Timeless, I will certainly switch to Vector 2022. Aasim - Herrscher of Wikis ❄️ 18:50, 2 February 2023 (UTC)[reply]
No, vector 2022 has not been designed for mobile at all (save for the mentioned tasks). MineurvaNeuve fulfills the expectation you mentioned as a non-tablet mobile skin. This degree of responsive design is enough for a desktop skin. While v22 also could be worked into mobile, this rfc is mainly about desktop and we shouldn't take phone expectations into consideration. Aaron Liu (talk) 20:16, 2 February 2023 (UTC)[reply]
Why would any sane person design a layout which looks almost identical to the mobile layout *specifically* for desktop which doesn't properly work on desktop? Holundiman (talk) 13:40, 4 February 2023 (UTC)[reply]
I'd say there's a very big difference (e.g. fullscreen menus, font, background, the entire article header...) Aaron Liu (talk) 15:13, 4 February 2023 (UTC)[reply]
The Vector 2022 definitely leans heavy into mobile design. It looks like what a mobile designer might come up with if they were forced to design for desktop. It is certainly not designed for the desktop user. TheMissingMuse (talk) 19:24, 4 February 2023 (UTC)[reply]
I'd say the top bars do lean a bit into mobile design but every site leans into icons nowadays to take up less space/i18n/whatever. The rest looks pretty well designed for desktop. Aaron Liu (talk) 20:31, 4 February 2023 (UTC)[reply]
WMF has repeatedly asserted that Vector 2022 was designed specifically for desktops (hence the irritation of desktop users). However, even if V22 were to be a universal skin, it can still be made fully responsive, displaying on a PC an interface that is comfortable on a large screen with a mouse and keyboard, and on a phone one that is comfortable on a small screen operated with a finger. I see two reasons why this is not the case: 1) laziness / ignorance of the designers, 2) the belief that if I sit on a mobile, folding chair while fishing, I also have to sit on it at home to maintain the consistency of the user experience. Freja Draco (talk) 12:32, 3 February 2023 (UTC)[reply]
It's a bit funny that biggest tantrums (resignation!) are throwing users who can easily switch to any old skin and live in their happy bubble. What kind of visual improvements can ever be expected if we're gonna come here and vote what we like or not. If you said there was research among 10000 users that that version was better than this version I'd trust it. You can't close an RFC based on I like it or I don't, you can't even tell who's voting and why.50.239.155.90 (talk) — Preceding undated comment added 20:29, 1 February 2023 (UTC)[reply]

If the RfC was closed with a consensus in favor of rolling back to V10 and the WMF did not follow the community consensus, we may be able to implement consensus on our own by modifying the site's common.js. This is what happened after the community voted in WP:VisualEditor/Default State RFC to make the VisualEditor opt-in. The WMF told us to take a hike despite bugs that much of the community saw as dealbreakers, so we took matters into our own hands. The Foundation eventually deployed an official patch, but the community consensus stands to this day. —pythoncoder (talk | contribs) 17:42, 1 February 2023 (UTC)[reply]

#Truth. And consensus is how things are supposed to run around here.... Shearonink (talk) 01:58, 2 February 2023 (UTC)[reply]
I should clarify that I don't know the details of the technical implementation of such a change. It would also take an interface admin willing to make the changes. This is something that has changed since 2013, when any admin could edit the sitewide common.js, which in retrospect seems like a terrible idea. —pythoncoder (talk | contribs) 05:36, 2 February 2023 (UTC)[reply]
Changing the skin is not a change that can be done by modifying common.js. – SD0001 (talk) 10:32, 2 February 2023 (UTC)[reply]
Confirming that as far as I know, default skin is set in m:LocalSettings.php and not editable on-wiki. You'd need a sysadmin to make that kind of change, and that's one of these people. It might be possible to use common.js to rig up some kind of kludge to override it or force the page to reload with the correct skin or something, but I don't really see that as a viable option because it probably would make the user experience worse instead of better. The WordsmithTalk to me 18:51, 2 February 2023 (UTC)[reply]

Foreign language Wikipedias

[edit]

A number of the foreign language Wikipedias – including the Chinese, German, Italian, Polish, Russian, and Spanish sites – are still using Vector 2010. Since this would in theory eventually affect all Wikipedias equally, it occurs to me we are missing a huge portion of the conversation. Could someone with a knowledge of those languages explain why they haven't switched and summarize what the reaction is like there? Are they holding similar discussions? Are they more for or against it or is the community divided? –Noha307 (talk) 01:56, 2 February 2023 (UTC)[reply]

@Noha307: I don't know about the other ones but I do know a problem on the Chinese wiki. The table of contents won't convert characters, see T306862.Aaron Liu (talk) 13:23, 2 February 2023 (UTC)[reply]
The German wiki has a discussion at :de:Wikipedia:Technik/Werkstatt § Einführung Vector 2022 Aaron Liu (talk) 13:29, 2 February 2023 (UTC)[reply]
@Noha307 Hi. Szymon present V22 on one of large meetups for Polish Wikip(m)edia last year I think. I think the reception was rather good (people seemed to like the new skin). We also have most if not all scripts (gadgets and others) ready for the new skin. Might need to test with new changes (like the tools menu). There were some complaints about things changing too fast, but that will hopefully settle down. Also nice to see that the right side is now less empty (with tools being moved there). This was my complain from a long time and I'm glad this was addressed. But yes, there were voices we (on Polish Wikipedia) still need to talk about this more. I would say maybe once things settle down a bit more. Nux (talk) 09:29, 15 February 2023 (UTC)[reply]

I happened to visit Commons today to check up on a file there and noticed that its menus were different from Vector 2022 and so assume that there's been no change there. As that project is complementary to the language Wikipedias, what is the plan for that? It's confusing to have the projects all going in different directions. Andrew🐉(talk) 14:15, 2 February 2023 (UTC)[reply]

oh my word...I hadn't even thought of the FACT that Vector 2022 is going to go live over on Commons too...yikes for me. An aside to this discussion but does anyone now if editors will be able to enable Vector 2010 as their preferred choice of skin on Commons? Or not. Shearonink (talk) 16:41, 4 February 2023 (UTC)[reply]
Yes, the "Appearance" preferences across all sites are almost the same Aaron Liu (talk) 19:18, 4 February 2023 (UTC)[reply]
@Noha307, @Aaron Liu, @Andrew Davidson - thanks for the question. This basically comes down to the amount of time the team can dedicate to working with each community on each wiki. We want to make sure that we have sufficient time to have community conversations across each wiki, which means that we are slowly shifting all wikis to the new skin over a period of a few months (with the exception of the 30+ early adopter wiki communities who have used the Vector 2022 skin as the default for a few years already). Currently, we have more than 94% of Wikipedias switched to the Vector 2022 skin, as well as a large number of sister projects. We hope to complete the remainder of Wikipedias by the end of this month or early in March (there is, as mentioned, an issue currently with Chinese sites that we are working through). Many of these wikis are ready for the change and are currently discussing specific dates, but the team hasn't had enough capacity to kick off and participate in community conversations there, partially due to the currently ongoing conversations on English Wikipedia. For Commons and Wikidata specifically, some additional conversation and customizations will also be necessary. We hope to have the new skin as the default there by the end of March. A timeline is available on the project page for anyone curious. Hope this is helpful! OVasileva (WMF) (talk) 14:43, 2 February 2023 (UTC)[reply]
It is helpful, thank you. –Noha307 (talk) 21:29, 4 February 2023 (UTC)[reply]
I think I read somewhere that metawiki successfully lobbied and undeployed vector-2022. Can anyone find their RFC and link it, or am I misremembering? –Novem Linguae (talk) 16:29, 2 February 2023 (UTC)[reply]
The Swahili Wikipedia successfully did the same; at least from what I have read somewhere.--Æo (talk) 16:48, 2 February 2023 (UTC)[reply]
We haven't talked to the Meta-Wiki community yet. Swahili is a different case, and I wouldn't compare that with our discussions taking place since July. SGrabarczuk (WMF) (talk) 16:53, 2 February 2023 (UTC)[reply]
@SGrabarczuk, can you explain how so? — Qwerfjkltalk 17:11, 2 February 2023 (UTC)[reply]
@Qwerfjkl - thanks for the question. The main concerns of the Swahili community are not around the new skin itself, but with lack of support and resources from the community side to update existing documentation related to skins, which they have asked us to help with. We are currently trying to work with them on providing more support in terms of translations for documentation and any other updates. OVasileva (WMF) (talk) 17:26, 2 February 2023 (UTC)[reply]
@OVasileva (WMF) Again, no reference to the objections to the new skin, to the analysis of the test data, to the legitimacy of the "consensus" during the previous RFC. Just "show must go on" and "no comment". Freja Draco (talk) 18:07, 2 February 2023 (UTC)[reply]
@Freja Draco, that's beause the response is specifically answering the question Could someone with a knowledge of those languages explain why they haven't switched and summarize what the reaction is like there? Are they holding similar discussions? Are they more for or against it or is the community divided?
What do any of those have to do with the question? — Qwerfjkltalk 19:11, 2 February 2023 (UTC)[reply]
Qwerfjkl, there was no answer to what the reaction is, are they having similar discussions, or whether they're for or against it. Just "we're continuing to force this skin upon everyone".
Imagine if WMF had stopped for a moment to acknowledge some of the critique instead of churning through and disregarding criticism as "aversion to change". Jetro (talk) 13:06, 3 February 2023 (UTC)[reply]
@Jetro, We want to make sure that we have sufficient time to have community conversations across each wiki, which means that we are slowly shifting all wikis to the new skin over a period of a few months (with the exception of the 30+ early adopter wiki communities who have used the Vector 2022 skin as the default for a few years already). ... We hope to complete the remainder of Wikipedias by the end of this month or early in March (there is, as mentioned, an issue currently with Chinese sites that we are working through). Many of these wikis are ready for the change and are currently discussing specific dates, but the team hasn't had enough capacity to kick off and participate in community conversations there, partially due to the currently ongoing conversations on English Wikipedia. For Commons and Wikidata specifically, some additional conversation and customizations will also be necessary.— Qwerfjkltalk 10:22, 4 February 2023 (UTC)[reply]
The ironic part here is that there appears to have been little engagement with the early adopter communities. It does seem that we are in the same spot here. If these community conversations are happening, they are not happening in an open and transparent manner. TheMissingMuse (talk) 19:28, 4 February 2023 (UTC)[reply]
@TheMissingMuse, the team hasn't had enough capacity to kick off and participate in community conversations [in other wikis]— Qwerfjkltalk 12:55, 5 February 2023 (UTC)[reply]
There is currently a local discussion about postponing the deployment on Chinese Wikipedia. There are 26 votes in favour of the postponement and 0 votes against. Anyway, It is great to hear that there will be a conversation with WMF soon. (Please ping me if you reply me. Thanks.) --SCP-2000 18:25, 8 February 2023 (UTC)[reply]
I just tried to run that discussion through Google Translate so I could read some of the comments, but it is impossible to open the sections of the resulting page. Is this a V22 issue? I've never encountered this before. —Compassionate727 (T·C) 22:40, 9 February 2023 (UTC)[reply]
Addendum: it seems that Google is trying to run it through the mobile version, even though I didn't tell it to do that, so it's related to sections being broken on the mobile version. Weird, but not related. —Compassionate727 (T·C) 22:48, 9 February 2023 (UTC)[reply]

In general

[edit]

I like the old skin more too. In general I would say WP should not change stuff by force. If you guys have something new then let it run as a kind of beta. Place a button in upper right corner like "test new design". If someone push it the button turns into "go to old design". Then just let in run. 6 months later you will see if people use the new design or not. If it is a real game changer 90% will usw it by free will. Then you can switch. If just 10% use it. Forget about it. Changes are great and important! But finaly most changes are no game changers. They just eat a lot of time and resources. Its just different- not realy better. So, yes i love changes but just great changes. What i hate are bad updates. Changes that just eat my time and dosent bring advantages. Maybe just are more worse then before. And the most worse thing if websites FORCE me to use the new stuff against my will. This are the most worse changes. WP should not do this. OFFER something and then have a look. But dont do by force. GOOD stuff never needs force MumQuin (talk) 15:54, 2 February 2023 (UTC)[reply]

The new skin has already been around for more than half a year with a feedback process. —Tenryuu 🐲 ( 💬 • 📝 ) 17:55, 2 February 2023 (UTC)[reply]
90% is impossible no matter how good the change is. Most people won’t even bother to look at or click the button because a lot of people are lazy. Even when people need the max width toggle the button wasn’t noticeable. Just look at how many people
Plus, what do you mean force? If you’re talking about changing to the default, the default of course always needs to be the best (not saying that v22 is the best here just taking about “good stuff never needs force” Aaron Liu (talk) 19:01, 2 February 2023 (UTC)[reply]

Workarounds for circumventing V22 problems for IP-users by further complicating scripts do not solve anything

[edit]
The workarounds for circumventing problems of new skin for IP-users by even more complicating the scripts do not solve the problems created by this new skin. Please solve the problems by simply reverting to the widely praised and perfectly functional classic skin

I strongly dislike the recent habit of Wikipedia of pushing tons of completely superfluous and unwanted data over the internet to disturb my reading experience by blocking my view to the text I want to read by popping up unwanted texts and pictures of every linked article in the text, wherever my pointer happens to shortly cross some links in the text when I just try to move to some completely different target. If I wanted the data of any link to be transmitted and read the linked articles, I would just click on the corresponding links!

To prevent this annoying popup behaviour for each accidentially touched link, prevent unneccessary tons of data transmission and to be able to just read the article which I opened, I had to diasallow scripting on wikipedia. This way, I prevent this massive unreasonable data transmission, can peacefully read the artcle I am interested in without being disturbed - as well as any other article by clicking on the link.

The old skin just worked perfectly with this simple solution. Even though the new skin (now) seems to be defaulting to screenwide textflow if I turn on scripting, with scripting disabled, Wikipedia is now defaulting to only use half of my screen and blank the rest!

Instead of creating an even more complex scripting jungle to try to patch some of the most obvious problems of this conceptually broken new skin, please just solve all these problems by just reverting back the the wonderful, perfectly working and much praised classic skin - and make your new ideas optional!

The overview, beauty, efficiency, user-friendlyness, functionality und usability of the classic skin are incomparably better than those of the new skin! 77.12.69.132 (talk) 07:02, 5 February 2023 (UTC)[reply]

I agree. All the "fixes" they propose have no place on this page. They can post that to [desktop improvements] instead. Jetro (talk) 11:55, 5 February 2023 (UTC)[reply]
You don't need to disable scripting to disable Page Previews. See mw:Page Previews § Enable/Disable. Aaron Liu (talk) 14:10, 5 February 2023 (UTC)[reply]
Thank you Aaron for this Information! However I generally prefer to have scripting disabled on pages which I just want to read and where is no really good reason for actively interacting with a page or sending my data to the server. I more fundamentally wanted to point out, that inceasing complexity to a page/design/skin by adding more buttons, additional scripts, bypass-features and workarounds, etc. for cirumventing/reverting newly created problems creates mostly even more other problems (and need for even more complexity) than it solves - for problems which all have been merely nonexistent in the perfectly working, well-thought -proven and -accepted, widely praised clear simple classic skin of wikipedia - which I (also for this reason) very much wish to be restored as the default! ;) 77.12.69.132 (talk) 16:40, 5 February 2023 (UTC)[reply]
Yes, but I'd rather have WMF fix as much as possible in the meantime. Cessaune [talk] 17:44, 5 February 2023 (UTC)[reply]
@77.12.69.132: I have shortened the title of the section you opened. The original title is now an introductory line to your message.--Æo (talk) 17:50, 5 February 2023 (UTC)[reply]
Yeah, curb-cutting solves things for everyone. However I still like the new skin and this appears to be a problem that can reasonably be solved by Question #2, that is if the foundation listens. Aaron Liu (talk) 22:06, 5 February 2023 (UTC)[reply]
If you like the new skin as a logged-in scripting user, why don't you just set your preferred skin as your personal permanent default skin for you and everything is fine? No offense! For me, and many others above, question #2 does not nearly solve all issues with the new skin (and this question is asked only as a fallback, if god decides to stick with the new skin anyway...). I do not really understand how this decision is finally made. From this RfC it looks to me, that a majority of people for a wide variety of well explained reasons clearly (and often strongly) prefers the well-known and proven wonderful classic skin - which for most people is just THE (loved) FACE of Wikipedia! I actually am from Germany and I daily use (and in some cases correct) both, the german and the english Wikipedia. I am deeply grateful on my knees, that the sky did not decide to forcefully dump this plage on the German Wikipedia yet and thankfully did not find any actual plans to do so (while alternative skins are optionally available ;). What will happen now? Best regards. 77.189.12.241 (talk) 18:35, 6 February 2023 (UTC)[reply]
There is a fundamental problem with this line of reasoning. WMF shouldn't be adding features with the mindset of if you don't like it, just change it. They should be adding features wth the mindset of if you don't like it, let's fix it. Secondly, not everyone can be logged on at all times, so this is a poor argument. Cessaune [talk] 18:44, 6 February 2023 (UTC)[reply]
I 100% agree! (but I think exactly this speaks for keeping the proven default ... ) 77.189.12.241 (talk) 18:52, 6 February 2023 (UTC)[reply]
Agree with all of the above. Aaron Liu (talk) 23:12, 6 February 2023 (UTC)[reply]
Hi Cessaune, thanks for this comment.  I'm really glad to be reading this, and I hope we can clarify something that is very important about the project from our perspective.
First of all, I wanted to learn more about your approach on adjusting the interface based on what people like or dislike.  From our perspective, this is only one variable which we consider, in addition to other qualitative and quantitative data.  I'm really interested in hearing your line of thoughts on this though. Perhaps there's something we're missing!
Here's our approach:
The first goal of this project (next to "keep the utility for existing users") is to improve the experience of new and occasional readers and contributors.  In the case of the readership of English Wikipedia alone, we're talking about almost a billion unique devices per month, from pretty much all around the world (source).  Concerning the editors - you may want to take a look at this table and this chart.  In order to discover what works and doesn't work for such a large and diverse audience, we've conducted user research and quantitative testing of different types.  Surveys where people declare their preferences are also important – they let us see what we're missing, and what their needs are that we might not be covering – but they are only one measurement of many, which needs to be considered alongside other data.  For example, there's a risk that those who choose to chime in are not representative for most users with their diversity.  There's also a risk of misalignment between what people declare and what they actually do.  According to all the data we track (more about that later this week), we have met the first goal.
Now, we're analyzing the feedback and considering different options for meeting the second goal of the project.  (We'll write more about what we're considering in the message I mentioned above.)  But this is still analyzed in the context of what we've done to meet the first goal.
It's possible we're actually on the same page about this, so I apologize if some of this is obvious - I just wanted to write this out so I can understand better how you came to the conclusion you mentioned.
Thank you! SGrabarczuk (WMF) (talk) 23:24, 8 February 2023 (UTC)[reply]
@SGrabarczuk (WMF): Thank you for replying to my comment! I'll address a few things that I disagree with in your statement above.
--
Wikipedia:Interface changes (I realize that English Wikipedia essays are not binding in any way, not even to users of enwiki and especially not to WMF but I find this particluar essay valid in all user interface contexts, even ones separate from Wikipedia) lists out a pretty straightforward and simple way to go about changes like this:

To minimise pain, any interface change should be one of the following, and may progress through this list:

  1. small enough that nobody notices or complains,
  2. small enough that grumblings don't lead to a "we won't stand for this" snowball of outrage,
  3. opt-in,
  4. opt-in for existing users, opt-out for new users,
  5. easily opt-out for all users,
  6. important enough to impose despite pissing people off.
Numbers 1, 2, 3, 4, and 5 have, obviously and objectively, not been fulfilled. I would argue (and I think this goes for all Supports and quite a few Opposes) that #6 has not been fulfilled.
--
The first goal of this project (next to "keep the utility for existing users") is to improve the experience of new and occasional readers and contributors.
  • Goal 1 - improve the experience of new and occasional readers and contributors.
  • Goal 2 - keep the utility for existing users.
Okay. Fair. I can agree with the logic behind this.
--
For example, there's a risk that those who choose to chime in are not representative for most users with their diversity. - Yes. This is an issue. Canvassing is not the solution.
Canvassing was proposed by both sides (such as publicizing this RfC using the ArbCom voting list, which would introduce a massive editor bias), but, in the end, only WMF decided to go through with it, in the form of this email and others. This email cannot be described as anything but canvassing. We do not actually know who this email was sent to, which is the main issue.
--
According to all the data we track (more about that later this week), we have met the first goal.
Let's analyze.

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. 86 responses reported the new experience as easier to use or the new and the old experiences as equally easy to use. Of these, 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.

Let's do some math.
  • 86 - 49 = 37. checkY
  • Based on the phrase set of 152 valid responses, 152 - 86 = 66. checkY
  • Based on this, 66 valid respondents said that V2010 was easier to use. 49 valid respondents said that both V2010 and V2022 were equally easy to use. 37 valid respondents said that V2022 was easier to use. checkY
  • WMF: 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. checkY
This is deliberate, objectively biased manipulation of survey data to fit WMF's needs. Watch this:
  • My sentence: The majority of respondents reported that the old experience is easier to use or that the new and old experience are equally easy to use. checkY
See the issue? So when WMF says that they have satisfied a data-centric goal, I hesitate to trust the results. I realize that a user survey is not as valuable as a user test, but if WMF is willing to twist the results of their survey to fit their needs, how can I trust that they aren't willing to twist the data of their supposedly unbiased A/B test? When you say we've conducted user research and quantitative testing of different types—I simply cannot trust the data anymore unless I am able to actually see the test itself and understand how it was conducted. You know?
--
Now, we're analyzing the feedback and considering different options for meeting the second goal of the project. (We'll write more about what we're considering in the message I mentioned above.) But this is still analyzed in the context of what we've done to meet the first goal.
I will examine this statement as if I believed that WMF has actually fulfilled the first goal, which I don't.
It would be reasonable to assume that UI/UX changes are often met with resistance. Hell, Google changes its logo's font from Helvetica to Helvetica Now or Facebook changes the main background color from #fffefa to #faf7eb and everyone loses their minds.
It would also be reasonable to assume bullet 6 of the Wikipedia:Interface changes list above—important enough to impose despite pissing people off—is a fair restriction.
Given these two assumptions, it would be fair to assume that, if goal 1 has been satisfied, that WMF has done a subjectively poor job of upholding #6. Lack of effective communication is my main reasoning behind it.
A lot is being said without a lot being done. Words ae being shared, but change is slow and, necessarily, limited to the uncontroversial (persistent width toggle for example). The major issues with the interface are not being addressed in a timely manner. In addition, attmpts to ping you four (you, @OVasileva (WMF), @MMiller (WMF), and @AHollender (WMF)) have often resulted in silence.
I don't know what company policy is over at WMF, but it seems to me that you, along with the other WMF employees, have been assigned to 'deal' with this 'problem' instead of working together with us to assauge some of our objections. This is because things that seem relatively straightforward, such as a sticky TOC/standard TOC hybrid which wo solve a lot of editor problems, and have been proposed multiple times, have not been acknowledged.
--
I hesitate to say the word you when referring to WMF unless necessary. It feels wrong. WMF and whoever S. Grabarczuk is are not the same thing. I don't actually know how many of your opinions are your opinions, and how many of your opinions are WMF's opinions. As such, I realize company policy might get in the way, but... respond to this. I beg. I would like to understand WMF's position, but, more importantly, I would like to understand your position. Just to know if we have some friends over at WMF. Wow, this is long. Congrats to anyone who actually read all of this.
Please answer, Cessaune [talk] 04:49, 9 February 2023 (UTC)[reply]
Hello Cessaune -- thank you for pinging me, and more importantly, thank you for spending so much of your volunteer time looking over the materials about the new skin and participating in this conversation. While other members of the team can speak better to the details around design choices and the survey data, I wanted to reply around how we at WMF work with communities.
Involving our communities in the development process is a major priority for how we work, and as a product manager at WMF, is the most special and unique thing about building software in this movement. Many of us WMF staff are reading as much of the conversation about the skin as we can, and discussing it frequently. It's surfaced important cases where community members have pointed out ways the skin can be improved, and we've taken quick action (like in the case of the "Log in" button and the persistent fixed-width toggle, and others in progress). Then there are the cases where many community members disagree with major choices in the design. In those situations, we are balancing their important input with what we know about the millions of readers those choices affect -- information that comes from A/B tests, user studies, etc -- all in the goal of producing an outcome that works for as many users, and as many types of users, as we can.
As we continue this conversation, we will be continuing to measure, discuss, ask questions, test, and improve and change the skin. It definitely does take time to iterate and improve software. If there are great ideas that have come up in this conversation that we haven't fully engaged with yet, we definitely want to get to those and consider them in light of all the other incoming information, to figure out what will be best for as many readers and volunteers as possible.
I'm sorry about comments and questions in this very long page that have gone unanswered! Our team is trying our best to reply to as many as we can, and we will keep doing so. -- MMiller (WMF) (talk) 04:28, 10 February 2023 (UTC)[reply]
@MMiller (WMF), thank you for replying to my comment! I have a few questions to ask:
  1. @SGrabarczuk (WMF) said above: The first goal of this project (next to "keep the utility for existing users") is to improve the experience of new and occasional readers and contributors. How much of a factor are the users, and where do things like A/B testing fall on the editor/reader/WMF scale? Are specific user opinions more or less important than data gathered from things such as A/B testing and the like in WMF's eyes?
  2. Given the fact that WMF is not bound to any outcome this RfC comes to, will WMF respect the decision?
    • In WMF's eyes, does an outcome of no consensus constitute a rollback to the status quo or will V2022 stay?
  3. When you do these A/B tests, user studies, etc—will you be releasing the raw data?
  4. Will past surveys, tests, etc. be opened for all to see the raw data?
Thank you again for responding, Cessaune [talk] 05:23, 10 February 2023 (UTC)[reply]
  • we've taken quick action (like in the case of the "Log in" button and the persistent fixed-width toggle, and others in progress) Which ones? Then there are the cases where many community members disagree with major choices in the design. Again, Which ones? we are balancing their important input with what we know about the millions of readers those choices affect What is what "you know"? Did you have a survey/poll implying "millions" of users, really? For sure, all-white eye-strain affects every non-blind reader out there... Actually, we all have no clue about what you are discussing/changing right now. Task https://phabricator.wikimedia.org/T259240 seems to have very few people involvement, and your last change to the prototype https://di-content-separation.web.app/Moss is to test how Zebra #9 looks with or without borders (???)... If it is the way you address such relevant things, then you all at WMF have lost your way. No one here in this RFC and related is begging you for such thing as "Zebra #9 without borders", but a lot of people complains about eye-strain and wasted desktop full-screen realestate. Your words are kind, but they sound as somewhat empty if they're not backed by facts. Please, rollback to V10 or add a 100% persistent "Switch to old look" button for everyone ASAP. Thank you. 37.134.90.176 (talk) 08:23, 10 February 2023 (UTC)[reply]
    While I agree that the words here should be more specific and the raw data should be released (especially for the sentiment survey, also note that the millions thing was probably an inbuilt tracker), 1. The phabricator is also a community thing and low involvement isn't WMF's fault 2. People ARE complaining about the borders, just ctrl+F "contrast" to find some of them, what do mean "people aren't begging for '#9 with borders'"? Pretty much everybody wants borders here, period. That's a large part of the eyestrain and whitespace complaints. Aaron Liu (talk) 13:27, 10 February 2023 (UTC)[reply]
    Read it again, I said: "Zebra #9 without borders". This is a proof your eyes are already strained... :p 37.134.90.176 (talk) 14:04, 10 February 2023 (UTC)[reply]
    I know that’s what you said, but testing with or without borders doesn’t mean they want to stick to without borders, it simply means they want to test which variant of #9 would be the best which is probably needed if we want to use it. Aaron Liu (talk) 15:05, 10 February 2023 (UTC)[reply]
    Nop. It simply means they are not focused on the real problem with the whole all-white layout design: nobody asked them for "Zebra #9 without borders". It's simple resistance to implement plain "Zebra #9" as it was originally conceived. As I already said, I prefer rollback to V10; if not, permanent switch to old skin for everyone. But if not, then Zebra #9 WITH borders and 0px offsets, and full width text by default. And, of course, with all bugs fixed, and all the other items (dual TOC, language selector, mistery meat, etc.) addressed. Well, let's them work, and we'll see... 37.134.90.176 (talk) 15:49, 10 February 2023 (UTC)[reply]
Just that they’re investigating different ways to do #9 in the latest prototype shows that they are working on doing away with all white. Aaron Liu (talk) 17:04, 10 February 2023 (UTC)[reply]
@MMiller (WMF)
The only study we know, clearly shows that the old skin was rated as better by the majority of the surveyed users (60 people) compared to 37 people preferring the new skin.
Talking about some mystical tests (which are still in progress) that no one has seen and which are supposed to prove your thesis is not a serious argument.
Despite this NEGATIVE test result, you have introduced a new, undeveloped and massively criticized skin on many wikipedias, causing chaos, as people do not know whether to adapt the structure of articles to the new default skin, or wait for its withdrawal, or wait for its modifications (because I don't even know what it will look like in the end).
This is a harmful and unreasonable decision. Similar experiments should be conducted behind the scenes, not on the front-end of one of the biggest websites on the internet.
In this situation, I see the following solutions:
1) Instead of many empty words and assurances of concern for the interests of the community and users, a simple admission of error and withdrawal of an unfinished intermediate product.
2) Acknowledging explicitly that you will do what you want to do, because you can do it, because you have already planned it and nothing will change that. Hard, but at least fair in place of the political deception about "how important the opinion of the community is to you". In such a situation, many people gathered here would not simply waste their time on ineffective activity.
p.s. Politically correct, empty talk straight from the Public Relations department only backfires here, further irritating the audience, especially since your actions are in obvious contradiction to your words. Freja Draco (talk) 13:02, 10 February 2023 (UTC)[reply]
The fraudulent sentiment survey was not the only study. There were at least 14 other studies at mw:Reading/Web/Desktop_Improvements/Repository (disregard the "Posts and essays" section). Aaron Liu (talk) 13:15, 10 February 2023 (UTC)[reply]
I've not read the other studies closely and don't have time to right now, but they seem to be examining specific features and their effectiveness. The sentiment survey seems to be the only study done on whether or not people actually thought the changes were an improvement. Additionally, the other reports have their own quirks, like this one which is totally incomprehensible to me, or this one where they found that a sidebar was useful to logged-out editors and an annoying intrusion to logged-in ones, and accordingly decided to get rid of it by default for anons and keep it open by default for logged-in users (what?). —Compassionate727 (T·C) 19:25, 13 February 2023 (UTC)[reply]
The prototype testing and Hureo report are definitely unspecific and on the skin as a whole.
For the notebook: ignore all the code and click the Click here to toggle on/off the raw code toggle (Currently on mobile and the toggle doesn’t work could just be a mobile issue though). The rest of the notebook seems to be data gathering on how and how much users use Search, Sidebar links, Header links, Language links, and Table of contents Aaron Liu (talk) 20:16, 13 February 2023 (UTC)[reply]
Hi, @Cessaune
Thank you for your thoughtful reply. I appreciate you taking the time to write all of this out. Firstly - I want to extend my apologies for not replying to certain topics throughout this conversation. There is definitely a lot to reply to and fewer of us on the WMF end than on the volunteer end! We’re also spending a lot of our time working with the team on the solutions that come up in conversation here. This means that I might not be able to reply here every day, or to notice each individual ping. Regardless, it is important for us to address concerns and be active in this conversation. This is why our focus has been on replying where we can, and where a quick answer makes sense, but writing longer posts on questions and concerns that take more thought and could be helpful to more people.
I want to address a couple of your points, and we’ll do our best to reply further as much as we can - we definitely welcome your questions and I, personally, love talking about data so I appreciate the opportunity to dig deeper :)
Firstly, I wanted to address goal #6 in the essay you mentioned above. In our opinion - this goal has been fulfilled, based on the data we have, which we’ve pointed to a few times already. At the risk of being repetitive, I’d like to repeat Szymon’s comment from above - we looked at multiple data points and both qualitative and quantitative data throughout the project. If anyone is curious about digging deeper into details - the repository on the project page is a good place to begin with more than 20 reports published on the project there. This data chart can also be helpful for a quick summary that includes links to the original reports). We have tried to be as transparent as possible about our data and have published as frequently and with as much detail as we could given the constraints of our privacy policy. We will also be publishing a set of data and metrics that we’ve gathered since the deployment on Jan 18 and we encourage anyone here who is interested to dig deeper into the data and ask us questions on methodology.
I also wanted to address the survey you mentioned, to make sure there are no misunderstandings. As we noted in the original survey report, the goal of the survey was to identify sentiment towards the new experience upon deployment. We never intend to use surveys as the sole measure of the overall success or failure of software, and so our intention with publishing the survey results was not to provide proof that the skin is or is not more usable. Rather, the survey was meant to gauge the reaction and sentiment of people immediately after launch. It’s from that perspective – anticipating sentiment immediately after launch – that we described and interpreted the results of the survey in the way that we did. Mainly, our conclusions were the following:
  • A large group of users will express surprise immediately after the change, and there will be many negative reactions
  • Many users will feel neutral towards the change, or not notice it
  • Many will like the skin immediately
This made us better-prepared for what to expect on the day of deployment. Based on these survey results, we worked to make the day of deployment effects more smooth by:
  1. Running banners informing about the change
  2. Creating documentation that will explain the change to logged-out users.
In hindsight, we wish we had designed the survey differently so that we could learn more from it than what I mentioned above. It is really important to highlight that the survey did not actually expose users to the functionality of the new skin – rather it just showed them a single page shown in the skin without the ability to explore or click through any links. That makes it inappropriate to use as a gauge for usability. We are planning a survey that will account for this, which can give us details about long-term sentiment, over the upcoming weeks.
That said, we would, once again, recommend looking at all the data points holistically, and noting the specific purpose or goal of each experiment or research project. Across the project, we have research which was designed to show us what people were struggling with in the new skin, quantitative data and A/B tests that show real-world usage, surveys with communities focused on identifying edge cases and improving micro-interactions, and more. The decisions the team took based on these results were related to the stage of the project or feature, and also to the particular information we were trying to gather. We have been documenting additional information on these decisions alongside data reports and other means of documentation and, once again, encourage you to dig deeper and ask us any questions! We’re happy to engage as much as possible and dig into the data together.
Thank you again, and similar apologies for the long reply here, OVasileva (WMF) (talk) 14:59, 10 February 2023 (UTC)[reply]
Are there any plans to release the raw responses (including invalid ones “ in the sentiment survey? Is this somehow against the privacy policy? Aaron Liu (talk) 15:08, 10 February 2023 (UTC)[reply]
Except for the paragraph starting "In hindsight[...]", which sounds as a strange form of twisted apologize (I guess it is, at least it seems to me is the first time any of you admit something you've not did well; if so, wellcome), the rest of your loöong text is (again) your mantra "we didn't things wrong guys, please read this and this for you finally thinking exactly the way we think, which is the right way". Did you are really listening the community? I subscribe Freja Draco words: Politically correct, empty talk straight from the Public Relations department only backfires here, further irritating the audience, especially since your actions are in obvious contradiction to your words. You promised us something new will be on Thursday, today is Friday, the clock is ticking... and we saw nothing new: neither your wording, the prototype nor the English Wikipedia. 37.134.90.176 (talk) 15:31, 10 February 2023 (UTC)[reply]
Correct me if I'm wrong, but isn't there now a log in button outside of the ellipsis? Aaron Liu (talk) 22:55, 10 February 2023 (UTC)[reply]
For sure not yet at 15:31 UTC. At 0:31 UTC I can see the "Log in"... along every flaw in design, layout and usability we all the readers and IP editors have seen every day since the rollout. Still waiting some real change. Still tweaking URLs with "?useskin=vector". Boo. 37.134.90.176 (talk) 00:43, 11 February 2023 (UTC)[reply]
The "Log in" ... (outside the ellipsis) IS a change from before, it used to be inside the ellipsis. Are you sure you don't see what's in File:Log in, Vector 2022, before and after.png? Aaron Liu (talk) 15:48, 11 February 2023 (UTC)[reply]
At my location, the change was effective at some time between Friday 10, 15:31 UTC and Saturday 11, 0:31 UTC. I guess some caching was involved, but I don't mind. Everything else remain the same. This simple update changes nothing to me, and for many, I presume. Supporters of this very RFC still await for real changes, not breadcumbs. 37.134.90.176 (talk) 17:13, 11 February 2023 (UTC)[reply]
Does the persistent toggle for IPs, which came out last Thursday, count as a real change? Aaron Liu (talk) 18:49, 11 February 2023 (UTC)[reply]
Not at all. They only fixed a buggy feature of V22. A note: that toggle it is not fully persistent when you are using incognito mode in Chrome for Windows 10 with third-party cookies disabled (the default option). Logged-out, IP editor persistance vanished when you close incognito Chrome's window. Did you know? Did they know? Did they test? So arguably a full persistent toggle feature for logged-out users is not acomplished yet. I'm still adding "?useskin=vector" to URLs, so I don't care V22 flaws in my everyday use of English Wikipedia, aside to take care of this (I must load every page twice, Great!). I only test V22 every time an update is announced (twice since the original rollout). As I still see every already known and reported flaw, I "revert" to V10 by "?useskin=vector" parameter. And remember: this very RFC is for rolling back to V10, not to improve V22. 37.134.90.176 (talk) 09:34, 12 February 2023 (UTC)[reply]
(I presume you were talking about the already known full-width toggle. If you refer to any other toggle, I can't see it in my whole screen nor behind any menu. I see no new toggle at all.) 37.134.90.176 (talk) 09:56, 12 February 2023 (UTC)[reply]
@OVasileva (WMF), thanks for your reply. However, it only serves to piss me off more.
I had a whole rant planned, but instead I am going to ask a series of questions in a simple, uncomplicated format. I am going to request something reasonable—answer the questions in the same simple, uncomplicated format.
  1. It’s from that perspective – anticipating sentiment immediately after launch – that we described and interpreted the results of the survey in the way that we did. Reasonable editors can come to reasonable conclusions, and a vast majority of people disagree with your conclusions. Considering the fact that most of us are reasonable, why won't WMF just release the raw data (of all past and future stuff) and let us take a look?
    1. Is this a justification for this sentence: 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. Considering that the data shows a 66/49/37 split how did WMF come to this conclusion?
  2. Will WMF honor the results of this RfC?
    1. If this RfC ends in no consensus, will WMF rollback to V2010 or keep it at V2022?
  3. What happened to the Thursday date where we were supposed to get more information?
  4. Will WMF continue to improve the interface regardless of the outcome when the RfC ends?
Respectfully annoyed, Cessaune [talk] 18:19, 10 February 2023 (UTC)[reply]
I agree 100% with Cessaune's arguments. I personally asked SGrabarczuk similar questions by e-mail already on 23.01.2023 and I am still waiting for an answer, so I do not have much hope for any reaction.
I also wrote about it in this topic: https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Rollback_of_Vector_2022#What_can_we_do_if_WMF_again_ignores_community_opinion_and_statistics?
Also, let me ask again: what happened to 72% of the responses in the survey comparing the old and new skins, out of 550 votes, only 154 were considered valid? Where's the raw data? Why one of the "reasons" for rejecting votes was "foul language" and what percentage of votes were rejected due to "foul language"?
If "foul language" were to be the basis for taking away the voice of critics, then the current main Polish opposition slogan would have to go into oblivion and the vote of the entire Polish opposition could be considered invalid. Freja Draco (talk) 16:14, 9 February 2023 (UTC)[reply]
Wikipedia:Civility and Wikipedia:Assume good faith and Wikipedia:CONEXEMPT. It is very clear that there will be no consensus for rolling back, just as much as there was no consensus for implementation. Even if there is consensus WMF can just say "no we are not doing this". In the face of no consensus, any decision, keeping with or rolling out the new skin, will result in uproar. Wikipedia:Polling is not a substitute for discussion as well. "Votes" that make the same argument may be bundled up into one. I know you are about as frustrated with the rollout as me. I am happy yet equally annoyed about the nature of the rollout. For one, Wikipedia's skin is now almost 15 years old. Think about anything that lasted 15 years without any major design changes; I can't think of any. Eventually, Wikipedia's Vector 2010 design is going to be rendered incompatible with newer platforms and will start to eat into web traffic. Aasim - Herrscher of Wikis ❄️ 18:23, 9 February 2023 (UTC)[reply]
"anything that lasted 15 years without any major design changes" Fashion are the plague of the modern internet. As long as interface design was done by engineers, interfaces were focused on usability. Ever since "artists" got to it, they are constantly chasing "freshness", "lightness", "purity" and "modernity". 83.30.233.133 (talk) 20:47, 9 February 2023 (UTC)[reply]
I don't think that the majority of those who support the rollback are against any future improvement to the interface. The point of this RfC is that V22 is not a good replacement for V10, that the latter remains superior in many — if not most — respects, and that V22's redesign goes in a direction which distorts the desktop experience towards a mobile experience (this is explicit). The majority of the community clearly prefers V10 and asks for a rollback to it; this does not mean that the WMF can't continue to improve V22 to make it more appealing to desktop users. Æo (talk) 18:33, 9 February 2023 (UTC)[reply]
It is very clear that there will be no consensus for rolling back. I strongly disagree with this assessment. There is 2:1 ratio in support of a rollback (that is including the 15% of opposers who were canvassed by WMF employees), and with no underlying policy issues, there is no basis on which anyone's argument might be given more or less weight (except for the argument being blatantly wrong concering the facts, which these has been very little of). The closer is going to have an unenviable job sorting through all of those arguments and laying them out (because there will be an expectation that they comment on all significant points raised), but frankly, it would be a scandal if they found no consensus. —Compassionate727 (T·C) 18:51, 9 February 2023 (UTC)[reply]
I am very confused. It is very clear that there will be no consensus for rolling back, just as much as there was no consensus for implementation—How? Can you elaborate? Cessaune [talk] 22:21, 9 February 2023 (UTC)[reply]
I don't understand that either, plus even if there is no consensus the right action would be to roll it back as there is consensus that WMF didn't fulfill the conditions given in the previous close. Aaron Liu (talk) 13:34, 10 February 2023 (UTC)[reply]
As long as interface design was done by engineers, interfaces were focused on usability. Ever since "artists" got to it, they are constantly chasing "freshness", "lightness", "purity" and "modernity". No. Web design is very important because bad web design makes it difficult to use the site. WMF obviously took the point of view of the "reader" (or at least attempted to) and made changes backed by research to make the content easier to read and skim. YouTube, Google, Twitter, and Reddit are popular sites because they consistently found ways to make their content easier to read and view. We are also struggling with a serious misinformation problem in this era and sites with facts may look ugly and sites with fake news may look beautiful. To dismiss this research just because you like the old design is very disingenuous. Also, these designs are not being worked out by "artists", they are being worked out by those same software engineers that worked out the "old interface".
For It is very clear that there will be no consensus for rolling back, 2:1 is not that significant of a landslide. And even if it was, this is a discussion, not a vote. In a discussion, a single user's strong argument can easily counter 5 or 6 user's weak arguments. The closer (hopefully) is going to assess the strength of all the arguments presented in this RfC and give next steps that can be taken to better satisfy consensus. I agree this rollout was done in a terrible manner, but I also do not think there is anything we can do to change the skin back. There was also no consensus for implementation, which the WMF misinterpreted as "if we can add fixed width toggle then we can rollout".
I do agree that this new skin is a bit of a shock for those of us used to the old design but that is where I mention that from this point forward there should be incremental progress. Even if the changes are for the better, if you change everything it will come as a shock to everyone used to the old design. That is why versions of iOS and Android and Windows and macOS are only done in incremental releases, not all at once.
I have said if you want to know how broken Vector 2010 is, consider those with ultrawide or dual monitors such as gamers, graphics designers, and power users. On these monitors, every single paragraph shows up on one or two lines, making the skin unreadable. If your solution is "well narrow the browser window" well also consider that for some people that can expose distractions from reading such as the desktop or other windows underneath or even a full-screen application like a game or a video player. You will also want to consider why mobile devices have a different skin from desktop. It is because the desktop skin is unable to meet the needs of mobile users. Vector 2010 in its current form will never be able to do that. Vector 2022 can. Monobook can. Minerva can. Timeless can. Vector 2010, in its current form, can't. Aasim - Herrscher of Wikis ❄️ 16:17, 10 February 2023 (UTC)[reply]
To dismiss this research just because you like the old design is very disingenuous. I don't think I am dismissing this research. As I stated above, I don't trust the reasearch, because of deliberate misinterpretation by WMF. I agree that the research is important. I just want to actually see the raw data.
It is very clear that there will be no consensus for rolling back. Your argument makes sense, but very clear? 2:1 is pretty significant of a majority, in most cases. Why is it different for this particular issue?
I have said if you want to know how broken Vector 2010 is, consider those with ultrawide or dual monitors such as gamers, graphics designers, and power users. When I had dual ultrawide monitors, I had V2010 on one side and another browser window on the other side, or Logic Pro, or UE4. I don't know many people who use dual monitors as a single monitor (barring certain video games), which I assume is what you're referring to. It's pretty much always better to use those screens as two separate screen doing two separate functions, instead of as one. If I am misinterpreting your position, please let me know.
Thanks, Cessaune [talk] 17:14, 10 February 2023 (UTC)[reply]
Sorry, I should have been clearer, the first part is directed at the IP, not you; I am sorry if I sounded a bit snappy or blunt, I got a little bit annoyed at the IP comment that mentioned how the shift in software design might have been towards "artists" rather than graphic designers and software engineers that know how best to present content to maximize readability and usability.
As for ultrawide monitors, I am talking about those which typically have a 21:9 aspect ratio. And then there is software that can make the computer treat two smaller monitors like one big one. I don't know why people would do that, but I do know that on some monitors the bezel is so insignificant that it can be done without the bezel obstructing the text in any significant way.
For the landslide part, yes 2:1 is a bit of a landslide, but there are dozens of Wikipedia processes that do not pass without an even bigger landslide. Most RfAs with less than 75% support typically do not pass. And this is a request for comment, not a request for votes (hence why we have WP:NOTVOTE). A single strong objection can easily end the discussion in "consensus to not do X"; similarly, a single strong reason to do something can easily end the discussion in "consensus to do X"; but then in those cases other editors will mention "Support/Oppose per Y" provided Y makes that strong argument. It is also one thing if there is consensus to make this change; whether WMF will follow it is another thing. Taking a second pair of eyes and rethinking this, I think the consensus is going to be either "no consensus" or "consensus to roll back for now" or "consensus to roll back"; but I also think that a more accurate close might be "consensus to formally disapprove of the rollout of the Vector 2022 skin" and then leave it at that untouched, since it is out of the purview of the Wikipedia community to manage the backend that runs Wikipedia. A Phabricator ticket might be opened after this, but WMF can still decline it.
Fundamentally, regardless on how this discussion is closed or not or whether this skin is reverted or not, a follow-up should be done to identify the needs of the English Wikipedia community to see what EN Wikipedia is looking for in a skin. WMF can then take those ideas and package them all together very nicely. A process for identifying new features that a skin might need should be established, and the new skin should get regular updates and releases to add new features, better existing features, and remove unwanted features.
I hope this clears things up. Please let me know if I got anything wrong with this or if I still sound confusing. Thanks :) Aasim - Herrscher of Wikis ❄️ 06:20, 12 February 2023 (UTC)[reply]
The rejection of responses for not answering all the questions is even worse. If you don't force a responder to answer all the questions by technical means, they will assume they aren't expected to, especially when (as the survey authors admit) the survey is too long! Moreover, the fact that they didn't answer all the questions has no bearing on the truthfulness and reliability of whatever feedback they did provide! What kind of fool tosses out hundreds of responses over something as flimsy as that? —Compassionate727 (T·C) 19:06, 9 February 2023 (UTC)[reply]
The real issue is that we don't know which responses they threw out. For all we know, they could be justified in their reasoning, but there is no way to know, and there is no reason to trust them, considering the fact that they twisted that data to fit their own narrative. Cessaune [talk] 22:25, 9 February 2023 (UTC)[reply]
The kind of survey that wants to only hear "I'm right and everyone thinks so too". WMF don't care about your thoughts. They care about their egos. They want to be right and they are going to make sure they are "right". Even if they have to cook the books to do it. 2600:1700:1471:2550:6002:A2:F43C:2665 (talk) 22:36, 10 February 2023 (UTC)[reply]
Can I abridge this? They want to be right and they are going to make sure they are "right" to an extent. We are still volunteers, after all. Piss us off and the project dies. Cessaune [talk] 23:33, 10 February 2023 (UTC)[reply]
Do you know it for sure, Aaron? or Are a you only guessing? If you know it for sure, What are your sources? (Obviously neither the Task T259240 nor the prototype.) There are some people interested in tracking of, me myself among them. 37.134.90.176 (talk) 17:17, 10 February 2023 (UTC)[reply]

Couple more questions (switched back to Timeless)

[edit]

I just switched back to Timeless because of how incomplete Vector 2022 is. Vector 2010 is a good skin, but Timeless is more feature rich and customizable, and I anticipate it might snipe a few features from Vector 2022 like a sticky ToC or expandable width. At the most, we might express consensus to formally disapprove of the rollout, but whether anything changes is up to the WMF.

I want to ask a couple of additional questions as well.

  1. Beyond "WP:ILIKEIT" or "WP:IDONTLIKEIT", what technical problems is Vector 2022 causing for those who want the change rolled back to Vector 2010? ILIKEIT and IDONTLIKEIT IMHO are arguments without arguments. No one likes taxes, but taxes are necessary in order to pay for our infrastructure. And I think if we revisit this in a year, I don't think the hatred will be as strong as it is right now.
  2. Can these technical issues be addressed in a future update to the skin? If they can't, then I agree that specific user should be using legacy Vector.
  3. Are these technical issues happening on newer platforms or on older platforms? We should not be designing for platforms that no one will use; the web in 2022 does not work well on out-of-support platforms such as Internet Explorer or Netscape.

I think these would be more suited arguments for the RfC. The table of contents or languages being in a place that you don't expect it to be is a legitimate concern. The fixed width being too narrow causing problems with readability is a legit concern. Dark mode or the lack thereof is a legit concern. The skin's responsiveness or lack thereof is a legit concern. The look of buttons or even the look of the entire skin as a whole is not one. Wanting to preserve the status quo while the Overton window is shifting is very concerning. If nothing changes, people are going to get bored of the look and move on to something else. If everything changes, people are going to find it break their workflow and move on to something else. Wikipedia is the one site that I have been on for several years without any incremental changes to make it stay within modern web standards. I am not surprised that this change was found to be a big one, but I am also not surprised that people have moved onto skins that better fit their workflow. Aasim - Herrscher of Wikis ❄️ 19:45, 7 February 2023 (UTC)[reply]

Sorry in advance for going on a tangent, but your last para carries a real sense of urgency for change to keep up with other changes around us, yet you can just as well argue the opposite: what if we still matter because we've done nothing?
We've seen so many changes in the media since the release of Vector (2010): the fall of Facebook and Twitter; popularisation of completely new kinds of social media; paid print media all but dying in favour of ads and paywalls; rise, worldwide market dominance and subsequent fall of several IM apps; remote work and smartphone use entering the mainstream; rise of independent social media, notoriously including those catering to far/extremist politics; four redesigns of Microsoft Windows and about a dozen new versions of OS X (now macOS), etc.
In the meanwhile, more than a dozen Wikipedias have passed the millionth article milestone. Consider our competition -- how many sites on the list of online encyclopedias do you think the average person would recognise today? Thanks to Vector or not, we've outperformed all of them (except for Baidu Baike, and a part of that is due to Wikipedia being banned in PRC). Who even remembers Conservapedia anymore? (That's not to say that conspiracy theories and technophobia aren't on the rise and that people aren't ditching us in favour of social media echo chambers, but we aren't likely to appeal to that crowd by trying to blend in with what they call mainstream. Moreover, most of the new media kill their own chances of cornering the market anyway by bearing their political POV with pride, making the threat of any individual app or website rendering us obsolete even less realistic.)
Now, was sticking with the same design for 13 years the key to our continued success? That's fairly unlikely, but so is the notion that we're risking something by keeping Vector 2010. Daß Wölf 08:26, 13 February 2023 (UTC)[reply]
Agreed. Wikipedia has no meaningful competitors. No meaningful competitors will ever exist because they would need to build a large, dedicated community of volunteer scholars from nothing, as Wikipedia did, and without a robust community and a large body of articles to attract them, that poses a nigh-impossible entry barrier. We will not succeed or fail for mere cosmetic reasons. —Compassionate727 (T·C) 16:16, 13 February 2023 (UTC)[reply]
Apologies my response comes a few days late.
I think as an editing community (and reading community), we should focus on making content, and then let web designers adapt our content to fit the frame.
Vector by the way is not the reason Wikipedia trumped all of them. We trumped all of them because we provided more comprehensive information than most sites, more accurate information than most sites, and the WMF provided a platform where anyone could share their knowledge with the world forever.
What I am saying is, unless if there are urgent technical problems that are being caused by Vector 2022 that are not being fixed (which is unlikely since there have been dozens of patches and announcements by WMF over the past several weeks), I do not see a reason to ditch the skin.
And with regard to my above comment, yes, people love just the right amount of novelty and familiarity, which is why people prefer incremental change over complete redesigns. YouTube got better (and worse) with incremental changes, but it has not broken anyone's workflow. That is why several years later there are still a lot of people using YouTube. TikTok has also had its fair share of incremental changes. The only site I can remember that has underwent a major complete redesign is Reddit. That change was so overwhelming that Reddit provided a link to the old Reddit so that people could still use that workflow. If we want a major redesign, sure, but there has to be a way for logged out readers to be able to view the content of our site. Spinning up an "old" domain to serve Vector 2010 or allowing for IP design preferences allows for just that. There might be a "flash of unstyled content" for a brief few seconds while the page loads, but I do not think this will be overwhelming.
Loading pages "in place" (without having to load the skin all over again, only changing the buttons to match what the user can do) via the MediaWiki API allows for the caching of skin and page content and will certainly allow for IPs to go back to Vector 2010 and even Monobook. I do think there should be mobile responsive design as well in old Vector (just as Monobook) as well as responsive design being turned on for new Vector but I agree that this RfC has several flaws.
There would not have been even more opposition in my opinion if every single logged in user was not forcibly switched to Vector 2022, like what has been described on Wikipedia talk:Vector 2022. WMF should not have tampered with settings of logged in users. That is why I agree the rollout is botched; however, I don't think anything else should have changed, as it is a lose-lose situation for those that have set Vector 2022 before the rollout, unless if those preferences have been backed up somewhere. Aasim - Herrscher of Wikis ❄️ 00:20, 21 February 2023 (UTC)[reply]
Great summation of the argument against change for change's sake.
Considering that it has now been almost 30 days since the publication of this RfC and there is clearly no consensus to stick with V22, would the closure not result in a return to the status quo (as in - returning to V10)?
WikEdits5 (talk) 18:17, 13 February 2023 (UTC)[reply]
As there is consensus that either the previous closure was off or the requirements outlined in the closure weren’t satisfied, a no consensus closure would likely support v10 becoming default again. Aaron Liu (talk) 18:43, 13 February 2023 (UTC)[reply]

User survey

[edit]

@OVasileva (WMF), SGrabarczuk (WMF), MMiller (WMF), AHollender (WMF), and SDeckelmann-WMF: Can you please provide the anonymized raw results from the user survey you held last year, including all the results you rejected for various reasons, such as being incomplete or having foul language? There has been significant discussion of it above and giving us the chance to consider the raw data would be useful. BilledMammal (talk) 23:07, 9 February 2023 (UTC)[reply]

The silence is deafening. ~ HAL333 04:21, 15 February 2023 (UTC)[reply]
Below they said they were planning to release as much of it as possible, and that they had to verify with their legal team what they could release (I don't get why but whatever). Cessaune [talk] 04:57, 15 February 2023 (UTC)[reply]
According to their message there was a privacy statement in the survey so they’re checking with the legal team to see how much they could release in accordance with the privacy statement Aaron Liu (talk) 12:48, 15 February 2023 (UTC)[reply]
@OVasileva (WMF), SGrabarczuk (WMF), MMiller (WMF), AHollender (WMF), and SDeckelmann-WMF: Any update on this? BilledMammal (talk) 03:21, 25 February 2023 (UTC)[reply]

Tools to the left

[edit]
One of my primary complaints against Vector 2022 was that the tools menu was dockable only to the right hand side of the screen, and it was non floating. While I believe the tools menu has now been made floating, it's still dockable only to the right hand side of the screen. But we have the technology! Introducting my somewhat hacky, slightly buggy Vector 2022 Floating Tools Menu script. With this added to your vector-2022.js page, you can enjoy the benefits of having the Tools menu appear underneath the Table of Contents in the same floating area! And as an added bonus feature, on any page that doesn't have a table of contents, like the editing window, the script will create the necessary HTML elements so that the Tools menu will still appear floating on the left side of the screen.
Instructions and known issues can be found on the script's information page. I'm happy to answer any questions about it here, on my talk page, or on the script's talk page. I plan on keeping this working until either the Foundation add the same functionality as a configurable option in V22, or until they make a breaking change to the skin that I just can't workaround. Sideswipe9th (talk) 00:21, 19 February 2023 (UTC)[reply]
If you have the time you might want to add it to mw:Reading/Web/Desktop Improvements/Repository Aaron Liu (talk) 02:20, 19 February 2023 (UTC)[reply]
@Aaron Liu: done! Sideswipe9th (talk) 02:26, 19 February 2023 (UTC)[reply]

Stopping this RfC?

[edit]

I think this RfC should be stopped soon if a close doesn't come. It's been 52 days and it's still not abundantly clear who's going to try to close this monstrosity. Continuing discussion will only make it harder for them, and not to mention that most of the recent discussion—which has been about Radirb's oppose—is very tangentially related to the issue at hand. With over 550 !votes, I think we can safely say that literally every single argument in the uncountably infinite set of possible arguments has somehow managed to have been said at this point.
PS: The size of the RfC, the discussion subpage, and the talk page combined is about 1.7 MB of plaintext. Going by the typical 70 KB convention, this is the size of over 24 typical archive pages combined. Snowmanonahoe (talk) 18:02, 13 March 2023 (UTC)[reply]

There's been a close request out for nearly a month now. And an administrator's noticeboard request has been outstanding for a while now too. The problem is finding uninvolved editor(s), which is tougher than usual given the size of this puppy, as well as editors who are willing to take this monster on. schetm (talk) 19:55, 13 March 2023 (UTC)[reply]
Yes. What I'm suggesting is that we hat the RfC without a result, to make the job of the closers easier. Snowmanonahoe (talk) 20:57, 13 March 2023 (UTC)[reply]
Why would hatting make the job of closers easier? And I'm not sure how stopping it before a close would be beneficial. Aaron Liu (talk) 22:25, 13 March 2023 (UTC)[reply]
Discussions can reach a point where more words are just repeating already-expressed points for the Nth time, and thus are just placing a higher time demand on the one evaluating the outcome without providing any greater enlightenment into the consensus view. Also at some point there are fewer people reading new comments, and thus less people to help manage interpersonal conflicts, leading to greater escalation of contention. isaacl (talk) 01:33, 14 March 2023 (UTC)[reply]
I think we should post a notice at Wikipedia:Administrators' newsletter, or mass-message every active admin who hasn't commented on this page. That might sound a little extreme, but I'm really hoping this discussion will be closed by the end of the month, before it's too late. InfiniteNexus (talk) 23:20, 13 March 2023 (UTC)[reply]
"Every active admin" meaning everyone here, minus the folks who have made edits to this page or the subpage. InfiniteNexus (talk) 23:22, 13 March 2023 (UTC)[reply]
I feel that mass-messaging just for this would be extreme but we could include it as an "advertisement" for an admin to close this. Aaron Liu (talk) 00:27, 14 March 2023 (UTC)[reply]
Please don't mass message all admins (minus a specific subset). Admins interested in evaluating the outcomes of discussions are aware of how to find them; they don't need a prompt on their talk page. isaacl (talk) 01:19, 14 March 2023 (UTC)[reply]
Some people just need an extra nudge, and not all admins check the noticeboard or CR. Regarding mass messaging, if not all admins, perhaps a random sample of — I don't know, 50 admins? InfiniteNexus (talk) 04:18, 14 March 2023 (UTC)[reply]
Does an admin have to close this? Why can't any of us? If we defined which arguments we would accept and which ones we won't beforehand, then why can't one of us just do it? Cessaune [talk] 04:21, 14 March 2023 (UTC)[reply]
Because that would be a clear breach of WP:INVOLVED and WP:NACINV? InfiniteNexus (talk) 04:42, 14 March 2023 (UTC)[reply]
1. I think “Any of us” means a non involved non admin.
2. Since most of the observable Wikipedia has participated, maybe a competent editor could exercise IAR? Aaron Liu (talk) 11:01, 14 March 2023 (UTC)[reply]
I don't think we should take that risk. An involved close would most likely bring allegations of bias and immediate attempts to overturn the close, and then things will get ugly. InfiniteNexus (talk) 16:30, 14 March 2023 (UTC)[reply]
As the outcome doesn't rely on administrative privileges to enact the result, it doesn't require an admin, but it would be better if it were someone with a track record of evaluating discussions. isaacl (talk) 16:49, 14 March 2023 (UTC)[reply]
Admins interested in evaluating the outcomes of discussions do check those locations. I feel it is better to bump those notifications. isaacl (talk) 16:49, 14 March 2023 (UTC)[reply]
I see Aaron Liu has made a post at Wikipedia talk:Administrators' newsletter#RBV22. InfiniteNexus (talk) 16:46, 14 March 2023 (UTC)[reply]

Commentary to Radlrb's oppose !vote

[edit]

N.b. This commentary was moved here from the RfC's main page as it had reached an excessive length:

1) I believe, for the most part, that the old Vector Skin (2010) is best suited for editing. What I mean is that, and if I remember correctly, I have always felt that this skin in Wikipedia looked quite unwelcoming to my eyes, insofar as needing to read humongous lines that immediately made my mind, and my eyes, tired. Most people do not enjoy reading a line that is the width of your screen (especially the elderly!), and in today's world, these screens are massive, which means that there are massive lines to keep up with. From the perspective of the brain, this is quite tiresome, especially when things that we read today are generally, in physical form, limited to a book size, or in other instances, inside objects that could be relatively large but at a distance from us that is significant (i.e. a blackboard in a University of school setting, or an advert somewhere in the road). Meaning, we are used to having snippets of information presented at us, and in a reasonable way that can be digested; the Wikipedia legacy skin is really maybe one of the only generalized examples in the world, where we (most readers, that is) were forced to read something that was relatively unnatural to the general way of consuming text (which, could also be good if you think of it as an example that brings forth something different - but how good and natural is that differential for something that is an encyclopedic source of content, that is sometimes very important in the lives of those that use it; shouldn't it flow with the rest the variables in our lives?). Now, this has consequences: your mind treats the experience differently, because it is not the same experience as usual, and if the skin layout is also somewhat unnatural (which, honestly, it is - it is quite square, linear, and feels like a program, rather than something smooth and welcoming, and relatable in the outside world), then your mind is also inputting the information being read alongside these visual and intuitive cues that can either be consciously worked with (for some, or many of us), or just left in the subconscious within the reading experience. Note that it could also be positive to have this very male, linear experience, where what you read is what you need to read sort of experience, and it gets ingested that way. Personally, I do not like it as much overall, because it is usually a lot to take in. Some people prefer that; for me, I like the new skin as a general experience because it is more respectful to my eyes, and I can take in less and focus more on what is immediately in front, and I can relate it to a book experience and bring all of that joy in as well, usually. The Legacy Vector is so different from my own general reading experience that I have to turn on a a bit of a different reading behavior mechanism. And this can be exhausting at times, actually. So that is why I prefer the new Vector Skin 2022, from a psychological point of view.
2) From a perspective of change: Change is good, it lets your mind rest and move onto something new, while taking some of the old with you. The new skin doesn't have to be The Skin for the next 35 years, we can possibly make amends and bring new changes (like remove a bit some of the white space, and find more of a middle ground - I find that idea fascinating). But the importance of turning the page on something as big as Wikipedia is actually needed right now. People want change, people want space, people need space. We're moving in a direction where we are not focusing so much on everything being tight together and feel forcefull, but more relaxed, and respectful of one's senses. I think this new Vector skin is that. I really enjoy reading with it, it's a much smoother experience, and brings forth some feminine qualities that were really absent from the previous Skin. I don't have a source for this in front of me, however the more your peripheral vision is unaffected by visual stimuli, the more your focal vision is able to focus. In the reading experience, one moves and reads through the lines, and tracks past visual cues with incoming expected cues, as with any visual experience. It is logical, imo, that if we have less on the periphery, then we will be able to focus more on the immediate front text, so to speak (though, the converse could be true, if I have plenty of text in a line, I might be able to anchor my reading more within that line; but, again, it depends on how much we can handle and how used to these long lines we are). Again, change, is really, really important. And something as important as Wikipedia making a change like this also stimulates other changes in other industries and general collective aspects of life as a whole - there is a greater sense of "things are moving on here, let's also be part of this." Stagnancy is usually the primary contributor of decay, and having change of this magnitude is refreshing, welcoming, and permits the mind to breathe fresh air. I totally support keeping this Vector 2022 skin as our default skin.
3) Also, worth mentioning, that this skin unites us with the greater global Wikipedia, which is great and permits flow between languages of a common article if a reader desires.
Note: I do think we can reduce the whitespacing some, at least, while still maintaining this white space that is a focus of the new skin; I think it is great. Thank you to everyone that was involved in producing it, and working it, and everyone involved in this discussion (for support and oppose, and neutral and alterante ); whichever the outcome, we will have both skins as preferences we can choose from. Our real next effort is how to more effectively incorporate readers as editors, I think. Maybe this skin will help, that would be an interesting metric to observe. Best regards. Radlrb (talk) 04:10, 7 March 2023 (UTC), last updated 12:13, 11 March 2023 (UTC)[reply]
lol why not use some spacing? The amount of nonsense is overwhelming :D 212.5.158.236 (talk) 08:53, 7 March 2023 (UTC)[reply]
Fixed, thank you for reminding me. Tell me more about why you think it's nonesense. Radlrb (talk) 10:40, 7 March 2023 (UTC)[reply]
There is way too much, but here is only a few:
"Change is good..." - allways and no matter what
"change, is really, really important..." - really?
"...very male, linear experience...", "...brings forth some feminine qualities..." - what, UI has gender qualities?
"People want change, people want space, people need space" - people love empty white spaces, lets give them more; and change is allways needed
"We're moving in a direction where we are not focusing so much on everything being tight together and feel forcefull, but more relaxed, and respectful of one's senses" - and lets squeeze and squish the articles texts, its relaxing and respectful to senses, and by no means feel forceful to implement it without consensus
"...it is quite square, linear, and feels like a program, rather than something smooth and welcoming, and relatable in the outside world" - everything should be round or oval to be relatable in the world. Imagine if the books were round...so futuristic, so space-age!
"...this skin unites us...permits flow between languages..." - does it? how? ah, because its a Change!
212.5.158.236 (talk) 13:02, 7 March 2023 (UTC)[reply]
Obviously, you are nitpicking. Yes, I should have said, due change: when things become old, and an update that reflects, let's say, the general style of other websites across the world. The old vector skin just looks old and needed an update. You knew exactly what I meant with "Change is always good." This is what I meant. "...very male, linear experience...", "...brings forth some feminine qualities..." Definitely! I imagine you are a man, else you wouldn't necessarily be saying this. Wikipedia, and the new vector skin, in general have, for the most part, male aesthetic characteristics; except that the new skin has more spacing on the side, which is a feminine quality, yes. There are barely any round objects in Wikipedia, aside from the logo. Look at the most beautiful sites around, and you'll see that what makes them stand apart is generally: spacing, and a good balance of linear and round objects throughout. This is an aesthetic principle usually covered in design, though you might be unaware of this - people are more attracted to a well balanced format. What's next, because you know, you are being facetious. "People want change, people want space, people need space": yes they do. People enjoy having their own space, instead of cramming them with objects and unnecessary amounts of information. Yourself included. "We're moving in a direction where we are not focusing so much on everything being tight together and feel forceful, but more relaxed, and respectful of one's senses": No-one is squeezing anything, actually its being made easier so that you can read a manageable amount. Young people and the elderly will absolutely generally prefer this skin over the older skin, simply because it manages a lesser amount of information in your screen (say reading age through at least age 15; and above 60 years old). That's just intuitive, if you give me the "get research" argument for that, then I don't need to respond that. Go out on the street and ask people yourself; the main reasoning is that people that are learning something new will feel safer, and more in tune with the information if is presented slowly, and in manageable fashion, rather than with what could be with something that is too much to handle, and different than other reading material. "...it is quite square, linear, and feels like a program, rather than something smooth and welcoming, and relatable in the outside world": Yes, there should be a balance, and as I mentioned, relatable with other reading experience. "...this skin unites us...permits flow between languages..." I guess your monolingual, but I am tri-lingual, and I often switch between skins, and sometimes find it slightly bothersome that I have to re-adapt. And in the interest of globalization and being part of the greater community, you include yourself with it, rather than stand apart (something that America loves to do, by the way, and yes, I am American). We should do everything we can to unite, especially in these dark times; I am sensitive and I understand that Wikipedia can be an extremely important tool for that, since it is a top ten website in the world. It already feels like something very big clicked, when we changed vector skin; like, woah, we're on board, what a miracle! Radlrb (talk) 13:52, 7 March 2023 (UTC)[reply]
All that said, structured knowledge is so square and so 2010's. The future is the change, and the change is the future, because it's so round, smooth, welcoming and feminine!
Instagram and YouTube are much more popular and modern - Wikipedia have to look like them, and stop being imitation of some retrograde male encyclopedia. ---- 212.5.158.236 (talk) 13:39, 7 March 2023 (UTC)[reply]
Oh boy, when we can't bring forth a meaningful and thought-provoking argument, what do we do if we are in defensive mode? Mock. I won't feed that. Thank you for your responses though. Radlrb (talk) 14:05, 7 March 2023 (UTC)[reply]
"...this very male, linear experience, where what you read is what you need to read sort of experience, and it gets ingested that way. Personally, I do not like it as much overall, because it is usually a lot to take in" > It is the "geometrical structure" discussed here. And I think this "male" infrastructure that V10 provides is needed to convey knowledge, because information is structure and structure is information, while unstructured knowledge is not actually knowledge. Wikipedia should not be "something smooth and welcoming, and relatable in the outside world"; it should rather be a structure for conveying and displaying knowledge from the outside world.
"...change, is really, really important. And something as important as Wikipedia making a change like this also stimulates other changes in other industries and general collective aspects of life as a whole - there is a greater sense of "things are moving on here, let's also be part of this" > I really don't understand this holistic argument, which I think is completely unrelated to the encyclopedic purpose of this website. It is also worthwhile to note that amidst all this infrastructural "change for change" what is really important, the articles, are in most cases in a state of deteriorating mess. Wikipedia should abide by its purpose, which is that of being an encyclopedia.
"...this skin unites us with the greater global Wikipedia, which is great and permits flow between languages of a common article if a reader desires" > V10 does exactly the same, and many have complained that the new languages' menu actually hampers the communication between the versions of the same article in different languages. Æo (talk) 12:54, 7 March 2023 (UTC)[reply]
1) No, knowledge is best conveyed with structural and round objects. Not just with straight lines, ahahah !. That's one of the most male-dominating arguments I have ever heard for learning. You want all your senses and background processes in your mind to be open and ready to admit information. I don't have the time and space right now to explain how this is relevant to the brain, but your brain will be much, much more in-tune with the information if it is not presented in a dry manner, which the old skin is much more of: dry, old and like a program. It feels like early 2000s at best, like when it came out. That is my view, and I'm not trying to hit on Wikipedia, I am obviously an editor here. But the old skin is far too linear. As in obsessively linear.
2) "...there is a greater sense of 'things are moving on here, let's also be part of this'" Yes, for that you'll have to search within more deeply. If you think standing back in time, and never updating and renewing yourself as your own body does, and your environment, then you won't be able to age correctly. And everything around you will change while you remain static. It's pretty boring and does not bring novelty and a sense of freshness; and people will sense this. Most prominent websites look much more attractive and appealing than the old Vector 2010. It's just truth. And if you weant people to retain knowledge learned, there is one very effective way of doing that: by making the experience relatable and enjoyable.
I don't understand your last point, so I won't comment on it. What I said is already obviously logical; most skins in other languages have the newer skins, or V. 2022, so there is seamless movement between the two. Radlrb (talk) 14:02, 7 March 2023 (UTC)[reply]
This design is equally linear? The only difference in 'linearity' between V2010 and V2022 are the icons. Everything else is as straight as is was in V2010. I don't understand this argument.
Secondly, 'it's more pleasing to the eye' is obviously subjective, as a lot of people don't agree with this statement. It doesn't matter what is generallly true, it matters what people think, and if people think that the linearity of V2010 is better, then they are right, in the context of their own person. An argument predicated upon a wide generalization of all people and the way their brains work (and a non-sourced one at that) isn't really that good. Cessaune [talk] 14:46, 7 March 2023 (UTC)[reply]
I did say that this skin is also linear, but the white space balances out that linearity some, by making it less linear and breaking the massive lines where they can exist. So that's a response to your question, hopefully you understand it better. I didn't bring sources here, but I will get you some of those sources, I cannot at the moment as I have something to do soon (though what I mentioned about how the brain inputs information shouldn't need a source since it is something well documented scientifically that I mentioned... but yes, I'll get a source and ping you). If people really did enjoy reading from Wiki-stylized pages, then we would be seeing more of that style everywhere. But we don't. What we see is websites that are more balanced in spacing, and in straight-and-curved formats, at least the best of them; whether people would prefer that for Wikipedia beyond well beyond even what Vector 2022 offers, I think would be a positive response, in the same sense that you would enjoy learning in a well-built and furnished library that is accommodating instead of in a white chamber, day after day. You might want to switch it up though, which is what the various skins are for too. A skin doesn't have to be an aesthetic show either, but it can be neutrally pleasing and inclusive of both elements, masculine and feminine (more or less what V. 2022 is, though I would prefer it to have a little bit less white space indeed); it really is a subjective perceptive male imbalance to say that lines lines lines everywhere lines and only lines is best for learning, or even what people prefer (though without a doubt what has been exercised the most). It's really the only thing most people have experienced for Wikipedia, though, and we should keep in mind that maybe that's a nostalgia that people are clinging on, rather than giving this an actual try, so to speak. All said and told, I think we can improve this skin, rather than revert back and start from zero. I think, actually, that is the solution that will be sought in the end, after this discussion is over. Move forward, rather than backward. Improve what is being tested, and take the best elements of it, and merge them with something that was lost, if we so feel. Radlrb (talk) 15:15, 7 March 2023 (UTC)[reply]
Could you just stop equating design you don’t like with maleness and design you like with femaleness? Aaron Liu (talk) 15:41, 7 March 2023 (UTC)[reply]
I am not equating the aspects that I dislike with maleness, and the ones I like with femaleness, I am pointing out the imbalances; don't distort my comment; and your comment proves that it is a point worth bringing up, because, well, many are entirely unaware that there is even such a categorization that is relevant; and a direction that we are headed to - where there is greater balance. And, why this new vector skin is also necessary. Secondly, I can say what I want, and how I want. You don't get to dictate that. Plus, I never said I don't like lines, what I don't enjoy is a format that is overly linear, which in all honesty will continue to be the case for most on-line spaces, not just Wikipedia. We're still ways off from knowing how to truly build an aesthetically balanced website. Radlrb (talk) 15:53, 7 March 2023 (UTC)[reply]
Still, where did you get the idea of male and female UI design? I've never heard of anything like that. Snowmanonahoe (talk) 18:51, 7 March 2023 (UTC)[reply]
Philosophy, extending some notions with my own vocabulary, but if you study design enough this is exactly the language used, with these words and other vocabulary. And not just in design, but art in general. Mostly oriental, and Indian (from India) in origin if you want to know. A mixture of elements, it's actually very basic and intuitive. You cannot tend toward mono-polar designs, because ultimately, they will not be aesthetically pleasing and lead to exaggerations since they will only build upon themselves without something that is opposite which brings novelty. You need space, colors, dynamics...anything that leads toward ultimate harmony, and really, balance. Static yet moving, and so forth. You know, Radlrb (talk) 19:12, 7 March 2023 (UTC)[reply]
This seems more 'art theory' as opposed to 'UI theory'. Snowmanonahoe (talk) 19:20, 7 March 2023 (UTC)[reply]
...or some New Age theory. Whatever it is, I prefer V10's "masculine", square, linear, functional UI. Æo (talk) 19:31, 7 March 2023 (UTC)[reply]
It's exactly what happens when we overwhelm only one element in what is a system dependent on dual expressions. It's so strong that some of us do not even know the experience of having a differing experience that is extremely pleasant. If you're not saying, Wikipedia is one of the best reading experiences in my life, where you are glued, and sucked in overwhelming desire to continue to be absorbed into something continuously life-changing, then you don't have something special. And that's how you know Wikipedia is still, for the most part, an underwhelming experience for most people (I gladly do find myself melt at some particles, and know some others do). We need to focus on making Wikipedia not just a basket of knowledge, but an experience to be had. What achieves this? Respect for elemental balance in the way the information in it is conveyed, which falls on two shoulders mainly: the very system transmitting the experience, and the content that is found inside. These are the only two variables we have to operate under, aside from the internal experience inside Wikipedia itself, that entangles both. Beauty is an elemental part of learning, which is why making Wikipedia a necessary relatable experience is tantamount; it is to most that use it often a personal experience, and for many that use it sparringly, a cornerstone of knowledge even for initially trivial matters. As in, I learned about eclipses in Wikipedia, and since that moment I began my road in a life devoted in astronomy. Just imagine, the things we could, and will do, with Wikipedia. Radlrb (talk) 13:37, 11 March 2023 (UTC)[reply]
You've said a lot, but it basically boils down to WP:ILIKEIT. If people don't like this experience then they don't like it. There is no objective "beauty", there is no objective "balance". It's all subjective. And, from the perspective of editing, the changes are, when totaled, bad for me, and many others, non-editors and editors alike. Cessaune [talk] 15:09, 11 March 2023 (UTC)[reply]
I agree with Cessaune. For me V22 is bad, probably exactly because its increased "fluidity" gives an impression of disorganisation, and I think it will be detrimental to the quality of the articles in the long run. And I don't feel well at all if my mind and the information it receives are molten into many particles, to use your metaphor. And if people are "not saying Wikipedia is one of the best reading experiences in my life", and the encyclopedia "is still, for the most part, an underwhelming experience for most people", it is most likely due to the fact that 95% of the articles are in a wretchful, messy and repulsive state, and people (especially qualified people) are not enticed to read them, let alone improve them. Æo (talk) 15:33, 11 March 2023 (UTC)[reply]
No, I've said plenty more than just I don't like it. It just goes over your head, for the time being; funny thing is, I've said plenty of things that are on both sides of the isle, which is how I know your comment doesn't mean much, since you don't see any positive in what I've said, you're just salting, but you'll probably get over it. That is the hallmark of a bad conversationalist, when you just see negatives instead of bridging points together. Anyways, add on top of the 60% - 70% bad articles maybe (not 95% that is absurd) a particularly bad skin, and the matter becomes much worse.. I have however indeed said everything I have needed to say; a little class in decency for you both would go a long way. At least we know that you think Wikipedia is a garbage bin AEo, and if you think the people up above will care for your comment at all, given how much of a trash talker you are, and just in your own words, repulsive to even listen to, then you lost your own battle with your own words from the onset. Intelligent people are not interested in people who make stupid, classless arguments; includig insulting your own fellow editor (by mocking what you whink is my spiritual base, i.e. New Age, which is incorrect by the way). Gladly the world moves on, and this skin will likely stay. And you'll have to learn to live with it. Best regards. Radlrb (talk) 03:32, 12 March 2023 (UTC)[reply]
Please refrain from making personal attacks. An argument that consists of 90% personal attacks is a hallmark of a bad argument. Aaron Liu (talk) 05:07, 12 March 2023 (UTC)[reply]
"Attacks" as defense are sometimes necessary. If someone attacks my spiritual identity, and think it isn't serious, then get ready to get a bit of fire from me, because there are things that are clearly missing from his persona for him to belittle someone's spiritual and emotional background (in any way, direct or subttle as he did). I didn't see you put this here for him. It's because you are also being insensitive, and you didn't notice that is an attack, maybe because you might be undermining other spiritual paths, or see what I wrote as strange (above there you were also disrespectful to me, yes, before I initiated anything with you, or with anyone). I'm pretty used to it. Anyways, I'm done here, glad some characters came out too. Also a plus for my arguments because it shows that there are things out of touch. It seems any time I bring forth even an iota of spirituality, people cannot handle it because it is too filled with too many colors, emotions, and love. Oh well, that also changes in time. Radlrb (talk) 06:21, 12 March 2023 (UTC)[reply]
Let's fully define your argument, shall we? Fully.
  1. I have always felt that [V2010] in Wikipedia looked quite unwelcoming to my eyes, insofar as needing to read humongous lines that immediately made my mind, and my eyes, tired. (IDONTLIKEIT)
  2. Most people do not enjoy reading a line that is the width of your screen (especially the elderly!) (Source? Generalization?)
  3. From the perspective of the brain, this is quite tiresome... we are used to having snippets of information presented at us, and in a reasonable way that can be digested; the Wikipedia legacy skin is really maybe one of the only generalized examples in the world, where we (most readers, that is) were forced to read something that was relatively unnatural to the general way of consuming text. (Source?)
  4. [It] could also be good if you think of it as an example that brings forth something different - but how good and natural is that differential for something that is an encyclopedic source of content, that is sometimes very important in the lives of those that use it; shouldn't it flow with the rest the variables in our lives? (Maybe. Good argument.)
  5. Now, this has consequences: your mind treats the experience differently, because it is not the same experience as usual, and if the skin layout is also somewhat unnatural (which, honestly, it is - it is quite square, linear, and feels like a program, rather than something smooth and welcoming, and relatable in the outside world), then your mind is also inputting the information being read alongside these visual and intuitive cues that can either be consciously worked with (for some, or many of us), or just left in the subconscious within the reading experience. (Source? Also, are you implying that being square and linear is not smooth and welcoming? That also needs a source if this is the case.)
  6. Personally, I do not like it as much overall, because it is usually a lot to take in. Some people prefer that; for me, I like the new skin as a general experience because it is more respectful to my eyes, and I can take in less and focus more on what is immediately in front, and I can relate it to a book experience and bring all of that joy in as well, usually. (Not simply IDONTLIKEIT; good argument.)
  7. The Legacy Vector is so different from my own general reading experience that I have to turn on a a bit of a different reading behavior mechanism. And this can be exhausting at times, actually. So that is why I prefer the new Vector Skin 2022, from a psychological point of view. (Again, good argument; though this only pertains to you, it's quality.)
  8. Change is good, it lets your mind rest and move onto something new, while taking some of the old with you. (Change is good? As in, always?)
  9. The new skin doesn't have to be The Skin for the next 35 years, we can possibly make amends and bring new changes (like remove a bit some of the white space, and find more of a middle ground - I find that idea fascinating). (I agree.)
  10. But the importance of turning the page on something as big as Wikipedia is actually needed right now. People want change, people want space, people need space. (Generalization, source? I get the logic but you state it like it's a fact when, in fact, it is an opinion.)
  11. I really enjoy reading with [V2022], it's a much smoother experience, and brings forth some feminine qualities that were really absent from the previous Skin. (ILIKEIT; opinion treated as fact; what are feminine qualities? Curves? I don't get it.)
  12. I don't have a source for this in front of me, however the more your peripheral vision is unaffected by visual stimuli, the more your focal vision is able to focus. (Source? You need a source for this. This is just something you're saying if you don't have one.)
  13. In the reading experience, one moves and reads through the lines, and tracks past visual cues with incoming expected cues, as with any visual experience. It is logical, imo, that if we have less on the periphery, then we will be able to focus more on the immediate front text, so to speak (though, the converse could be true, if I have plenty of text in a line, I might be able to anchor my reading more within that line; but, again, it depends on how much we can handle and how used to these long lines we are). (You need sourcing for all this.)
  14. Again, change, is really, really important. And something as important as Wikipedia making a change like this also stimulates other changes in other industries and general collective aspects of life as a whole - there is a greater sense of "things are moving on here, let's also be part of this." Stagnancy is usually the primary contributor of decay, and having change of this magnitude is refreshing, welcoming, and permits the mind to breathe fresh air. (Source? Is Wikipedia a major contributor to change? A website that literally hasn't changed substantially for over a decade, despite websites of all sorts changing completely over the same time span?)
  15. Also, worth mentioning, that this skin unites us with the greater global Wikipedia, which is great and permits flow between languages of a common article if a reader desires. (Fair, but V2010 can do that also, so I don't see your point.)
  16. Note: I do think we can reduce the whitespacing some, at least, while still maintaining this white space that is a focus of the new skin; I think it is great. Thank you to everyone that was involved in producing it, and working it, and everyone involved in this discussion (for support and oppose, and neutral and alterante ); whichever the outcome, we will have both skins as preferences we can choose from. Our real next effort is how to more effectively incorporate readers as editors, I think. Maybe this skin will help, that would be an interesting metric to observe. (Yep, fully agree. Well said.)
  17. Yes, I should have said, due change: when things become old, and an update that reflects, let's say, the general style of other websites across the world. The old vector skin just looks old and needed an update. You knew exactly what I meant with "Change is always good." (Aha! Now I get it. WP:NOCOMMON begs to differ with your last point, though.)
  18. This is what I meant. "...very male, linear experience...", "...brings forth some feminine qualities..." Definitely! I imagine you are a man, else you wouldn't necessarily be saying this. (Unnecessary to assume someone's gender, but ok. I'm kinda confused.)
  19. Wikipedia, and the new vector skin, in general have, for the most part, male aesthetic characteristics; except that the new skin has more spacing on the side, which is a feminine quality, yes. There are barely any round objects in Wikipedia, aside from the logo. Look at the most beautiful sites around, and you'll see that what makes them stand apart is generally: spacing, and a good balance of linear and round objects throughout. This is an aesthetic principle usually covered in design, though you might be unaware of this. (You've never actually explained what the difference between male and female is. Also, source?)
  20. "People want change, people want space, people need space": yes they do. People enjoy having their own space, instead of cramming them with objects and unnecessary amounts of information. Yourself included. "We're moving in a direction where we are not focusing so much on everything being tight together and feel forceful, but more relaxed, and respectful of one's senses": No-one is squeezing anything, actually its being made easier so that you can read a manageable amount. (Yes, but all this is subjective. There is no objective unnecessary amount of info. There is no objective "more relaxed", and definitely no objective "respectful of one's senses".)
  21. Young people and the elderly will absolutely generally prefer this skin over the older skin, simply because it manages a lesser amount of information in your screen (say reading age through at least age 15; and above 60 years old). That's just intuitive, if you give me the "get research" argument for that, then I don't need to respond that. (Generalization as you self-described it; source? Also, NOCOMMON applies here. You don't get to say stuff like this without sourcing. There is no objective "intuitive". Also, I consider myself one of these "young people" you talk about, and I do not agree.)
  22. ...the main reasoning is that people that are learning something new will feel safer, and more in tune with the information if is presented slowly, and in manageable fashion, rather than with what could be with something that is too much to handle, and different than other reading material. (Generalization; source?)
  23. "...it is quite square, linear, and feels like a program, rather than something smooth and welcoming, and relatable in the outside world": Yes, there should be a balance, and as I mentioned, relatable with other reading experience. (Okay, but why? It's an encyclopedia; I didn't pick up I, Robot or Lord of the Rings. Why can't it stand on its own, given the fact that it's sort of an anomaly in the literature world?)
  24. "...this skin unites us...permits flow between languages..." I guess your monolingual, but I am tri-lingual, and I often switch between skins, and sometimes find it slightly bothersome that I have to re-adapt. And in the interest of globalization and being part of the greater community, you include yourself with it, rather than stand apart (something that America loves to do, by the way, and yes, I am American). (Two unnecessary, speculative and negative characterizations. Why?)
  25. We should do everything we can to unite, especially in these dark times; I am sensitive and I understand that Wikipedia can be an extremely important tool for that, since it is a top ten website in the world. It already feels like something very big clicked, when we changed vector skin; like, woah, we're on board, what a miracle! (I agree.)
  26. No, knowledge is best conveyed with structural and round objects. Not just with straight lines, ahahah ! (What? Source?)
  27. That's one of the most male-dominating arguments I have ever heard for learning. (Male as in human gender, or male as in com...puter[?] gender? Like the previous male you used above? If it's the first one, why does that matter, and if it's the second one, why does that matter?)
  28. You want all your senses and background processes in your mind to be open and ready to admit information. I don't have the time and space right now to explain how this is relevant to the brain, but your brain will be much, much more in-tune with the information if it is not presented in a dry manner, which the old skin is much more of: dry, old and like a program. (You neeeed a source for this. You can't just say this. Also, what is a "dry manner"?)
  29. It feels like early 2000s at best, like when it came out. That is my view, and I'm not trying to hit on Wikipedia, I am obviously an editor here. But the old skin is far too linear. As in obsessively linear. (V2010 didn't come out in the "early 2000s"; the rest is fine, given that it's only your own opinion.)
  30. "...there is a greater sense of 'things are moving on here, let's also be part of this'" Yes, for that you'll have to search within more deeply. If you think standing back in time, and never updating and renewing yourself as your own body does, and your environment, then you won't be able to age correctly. And everything around you will change while you remain static. (What? Two unnecessary, and, frankly, pointles characterizations... Being "static" isn't always bad, and what do you mean by "won't be able to age correctly"? You'll become digitally old? Stuck in the past? What? It's only a skin. It's not some new technology.)
  31. Most prominent websites look much more attractive and appealing than the old Vector 2010. It's just truth. And if you weant people to retain knowledge learned, there is one very effective way of doing that: by making the experience relatable and enjoyable. (Source? Also, opinion. Also also, NOCOMMON applies here.)
  32. I did say that this skin is also linear, but the white space balances out that linearity some, by making it less linear and breaking the massive lines where they can exist. So that's a response to your question, hopefully you understand it better. (Hmm. I guess. Makes sense.)
  33. If people really did enjoy reading from Wiki-stylized pages, then we would be seeing more of that style everywhere. But we don't. What we see is websites that are more balanced in spacing, and in straight-and-curved formats, at least the best of them; whether people would prefer that for Wikipedia beyond well beyond even what Vector 2022 offers, I think would be a positive response, in the same sense that you would enjoy learning in a well-built and furnished library that is accommodating instead of in a white chamber, day after day. (What? Source? Also, I would quite like reading in a "white chamber", provided I have a dictionary, couch/bed/table and chair, and some light. Much less distracting for my ADHD brain.)
  34. A skin doesn't have to be an aesthetic show either, but it can be neutrally pleasing and inclusive of both elements, masculine and feminine (more or less what V. 2022 is, though I would prefer it to have a little bit less white space indeed); it really is a subjective perceptive male imbalance to say that lines lines lines everywhere lines and only lines is best for learning, or even what people prefer (though without a doubt what has been exercised the most). (What? So many issues here. "...it really is a subjective perceptive male imbalance"? What? Also, who has said this latter part? I didn't. Any good Support argument didn't. Frankly, it's not about the lines, it's about the seperation or lack thereof. The separation can be done by using lines or colors or whatever.)
  35. All said and told, I think we can improve this skin, rather than revert back and start from zero. I think, actually, that is the solution that will be sought in the end, after this discussion is over. Move forward, rather than backward. Improve what is being tested, and take the best elements of it, and merge them with something that was lost, if we so feel. (I agree 100%.)
  36. I am not equating the aspects that I dislike with maleness, and the ones I like with femaleness, I am pointing out the imbalances; don't distort my comment; and your comment proves that it is a point worth bringing up, because, well, many are entirely unaware that there is even such a categorization that is relevant; and a direction that we are headed to - where there is greater balance. (Fair.)
  37. Secondly, I can say what I want, and how I want. You don't get to dictate that. (Of course, to an extent. WP:PA and whatnot.)
  38. Plus, I never said I don't like lines, what I don't enjoy is a format that is overly linear, which in all honesty will continue to be the case for most on-line spaces, not just Wikipedia. We're still ways off from knowing how to truly build an aesthetically balanced website. (There is no objective "aesthetically balanced website". The rest is a fair opinion.)
  39. Philosophy, extending some notions with my own vocabulary, but if you study design enough this is exactly the language used, with these words and other vocabulary. And not just in design, but art in general. Mostly oriental, and Indian (from India) in origin if you want to know. (No source but a country is a start.)
  40. You cannot tend toward mono-polar designs, because ultimately, they will not be aesthetically pleasing and lead to exaggerations since they will only build upon themselves without something that is opposite which brings novelty. You need space, colors, dynamics...anything that leads toward ultimate harmony, and really, balance. Static yet moving, and so forth. (This is opinion treated as fact. Makes sense, but then again, NOCOMMON and all that.)
  41. It's exactly what happens when we overwhelm only one element in what is a system dependent on dual expressions. It's so strong that some of us do not even know the experience of having a differing experience that is extremely pleasant. If you're not saying, Wikipedia is one of the best reading experiences in my life, where you are glued, and sucked in overwhelming desire to continue to be absorbed into something continuously life-changing, then you don't have something special. (I agree, but this is only an opinion, and I don't like the last phrase.)
  42. And that's how you know Wikipedia is still, for the most part, an underwhelming experience for most people (I gladly do find myself melt at some particles, and know some others do). (Most? Generalization; source?)
  43. We need to focus on making Wikipedia not just a basket of knowledge, but an experience to be had. (I agree, but this is an opinion treated too strongly. 'I think' would fit better than "we need" IMO.)
  44. What achieves this? Respect for elemental balance in the way the information in it is conveyed, which falls on two shoulders mainly: the very system transmitting the experience, and the content that is found inside. These are the only two variables we have to operate under, aside from the internal experience inside Wikipedia itself, that entangles both. Beauty is an elemental part of learning, which is why making Wikipedia a necessary relatable experience is tantamount; it is to most that use it often a personal experience, and for many that use it sparringly, a cornerstone of knowledge even for initially trivial matters. (Makes sense logically. Good argument.)
And that's your opinion.
Now, pertaining to your later statements:
No.
No.
Let's go through again, shall we?
  1. No, I've said plenty more than just I don't like it. It just goes over your head, for the time being; funny thing is, I've said plenty of things that are on both sides of the isle, which is how I know your comment doesn't mean much, since you don't see any positive in what I've said, you're just salting, but you'll probably get over it. (Yes, you have; it doesn't go over my head or AEo's head; I see positives and negatives in your argument, mainly negatives.)
  2. That is the hallmark of a bad conversationalist, when you just see negatives instead of bridging points together. (WP:PA? Comment on content, not on the contributor. Also, again, I see positives also.)
  3. Anyways, add on top of the 60% - 70% bad articles maybe (not 95% that is absurd) a particularly bad skin, and the matter becomes much worse.. I have however indeed said everything I have needed to say; a little class in decency for you both would go a long way. (Opinion treated as fact. Also, I apologize if I wasn't being as thoughtful as I should have been. That is never okay. I'm rectifying it by being more thoughtful than I've ever been on Wikipedia.)
  4. At least we know that you think Wikipedia is a garbage bin AEo, and if you think the people up above will care for your comment at all, given how much of a trash talker you are, and just in your own words, repulsive to even listen to, then you lost your own battle with your own words from the onset. Intelligent people are not interested in people who make stupid, classless arguments; includig insulting your own fellow editor (by mocking what you whink is my spiritual base, i.e. New Age, which is incorrect by the way). Gladly the world moves on, and this skin will likely stay. And you'll have to learn to live with it. Best regards. (This IMO constitutes a personal attack. Please refrain from using such negative language against a fellow editor. I get your point, but you need to be nicer. Also, best regards after this just seems disingenuous IMO.)
  5. "Attacks" as defense are sometimes necessary. If someone attacks my spiritual identity, and think it isn't serious, then get ready to get a bit of fire from me, because there are things that are clearly missing from his persona for him to belittle someone's spiritual and emotional background (in any way, direct or subttle as he did). (I don't think I have ever disagreed with a statement said on Wikipedia more. Attack are never justified. Never. Never means that in no situation is a peronal attack ever justified. I can't and won't try to understand the logic here. Please strike this.)
  6. It's because you are also being insensitive, and you didn't notice that is an attack, maybe because you might be undermining other spiritual paths, or see what I wrote as strange (above there you were also disrespectful to me, yes, before I initiated anything with you, or with anyone). I'm pretty used to it. (Again, one attack doesn't justify another. Also, IMO, "I'm pretty used to it" just sounds disingenuous. I don't know.)
  7. Anyways, I'm done here, glad some characters came out too. Also a plus for my arguments because it shows that there are things out of touch. It seems any time I bring forth even an iota of spirituality, people cannot handle it because it is too filled with too many colors, emotions, and love. Oh well, that also changes in time. (What? I can only speak for myself, but I don't disagree with your answers because of their spirituality. Above, I said nothing about that. I disagree with most of your arguments because they are founded upon unsourced material, or are generalizations. An argument based on your own spirituality is fine IMO.)
I'm done. Wow. I wrote way more than I meant to. Good night, Cessaune [talk] 04:43, 13 March 2023 (UTC)[reply]
Changed my mind. I'm going to leave it at this. I don't need to respond anymore. Especially since you are so closed to hearing why I will spit fire when I need to, when some cultural prejudice raised against my identity occurs, meaning my spirituality. If you are going to sit idly if someone insults your entire intellectual background, that goes to your roots, then you do not know how to engage effectively in creating change; I stand up for my spiritual and non-spiritual sisters and brothers, for everyone, and I never insult what is sacred from others. Sometimes, you need hurt people so they get a perspective of the damning things they say (because they are so deaf on the vocabulary of love), because these are prejudiced emotions and perspectives that are years and decades old, and don't come out with a simple word or two (!). Maybe you're too young to understand this, but that's how it is; that's how real emotional injustices are undone deep at the core, by returning it alongside love in the face of those who acted this way. It always works, because no-one likes to see their own dirt, and everyone prefers deep down to act in kindness; so when you present both in equal measure, the person changes. Thank you for your replies, and rehighlighting of everything. But I don't need to say anything else anymore. Radlrb (talk) 11:59, 13 March 2023 (UTC)[reply]
(edit conflict) Again, there is WP:NOCOMMON sense. Your personal philosophy might not be right and we can't just take the output of it as fact, especially when we don't know what your philosophies (i.e. the reasonings) are. (Note that this oly applies to your refutation of needing sources)
Æo is a researcher in philosophy and new religious moments. I believe they were merely trying to get the gist and categorize your philosophy. I don't know where you got the idea from, but "New Age" is not derogatory at all. Aaron Liu (talk) 12:03, 13 March 2023 (UTC)[reply]
The addendum "some New Age Theory" is what is derogoatory (i.e. the word some); and the fact that he assumed I am under New Age. It's just prejudice all over. I'll get two sources I know you might need, that is it. The rest, I can say as I feel since they were my feelings and there are no possible studies that could have covered what I felt (i.e. really young people and old people across cultures will tend to prefer shorter lines because they cannot keep focus as long as normal people. That is just obvious, natural; and the rest about this skin being a relatable experience is just also logical). Radlrb (talk) 12:13, 13 March 2023 (UTC)[reply]
I'm even more confused now, how is "some" derogatory here? It's a normal article just like "a". (Technically, it's a determiner which has the same meaning as "a" in this context.)
There are multiple hypotheses you can get just from thinking. Aristotle made a complete set of natural philosophies just from thinking, but without experimentation and real-life data gathering he got a lot of it wrong. Some things can't just be claimed based on common sense, and just hypothesis-like thoughts can also be refuted by other hypothesis-like thoughts. For example, I could say that "the focus doesn't matter in context of line lengths as the overall word-count of the document is the same and new lines don't break focus as it's still the same document". Aaron Liu (talk) 12:26, 13 March 2023 (UTC)[reply]
I don't think you understood what I said. Let me repeat it:
Attacks are never justified. Never. Never means that in no situation is a personal attack ever justified.
Do you understand why? Do you understand why biting back doesn't work? I'm sure you're older than me. How much of life is simply biting your tongue and staying quiet? Do you say every snide remark that pops into your head, come up with every fiery comeback when someone disrespects you? Likely not. You learn to live and forget.
The wise words of Dr. Doofenshmirtz always come to mind:
Have you ever wondered what it is that holds the fabric of society together? No, it's not cooperation or trust or any of that stuff hippies want you to believe. It's lies. All the little white lies we tell each other.
It's what we don't say, those lies of omission. It's what we twist, it's what we leave out, it's what we conveniently 'forget' to mention.
Yes, you look fat in that dress, Karen. It's not a good look. No, you're not fat; it looks nice on you.
What is this? This is terrible! It's tastes like wet feet and tv static. I actually really like the casserole. It's tasty.
What? I wanted the new smartwatch. I even dropped all these hints, and made sure he knew... Thanks so much, I love this!
She's so ugly, I hate her! Hey Kendra, love your makeup!
Oh my god, Kallie. Her lazy ass can't be bothered to do any of the work. She's always outsourcing it to me. I'll be happy to!
You... you smug little son of a bitch. Look at that smile. Fuck you, Kyle. I hate you and your stupid little mind games. *stays silent*
I just realized all my names start with K. Hmm.
You get it? You can't always say what you want to say. Here's a scenario.
The employees hate the boss because she enforces arbitrary, unnecessarily strict rules; the boss is fed up with her higher-ups because they give her tasks that she deems stupid and they ask her to enforce rules that make her unpopular; the higher-ups are mad at the CEO because he threatens to fire them if what they do doesn't work; the CEO is mad at the higher-ups because nothing they do is working, and he's watching his company crumble around him.
The employees will stay, or they will migrate on to different jobs, but, as it stands they are pretty safe. The boss is generally safe; she is only enforcing rules, and she does a pretty good job at that. The point of danger is the CEO—higher-up divide: The CEO is in danger of losing his job if the higher-ups kick him off the board; he only owns 33% percent of the company, so they could do it now. The higher-ups are in danger because at any moment they can be fired, though it would have to be a joint action between the CEO and any two higher-ups. They've worked hard to get where they are. They don't want to lose it to favoritism.
Since the CEO was not an effective communicator, he is the only one in any real danger of losing his job. He said what he wanted to say because he was scared. Scared of losing everything. And, in a moment of stress, he just made matters worse for himself, by hanging the threat of firing over the higher-ups' heads.
---
The golden rule. I'm sure you've heard of it. It's a cool rule because cultures of all different shapes and sizes have it, even cultures that never had contact with Western, Middle Eastern, or mainland Asian cultures (the big three in antiquity, if you will):
Treat others the way you would like to be treated.
The simplest way to combat fire is not water: it's flame retardant. Aim at the base and slowly, calmly, remove its legs from underneath it. Fighting fire with fire does not work, and fighting fire with water doesn't work either. This is a grease fire.
Anyways. See you later. Cessaune [talk] 16:03, 13 March 2023 (UTC)[reply]
This conversation has increased the RfC's wordcount by the length of The Tell-Tale Heart and The Fall of the House of Usher combined. Perhaps it could be hatted so the RfC closer doesn't feel obliged to read it? Sojourner in the earth (talk) 16:42, 13 March 2023 (UTC)[reply]
Haha. Dang. It's not done yet. I'll hat it when it's done. I knew I typed a lot, but not that much. Cessaune [talk] 16:45, 13 March 2023 (UTC)[reply]
Uff, a lot to respond to, but I won't touch on everything since most of these points were already answered. First off, I will defend my own points. Just letting derogatory remarks run around rampid is not the solution, because while you might save yourself the trouble, that individual still has inside destructive viewpoints and tendencies, which have not been changed, and will continue to spread. So while I could just be quiet as you say and say nothing, it does not address the root issues that are in the background. Hence why you must address these directly if possible, rather than let them keep growing, which leads to others getting hurt by the same words that are now further augmented. You can always say what you want, and how you want to, as long as you know what you are saying, and that it is a wholesome argument toward a greater healing. Which is what I am doing, I am bringing forth deeply rooted prejudices which are sometimes not even noticed, so that I can breathe myself, and bring to life the perspectives that are missing; what goes around comes back around (and not just eye to eye, but also more deeply simply brought back to balance, with the confusion and clarity simultaneously wrapping around into clarity alone). If there is no room for empathy, and compassion, because of rooted misbeliefs that are not understood in regards to how selfish viewpoints were forged in the first place, then you will be unable to heal. And the traumatic passive insults will continue to resurface against others, as is the case here where there seems to be a very, very acute misrepresentation of feminine and masculine elements that are always involved in any, and every, aspect of life (night and day, cold and warm, sweet and salty; etc). However how can people notice this when we have for example The White House in the U.S., when we call a God, God, which is a masculine name (Goddess the feminine, however not incorporated with a root feminine language construct), when we say we are humans , when we ascribe all of these basic male principles to the elementary aspects of life, we are bound to forget and even unknow how to identify pure feminine qualities, since to be honest, we ascribe pure feminine qualities to very few things in life; as well as hold these sacrosanct. So, in order to remind others how they want to be treated, if these individuals are in any degree of "silfish", one must bring forth what hurt they are causing (via mirroring), as well as what internal purely positive state they are missing within the context of the issue at hand, and in general as a reminder of the greater archetype that is a peaceful interaction, filled with integration. True healing is a very complex phenomenon, which usually requires bringing forth the entire emotional spectrum (past, present, and future states, too). Sometimes, these prejudices are so deeply dividing, and destructive (like racial prejudices can be, or sexual prejudices), that the only thing deep down that will reawaken the spirit is a self-condemnation of these actions (and alone, prior to receiving a truly healing experience), because these actions are destructive on a wholesome scale, and you cannot get a true sense of that unless it is negated fully, which is a painful experience (and one that is the reminder of this entire built thought structure, that is the avenue to a reconstruction of these thought processes). This opens the door toward seeing reality and the universe entirely differently, because it forces one to equate oneself with other things, 1 : 1, rather than hold any superiority complex over any single thing. Then, and only then, does healing really start, and do viewpoints change. It's a self smacking so to speak, aided by someone else who is calling this out, and with a greater purpose of integration in sight. Radlrb (talk) 17:11, 13 March 2023 (UTC)[reply]
If by "that individual [who] still has inside destructive viewpoints and tendencies" you were referring to me, my simple comment "...or some New Age theory" had nothing derogatory in it. As pointed out by Aaron Liu, I was just trying to figure out what is your intellectual background, and I personally have nothing against New Age or whatever is your spiritual background. Anyway, the word "human" itself has nothing to do with gender: it is a derivative of Latin humus, "soil", or otherwise from Germanic gumo, itself meaning "human" in the general sense. Æo (talk) 17:44, 13 March 2023 (UTC)[reply]
I don't believe you actually... (changed my mind, it just doesn't flow from what we were discussing, you clearly then were trying to minimize my argument by putting it in a box). If I say, for example "some Black theory", or "some Native American ideology", it comes across as demeaning; since it makes it seem arbritrary, or unspecial. I think it's also further the assumption that I am coming from a New Age background with the philosophy I brought up. It actually comes from a mixture of many things, not just New Age; though New Age tends to be most inclusive of many different perspectives, like Sikhism or many native tribe ideologies. And I know human doesn't come from an English background or anything to do with man, per se, however it has merged into that which does internalize inside us, whether we realize it or not, as something to do with man at the core. I do study languages too. Radlrb (talk) 18:58, 13 March 2023 (UTC)[reply]
Okay. I like this. This still doesn't justify anything, however. Use my analogy of fighting fire with flame retardant. Calmly explain and disable the attack from th ground up. Don't attack an attack. This just causes needless fighting and is more destructive that it needs to be. Sometimes, you need [to] hurt people so they get a perspective of the damning things they say is a poor philosophy. My philosophy is that people are people, and they sometimes say dumb stuff. I'll either come up with a calm, collected answer or a simple, terse I don't like the way you said this, I think this constitutes a personal attack, please strike. Again: personal attacks are never justified.
Also, what? Humans? That's like saying amen is sexist, and you should also say awomen. Cessaune [talk] 18:28, 13 March 2023 (UTC)[reply]
Well, it does justify it, I'll explain. I am not attacking as a root action, or alone. I am defending myself, and the other, by reminding the other of what this actions are and are not, in order to initiate a deeper empathy (and within the scope of gentleness on the onset) that returns the other into a natural state (i.e. create a self-reminder of true identity, which undoes past reflexes, to whichever depth). For that I have to show what proportional abject feelings are like, there is no other way around it if that memory is absent. There must be hurt also, mixed with feeling an overpowering love, is the key. This, only when the other person is very averse to seeking an understanding. Normally, I would come with only light, and let the light do the work, but when there is a deep aversion to seek amends because of a deep prejudice, then I have to return some fire, because the individual then forgot what that fire alone feels like. Once you can emotionally compare the hurt as isolated, and then infuse it with compassion, the heart and brain feel holistically able to compare between these emotions and make connections. Again, I do not attack as my own root action, it is infused within the greater action which is passive. It's like mixing defense with offense, within a grand context of self-defense (for both entities involved). I hope this makes sense. I am not an evil person, to the contrary, I am a healer, but there is dark shit inside us that cannot be faced except with complete surrender, surrender that we have been working against our own selves. Then comes who we truly are. And, some people you just cannot work with sometimes, as in they will come and willingly harm you, they will actually want to hurt you and enjoy it (dark, contorted lust), and in these circumstances you have to also use some fire, because what they have missing is precisely the understanding of what deeply prejudiced actions do (as in years without experiencing pain themselves, of the kind that is projected outwardly). Now this fire is not a red fire, it's a blue fire of sublimation, because it is infused with frigid temperatures that steam and quell the fire (because it is such an acute revealing and healing experience).
And yes, we need to eventually rewrite, imo, human to the same extent that amen needs to be revocalized (internally first, once this is realized, and expanded into both a new sacred prayer and mantra that is accompanied by a different purely feminine one; and then an entirely new one, which all become one and almost equal to one another, as well as equal); that is, if we want to be precisely fair to entonations in our vocalizations and vocabulary, our brains really do notice all of these thingsnuances, wehther consciously or subconsciously (Amen for the most part uses middle and higher notes depending on how it is pronounced; deeper vibrations require different vocalizations and therefore written representations - which create a different connection too. This is an entirely different discussion, but yes, to answer your question, and notice as well that the root woman is such that if I take out wo and am left with man I have enough to describe the male, and I need to add letters to represent its feminine counterpart; which is also true when thinking instead of removing letters. The are many other examples, but alas, at least we do have Mother Nature, where nature is usually feminized). Radlrb (talk) 19:02, 13 March 2023 (UTC)[reply]
1) Attacks are never justified. There is literally never a time when an attack is justified on Wikipedia. This is so simple. There is never a justification for an attack. Like, never. There is no gray area, it's just a simple no. Nothing you say will ever, ever justify an attack. Like, you don't understand what I mean by this. Never will there ever be a time when an attack of any sort is justified. There is no argument here. ...but when there is a deep aversion to seek amends because of a deep prejudice, then I have to—wait for it—avoid attacking back. It literally doesn't matter what has been said—there is no justification for an attack. Never. As in, never. Meaning, never. It's pretty simple, actually. All of the justification above is pointless. There will never be a time where the wider Wikipedia community will ever justify an attack, bar none. So I would kindly ask you to refrain from trying to justify something that will never be accepted.
Now, pertaining to the real world, I agree somewhat. There is definitely dark shit inside us. And, yes, some people you just cannot work with sometimes, as in they will come and willingly harm you, they will actually want to hurt you and enjoy it (dark, contorted lust), and in these circumstances you have to also use some fire, because what they have missing is precisely the understanding of what deeply prejudiced actions do (as in years without experiencing pain themselves, of the kind that is projected outwardly). That, however, does not apply here, on Wikipedia.
2) The amen-human argument makes no sense. I'm deifinitely not an expert but my cousin asked me why people say amen and not awomen a long time ago, so I did some research. Amen is a loanword from Hebrew. To say awomen, or any equally feminine word, makes no sense, as amen does not refer to men (male humans) in any way. Secondly, man represents all humans, and it also represents male humans, because both women and men fall under the category of man. 'A man' is a male human. (adverb/adjective-noun), while 'man' is all humans (noun only). And the man walked: male human. And man walked: humanity. The men fell: male humans. Men fell: Depending on the context, either male humans or humanity. The fact that man can refer to a male human does not mean it always does. ...the root woman is such that if I take out wo and am left with man I have enough to describe the male, and I need to add letters to represent its feminine counterpart—no, you don't. Man represents all humans. 'Man' and 'man' are two different words, same as lie and lie. The fact that 'man' and 'man' are more closely related than 'lie' and 'lie' does not change this.
However, this is all tangential to the point at hand, which is this: There is never a justification for a personal attack. Never. Cessaune [talk] 04:05, 14 March 2023 (UTC)[reply]
Wikipedia is part of the real world, don't expect me to follow that rule if people come here trying to minimize me and intimidate me or harass my background; I don't care if I'm in Wikipedia headquarters, I will make sure that person feels shit inside, and love (you cannot change otherwise, you get what you give too, else the principles are not fully communicated in all emotive states; you'll understand that later). That's for sure, because prejudices don't go around for free in today's world, maybe for you who is afraid of making real change and using the power of your own words, but not me. Secondly, I never said to say awoman, that also flew over your head (so much deeper than what you've even brought up, and most of the points I touched you just do not understand, as simple as that). Thirdly, clearly you missed the point: Man should not represent all men and women, that's psychologically damaging and if you need sources for that, go create them because they do not exist yet since people are so uninterested in these subjects that there is not much science on this, yet (another example why your minimalistic "let's not make language evolve" is just ridiculous, and shortsided, and unempathic, not to mention selfish and lackadaisical). I mean, seriously, the modern world is made by undoing all the nonesense we have accumulated over time, and all the imbalances. It's not made better by making it more imbalanced or unrepresentative of the real world, which is that the woman and the man are equivalent, and in the direction of the female (the black hole, nothingness, pure space); hence let's bring all the the things that have preferences for the male back in balance for both. Open your mind, don't just accept things, wow. Like, I actually feel deep sorrow for you, and everyone that shares that viewpoint, given how young you are and how seemlessly you play into the hand of divisive philosophies; gladly most of the world is catching up to that and even here in America, where we are becoming unafraid of moving in the right direction even if it is entirely novel and somewhat uncomforable because it is so clean and fair. I won't explain more of that. Fourthly, I am done, I'm not replying to anything else you write, or any one of you that has responded here on my comments. You can talk to a ghost if you do. You've definitely shown in different manners why this new Vector Skin is entirely worthwhile. Thank you. This is probably the last time I speak of this in Wikipedia (unless in my talk page), since it is too much of a challenge for so many, too much openness and too much clarity of vision. Too much femininity, sex, and love for everything that is, without bounds and in equality; there is such a fear to change status quos. Yes, that's all barreling down harder than any cataract and exploding louder than any volcano, and some men are going to have a real tough time adjusting (some won't even make it), even though it's within the male principle of being a gentleman to highlight the feminine, that's what real men do. Radlrb (talk) 14:20, 14 March 2023 (UTC)[reply]
Okay then. Thing is, I agree with most of your viewpoints, except the philosophy of I don't care if I'm in Wikipedia headquarters, I will make sure that person feels shit inside, and love. The nuance of your arguments doesn't carry to the text on the screen, I feel. I would love to talk to you in person; I feel like we could have some good discussions. Goodbye, for now, Cessaune [talk] 15:50, 14 March 2023 (UTC)[reply]
We can continue this conversation over e-mail. And yes, I worded that wrong, I should have said feel love and shit inside, all for the greater purpose of love and comfort (got to be real too, this crud doesn't just dissapear, pain is essential to be felt in order to cleanse yourself, that's how the other tells you "I get you, I undertand the pain I have caused you and I am sorry, ashamed, and grateful to you for pointing out my imperfection"; which we all carry). We'll be in touch. o/ Radlrb (talk) 16:38, 14 March 2023 (UTC)[reply]

Other proposals for the skin

[edit]

Allowing for IP users to change the skin back if Vector 2022 is kept as the default

[edit]

Maybe we should create an easy way for IP users (and all Wikipedians) to be able to switch back to the old look? I know if I turn my skin on to Vector 2022, on the side, there is a button that says "Switch to old look." We could maybe do something like that with cookies. It seems like at the Teahouse, there are a lot of IP users complaining about the skin. ‍ ‍ Helloheart ‍ ‍ 03:00, 20 January 2023 (UTC)[reply]

The stated objection is the increased load on the servers caused by the need for more caching. I have outlined some possible technical solutions to this here (ctrl+F "particular items that have been listed"). IWantTheOldInterfaceBack (talk) 03:04, 20 January 2023 (UTC)[reply]
They have a $100 million dollar endowment. I think that's sufficient to get servers that can do that. ~ HAL333 06:13, 20 January 2023 (UTC)[reply]
Agree that there should be a way that they can implement preferences like that. It shouldn't be impossible given that https://en.m.wikipedia.org/w/index.php?title=Special:MobileOptions&returnto=Main+Page exists in mobile. CactiStaccingCrane 08:52, 20 January 2023 (UTC)[reply]
Its possible but i doubt that will happen as i think the WMF wants more registered users and I wont be surprised if they remove the ability of IP users to edit or even to read articles in the future Qwv (talk) 10:25, 20 January 2023 (UTC)[reply]
That's particularly funny since the WMF has generally been then one pushing back against community attempts to limit edits from IPs. Nil Einne (talk) 15:45, 20 January 2023 (UTC)[reply]
The WMF likes IP editors, and so do I. Plenty of them turn into long-term registered (or unregistered) editors. The main threat to IP editing is not skins but the prospect of IP masking limiting our vandal-fighting ability so much that we are forced to block all IP editing. Certes (talk) 14:10, 19 February 2023 (UTC)[reply]
Why would they do this? IPs that edit become editord, and WMF wants editors. Secondly, if WMF tries to force people to make an account just to read Wikipedia articles, the pushback will be literally catastrophic. It would commpletely destory WMF—user relations. Cessaune [talk] 03:16, 14 March 2023 (UTC)[reply]
I have outlined some possible technical solutions to this here
here is a permalink to your comment. I agree the argument against having skin-specific cookies for those who wish to default away from V22 is extraordinarily weak. We wouldn't need to cookie everyone, just those who wish to go back to V10. And any server usage increases must be weighed against those increases attributable to new accounts who wish to default to V10, increased clicks and reloads from navigation issues, need to have expandedwidth toggles, etc. It's not a decision that's made in a vacuum.— Shibbolethink (♔ ♕) 18:57, 20 January 2023 (UTC)[reply]
Agreed. If their current technical staff can't handle this then they need to do some new hiring. They have plenty of money to do so. 2600:1700:1471:2550:4102:7C99:2804:8FC3 (talk) 21:10, 20 January 2023 (UTC)[reply]
yes that stated objection is not a true one. they are just trying to force user to use the new look.
this would be a trivial thing to implement.
one single cookie can solve this... 82.9.90.69 (talk) 01:57, 21 January 2023 (UTC)[reply]
Bull. If they force this crap on IP users, they should just as easily allow them to revert to V10 73.8.230.57 (talk) 02:02, 21 January 2023 (UTC)[reply]
I think any such creation of this should be handled upstream, not with any sort of hacks here. — xaosflux Talk 11:49, 20 January 2023 (UTC)[reply]
I find it hilarious and sad that, after spending the entire year begging me for money, you then go and make a chance like this which makes me LESS likely to come here anymore. I'll get my information elsewhere. You aren't the only wiki in town anymore, fan wikis often have far more information anyway. 2603:3023:180:4800:112D:D97D:8F55:28B3 (talk) 18:52, 20 January 2023 (UTC)[reply]
Not sure what you're talking about. Wikimedia Foundation are the ones who put up the donation banners, not the unpaid volunteers of Wikipedia; and they certainly do not need you or your money. Have fun on those fan wikis, though, which I personally find impossible to navigate due to the obnoxious ad banners. 🌈WaltCip-(talk) 15:05, 21 January 2023 (UTC)[reply]
While I'm not a fan of Vector 2022 and think the 2010 version should be standard your snyde comment about "this not being the only Wiki in town anymore" doesn't make much sense to me, Wikipedia covers hundreds of different subjects from an encyclopedic point of view while fan Wikias cover specific fandoms in detail and are aimed at a specific audience, they don't serve the same function for the majority of people.★Trekker (talk) 15:23, 21 January 2023 (UTC)[reply]
This could be done with cookies but it would be very clunky, and I wouldn't support doing it on the server end since one user's preferences would stick to the next user on that IP address. Just as is the case with just about every website on the internet these days: if you want to save preferences, create an account to save them to. Otherwise you get whatever defaults the website gives you. Ivanvector (Talk/Edits) 19:02, 20 January 2023 (UTC)[reply]
@Ivanvector I agree, and I'm also pretty sure there are better ways to spend the money on software. Doug Weller talk 09:37, 21 January 2023 (UTC)[reply]
Strongest possible support. I don’t find the technical arguments against this very convincing given that there’s already a way to switch between the mobile and desktop interfaces. I personally am not a fan of the new design and therefore would (selfishly) prefer the default to be changed back to “Vector 2010”, but I’d also be perfectly content with keeping the default as Vector 2022 as long as there was an easy way for me to switch back without having to make an account. 70.172.194.25 (talk) 19:45, 22 January 2023 (UTC)[reply]
Strongest possible support. It goes against the entire spirit of Wikipedia to require log-ins. And it should not require JavaScript either like the expand width button requires. I can't overstate how much I feel the people who worked on this redesign do not understand some very fundamental things about the web. Web content should be viewable by everyone without having to take extensive measures to see it. Simplicity. Simplicity. Simplicity. Exactly like Tim Berners-Lee designed it. Wikipedia, until recently, had been an example of how to properly do Web content for everyone. It did not require CSS edits. It didn't require JavaScript. It was minimalist, simplistic, and excellent. This redesign takes things in exactly the wrong direction. 2600:1700:1471:2550:4920:A572:D62A:79E4 (talk) 02:56, 24 January 2023 (UTC)[reply]
Support as nom. I don't really like the skin, but I don't mind the change since I can just log into my account and switch my skin. It's the IP editors who are being affected by this the most, and they are the ones who read Wikipedia the most. ‍ ‍ Helloheart ‍ ‍ 04:45, 24 January 2023 (UTC)[reply]
Sure There's already ways to do this but at present they require considerable effort to implement. No reason to limit it to just the older vector either. Well past due. 74.73.224.126 (talk) 01:35, 27 January 2023 (UTC)[reply]
Strongest EVER possible support If Vector 2022 will be kept, at least allow IP users to change the skin from Vector 2022 to Vector 2010, Monobook or Nostalgia please. -SonicIn2022 (talk, sandbox)
Helloheart, I wouldn't recommend a cookie unless the WMF implements this themselves as non-WMF cookies get randomly lost on a regular basis in my experience. They are also ignored by the caching infrastructure AFAIK so it just doesn't work. LocalStorage on it's own won't work for this use case either as it's not part of the http request.
Technically it's possible, visit https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page without logging in, click Tools, Gadgets, Skin Changer, wait for reload, click Tools again, Skin, Vector. Now you have a semi-persistent Vector legacy experience on betacommons without logging in. It's not perfect, and concerns have been voiced about this causing a cache split. Based on https://en.wikipedia.org/w/api.php?action=help&modules=parse I guess it would, the used skin affects parser output. Whether the skin needs to affect parser output is another question - I'd think this would preferably be solved with (mostly?) CSS, making all (or at least Vector and Vector-2022) skins use the same parser output. — Alexis Jazz (talk or ping me) 14:03, 19 February 2023 (UTC)[reply]
If we were designing MediaWiki from scratch, we might generate skin-agnostic HTML and implement skins via CSS. That makes our caching problems vanish and allows easy support for numerous user-written skins. However, retro-fitting it to the existing software would probably require extensive, risky and costly surgery. Certes (talk) 14:14, 19 February 2023 (UTC)[reply]
Certes, Vector-2022 was developed (relatively) recently. They should have had the foresight to synchronize its parser output with Vector-2010. They didn't, but maybe they were clever enough not to deviate too far so it could be fixed. If not, guess a new skin will have to be designed instead. — Alexis Jazz (talk or ping me) 16:43, 19 February 2023 (UTC)[reply]

Bring back the TOC

[edit]

Alongside the limited width and the hidden toolbar, another oft-criticised big problem of V2022 is the new lateral sticky ToC. Some discussions and specific comments of negative critique about it may be found at the following links: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, and 12, amongst others, including my commentary and proposal of alternatives in the foregoing RfC. Still other negative discussions and comments may be found at the Desktop Improvements talk page on MediaWiki, and amongst them I found one that, in my opinion, is particularly thoughtful and hits the mark by indicating that the new lateral sticky ToC is no longer a ToC, but a new, completely different feature, which may co-exist with the "real" (static) ToC. The comment is Bring back the TOC; let me quote it (the permission to quote it was asked to the author, and granted, here):

There are many things about the new 2022 interface that made me a bit uncomfortable on first using it, but in my experience so far the designers have made only one game changer, deal breaker change, by removing a feature I can't give up, so I will stay with the 2010 interface forever if they don't bring that feature back, at least as a user appearance preference. That's their removal of the old inline TOC at the top of the article, of course. The new pop-up sidebar TOC with its floating button is not a static TOC, it's a different feature entirely, innovative and useful in its own way (although the way its floating button always blocks the upper left corner of the page is very visually annoying, and you cannot get it out of the way no matter what you do by repositioning the page). But no matter — that's not the deal-breaker. The pop-up sidebar TOC, whether you like it or not, isn't a TOC at the beginning of the article, which has been the signature appearance of every Wikipedia article since time immemorial.

When you open a Wikipedia article you expect to see a lede (like the abstract of a research article), followed by a table of contents showing the structure and organization of the article, giving you an instant idea of whether this article is 1 or 100 pages long, and how developed it is. As you refer to the article again and again over time, you will probably depart from that TOC to places you have discovered within the article again and again, your body developing a kind of muscle memory for the way the space inside the article branches out from the top. Your mind is learning the geometry of part of the vast space that is Wikipedia. The TOC at the top of every article illustrates one local part of that space. The TOC is the article editors' best attempt to choose a geometry for that subject that makes sense. It is editor-written content, artistry, not merely a generated index or search results; in fact it is the most important content in the article, after the lede. Sometimes it's all you read of an article (the lede and the TOC), and it tells you that you don't need to know any more. It can be collapsed or expanded, as suits your personal need of it, but surely it should not be entirely hidden in an always-collapsed pop-up sidebar.

The designers should fix this flaw in the new interface by simply bringing back the static TOC exactly as it is in the 2010 interface. The pop-up sidebar displaying the TOC can remain too, just don't display its floating button until the display is scrolled down to below the static TOC. It would also be a diplomatic policy decision (a no-brainer, really) to provide a user appearance preference for a static TOC, a pop-up TOC, or both.
— Dc.samizdat, 21:35, 20 January 2023

With the new lateral sticky ToC there is a sort of disarticulation and mismatch between the sticky ToC itself with its subsections and the article, and the article's subsections, therefore producing illustrative, informative, and structural problems — impeding the general overview of the article's structure in the reader's mind, disrupting the article's very spatial geometry, cancelling the distinction between the article's lead and body —, as it emerges from the linked discussions and comments and as it is well explained in Dc.samizdat's one.--Æo (talk) 13:59, 23 January 2023 (UTC)[reply]

While I still don’t get whatever geometry the TOC brings, I agree that there should be a preference to restore the inline TOC. Aaron Liu (talk) 14:13, 23 January 2023 (UTC)[reply]
The quote makes a good point about the artistry behind the ToC, but the more practical concern is that the sudden squishing of the lede into the rest of the article is causing MOS:sandwich issues that are going to take years of collective time to fix. I'm not actually against the idea of a floating ToC existing, maybe only appearing after scrolling past the main one, but the way that it tries to keep up as you read the article in the v2022 implementation is pretty janky and distracting. small jars tc 17:07, 23 January 2023 (UTC)[reply]
Yes, as expressed here by StarTrekker, cit. "The lack of space between the lead section and rest of the content makes every article look like a stub [...] Generally having a TOC separate the lead from the rest of the article was an indication to me that a page was not a stub but a more extensive article [...]", and by A. Parrot, cit. "[...] I think there should still be more space between the lead section and the rest of the article. Perhaps the Wikipedias in other languages do it differently, but on en-wiki, the lead section is supposed to be a summary of the body, which I feel means it should be somewhat set apart from the rest of the article. And adding a little space after the lead section would at least reduce the image-crowding problems that other editors have complained about". The MOS:SANDWICHing and disruption of the layout of articles with many images, templates and tables is an immediate consequence of the cancellation of the space between articles' lead and body. I think something in the wake of V2022 propotypes Sushi and Song with both the classic "real" ToC (fully collapsed and numbered, as many comments demand) and the new sticky thing would be a good compromise. Æo (talk) 17:42, 23 January 2023 (UTC)[reply]
Or maybe something among the lines of the {{clear}} template could be placed after the lead section to space things out? Granted, excessive whitespace may still be an issue in a different way. Also, wouldn't that sandwiching problem exist in legacy Vector, too, if you use its "hide ToC" button? -BRAINULATOR9 (TALK) 18:31, 23 January 2023 (UTC)[reply]
«Or maybe something among the lines of the {{clear}} template could be placed after the lead section to space things out?» — Yet this would not solve the illustrative/informative/conceptual and navigational problems yielded by the deletion of the real in-article ToC as explained in Dc.samizdat's and in my comments above; the sticky ToC in my opinion is not a ToC at all, it is a sort of unwieldy navigation bar.
«Wouldn't that sandwiching problem exist in legacy Vector, too, if you use its "hide ToC" button?» — Hidden ToC is not the default in V2010, it is an option. Æo (talk) 18:48, 23 January 2023 (UTC)[reply]
Also have a scroll of a heading-dense article like list of railroad truck parts with the contents open. The dynamic bolding and unbolding of the links gets seriously annoying! small jars tc 21:22, 23 January 2023 (UTC)[reply]
They could combine the new floating ToC and the old static ToC by making the old static ToC scrollable and "float" on the left just like the new one. The new ToC is a cool feature, but the subsection headings aren't indented enough so heading 1 looks like it's about on the same level as heading 1.1, for example. Some1 (talk) 01:12, 24 January 2023 (UTC)[reply]
On long articles, the old ToC is an eyesore--it can be a big chunk of (effectively white) space before the body of the article even starts. DecafPotato (talk) 01:33, 24 January 2023 (UTC)[reply]
I actually think that the new one is an eyesore and a dysfunctional nightmare. The old one was fine (even to the eye) for the role it had as a table of contents, which the new one fails to fulfil. Æo (talk) 14:20, 24 January 2023 (UTC)[reply]
Support: Indeed for me the biggest issue with the new redesign is the loss of the long-standing TOC fully visible (no collapsible parts), wide and readable, placed under the lead section of each article. I am ok keeping the new "sticky" one on the side, but an addition to and not as a replacement of the classic TOC. Thank you. Al83tito (talk) 16:52, 24 January 2023 (UTC)[reply]
Ironically, the old TOC creates huge amounts of dead whitespace on a significant group of articles, most exaggerately so in long lists with many sections, no infobox and a one- or two-sentence lead. The old TOC is worse than the paper medium equivalent: in most non-fiction books, you will not just have a TOC at the start but book name/chapter headers at the top of each page. (Our equivalent is article title and section names.) I grabbed the nearest three non-fiction books I had and this is true in all of them. The new TOC and floating top bar, on the other hand, serves both of these purposes, as well as allowing immediate navigation from, say, halfway through the "Oppose" !votes in this RfC to the start of the "Support" section, and navigation to other articles with the search bar.
I've been using Vector 2022 for several months now and I don't know how I coped with the old TOC. It was one of my main issues with Vector 2010 and a frequent annoyance that was apparent to me as a disadvantage of the skin for the 8 or so years I used it. I was frequently pressing Home+PgDn to find the TOC to move section or Home to get to the search bar and not having this experience on any other website. — Bilorv (talk) 18:52, 24 January 2023 (UTC)[reply]
  • This is the biggest issue for me too. Not necessarily because of the appearance issues, although I agree that suddenly there are a whole lot of page layout issues because people designing the look of articles on the screen were working with the assumption that the ToC would be in that location and have that appearance. But also because the choices of headers, and what level to put them on, were based on the assumption that the entire TOC would be fully visible and therefore contents being in a given subsection would be easily seen by seeing the subheader on the TOC. Putting a key bot of info about the topic on a subsection wasn't seen as detrimental because it would still be apparent. Now it is not.
In fact, in many ways that's the overall issue. Wikipedia editors have not been just writing text, but designing entire pages, layout and all, based on consistent knowledge of how the site's layout overall layout works. Changing that with insufficient input ignores that, and still seems to be stuck on the idea that it's 2003. Oh, and no matter what anyone says, it was definitely insufficient input; a couple of hundred comments, heavily divided at the most generous description, is not sufficient input for something that effects the volunteer efforts of thousands of editors. Period. oknazevad (talk) 20:08, 24 January 2023 (UTC)[reply]
Most readers are on mobile, so editors should not be writing wikitext based on an assumption of a TOC and headers as on desktop. — Bilorv (talk) 20:42, 24 January 2023 (UTC)[reply]
Then why should the desktop version be adapted to the mobile version? Serious editing is impossible on the mobile version, and I think mobile editing is one of the main causes of the general qualitative deterioration of the articles. Æo (talk) 20:49, 24 January 2023 (UTC)[reply]
I don't understand the question. The new desktop version is not like the mobile version. — Bilorv (talk) 20:51, 24 January 2023 (UTC)[reply]
The new desktop version may not be like the mobile version, but it is styled *as* a mobile layout. This makes the UX very poor. TheMissingMuse (talk) 03:57, 25 January 2023 (UTC)[reply]
I don't understand these mobile arguments. Is it just responsiveness and swapping text for icons? Is that the "mobile UX" y'all are talking about? To me the UX is almost the same as v10. Aaron Liu (talk) 12:42, 25 January 2023 (UTC)[reply]
Mobile UX is all about hiding features behind small compact elements so that features are still accessible on a constrained viewport. When you are dealing with modern desktops, using design elements like that only makes the site harder to use. TheMissingMuse (talk) 16:40, 25 January 2023 (UTC)[reply]
No, it’s just decluttering Aaron Liu (talk) 02:00, 26 January 2023 (UTC)[reply]
Decluttering means removing clutter. This is not what the redesign has done. It has instead adopted mobile design aesthetics for desktop presentations. This is bad UX from the ground up. TheMissingMuse (talk) 19:00, 26 January 2023 (UTC)[reply]
No reason to hide stuff behind tons of different dropdowns when there is plenty of space to just not do that, I think, and they didn't even do it masterfully. They left a ton of white space scattered around and made the body smaller for no discernible reason. It looks like it's optimized for a smartphone. Cessaune [talk] 16:14, 28 January 2023 (UTC)[reply]
[32] He's an admin also, so I mean it's possible, and he addreses exactly what you talk about. Cessaune [talk] 16:04, 28 January 2023 (UTC)[reply]
I will also add myself to the camp particularly bothered by this. I think reverting the ToC change alone would go a long way to fixing Vector 2022 for me, at least visually. DarkSide830 (talk) 03:27, 25 January 2023 (UTC)[reply]
I just wanted to let you know that, in response to some of the points raised here, I wrote a user script to modify how the TOC is displayed under the Vector 2022 skin. The TOC is still on the left but now all sections are unfolded and they are numbered like in the Vector 2010 legacy skin. Instructions on how to install it and a screenshot showing the difference can be found at User:Phlsph7/UnfoldedNumberedTOC(Vector2022). Phlsph7 (talk) 18:58, 25 January 2023 (UTC)[reply]
  • I quote another comment that has hitten the mark about the ToC: "Structure – such as the table of contents – makes sense at the top, where there is space to show sections and subsections. Unstructured knowledge is not knowledge. [...] Non-logged editors should not be given the impression that Wikipedia is Tik-tok. The review of knowledge should be transparent and the structure and tools should be displayed [...]", by Boud.--Æo (talk) 21:48, 25 January 2023 (UTC)[reply]
    I don't get it. How is only having ToC in the sidebar unstructured knowledge? How does that create the impression that Wikipedia is Tiktok? Aaron Liu (talk) 21:56, 25 January 2023 (UTC)[reply]
    The classic ToC is structure and gives structure to articles; its absence bereaves articles, and the knowledge they should convey and present, of structure. I don't use Tiktok, and I don't know how it is structured (or unstructured), but I think Boud's comment can be interpreted as a general critique against the new V2022 interface which seems to be a step bringing Wikipedia towards the style of mass social networking websites where knowledge is, given the nature of such websites themselves, superficial, shapeless, and fleeting throwaway. Æo (talk) 22:11, 25 January 2023 (UTC)[reply]
    classic ToC is structure and gives structure to articles; its absence bereaves articles That's exactly what I'm asking, how does the absence of the classic ToC bereave articles? Aaron Liu (talk) 22:24, 25 January 2023 (UTC)[reply]
    Surely this argument can be equally well turned against the older ToC, no? I might justifiably say that the V22 interface ensures that structure is always present for the reader: with section headings floating on the side, the reader is constantly reminded of where a piece of information sits in the page hierarchy. With the older ToC, as soon as one scrolls past it, one is suddenly bereft of whatever structure it provides; the article becomes a prose sea marked only intermittently. Shells-shells (talk) 22:28, 25 January 2023 (UTC)[reply]
    The new sticky ToC is a new feature entirely, as explained in Dc.samizdat's comment, and it could co-exist with the classic ToC instead of replacing it. The classic ToC is structure because it gives geometry to space; let me quote Dc.samizdat again: "When you open a Wikipedia article you expect to see a lede (like the abstract of a research article), followed by a table of contents showing the structure and organization of the article, giving you an instant idea of whether this article is 1 or 100 pages long, and how developed it is. As you refer to the article again and again over time, you will probably depart from that TOC to places you have discovered within the article again and again, your body developing a kind of muscle memory for the way the space inside the article branches out from the top. Your mind is learning the geometry of part of the vast space that is Wikipedia. The TOC at the top of every article illustrates one local part of that space. The TOC is the article editors' best attempt to choose a geometry for that subject that makes sense. It is editor-written content, artistry, not merely a generated index or search results; in fact it is the most important content in the article, after the lede". Æo (talk) 22:40, 25 January 2023 (UTC)[reply]
    Irregardless of Geometry, which I keep failing,[Joke] both the old ToC and the new feature provide structure to the article. Just the fact that it's a new feature doesn't remove structure, it still provides the same structure of the article. Aaron Liu (talk) 23:10, 25 January 2023 (UTC)[reply]
    I want to again express my strong support for and echo the idea that the sticky ToC could and should coexist with the classic ToC, as they serve different and complementary purposes. Al83tito (talk) 05:46, 28 January 2023 (UTC)[reply]
  • I can get used to everything else but for me the loss of the classic ToC is also the biggest issue. It's a quick overview of the contents of the article. Scrolling through that narrow listing and clicking items to see second, third, and fourth-level headings may work in short articles but in longer ones you don't get an overview. Also, how are editors supposed to structure the article when you can't see the structure? The ToC also separates the lead from the body. It was difficult enough before to keep editors from treating the lead as a separate article on the topic, i.e, add content that's not mentioned in the body. Now it's just more text. Space4Time3Continuum2x (talk) 15:59, 28 January 2023 (UTC)[reply]
  • Should restore ToC (or at least mobile version under the lead) not only because of mass text sandwiching that is not seen in mobile view as sections are separated, but because of the research about the TOC ..... «A main finding was that readers tended to look first at the table of contents, then at the article's infobox».[1] «In "lookup" tasks, readers spend >45% of time on scanning TOC and lists ("QL-LI"), in "learn" tasks it's <10%».[2] Moxy- 09:11, 29 January 2023 (UTC)[reply]
Thank you for these very pertinent sources and quotes. I took the liberty of highlighting the quotes in your comment with the template {{tq}}.--Æo (talk) 18:56, 29 January 2023 (UTC)[reply]
  • The new ToC is perfect; it helps gain a better sense of an article's structure, and how each section fits within the "whole" (since it is always visible). It's also extremely practical to easily navigate between sections (including References) without needing to scroll to the top. Is there anybody that likes Vector 2022, but dislikes the new ToC? DFlhb (talk) 08:37, 30 January 2023 (UTC)[reply]
    There are A LOT. I still don't get the argument but a lot of people seem to agree. Aaron Liu (talk) 13:25, 30 January 2023 (UTC)[reply]
    @DFlhb: I am among them. The foremost problem of V22 for me is the new ToC (on par with the reduced text width and immediately followed by the hidden toolbar; while I generally like the new colour palette and logos), since my use experience and impression is exactly the opposite of yours: the new sticky ToC does not give a sense of the article's structure; the overview on the "whole" and its "sections" is completely messed up; it is impractical for navigation, given that there is a sense of disconnection between the ToC and the article itself (both have to be scrolled) and most subsections are hidden (collasped) in the major ones they belong to. Æo (talk) 15:22, 30 January 2023 (UTC)[reply]
    That's pretty amusing; the TOC was my main reason for switching from Monobook to V22. The fact that it autocollapses in certain cases makes it easier to get a broad overview of a topic. DFlhb (talk) 10:24, 1 February 2023 (UTC)[reply]
    I like new version ...as it looks better. However i dont use a mouse and expanding the TOC using tab does not work. Moxy- 05:53, 31 January 2023 (UTC)[reply]
    I can expand the TOC with keyboard navigation. Just make sure you select the arrow on the left before pressing space or enter, which is one tab after you select an expandable header. I believe that V22 is an improvement for keyboard navigation. Aaron Liu (talk) 13:27, 31 January 2023 (UTC)[reply]
    How could it be an improvement for keyboard navigation when one has to repeatedly move the cursor with either the mouse or the pad between the article and the ToC, scroll both of them, and repeatedly click on the ToC's main sections to navigate the subsections? All of this beyond the mental-spatial structural ("geometric") and aesthetic concerns. Æo (talk) 14:40, 31 January 2023 (UTC)[reply]
    The TOC scrolls automatically when you scroll the article. Why would you need to repeatedly move the cursor between the article and the TOC? Why do you need to repeatedly click on main sections to navigate the same subsections? And if you mean navigating different subsections in different main sections, most articles have only one or two or zero main sections with tons of subsections to warrant navigating. All of this beyond the geometry argument which I do not understand at all. Aaron Liu (talk) 14:54, 31 January 2023 (UTC)[reply]
    I like the old version ...as it looks better. Cashewnøtt (talk) 12:33, 3 February 2023 (UTC)[reply]
    I generally prefer the old design, but I could get used to the new one. With the exception of the Table of Contents. Inline TOC needs to return. It needs to be inline, between the lead section and the rest of the article like before. It needs to be visually separated with a different background colour like before. And it absolutely needs to not be collapsed. Frogging101 (talk) 22:28, 1 February 2023 (UTC)[reply]
I sat in on the "office hours" zoom call yesterday afternoon and raised the TOC issue. The sentiment I got from the host was that they don't really want to bring back the inline TOC because of duplication (having the sticky TOC in the sidebar and the article body) and the large section of space that the inline TOC occupies. They would prefer to address the new TOC's issues by tweaking the sticky TOC's parameters and thresholds for collapsing and other behaviour, and falling back on the ability to stow it next to the article title for cases where the sidebar is too narrow for it.
Unfortunately, I don't think this is a good approach. While you can tweak and adjust its behaviour to "do the right thing" in as many cases as possible, it has fundamental limitations because of its new location in the sidebar. It will always have to compromise between displaying everything and fitting in the sidebar. It will always have issues on pages with lots of important sections and long headings (such as the naturally chaotic talk pages of new and heavily edited articles).
Even in its "hidden" next-to-the-title state, it's less usable than the inline TOC, and it's likely that many users would miss it entirely; when I first clicked the "hide" button on the sidebar TOC it took me some time to figure out where it went and how to get it back.
I assume the desire is to ultimately use the same skin for desktop and mobile. I can see why the inline TOC might be undesirable on small screens. But if this is your dilemma, then there is a simple solution: Don't show the inline TOC on small screens. --Frogging101 (talk) 19:30, 3 February 2023 (UTC)[reply]
@Frogging101: I don't think theirs is a good approach either, and it is disheartening. I already had the impression that they were avoiding the ToC issue. I don't see how the "duplication" would be a problem if the sticky ToC were set to appear in the sidebar only when the classic inline ToC is scrolled out of screen. They already experimented with this; see the prototypes Sushi and Song (there are other prototypes with both the ToCs). And I agree that having a fully collapsed sticky ToC would not solve anything; all the problems we have been discussing would remain in place. Æo (talk) 20:15, 3 February 2023 (UTC)[reply]

There are definitely a few things about the TOC which need to be fixed. For example, no matter how many headings there are, the current section should never be collapsed. (On this page, it should automatically uncollapse the first heading as I scroll through its subsections; then it should collapse it again, and uncollapse the "Question #2" heading, as I scroll through its subsections. There are also some bugs, where the wrong section is bolded in the TOC, or where the bold doesn't move as I scroll around. The section I'm currently viewing should always be the bolded one; the TOC should never get "stuck". Another issue is that I need to fully scroll into a section (i.e., its header needs to be at the very top of my browser) in order for it to be bolded. If a mere few lines of the previous section appear on my screen, that pevious section is the one that is bolded. The cutoff point should be changed to be half a viewport height. If a section takes up more than half of my VH, it should be the bolded one. DFlhb (talk) 10:27, 1 February 2023 (UTC)[reply]

References

  1. ^ Clark, Malcolm; Ruthven, Ian; O'Brian Holt, Patrik; Song, Dawei (2012). Looking for genre: the use of structural features during search tasks with Wikipedia (PDF). IIIX '12: Proceedings of the 4th Information Interaction in Context Symposium. doi:10.1145/2362724.2362751.
  2. ^ Knäusl, Hanna (18 December 2014). Situationsabhängige Rezeption von Information bei Verwendung der Wikipedia (Thesis). University of Regensburg. p. 202 (in German, with English abstract), cf. 2012 poster.

What changes, if any, need to happen in order to make skin preferences work for anons?

[edit]

I am not 100% convinced, even after reading the FAQ, that it is impossible to have different readers have different skins, while at the same time allowing for the use of caching. I think WMF outlines that it might be difficult right now, but I don't think it is impossible. I point to Fandom Desktop and how readers have options between both light and dark mode while logged out and even changing the width of the content. Of course, Fandom will do Fandom, but I actually am wondering what changes would need to be made to make skin preferences work for anons? If this can be done, then I think it should be a high priority task. Aasim - Herrscher of Wikis ❄️ 23:27, 23 January 2023 (UTC)[reply]

Okay - so I took a look at Fandom does use LocalStorage, which then I also saw "legacy browsers" but I do not think it is worth supporting browsers that a very small percentage of users use. Aasim - Herrscher of Wikis ❄️ 23:32, 23 January 2023 (UTC)[reply]
I do not agree with this. I don't think that Wikipedia and the other WMF projects, which are encyclopedic projects, should take Fandom, which are fandom projects (not encyclopedic projects), as a model. I think that in the case of Wikipedia et al. a unified interface is more appropriate and staid. Æo (talk) 17:01, 24 January 2023 (UTC)[reply]
Pretty sure he was taking about ip skin prefs, not changing the global default skin. Aaron Liu (talk) 17:15, 24 January 2023 (UTC)[reply]
The options were discussed in the previous RfC and are also covered in the Phabricator ticket phab:T321498. As is generally the case with software development, almost anything can be done; there's just drawbacks and costs that have to be considered. The way most sites would alter the client-side appearance without requiring an account is to run Javascript in the client that makes the appropriate changes (depending on configuration stored locally in the client). This requires that the user allows Javascript to run (most users do allow this, though a few of the commenters in this discussion have complained about the need for Javascript), and either will cause the client to pause rendering and simultaneous download of everything needed to display the page and thus delay the final result, or the client will display an initial layout and then change it to the final layout (this latter option is the one usually adopted these days, as the first choice adds a significant delay to responsiveness). The shifting layout can be distracting, and can cause problems when the user tries to interact with the page as it initially appears, but due to the changing layout, ends up selecting something else on the page. It's the simplest approach, though, so sites using this method will just try to minimize the effect of a changing layout. Note this isn't a good choice for something like a dark mode theme, since the initial layout would be the opposite of what the user wants.
The other option is for the servers to render different output based on a returned cookie from the client. Note in order to support the large number of Wikipedia page requests made at every moment, there are caching servers where the pages have already been transformed from the underlying wikitext to the ready-to-send HTML files, for non-logged in users. Because logged-in users have many preferences that can alter the page appearance, it's ineffective to cache pages for them and thus they are generated each time (for simplification, I'm ignoring intermediate levels of caching, which still occur for logged-in users). Thus in order for this option to maintain adequate performance, more server resources (including everything that entails) are required to cache different versions of the pre-rendered pages. When you're serving pages at a high rate, milliseconds in the page delivery process matter a lot. The WMF has done a lot of work to avoid cache fragmentation by reducing, as much as possible, the number of variations that need to be rendered. isaacl (talk) 18:22, 24 January 2023 (UTC)[reply]
If the CSS is written with dark mode in mind, you only need a small snippet of CSS to control the dark and light modes. The rest can be the same and thus amenable to caching. The server will serve one of two version of the snippet with the default state set according to a cookie. The snippet would go in <head> or perhaps inline, so it's loaded before the content, avoiding the white flash and reflow. This approach might even work for multiple skins, if they are similar enough, and certainly for a simple width setting. It doesn't even need JS on the client, you can use a form with a checkbox somewhere and have the server serve the cookie. If JS is available, create the cookies on the client. So, you end up adding something like one branching on a boolean and 1kB to cache server-side.
Now, I have very little idea about how the CSS is done in reality, and even less idea about the backend, but to claim that this can't be done without reflow is incorrect. 89.102.98.143 (talk) 21:12, 24 January 2023 (UTC)[reply]
Yes, that's the second option I described. isaacl (talk) 21:35, 24 January 2023 (UTC)[reply]
The following CSS can be used for light/dark mode theming:
@media (prefers-color-scheme: light) {...}
and
@media (prefers-color-scheme: dark) {...}
Aasim - Herrscher of Wikis ❄️ 23:50, 24 January 2023 (UTC)[reply]
Perhaps this digression can be covered elsewhere, to save on more edits to this page? isaacl (talk) 17:29, 25 January 2023 (UTC)[reply]
I point to Fandom Desktop and how readers have options between both light and dark mode while logged out and even changing the width of the content.
The difference, I think, is that one website serves millions of users every day, and the other doesn't. Snowmanonahoe (talk) 13:31, 27 February 2023 (UTC)[reply]

Another option for changing the width

[edit]

I want to know if instead of having an expand/collapse toggle, maybe we have the width of the Wikipedia page be editable by dragging on the borders? Or for ultra-wide screens we can use multiple columns to display article content? That would allow for the fixed width to be adjusted and modified to each user's liking. Aasim - Herrscher of Wikis ❄️ 00:10, 30 January 2023 (UTC)[reply]

A multicolumn design, or options for it, would be beautiful and revolutionary. I hope we move in that direction. This would require more design innovation for dealing with long sections: not something that could just be added to current designs. V22 could improve support for div col, however, rather than breaking it. – SJ + 17:00, 30 January 2023 (UTC)[reply]
Support for prose in multiple columns would be very neat. These comments inspired me to make a mockup here of how I think it could be done properly, circumventing the fundamental problem of having to scroll to the top of the next column when one reaches the bottom of the first one. (I don't pretend that this idea is original, but I couldn't immediately find any implementations of it online). Shells-shells (talk) 06:22, 1 February 2023 (UTC)[reply]
I'm just imagining the potential of multiple columns—that sounds legendary. Like, you could have one column be the side bar, one be a floating TOC, two be the main body, etc. The sidebar could be on the right, the article text could be on the left, there could be a column next to the article text that displays the source code and a column next to that that displays a preview, so you can see the differences between the unedited page and your page without having to flip through tabs—whatever insanity you prefer. Configure it however you want, and save it in preferences. Have a toggle at the top that switches between your favorite page layouts, and you could name them however you want. You could even share them with other editors. Maybe I'm getting a little carried away, but imagine the possibilites! If that was added I would immediately support V22. Cessaune [talk] 17:24, 31 January 2023 (UTC)[reply]
I would say if there is a multi-column option the scrolling should immediately switch from vertical to horizontal scrolling. Some of the buttons would also be worth rearranging, such as moving the view/edit/talk/history and user account buttons to the left side of the screen, rather than the top, having the search bar take up the full length of the top, to name a few. I imagine it being more like a book and less like a webpage when scrolling horizontally. Sure using the scrollbar would scroll the text, but you would also be able to do stuff like "turn the page" by dragging your cursor from the edges. Aasim - Herrscher of Wikis ❄️ 18:40, 31 January 2023 (UTC)[reply]
I think it would be a nightmare worse than V2022. Æo (talk) 20:40, 31 January 2023 (UTC)[reply]
I agree. Changing scrolling to horizontal would be completely bonkers and doesn't serve much purpose, this is a webpage and we should take advantage of the web. There isn't an advantage here to turn pages into books by default. Sure there'd be kindle-like usecases but this shouldn't be the default. Moving the core actions to the left would completely drive against the decluttering effort and won't make much sense either since page actions are on the right. I agree that an internal window manager would be great but notlikethis. Aaron Liu (talk) 22:16, 31 January 2023 (UTC)[reply]
Yeah, horizontal scrolling is a step too far. Would support it being added as an option in Preferences, though. Cessaune [talk] 00:52, 1 February 2023 (UTC)[reply]
Is it? Most people read their content in landscape mode, and in landscape, having two columns would absolutely make sense. The Windows 8/8.1 Wikipedia app had Wikipedia articles scroll horizontally, rather than vertically. You can also fit more information onto the screen when the page is arranged like a book. The problem with information density and skimming can also be mostly solved, as now a reader would be reading from top to bottom. Certain languages, namely those in the CJK family, also are traditionally written from top to bottom, and being able to orient text as such would actually increase information density even further while making it friendly for skimming.
If this sounds too confusing, then this is kind of what may be helpful for effective use of screen real estate for readers:
  1. If the window width is double that of the window height, and the text reached double the text fixed width, then the text should be arranged like a book and the width of the text should be limited to the text fixed width (calling this horizontal scrolling mode).
  2. Otherwise, the default should be vertical scrolling. This applies to tablets, phones, and desktops in portrait mode, as well as most smartphones in landscape mode. There can be an option for switching to horizontal scrolling even if the number of columns is 1.
  3. Provided there is enough room, in horizontal scrolling, the reader should be able to specify a maximum number of columns per page.
  4. For Chinese/Japanese/Korean articles, in horizontal scrolling mode, the text would be written top-to-bottom, right-to-left. In vertical scrolling mode, the text would be written left-to-right, top-to-bottom. For these kinds of articles, there would be an option to change between Latin-style left-to-right and traditional Chinese-style top-to-bottom.
This might be something worth trialling with different default settings for different readers to see what they think. Horizontal scrolling might be a little difficult especially on articles with large tables; something like moving the tables to their own pages or to an appendix at the end of the article would be needed. Aasim - Herrscher of Wikis ❄️ 16:02, 2 February 2023 (UTC)[reply]

Why so complicated? (TOC right)

[edit]

If you're going to put something on the right side - put the Table of Contents there.

Leave all the tools as-is on the left.

And Voila - you break a lot fewer things.

Less "change for the sake of change", would be a good thing, I think. - jc37 13:03, 3 February 2023 (UTC)[reply]

...break a lot fewer things? How? What effect would flipping the TOC and the toolbar have? Cessaune [talk] 15:41, 3 February 2023 (UTC)[reply]
The long-standing left side is customizable, per wiki. Not to mention other page formatting issues. The current change wreaks havok across all wikis.
Just move the TOC to the right and leave the left alone.
And you could even have a toggle to hide/show the ToC on the right.
tools on the left, toc on the right, would also reduce confusion, instead of splitting them in a mishmosh. - jc37 20:41, 3 February 2023 (UTC)[reply]
Tools all on the same side makes the most sense to me. I guess I see the logic of moving the TOC to the right. I'm just so used to a TOC on the left, that I think it would feel weird. Count me as another person resistant to change, WMF. Cessaune [talk] 00:17, 4 February 2023 (UTC)[reply]
@Jc37 you can try out ToC on the right side here: Fixed top and sidebars, by eccenux, Stylus.
Things changed in above style:
  • Top bar always accessible (fixed header). So if you have any modifications like extra links – they will always be available to you (no matter how far down you scroll).
  • Sidebar on the left and also fixed (always accessible).
  • Table of contents on the right. Which was just a wasted space before (and now a bit less).
  • Gray background which I find to work better for my eyes.
See also my lang on top script. You can find few more screenshots there.
Having said that, there are some problems with ToC being on the right side. If the ToC is long. Some content is too wide and overflows articles. This might look bad with something on the right side. When things overflow they should be fixed in the article (as it will probably look bad on mobile anyway), but long ToC would overlap with this kind of content. So that might be viewed as a problem with the ToC on the right side. Nux (talk) 17:59, 3 February 2023 (UTC)[reply]
@Nux: Trying this Stylus skin out and I have to say it seems pretty good, especially with tools like and file:OOjs UI icon edit-ltr.svg being displayed in the bottom-right corner. Do you know which class to edit if I want to change the width of the right sidebar? Contents seem pretty squished for me as is. —Tenryuu 🐲 ( 💬 • 📝 ) 05:00, 4 February 2023 (UTC)[reply]
@Tenryuu At the moment the setting is: .vector-sticky-header-enabled #vector-sticky-header {max-width: max-content;}. But if you want to change gaps between buttons/links then you can just change this: .vector-sticky-header-icons {column-gap: 20px} Nux (talk) 12:11, 4 February 2023 (UTC)[reply]

Per longstanding usage - none of this should require scripting. - jc37 20:41, 3 February 2023 (UTC)[reply]

I'm repeating myself, but I do like the idea of having the TOC on the right hand side as here. This way you'd always see it, its position would not depend on other menus/sidebars. Wikipedia tools and page tools could be two collapsible boxes on the left hand side. Note that this is also where the ToC is in the mobile app (Android). Thoughts? \ Aprovar (talk) 01:29, 4 February 2023 (UTC)[reply]
I don't know. First we would have to gage community input on the static TOC. Do people want a static TOC/floating TOC hybrid or a static TOC/floating TOC toggle? If it's the first one, the TOC will likely be on the left, where it is in V2010, and will have to sink into the left sidebar. Cessaune [talk] 03:21, 4 February 2023 (UTC)[reply]
I think that the classic in-line ToC under the lede + the new sticky ToC appearing on the left band when the classic ToC is scrolled out of screen + the static and unhidden user's toolbar in the left band as it was in V2010 would be a good compromise. The sticky ToC on the right band would obviously interfere with the article's text's width. Æo (talk) 22:00, 4 February 2023 (UTC)[reply]

Dark mode

[edit]

Is there a potential official dark mode in development, one which would employ grays and whites masterfully and unlike the simply inverted colors of V2010 dark mode? I regularly used V2010 dark mode at night, and a dark mode toggle would be a step in the right direction. I know this would be low on the list of priorities, but I feel it is a necessary addition. Cessaune [talk] 18:30, 3 February 2023 (UTC)[reply]

How about Wikipedia:Dark mode gadget Aaron Liu (talk) 18:38, 3 February 2023 (UTC)[reply]
This thing? I mean, it functions as a way to reduce strain on eyes at night, but it is more of a color switcher than an actual dark mode (which was one of my qualms with it). Typical dark modes of today employ grays, whites, blacks, navies (alongside purples and blues for links). This was a V2010 solution that worked in 2010, but since we're here, why don't we make it thinking ahead to the next decade (maybe a dark mode 2.0 gadget that adds more gray variation and not the stark black that I find very grating)? I don't know. Cessaune [talk] 00:24, 4 February 2023 (UTC)[reply]
Yeah, it does need a lot of work. For me the biggest thing is how weightless the font is.
Also, is it just me or do image thumbnails slowly decrease their width when I type in DiscussionTools? Aaron Liu (talk) 15:19, 4 February 2023 (UTC)[reply]
I was on their Office Hours Zoom call yesterday, and dark mode was discussed as something that would help many who didn't like V22. The web team didn't commit to anything because they didn't immediately know how feasible it would be to implement it quickly or how much work it would take, but they did say it was something they were going to look into. I assume they'll let us know once they know what the possibilities are. The WordsmithTalk to me 22:20, 3 February 2023 (UTC)[reply]
It is nice that the dark mode gadget also works on Vector2022, even if that is an interim dark mode solution. CMD (talk) 03:47, 4 February 2023 (UTC)[reply]

Sticky header in Vector Legacy

[edit]
Screenshot of the style in action

Vector 2022's sticky header got me wondering how easy it would be to add the same feature to Vector Legacy. Turns out the answer is "very easy". Simply copy-paste the following onto your vector.css: 

@media screen {
    #mw-head {
        position: fixed;
        background: linear-gradient(to bottom,#fff 50%,#f6f6f6 100%);
    }
}

Plus, it loads faster* and there's no hieroglyphics!

* This is probably just a me problem because I have a lot of user scripts installed and the sticky header on Vector 2022 doesn't show up until they all load.

—pythoncoder (talk | contribs) 06:00, 4 February 2023 (UTC)[reply]

Just a heads up @Pythoncoder that the screenshot you uploaded is completely broken for some reason. ♠JCW555 (talk)♠ 07:47, 4 February 2023 (UTC)[reply]
It probably got fixed but it isn't broken for me now. Aaron Liu (talk) 15:21, 4 February 2023 (UTC)[reply]
Thank you. This is the way WMF should make new skins :) Freja Draco (talk) 10:03, 4 February 2023 (UTC)[reply]
Thanks for this, now a way is needed to make 2022 one permanent and modify its available buttons. CMD (talk) 03:15, 5 February 2023 (UTC)[reply]
What do you mean make 2022 one permanent?Aaron Liu (talk) 04:29, 5 February 2023 (UTC)[reply]
I've been using a sticky header for what is now Vector Legacy for quite some time. I can say that is quite nice, IMO. The only issue is when someone would update the Vector skin and something would get slightly out of wack, and I would have to tweak the CSS a bit, but I think they have now frozen the code for Vector Legacy (no more changes to it), so I don't think that will be much of a problem anymore.— al-Shimoni (talk) 03:25, 5 February 2023 (UTC)[reply]
After using it for a couple days, it works as a quick-and-dirty solution, but there are a few things making it not ready for primetime:
  • When you're click on a link in the contents, it jumps you a little too far down because it expects the very top of the page to be visible. Vector 2022 does this right.
  • On my phone (viewing the desktop site of course) it makes the search suggestions jump over to the left so you can't see them unless you scroll/zoom, but then you can't see what you're typing.
  • It's missing the blue border at the top of the main content block when you're at the top of the page. This is a 1-pixel difference but it's still annoying.
—pythoncoder (talk | contribs) 04:59, 5 February 2023 (UTC)[reply]

Borders and backgrounds: bring back the distinction between the article's space and the user's space

[edit]

The more I use V2022, the more I think that V2010 is better, more functional, fine, sleek, serious, professional, suitable for an encyclopedia and especially for a user-edited encyclopedia like Wikipedia. Beyond the problems that have already been raised and widely examined, namely the fixed width, the sticky ToC, the hidden toolbar, the languages' bar, and others, I also want to highlight the indistinction in V2022 between the space of the article and the space of the user. In V2010, the boundaries between such spaces were clearly marked by those azure lines; in V2022, boundaries have vanished and there is only one big white space where the article's texts (including the ToC) and the user's menus blend together.

Here you can experiment with nine prototypes of V2022 with different styles of borders and backgrounds (including the #1 which was chosen for the deployment, called "minimalist"). As the prototypes' page itself says: "Borders and backgrounds can divide up the regions of the interface, and frame the content". Personally, I would have chosen either #4 or #9 — obviously with the classic ToC, itself once again with its borders and numbering, restored in its "natural" place in the article's space under the lead, and with the unhidden toolbar in the left band of the user's space as it was in V2010.--Æo (talk) 21:50, 4 February 2023 (UTC)[reply]

Oh my goodness. Oh my god. I'm shaking. Lines make it so much better (I think it's because it takes my eyes off of the white space). It was this simple. If there were all these options, why did WMF decide to go with #1? #2 is good and still pretty minimalist (let's be honest, they're all minimalist), #4 looks professional, #6 and on introduce color separation which makes them look crisp. We should literally hold an straw poll right now and choose the top three for an RfC. Cessaune [talk] 02:18, 6 February 2023 (UTC)[reply]
There was a poll that chose #9 (with #1 in second place) yet they went ahead with #1 for some reason. Aaron Liu (talk) 11:58, 6 February 2023 (UTC)[reply]
@Cessaune: If there is consensus, we could open it as "Question #3: In Vector 2022, what styles of borders and backgrounds do you prefer?". Æo (talk) 15:29, 6 February 2023 (UTC)[reply]
There has already been a survey and #9 won. Aaron Liu (talk) 15:45, 6 February 2023 (UTC)[reply]
Yes, but what do you think about opening a new survey, as part of this RfC? Also, where are the results of the previous survey? Æo (talk) 15:52, 6 February 2023 (UTC)[reply]
mw:Reading/Web/Desktop Improvements/Features/Visual Refinements § Borders and Backgrounds Aaron Liu (talk) 15:57, 6 February 2023 (UTC)[reply]
@Æo, @Cessaune, @Aaron Liu - thanks for the thoughts on this. The team has started exploring different ways to separate the content from the navigation based on some of the thoughts and requests we've been hearing. One of the concerns with #9 and some of the other line-based prototypes was that they made the ToC feel too separated from the content of the article. We're trying to work around this to find a balance that prevents this separation. If you're curious - https://di-content-separation.web.app/Moss - shows an early prototype of one of the directions we've been discussing recently. We're still working on some details and changes to the prototype, but we're hoping to refine it a bit and share wider later this week to see what folks think. OVasileva (WMF) (talk) 19:59, 6 February 2023 (UTC)[reply]
Thank you for your ongoing efforts. However, I would have chosen either #4 or #9 provided that the classic ToC was restored; this is not negotiable in my (and other users') view (#Bring back the TOC). Indeed, the best way to prevent any separation between the ToC and the article would be to simply put the ToC back into the article, below the lede and with numbered sections. Then the left band would be free space for the user's toolbars. Æo (talk) 20:38, 6 February 2023 (UTC)[reply]
Hi @Æo - thanks for the feedback on the ToC. We'll also be posting later this week about smaller changes to the current ToC to make it easier to use for all users. If you're curious about the reasons the new ToC is persistent, or its location, check out our report on the project page. Here, we tested many different versions for the new ToC, with both persistent and non-persistent options, as well as collapsed and non-collapsed options (the full results of the user testing are available in this report). The ToC we decided on, the persistent and uncollapsed version, was the one which fit the needs revealed in the user testing, and was the most well-received by both readers and editors. The main issue with the previous ToC, which we heard from both readers and editors, was that it required scrolling to the top of the page every single time in order for it to be used. This took a lot of time in scrolling, but also made people navigate throughout the article less frequently. In our A/B test, we saw the new ToC increased ToC usage overall (and thus the number of sections of an article people navigate to) , with 53% more clicks on new ToC for logged-in users and 45.5% more clicks on new ToC for anonymous users. OVasileva (WMF) (talk) 21:26, 6 February 2023 (UTC)[reply]
Hmmm...
So you put borders around the TOC and the tools. Nice. You didn't decrease the empty space though (now it's white and gray space, I guess). You just hid it. I mean, it works, but I still want my article text to be wider. I like the persistence of the toolbar. Cessaune [talk] 22:31, 6 February 2023 (UTC)[reply]
@OVasileva (WMF), on my screen, the bottom of the toolbar goes below my screen, and there is no way to reach it, barring scrolling down to the bottom of the screen? I'm sure this is undesired. Cessaune [talk] 01:18, 7 February 2023 (UTC)[reply]
Thanks for the feedback @Cessaune. Just to note - since this is a prototype, it might be missing some functionality of the site in production (for example, the toggle to expand the width of the content is not available in the prototype, but it is available in production) and have other issues. For the toolbar issue - is this something you were seeing just in the prototype, or also on-wiki as well? OVasileva (WMF) (talk) 18:59, 7 February 2023 (UTC)[reply]
Just in the prototype. It happens because of the new persistence of the toolbar. Cessaune [talk] 21:00, 7 February 2023 (UTC)[reply]
At mw:Reading/Web/Desktop Improvements/Features/Table of contents#Background and Goals we read: "Users use the ToC to create a mental model of the page. This is similar to the role of the introduction to the page. Users learn what the page contains, how long may be, what parts may be the longest, etc. This becomes lost without the ability to reference the ToC more frequently" — I would add that these functionalities of the classic ToC become lost with the new sticky ToC, as it has been discussed at #Bring back the TOC and pointed out in many support and oppose comments.
You write: "The main issue with the previous ToC, which we heard from both readers and editors, was that it required scrolling to the top of the page every single time in order for it to be used" — Personally, I was never bothered by having to scroll back to the top, also considering that this gave me a complete overview of the article. However, what about having both the classic in-article ToC which covered those functions and the sticky ToC appearing when the classic ToC is scrolled off screen?
Then: "This took a lot of time in scrolling, but also made people navigate throughout the article less frequently. [...] the new ToC increased ToC usage overall (and thus the number of sections of an article people navigate to), with 53% more clicks on new ToC for logged-in users and 45.5% more clicks on new ToC for anonymous users" — The new sticky ToC obviously induces users to click more on it, both because it is always present and because users actually need to click on its sections if they want to see the subsections and sub-subsections; on the other hand, on very long articles with long ToCs the user now needs to scroll both the article and the ToC, in addition to having to click.
Anyway, in discourses and calculations about increasing and speeding up navigation, increasing ToC usage and clicks, I see a prevalence of quantitative thinking over qualitative thinking, while I think that the latter should be more important for an encyclopedia. Æo (talk) 23:00, 6 February 2023 (UTC)[reply]
@OVasileva (WMF): Do you have more details on the methodology of the surveys done? The sample size in this report you linked to is quite small (18; "English (Ghana), Bahasa Indonesia (Indonesia), and Spanish (Argentina). Each testing location had 6 participants that consisted of approximately ½ newcomers or casual readers, and ½ regular editors on their respective language wikis"). I also couldn't find the sample of the A/B test you linked to. Thanks! Sariel Xilo (talk) 23:10, 6 February 2023 (UTC)[reply]
Hi @Sariel Xilo - Thank you for your question!
  • We usually start our process with interviews with both readers and editors. These are mostly to see what issues people currently have with using the site (in this case with the ToC), and to try out initial ideas. These interviews have small sample sizes since they're quite lengthy and require researchers to sit down with the participants for longe periods of time. We spread these interviews over different location and user types to make sure we don't make conclusions based on the needs of a single language and location. In this case, we worked with three different research contractors in Ghana, Argentina, and Indonesia.
  • The second step is to use what we've learned to put together a prototype that we can test with communities. The link to the feedback form was shared via Central Notice across a number of different languages. For the ToC, we have the results of this prototype summarized on this page, and the actual feedback from communities here. For this prototype, we received 236 replies from editors across 30 languages.
  • Once we receive the feedback from the prototype, we change the feature based on what we've heard and any new needs that were flagged in testing and build the new feature itself. Once the feature is built, we deploy it to our pilot wikis and begin A/B testing with logged-in users (and, where possible, with logged-out users as well). The number of sessions we test across generally depend on the size of the wikis we are testing on and the number of sessions in which the ToC is used. Here, since we were testing on large Wikipedias such as French, Portuguese, Farsi, and Korean, the data set was quite large (for example, we tested across 3,245,573 sessions for French Wikipedia and 527,008 sessions for Korean Wikipedia).
  • After this A/B test, we release the feature for our early adopter wikis who are using the skin as default and for all logged-in users on other wikis who have opted into the change (for example, on English Wikipedia, the Vector 2022 skin was the most popular non-default skin so it already had an active user base from which we could receive feedback). Once released, we made some changes based on the feedback we received from the communities such as allowing the new ToC to be available in its collapsed state and making other stylistic changes.
Generally, this is the process we go through for each of the features in the Vector 2022 skin. Sorry for the lengthy reply - hope this is helpful! OVasileva (WMF) (talk) 15:48, 7 February 2023 (UTC)[reply]
@OVasileva (WMF): Thank you for breaking down the details. Qualitative research is a super important part of UX design (market research is my field) but I'm concerned with you presenting focus group data (we tested many different versions for the new ToC, with both persistent and non-persistent options, as well as collapsed and non-collapsed options --> These interviews have small sample sizes since they're quite lengthy and require researchers to sit down with the participants for longer periods of time) as the same as quantitative research with much larger sample sizes. The way in which WWF has been presenting survey data has been flagged by other editors (as seen here) and I would ask going forward that you make it clear when you're referring to decisions made on qualitative research vs quantitative. Sariel Xilo (talk) 17:57, 7 February 2023 (UTC)[reply]
Thanks @Sariel Xilo! Here's a quick overview about the process, but I would love to go into more detail if you're interested. As I mentioned above, we use qualitative and quantitative data throughout the process. Qualitative data is generally used early on to identify problems and issues and to be able to determine the hypotheses (in this case, that changes in the ToC will improve ToC usage and ease of navigation throughout the page for both logged-out and logged-in users. That this behavior will roughly be similar across user cohorts (logged-out users, new editors, experienced editors)), which we then validate with quantitative data (the A/B test mentioned above). We also use qualitative data (via community feedback) towards the end of the process to make sure we're considering edge cases for specific users and user cohorts that are not apparent within the A/B testing scenario (for example, the effects of micro-interactions and styling of the ToC). OVasileva (WMF) (talk) 18:07, 7 February 2023 (UTC)[reply]
@OVasileva (WMF): My concern is less about process (although always fun to see the nitty-gritty) but the way in which results are being presented – I'm mostly going back to this paragraph where you go from discussing qualitative work to quantitative work without distinguishing it. In your first follow up, you treated the prototype feedback as if it was a large sample size ("236 replies") which is an odd presentation choice when you consider it was broken up across 30 languages so the sample size is actually quite small per language group which does impact the validity; I'm not dismissing the usefulness of this type of prototype UX research but the level of validity should be made clear to all to all editors, not just those who have a background in this type of survey work. Editors have raised concerns that WWF is presenting data in way to fit a specific narrative so my request is mostly about being very clear when you quote research on V22 (what type it is exactly & the methodology). Thanks! Sariel Xilo (talk) 18:48, 7 February 2023 (UTC)[reply]
@OVasileva (WMF): when you show the prototypes, are they shown in a randomised order? If not, the second-choice minimalist design for borders likely got too many "votes", given response order bias [33]. That would explain part of the discrepancy between people not liking the white space and borders and backgrounds survey.
The sample size of 236 seems sufficient. A 5% random error or so is so may be acceptable for this kind of research supplemented by qualitative research. Femke (alt) (talk) 08:08, 8 February 2023 (UTC)[reply]
@Femke and Femke (alt): My point was 236 divided across 30 languages/regions has an average of just over 7 per language (I'm sure the study has the exact breakdown) which is no longer a representative sample. I'm not saying this isn't useful or uncommon in early UX research and I'm not raising concerns about research process but I am saying that when referring to that data, limitations should be clear.
  • Instead of saying we tested many different versions for the new ToC without mentioning the sample size, you could say in early prototyping, we tested many different versions for the new ToC with a small sample in three languages.
  • Instead of saying For this prototype, we received 236 replies from editors across 30 languages, you could say For this prototype, we prioritized testing across a large number of communities (30 languages in total) with a total of 236 replies (7.86 respondents per language).
There are ways to present data with caveats and still be successful in using it to support your argument. When data starts to be presented without context (such as methodology) and treated as the definitive answer (even though there research limitations), I become concerned about bias and cherry-picking to support a single narrative. Sariel Xilo (talk) 16:05, 8 February 2023 (UTC)[reply]
I actually like that prototype a lot. I think it solves all my problems that I had with Vector 2022. The login button is already fixed, and that link fixes my problem with the contents-section whitespace. As a prototype, it's of course less polished than the production version, but conceptually I could get used to Wikipedia looking like that. I might even switch to a version of Vector 2022 that looks like that after a few JavaScript tweaks. —pythoncoder (talk | contribs) 21:50, 6 February 2023 (UTC)[reply]
For me in the Moss prototype the TOC becomes less wide. The V22 TOC is already causing problems for being too small, and this seems to force more TOC scrolling / scroll bar obscuring the TOC.
I wonder if the survey on the borders was done with a random shuffle of options: people tend to choose the first and last options more in such surveys? If not, support for the first option is likely overstated. I've been hearing people prefer #8 instead. #9, while less sleek, also addressed the eye strain accessibility concern however. Femke (alt) (talk) 09:33, 7 February 2023 (UTC)[reply]
In today's (february 8) update of https://di-content-separation.web.app/Moss (please check it), I agree with others in the task https://phabricator.wikimedia.org/T259240 that #9 Zebra-alike with 0px offsets are the better choice by now. But still is not convincing enough to me.
  • I still find the default width of the article's area very narrow, the sticked TOC narrower yet, the article and the sticked TOC very separated (with background grey it is not necessary, less when the TOC vertical scroll bar appears), and almost 1 inch of wasted space at leftmost and rightmost parts of the screen, with the "hamburger" button not in the upper left corner (maybe the prototype do not has the width toggle, I guess). Perhaps do you think that 96 dpi is some sort of standard, but it is not. My laptop screen is actually 17", 1920×1080 at 144 dpi, and these are the system's defaults (Windows 10 with recommended 150% text size, which yields 144 dpi), not any personal choice. This means I see the font size larger than (I guess) you, thus text lines are narrower than you expect, and the info box plus images made the overall worse.
  • Have you ever scroll to the very bottom of that page? The final large info box are fully corrupted, but maybe the prototype is not refined yet. Left (TOC) and right (Tools) panels also bad.
  • When in #9, clicking on «Tools[hide]» also corrupts things, leaving an empty gray space at right (maybe also due to unfinished prototype).
  • Also, still "mistery meat" buttons without tooltips (maybe a prototype's flaw).
  • When I use the mousewheel to scroll down, at the first single move, there is no visible header but still the sticked header is not shown, there is some kind of "nobody's land". When the sticked header appears, it shows up with a distracting and annoying animation. The sticked header lacks the "hamburger" button and the Wikipedia logo (that may be minimized as a single "W", as others said). When I start to scrolling down, left (TOC) and right (Tools) panels slighty change their top "sticked" positions. Why they "dance"? :) I presume unpolished prototype again.
  • I can't say how the prototype would work with a TOC-less article. English Wikipedia has over 6 million articles, but most of them are short. Have you ever try "Random article" with the new skin? About 8 of 10 times you'll get a TOC-less article. But TOC-less articles should have the same layout than articles with TOC.
  • Still no numbering scheme for the new TOC. Please return the numbers, as former TOC has.
  • But the most curious thing to me: now you propose TWO different shades of gray for the header (I think it is unuseful, and it only adds a bit more wasted empty space, of a single text line or so, when original #9 Zebra was clear enough), when you've been advocating a minimalist, all-white background until now, in your own words, "to be consistent" (?).
Hope this help. Regards. 37.134.90.176 (talk) 16:03, 8 February 2023 (UTC)[reply]
I would like it. If WMF is going to hold a survey, then decline to uphold the results of their own survey, we've got to hold another one. Cessaune [talk] 21:50, 6 February 2023 (UTC)[reply]
Let's see if others join this support. We could also add Moss as the prototype #10 (I personally don't like it that much, considering that the foremost problem for me is the ToC). @InfiniteNexus: Would you consider a "Question# 3" on this matter worthwhile? How many supporting users do we need to consider its opening as consensual? Æo (talk) 00:11, 7 February 2023 (UTC)[reply]
To be frank, I think any additional questions other than #1 and #2 would be premature. We should at least wait until the main RfC has ended before we discuss how to further improve V22 (if the RfC accepts rolling back, we can discuss everything that needs to be changed before the community would consider re-adopting V22; if the RfC rejects rolling back, we can discuss everything that needs to be changed so the majority of anti-V22ers are happy). We shouldn't overcomplicate the RfC. A better alternative would be to start building a list of the most pressing concerns the WMF needs to address, regardless of the outcome of this RfC, and then using that as the basis for a post-RfC discussion. InfiniteNexus (talk) 01:00, 7 February 2023 (UTC)[reply]
I agree that it is more correct to wait for the conclusion of the main RfC. Æo (talk) 01:10, 7 February 2023 (UTC)[reply]
At what point does the RfC conclude? Do we have to wait for everything to die down completely? We already have over 500 responses. I don't think consensus is going to change any time soon. Cessaune [talk] 01:27, 7 February 2023 (UTC)[reply]
Look, InfiniteNexus has opened a discussion to propose an expedited closure, here: Wikipedia talk:Requests for comment/Rollback of Vector 2022/Archive1#Expedited close?.--Æo (talk) 18:28, 7 February 2023 (UTC)[reply]

Web team/WMF updates

[edit]

Vector 2022 Post-Deployment Update from WMF Team

[edit]

Hi everyone - we have posted an update to the technical Village Pump with some information about the deployment, responses to feedback we've received so far, and some upcoming changes we will be making to the skin. We encourage you to check it out and leave any comments or questions. Thank you! OVasileva (WMF) (talk) 01:36, 20 January 2023 (UTC)[reply]

You really should be rolling back this unwanted change instead.Tvx1 01:53, 20 January 2023 (UTC)[reply]
If it's unwanted by you, change to the old skin. There are people who do want it. Personally I am undecided, but at least willing to try it. 331dot (talk) 01:54, 20 January 2023 (UTC)[reply]
As Daß Wölf put it in the previous RfC: "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." --Kizor 02:06, 20 January 2023 (UTC)[reply]
That cuts both ways, though. We have several officially supported skins, and you can only set a different default if you are a logged-in user; whichever one we choose as default forces some IP users to either put up with their less preferred skin, or create an account. People were just as upset by change when old Vector became the default, but today people are just used to that being the default interface. Caeciliusinhorto-public (talk) 09:30, 20 January 2023 (UTC)[reply]
It only cuts both ways if we don't allow cookies to default a skin per user-agent. — Shibbolethink (♔ ♕) 18:02, 20 January 2023 (UTC)[reply]
I mean, this works both ways. If it was wanted by you, you could have just switched to the new one. No need to impose it on everyone, including those without accounts. RoadTrain (talk) 04:00, 20 January 2023 (UTC)[reply]
Exactly. There is no reason to make a highly contentious change like this a forced default. This should have been an option for those who like the new skin, not a forced global one. 2600:1700:1471:2550:4102:7C99:2804:8FC3 (talk) 15:22, 20 January 2023 (UTC)[reply]
(edit conflict) Here's the thing. There are those who like Vector 2022, and there are those who hate it. For what reason should WMF favor those who like Vector 2022 over those who hate it, besides the fact that the new UI was designed by the Foundation? In XFDs, if editors are divided on what to do, the discussion is closed as "no consensus" and no action is taken. The page doesn't automatically get deleted or moved. Why should this situation be any different? InfiniteNexus (talk) 04:01, 20 January 2023 (UTC)[reply]
@InfiniteNexus, I'm fairly sure there will never be consensus concerning this, at least not now. — Qwerfjkltalk 21:57, 20 January 2023 (UTC)[reply]
There can be if the Web team addresses most of the community's concerns. InfiniteNexus (talk) 05:35, 21 January 2023 (UTC)[reply]
@331dot "people who do want it" can do it. Why do they impose it on others who don't, that is the point. 2dk (talk) 13:48, 22 January 2023 (UTC)[reply]
Since you summoned me here I will only say that the Foundation can decide what software they wish this website to run on and who has access to what. The community decides on the content that software displays. That's how it works. The Foundation can request input if it chooses(and they have, extensively, for years) but the software they use and its configuration is up to them. The guests to my home do not get to force me to paint my walls a certain color even if I ask for their opinions. I have disengaged from this discussion; I am no longer following this discussion and will probably ignore further pings to it. Thank you. 331dot (talk) 14:05, 22 January 2023 (UTC)[reply]
Very much glad to see the feedback heard - hope to see Vector '22 refined to a state many more will be happy with. Lucksash (talk) 01:59, 20 January 2023 (UTC)[reply]
As has been stated above, this RfC is a psuedo-review of the previous RfC's close. I'm not convinced that the closing comment interpreted the results of the discussion accurately (i.e. that there was consensus to roll out Vector 2022 if a limited-width toggle is added), and the comments on WT:VECTOR2022 indicates that many users did not even have a chance to weigh in on the RfC, which means the RfC may not have been representative of the entire Wikipedia community. I agree that if this RfC closes as "no consensus", WMF should restore the old skin immediately. InfiniteNexus (talk) 07:06, 20 January 2023 (UTC)[reply]
And to reiterate my comments at WT:VECTOR2022#‎Requests for comment/Reverse deployment of Vector (2022), a close that does not end in the Web team's favor will not close the door on Vector 2022 being re-deployed in the future. If Vector 2022 is rolled back, the Web team is welcome to improve the skin to address the concerns raised here, come back with a follow-up discussion asking for more feedback, and then after most concerns have been addressed, a third RfC can be held. InfiniteNexus (talk) 07:11, 20 January 2023 (UTC)[reply]
When are you guys rolling back the Vector 2022 update? Thanks! AdmiralBeans (talk) 07:45, 20 January 2023 (UTC)[reply]
@AdmiralBeans WP:CONSENSUS has not been reached. Aaron Liu (talk) 13:14, 20 January 2023 (UTC)[reply]
Or a lack thereof. InfiniteNexus (talk) 16:24, 20 January 2023 (UTC)[reply]
@Aaron Liu you didn't ask for our consensus when introducing it either, did you? 2dk (talk) 16:22, 20 January 2023 (UTC)[reply]
The consensus was misinterpreted on the previous RfC. InfiniteNexus (talk) 16:24, 20 January 2023 (UTC)[reply]
I'm surprised it didn't get taken to WP:Close review. But I guess WMF is the law of the land. That closure smelled to me of "regulatory capture" e.g. the closers closed with a bit of deference to what WMF actually wanted, even if not told to do so, and even if subconsciously so. — Shibbolethink (♔ ♕) 18:03, 20 January 2023 (UTC)[reply]
Quite possibly. When the community rejects the WMF's pet projects, they tend to force them on us anyway. Perhaps the closers were hoping that a "there would be a consensus if these things were fixed" close would result in the things actually getting fixed. —Compassionate727 (T·C) 00:15, 23 January 2023 (UTC)[reply]
I personally think that Vector 2022 is a WMF fait accompli and it doesn't matter how many of us come to an editorial consensus that we disagree with the "2022" changes, it's a done deal. They've made the kids a shiny new toy and many of us kids just don't want to play with it (somewhere I read that almost 40% of us are reverting to Vector Classic - aka "Vector 2010") Shearonink (talk) 00:46, 23 January 2023 (UTC)[reply]
They don't and won't have to use fait accompli, they can just use office actions. Though I really hope that is not the case and they use this RfC. Aaron Liu (talk) 02:47, 23 January 2023 (UTC)[reply]
Introducing what?@2dk
If you’re talking about the new skin, I am not affiliated with WMF in any way. Also, the skin change was abiding by the misguided closing consensus at WP:V22RFC. Aaron Liu (talk) 16:25, 20 January 2023 (UTC)[reply]

Jan 23 update from Web team: page tools and more upcoming changes

[edit]

Hey everyone,

Thank you all for continuing the conversation on the new skin and reporting thoughts, issues, and bugs as you come across them. We’re reading through everything, collecting your feedback, and planning next steps.

Today, the new page tools menu was deployed to the Vector 2022 skin for logged-in users. The page tools menu allows for a separation between navigation that is related to the entire wiki (Main page, random page, etc) and tools that are related to a specific page (what links here, related changes, cite this page, etc). It also collects all page-specific tools in a single menu, rather than splitting them between the main menu and the more menu. The goal here is to make it easier to understand what these links do for new readers and editors. The new menu can also be pinned and unpinned as needed. More information is available on the project page. The new menu will also be available for logged-out users in one to two weeks.

Moving this menu to the right side of the page has the benefit of showing the table of contents further up the page without requiring people to scroll down to see the table of contents. We’ve noticed that this is one of the concerns we’ve been hearing over the last couple of days and hope this addresses it.

Let us know if you have any questions or experience issues with the tools menu. We have already noted that the menu doesn’t work with the Content Translation beta feature on the Contributions page - a quick fix for this will be available tomorrow morning. Later, the pinned menu will also be sticky, just as the Table of Contents and the left menu.

I also wanted to give a quick update on the status of other fixes, requests, and explorations:

  1. We are lowering the width at which the toggle to make pages wider appears from 1600px to 1400px. This will allow the toggle to show on smaller screens. This change will be available this week.
  2. We have a fix for the scrolling issue on Chromium-based browsers on Windows operating systems. This fix will also go out tomorrow.
  3. We are still working on a short-term solution for making the width toggle persistent across pageviews for logged-out users. I will be updating later this week with news and a potential timeline.

Thank you all again and let us know if you have any questions or concerns! We’ll be posting another update later this week. OVasileva (WMF) (talk) 00:38, 24 January 2023 (UTC)[reply]

@OVasileva (WMF): When you moved the page tools to a sidebar on the right hand side of the screen is there a reason why you made them not float like the table of contents? At present, this means that a huge amount of screen space is lost to empty space for the majority of content on longer pages. While this slightly improves upon the amount of scrolling before the ToC appears for readers, it at best does nothing for editors who still have to return to the top of the page before they can use the tools and at worst makes the experience for them worse as the content area is narrower. Sideswipe9th (talk) 00:46, 24 January 2023 (UTC)[reply]
Hello @Sideswipe9th. Thanks for asking! This is purely temporary. We will make it float: T318169. SGrabarczuk (WMF) (talk) 01:01, 24 January 2023 (UTC)[reply]
@SGrabarczuk (WMF): Awesome! I look forward to that! Thanks! Sideswipe9th (talk) 01:08, 24 January 2023 (UTC)[reply]
I liked the old one better due to the spacing and indentation. Is there a way to switch to the old one? Aaron Liu (talk) 01:38, 24 January 2023 (UTC)[reply]
Hi @Aaron Liu -- I'm Marshall Miller; one of the directors of product at WMF. Thank you for engaging so deeply with this Vector deployment situation; I've noticed your comments in lots of places! Have you tried clicking "[hide]" in that new menu to pop it back into the header of the article? Does that do the trick, or do you mean something else? MMiller (WMF) (talk) 02:26, 24 January 2023 (UTC)[reply]
So, basically, you Marshall Miller are one of the main responsibles of all these mess. As one of your critics, I would like some of you reply sometimes to any from that side, not only to those who appeals the new skin. You are really biased, sorry to say. I've posted my objections reduntantly, most polilely here: https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Aimed_to_help_you, but neither reply nor comment at all (not to me but to the subject, I mean). I expect nothing, so I still append «?useskin=vector» to every requested URL, and I advocate and promote this among the non-logged users. Will you give us counters of requests with that option «?useskin=vector», as part of your surveys on the (hypothetical) success of the new UI? I guess not... 37.134.90.176 (talk) 09:26, 24 January 2023 (UTC)[reply]
A tiny fraction of readers will add useskin=, simply because 99% don't know about it. Unfortunately, that tells us nothing about which skin they prefer. Certes (talk) 10:36, 24 January 2023 (UTC)[reply]
Then, add a banner explaining it: «If you want to use the previous visual style of Wikipedia, please: a) create an account and set your preference, or b) add ?useskin=vector to the URL.» Easy, isn't it? (Not sarcasm at all). 37.134.90.176 (talk) 11:03, 24 January 2023 (UTC)[reply]
There are now extensions for Chrome and Firefox, I haven't checked the other browsers, but there is likely something available too. If not, one can use a generic redirect extension with a redirect rule. Crucially, to use these, one does not even need to understand what an URL is. Pretty much like with old reddit. This is how I'm going to insulate myself from the new changes. It will make the URLs ugly but so be it. 89.102.98.143 (talk) 21:36, 24 January 2023 (UTC)[reply]
So, basically, you Marshall Miller are one of the main responsibles of all these mess. As one of your critics,... In fairness, having interacted with MMiller before on Growth Team product launches, I can say he's an excellent product manager who communicated actively and substantially with the community at each step of product development and deployment, including starting multiple community consensus discussions while rolling out new product features. (I don't know what his involvement in Vector 2022 is.) IIRC this opinion was universally held among editors involved in those discussions. ProcrastinatingReader (talk) 12:58, 24 January 2023 (UTC)[reply]
Absolutely agreed. The criticism is most unfair, regardless of one's opinions on Vector 2022. 🌈WaltCip-(talk) 13:30, 24 January 2023 (UTC)[reply]
It seems you're more concerned about criticism, not about technical objections. Mr. Miller introduced himself, and I guess he didn't if there was no problem at all with this new skin. But it resounds... In my job, I must to face criticism when results are not as expected, so Why you don't? Still, no comment about the flaws I and many detected and communicate you (aside that both you decided to patch) what is what I'm interested in, not disputes. Anyway, thank you for answer me this time. 37.134.90.176 (talk) 16:40, 24 January 2023 (UTC)[reply]
While I agree that the criticism of individuals involved in the project is somewhat unfair, I strongly agree with the sentiment of this RFC and the strong protests of the myriad new users who created accounts simply to protest the decision and/or revert to the Vector 2010 style via user preferences. You state that "the opinion was universally held among editors involved in those discussions," but the problem is that there were far too few editors and readers involved to reasonably make such a huge change that affects every reader and editor. It is a mistake to make such a contentious UI change the default with out much longer and much wider testing and polling. Furthermore, it is unwise to ignore the voices of the many volunteers (and donors) who make all of the community-driven projects work so well. KnowledgeablePersona (talk) 07:19, 30 January 2023 (UTC)[reply]
Hello 37.134.90.176 -- thank you for writing out your thoughts on Vector 2022 and for being an editor. I'm sorry we hadn't responded previously. As you can see, there are lots of comments coming in and the team is doing its best to get to them. I read the list you linked to of the 7 points you wrote out. There were some that I've heard before but others that I hadn't (like your point about how articles with and without tables of contents start at different parts of the screen). We'll be recording your thoughts along with the rest of what we're reading in everyone's comments to figure out what is coming up the most often.
@ProcrastinatingReader -- just to shed a little more light on how we're structured at WMF, as a director of product, my job oversees the work of multiple product teams (whereas I used to be the product manager of the Growth team). The teams I work with now are the Web, Editing, and Growth teams. So while I am not as intimately familiar with all the details and nuts and bolts as someone who works with the Web team every day, I do follow along and advise on the work. And since this is such a big conversation with the deployment of the new skin, I am reading comments and helping reply where I can. MMiller (WMF) (talk) 05:53, 25 January 2023 (UTC)[reply]
Thank you very much to be personally answered by you, Mr. Miller. Not for the answer it itself, but to realize myself you're taking into account the flaws I (and many others) pointed you. Many people complaint not only about the UI technical flaws (aesthetics is always a matter of personal taste), but the way how all of you in WMF have handled all the case. But done is done. As an experienced developer, I want to contribute to correct every technical fault, from the point of view of an IP editor (and potential donator, you know). This is the right way. Your involvement here is a proof to me that the team did poorly testing (many flaws of design were detected at first sight), and now all this mess must be put under control. This is sufficient to me, and I expect to be to many others. Thank you again. Regards. 37.134.90.176 (talk) 08:01, 25 January 2023 (UTC)[reply]
Other problem I've found just now: the new skin with in (default) max. length width text mode ignores the directive «{‍{div col|colwidth=35em}}» (or similar) in «See also» sections. In articles with many links in this section, it becomes a lenghty, unstructured linear list. In full-width length text mode, it behaves as Vector legacy, as expected. As editor, usually I take care to carefully format that section using «colwidth», but the new skin ruins the effort.
Similar behaviour occurs with the «References» section, but in this case, if some image at previous section became intrusive: the whole Refs section becomes a single, full width column. Not easy to read (probably, contradicting your own overall intentions). 37.134.90.176 (talk) 09:41, 27 January 2023 (UTC)[reply]
Hi @MMiller (WMF), it was something else. Besides T327719, I have a couple of issues with it:
  1. On the left, the texts are short, creating a lot of empty space for the whole right half of the left sidebar. This isn't "useful whitespace" as it is obstructed by the section ribbons and it is grey. Couldn't we shorten the width and/or right-align it?
  2. On the left the spacing appears to be sparser than the article. This just makes it a lot more eye-catching than the old sidebar which is distracting.
  3. For whatever reason, Twinkle doesn't appear in the tools sidebar.
  4. The tools sidebar doesn't have a background or border, which doesn't make it nicely separated from the main article. This looks confusing and distracting to me.
  5. On an iPad, the pagetools create a content flash before auto hiding due to responsiveness. Why do we have a content flash? If the content flash is needed, shouldn't IP prefs with cookies/local storage also be implemented?
  6. The content flashing sometimes causes Safari on iPad to crash and refresh repeatedly before admitting defeat "A problem repeatedly occurred".
Aaron Liu (talk) 12:51, 24 January 2023 (UTC)[reply]
Additionally, jumping to sections occurs BEFORE the content flash which makes the jump useless as the flash made it scroll to other places anyways. Also if there’s a TOC on sidebar for small screens shouldn’t we be able to move the left sidebar to the sidebar?Aaron Liu (talk) 14:57, 24 January 2023 (UTC)[reply]
Thank you for the specifics, @Aaron Liu. The Web team is going to find those reflections useful. I'm pinging @OVasileva (WMF) who can react in better detail than I can, since she is a lot closer to the nuts and bolts of the design. MMiller (WMF) (talk) 06:50, 25 January 2023 (UTC)[reply]
Hi @Aaron Liu - thank you for your detailed feedback! We’re currently sorting through additional notes and reports for the page tools menu and menus overall, so this is really helpful. To address your specific points:
  1. Generally, the space in this menu is done for two reasons - matching the width of the ToC and also making sure that the menu is consistent across different languages. For example, on German Wikipedia and other language wikis, the titles of the sections can be a bit longer. There might be some smaller optimizations here we can look into, however.
  2. Initially, we wanted the styling of the menu here to be consistent with the ToC. However, we are receiving feedback that it might be preferable for editors to have these items be a bit less sparse, even at the cost of consistency (see this phabricator thread for more context). We plan on proposing some changes to this spacing in the upcoming week.
  3. Twinkle is still currently a separate menu from the new tools menu and appears alongside the tools menu when collapsed. In the future, we also want to be able to make Twinkle and other menus coming from gadgets to be pinnable as well. This will take additional technical investment and coordination with gadget creators, but we have started exploring what is possible. Check out this prototype for the initial ideas on this: https://di-article-tools-2.web.app/Blue_whale (select advanced tools in the bottom right corner to make these tools appear). Another step we'd like to explore, in the even further future, might be to explore customization for the location of different menus so users can select whether they want menus to appear in the right or left sidebar, and in which order.
  4. The main idea behind the tools menu is to combine page-specific tools that were previously available in the “more” menu with the page-specific tools that were in the main menu/left sidebar into a single menu. Our initial thinking was to have the main menu as more visually separated via the gray background (since it focuses on global/site navigation), but to have page tools more closely associated with the article content since the tools themselves are related to the page. We are interested in exploring some more options on how to visually separate the menus in general. @AHollender (WMF), our designer, can speak more to this, but one potential option can be seen in the prototype I linked to above
  5. Both this point and the following one seem like potential bugs - we will try to reproduce this and get back to you on the specific issue. Could you let me know what version of Safari and operating system you are using? It will help us debug and try to reproduce.
Thank you again for your thoughts and the specific feedback - definitely let me know if you encounter more issues or questions with the new menus in general. OVasileva (WMF) (talk) 22:41, 25 January 2023 (UTC)[reply]
Thanks for the response!
3. On the prototype, putting the toggle in the bottom right isn't a good choice. Just like the max width toggle, it's hard to see the toggle since margins are to be ignored.
5. I'm using 16.1 605.1.15 . Aaron Liu (talk) 23:04, 25 January 2023 (UTC)[reply]
5. Is because it dynamically switches to 1000px width rendering instead of the iPads default width of 960px. Generally this happens so fast that you wont' notice, but on bigger pages you might notice it. It is far from ideal, but will be solved as the skin becomes more responsive in the future.
6. The crashing is generally because the page is too big sometimes. The iPad runs out of memory for the browser thread and crashes it. It happened before as well, but now there are a lot of people engaging and talking on very large pages with very large threads, so they experience it quite often. It might be that the reflow of 5 causes a spike in memory, which makes it slightly more common, but.. I think its just big pages. —TheDJ (talk • contribs) 23:42, 25 January 2023 (UTC)[reply]
Note that I can't find a page on which I can consistently reproduce crashing. It only occurs once every few loads, even for the same big page. Aaron Liu (talk) 00:07, 26 January 2023 (UTC)[reply]
Hello, thanks for this post - I'm fine with the Vector 2022 layout, but was not impressed to find that wikipedia had changed again this morning. Not everyone monitors RfC like a hawk, and this took some finding! Could you maybe give people the heads up when you make changes like this? Letting people know that you can hide the tools is also useful - esp. when you read more than you edit! Turini2 (talk) 08:31, 24 January 2023 (UTC)[reply]
Hi @Turini2 - thanks, you raise a good point. We had initially announced this last week on the Village Pump as well as the Vector 2022 landing page, but are still looking at more options to get notices and alerts out about any upcoming changes as we move forward. We're also trying to respond to feedback and concerns quickly, so our rate of making changes right now is probably a bit faster than usual. That said, the page tools menu is the largest of these changes that we currently have planned. Some smaller changes are coming up that I've mentioned above as well. We'll continue updating here and on VPT as we move forward and learn. Hope this is helpful! OVasileva (WMF) (talk) 19:56, 24 January 2023 (UTC)[reply]
Please do not plan next steps. This is not ironic or a clever choice of words. There is an RfC in progress with wide participation over whether the new skin should basically be an option. Respect the process by not moving the goalposts through adding more "features". It is however fine to debug the new interface. If I'm reading correctly, most users' objections have to do with look-and-feel and usability and not with any bugs present in the current skin build. I suggest you devote any extra development resources into making it easy for all users to seamlessly switch between skins depending on the device/screen size they use at the time. Or develop a proper iteration of the new skin for screens over 12" landscape. 172.254.255.250 (talk) 16:50, 24 January 2023 (UTC)[reply]
1 and 3 ARE community look and feel expressed here and at WT:V22. And bugs should definitely take priority especially for a giant scrolling bug. An RfC should not prevent changes from being made to improve it. Aaron Liu (talk) 17:09, 24 January 2023 (UTC)[reply]
Were these look-and-feel issues not noticed before forcing them as default? The tacit admission (to paraphrase, "everything is getting fixed/better! look here, not there!") regarding bugs in the new interface does not inspire confidence. The fundamental questions remain: what consensus requested an obligatory new skin/view? If it is a technical issue that for some reason requires the new skin as default, what issue is it? It is obvious that many users do not consider the change positive or neutral. 65.88.88.59 (talk) 21:33, 24 January 2023 (UTC)[reply]
aaa See FAQ Q3. The community closers unaffiliated with WMF of WP:V22RFC said that they think the !votes there indicate that v22 can be adopted without another discussion (hence consensus) as long as the fixed width toggle was added. There is some debate as to whether or not the text says that two also issues also need to be fixed. Aaron Liu (talk) 12:47, 25 January 2023 (UTC)[reply]
Aaron Liu, I think those bugs should be fixed. But discussion of those bugs aren't really relevant on this page. This page is for discussing whether or not to roll back the the theme, not whether this or that bug fix should be done sooner or later. TheMissingMuse (talk) 04:02, 25 January 2023 (UTC)[reply]
Yeah the page does'nt discuss the bug fix it discusses whther to adopt the old skin as default or not so the timing of bug-fixes are irrelevant and shouldn't be delayed by an rfc. Aaron Liu (talk) 12:44, 25 January 2023 (UTC)[reply]
I've read carefully the thread T326887, and I see you're struggled only with the amount of pixels for some kind of threshold. But, you know, on screen font size depends also of dots per inch (dpi) logical resolution. While many display on MS Windows use 96 dpi by default, recent displays have greater pixel density, in my case it is using 1920×1080 at 144 dpi in a 17" laptop display. That is, it is using more pixels per character than at default 96 dpi. Even more, users can change that setting (Config→Screen→Change text size) at their taste/need. So please don't rely in pixels, but in some other logical unit, as "em". Even better if the text width toggle button is unconditionally visible always, if there is a chance it will expand the text a single "l" character, or if wide text has been already set (to unset it). 37.134.90.176 (talk) 17:26, 24 January 2023 (UTC)[reply]
CSS pixels are already virtual. E.g. for people with high DPI displays the CSS pixels are not equal to actual pixels. 89.102.98.143 (talk) 21:40, 24 January 2023 (UTC)[reply]
I already know, I'm a web designer and developer, but if you read that thread, it gives the impression they don't know it. I realized many times that some developers didn't know about some basic details, and this could be the case. May be they rely only in test-and-error while looking only to their screens, otherwise it is hard to believe they didn't find that flaw while testing, as it has been obvious to many at first sight. CSS virtual pixels make browsers' zoom to work. But even at 100%, dpi must be taken into account, because the system's font renderer engine rely upon it. A better testing should imply not only viewport width, but also browser zoom and system dpi settings. Have in mind. 37.134.90.176 (talk) 08:23, 25 January 2023 (UTC)[reply]
I've already found the developers think 96 dpi is sort of standard: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Visual_Refinements#Font_size I quote: "Firstly, we need to convert the measure used by the researchers (points) into the measure that browsers ultimately render (px). The conversion is: 1px = 72pt / 96. So the range studied in the research (10–26 points) is equivalent to 13.3–34px. Their conclusion, 18 points, is equal to 24px." So I was right, they didn't know about pixel density. Not a good starting point... 37.134.90.176 (talk) 08:49, 26 January 2023 (UTC)[reply]

Brilliant. One of my complaints was that Vector22 increased the place and number of menus, so now instead of 4 locations with menus (left, top, right of title, under title), they are spread over 5 locations, compared to the two of Vector (left and top). Also looks extremely rushed, e.g. couldn't even be bothered to use the same grey background the left side menu has. No idea why, on Preferences, I get the "upload file" option on the left and on the right, has nothing to do with Preferences??? All in all, it makes Vector22 even less appetizing, creating a very tiring look with way too much distraction from the actual essence, the article. Fram (talk) 09:29, 24 January 2023 (UTC)[reply]

@Fram: The double "upload file" link is a pre-existing issue, you should see it in legacy Vector, Timeless, etc. with two links on the left side. It's because the English Wikipedia added the upload link to the sidebar (per this RfC) and then hid the default one with CSS. Except said CSS doesn't work on Special:Preferences for security reasons, so now there are two upload links. Maybe the declining of T255381 should be reconsidered, idk. Legoktm (talk) 12:00, 24 January 2023 (UTC)[reply]

Ovasileva: sorry if I missed it in the discussion, but could you indicate how the skin has changed in regard to the other two concerns that were required for a firm consensus according to the first RfC (the non-intuitive icons and the language selector). —Femke 🐦 (talk) 20:57, 26 January 2023 (UTC)[reply]

Disclosure of email outreach

[edit]

Hello, everyone. I am Selena Deckelmann, the Chief Product and Technology Officer at the Wikimedia Foundation. We have been made aware that last week, one of our staff members sent an email to draw the attention of other people in their professional networks to this RfC. In the interests of full transparency, we are publishing the contents of that email, with permission of the author and with identifying information redacted, as a pdf. The email was initially sent to 29 people. We do not know how widely it was subsequently redistributed, although we do know it was shared on several online groups with collective memberships of just under 350 people. The email itself invited redistribution, so it is not possible to calculate how many people received it. We believe the distribution occurred between January 23 and January 25. We will be sharing full details as they become available with the Arbitration Committee.

The Foundation does not encourage or condone canvassing, as we recognize that it can undermine community conversations and harm trust. While we believe the staff member who did the outreach was well intentioned (they mentioned the canvassing guideline themselves, encouraging people to follow it), they acted against both direct instructions and the relevant Wikipedia guideline.

I am disappointed that this is my first engagement with this RfC. My hope was to participate and share in the discussion. I still plan to do that, Tuesday at the earliest.

I want to thank ArbCom for drawing this to our attention. We are cooperating fully with them as they review this matter themselves. We are considering steps to take to avoid such situations going forward, including but not limited to training. We will need additional time to determine other steps that will help. We will follow up with ArbCom within a few days. -SDeckelmann-WMF (talk) 15:08, 29 January 2023 (UTC)[reply]

! Thank you for this prompt + thorough note. – SJ + 16:32, 29 January 2023 (UTC)[reply]
@SDeckelmann-WMF: Thanks for the transparency and sharing the email. Could you kindly let the staff member who sent that email that even though RfCs look like ballots with support and oppose choices, they aren't votes? —Tenryuu 🐲 ( 💬 • 📝 ) 18:18, 29 January 2023 (UTC)[reply]
If I had to describe Wikipedia RfCs to an outsider, I would probably call them votes just for simplicity. But I think focusing on the terminology of "vote" vs "!vote" risks missing the bigger red flags (for me) in the email.
The email starts with, "On Wikipedia decisions are made democratically...". Wikipedia is explicitly not a democracy. Technical decisions (which fundamentally is what the choice of default skin is) are not made democratically! As I've already expressed on this page, I think it was a big mistake for the WMF to put switching to Vector 2022 by default up for an RfC as if it was a decision communities can make via RfC, leaving us in the spot where the community is discussing overturning the previous RfC (which makes total sense). Did this misguided impression that Wikipedia is a democracy lead them down that route? We always need and want more community input in technical decisions, but the on-wiki RfC process really isn't it.
It seems incredibly unhealthy that staff feel forced to resort to such measures to try to "win" an RfC. I hope this is addressed as a culture problem within the WMF rather than focusing on one specific individual's actions. Legoktm (talk) 20:18, 30 January 2023 (UTC)[reply]
I very much appreciate the prompt attention the WMF gave this matter once it was brought to their attention. It is never fun to find out one of that someone you work with has done something that could damage the reputation of the entire enterprise, and for many, the instinct would be to try and keep it quiet and cover it up instead of openly admitting it, saying it was wrong, and sharing the evidence. Mistakes happen, I have often said that it is what happens after the mistake becomes apparent that is the true test of character. Beeblebrox (talk) 18:22, 29 January 2023 (UTC)[reply]
I also applaud your handling of this. One perhaps unrelated observation, my understanding is that this RfC advocates rolling back to Vector 2010 as the default. Nobody suggests that Vector 2022 should disappear, or should not be ever reconsidered as defaul. 204.19.162.34 (talk) 18:40, 29 January 2023 (UTC)[reply]
Ah, so that's what the suspicious chain was. Also the email mentions the rfc as a "vote". Aaron Liu (talk) 22:54, 29 January 2023 (UTC)[reply]
@Aaron Liu I'm really really sad about this, we are telling one and another that RFC is not a vote, however, it was dealt like a vote, even from WMF. Lemonaka (talk) 14:27, 30 January 2023 (UTC)[reply]
SDeckelmann-WMF: Thank you for sharing this. This incident is disappointing, but I welcome your transparency. I hope internal training, and some kind of internal counseling for community relations, can prevent this in the future. Best, MarioGom (talk) 08:06, 30 January 2023 (UTC)[reply]
SDeckelmann-WMF I appreciate the transparency here, I'm sure it must put you in a difficult situation that you didn't ask for. I'm also somewhat disappointed that the situation was discovered by Arbcom at some point but there was no notification from them. I of course understand the need to keep confidential information private, but a simple "We've learned about a potential canvassing incident, have notified the WMF and are investigating" would have been helpful. Editors appear to have already become suspicious of some of the statements as indicated above. I do think the larger red flag here isn't the wording of "democratically", but rather "due to some political concerns we had to wipe the doc, pasting the content below". This seems to suggest that the person sending the message knew that it wasn't allowed, but wanted to do it anyway. I don't know if the Foundation is using Google Workspace, but if that's where the Drive document was being hosted then it should be possible to use the Drive log to see how many external users viewed it. I'd urge the closing administrator(s) to keep this incident in mind when reviewing the !votes and weighing the arguments made. The WordsmithTalk to me 21:10, 30 January 2023 (UTC)[reply]
Same. The staff member seems to know what they were doing yet just brushed it off as “some political concerns” as if they weren’t relevant. Aaron Liu (talk) 14:05, 31 January 2023 (UTC)[reply]
Thank you for being so transparent about this matter. Lots of IPs or accounts with few edits joining a technical discussion would normally raise a huge red flag. However, this RfC is unusual (possibly unique) in that, even without canvassing, readers are joining Wikipedia and making their first edits in good faith just to make their views about the new skin known. Certes (talk) 23:16, 31 January 2023 (UTC)[reply]
@SDeckelmann-WMF: The email says that a google doc was wiped due to "political concerns". Can you explain what those concerns were?
Can you also provide the dates and times that any emails or other communications were sent? This will help us identify !votes that have been canvassed, by comparing them to the !vote times of low-contribution editors. BilledMammal (talk) 16:27, 2 February 2023 (UTC)[reply]
Hello @BilledMammal -- thank you for reading closely and thinking about this issue (and thank you to everyone else in this thread for commenting, collaborating, and weighing in on the nature of RfCs and consensus). Regarding that phrase "political concerns", the issue there is that the staff member was told not to distribute the contents of the document, but decided to proceed, and it looks like they used that phrase to explain what happened.
And to your question about when the communications were sent, as Selena said in her original message, we believe the messages were sent between January 23 and January 25. We continue to be in contact with ArbCom, providing them the details they need to assess this situation.
I hope this helps, and let me know if you have other questions or concerns. MMiller (WMF) (talk) 17:19, 2 February 2023 (UTC)[reply]
Thank you for your response, and for clarifying that phrase.
If they are available to you, can you provide the exact times and dates the communications went out? BilledMammal (talk) 17:44, 2 February 2023 (UTC)[reply]
@MMiller (WMF) and SDeckelmann-WMF: BilledMammal (talk) 10:56, 4 February 2023 (UTC)[reply]
Hi @BilledMammal -- I'm sorry I missed your first note, and thanks for the ping. I will find out and get back to you. MMiller (WMF) (talk) 06:13, 6 February 2023 (UTC)[reply]
Hello @BilledMammal -- I looked into the details you asked about, and I have the following information. Thank you for waiting. The emails were sent in three clusters:
  1. Between Jan 23 19:00 UTC and Jan 24 01:30 UTC
  2. Between Jan 24 12:00 UTC and 16:00 UTC
  3. Between Jan 24 23:00 UTC and Jan 25 01:45 UTC.
I hope this is helpful. MMiller (WMF) (talk) 17:15, 7 February 2023 (UTC)[reply]
Thank you, it is. I've posted a review below BilledMammal (talk) 09:25, 8 February 2023 (UTC)[reply]
Nice to see this is being shared with the community - still disappointed with what happened. Here's one quote from the mail: "If rolled back to 2010, the site may get stuck in the past". That's not even remotely neutral, and neither is the targeted audience (professional developers are more likely to oppose going back to Vector 2010).
I would like to see a humbled public apology from whoever did this. If they can convince the community they are deeply sorry and understand the error of their ways, I could forgive them. If they'd rather remain anonymous or don't understand their mistake (or have made similar mistakes in the past), IMHO they should find a job where this kind of behavior isn't frowned upon, if you catch my drift.
Also from the mail: "The Wikipedia community recently approved the redesign our team has been working for the past 3 years"[citation needed] Seriously, where is that approval? As an aside: I personally (regardless of WP:CANVAS) don't mind stealth but fully neutral and non-partisan canvassing (it's nigh impossible to achieve though) and I don't mind biased public campaigning provided it's not spammy. What happened here was unfortunately the worst kind: a clearly biased message, full stealth, partisan audience AND spammy. Checking all four boxes for Wikipedia:Canvassing#Inappropriate notification, that's an accomplishment of some sort. — Alexis Jazz (talk or ping me) 07:12, 19 February 2023 (UTC)[reply]

Canvassed vote review

[edit]

I split !voters into three groups; less than 10 edits, between 10 and 100 edits, greater than 100 edits. I then split each of these groups into two groups; those who support the rollback and those that oppose it. All of these groups followed the same general activity trend, with peaks and declines matching, with two exceptions:

  • Supporters with more than 100 edits spiked on Jan 30, with approximately five excess !votes
  • Opposers with less than 10 edits spiked between Jan 23 and Jan 25, with approximately thirty excess !votes

I assume the cause of the first is the disclosure of this canvassing on ANI, and the second appears to be the result of this canvassing, with the spike times also being closely correlated with the times the WMF provided above:

  • 9 !votes between Jan 23 19:00 and Jan 24 04:00
  • 17 !votes between Jan 24 12:00 and Jan 24 22:00
  • 6 !votes between Jan 24 23:00 and Jan 25 12:00

Outside of these days, this group had a peak of 4 !votes, and a median of 1. On the basis of this, I've tagged those editors as canvassed; there will be a couple of false positives, but only a couple. BilledMammal (talk) 09:25, 8 February 2023 (UTC)[reply]

Interesting research; thank you. I came here sceptically expecting the contributors to be typical readers who had registered to praise the skin (unaware that IPs can comment too). However, the timing suggests that many of those !votes seem likely to be canvassed. Certes (talk) 12:53, 8 February 2023 (UTC)[reply]
I got the the following result counting supporters and opposers of the RFC at different times:
Time Support Oppose Support/
Oppose
Jan 23 19:00 177 110 1.61
Jan 25 01:47 211 158 1.33
Jan 25 00:04 230 170 1.35
Feb 8 21:18 310 209 1.48
It seems that the balance changed during the alleged canvassing and that it has been partially reversed afterwards. Plumbum208 (talk) 22:03, 8 February 2023 (UTC)[reply]
Full breakdown BilledMammal (talk) 09:17, 9 February 2023 (UTC)[reply]
Row Labels Neutral <10 Oppose <10 Support <10 Total <10 Neutral <100 Oppose <100 Support <100 Total <100 Neutral >=100 Oppose >=100 Support >=100 Total >= 100 Neutral Oppose Support Total
19-Jan 0 1 0 1 0 0 2 2 0 6 5 11 0 7 7 14
20-Jan 1 4 7 12 0 1 7 8 4 38 53 95 5 43 67 115
21-Jan 0 0 12 12 0 0 8 8 2 24 25 51 2 24 45 71
22-Jan 0 1 13 14 1 1 1 3 2 13 22 37 3 15 36 54
23-Jan 0 6 2 8 0 0 5 5 1 19 19 39 1 25 26 52
24-Jan 0 23 2 25 0 4 2 6 0 11 19 30 0 38 23 61
25-Jan 0 7 1 8 0 1 4 5 0 7 14 21 0 15 19 34
26-Jan 1 2 1 4 1 2 1 4 1 6 5 12 3 10 7 20
27-Jan 0 1 1 2 0 0 0 0 1 3 7 11 1 4 8 13
28-Jan 0 1 1 2 0 1 0 1 0 3 2 5 0 5 3 8
29-Jan 0 0 2 2 0 0 0 0 0 6 4 10 0 6 6 12
30-Jan 0 2 2 4 0 0 0 0 1 1 10 12 1 3 12 16
31-Jan 0 0 1 1 0 0 1 1 0 3 6 9 0 3 8 11
01-Feb 0 1 4 5 0 0 0 0 0 0 1 1 0 1 5 6
02-Feb 0 3 0 3 0 0 0 0 1 3 6 10 1 6 6 13
03-Feb 0 0 1 1 0 1 1 2 0 0 2 2 0 1 4 5
04-Feb 0 0 1 1 0 0 1 1 0 0 1 1 0 0 3 3
05-Feb 0 1 0 1 0 0 0 0 0 0 6 6 0 1 6 7
06-Feb 0 0 1 1 0 0 1 1 0 1 1 2 0 1 3 4

Persistence for fixed width for all users coming this week

[edit]

Hey everyone,

Thank you all so much for your continued feedback, especially since the deployment of the skin almost two weeks ago.  We have been going through your comments, and noted that one of the main issues we are hearing is concerns about the fixed width toggle on the page, in particular when it appears and its behavior for anonymous users.  In this message, we are announcing an improvement we have already made, and another that is in progress.

the Vector 2022 skin's fullscreen toggle icon
the Vector 2022 skin's fullscreen toggle
Some users pointed out that they would like the toggle to appear at lower resolutions and for smaller screens and monitors. We decided this is something we could quickly address. We had initially set the page width threshold at which the toggle displays at 1600px so that the toggle could be effective even on pages (such as History or Recent Changes) that appear in full width. Last week, we made a change that allows the toggle to show at the lowest possible width where it can have an effect (1400px). This means that more users will have the options to toggle the width on more pages.

The most commonly heard concern was the lack of persistence for the fixed width toggle across pages for logged out users, i.e. that if logged out users want to read with full width, they have to click the toggle button for each new page they read.  After coordinating with multiple teams across the WMF, including the Performance, Design Systems, and Site Reliability Engineering teams, we are in the process of implementing a workable solution.  

We are aiming for fixed/full width persistence to be available for all users, including logged-out users, starting this Thursday, February 2.  This means that all users will see the width setting of their choice despite refreshing pages or opening new ones.  For those of you interested in testing the change ahead of time, it is already available in our testing environment.  

This has been a technical challenge, since logged-out users have never had persistent settings before.  We have spent the week coordinating and trying out various solutions, before building out the best option.  We will spend the next few days testing and ensuring that we can have a bug-free rollout of this change.  While the current solution solves the short term problem of allowing logged-out users a way to choose the full width, it is imperfect and bespoke for this particular case. There is more work to be done to make sure this solution is maintainable in the long term, so that we can apply it to other use cases we might want to work on in the future such as font size, keeping the sidebar open, or dark mode.  We plan on updating on potential plans and ideas here in the upcoming weeks and months.

Ping @Aaron Liu, Jonesey95, Xaosflux, Kizor, 2dk, JCW555, IanKBania, ApLundell, and Blue Edits who have pointed at the toggle specifically. We know many of you have asked for this, so apologies to anyone that has been waiting for this that we have forgotten to ping directly.

Thank you again and we look forward to continuing to make the skin better based on our measurements and your thoughts and ideas.  We also encourage you to bring your thoughts to our next office hours: Thursday, February 2 at 20:00 UTC (click here to join / dial by your location). We will be reviewing and discussing different requests so far, and answering general questions about the skin.  OVasileva (WMF), SGrabarczuk (WMF) (talk) 17:43, 31 January 2023 (UTC)[reply]

@SGrabarczuk (WMF) will the Zoom meeting also be broadcast on Discord? Aasim - Herrscher of Wikis ❄️ 18:28, 31 January 2023 (UTC)[reply]
Hey @Awesome Aasim. We don't broadcast our meetings (or record them). Zoom works on browsers, so you don't need to install the app. And if you prefer, you may dial in instead of joining. Does that answer help you? What problem would you like to solve? SGrabarczuk (WMF) (talk) 20:56, 31 January 2023 (UTC)[reply]
Yay! Aaron Liu (talk) 18:53, 31 January 2023 (UTC)[reply]
There needs to be a way to just revert to the Vector 2010 skin for logged out users. There is nothing worth saving in the new skin. It gets a complete 0/10 rating from me. Sorry to be so blunt, but it's just not getting through that many of us hate your new skin and don't want to use it. Stop forcing me to do so. Just give me the option to use the 2010 skin as an anonymous user. When this happens I'll stop complaining about this. 2600:1700:1471:2550:82D:A299:5C4B:30F8 (talk) 19:39, 31 January 2023 (UTC)[reply]
I agree. The more I experiment V2022, the more I think that V2010 is more functional, fine, sleek, serious, professional, suitable for an encyclopedia and especially for a user-edited encyclopedia like Wikipedia. The width is certainly not the only flaw in V2022: the sticky ToC, the hidden toolbar, the languages' bar, the indistinction between the space of the article and the space of the user (in V2010 it was given by those azure lines demarcating the boundaries between the article and the user's menus) — everything is worse than in V2010, unstructured and confusing. V2022 is not more "polished" at all; it's just mobile-looking and winks at the oversimplified interface of social networks. Æo (talk) 21:09, 31 January 2023 (UTC)[reply]
Again I fail to understand how any of the changes you listed are problems, save for the contrast, which I agree is a big problem but that doesn't outweigh all the benefits. I've been debating the TOC above, the hidden sidebars are easily accessible with the move to sidebar button, the width isn't a flaw as it creates comfort reading and finally unifies the width of wikipedia for page layout, V2022 is sleek and all of the skins are fine. Aaron Liu (talk) 23:40, 31 January 2023 (UTC)[reply]
Aaron Liu - That all the skins are fine, that V2022 is sleek, that the changes are (not) problems, that the width isn't a flaw, that the hidden sidebars are easily accessible...that's all your opinion and your opinion about Vector 2022 does not negate mine or anyone else's. Your experience with Vector 2022 has been Good - that's great for you - but my experience was Not Good, and many other editors' experiences with Vector 2022 have been Not Good. If a sizable number - say 30 or 40% (40% was the figure, I think, last time I checked?) or even a majority of editors abandon Vector 2022 and choose to use Vector 2010/Vector Classic instead, then in my opinion editors and readers are voting with their feet. I personally do not have any great hopes that the various WMF Teams will rejigger Vector 2022 according to the flood of feedback seen here and elsewhere on Wikipedia. Shearonink (talk) 06:48, 1 February 2023 (UTC)[reply]
@Shearonink, 40% was the figure, I think, last time I checked? where did you get this figure from? — Qwerfjkltalk 08:16, 1 February 2023 (UTC)[reply]
Qwerfjkl - Lol...oh boy, if I could remember I would have provided a link. I've been on SO many of the Vector 2022 pages here on WP. I think maybe the obverse was cited by a WMF-person early on, within a few days of Vector 2022's public unveiling, as a measure of Vector 2022's success... that the adoption-rate was almost 60% and I replied but that means that almost 40% are rejecting Vector 2022 and how can that be a measure of success? It is possible I am misremembering the figure cited, happy to be corrected if I am wrong. Sorry I'm not any better on the specifics... Shearonink (talk) 19:33, 1 February 2023 (UTC)[reply]
@Shearonink, Are you perhaps thinking of mw:Reading/Web/Desktop Improvements/Repository/Sentiment Survey, mentioned below? — Qwerfjkltalk 19:57, 1 February 2023 (UTC)[reply]
Technically it’s all opinions. Every policy and guideline etc are consensus’d opinions on what’s best, and here we’re basically weighing which option should be the best for a huge majority of users. And I think v22 is better because it adds a lot of new useful features such as search and sticky header.
If you’re talking about the opt out statistics, for editors that have made 5 edits in the past year starting September, it averages 13% across all wikis. Statistics by wiki can be found at T317529 Aaron Liu (talk) 13:58, 1 February 2023 (UTC)[reply]
Disagree with the width not being a flaw. For reading it can be argued that it's better, but if you have realtime preview on while editing (I always do), the page becomes impossibly thin. An average size picture pushes the text away, and to make the preview window bigger is to make the editing window smaller. On my screen, in V2010 the sidebar takes up about 1/7 of the page, while the edit window and preview window take up about 3/7 of the page each. In V2022 the left sidebar takes up about 1/4 of the page, the edit window and preview window take up about 1/4 each, and the right sidebar takes up about 1/4 also. 43% to 25%, a 42 percent decrease in editing space. And there's nothing I can do about it, except buy a bigger computer? Hook it up to a monitor just so I can edit Wikipedia? This is an irreconcilable issue for me, and many. Width is my number one issue with V22 by far. Cessaune [talk] 00:40, 1 February 2023 (UTC)[reply]
Even as I read I find more issues with the width. When I opened the Costa Concordia disaster talk page, two of the templates are inline with each other. Their combined minimum width is too big to be centered correctly, so it shoves one of the templates off center to compensate for that. Only one, so it ends up hanging off the side in the abyss of white. Cessaune [talk] 00:57, 1 February 2023 (UTC)[reply]
That is not just a problem with v22. That archives template floats to the right, as is by default. You can enable max width or switch to old vector on a large width to see that it will float to the right. Usually different templates use new lines to separate them. What do you think should've happened? It's not even a banner.
Besides, that talk page already has a talk page header template so that archives template shouldn't even be there. I've went ahead and merged it into the header, see Old revision of Talk:Costa Concordia disaster for when I didn't remove it. Aaron Liu (talk) 01:32, 1 February 2023 (UTC)[reply]
Yes, I know, but in V2010, the width is typically too wide for that to be an issue. It's only an issue due to the smaller width of V2022. Cessaune [talk] 01:36, 1 February 2023 (UTC)[reply]
What was I trying to say in this reply here? It looks very incoherent what was I thinking Aaron Liu (talk) 01:43, 1 February 2023 (UTC)[reply]
I agree with Cessaune, and (@Aaron Liu) honestly I feel more invited to read in V2010. Also, I have two laptops and I have noticed that articles' width is displayed differently in the two cases: on my smaller laptop with a small screen, the articles seem to occupy a wider section of the screen, although significantly shifted to the right, as the right sidebar lateral white band is significantly narrower (almost to be zeroed) while the left sidebar lateral white band remains rather large (about 20-75-5%); on the other hand, on my bigger laptop, with a rather large screen, the articles appear as a relatively narrow central column while the left and right sidebars lateral white bands appear quite wide (about 25-50-25%). Æo (talk) 01:10, 1 February 2023 (UTC) — Amended.--Æo (talk) 01:49, 1 February 2023 (UTC)[reply]
You can easily hide the sidebars because of that, and I'm pretty sure sidebars hidden was the default though that might have changed. I do agree that it impacts realtime preview but I think it's alright since you don't need to reference the article layout most of the time, you just look at the table formatting and text formatting, and maybe picture size but at least I don't usually reference the layout. When I do I use the full preview. At least the max width toggle's there. God I can't speak well today. Aaron Liu (talk) 01:42, 1 February 2023 (UTC)[reply]
By "sidebars" in my previous comment I did not mean the sticky ToC and toolbar, but the empty white bands. Æo (talk) 01:45, 1 February 2023 (UTC)[reply]
Like, what is this?
Vector 2022, logged-in, 4K display
The white space is insane. Cessaune [talk] 02:05, 1 February 2023 (UTC)[reply]
Yes, on my big laptop it is exactly like this. Æo (talk) 14:52, 1 February 2023 (UTC)[reply]
The issue is that hiding it is a weak solution. I like the TOC idea, as long as there is a TOC at the top if I choose to hide the left one, but there isn't, so there is no other way to access the TOC. I absolutely despise the right sidebar, due to the massively unnecessary amount of white, but I find it necessary as a tool so hiding it really isn't a solution. Basically, you have to remove functionality to improve layout, which is, generally speaking, bad. Cessaune [talk] 01:52, 1 February 2023 (UTC)[reply]
Not sure what you mean by there isn't a TOC. It's still accessible if you click the next to the page title. —Tenryuu 🐲 ( 💬 • 📝 ) 05:59, 1 February 2023 (UTC)[reply]
Yes, but it's hiddden behind a dropdown it doesn't have to be hidden behind, and honestly shouldn't be hidden behind, as it kinda defeats the point of floating the TOC (and it looks like a link to a settings page as opposed to the TOC so users unfamiliar with V22 might get confused if they click [hide] and then are unable to find the TOC, which happened to me in V22 preliminary testing a while back). I personally like the floating TOC but not at the cost of that much width. Cessaune [talk] 07:13, 1 February 2023 (UTC)[reply]
Seems this is where we disagree; sometimes the number of headings goes past a certain point where I have to scroll up and down to find where I am, and there are times where I don't need to constantly have the TOC in view. What would be nice is to give a tooltip that lets users know it is the TOC, and a shortcut key combination to quickly open it. —Tenryuu 🐲 ( 💬 • 📝 ) 07:35, 1 February 2023 (UTC)[reply]
Actually, I feel like we basically agree. Personally I think there is a better way to implement the floating TOC (hovering over the edge of the screen, perhaps) than simply hiding it in a dropdown. A keyboard shortcut would work well. Cessaune [talk] 14:30, 1 February 2023 (UTC)[reply]
@Aaron Liu Look, I understand that you like the new skin. Fine. Use it. But it's really the height of arrogance to insist that everyone share your opinion. I absolutely hate the new skin. I don't see a single redeeming feature about it. I do not like it.
Just give us back the 2010 skin. Stop this gaslighting campaign to try and make us all like the 2022 skin. It's not going to happen. I hate it and I'm not going to change my mind. Just give me back the 2010 skin as an option so I can continue to use Wikipedia in peace. This is a completely reasonable request. Other sites have done similar. Reddit did it with old.reddit.com. It's clearly technically possible. Let's get it done. 2600:1700:1471:2550:59D3:9D9E:3973:51D1 (talk) 23:21, 2 February 2023 (UTC)[reply]
I fail to see how I am insisting that everyone share my opinion. If you're talking about how I'm inquiring about the negative aspects and trying to argue about features this is a discussion and it's normal to discuss in RfCs.
I don't think I'm gaslighting, I have never tried to convince people that their sensors are acting up. By this logic I can say that you're trying to "gaslight" me into backing away and insisting that everyone share your opinion.
Also I am in no position at WMF and unable to double up the cache. Aaron Liu (talk) 00:35, 3 February 2023 (UTC)[reply]
@Aaron Liu You wrote "Again I fail to understand how any of the changes you listed are problems" which sure sounds a lot like "it's not a problem for me, ergo it's not a problem at large". If I'm misinterpreting you, then please correct me. I'm just trying to get this issue resolved. I use Wikipedia all the time. Many, many people do. It's a vitally important resource. Which is why this is so exasperating having the site so degraded. I was not personally suggesting that you fix Wikipedia, it as poorly worded but I meant that to the community at large. Other sites like Reddit have provided options for users who are not happy with the redesign. So I'm not buying the story that it's not technically possible. old.reddit.com proves otherwise. Let's get 2010 rolled out for everyone - logged in and anonymous - as an alternative to 2022. That makes the most people possible happy. 2600:1700:1471:2550:59D3:9D9E:3973:51D1 (talk) 03:11, 3 February 2023 (UTC)[reply]
It was more like asking why it is a problem, ie the reason they consider it a problem Aaron Liu (talk) 12:52, 3 February 2023 (UTC)[reply]
2600:1700:1471:2550:59D3:9D9E:3973:51D1, there's a difference between "technically possible" and "technically plausible". — Qwerfjkltalk 10:18, 4 February 2023 (UTC)[reply]
yeah, the fact you can't recognize your own blatant arrogance when saying stuff like "Again I fail to understand how any of the changes you listed are problems" from your ivory tower is the real issue here.. if WMF would put someone even slightly less biased than you, this discussion could actually be fruitful.. but no, you keep defending this mess like it's your child.. you make this entire process look like the absolute joke it is! Holundiman (talk) 13:33, 4 February 2023 (UTC)[reply]
hey "aaron" why are you always so defensive and hellbent on defending this trainwreck of a redesign? do you have stakes in it, where you part of the redesign? if so, there's no way you should be involved in lobbying for this mess and constantly downplaying valid criticism about Vector 2022! Holundiman (talk) 13:28, 4 February 2023 (UTC)[reply]
IMHO they should have been focused on Timeless. Really really focused on Timeless. It was the most polished skin that did not have all of these same problems at the same level as Vector 2022. Responsive design? Check. Non-sticky table-of-contents? Check. Consistent width from page to page? Check. Non-wasteland sidebar? Check. Sticky header with easy-to-access search and notifications? Check. Next time, please don't reinvent the wheel. Aasim - Herrscher of Wikis ❄️ 23:27, 31 January 2023 (UTC)[reply]
If you feel so strongly about this why not make an account? Garuda3 (talk) 20:01, 1 February 2023 (UTC)[reply]
That really isn't an argument; the opinions of readers without accounts are valid too. Especially since the change was ostensibly made for them. The WordsmithTalk to me 20:18, 1 February 2023 (UTC)[reply]
@SGrabarczuk (WMF), @ OVasileva (WMF) I only hope you don't think, that solving the page width problem invalidates most of the votes against Vector 2022, and you will not come once again to the conclusion, that you've reached "consensus". Freja Draco (talk) 22:09, 31 January 2023 (UTC)[reply]
Indeed, I don't think theirs is a correct practice given the ongoing RfC. They should simply restore V2010, rework the new interface and then possibly re-propose it to the community when and if all the highlighted problems have been resolved. Æo (talk) 22:39, 31 January 2023 (UTC)[reply]
They should simply restore V2010 Based on what? there isn't consensus to restore either. I think we should wait and see. Aaron Liu (talk) 23:29, 31 January 2023 (UTC)[reply]
As of today, 60% of the comments support rollback, even despite the email outreach disclosed above. While RfCs are not votings, and the merit of each single comment takes precedence over their overall number, 60% means an absolute majority of Wikipedia users. Æo (talk) 00:35, 1 February 2023 (UTC)[reply]
@Æo, what do you mean by an absolute majority? — Qwerfjkltalk 08:18, 1 February 2023 (UTC)[reply]
@Qwerfjkl: Absolute majority means more than 50%. Æo (talk) 14:42, 1 February 2023 (UTC)[reply]
Ah, just like a majority. — Qwerfjkltalk 14:49, 1 February 2023 (UTC)[reply]
@Qwerfjkl: Not exactly. If you have 40% + 30% + 30%, assuming that those two 30% represent two completely different things, that 40% is a relative majority, not an absolute majority. Æo (talk) 14:59, 1 February 2023 (UTC)[reply]
@Æo, but we do have a relative majority as well. — Qwerfjkltalk 15:34, 1 February 2023 (UTC)[reply]
Well, of course. By the definitions used above, all absolute majorities must also be relative majorities. The point is that an absolute majority is more signifiant. small jars tc 18:06, 2 February 2023 (UTC)[reply]
@SmallJarsWithGreenLabels, not when there are only 2 options (and a very small number of neutrals). — Qwerfjkltalk 19:06, 2 February 2023 (UTC)[reply]
@Qwerfjkl: The small number of neutral responses is part of why we can call the majority absolute, i.e., adding more neutrals would push it into a relative majority, so your point doesn't make sense. It's kindof like saying books shouldn't have blurbs because all the information can be found between the covers. I don't think it matters much when this isn't a vote, but it seems like you have missed Æo's point here. small jars tc 19:40, 2 February 2023 (UTC)[reply]
@Aaron Liu At least based on the fact that Vector 2022 was forced against the opinion of most of the testers and the community voting. Let's remind: 60 responses reported the old experience as easier to use (...) 37 respondents reported that they find the new skin easier to use They added positive and neutral opinions to get 6.4/10 "majority" to force skin change. https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Repository/Sentiment_Survey The same situation was in "Requests for comment/Deployment of Vector (2022)" 154 votes for and 162 votes against new skin https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_%282022%29 And here again currently we have 275 votest for roll back to Vector 2010 and 200 votes for Vector 2022 Freja Draco (talk) 01:53, 1 February 2023 (UTC)[reply]
The first link infuriates me. "Issues with current experimental setup" refers to uneven sampling of target audiences, which is fine, but then it goes on to define the main target audience as new readers and editors. What? Shouldn't the main target audience be all users of Wikipedia, not a specific group of users? It annoys me that the logic was well, if you don't like it, you can always switch back when the logic should've been how can we make everyone like it, but WMF is doing better on that front.
Does a link to the actual survey exist? I remember responding to it, but I don't know where to find it. I want to verify that what WMF said was actually an unbiased reading of the survey. Cessaune [talk] 02:18, 1 February 2023 (UTC)[reply]
there *LITERALLY* is consensus, because well over 50% of people voted against V2022.. despite your guys best efforts to skew the results in your favour, how embarrasing.. Holundiman (talk) 13:34, 4 February 2023 (UTC)[reply]
Kindly see WP:CONSENSUS for how consensus is achieved on Wikipedia, and tone down the incivility. —Tenryuu 🐲 ( 💬 • 📝 ) 14:16, 4 February 2023 (UTC)[reply]
@OVasileva (WMF), I clicked on today's featured article, Space Shuttle Columbia disaster, and the little featured star is blocking the coordinates beneath it partially. Might just be me, though? Also, thank you for this Zoom meeting. I'm excited to be able to talk with WMF directly! Cessaune [talk] 00:50, 1 February 2023 (UTC)[reply]
@Cessaune, no, that occurs with me as well. I believe there was an earlier discussion about this, and having a new special place for things like the coördinates. — Qwerfjkltalk 08:21, 1 February 2023 (UTC)[reply]
  • As others here, I think WMF only seeks to fix (?) that buggy implementation of the full-width toggle in order to proprerly put a "happy ending" to the previous RFC, not to recognize their big slip. The good news is: if they successfully achieve a method to make the setting persistent for every non-logged user finally, then they'll have no excuse to put a «Revert to classic Wikipedia» (or whoever it is called) option in Main Page for everyone, and save the setting. And then, they'll can collect metrics and publish them, if they dare. Note that in their listing of future uses for that persistence (I quote: «we might want to work on in the future such as font size, keeping the sidebar open, or dark mode») there is no «Revert to...» case, so it is a clue that they don't have in mind to regret of, and still forcing casual readers and IP editors into using the new skin. If they finally put a persistent «Revert to...» option in the Main Page for everyone, letting people to choose freely, all this obvious no-consensus (and may be this very RFC also) will over. Any vote? 37.134.90.176 (talk) 08:37, 1 February 2023 (UTC)[reply]
  • Really appreciate this. I believe this wasn't trivial technically, so thanks a lot to people who worked on this. With this change, we are getting close to meeting the conditions set out at the previous RfC. Femke (alt) (talk) 09:03, 1 February 2023 (UTC)[reply]
No, it's not true. They said: If the community decides against deploying the skin, no deployment will be made. And next they ignored decision of community. Freja Draco (talk) 13:57, 1 February 2023 (UTC)[reply]
@Freja Draco, from the closure: 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.— Qwerfjkltalk 14:51, 1 February 2023 (UTC)[reply]
is it possible to have a persistent vector skin toggle? 103.62.153.150 (talk) 11:09, 2 February 2023 (UTC)[reply]
103.62.153.150, yes. It should happen soon. — Qwerfjkltalk 17:10, 2 February 2023 (UTC)[reply]
thank goodness! loading pages twice due to adding ?useskin=vector is getting tedious. 103.62.153.157 (talk) 05:41, 9 February 2023 (UTC)[reply]
The button for increasing the width requires JavaScript. No alternative is (as far as I can tell) available for users who are not running JavaScript. This is yet another thing that needs to be fixed. Users should not have to use JavaScript. 2600:1700:1471:2550:21B6:FBB3:C22B:B099 (talk) 06:18, 4 February 2023 (UTC)[reply]
I agree, maybe the "Enable limited width mode" toggle in preferences can somehow be made available for IPs. Does anyone know if this is easily possible without JavaScript? Aaron Liu (talk) 15:16, 4 February 2023 (UTC)[reply]

Login button now to appear outside of menu for logged-out users

[edit]

Hello everyone. Thank you for your continued feedback! We wanted to update you all on another change the team is currently working on based on what we've been hearing.

Since the deployment, based on your feedback, we have changed the threshold for the width of the pages at which the toggle is available on and made the toggle persistent across pages to all logged-out users (read more), deployed the new page tools menu and made post-deployment fixes and concerns (read more), and addressed some smaller bugs and issues.

In a few days, we will be updating with some suggestions for changes to the table of contents styling and behavior, as well as continuing the conversation on the visual separation between menus and sidebars, and the page content. We will also publish some of our initial data on skin usage and opt-outs.

Since the rollout of the new skin, we have read a lot of comments about the new location of the login button. Initially, we had placed the login button behind a menu so that we can draw attention to the account creation workflow, and because logging in is a fairly infrequent action. However, due to current issues with the global authentication system (which requires people to log in more frequently than expected), as well as the number of concerns we're heard here and on the Technical Village Pump, we've revisited this and moved the log-in button outside of the collapsed menu and as a link on the page itself, as in the Vector legacy skin.

This means that now the login button will return to being accessible with just one click.

A before and after comparison of the login button change
A before and after comparison of the login button change

We hope to have the button available across wikis next week, which means we plan to have the change here on English Wikipedia available by next Thursday, February 9.

Ping @Chipmunkdavis, Nosebagbear, Useight, Aaron Liu, Wiki-Ed, Pythoncoder, Schlosser67, KnowledgeablePersona, Sweet6970, The wub, Xx78900, Sdkb, Tenryuu, and IWantTheOldInterfaceBack. As with our previous update, we apologize for not pinging anyone else that has directly requested this.

Over the coming weeks we will continue posting updates on the change based on what we're hearing from this and other conversations across the wiki. Thanks again! OVasileva (WMF), SGrabarczuk (WMF) (talk) 19:20, 2 February 2023 (UTC)[reply]

Question: in responsive mode will the button be pushed back under the user account dropdown when the screen width gets very narrow? Aasim - Herrscher of Wikis ❄️ 19:25, 2 February 2023 (UTC)[reply]
Hey @Awesome Aasim, thanks for asking. When there's no longer space for it, yes, it will.
Oh, I forgot to remind everyone who's interested:
We also encourage you to bring your thoughts to our next office hours: today, February 2 at 20:00 UTC. This is in 10–15 minutes. Click here to join / dial by your location. We will be reviewing and discussing different requests so far, and answering general questions about the skin. SGrabarczuk (WMF) (talk) 19:54, 2 February 2023 (UTC)[reply]
This is good, thanks. Frogging101 (talk) 19:58, 2 February 2023 (UTC)[reply]
However, I still implore you to restore the inline table of contents. I won't restate the reasons, but look at Wikipedia:Requests for comment/Rollback of Vector 2022#Bring back the TOC. The floating TOC is a good feature, but it's not a replacement for the inline TOC. Frogging101 (talk) 16:34, 3 February 2023 (UTC)[reply]
I agree. It is interesting that even many of those who have voted "oppose" to the rollback still would like to see the classic ToC restored. Æo (talk) 16:37, 3 February 2023 (UTC)[reply]
My interpretation of many comments in both the "support" and "oppose" categories is an expression that Vector 2022 can stay, but they want certain things changed first. I commented under "support" because I support a rollback of the skin if they refuse to budge on certain design choices that I consider regressive. But I don't categorically dislike the new skin; I support keeping it if certain things are fixed. Frogging101 (talk) 19:00, 3 February 2023 (UTC)[reply]
I think the same. While I like some features of V2022 (namely the logos and the colours), some other design choices, namely the ToC, the hidden toolbar, the languages bar, and the absence of lines distinguishing between the space of the article and the space of the user, are in my opinion regressions (and mobile-ising choices) which compromise my (and I think others') whole experience on Wikipedia. Æo (talk) 20:29, 3 February 2023 (UTC)[reply]
Delighted to see this, thanks for the update. Xx78900 (talk) 20:45, 2 February 2023 (UTC)[reply]
This is a step in the right direction. —pythoncoder (talk | contribs) 21:56, 2 February 2023 (UTC)[reply]
Thank you for putting the login "button" back where it should be. In my experience, logging in really is not such an "infrequent action" - after all, you need to do it every time you are on another computer that isn't yours, e.g. in a library, or if you cannot save cookies for any reason. --Schlosser67 (talk) 11:10, 3 February 2023 (UTC)[reply]
Thank you :) At least one step in the right direction and an announcement of more. I'll wait for it. In addition to the ones listed above, return the full-sized TOC at the beginning of the article, and don't hide the language list on the big screen, and the new skin will become usable. Freja Draco (talk) 12:20, 3 February 2023 (UTC)[reply]

Summary of work so far and next steps

[edit]

Hi everyone,

I wanted to give you another update with our data, the work we are currently focusing on, and provide a quick summary of our take on this discussion so far.  Firstly, though, I wanted to sincerely thank you for the time you have taken and your engagement here.  It's great to know how many of you care deeply about the user experience here on English Wikipedia, both for our editors as well as for our readers.  Thank you all for your continued commitment to improving our interfaces into the future.

To make it easier to navigate within the update, we've used two icons. 🆕 introduces new information, and ⍰ introduces requests for feedback.

The objectives for the project

[edit]

I know many of you have heard these aspects, but I just wanted to review the two objectives of the Vector 2022 skin.

  1. The first was to make the interface more welcoming and comfortable for readers and new users so that more of the world can easily access the free knowledge.  Many readers did not understand how the site was structured, newcomers had problems accessing important tools, the site was difficult to read and process, and the previous skin did not follow accessibility standards and guidelines.  So the new skin tackles known usability and readability issues. It also takes inspiration from customizations, gadgets, scripts, volunteer-built skins that individuals were making to the site, for example gadgets making the sidebar collapsible. If you'd like to learn more about the disadvantages of the previous skin, see the reports here.
  2. The other goal was to keep the interface equally useful for advanced users on desktop.  To do this, we ran five rounds of prototype testing with editors, brought questions and conversations here on-wiki, and ran office hours to make sure that active volunteers had the opportunity to speak to us directly.  These efforts led us to building, targeted testing, and adapting some of the features to make the skin better for advanced users as well.
Examples how we've been working to achieve the second goal
  1. For example, when testing the new table of contents, we found that our data model predicted 53% more clicks on new ToC compared to the old one with logged-in users. The trend is consistent among all edit count buckets.  Thus, while the new ToC was designed to be more useful for non-advanced users, it is more used by advanced logged-in users, too.
  2. Another example (I'll add more details below): the sticky header functionality was designed specifically for editors.  It allows access to commonly used tools throughout the interface.  With the new sticky header, logged-in users scroll to the top of the page in order to use tools there 15% less than before.  The edits they begin from the sticky header are also completed more frequently, and less likely to be reverted, than edits started from anywhere else in the page.

Over the past few weeks, we've begun making even more changes towards this goal, based on the conversations here, on Phabricator, and elsewhere on-wiki.  We plan to continue these conversations and to improve the skin to make sure we're covering all use cases. We are still want to hear thoughts on how we may keep the "advanced workbench" usable without compromising the utility of a "library desk".  (Thanks to @Freja Draco for suggesting the workbench metaphor.)

Data

[edit]

Explore our results

[edit]

I've seen that some of you have been interested in our data recently, so I've added links below to our analysis.  In the sections with detailed explanations, I've also provided links for each analysis of the queries themselves, where permitted.  We welcome you to explore the data, look through the results, and ask us any questions!

Overview on the previously learned lessons

[edit]
Previously known statistics

Early adopter wikis and all wikis

The data we collected in our early adopter wikis indicates that the Vector 2022 skin achieved these objectives and performed better overall when compared to the Vector legacy skin for readers and new editors, and in specific cases, for long-term editors and community members as well.

We are making this conclusion based on the following data (these are the same results many of you have seen us post before, but we're reviewing them again here):

  • After at least 9 months after the deployment, on average, 87% of active logged-in users on the early adopter communities (incl. French Wikipedia) continued to use the new skin. (Source)
  • The sticky header makes it quicker to access tools that editors use often. It decreases scrolling to the top of the page by 15%. (Source)
  • The edit button within the sticky header shows that people are more likely to complete the edits they start using the sticky header and that edits that were completed using the sticky header are less likely to be reverted. (Source)
  • The new table of contents increases navigation to different sections. Our A/B test showed that, compared to the old ToC, we saw 53% more clicks on new ToC with logged-in users and 45.5% more clicks on new ToC with unregistered users. The trend is consistent among all edit count buckets in logged-in users. (Source)
  • 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 28.9% on the wikis where tests were performed. (Source)
  • PHP code in Wikimedia deployed skins has been reduced by 75%. (Source)
  • 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 (see below for findings and graphs).
  • The new features of the skin were well-received in usability testing among readers and editors (Source)

More information about our findings and process can be found on this page.

English Wikipedia

On English Wikipedia:

  • About a week before the deployment, the skin was the most popular non-default skin, with more editors using it than MonoBook, Timeless, or any other non-default skin.  (Source)
  • It was tested qualitatively across five different rounds of prototypes, as well as with readers in different English-speaking countries.  (Source)
  • The performance of the site has improved from the Vector legacy skin, meaning that pages load faster.  (Source)

Post-deployment data on English Wikipedia

[edit]

Since the deployment, we have been studying the metrics above here on English Wikipedia, and validating that the skin is bringing these improvements to people here as well.  As we mentioned in our previous post and prior to deployment, we use specific targets to ensure whether a particular result is successful, and when a result might lead to iteration or require significant change.

🆕Based on what we've measured so far, user behavior, overall, is similar to what we saw on our pilot wikis, and the skin so far is generally behaving as expected, meeting these targets, and achieving its initial objectives. We will be continuing to evaluate it in an ongoing way, though.

🆕Pageviews

[edit]

Pageviews show whether the overall readership of the site is growing or declining.  Generally, it is difficult to establish immediate improvements to pageviews with a single change, which is why we are using our pageviews data to ensure that none of the changes have affected pageviews negatively.  Over a long period of time, we expect that the new skin will increase pageviews, especially with readers who had readability issues with using the previous skin. Some of you have mentioned that the skin can improve on its readability further, specifically in relation to the blocking the content area from the navigation, or through additional improvements to the table of contents – more on that below.  

Metric Findings Original target Target met Learn more
Pageviews We have not seen any significant shifts in pageviews due to the deployment of the Vector 2022 skin Less than 5% decrease in pageviews attributed to the change ✅ T327440#8542723

🆕Edits

[edit]

Edit rates, or the total number of edits, show the general state of editing across the wikis.  A significant decrease in edit rates would indicate usability issues or other concerns in editing, readability, or contribution overall.  

Metric Findings Original target Target met Learn more
Edits We have not seen any significant shifts in edits due to the deployment of the Vector 2022 skin Less than 5% decrease in edit rates attributed to the change ✅ T327440#8542723

🆕Account creation

[edit]
Account creations before and after the Vector 2022 deployment on English Wikipedia

"Account creation" is what we refer to when a reader or editor creates a username and password.  In our research, we saw that many readers (who could become editors and join the communities) were not aware that they could have an account on Wikimedia wikis in the first place.  To respond to this, we made the create account link more prominent on the interface. In this sense, a slight increase in account creations was desired.

In addition to that, some readers create accounts for the single purpose of setting up different preferences.  We have been calling this group "account holders". We  expected that some readers who were not happy with the new skin would become account holders in order to switch back to the Vector legacy skin.

We saw a spike in account creations in the days after the January 18 deployment, and we believe that these account holders who wanted to change their skin were the main contributors.  Overall, this was a fairly small percentage of all users who visited the site (to get an idea of the scale, the ratio of accounts created to pageviews on January 19th, the day with the largest spike, was 0.000009375).  Since then, account creation has generally settled back into its usual pattern, though it may remain somewhat elevated because of the increased prominence of the "Create Account" button.  Over the course of the four days of the main spike, we estimate that roughly 20,000 to 25,000 additional accounts were created during the spike in account creation, or, roughly, the same number of accounts we would see in one to one and a half weeks of usual traffic.

Metric Findings Original target Target met Learn more
Account creation We have seen a spike in account creation immediately after deployment, followed by a return to regular account creation patterns No significant decrease attributed to change ✅ T328609  

We did some further analysis to learn more about whether account holders were creating accounts specifically to turn off the new skin.  We saw the following:

  • On 2023-01-21 (the first three days after the deployment, cumulative), among all the account holders who registered after the deployment, 64% used the Vector 2022 skin, and 34% used the Vector legacy skin
  • On 2023-02-01 (12 days after the deployment, cumulative), among all the account holders who registered after the deployment, 94% of used the Vector 2022 skin and 6% used the Vector legacy skin

Our analysis of this is that during the first three days after deployment, around 34% of users created accounts specifically to turn off the new skin.  During the first two weeks after the deployment, 6% of users created accounts specifically to turn off the new skin.  During this time period, there was (and still is) a bolded opt-out link in the sidebar, and there was also a CentralNotice banner informing people on how to turn off the new skin, which ran from Jan 18th to Jan 23.  

We will continue to track these metrics into the future.

This leads us to the conclusion that, overall, some accounts were created with the purpose of turning off the skin, concentrated in the days immediately after the deployment.  It looks like these were about 6% of all created accounts since deployment.  The large majority of new accounts use the Vector 2022 skin.  

🆕Opt-out rates

[edit]
Skin selection of active editors on English Wikipedia

It's important for us that the new skin is used by the majority of logged-in users in addition to logged-out users.  This introduces a consistent experience and ensures that article layout choices are made with the consideration of what most people will see.  

However, we also wanted to make sure that it is easy for anyone who wants to opt out to find a way to do so.  To make sure of this, we:

  • added the "switch to old look" link in the sidebar, and bolded it so that it was the most prominent link in the sidebar, and
  • ran banners to 100% of logged-in users which directed them to a page with instructions on how to opt-out.

The opt-out rate around which we set our targets is the rate amongst "active editors".  These are editors who have made at least five edits in the past calendar year (in these metrics below, that would be from January 2022 to January 2023).  We're reporting on that target below, but in the following table, we also report on a few other ways to look at those numbers.  An important one is "recent active editors" – these are editors who have made at least five edits since the deployment of Vector 2022, meaning they are the editors who have encountered the new skin during their activity on wiki.  Though the share of these editors who have opted out is higher, the majority of these recent active editors have left the Vector 2022 on by default.  We also see a larger portion of these editors using the Monobook skin and other skins, indicating that they have not made any change in their skin preference (since the Vector 2022 deployment only affected users of the Vector skin.  

Metric Findings Original target Target met Learn more
Opt-out rates Usage of the Vector 2022 skin is 88.12% of active editors[editors 1] (our target metric). More than 60% of active editors will use the Vector 2022 skin ✅ T328088

T328088#8573021

Usage of the Vector legacy skin is 8.15% of active editors[editors 1] (our target metric).

We've also measured opt-out rates for the following segments of users:

Less than 40% of active users will use the Vector legacy skin ✅
  1. ^ a b Editors who have made at least five edits in the past calendar year (from January 2022 to January 2023)
  2. ^ Editors who have made at least one edit in the past calendar year (from January 2022 to January 2023)
  3. ^ Editors who have made at least one edit since the deployment
  4. ^ Editors who have made at least five edits since the deployment

Overall, most opt-outs occurred immediately after the deployment of the skin.  As with account creation, we are seeing opt-outs slow with time after the deployment, indicating that most editors have already made their choice of skin.  MonoBook users, and users of other non-default skins were not affected by the change. As the trend in the graph below is consistently decreasing, with no subsequent spikes after the deployment, we do not expect the opt-out numbers to change significantly over time, but we will continue monitoring and publish the results for one to two months after the change.  

A graph of the number of times people have opted out of the skin (note: some users might have opted out and opted back in numerous times)

🆕Upcoming analysis

[edit]

We are still analyzing feature-level data for English Wikipedia, which will compare use of specific functionality and overall metrics before and after the introduction of the new skin.  Over the next few weeks, we hope to publish data on:

  • Effects of the Vector 2022 skin on session length
  • Usage of the Table of Contents
  • Usage of the new search functionality
  • Usage of the sticky header
  • Usage of the fixed with toggle
    • Our initial analysis on the toggle indicated that most users who expand the width once, later proceed to collapse it, indicating a preference for the limited width of the page when compared to the full width.  However, this data was gathered prior to the introduction of the persistence for the toggle.  We are re-running our analysis to validate the initial conclusion and to measure whether it has changed after toggle persistence for logged-out users was introduced. We will publish this data once this check is completed. (Source)

🆕Summary of concerns we've heard so far

[edit]

Over the past few weeks, we have also been busy classifying and addressing the issues brought up in this RfC by reviewing individual comments and clustering them to get a better understanding of what we can make better.  Based on this, we have seen the following breakdown of the top 10 most frequently mentioned concerns:

Most common concerns

Concern Percentage of comments which mention this concern
White space and content separation/ Desktop feeling like mobile 26%
Deployment process and communication 17%
Unregistered users cannot opt-out/only logged-in users have preferences 15%
The skin needs more feedback from readers and the community 14%
Content width is too narrow 14%
Menus require extra clicks to open 8%
There were no significant problems with the Vector 2010 skin 8%
Table of Contents issues 4%
Use of icons 4%
Language Switching 2%

How the team is addressing these concerns

[edit]

🆕Track our progress

[edit]

We have begun collecting and addressing these concerns, implemented initial changes, and are also planning to implement further changes on the concerns we find actionable.  Below is a summary of our progress, but if you're interested in tracking it in detail, you can see these Phabricator boards:

Note: Currently scheduled future work might change in priority based on the team's capacity, technical feasibility, and as a result of things we learn through various conversations here, on the technical Village Pump, across other language and project communities, and in office hours.  A specific thank you to @ferret and @Femke for their participation in our office hours, and for drawing our attention to accessibility for neurodivergent users.  Your thoughts and constructive criticism have truly helped us with the conversation around content separation and white space.  

White space, readability, and dark mode

[edit]
  1. Problem with Legacy Vector: Reading Wikipedia in the Vector legacy skin was difficult for the majority of readers and editors
  2. How this problem was addressed in Vector 2022: We limited the content space and structured the navigation by purpose so it is easier to understand (user links collected in one place, page tools collected in one place, global navigation collected in one place).
  3. Concerns with the current implementation:
    The main concern we are hearing is issues with the readability of the page when limited width is present.  We have separated this from concerns about how narrow the content is (see below).  What we've heard is that many of you are having issues with the contrast of the white space itself, and the lack of separation between content and navigation.  We have separated this into three areas of potential improvements:
    • Making the different regions of the interface clearer.  While we have structurally separated the different regions when compared to the Vector legacy skin, we have seen the need for stronger visual separation as well.  For example, being able to tell easily where the ToC ends and the article begins.
    • Emphasizing or de-emphasizing parts of the interface – making the content stand out more clearly.  While the current content is more readable, we can do additional work to more clearly delineate the content container as the main focus on the page.  
    • Decreasing the contrast on the page, specifically in the sidebars of the page where a significant amount of white space is present.
  4. 🆕Upcoming: We believe we can address this through the following:
    • Exploring ways to introduce lower-contrast backgrounds
    • Introducing visual separation between the content area and navigational elements such as the table of contents, or the sticky header
    Thank you to all of you that have given us direct feedback there.  We have produced this prototype which explores a number of different ways we can approach the blocking off of content and white-space reduction.  ⍰We welcome your feedback on these in this Phabricator ticket: T259240, or on this page.
    We are also exploring bringing dark mode for Vector 2022 to logged-in users, and are currently evaluating what might be possible for logged-out users.  While bringing it to everyone will take a lot of conversation and coordination with the communities (specifically around fixing pages and templates that do not currently work with the existing dark mode gadget), we are currently exploring ways we can begin this conversation together, and what we would need to do to address the technical barriers for logged-out users.  We are also aware of the related Community Wishlist Survey proposal. We are coordinating on that with the Community Tech team.

Unregistered users cannot opt-out/only logged-in users have preferences

[edit]
  1. Problem with Legacy Vector: As with Vector legacy, MonoBook, and all the previous default skins, the Vector 2022 skin does not offer unregistered or logged-out users the option of opting out.  This is due to the way that we serve our pages to logged-out users from our cache.  As of right now, we still do not have any options for allowing an entire skin to be selected by a logged-out user.  However, we are exploring the possibility of allowing feature-level settings to persist across pages for logged-out users.
  2. Changes made since deployment:
    • The main request we saw and fulfilled was for the persistence of the width toggle at the bottom of the page.  This allows users to set their preference for the width of the skin.  This toggle is now available across all users of the Vector 2022 skin.  (T327979)
    • A secondary issue was the width at which the toggle appears.  We have lowered this width so that it appears as soon as there is text available to be expanded.  (T326887)
  3. 🆕Upcoming: We will continue to explore the possibility for other configurations, such as the use of icons, font size, and dark mode.  This is a challenge, technically, so it might take us some time, but we will keep you all updated with our progress.  

Getting more feedback through surveys

[edit]
  1. Question from the community: Shouldn't there be more feedback shared via satisfaction surveys?
    We have been truly inspired to see the feedback here which requests hearing more voices from the community, as well as from readers.  We know that conversations on the Village Pump and RfCs are not representative of the thoughts of everyone who is affected, and we have focused our previous research and data collection on ensuring that this skin works for the majority of our users.
    The readership of English Wikipedia is almost a billion unique devices per month from many countries and continents of the world.  This Wikipedia also has tens of thousands of active logged-in editors each month.  In order to discover what works and doesn't work for such a large and diverse audience, we conduct qualitative and quantitative testing of different types.
    We think surveys are an important part of this: they let us see what needs we are not meeting and how people feel about specific changes.  Yet they are only one measurement of many, which needs to be considered alongside other data.  As we've discussed before, surveys need to be sampled correctly, allow for full access to the interface over an entire session, or an even more extended period of time (what is generally known as a journal study).  Without this, there's a risk that those who choose to chime in are not representative of most users with their diversity.  There's also a risk of misalignment between what people declare and what they actually do.  
    With all of that said, we do believe that surveys are useful and important, and a good way for us to flag concerns, and plan on continuing to survey our readers and editors on their satisfaction with the skin.  
  2. 🆕Upcoming: We are working with our design research team and WMF researchers to design a survey of logged-out readers on their experience with the skin so far.  We hope to start this survey within the next calendar month.

Text width

[edit]
  1. Problem with Legacy Vector: Reading Wikipedia in the Vector legacy skin was difficult for the majority of readers and editors
  2. How this problem was addressed in Vector 2022:
    The new width was set to improve readability and ensure we are following best practices and accessibility standards.  Our previous width made it difficult for the majority of users to read the site, and to retain the information they have read.  
    We limited the content space to follow existing research, as well as to be closer to (but still wider than) WCAG accessibility guidelines of 80 characters per line.  This change makes it faster to read, but also to retain content.  Previously, our text, on a browser window of 1280px (roughly a 13-inch monitor) was approximately 170 characters per line, more than double the recommended length for accessibility.  On a browser window of 1920px (the second most-popular size amongst our users), text was at approximately 262 characters per line, more than triple the accessibility guideline of 80 characters.  
    That said, we understand that different users might have different preferences for text width, depending on their context.  
    During the first RfC on the skin, we noted that the main concern was the inability to revert back to the full width for users who felt more comfortable reading in full width.  We have since built a toggle which allows logged-in and logged-out editors to set this width.  Since the deployment, we've made some changes to this toggle to make it easier to use.  
  3. Changes made since deployment:
    • Ensuring that the toggle which increases the width is available across pages for logged-out and logged-in users (T327979)
    • Lowering the width at which the toggle appears, so that it can be used with smaller screens and monitors (T326887)

Opening menus requires an additional click

[edit]
  1. Problem with Legacy Vector: Readers and new editors did not understand what links in our navigation elements were for, and they were unlikely to use them to explore the site further or to learn more about editing.
  2. How this problem was addressed in Vector 2022:
    One of the main goals of the project was to introduce a logical hierarchy within our navigation.  In our research, we saw that users did not understand individual navigational elements and the ways they were connected to the page overall.  This included not understanding the difference between the user links at the top of the page and the links contained within the main menu.  It also included difficulty in determining which links within menus work on the site as a whole (global navigation) and which work on the individual pages (local navigation) as these were not previously separated.  The introduction of individual menus: the user menu, the main menu, and the page menu, was done to clearly delineate these different sections, to help readers and newcomers understand what each link does, and ultimately, to allow them to explore areas of the site they had previously been afraid or unlikely to interact with.
    While we know editors might spend extra time opening menus due to the additional click, we tried to offset this by saving them time in other places.  For example:
    • While the language button now requires a click to view the list of languages, it no longer requires you to scroll down the page in order to reach languages, saving time in scrolling.
    • The new sticky header allows for easy access to commonly used tools and decreases scrolling to the top of the page in order to use these tools by 15%.
    We are also working on improving the menus, and moving important links outside of menus when relevant.
  3. Changes made since deployment:
    • Deploying the new page tools menu.  This menu adds page-specific tools to the right side of the page.  It is available in both a collapsed as well as persistent state.  The persistent/uncollapsed state is the default (T302073).
    • 🆕Moving the log-in link outside of the collapsed menu for logged-out users.  This will make it quicker to reach the log-in link.  This change will be available Thursday, February 16 (T289212).
  4. 🆕Upcoming: Making the new page tools menu persistent while scrolling (T318169).  This change will be available Thursday, February 16.

Issues with the Table of Contents

[edit]
  1. Problem with Legacy Vector: Readers and editors were unable to gain overall context about the page they were reading from anywhere in the page.  This caused them to explore our pages less overall.  
  2. How this problem was addressed in Vector 2022:
    The new table of contents is one of the main changes in the site.  It introduces a table of contents which is persistent while scrolling.  This persistence allows readers and editors to gain context on the article they are reading throughout the reading experience, rather than only at the top of the page.  It also reduces scrolling to the top of the page and encourages users to explore more individual sections.  This change has had the biggest impact on logged-in users, who have increased their use of the ToC by 53%.  This impact was seen throughout edit buckets, meaning that both new editors and veteran editors were using the new ToC in a similar way and with similar frequency.  Logged-out users used the new ToC 45% more frequently.
    Creating this large impact on functionality required making some tradeoffs.  The main tradeoff we made is that the new ToC is more difficult to read on less-frequently visited pages which have long headings.  To account for this, we created a collapsible version of the ToC which shows headings at their full width and is also persistent as you scroll down.  
    We have also received many other types of feedback about the smaller interactions in the table of contents from experienced editors and have begun addressing these issues to make sure that experienced users can also get the same value from the new ToC.
  3. Changes made since deployment:
    • Increased threshold for table of contents from 20 to 28.  This will allow more sections in the ToC to show by default (T328045).
    • Fixed issue with self-linking to anchors.  This will ensure links work as expected (T327467).
  4. 🆕Upcoming:
    • Increase the height of the ToC.  This will allow the ToC to appear longer, and for more sections to be visible (T319315).
    • ToC configurability.  This will allow the ToC to be configurable so that editors can determine when the ToC needs to be expanded or collapsed by default, and how many sections of the ToC can be shown by default.  This will replicate the functionality of some of the "magic words" used in the ToC.  It will be especially useful on pages like the Village Pump or Closure request pages.  A special thanks to our office hours participants who drew our attention to this issue!  (T317818)
    • Where the page lands when clicking on a ToC link (T314419).  We've heard some feedback that the ToC opens too close to the beginning of a section, without giving any space for the title and previous section.  This change will increase this space, making it more comfortable when navigating.
    • Threshold for when a section is considered active, and marked in the ToC (T317661).  We have also heard feedback that a section is considered active only after the previous section has been scrolled out of view, leading to some confusion on the active state.  This change will allow sections to be shown as active earlier, when the majority of the section is displayed on the screen.  
    • Navigating directly to sub-sections and expand the parent section if collapsed (T325086).  Some of the feedback we've heard relates to the way that subsections appear on the page.  We've heard feedback that subsections should appear more consistently when needed.  This change ensures that subsections default to open when a direct link to that subsection is followed.  

Issues with the use of icons

[edit]
  1. Problem with Legacy Vector: Text labels feel overwhelming for the majority of users, especially on a navigation-heavy site such as Wikipedia
  2. 🆕Upcoming: Here, we have been reviewing our studies on current icon usage and would like to ask for your help.  Among the readers we studied, we did not note any icons which were missing labels that were confusing.  We are open to making further changes to icons, or to adding preferences that choose between using icons or using text.  In general, we'd like to learn more about this concern.  ⍰Which icons have you personally had issues with? What, in your opinion, would be a solution that allows for quick understanding of a link or button, while also not giving too much navigational overload to readers and editors?

Exploring options for one-click language switching

[edit]
  1. Problem with Legacy Vector: Readers were not aware they could switch languages from Wikipedia.
    The new language selector was made as a response to readers and editors who were not aware that they were able to switch languages directly from the site.  These users would generally resort to using a search engine to go to the article they are reading in a different language.  Many readers, despite being bilingual, did not know Wikipedias existed in multiple languages. Due to this, we decided to make the language links more prominent in the interface.  This was another moment where we had to make a tradeoff – in this case, this tradeoff was prominence and the reduction of scrolling at the cost of one-click access to all languages.  
    Since then, we have been exploring ways to add one-click access to the new location of the language switcher, for users who want to switch languages even quicker.
  2. 🆕Upcoming: Introduce one-click access to commonly-used languages: T301787.  We're also curious to gather more feedback here.  ⍰Would this solution be helpful? How many languages do you generally need to have direct access to, and under what circumstances?  

🆕Other changes

[edit]

In addition to the list above, we're also looking into some changes based on other pieces of feedback, which we've flagged as potential improvements.  Here is some of that list.  For the full list of ongoing work, we recommend that you check our sprint boards linked above.  

  • Improving the styling of the "Edit interlanguage links" link (T328069)
  • Provide support for the Atom icon (T327717)
  • Improve gadget support for the sticky header to make it easier to inject gadgets into the sticky header (T327369)
  • Improving our automated testing so we can flag bugs and issues more quickly across all skins (T322355)
  • Reduce the height of the article toolbar so more content can be exposed on the page (T316950)
  • Improving gadget support and recommendations for gadget developers (T311891)

And more!

⍰Our questions for you

[edit]
  1. What questions or details about our data do you still have?
  2. What, in your opinion, are issues with the new skin that are not mentioned or addressed above?
  3. What thoughts do you have about the details of proposed changes above and the ways we are addressing them?

Next steps

[edit]

Thank you for reading our extremely long post! We wanted to be thorough about what we're thinking about currently, and we thought this covered the main highlights, although it's not an exhaustive list of the changes we've made and the conversations we're having right now.  If you think we've missed something from the list of immediate priorities, definitely let us know!

Will will continue working on addressing the concerns mentioned above as well so that the new skin can provide an improved experience for readers and editors, and also to cover the specific needs of those who have used the site for a long time as well.  We want to fix the issues flagged above, and focus on flagging things which might come up in the future.  Thank you again for your continued feedback and support, and we look forward to hearing your thoughts on the data and what we've proposed here! OVasileva (WMF), SGrabarczuk (WMF) (talk) 01:35, 14 February 2023 (UTC)[reply]

Thank you both, as well as any others involved in it, for compiling this report. I'll take some time to consider everything you have said before responding further, but in the meantime could you please provide information on how many editors opted in to Vector2022 prior to it being deployed, and I would like to repeat my above request for the complete anonymized results from the user survey you held last year? BilledMammal (talk) 02:29, 14 February 2023 (UTC)[reply]
@BilledMammal You can find a graph with skin stats before deployment here: Wikipedia:Vector 2022#The Vector 2022 skin on English Wikipedia. Nux (talk) 10:25, 17 February 2023 (UTC)[reply]
@Nux: Thank you, but that doesn't include the figures for Vector2010 - although I estimate total use of Vector2022 per-deployment was approximately 3%? BilledMammal (talk) 10:32, 17 February 2023 (UTC)[reply]
For obvious reasons, it's very hard to count the active users who voluntarily chose the default skin over other skins and not count these that just didn't care to take a look at the skins, user apathy is pretty big. Aaron Liu (talk) 12:34, 17 February 2023 (UTC)[reply]
It is, which is why I am asking for the number of editors who chose to use Vector2022 prior to it becoming the default - we can compare that to the number of editors who chose to use Vector2010 after Vector2022 became the default. BilledMammal (talk) 12:47, 17 February 2023 (UTC)[reply]
Is there some graph for current percentages of non-default skins? Aaron Liu (talk) 12:52, 17 February 2023 (UTC)[reply]
#🆕Opt-out_rates. The graph includes editors who have not edited since the deployment of Vector2022; the relevant figures are 15% of editors with at least one edit since the deployment having opted out, and 23% with at least five edits. I've asked for more details on how many edits by logged in editors have been made with each, and I hope they will also provide additional information on the percentage of editors with at least one hundred and five hundred edits have opted out. BilledMammal (talk) 12:59, 17 February 2023 (UTC)[reply]
I just did some calculation. It appears there is a whopping 68.91% of users with non-default skins that use v10. I calculated this by rounding the result of 8.2% divided by 11.9%, the latter of which is 100%-88.1%. Aaron Liu (talk) 13:06, 17 February 2023 (UTC)[reply]
Users that used V'22 in January are most probably only active users. That graph actually surprised me a bit as it seems many users did try out V'22 before it was deployed (contrary to some suggestions).
As for context I assume that was only for kind of active users. The graph is probably from the same as stats as on phab [34]. So that would be 2.32% of all "active" users. Active users defined as: "editors who edited on content pages at least once on the specific wiki project between 2022-01-01 and 2022-12-31." Nux (talk) 17:52, 17 February 2023 (UTC)[reply]
The graph doesn't specify active users or anything so I think it's for all users that don't use vector legacy. It's still a very big possibility that it's for active users though. Aaron Liu (talk) 20:09, 17 February 2023 (UTC)[reply]
@Aaron Liu nope. The data is the same as on Phabricator. The graph shows only users that were active in 2022 [35]. Nux (talk) 20:40, 17 February 2023 (UTC)[reply]
@OVasileva (WMF) and @SGrabarczuk (WMF), thank you for this! I'm very happy to see that progress is being made towards a solutionn that works for everybody.
I have two questions:
  1. Are you going to relesase the raw data from the opinion survey you held last year?
  2. Are you planning to change the link colors back to what they were in V2010? A lot of templates and style guides relied on the previous link color schemes, and many were centrally built with the link colors in mind.
Again, I'm very happy to see all this data. I've been asking about this for a while. Thank you! Cessaune [talk] 02:33, 14 February 2023 (UTC)[reply]
I have one more question: static TOC/ floating TOC hybrid? So many good reasons for its implementation:
  • It solves a lot of user complaints about the new TOC
  • It has all the same advantages as the new TOC
  • It keeps formatting the same for articles without TOCs (see tied island, then go to tidal island for an example)
Thanks! Cessaune [talk] 13:29, 14 February 2023 (UTC)[reply]
Hey @BilledMammal and @Cessaune - just wanted to drop a quick note here to ensure that we are not ignoring your question on the survey data. We have to be extra careful with the data we publish due to privacy, and we're currently consulting our legal team to help us interpret the privacy statement attached to the survey and what would be acceptable to publish based on that. We'll update once we learn more. OVasileva (WMF) (talk) 18:06, 14 February 2023 (UTC)[reply]
Wow, I haven’t read this yet but this looks super long, I think this would work better on a subpage. Aaron Liu (talk) 03:58, 14 February 2023 (UTC)[reply]
Thanks for this incredibly detailed update. I'm pretty unsurprised by the actual data but will second Cessaune's question about link colors! ThadeusOfNazereth(he/him)Talk to Me! 04:02, 14 February 2023 (UTC)[reply]
As a long time donator the lack of consideration for non-logged in users has greatly diminished my respect for WMF. It may not mean much, but this whole debacle has cost you at least my donations. 2404:4404:1758:400:A112:646E:A68F:5D0E (talk) 06:42, 14 February 2023 (UTC)[reply]
Regarding many of these statistics, apathy does to have been accounted for. Also that account creation graph seems oddly zoomed in and even my untrained eye sees that account creation looks overall higher than before, ignoring the spike. It regularly dipped under 3k, but has remained over 3k since. Comparing it with the same period last year as well as over a longer period would be much more useful.
Also the toggle visibility issue still has not been addressed, which might be influencing it's usage as it is in a highly isolated location from the general content, easily lost in the whitespace void.
Overall I am still quite suspicious of the metrics used, as apathy or lack of awareness are easily able to reach those thresholds I believe.
As for the prototype shown however does solve the harshness with the page background zebra #9 AND borders in place to provide obvious differentiation between content, supplementary elements, and reduce how blinding the whitespace is. The design is still quite ambiguous though, having tools bound to the right side of the screen akin to the scroll bar with the table of contents bound to the content with their own borders would give them some much needed visibility. The multiple click to reopen the side menus does hinder usability significantly as well. Also the 0 top offset still leaves really unnerving floating menus, which means it isn't really a 0 offset, and the top bar having inconsistent height as well is weird. It also misses the mark as both experimental choices are not mutually exclusive as they are portrayed, using them both at once should be perfectly viable.
Overall the design still seems highly unfinished and unresponsive.
I made a crude derivative mockup of the prototype combining elements of it with some of my own. Menus have their own background from prototype to isolate them, while the background is also in the prototype's darker shade to be less of an eyesore, table of contents placed in a manner with a touching border to the article makes if look welded to it, tools menu is bound to the edge of the screen to disconnect it from the article, and everything has the prototypes borders to make them better identifiable as separate. I'm not a notable programmer, nor am I a graphics designer. I just used video game logic and latching menu design concepts I have encountered over the years to bash something together that both looks about right and gives an intrinsic flow. This is what 0 offset should look more like. Deadoon (talk) 07:29, 14 February 2023 (UTC)[reply]
User apathy is definitely underrated. Example: my bank recently changed their website design. Their website now loads atrociously slow on my older top-of-the-range computer and (among other problems) the UI is so large that at its default size I get about three lines per screenful when viewing my bank statement. I honestly can't imagine how anyone who pays more than three bills each month could see this as an improvement. Yet I haven't put in a written complaint and neither has anyone else I've talked to about it, because we all assume it's a done deal and, knowing how much inertia banks have, we expect they surely aren't going to bother hiring new developers unless people literally start closing their accounts in droves. From the developers' POV, for all they know, they've done a great job!
BTW, I like your design. As the elements are clearly distinguished, this not only makes the whitespace less jarring, it also solves the awkward "floating" scrollbar problem with TOC and the language widget. Daß Wölf 11:33, 14 February 2023 (UTC)[reply]
I can't make claims to the general element designs in my mockup, all I did was take the https://di-content-separation.web.app/Moss prototype, combine both options and shove them in corners, and mark absolute boundaries in red. Visual separation is important, but visual connectivity is much more so. Having things directly touching makes them more obviously connected, having a thing connect to something unrelated shows disconnect. Sharing colors can show similar use cases, so even if two things are connected to different parts, having the same background links them. The distance aspect is a core issue I have with the current expand button being in such an isolated corner. Something that affects the core of the page directly was designed in such a way to seem unrelated. Deadoon (talk) 22:06, 14 February 2023 (UTC)[reply]
Apathy is my main concern as well. Even as someone who's very bothered by bad website design, it's very rare for me to create an account for sites I'm interacting with in a read-only way, even if they're actively pushing me to. I'm honestly shocked signups increased as much as they did.
I don't know how to measure this well. The best I can think of is a "which one of these do you want" interstitial page for desktop users with screenshots of each, but that's probably too annoying for not enough accuracy. ℰmi1y⧼T·C⧽ 08:02, 15 February 2023 (UTC)[reply]
---
First, please make the [?] mark in yellow background. Now it is very difficult to locate them. It is quite obvious you are not experts in graphical interfaces and/or accesibility, but also it feels like if you do not want feedback at all.
Second, I do not give you any "thank you" for you doing your job, and being it late. I do contribute for free, you do not.
Here my feedback, hope this help (believe it or not, I'm wellhearted but very critical).
  • Whitespace (both excessive and highly contrasted; see Biological effects of high-energy visible light)
    • Based on prototype, my vote is for Zebra #9 with borders and both 0px offsets. "Hamburger" button behaving as dropdrown menu is OK, so "Tools" menu should behave that way too. Full height TOC looks OK.
    • TOC and other side panels must be alligned to the top, as per Deadoon. Avoid wasted top side empty space.
    • Vertical scroll bar in Tools menu when needed (the prototype fails on this).
    • Widest possible TOC, it using all available horizontal space not covered by article. Avoid wasted rightmost side empty space. In landscape 16:9 form factor, my recommendation is 1/3 of full width viewport devoted to TOC (or alternative for non-articles) and 2/3 devoted to the content in itself (narrow or wide lines at user's taste). Responsive up to a minimum width. Take into account 4:3 and/or portait form factors, along with browser's zoom level and system's dots per inch (dpi) setting (not always 96 dpi; my case is 144 dpi).
    • The same layout for TOC-less articles. Even simple light grey empty background is OK, to avoid elements being "dancing" around. Favour consistent and coherent fixed layouts where possible (V10 proves it is always possible).
    • Tables and other large elements (as panoramic images or large graphs, to say) at full width even when text in narrow width mode.
    • "See also" section appears in only one column when in narrow text view. Many articles show more than one column when they have many "see also" entries, and editors usually decide on this at edit time. Articles with many "See also" links now are viewed as a very long, single list. When using full width text mode, columns are viewed as expected. Probably a bug. Then: make the "See also", "References", "External links" and the like independent of narrow text (as stated for tables in previous point).
    • A proposal: leftmost and rigthmost images (and infoboxes, etc.) could be put outside the narrow text column, up to the viewport sides, filling current leftmost and rightmost V22 article's empty space partially. This lowers the wasted whitespace realestate, and it gives a lesser "mobile" form factor-alike feeling. This should be responsive, and article's text should flow in its devoted narrow strip, which can be partially invaded by images and boxes. Of course, this behaviour is for narrow text mode only. Full width text do not need to take care of this.
  • Icons
    • Tooltips at least for desktop-plus-mouse users, this is a must-be. Avoid mystery meat navigation UI.
    • Better if icons with text below (example: AirBnB app icons), as no every glyph is obvious for everyone.
    • Still, I think there is an over-abuse of icons in V22, they making less relevant other visual icons as featured article star, good article mark, geographical/celestial coordinates, protected article, and the like.
  • Languages
    • Alphabetically orderer languages as always, at least be a toggled option (that is, the possibilty to toggle between alphabetical/geographical).
    • In T301787 demos, my vote is for the mockup #2 ("language toolbar below page title"; you should give them numbers, to short and clarify). For sure, to restrict it to only two/three "main" guessed languages or the like (mockup #1) will not satisfy everybody. Burn #3 in the stake.
    • How I use languages: I'm not a native English speaker, but I like English encyclopedia the most due to its completeness and (almost) NPOV, as well as to practice myself in reading/writting in English, so I almost never read my own native language WP. But sometimes, some topics I'm interested in are not fully covered in English articles, specially when they are topics of local interest, as geographical features or locally relevant people or groups (let's say, a rock band). Then I go to the most probably language(s) I think the topic is best covered, to find the info I am looking for, and generally I found it there. Of course, in written scripts I can read, i.e. Latin alphabet in my case. Aside to translating-by-machine, usually I only need some date/year and/or some name, noun, adjetive or verb quite common in some speciallized jargon, which usually are shared between Indo-European languages. Sometimes I only want some image, or alternative image, or a data table. In other words, I use other WP languages as an extension of the English WP proper. Sometimes I overview some other WP in different scripts (as Arabic, Cyrillic, Japanese or Berber, to say) only for curiosity and amusing (I love Unicode), but it is secondary.
  • Questions for us
    • 1. About your offered data: it's not worth to waste a single word, more than "untrustful": you will always present any result in a "positive" view (for you, of course). You've never take into account non-logged users who do not want V22 but they do not know/want/can to create an account to revert it. French and the other "Guinea pigs" WPs readers' could never made their voices/complaints be heard by you (they had no obvious/easy ways to do so).
    • 2. Issues not mentioned/addressed: many.
      • Persistent toggle for every non-logged user to switch back to V2010. It has been "promised" (?) by Qwerfjkl at 17:10, 2 February 2023 (UTC).
      • Main page layout. It is not an article at all, so narrow width it is not suitable. Now it "dances" when you open/collapse the "hamburger" menu. Best as in prototype ("hamburguer" as dropdown menu), but still the left sidebar should be filled with meaningful items related to the Main Page, to preserve overall layout. Current width-text toggle does not fit well as a Main Page feature.
      • TOC
        • TOC with numbers is a must-be, taking into account that the current tree's children indentation is very small, it is difficult to guess at glance if an entry is a sub-section or a sub-sub-section. Also numbers identify the left sidebar content as TOC, in contrast to other left sidebar's content for non-articles. Finally, numbers provide the counters.
        • Fully expanded TOC tree by default, to evaluate the whole article at glance. Everybody can then collapse what they want to collapse, if they wish. Please no AI trying to guess how many sections should be expanded/collapsed, you'll never get an algorithm suitable for every user, situation, and form factor.
        • Change "(top)" label for "Start". "Top" is a spatial term, "Start" (or the like, as "Home" or "Summary") is related to article's content. I do not advise "Lead", as certain articles lack true lead paragraphs.
        • TOC following the article's view must be an option, it be controlled by a new persistent toggle (follow vs static) for everyone. Peripheral vision makes the TOC constantly moving very annoying.
      • Editing layout inconsistencies: editing must always have the very same layout than standard reading. Page elements must not be "dancing" around. Preview must match saved changes.
      • Search bar
        • In my screen, the results' list exceeds viewport height, so I cannot see "Search for pages containing X" unless I scroll down the page. Bad design:
          • a) The results' list should show the visible items given the current user's viewport height at most, and
          • b) An "Advanced search" button/option should be always present.
        • I prefer the previous search bar behavour (simple and quick search by text in articles' titles), I use it very often. If you want to stick to the new search bar (I bet you want), then put a persistent toggle letting every user to opt-back to the old search behaviour.
        • Why the hell the "Search" button, at right side of the search bar, appears and dissapears with fading in/out animations? You cannot link this behaviour with any functionality. Please, make that button always visible and static. Avoid flashing animations elsewhere.
      • I also use "Random article" from time to time, both for fun and curiosity. With V22 this is less appealing (open "hamburger" button, click on "Random article", once and again). This has been pointed out by others also. May the "Random article" be always visible, as now "Login in" is"?
      • Featured article star overlapping menu items (an obvious bug).
    • 3. Thoughts
      • About proposed changes: far to reach I'll became a V22 IP editor. My list is longer than yours.
      • Way you address them: as always, you'll do your own way. For sure, this RFC will be closed with a fake "consesus to improve V22" or the like. Obviously you will not rollback to V2010. No reason to try to convince you, I'm tired of writting, and I already wasted a lot of time with the V22 issue. I'll put an eye time to time on V22 to test progresses (more likely month to month, given the timing you gave). Meanwhile, I'll be using "?useskin=vector" parameter in URLs.
Last, sorry my typos and grammar. Thank you everyone on my side for read. Regards.
--- 37.134.90.176 (talk) 12:59, 14 February 2023 (UTC)[reply]
Besides my concerns about registration apathy above, I'd like to note that I recently arrived at an article on a desktop on which I was not logged in, knew that there should be a width toggle somewhere, and could not find it.
Do we have a way to estimate how many people noticed it but chose not to use it? Failing that, could we temporarily default it on for some readers and off for others, to see if people ever toggle it in the other direction? ℰmi1y⧼T·C⧽ 08:26, 15 February 2023 (UTC)[reply]
The toggle is only visible starting at 1400px, which is the point where it actually has an effect. Maybe your screen was too narrow somehow?
If your screen is bigger than that, then congratulations, you have found a problem with the fixed-width toggle. It's on the very bottom-right of the screen, not just the white part, the bottom right of the right grey margin.
I don't think it's possible to estimate how many people noticed it. That is a very subjective thing that doesn't have any clear detection triggers. Aaron Liu (talk) 13:06, 15 February 2023 (UTC)[reply]
I use my browser at either full 3840x2160 or half of that width, so no. Looking at it again now, it's definitely there, but it's nowhere near any of the other controls on the page and it's too light to catch my attention. (I had also previously seen the prototype someone had thrown together where it was in the header.) ℰmi1y⧼T·C⧽ 16:12, 15 February 2023 (UTC)[reply]
Could we temporarily default it on for some readers and off for others, to see if people ever toggle it in the other direction? (Redacted) MediaWiki lacks the technical capability to deploy different interfaces randomly like that. This has been an obstacle to testing for a long time, and there is no good reason it doesn't exist yet, apart from the fact that (Redacted). —Compassionate727 (T·C) 22:48, 15 February 2023 (UTC); second paragraph added 23:12, 15 February 2023 (UTC)[reply]
@Compassionate727: could you please refrain from personalisations towards WMF employees? Femke (alt) (talk) 08:56, 16 February 2023 (UTC)[reply]
Yeah, fair. Redacted. —Compassionate727 (T·C) 09:21, 16 February 2023 (UTC)[reply]
Do you understand that "clicks" are pretty nigh useless as a determinative in this context?
People "make do". It's not like logged out users have any option to use something else. So they're going to click on the links provided.
I get that a lot of work went into this.
But saying "Look we have these great ideas and are implementing them" and seeing that (so far) the poll is about 3:2 against - this really sounds a lot like WP:IDHT.
You talk about fixing things - and I won't disagree that it's great that you're fixing what you broke by this rollout.
But how about address the navigation concerns?
Hiding the user links in a drop down - how did the watchlist get priority over the talk page? because a cute icon was found for it? If you're going to have a dropdown, it should be directly next to the username, to inherently indicate what the heck it is. Off to the side, no one's going to look for the things in it - ever - unless they find them by acccident. Sorry, but that is just flatly bad page design.
And the shuffling of the TOC, depending on what type of page one is looking at is very NOT intuitive.
restore the left side, tools and all. And if you want to play with something retractable on the right, put a retractable TOC there.
Or to put it another way: Please stop breaking stuff that works! - jc37 08:15, 14 February 2023 (UTC)[reply]
  • I'm concerned about the high opt-out rate. We see that almost 25% of active recent users (the ones doing the majority of the work) have switched back. V22 is fundamentally different from V10 in how images need to be placed to prevent accessibility issues. Having two sets of editors with conflicting goals on image placement will make this a very painful process. I think the <40% goal for semi-active editors was silly. Most semi-active editors (at least 5 in the last 12 months) would not know how to switch back. Femke (alt) (talk) 08:39, 14 February 2023 (UTC)[reply]
    +1. Having two common skins is going to be a serious issue for our FAC reviewers. —Compassionate727 (T·C) 14:24, 14 February 2023 (UTC)[reply]
    • +1 on the accessibility concerns; the switch to V22 means the way colors are displayed in a lot of articles don't meet the MOS:COLOR standards. I saw this flagged at FLC where the nominated list's "contrast between the green backgrounds and blue links is insufficient for accessibility purposes in Vector 2022" (leading to a discussion which flagged this was an issue across most lists of awards). Sariel Xilo (talk) 00:36, 15 February 2023 (UTC)[reply]
      This is because Vector 2022 (like the mobile skin) uses the same pale blue colour for local and interwiki links. That is a problem in itself IMO, as it removes a good visual benchmark for some instances of spam and POV pushing. Daß Wölf 10:39, 15 February 2023 (UTC)[reply]
      Commenting here since I brought up this point originally (while I support V22 as a whole): I've done more research and the issues are more widespread than I thought. Even ignoring when the background colors are manually changed, the colors do not work for V22's defaults. Using this article, I checked the font color for unclicked links (#3366FF) against the background color for the row header cells (#EAECF0), and it fails WCAG AA accessibility for regular text. (Check the results here.) Under V10, the link color (#0645AD) meets WCAG AA and AAA guidelines for those cells. Even if we ignore that and consider plain article text (#3366FF text on #FFFFFF background), it only meets the WCAG AA guideline – not a great result. In general, clicked links (#795CB2) have very similar accessibility scores, so both colors need to be changed. RunningTiger123 (talk) 04:38, 16 February 2023 (UTC)[reply]
    @Femke: I didn't comment on this below to avoid piling on, since I already commented on the other goals, but I agree that we need better benchmarks. I doubt that the majority of the 5 edits/12mo crowd has even logged in since the deployment, but I'm not sure which exact edit count cutoffs we should ask for.
    We could also compare editing rates of editors who stayed on Vector 2022 before/after the deployment in order to see if the skin change discouraged editors who didn't realize how to switch from editing. This could best be seen in some kind of histogram, but again we should be the ones to set the bucket sizes. Daß Wölf 10:52, 15 February 2023 (UTC)[reply]
    Making benchmarks with WMF together would be a good idea before RFC3. I think if the skin passes community-co-created benchmarks, it will do away with a lot of skepticism. The metrics above do not make a convincing case either way (except the high opt-out rate). I think 5 edits after deployment is an okay group (recent active). I'd estimate half of those people would know how to switch, so a reasonable benchmark for them would be <15% switch or something. —Femke 🐦 (talk) 17:32, 15 February 2023 (UTC)[reply]
    I think expecting half of them to know is too generous. We have a lot of editors who engage regularly with a handful of articles or with niche maintenance tasks and are totally oblivious to any sitewide issues like skins. I would like to see data from one even more active group, perhaps 25 edits since rollout (~1 per day). —Compassionate727 (T·C) 22:57, 15 February 2023 (UTC)[reply]
  • Many editors want the ToC back into the article. Making the ToC collapsible is not enough, and a long post with many subsections like yours, which is unnavigable with the new ToC, only makes it clear that the new sticky ToC is not functional at all.--Æo (talk) 09:08, 14 February 2023 (UTC)[reply]
    Here is a good compromise: have the ToC in the article, but then, upon scrolling down, the ToC automatically moves to the left hand side? The ToC could then move back inline upon scrolling to that position. This might be the best compromise to ensure easy scrolling. Aasim - Herrscher of Wikis ❄️ 05:47, 19 February 2023 (UTC)[reply]
    Why only upon scrolling down? Aaron Liu (talk) 14:19, 19 February 2023 (UTC)[reply]
    Interesting, but that wouldn't work. You would either have a huge hole in the article or the article contents would jump up (would fill the space left empty by the ToC). BTW. I think time for the ideas was something like 6 months ago, when the skin was just being developed. A better solution now would be an option (gadget?) to push ToC into the article for those that want it. Nux (talk) 20:56, 19 February 2023 (UTC)[reply]
    Why woudn't it work? The way you explained it confuses me. Cessaune [talk] 00:56, 20 February 2023 (UTC)[reply]
    I think that means when you scroll down past the inline toc, the article would suddenly go up since the inline toc disappeared. Aaron Liu (talk) 03:25, 20 February 2023 (UTC)[reply]
    That would mean the thing was implemented wrong... Aasim - Herrscher of Wikis ❄️ 21:09, 20 February 2023 (UTC)[reply]
    To not have it do that you'd have to copy it to the sidebar instead of moving it. By moving it you mean it would go up as the original ceased to exist. Aaron Liu (talk) 22:42, 20 February 2023 (UTC)[reply]
    @Awesome Aasim, maybe I'm making this up, but I think that was one of the prototypes. — Qwerfjkltalk 21:16, 19 February 2023 (UTC)[reply]
  • Thank you for the report, but since it's really long (even in Vector 2010!) I've only had time to skim it. I have a few comments/requests, apologies if it turns out I wasn't reading closely enough:
    1. It would be nice to see the survey data that BilledMammal mentioned above. It certainly looks like we need to draw new conclusions from it.
    2. You're mentioning targets that have been met. How about those that haven't? Have the metrics been published before the deployment? Without the whole picture it's hard to say if this was a success or not (see p-hacking). In addition, some of these metrics are inconclusive. It's hard to see a decrease in account creation no matter if readers like the skin or not when various sites have recommended creating it to get Vector 2010 back (example), or fewer pageviews when the new skin is getting covered in tech news and there are various scripts floating around online that load the page a second time to append ?useskin=vector to the URL. These two metrics could fail only if readers were literally abandoning Wikipedia in droves.
    3. User choices, such as changing the skin or even unhiding the sidebar, are still not persistent for IPs. The full width toggle appears to be the last item to load on the page, and since the page takes a few seconds to load it might not register to readers. I could find it only once I knew where to look. These things break user expectations and cause fatigue. After a few more months it might look that few people want these features, but it could also mean that the others simply gave up trying.
    4. The icons are unintuitive: the full screen icon for changing width, the mobile icons for settings. The TOC icon is particularly confusing; when the TOC is collapsed, the icon looks almost exactly the same as the mobile menu icon above it, and its positioning doesn't make it obvious that it isn't something along the lines of FA, GA or article protection icons.
    5. Judging from my own use, it seems Vector 2010 causes less freezing on this page in particular (as an example of a stress test) on older computers in spite of the caching decision. The design is also still rough on the edges. Longer TOCs spawn a scrollbar on the side, but don't extend all the way down the page, even though there's nothing but whitespace under there. Also, since all elements have the same background, it's not immediately obvious what the "floating" scrollbar applies to. Taking all of this into account, I really think Wikipedia should go back to Vector 2010 at least until these issues are polished out. Daß Wölf 11:20, 14 February 2023 (UTC)[reply]
    6. P.S. Regarding #🆕Summary of concerns we've heard so far: Issues on the bottom of the table are probably highly underrepresented. For example, I also find the multi-click language switcher unintuitive and very hard to use and have had it turned off in Preferences ever since it was deployed in Vector 2010 a while ago, but I didn't comment on it since going back to Vector 2010 avoids my dealing with this issue. This could be the case for a lot of other people who expressed a general wish to redeploy Vector 2010. Daß Wölf 11:02, 15 February 2023 (UTC)[reply]
      Emphatic agreement with #6. I agree with all of the complaints in that table, but as far as I can recall, I have only actually said that deployment sucked. Many people aren't going to waste their time articulating sentiments that they already feel have been well-expressed by others. —Compassionate727 (T·C) 23:18, 15 February 2023 (UTC)[reply]
Actually, the reason the watchlist button got to be one click away is that it was buried in the mystery “…” menu where the talk/contribs links are right now, until beta testers complained. —pythoncoder (talk | contribs) 01:12, 15 February 2023 (UTC)[reply]
I would like to thank the Web team for their continued communication and this comprehensive update. However, while you have accurately summarized editors' most pressing concerns with Vector 2022, you have yet to address how you intend to alleviate some of them. For instance, my biggest gripes about V22 are the forced limited text width, color/contrast issues, and the extra-click menus. You've talked a lot about the limited-width toggle, but no, editors would like to see unlimited width become the default. You mention work on the page tools menu, but I personally am most concerned with the navigational menu at the top of the page. The positioning of the talk/sandbox/watchlist/contributions are hardwired in my brain, and I do not want to click on an extra button every time and scan the dropdown menu to find a page. Also, why bother with hamburger menus? And finally, as multiple editors noted above, the link color issue has yet to be addressed. That change needs to be reverted immediately, or else hundreds of articles are in violation of MOS:COLOR. InfiniteNexus (talk) 19:33, 14 February 2023 (UTC)[reply]
Thanks for the update.
As the biggest pain point of Vector22 for me is the way languages have been handled, I’d like to draw some of that out a bit more.
I understand the intention and the logic behind the changes, but I don’t think the solution in the current Vector22 is right. I think there are problems with hiding away languages in a menu – these are problems of visibility, of ease-of-access, and of context.
I imagine I’m a bit of an outlier, as I use eight languages regularly, and make more limited use in certain topic areas of another nine or ten. Even though I might not be the most common use-case, I would say that knowing at a glance if, for example, a page is available on the Georgian, French and Russian Wikipedias is helpful; I can know, almost as soon as the page on one version loaded whether I will be able to get what I need from Wikipedia before I start (and without having to wade through a sub-menu!).
I note you are looking to implement one-click switching to “commonly-used languages”, and that T301787 has some solutions. I would really strongly suggest a solution that makes a full list available somehow – akin turning off the “use a compact language list” option on Vector10. In T301787, there’s a solution which pins the languages to the right bar, but this solution still needs the user to click through to a secondary menu for the full list of languages – if you made it so that the pinned list was the full list of languages for that article AND made the pin persistent, then I’d be mostly satisfied, though I still worry about the context around the way the languages are displayed.
You have mentioned that people weren’t using links to different language versions of Wikipedia and that bilingual people weren’t aware that they existed – and I’m sure that you must have evidence suggesting that the new layout fixes that. To me, the Vector22 solution – based on its position and icon – appears more like a translation picker than a link to articles on a different language Wikipedia (and indeed I see that different language Wikipedias are compared to translations in T301787 too). There is a difference, and I think it might be helpful to make it clearer.
I do have other gripes with Vector22 (let people move the ToC between floating and its old position! make it less cluttered!) – and ultimately I’m not sure I believe that the skin is fixable without scrapping it and starting again from scratch – but this is the thing I care the most about, and making it work better would be great. In the meantime I’ll be sticking with Vector10; either logged in or using a plugin where that’s undesirable.Nimbue (talk) 00:53, 15 February 2023 (UTC)[reply]
At the beginning of the section "How the team is addressing [the concerns of this RfC]" I saw "Problem with Legacy Vector: Reading Wikipedia in the Vector legacy skin was difficult for the majority of readers and editors" and I followed the link thinking that there was some kind of survey among readers and editors. To my surprise, the link sent me to the two-decades old "research" that the WMF used to justify its decision in the first place. The rest of the section made it even more clear that the title should be changed to "How the team is ignoring these concerns since it's too busy patting itself on the back". I'm frankly too disgusted and disheartened to keep following this page. Rizzardi (talk) 08:29, 15 February 2023 (UTC)[reply]
First, I want to thank everyone at WMF for the effort they are putting into this discussion. While I strongly disagree on many points and think they have drawn the wrong conclusions, I believe that it comes from a sincere desire to improve Wikipedia and I sincerely regret the personal attacks they have received.
While my concerns are slightly different – having to do with a lack of distinction between internal and external links – I'm going to fifth what Cessaune, ThadeusOfNazereth, Sariel Xilo, InfiniteNexus said about link colors. This issue is quickly becoming one of my bigger complaints about Vector 2022. I want to be clear, I am not against accessibility. There are many cases when it can be a good thing. However, it should not be the only consideration. I would very much like to see an explanation of: 1) why the change was made, and 2) why it was not possible to maintain separate colors for internal and external links while also being accessible (or whatever other reason motivated the change).
I also want to repeat the incredibly well stated comment on role of the table of contents in an article. I never realized how key it was to defining the Wikipedia experience before. I think a good compromise may be to have it in the original position on the page to start, but as the reader scrolls down past it, have it jump to the sidebar.
At the risk of sounding like a broken record, I am going to reiterate my comment on the vote page. The reason people trust Wikipedia is because it is old and stodgy. Wikipedians have a reputation for being argumentative, inflexible and pedantic, but the flipside of that is a reputation for a stubborn dedication to the facts. It is not a coincidence that Wikipedia, as one of the "last bastions of truth" on the Internet, has an old interface. People recognize that websites that value content over appearance are reputable. I have seen many museums – organizations with a similar mission to Wikipedia and that should know better – prioritize a sleek or flashy design to the detriment of the knowledge that they control. It gives off an air of superficiality that is associated with clickbait, push notifications, and other dark patterns.
Please note, this is not an argument against change, but an argument for being careful to avoid changes that upset this balance. –Noha307 (talk) 04:07, 16 February 2023 (UTC)[reply]
Instead of just complaining, let's see if I can suggest a solution. According to Help:Link color, the unvisited internal link color went from:
#0645AD = rgb(6,69,173)  
to
#3366CC = rgb(51,102,204)  
a change of 45,33,31. Therefore, if the unvisited external link color was to change the same amount, it would go from:
#3366BB = rgb(51,102,187)  
to
#6087DA = rgb(96,135,218)  
which seems to be very reasonable. According to visual refinements page on MediaWiki, the stated goal of the color change was apparently to increase the contrast with the body text to greater than 3:1. Using a contrast checker, reveals that it has a contrast ratio of 4.58:1, whereas the existing Vector 2022 unvisited external link color, which is identical to the internal link color, is only 3:1. Note that #6087DA is not too light, either, as the contrast with the white space is 3.51:1. The visited external link colors are a bit more difficult, as changing them by the same amount as the visited internal link colors leads to a color, #D48F98, that is far too close to red. Therefore, a different solution is needed. If we instead select a tint of the Vector 2022 visited external link color using the website ColorHexa the result is a change from:
#663366 = rgb(102,51,102)  
to
#957FC2 = rgb(149,127,194)  
which again seems reasonable and has a contrast ratio of 4.67:1 with body text and 3.44:1 with white space.
Now, I'll admit that I'm no expert on color and I imagine someone who is could come up with an even better answer, but the above is a solution that meets both the contrast with body text and the distinction between internal and external link requirements. –Noha307 (talk) 04:29, 18 February 2023 (UTC)[reply]
Note that the 3.51:1 contrast between the text and the background does not meet WCAG AA or AAA accessibility requirements for normal text (the AA standard is 4.5:1). There's different requirements for two colors of text placed next to each other versus one color placed atop another, and we shouldn't conflate the two. RunningTiger123 (talk) 21:46, 18 February 2023 (UTC)[reply]
The self-imposed standard was to have it above 3:1 so while this is a problem it's still better than what we have. Aaron Liu (talk) 02:14, 19 February 2023 (UTC)[reply]
Thanks, I was going to make that point, but you beat me to it! –Noha307 (talk) 02:30, 19 February 2023 (UTC)[reply]
Fair point. I appreciate the distinction. As the multiple considerations are quickly becoming confusing, I tried to lay out the relationships in an organized manner:
  • Contrast, WCAG ??, link text vs. non-link text: 3.1
  • Contrast, WCAG AA standard, normal text vs. background: 4.5:1
  • Contrast, WCAG AA standard, large text vs. background: 3:1
Also, to restate what you wrote, "[t]here's different requirements for link text versus body text color and body text versus background color". Again, not trying to mock or anything, the interplay between the different standards is just confusing so seeing it better laid out helps. –Noha307 (talk) 02:20, 19 February 2023 (UTC)[reply]
I found the standard! https://www.w3.org/WAI/WCAG21/Techniques/general/G183.html It's apparently an "A" standard. Aaron Liu (talk) 02:26, 19 February 2023 (UTC)[reply]
WCAG A is a standard, but WCAG AA is the minimum guidelines preferred for English Wikipedia per MOS:COLOR. RunningTiger123 (talk) 03:51, 20 February 2023 (UTC)[reply]
As far as I can see, that is a different part of the standard that only has an "A" class, it doesn't have "AA". Aaron Liu (talk) 15:01, 20 February 2023 (UTC)[reply]
This is a pretty good solution, though we still need to update all the templates. In general I think changing the link colors just for one skin is a bad idea, maybe this can be extended to all skins with an option to change it back? Aaron Liu (talk) 22:20, 18 February 2023 (UTC)[reply]
I would have to strongly disagree with that. The whole point of having multiple skins is to have different ways of viewing Wikipedia. Also, one of the claimed points in favor for Vector 2022 is that people who don't like it can always go back to using Vector 2010. Arguing that Vector 2010 should be changed as well undercuts that whole argument. If anything, it should be an opt-in for Vector 2010. –Noha307 (talk) 02:29, 19 February 2023 (UTC)[reply]
I think the concern is that if readers only have access to Vector 2022, then editors need to make sure that articles remain accessible in that skin no matter what their own preferred viewing/editing skin is. So what's the best way to do that (ie. update templates, update V22, etc)? Sariel Xilo (talk) 02:57, 19 February 2023 (UTC)[reply]
Yeah, that’s what I meant. Aaron Liu (talk) 14:20, 19 February 2023 (UTC)[reply]
This does make it seem like you are proceeding with blinders intentionally set so that the results can only be favorable. For example. your list of mentioned concerns work off of the bias perspective that only things that are explicitly mentioned are fine, this is a gaslighting measure to under count those that dislike the design. Here is a simple fix, only count the feature that were explicitly praised and assume that every other feature in those comments was disliked. Now this might seem to create an overly negative view, but its exactly what you did in the other light. Your measured objectives are so low that the design would have succeeded by anything short of wikipedia imploding. This furthers my belief that the design was poorly thought out, poorly communicated, poorly designed, and ignoring the community. 2601:246:CD80:8210:642E:854E:F7A0:8220 (talk) 22:13, 17 February 2023 (UTC)[reply]

Lack of success assessment

[edit]

I can't help but notice that all the metrics provided by this update are geared towards proving that the new skin didn't cause catastrophic user and activity losses, but there's nothing whatever proving that any of the supposed goals were achieved. We're told that in Vector:

  • "reading was difficult" – but we have no data suggesting that people are now reading more;
  • "people didn't find interlanguage links" – but we have no data suggesting that more people became aware of Wikipedias in other languages;
  • "it was difficult to reach tools" (because you had to scroll to the top) – but we have no data suggesting that they're now used more (or by more people);
  • "it was hard to navigate long articles" (because the TOC wasn't always available) – but we have no data suggesting that text deep down the fold is now used more.

In absence of any information suggesting that the new skin improved anything on the average, and in presence of clear information that it made things worse for a large part of the population, the obvious decision should have been to not make it default. Nemo 14:15, 15 February 2023 (UTC)[reply]

Pertaining to "people didn't find interlanguage links"—I can confidently state that the new language dropdown has made me more aware of Wikipedias in other languages. It's an interesting metric: United States has more articles in different Wikipedias than Wikipedia, human, Earth, or water (what?) When I reach an interesting article that only exists in English, I want to copy it to a different language, but the only other language I speak (besides English) is Mandarin, and I'm definitely not confident enough in my grammar to edit there. Cessaune [talk] 03:50, 19 February 2023 (UTC)[reply]
Good to hear! Now, if that's a widespread effect, it should be pretty easy to find some way to substantiate it. Yet we have nothing. Nemo 19:52, 27 February 2023 (UTC)[reply]

🆕 New prototype. Visual separation between regions

[edit]

Hi everyone. Thank you all for your continued involvement and participation in the conversation around the Vector 2022 skin. Over the past two weeks, we have been focusing on addressing one of the main concerns which has come out of the feedback around the skin so far - the separation of content and overall brightness of the interface. As we've shared before, we've been working on a few prototypes around this and have finally settled on a final prototype we would like to get your feedback on. We also want to have a conversation around how we want to measure the potential changes as compared to the current layout. We've posted more details and specific questions on the talk page of the project – we welcome your feedback and questions there! SGrabarczuk (WMF) (talk) 01:20, 9 March 2023 (UTC)[reply]

Response from Selena Deckelmann, Chief Product and Technology Officer of WMF

[edit]

Hello! I’ve introduced myself elsewhere in this conversation, but for those who may have missed it, my name is Selena Deckelmann, and I am the new Chief Product and Technology Officer for the Wikimedia Foundation. I joined in August. Although other threads have been moved to a subpage, I’m posting this here on the RfC page itself to help make sure more people see this message.

I’ve been watching this RfC with interest (I also read up on the prior one) and I want to thank you all for the time you spend as volunteers to think hard about the software on the wikis and engage in discussion about it. In addition to reading the discussion in this RfC, I have been working closely with the Web team to understand how the rollout has been progressing and what we are seeing from readers and editors alike. We have been thinking about what steps to take depending on the result of this RfC, and, in this note, I want to share my thinking with you.

In hindsight, I recognize that we should have paid closer attention to the needs of veteran editor workflows in this work and optimized for more of these use cases before rolling out more broadly. Some of the editor concerns expressed in this RfC could have been addressed directly or resolved sooner. For this, I am truly sorry. I have read the frustration, anger and sadness from you all, and spent time reflecting on how we might move forward together. The draft objectives for next fiscal year are one part of the changes I am making in the Product and Tech departments to focus more directly on the needs of editors, admins and functionaries, and to help make it really clear what we are working on and the impact of that work. In addition, the Web team is actively working on concerns raised in this RfC, with next steps mapped out in significant detail. In particular, we have already enabled persistent fixed width for logged out users, allowing readers to choose to use the full width and stick with it.

I have been reviewing the metrics and results of making the change to the default. I’d like to share a couple of notes on what we have seen for opt-out rates: for editors who have made one edit since the deployment, 85% did not change their skin preference, and 15% have opted out, and for editors who have made five edits since the deployment, 77% did not change, and 23% have opted out. To look a bit closer, this means that, as of January 30, 2023 on en-WP, 16,000 editors had edited five times while using the new skin and had not turned it off, and 58,000 editors had edited once and not turned it off. This is true despite the fact that all editors saw a banner with information on how to opt out and have access to a link to do so in the sidebar. I know Wikipedia is a very different type of website than Reddit, but for a point of comparison, about four months after the Reddit redesign in April 2018, an admin shared that they saw “about 58% of our users on the redesign exclusively, 33% on legacy exclusively, and 9% using both in a given day”.

I think it’s important for our software to meet the needs of all users – readers and editors – and I think it is important for us to figure out the best ways to do software development so that we meet those needs. I have a great deal of respect for the consensus process on Wikipedia. Although I am new to work here, I am not new to open source movements, and I recognize how crucial these open decision-making processes are in the difficult work of guiding the evolution of Wikimedia projects. And frankly, the current situation feels no-win for me. Despite the best intentions of many people who are engaging here, no matter what I do or recommend, I believe that many people will be dissatisfied.

I recognize that this software with respect to the needs of editors requires further improvement. For that reason, if consensus in this RfC calls for rolling back the software, I recommend that we do that only for existing logged-in editors on the English Wikipedia, while we work to address the key issues. We want the software that you use to work well for you. We know that rolling back for existing logged-in editors may cause confusion for those who have been editing with Vector 2022 since January 18 (or earlier), so I want to hear any ideas people have for how to do this as smoothly as we can.

In considering the data we have, however, I don’t see a basis for rolling back the skin for logged-out readers, or changing the default width for them (especially now that the fixed width toggle is persistent). I believe this is aligned with the policy at WP:CONEXCEPT on behalf of readers, in the sense that the perspectives of the editor community can only be one of the important inputs to making decisions about readers. I don't think the evidence we have supports rollback for readers, and, on the contrary, the evidence suggests they are receiving the benefits we hoped they would.

I also want us to think together about how we can move forward, how I and the teams I manage can tackle the software development needs of many different communities with the resources we have, through established decision-making processes. I worry that RfCs are not an effective way to plan for and execute software development projects, and I would like to create more effective spaces across communities to hear your needs and plan together. One reason I feel this way is that RfCs like these may not fully represent the perspectives of the users that they affect. I would like your recommendations on a process that might bring us together to successfully implement important changes, and I look forward to collaborating with you to bring that about. SDeckelmann-WMF (talk) 01:41, 17 February 2023 (UTC)[reply]

Dear Selena, thank you for your response. As an IP user I have to strongly disagree with your proposal of rolling back to Vector 2010 only for logged-in editors. The vast majority of Wikipedia users are not-logged-in IP users like me (we're readers only and do NOT edit anything). If you roll back, then do it for all users, editors and readers alike. Actually I feel like some sort of second-class user. I do not dislike Vector 2022 in every aspect but several complaints like the huge amount of white space haven't been adressed yet or simply have been ignored (why for god's sake didn't you just chose the #9 theme which obviously got the most votes in the June/July 2022 survey?).
I also wasn't aware of any kind of upcoming changes. It totally took me by surprise as an IP User. I use english WP almost every day and there wasn't anything to announce a new design. No banners or whatsoever. Banners only turn up if WMF needs money. Please give all users the chance to give their vote.
Yes I could create my own account but I use enWP mostly at work where I just cannot be logged-in. 91.221.58.26 (talk) 05:18, 17 February 2023 (UTC)[reply]
On "the evidence suggests they are receiving the benefits we hoped they would", no, it doesn't. Nemo 06:22, 17 February 2023 (UTC)[reply]
@SDeckelmann-WMF: The largest issue with the enwiki-WMF relationship is that you don't engage with us to learn what needs to be done. You assume that you know best and work towards that; the frustration, anger and sadness from us in relation to Vector2022 and more broadly is because of this.
Having read the 2023-2024 plan I don't believe you recognize this. You believe you are focusing more directly on our needs but in that document you commit a lot of resources to projects that we would reject as unhelpful if you asked us about, and commit no resources to communicating with us to identify and address our actual needs.
If you ask us what we need we won't say that we need the WMF to prioritize the audio experience for mobile readers (Exploring, improving and prioritizing mobile experiences including audio); while that may be nice to have, what we would say we need is, for example, the WMF to prioritize the resolution of basic issues that should have been fixed years ago like WP:TCHY.
If you want a process that might bring us together to successfully implement important changes then you need to trust us and our processes, including our consensus model, and accept that trusting us and our processes will sometimes result in you and your teams scrapping projects that you believe strongly in and working on projects that you disagree with.
Part of this will be allowing us to define some of the tests that are used to assess whether a change is positive, and providing us with the raw results for us to analyze. This will address the trust issue caused by your misrepresentation of the results of your tests and it will ensure that the tests focus on the areas that will convince the community that the change is for the benefit of all users, especially those who are not involved in the discussion.
Finally, rolling back only for editors is not an option. Having editors and readers on different skins will result in articles being optimized for the skin used by editors to the detriment of readers, which is part of the reason why the high reject rate among the most active editors is an issue (what percentage of edits made by logged in editors since deployment has been with Vector2022?) and why you need to develop a skin that is acceptable to the editing community; you can force Vector2022 on us but the result will be to the detriment of readers. BilledMammal (talk) 11:20, 17 February 2023 (UTC)[reply]
Thanks for posting an explanation. I don't believe that your solution: if consensus in this RfC calls for rolling back the software, I recommend that we do that only for existing logged-in editors on the English Wikipedia, while we work to address the key issues, is what editors are requesting. If you were to take a vote, poll, survey on that plan, I would expect it to be shot down even by editors that voted to rollback in this rfc. Logged-in editors can already choose a skin and it seems bizarre to encourage people to edit for a skin not seen by readers. I am one of those people in your statistics who is editing primarily on Vector 2022. My reason for doing so has nothing to do with something positive in the new skin, but rather I use Vector 2022 because it's what most readers will see.
For example, I only seriously contribute to 7 articles. Of those 7: 4 had issues with layout due to the removal of ToC, 2 contained sortable lists in table format which need to be modified due to the narrower width, and 2 had formatting issues with floated block elements due to the narrower width. Only 2/7 had no formatting issues from Vector 2022. If logged-out readers are given Vector 2022, it should be the default for editors. Rjjiii (talk) 19:49, 18 February 2023 (UTC)[reply]
@Rjjiii: Thank you for your note, and sharing your perspective. I agree that it is not good to have editors using a different skin than most readers long term and I appreciate that you're making this choice despite it being suboptimal for you. Would you mind sharing here or via email the 5 articles you're mentioning. I would like to investigate whether any of the planned work would address these issues. SDeckelmann-WMF (talk) 18:48, 23 February 2023 (UTC)[reply]
Thank you, @SDeckelmann-WMF, for your response. I am going to address it (this may be a bit lengthy).
--

In hindsight, I recognize that we should have paid closer attention to the needs of veteran editor workflows in this work and optimized for more of these use cases before rolling out more broadly. Some of the editor concerns expressed in this RfC could have been addressed directly or resolved sooner. For this, I am truly sorry. I have read the frustration, anger and sadness from you all, and spent time reflecting on how we might move forward together.

This is the first real apology from the WMF side. I am very grateful for this. I read this and was more than pleasantly surprised. This was very unexpected, and very welcome.
--
I know Wikipedia is a very different type of website than Reddit—pertaining to this entire paragraph (as I don't want to copy all of it over), I'm going to adress a few things:
  • I like the direct use of data. Others have commented on the validity of the metrics you use; I can't. I'm going to assume that y'all know what you're talking about.
  • Wikipedia and Reddit are not the same, so different, in fact, that they do not deserve to be compared to each other in this way.
    • There are many benefits to logging in on Reddit, karma being one of them. There are limited opportunities for that same dopamine-fueled pulse on Wikipedia. Some of them are contributing something significant, saying something wise, doing the Lord's work, as I like to call it (those menial keeping-the-backend-running edits that often go unnoticed), or doing a whole lot of work. Editors are rarely awarded a barnstar for their work; edits to articles are rarely thanked; edits that are thanked tend to be low-level contributions to userspace templates or random bits of insight on a talk page, and those are still rarely thanked in the grand scheme of things.
    • On Reddit I can repost an average meme about nothing interesting and 88 lusers jab an orange arrow into my stomach. It's inherently satisfying, that orange arrow, and it's super accessible (it's just right there, in front of you). This is why editor data metrics should not be compared with Reddit user data metrics. Everyone wants to feel that rush of knowing 88 internet randoms found what you posted at least a bit interesting or useful; consequently, there are more users available to opt-out and to track. On Wikipedia, you can create the most interesting article, you can write the most perfect rebuttal, you can upload the most perfect picture—nobody cares. Consequently, there is little incentive to become a Wikipedia editor, and if you do become one, there is still little incentive to sign up, as many edits tend to be of a menial copyediting nature, and don't require a largely useless account to make. If the vast, vast majority of users of Wikipedia are not editors, then how would they even opt-out, and how would they even be represented in the data? How many people were actually aware of the opt-out banner you talk about? I wasn't, and I'm on Wikipedia virtually every day, signed in and signed out.
    • Combine this with the fact that edting Wikipedia is not necessarily fun for most people (and a lot of editors find it weakly gratifying as opposed to wholly satisfying/exciting), and the other fact that the whole karma system of Reddit is set up in such a way that there is an actual incentive to post stuff, no. Regardless of whatever tie-ins you may see, no. They are so vastly different that I am willing to chalk up any connection that they might have to each other as mere correlation and not causation. We shouldn't be using a social networking site (the least serious major social networking site, likely) as a reference in decisions pertaining to an encyclopedia.
--
And frankly, the current situation feels no-win for me. Despite the best intentions of many people who are engaging here, no matter what I do or recommend, I believe that many people will be dissatisfied.
  • You are correct. Not everyone will be satisfied. However, every single proposal WMF has outlined will alienate and dissatify more people than simply following the consensus of this RfC.
    • An editor rollback without a reader rollback will not solve anything. It literally does nothing at all. In fact, it will only serve to piss off more, as it is pointless.
    • Going against consensus (which at the moment clearly calls for a rollback) and just declining to rollback will piss off not just advocates of the rollback, but all informed editors who have participated in this RfC. Yeah, yeah, CONEXEMPT, but I don't think the CONEXEMPT hammer is justified at this stage.
    • Going with consensus will piss off relatively few compared to the other two possible options. People might be confused about the fact that as soon as they had gotten used to V2022, V2010 is back, but that's the most serious problem I can imagine rising from this option. Of course, people prefer V2022 for a lot of reasons (new TOC being the main draw in my mind), but I can't imagine a stronger pushback than the current one.
--
If consensus in this RfC calls for rolling back the software, I recommend that we do that only for existing logged-in editors on the English Wikipedia, while we work to address the key issues—I have not disagreed with anything WMF has said more.
  • If you only roll back logged-in editors, the rollback becomes useless. There is literally zero point in rolling back editors who can just change their skin at will.
  • Again, but bolded and italicized for emphasis: If you only roll back logged-in editors, the rollback becomes useless. There is literally zero point in rolling back editors who can just change their skin at will.
  • I don't even understand why this is a suggestion. Why would it be beneficial in any way to roll back people who can roll back themselves? I don't get it.
  • I said this below:
    • The switch from Monobook to Vector was more of a UI refreshment than a UX change. As such, editors could use Monobook to edit articles that most viewed in Vector and it was, generally speaking, fine.
    • This switch from V2010 to V2022 is both a UI and a UX change. If I edit in V2010, the lack of a floating TOC will screw up alignment for a reader using V2022. If I read using V2010 in an article that was mainly edited in V2022, the lack of a floating TOC will screw up alignment.
--

In considering the data we have, however, I don’t see a basis for rolling back the skin for logged-out readers, or changing the default width for them (especially now that the fixed width toggle is persistent). I believe this is aligned with the policy at WP:CONEXCEPT on behalf of readers, in the sense that the perspectives of the editor community can only be one of the important inputs to making decisions about readers. I don't think the evidence we have supports rollback for readers, and, on the contrary, the evidence suggests they are receiving the benefits we hoped they would.

  • Let me start off by stating that I do not care, on a fundamental level, about V2022 and what I see as its problems—I use, and will continue to use (unless certain necessaries are addressed) V2010. V2022's problems don't affect me in any way, shape or form.
  • What I do care about goes deeper than any data metric, any IP's complaints, any users rebuttal—I care about the people affected by this change. It's the subtle annoyance between colleagues, the outright hatred of the skin between me and my editor friends, the random snippets of disgust you hear on the bus, the explaining of the interface to my non-editor friends. People really don't like it. A lot of Oppose arguments boil down to well, I think it's fine; pushback is normal; ILIKEIT. All fair and valid points. However, they are dwarfed by the animosity of most Support arguments. This is something deeper than IDONTLIKEIT, and I don't know why the dislike is so strong, but people really, really don't like it. I don't fight for myself, but for every single non-editor friend, to all my friends who have moved on to Wikiwand-type websites, to my mom, who has no interest in creating an account just to read words on a page. Data can show whatever you want it to show, but first-hand experience is the only thing that shows the truth, and the truth is that this change has the most significant pushback of any UI/UX change I've seen, barring Reddit. Metrics can't show that. I don't support the proposal merely for myself, but I support it on behalf of everyone who is forced to put up with the new skin.
  • Despite this CONEXEMPT sentence—Some matters that may seem subject to the consensus of the community at the English-language Wikipedia (en.wikipedia.org) are in a separate domain—WMF should still respect the outcome of this RfC. CONEXEMPT is a gavel of justice that should, in my view, only be used against editor opinion when editor opinion can cause actual problems, whether these problems pertain to Wikipedia, or a sister wiki, or WMF, or some other real-world entity; or when editor opinion conflicts with WMF policy. Neither of these two things are true in this case.
--
I know you are reading this, @SDeckelmann-WMF, and I am almost certain you are not going to comment, as has been the case when I have said anything even remotely negative about anything WMF has done and pinged WMF employees for comment: When are you going to own up and talk about the deliberate misinterpretation of survey results? Also, is raw data ever going to be released for that survey? I have so many better questions to ask, but this is the question that, once answered, will open a pathway to answering my other ones... Prove me wrong, WMF. Answer a non-surface level question of mine, please. Cessaune [talk] 06:07, 20 February 2023 (UTC)[reply]
⯈ Let me tell you a tale: one day, visitors of Sistine Chapel encounter all the walls and ceiling covered with graffiti. Some of these horrified visitors start searching the web, and found an obscure forum in which the perpetrators explain they spent more than two years planning the move, in order to make the chapel looking more fresh and modern. They are proud to have conducted some surveys among different populations to which the change is addressed: those who like rap music, those who ride skateboards and those who like to smoke cannabis, along many other casual users. Their countings said them that most targeted people would like the change, once discarded all responses insulting them, due to "foul language". Some Sistine's visitors leave complaints in such forum after registering themselves, begging the "artists" must to clean the walls and return back the classical Michelangelo's paintings immediately. Of course, perpetrators do not regret, but surprisingly, they also try to convince the complainers showing them the results of their surveys along with their interpretation: "we did nothing wrong, we only updated and improved an outdated form of art, there were people who liked the proposal". Nonetheless, the major surprise comes when complainers realize that the perpretators are a small group of young priests and nuns from the Vatican!
Ridiculous? 37.134.90.176 (talk) 23:25, 22 February 2023 (UTC)[reply]
The changes were made in good faith, but then so was this. Certes (talk) 00:05, 23 February 2023 (UTC)[reply]
I don't think that comparison is fair. Please be a bit more considerate of the humans behind these changes. They deserve respect too, however much we may disagree on whether V22 serves our readers better or not. Femke (alt) (talk) 08:33, 23 February 2023 (UTC)[reply]
Editors will get one skin, other readers will get another. [FBDB]CMD (talk) 04:13, 18 February 2023 (UTC)[reply]
I'd like to echo the sentiment we'd be doing our readers a disservice if we switch them before we switch editors. Many articles need to be "redesigned" (images/tables shuffled or made smaller) to fit V22. The logical switch would be editors first, readers second, so we can make articles look professional in advance. I think the remaining issues identified in the RfC are reader-focussed; a lot of the technical problems facing editors have been fixed. Of the main remaining issues, I'd categorise language switching, accessible link colours, overly bright design, and TOC concerns as reader issues, whereas the issue of Menus require extra clicks to open is mostly editor-facing. —Femke 🐦 (talk) 17:23, 17 February 2023 (UTC)[reply]
Encouraging editors to use Vector 2010 and readers to use Vector 2022 will result in pages which are well laid out in V2010 but not in V2022. It's the worst of both worlds. However, to some extent, it's the (hopefully temporary) situation we have now, with many editors choosing to return to V2010 whilst the vast majority of readers use V2022. Certes (talk) 20:03, 18 February 2023 (UTC)[reply]
@Certes editors should plan for mobile skins anyway. There are more smartphone and tablet users on the Internet then PC users. So you should always plan for the layout to be responsive (let's call it squishy layout, though that is a simplification). Nux (talk) 18:09, 20 February 2023 (UTC)[reply]
We already have MinervaNeue for mobile. WMF isn't planning to exchange MinervaNeue for V2022, and, even if they did, V2022 currently doesn't work as a mobile skin. Text and icons become small and hard to click, similar to trying to use V2010 on mobile (it's possible but it's clunky). V2022 also lacks the simplification and agressive optimization for lower-end tech that Minerva has. V2022 looks like it's designed for mobile but, at least to me, I think it's clear that it's only intended for PC use.
Also, the way that Minerva works negates all these alignment issues that happen on PCs, by having a simpler alignment system (that is really only possible on a thinner screen with less text). Cessaune [talk] 01:24, 21 February 2023 (UTC)[reply]
Bad metaphor, because on Wikipedia, we really do repaint the walls all the time. It's more like forcing every visitor to the Sistine Chapel to wear special colour-filtering glasses. When they ask why, it's because "we found that reducing the spectrum width decreased viewing times. This implies that visitors prefer the Sistine Chapel with limited vibrance." If they complain enough, eventually a stranger might appear and tell them that they can be permitted to take off their glasses if they sign the ledger at the opposite end of the chapel, and fill in the appropriate paperwork. Half the time they can't be bothered, which is enough to convince the leadership that everyone loves their glasses. small jars tc 17:41, 26 February 2023 (UTC)[reply]
Re I worry that RfCs are not an effective way to plan for and execute software development projects, and I would like to create more effective spaces across communities to hear your needs and plan together. I think that nearly all of us here believe the same thing. We create these RFCs out of reluctant desperation because we spend years submitting bug reports, providing feedback, and engaging with WMF staff, but ultimately, software is rolled out in beta or pre-beta form, with absurdly easy-to-fix bugs like T325219 unfixed even now. What choice does WMF leave us when this happens time and again?
On a different note, I am counted above as one of the editors who had "edited five times while using the new skin and had not turned it off", but I am staying with it only because I had the know-how to make massive, clunky modifications via a personal CSS file that make Vector 2022 mostly usable while waiting for a long list of bug fixes. I'm not the only one. I do not envy you your task, but on the positive side, the bar is low. All you have to do is listen, avoid shiny new toys, and fix a bunch of bugs that have been plaguing the editing (and reading!) community for years. Piece of cake! – Jonesey95 (talk) 20:13, 17 February 2023 (UTC)[reply]
And here it is. The big reveal that the WMF isn't acting in good faith in this discussion. This has seemed to be the case from the beginning, but its nice that you have made that perfectly clear. 2601:246:CD80:8210:642E:854E:F7A0:8220 (talk) 22:05, 17 February 2023 (UTC)[reply]
@SDeckelmann-WMF: Everything I've seen from you and the Web team suggests that your hearts are in the right place. I still think you are misunderstanding what the actual issue is. For most of the people who want a rollback, their opinion doesn't seem to be we don't want this but rather this wasn't ready yet. If it is heading for a rollback close, which seems likely at this point, then based on what I've read (admitting that I haven't read the entirety of the discussion) it seems like the rough compromise would be to roll back for all (especially logged out users), work with the community to assess what changes need to be made on the Web team side and on the wiki side such as modifying templates, tables, page design norms etc, and tackle them collaboratively. Plenty of editors would be happy to work with you to prepare for the change, and it could probably happen in just a few months.
If you are truly interested in collaborating with the enwiki community better in the future to bring about important changes without the drama, that's the way forward. Get a consensus on whether a proposed change is good, work with the community on the issues raised to resolve them, and then once the community says those issues have been addressed, we can proceed with minimal disruption. The WordsmithTalk to me 22:15, 17 February 2023 (UTC)[reply]
I'd like to repeat one point mentioned there because it's especially important: it's whether we roll back for logged out users that matters. Logged-in editors can use preferences to roll back individually, though I still think our default should remain Vector 2010, but logged-out readers have no such luxury. Certes (talk) 22:32, 17 February 2023 (UTC)[reply]
Please can we not use the term "legacy"? This biased description has suddenly appeared as an unsupported assertion that Vector 2010 is somehow suddenly obsolete and redundant, a notion clearly opposed by the majority of respondents. Certes (talk) 22:18, 17 February 2023 (UTC)[reply]
"Legacy" is a perfectly unbiased description of what V2010 is—the older brother of V2022. I don't think that the term legacy asserts any assumptions about the nature of V2010, or the future of V2010. It's a commonly used blanket term for stuff that's old, or, at the most, stuff that gets low priority. Cessaune [talk] 01:54, 18 February 2023 (UTC)[reply]
Legacy system uses some very negative language, accurately reflecting the emotions and opinions I associate (and hear others associate) with the term. "Legacy" is a word the software industry uses disparagingly to discourage use, either for technical convenience (no longer wanting to support it) or commercial gain (upgrade to Wizzo 2023 NOW!!!). Certes (talk) 13:21, 18 February 2023 (UTC)[reply]
Hmmm. I guess I see your point. They could call them Vector (2010) and Vector 2.0 (2022) or something. In the grand scheme of things this is pretty trivial though. Cessaune [talk] 16:16, 18 February 2023 (UTC)[reply]
@Certes: "Legacy" is not officially part of the name. The interface is officially called "Vector", as far as I have understood, and "2010" and "legacy" are added just to distinguish it from Vector 2022. Æo (talk) 13:08, 18 February 2023 (UTC)[reply]
-I think that the insistence that non-logged in users keep V22 specifically goes against the consensus here, in part because virtually all IP commenters here have specifically asked for V10 to become default again WikEdits5 (talk) 00:15, 18 February 2023 (UTC)[reply]
Now that WMF finally accepts that it is not going to respect community's viewpoint, is it worth sticking around anymore? It is really very frustrating as an IP editor.130.88.16.130 (talk) 13:47, 18 February 2023 (UTC)[reply]
Where has WMF decided that they are not going to respect community's viewpoint? This is an actual question, by the way. Cessaune [talk] 16:14, 18 February 2023 (UTC)[reply]
@Cessaune I believe this is the quote being referenced: "if consensus in this RfC calls for rolling back the software, I recommend that we do that only for existing logged-in editors on the English Wikipedia" It's not quite as stark as the IP puts it, but it does feel as if there is a lot of internal pushback on rolling back Vector22 until it's ready. TheMissingMuse (talk) 17:00, 18 February 2023 (UTC)[reply]

@SDeckelmann-WMF: Thank you (and your team) for these updates. Could you please run and release the "opt-out" data with "active editors" being defined as "5+ edits in the past 30 days" (or since V22 was made default), rather than in the past year? I don't think that five edits over a year is a meaningful definition of "active", and, AFAIK, not how we define "active editor" elsewhere. I'm curious if the opt-out rate changes when looking at more recently active editors? (Also, FYI, reply tool put this reply in the wrong place.) Levivich (talk) 16:22, 18 February 2023 (UTC)[reply]

Hi @Levivich - thanks for your question! The numbers @SDeckelmann-WMF shared above refer to users who made edits since the deployment (thus, who have made either one edit or 5 edits since January 18, 2023). From the group who have five or more edits, 23% opted out to Vector legacy. If we look at editors with five edits over the past year, 8.15% have opted back to Vector legacy. Here's some links with details on the data: phab:T328088, phab:T327953. OVasileva (WMF) (talk) 17:01, 19 February 2023 (UTC)[reply]

Regarding the question on a process to successfully complete projects such as these, as I've stated previously, I think it's important for the development team to work with the community on setting metrics that should be gathered through user testing to evaluate the efficacy of the proposed changes to the site's skin. isaacl (talk) 17:32, 18 February 2023 (UTC)[reply]

Thanks for your comment, @Isaacl. Investing in creating a technical system that would enable us to do that more efficiently and effectively is something I'm considering. While we can set metrics and share outcomes today, there are areas where without a significant and unsustainable investment of time, it's hard to evaluate outcomes.
A complimentary approach that still focuses on metrics and outcomes and that we can do today, is to deliberate together on objectives or goals, and through that come up with what we think are good things to achieve. That way, there's a bit more room for everyone to pursue work in parallel that improves something we already agree on. This is why I shared the draft objectives for next fiscal year, before we've settled on exactly what they will be. SDeckelmann-WMF (talk) 06:52, 24 February 2023 (UTC)[reply]
The key issue with something like the default site skin is that the focus should be on the user experience for non-registered users, but most of the expressed opposition has centered on personal experience. Part of the reason I feel that the site's UI design is best dealt with by the Wikimedia Foundation is that it has the resources to actually perform anonymous user testing. I agree there are feasibility concerns to consider, which is why I think the development team should work with the community on establishing metrics, so that any constraints can be clearly described and thus the community will understand why some approaches won't be taken.
I agree with also consulting on objectives, in a complementary discussion. However I think the development team should take the lead in bringing industry expertise into the discussion when it comes to the default skin, and ideally also have focus group sessions with anonymous users. We ought to leverage the ability of the WMF to expend some resources on finding out what would help the actual target audience. isaacl (talk) 17:01, 24 February 2023 (UTC)[reply]
  • @ SDeckelmann-WMF - First, thank you for your comments. Your engagement in this process is appreciated.

Second - Please understand that: doing rollouts, and then saying after you've rolled it out that there hasn't been much pushback on the rollout, so we're keeping it, really come across as disengenuous. You could change all the text on Wikipedia to alternate purple and green, and likely get similar results. that's just how things go. People just make do. Time has value, and people are just unlikely to take the time. So please understand that this really merely comes across as WP:Fait accompli.

Third - This rollout broke a lot of things. One need only to go to the many threads that have been appearing at various WP:VPs to see that. I'm heartened that it sounds like you're looking to take that into account in the future.

Fourth - This isn't just about subjective usefulness. Navigation on Wikipedia is a primary issue. Let me say that again: Navigation on Wikipedia is a primary issue. People can debate whitespace and layout and whatnot. That's the "skin". But changing navigation. Like moving the TOC, hiding the side banner, moving the tools menus, hiding links in drop downs - in particular links to talk pages - is a very bad idea. These things very much need community discourse. And to be clear - We're talking about a skin here. What this update has done goes well beyond just the visual "look" to a page.

Fifth - "I worry that RfCs are not an effective way to plan for and execute software development projects..." - changing navigation links should not be a "software development project". So the process isn't broken - it's just that the process was bypassed or bulldozed past.

Again, thank you for your comments. I look forward to your thoughts on these issues. - jc37 20:18, 18 February 2023 (UTC)[reply]

@SDeckelmann-WMF I do not think your data, as represented on the discussion side of this rfc, which seems to be the proper place for this, properly accounted for user apathy and only accounted for active choices. When such choices are inequally provided or advertised, the default should be expected to be used at a far greater rate than the other options.
The general user often does not know of the options available to them unless you bring them up directly. The spike of user registrations and continuing higher registration rate as well as high number of new and prior low participation accounts and ip users on this rfc should be some red flags. Those indicate to me that a significant number of people are seeking solutions to problems they encountered as common users, which due to the overall difficulty of finding this page without external assistance is concerning that so many people got through. (Formatting and reply functions also seem to be breaking down.) Deadoon (talk) 07:00, 19 February 2023 (UTC)[reply]
Regarding @SDeckelmann-WMF remark "if consensus in this RfC calls for rolling back the software, I recommend that we do that only for existing logged-in editors on the English Wikipedia, while we work to address the key issues": if this happens, we'll have a good (quantifiable) measure of apathy. After the rollback, we just need to tally how many existing logged-in editors willingly alter their preferences to keep Vector 2022. Rizzardi (talk) 10:44, 19 February 2023 (UTC)[reply]
This RFC is already a mess, so let's switch the skins every two months to see who's right and who's wrong? Please don't! Yes, most users don't care, don't notice, or even prefer the new skin. Call it whatever you want. Users who dislike the new skin for others (they can change it for themselves) are adding more and more (im)possible requests misusing Wikipedia's sacred 'consensus' principle, very skilfully I must say. Know that story of a wolf determined to eat a lamb, coming up with more and more reasons to do so? 12.51.135.28 (talk) 15:15, 22 February 2023 (UTC)[reply]
I consider myself one of these users who dislike the new skin for others. I definitely do not think my requests are impossible; if they were, I wouldn't be able to tell, as WMF has not repsonded to many of my pings for comment.
I also enjoy the benefits of the floating TOC, which is the most substantial change in my eyes, so I would like to use the skin, but there are certain unreconciliable problems that bar me for using it.
Changes I have advocated for:
General questions
  1. @SGrabarczuk (WMF) said above: The first goal of this project (next to "keep the utility for existing users") is to improve the experience of new and occasional readers and contributors.
    • How much of a factor are the users, and where do things like A/B testing fall on the editor/reader/WMF scale?
    • Are specific user opinions more or less important than data gathered from things such as A/B testing and the like in WMF's eyes?
  2. Given the fact that WMF is not bound to any outcome this RfC comes to (WP:CONEXEMPT), will WMF respect the decision?
    • In WMF's eyes, does an outcome of no consensus constitute a rollback to the status quo or will V2022 stay?
  3. When you do these A/B tests, user studies, etc—will you be releasing the raw data?
  4. Will past surveys, tests, etc. be opened for all to see the raw data?
  5. Pertaining to this survey: @OVasileva (WMF) said It’s from that perspective – anticipating sentiment immediately after launch – that we described and interpreted the results of the survey in the way that we did. Is this a justification for this sentence in the survey: 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.
    • Considering that the data shows a 66/49/37 split against V2022 how did WMF come to the conclusion that the data showed that most liked the new skin?
UI/UX questions
  1. What about a static/floating TOC hybrid, where the TOC sinks into the sidebar (I've suggested this at least three times)?
  2. Are you planing to shrink the white space, or hide it with color, or both? (Every suggestion is better than what it is currently, but I would prefer both.)
  3. More borders and lines? Is this possible?
  4. You should be able to configure your tools sidebar, to include or exclude stuff you don't need, and you should be able to filter the random article paramaters to only select C-class articles, or stubs and featured articles, or level-2 vital articles, for example (imagine the Wikipedia game possibilities).
Bugs and other stuff
  1. When I visited the article Space Shuttle Columbia disaster, I noticed that the featured star was blocking the coordinates partially. It's small but it bothers me. I think they should simply shift the entire body of article down a few px.
  2. Link color changes are not in line with (according to others) standards for reader accessibility. I'll admit, I know virtually nothing about computer accessibility issues, but it's a common complaint that I feel like is getting little attention because it affects few people.
These are reasonable questions. I don't think I'm misusing Wikipedia's sacred 'consensus' principle at all.
Also, pertaining to most users don't care, don't notice, or even prefer the new skin—at least where I live, this sentence is patently false. People don't realize that they can do something about it, or are unwilling to take the time to make their voice heard. As I said below: Data can show whatever you want it to show, but first-hand experience is the only thing that shows the truth, and the truth is that this change has the most significant pushback of any UI/UX change I've seen, barring Reddit. People I know, for the most part, don't like it. Cessaune [talk] 16:44, 22 February 2023 (UTC)[reply]
I also "dislike the new skin for others". Any "switching every two months" results from a hasty release without consensus, and we mustn't let it drive us to discard the status quo ante in favour of a fait accompli. Certes (talk) 00:01, 23 February 2023 (UTC)[reply]
  • Speaking as someone who (having used the new skin for a couple of weeks, and somewhat to my surprise, given my initial dislike of it) has decided to oppose the rollback proposed above, and without wishing to fall out with any of my fellow editors here, I welcome the statement by Selena above. As editors, our job is to write content, curate that content, handle disruption which threatens the project, determine what is and isn't included, and appoint administrators and arbitrators etc. to facilitate all that. Maintaining the software or servers that Wikipedia runs on, what I'd call the infrastructure decisions, has never been part of our remit, and the look-and-feel presented to readers is part of that infrastructure. This is very explicitly covered by WP:CONEXCEPT -

    Some matters that may seem subject to the consensus of the community at the English-language Wikipedia (en.wikipedia.org) are in a separate domain. In particular, the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, and the sister wikis, are largely separate entities. These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features (see meta:Limits to configuration changes), or accepting or rejecting some contributions, even if their actions are not endorsed by editors here.

    Which is how it should be, really. Software developers are good at the nuts and bolts of that discipline, including UI design and user experience, while Wikipedia editors are good at writing and sourcing an encyclopedia. It's fantastic that Selena and her team are engaging with the community and seeking our feedback, but ultimately that's all it is. We don't have the authority to force readers back on to Vector 2010. And personally I don't even see an advantage to doing so for logged-in editors either. V2022 has been live for a month now, editors who don't like it have presumably all switched back to V2010 already, whereas those who haven't presumably either like the new one or don't care either way. Or they want to keep their UX consistent with readers, which I personally do think is important. Switching all those users back to 2010 overnight would seem more disruptive than not doing so. *:But anyway, all this is just my opinion, I don't pretend to have definitive answers to this, and I await the results with interest. Cheeers  — Amakuru (talk) 11:08, 19 February 2023 (UTC)[reply]
IMO this is a good place to invoke WP:IAR over WP:CONEXEMPT. This is quite a serious software change and I do believe it's fair that the community debate it, whether or not WMF intends to abide by the community's decision. In particular, the metrics that the WMF team has shown us so far hardly indicate that users prefer the new skin. For instance, occasional editors having a similar opt-out rate to Reddit's "old.reddit.com" inital usage rate could indicate that WMF could also have to deal with having two desktop skins for years to come (or losing a different chunk of readers to WikiWand-type websites). Daß Wölf 17:34, 19 February 2023 (UTC)[reply]
  • Pertaining to WP:CONEXEMPT—given the fact that WMF is obviously aware of this RfC, they have commented multiple times, and they seem generally interested in feedback from the community, it would be a severe blow to relations if they just decided to ignore the consensus.
  • Software developers are not necessarily good at UI/UX design. I think that WMF is doing most things right from a UX standpoint, but there are key issues with the UI that many people dislike, including me.
  • We do not have any authority to force any change to happen. This is true. However:
    • They have many reasons to listen. We are volunteers who can just... stop editing. It doesn't make a difference in my day. I can do something else. We are also asking for something pretty reasonable—rollback until improvements are made.
    • They have no reason not to listen, given the fact that many are trying to make V2022 better, and not trying to scrap it as a whole.
  • I can switch to V2010 anytime I want. Yes. However:
    • The switch from Monobook to Vector was more of a UI refreshment than a UX change. As such, editors could use Monobook to edit articles that most viewed in Vector and it was, generally speaking, fine.
    • This switch from V2010 to V2022 is both a UI and a UX change. If I edit in V2010, the lack of a floating TOC will screw up alignment for a reader using V2022. If I read using V2010 in an article that was mainly editied in V2022, the lack of a floating TOC will screw up alignment.
Multiple times I've suggested a static TOC that becomes a floating TOC after you scroll past it, which could preserve alignment between virtually all past and future skins. It's issues like this that make switching back to V2010 if you don't like V2022 a low-level solution.
I don't know. There's a lot that could be improved. Cessaune [talk] 17:47, 19 February 2023 (UTC)[reply]
You make several important points there, most of which I agree with. I am a veteran software developer and like to think I was a rather good one, but admit I have no clue about designing UI or particularly UX (though I can certainly spot a bad one). I find editing rewarding and try hard to assume good faith, but each misstep by the WMF makes stopping editing more and more attractive. We're close to ending up de facto with one skin for readers and another for editors (and a few savvy readers) which, as explained below, will result in pages which are formatted well for editors but not for readers. Certes (talk) 18:41, 19 February 2023 (UTC)[reply]

Thank you for weighing in, but I agree with Rjjiii, The Wordsmith and others above regarding the interpretation of RfC results. Retroactively making this RfC only about logged-in users would clearly be a WP:SUPERVOTE. Quite a few of those weighing in are IPs or editors who have stated they made their account only to read using the old skin and keeping Vector 2022 for logged-out users is obviously against the spirit of their comments. In addition, I just think it's a bad idea to turn this into an open beta for inexperienced end users only. If we decide to have different UIs for readers and editors, the testing should be done by editors, so that they can weed out problems such as this accessibility issue before they can affect readers. Daß Wölf 17:34, 19 February 2023 (UTC)[reply]

I strongly agree that the Vector 2022 implementation was half-baked. Many of the problems that occurred with Vector 2022 occurred because these changes happened all at once, without ensuring compatibility, and there was no way made available for IPs to return to the old skin. On the other hand, the excuses why there is no option to change the skin for IPs are just that: excuses. I don't see a legitimate technical reason why IP settings cannot be implemented. If YouTube can do it and TikTok can do it then surely Wikipedia can too.
I supported implementation of the Vector 2022 skin on the premise that the skin would develop into something that is responsive and that would completely deprecate the need for a mw:Extension:MobileFrontend (ish). Many mobile browsers have a "view desktop site" button which switches between mobile and desktop view.
As a gen Z, I have grown up with the idea that mobile and desktop interfaces would slowly merge into one; that was the reason for the support. None of the other skins available to Wikipedia editors have this issue of lack of responsive design. I am also used to the idea of collapsing everything in dropdowns when there is not enough space in order to provide a focus on the content at hand. Having buttons pinned to the top and left and right can be distracting, especially when there is not enough room.
Vector 2010 has served its purpose during the transition to mobile first, with the complementary skin Minerva, but it has started to show its age when Timeless in ~2018, after extensive development by @Isarra to ensure that it was up to modern web standards, was released a few years ago. Timeless displays content so much cleaner than Vector 2022 currently does. If Vector 2022 is able to adopt some design principles from Timeless to allow for it to adapt to the modern day, then maybe the opposition would not be as strong. Aasim - Herrscher of Wikis ❄️ 21:35, 20 February 2023 (UTC)[reply]
I've noticed this trend too, but I don't think having the same interface on mobile and desktop is a good idea anymore.
In 2023, quite possibly the majority of people browsing Wikipedia on a modern laptop or desktop computer can be assumed to also own a smartphone capable of running a web browser or the Wikipedia app. Therefore, when a person, who probably carries their smartphone with them during most of the day, decides to sit in front of a PC to do their reading and/or editing, it's a fair guess that they wanted to do something in a different way than a smartphone or the mobile interface lets them. Daß Wölf 22:15, 22 February 2023 (UTC)[reply]

Selena, I don't have anything else to add beyond what others have written above, but I would like to thank you for recognizing the problems with Vector 2022's rollout, and I am relieved the WMF is open to respecting the community's consensus (at least to a certain extent) should this RfC not end in your favor. InfiniteNexus (talk) 07:06, 20 February 2023 (UTC)[reply]

Thanks! We're all here just trying to do our best, and I truly appreciate the effort everyone here is making to do the right thing. SDeckelmann-WMF (talk) 18:50, 23 February 2023 (UTC)[reply]

Called it. Toa Nidhiki05 13:42, 20 February 2023 (UTC)[reply]

@Toa Nidhiki05 well if you want to talk about a community "vote" then you should count "58,000 editors" that stayed with V'22 to those saying they are fine with V'22 and they want to keep using it. RFC was supposed to be about a discussion and arguments, not about a vote. Nux (talk) 18:14, 20 February 2023 (UTC)[reply]
Don't especially care. There's a pretty clear consensus against it, and there's a pretty clear consensus specifically against having it as the default for logged-out IPs. Toa Nidhiki05 19:31, 20 February 2023 (UTC)[reply]
It's difficult to find a more apt adjective than petulant to describe the ongoing decision making process with respect to WMF's approach to V22. Peoples egos have been bruised, so instead of doing the right thing, people is insisting on doing the wrong thing. I can't say I'm surprised, only disappointed. TheMissingMuse (talk) 06:28, 21 February 2023 (UTC)[reply]

@SDeckelmann-WMF: Just roll back this disliked abortion of a skin as a default for everyone alike, if you don't want to simply continue to ignore the countless intense good arguments, explanations, complaints and votes which have been given especially by numerous committed IP-users in overwhelming majority against this horrible new skin in the current RfC, who in masses feel forced to ceate an account just to somehow avoid this madness! Thank you!!! 77.179.86.51 (talk) 01:32, 21 February 2023 (UTC)[reply]

  • @SDeckelmann-WMF: Trying to prove "success" through stats is always a bad move – it ignores any explanation except the one you want to prove. I am trying the new vector and will count in your "success" stats for the moment, but I'm likely to revert back to the old version having trialled it extensively. It also ignores those editors who are using the new skin so that when content is created, they can see how it looks for readers on the new skin. They may not want to be using the new skin to check the impact of changes, and that does little for any good faith they may feel towards the WMF (and let's face it: the WMF do have something of an image problem within the community that actually provides the product).
    I've been trying it out, doing both logged in editing and logged out as a reader, and there are a few things not to like at the moment. I'm trying very hard to use the new skin, but its deficiencies at the moment outweigh the benefits in a few key areas. These are not things that should be fixable with a script, but points that affect both editors and readers that should be looked into more closely and hopefully changed:
  1. the default to a narrow view is problematic. Studies may show shorter lines are easier to read, but people have their monitors or windows set to what they personally like, and the WMF shouldn't try to double guess that – it's arrogant to assume the WMF knows what people want when they've already got their browsers adjusted to their own preference.
    Just let the page flow to 100% of page width and give people the option of narrowing if they want – not what you think is best.
  2. the lack of user links in the top right is a huge mistake – having talk, sandbox and contributions hidden in a dropdown is a backwards step. Why should anyone need to now have to click twice for simple links when previously it was available on the page? Previously they were presented cohesively as a unit and you're now making it more difficult to navigate. How is that an improvement?
  3. Having those top-right links as words, rather than icons would also be a huge benefit: icons mean different things to different people, while the words Talk, Sandbox, Watchlist and Contributions are much easier to identify. Making key navigation points more difficult to understand is mind-blowingly bad and I can't understand why you have got rid of some basic (and universally used) words for something that isn't intuitive.
  4. At the top of an article (the 'sticky header' that scrolls down the page), the block of links to other languages is dominant and unnecessary. That's a dropdown that should be on the left-hand menu. This is English WP: people are here because they speak English and don't need a link to all other languages to follow them down the page. It's the only word you have in the sticky header (if the WMF have an obsession with icons in the menu, the least you can do is have one for this too). It's odd but I've never felt the need, half way down an article, to decide to read the remainder of the article in French, Finnish or Farsi. People will make the choice before they start reading. The big bold word following readers down the page is distracting – and if it takes eyes off the text, it's bad design.
These are not just issues to be faced by logged in editors (although you really need to take that into consideration), but for logged out readers too. While I'm trying to like the new version (and there are some advantages to it), I'm struggling to get over the obvious downsides built into it. I can see myself reverting to the previous version shortly if this isn't improved. – SchroCat (talk) 11:31, 22 February 2023 (UTC)[reply]
  • I think that a lot of this (as a process) was pretty predictable (it's what happens every single time, it's why we didn't do this for over 10 years, it's why any deploy other than an en.wp deploy is an unusable signal, why lots of staff are afraid of the community etc etc).
  • I personally find the opt out rates low enough that I don't think a rollback is warranted and that a commitment towards lots of incremental improvements is a better route.
  • At the same time, the RFC reflects a strong opinion and apparently 1/5th seem to hate it quite a bit. It should definitely be considered to honour that opinion for both anonymous and registered editors. It would help build trust and long term sustainability
  • Lastly, perhaps it IS time for a change in how we deploy large user facing changes. The traditional solution of the community boils down to an escalation of "just let us participate, just tell us, just listen to us, just trust us, just give us the power". We know this is a fallacy (the community can't even get the main page to move forward, office hours are notoriously unattended, ppl hardly make use of invites to participate in design and feedback phases etc.) But maybe it should be considered, specifically that last step, as it is the only one that requires true commitment to responsibility. I've recently been thinking about a system where major changes need to be approved by editors in the week preceding the release. That would give a lot of power the community. To make sure this power is somewhat balanced, it can require you to vote BEFORE you can use Wikipedia as a logged in user. Just a blocking voting page before you can do anything at all that week. Some will argue this is too 'in the face' and will be bothering editors too often, or that it is not their job. But maybe radical change is required to safeguard the foundation, the developers and the wikis. This squarely puts a lot of veto power in the hands of editors, but it also gives them a LOT of responsibility wrt getting it right and will avoid the fingerpointing. It will help balance their asks (see also 2030 strategy aspirations, collected from the community) with the reality of what can be deliver. After 18 years of this mess, I'd find that refreshing. —TheDJ (talk • contribs) 12:31, 22 February 2023 (UTC)[reply]
This is not to say the development team is blameless. There were many points indicated from the start that experienced editors and even internal staff have indicated would be problematic, but were brushed off for 2,5 years as (per design)
  • Wasting space (making it harder to use 'my tools')
  • The need for wide view for some (which easily could have been an option from the start)
  • The need for responsive content when introducing narrow view (marked as a separate concern, that editors should fix by themselves, which was never going to be realistic).
  • Better distinction between interface and content.
The remaining problems seem less unusual to me, and are somewhat expected when a larger crowd starts using new software and encountering every single edge case possible. —TheDJ (talk • contribs) 12:52, 22 February 2023 (UTC)[reply]
Going through the talk pages on mw:Talk:Reading/Web/Desktop Improvements from back when Vector 2022 was deployed on several Wikipedias in 2020, there are so many comments about line width. I can't find a good faith reason why nothing was done about this for nearly 3 years, up until a few weeks ago. It seems like enwiki had to start a RfC before any wiki's complaints would be heeded. I'm hoping this attention means the WMF intends to honour the results of this RfC. Daß Wölf 21:59, 22 February 2023 (UTC)[reply]
Oh it's pretty simple. It was the intent. Just because a select set of ppl complain doesn't make it bad. Ppl complain all the time and they project their own experience upon everyone else and always say that "everyone" feels the same way, even though that is CLEARLY not the case. It's an inherent human trait. Doesn't make them right. What you are supposed to do however is collect those complaints and continuously question if you TRULY have made enough affordances. I think that after a certain period, ppl just started ignoring the complaints, instead of questioning "what can we do to elevate some of the concerns of the complaints". —TheDJ (talk • contribs) 12:13, 24 February 2023 (UTC)[reply]
Sure, but the line width issue is a different thing entirely. And it wasn't a select set of people; in this RfC, a non-insignificant number of Oppose votes talk about line width being an issue to some extent. Cessaune [talk] 16:55, 24 February 2023 (UTC)[reply]
Many of the support comments also voice a lot of assumptions about "everyone". If you treat "everyone" as meaning "one", there's still obviously an overwhelming interest in a full-width default (let alone option) throughout the archives.
I take back my claim about good faith -- falling prey to battleground mentality clearly doesn't imply dishonest motives. However, it does mean that it's unlikely that the devs were objective in assessing the complaints, or that decisions made about the skin reflect the users' wishes. Particularly when the feature users end up complaining about the most is the project's selling point. Daß Wölf 18:19, 24 February 2023 (UTC)[reply]

@SDeckelmann-WMF: I mentioned 5 articles with layout issues and you asked for links to see if your planned solutions would help out. I either have updated the articles I mentioned or I am in the process of doing so. For example, the niche web browser Pale Moon had issues with images stacking under the info box with the new theme ( https://en.wikipedia.org/w/index.php?title=Pale_Moon&oldid=1135414265 ) so I adjusted image locations, introduced the {{clear}} template, and expanded a small section. I am currently working on List of reported UFO sightings with Timeshifter. The list is formatted into several full-width tables. To really see the issues, you need to look at older versions of the article like this section https://en.wikipedia.org/w/index.php?title=List_of_reported_UFO_sightings&oldid=793348538#20th_century where the table has narrow columns and juts off screen. Changes since then include removing the Hynek scale as Orginal Research, consolidating Country and City into Location, merging the references into the description, and Timeshifter's work on making the dates collapsible.

Other articles are not being updated and are likely more helpful for your tests. The articles below are several that you could use to test changes. I have noticed that they need updates, but am not working on them.

I hope this helps with your testing, Rjjiii (talk) 20:52, 23 February 2023 (UTC)[reply]

Thanks for this list User:Rjjiii. Allow me to make some comments as a WP:VP/T regular (where some of these problems have been discussed and/or fixed) over the last couple of weeks.
  • I'd like to point out that Pale Moon is not a supported browser, which contains bugs that have been solved in other browsers many many years ago. You should probably not adapt pages to meet Pale Moon's broken rendering support.
  • Tables on narrow pages. This is absolutely a problem. One thats always was going to present. Unfortunately wide tables are VERY problematic and are hard to style without making very broad assumptions that can break lots of other things. Regardless, both Timeless and Minerva have rules for this, which SHOULD help if applied only below a certain width, even though you then have to discover they are scrollable. It is a BIGGER problem now that the tools menu has been made sticky. That causes the tables to overlap the tools menu in certain situations.
  • Europe "The {{multiple image}} template pushes horizontally-aligned images out of the content area and on top of the tools menu" While true.. the Europe article should be using a gallery here. Multiple image is to compose several images, and present them such that they 'look' as if it is one picture, mostly for reasons of comparison.. But that is not what this usage is. This can be fixed via multiple image template, but that likely will have undesirable side effects and the article should switch to make use of a gallery in my opinion.
  • Europe: "The right-floated "Köppen-Geiger climate classification map" can no longer fit to the right of its table. " It didn't before for half the people viewing the page. Again, this is authoring with assumptions about page width. You should never make assumptions about page width. This is not a newspaper where you can set content to exactly fit a physical form.
  • Interstate 5 in California "This table triples in length" This is a monstrosity. 65% of our audience can't use it. We should not be writing tables like this at all, but combined with the overflow issues, its now even worse indeed.
  • Rook (chess). 1 this page uses a table to show two images next to eachother... that is not what tables are for. "float a message next to the table of contents." not sure what this means.
Overall, this shows that when authored content written with incorrect and unchecked assumptions is combined with a skin that doesn't take precautions against this content, you get problems. This was expected to a degree of course and had been predicted. It can be reasoned that the skin should have 'fixed' most of these issues, but that wouldn't motivate people to improve the content instead (a problem we've seen with the mobile layout). So there is something to be said for making the problems visible so that people will identify and take care of them. As a matter of fact, some people have claimed that the hacks that are applied to mobile should be removed, so that editors are not bothered with them and that the "editors will than just make sure it is done correctly on mobile". And in many ways people HAVE been doing just that for the last years already via the mobile skin. But shifts like this have a VERY long tail. A long tail of problems. You can work for 10 years and still not have it perfect. Clearly that upsets people when suddenly confronted with it. But in the end, it's mostly a pick your poison type of problem. —TheDJ (talk • contribs) 14:00, 24 February 2023 (UTC)[reply]
"65% of our audience can't use it"[citation needed] "We should not be writing tables like this at all": can you point to a policy or guideline that backs this up? - SchroCat (talk) 14:06, 24 February 2023 (UTC)[reply]
65% is a reference to the number of user page views on the mobile website out of the total number of user page views (between desktop website, mobile website, and the apps). Izno (talk) 02:52, 25 February 2023 (UTC)[reply]
Oh, so it’s a figure that bears no relevance to the point - thanks for the clarification. I was using my mobile to look at the table before leaving my comment and did so with no issues at all. I hope TheDJ strikes his claim and answers the second point. Cheers - SchroCat (talk) 08:08, 25 February 2023 (UTC)[reply]
@SchroCat, I presume TheDJ is saying that the table does not work for 65% of readers (those using mobile view), so should not be used in articles at all, and that V22 just makes this problem clearer.
Just because it does not cause you problems does not mean it doesn't cause problems for anyone. — Qwerfjkltalk 10:52, 25 February 2023 (UTC)[reply]
@Qwerfjkl, "65% of our audience can't use it" is a false claim that cannot be backed up. If theDJ is saying that mobile users cannot use the table, that is demonstrably not true: I can use it, and did so on a mobile (and that was before I knew s/he was talking about mobile readers having problems). I cannot say (and have not even tried to) how it works for other people, but theDJ equally cannot make spurious claims like "65% of our audience can't use it" unless he can back it up. S/he also needs to back up the claim "We should not be writing tables like this at all": where is the policy or guideline that says this? On a wider point, if the new skin is making some pages problematic, then it should be something that the developers should be considering why their shiny new product is causing problems, and maybe work on a way of fixing them without having to reinvent the wheel. - SchroCat (talk) 11:08, 25 February 2023 (UTC)[reply]
65% is indeed a reference to mobile users. On en.wp its about 56% and heavily trending upwards. Outside of the western world its already well beyond 60 generally.
The table, while potentially usable a bit on mobile, is effectively unreadable content. You cant distinghuish what columns mean what, hard to compare the rows etc, and you have to scroll around like mad. And there is not true solution to this. Like, even while there are Spreadsheet apps on mobiles, thats not a particular popular way to use them. We are an encyclopedia and not a tv guide/factsheet etc. —TheDJ (talk • contribs) 11:45, 26 February 2023 (UTC)[reply]
You have spent a lot of time telling people who are critical of parts of the new vector that they cannot project their own opinion to reflect everyone else's. The same is also true of your opinion. "65% of our audience can't use it" is a false claim. It is your opinion that is cannot be used, but that does not make it true. I am still waiting for a guideline, policy or any consensus to back up the rather spurious claim that "We should not be writing tables like this at all": again, that is only your opinion and one that is not reflected by policy or practice. - SchroCat (talk) 12:14, 26 February 2023 (UTC)[reply]
You're welcome and thanks for the reply. Some responses:
  • I'm not adapting for the Pale Moon browser engine, I'm talking about the article on it. We have articles on lots of old software like Netscape Navigator or MS-DOS. The Pale Moon article (not browser) was written in such a way that the info box pushed all the images out of place when the Table of Contents was moved. You can see it from the link I posted earlier. It's fixed in the current version (of the article, not the browser).
  • Regarding Rook (chess), ctrl+f "This article uses algebraic notation to describe chess moves." There may be more templates like this, but this is only one that I'm familiar with. (Was refreshing my chess knowledge because I have a client interested in the game.) What it's meant to do is float a notice out in the white space to the right of the Table of Contents. That white space does not exist in the new theme. I'm not sure where the notice should go now, but the template currently just dumps it at the bottom of the lead. Here are both themes:
  • Regarding the comments on Europe and Overall, this shows that when authored content written with incorrect and unchecked assumptions is combined with a skin that doesn't take precautions against this content, you get problems. I am not 100% sure if you are speaking in general or to me here. I am assuming it's a general "you" throughout your post, but I can, at times, be impervious to subtlety so let me know if I've got that wrong and I'll reply.
Take care, Rjjiii (talk) 19:36, 24 February 2023 (UTC)[reply]
I think where the PGN notice ends up is actually quite reasonable for what it is. The equivalent in most other pages are the various "uses Chinese characters which may not render blah blah" (the name of which I cannot remember), which is a template that ends up on the right side of pages. At best, its assumptions are atypical; I actually don't think I can point to another template remotely like it - small enough to live in such a place as it does in most skins.
(There's a general argument to be made that these kinds of templates shouldn't exist at all.) Izno (talk) 02:50, 25 February 2023 (UTC)[reply]
Starting from Overall, its no longer a direct response to the list. Just commentary about what is happening in this entire skin change. —TheDJ (talk • contribs) 11:47, 26 February 2023 (UTC)[reply]

Follow up from Selena

[edit]

Hi everyone,

Thank you so much for your ongoing feedback and thoughts in this conversation. I appreciate the thought you have put into my recommendation and the skin as a whole and am happy to see the dedication all of you have into making this skin truly better for everyone. I have replied to a few individual comments, but wanted to highlight a couple of topics which seem to have come up for a number of folks.

  1. Many of you have mentioned that it’s important for readers to have the same skin as editors – thank you, I learned a lot from your comments and the nuances of your experiences. Being on the same skin as most readers will minimize any layout issues, and allow for the layout to be as consistent as possible across different screen sizes. While this is not a new problem and instances of layout issues were found in the Vector 2010 skin and on the Minerva skin (the mobile website), I recognize that a rollback of the Vector 2022 skin for logged-in users would delay fixes for layout issues significantly. And we also recognize that rolling back for all users will be jarring for readers and cause layout issues for articles that have already been changed for Vector 2022. If we end up rolling back just for logged-in users, we’ll want to start talking about what will need to change in the skin before it can be turned back on all users, so that we minimize how long the disparity is present. On that front, the team has been working on the issues posted last week (check out this phabricator board to see upcoming work). They are also planning out ways to identify any additional issues that folks are struggling with that will make the skin acceptable for release to logged-in users from the perspective of those who are engaging here. These plans include monitoring the conversation here and potentially starting a new conversation that will help the team rank the most important issues yet to be addressed. We welcome your ideas. What are issues we haven’t yet discussed or addressed? What would be the best way to collect these issues?
  2. One of the main issues raised to me is the blocking of content and navigational areas, i.e. being able to easily distinguish navigation from content. Many of you have expressed interest in our latest prototypes (Zebra #9, Blue Whale). The team is working on putting some more options together for you to review and will begin a conversation here and on the VPT early next week.
  3. Regarding the nature of RfCs for making software decisions, a few of you mentioned that RfCs have so far been a good process for decision-making and gathering consensus. Others mentioned that they can be difficult and lack representation, or that they might be used as a last resort when other processes fail. I am curious to hear your thoughts on how we can better make software decisions together for our users, or what potential alternatives to the existing RfC process we might be interested in exploring (Specifically, I wanted to thank Barkeep49, Enterprisey, Izno, GeneralNotability, Æo, RoadTrain, Sojourner in the earth, Nosebagbear, Sunrise, Jonesey95, theDJ, Levivich, WaltCip, Tim O'Doherty, ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, Freja Draco, Femke, Awesome Aasim, Rhododendrites, Qwerfjkl, Aaron Liu for beginning to discuss this topic already and for your ideas so far). Have you participated in other processes on-wiki or in other communities which you thought might be a source of inspiration for change? What, in your opinion, would be the ideal process for the collaboration and decision-making between the WMF and the community here on English Wikipedia and across other language wikis? We plan on beginning a longer conversation on this in the coming months, but I am curious to hear more concrete examples of historical successes, useful forums and successful collaborations that come to mind now as this RfC is ongoing and feels fresh in our minds.

Thank you all again for your continued interest and engagement. SDeckelmann-WMF (talk) 00:16, 25 February 2023 (UTC)[reply]

Quick response on #3. First, thank you for asking this question. I really like the way the "new WMF" has been engaging with the community even in choppy waters.
I think almost none of the ways we use to collect community feedback about software are good, because they all have self-selection barriers that filter the participants until the final pool is not representative of the broader community. RFCs on enwiki, or going to meta for the community wishlist survey, or going to whatever-that-new-thing-is for movement strategy... a user has to take extra steps to participate, so it self-selects for people who feel passionately enough to take the extra steps. You end up with all the disgruntled users; the users who are content with the status quo won't bother to vote in an RFC, nevermind go off-wiki to somewhere else.
I think it'd be better to collect information about user software preferences with other methods, like focus groups -- and not a call for volunteers, but randomized selection of actual editors, and with multiple groups (e.g., high activity, low activity, by age, geography, etc.). Also large-scale (thousands of randomly-selected editors) surveys and A/B testing, also broken down by groups. Spend a million bucks to collect real data in a scientifically-sound way, and then present the results to the community, and I bet both the WMF and the community would align and support whatever software changes the data suggested. Levivich (talk) 00:42, 25 February 2023 (UTC)[reply]
Thank you! I too would be excited to use an experimental approach that samples different behaviors we already have data about and maybe samples based on demographic information (caveats about our privacy policies apply). Establishing a robust system would have a significant up front cost, and I’m not sure exactly how much that would be for us. Firefox has such a system, called Experimenter. There’s also a survey system for sentiment and qualitative feedback rather than behavior change measurement. I am not sure the results will always be conclusive to everyone. With those caveats, I am very interested in considering this kind of approach. SDeckelmann-WMF (talk) 01:47, 25 February 2023 (UTC)[reply]
Yup, that's the thing. Worth the money to port (IMHO), the platform will surely be used over and over across projects. Levivich (talk) 02:05, 25 February 2023 (UTC)[reply]
Regarding software development in general: the most recent relatively successful deployed features were targeted at specific users and had a lot of iterations letting them try out features as they were being developed (the various discussion tools and the features from the WMF growth team). It isn't a panacea, as there was still a small proportion of editors who participated, and a certain number still raised their concerns when full deployment occurred. Those features are also optional, thus lowering the bar of resistance. While I understand the reasoning behind Levivich's proposal to pay editors to participate in focus groups, as is done with many companies testing their new offerings, I think there is a resistance amongst the English Wikipedia editing community to becoming paid editors, so I'm not sure how feasible this is. I do nonetheless agree that even if it's not possible to construct a true random sample, it would still be good to try to collect data from a broader sampling of editors than just whoever follows up on a thread posted at the miscellaneous Village Pump. isaacl (talk) 02:04, 25 February 2023 (UTC)[reply]
Agreed with every single point of this. —TheDJ (talk • contribs) 11:51, 26 February 2023 (UTC)[reply]
Hi Selena, I believe I have previously said this, but for #3 I believe data-driven RfC's. Allow the community to define the tests of whether the change is a positive, provide the raw results to the community, and allow the community to make a decision based on those raw results. When we have data that we can trust we will use that data to make our decision, even if the data suggests that our personal opinion is wrong.
Could you also clarify your first statement slightly; if there is a consensus to rollback for all users, will you do so? BilledMammal (talk) 02:18, 25 February 2023 (UTC)[reply]
We could always use WP:VPWMF if we need collaboration between English Wikipedia and the WMF; however, there doesn't seem to be that option on any other wikis (something that might worth looking into). As for collaborations or decisions that may need to be made across wikis, maybe a new section on WP:VP could work. Wikipedia:Village pump (other wikis) or something similar, if cross-wiki communication is desired. As for the RfC process, I don't see how it can really be improved; we've had it for years and they are usually successful in what they try to achieve. Tim O'Doherty (talk) 11:21, 25 February 2023 (UTC)[reply]
  • In terms of #3, I would echo the desire to codesign metrics for readers. One of the reasons I'm unconvinced of the new skin is that I don't think the metrics of success reflect our readers need (is it easier for them to find info if they click rather than scroll?). With better A/B testing facilities + a say in a small set of more expensive real-world experiments, we can come up with much better tests. RfCs are time-consuming, so ideally we can get together on defining metrics of success in a normal discussion. RfCs on an end-product that is reader-facing is probably more likely to derail than a discussion/RfC on metrics of success for readers.
    One of the issues of research here, is that resulst were described in a less-than-neutral fashion. Having the research performed by a different team may help prevent this in the future. —Femke 🐦 (talk) 12:08, 25 February 2023 (UTC)[reply]
Thanks Femke. I’m very interested in aligning around metrics. Something I’m curious about is whether we can get broad alignment, and what that might look like. For example we might focus on one area, like backlogs for curation and moderation workflows, but then need to spend some time on some other area with very different metrics. How to get buy in for trade offs in investment areas is very much on my mind. SDeckelmann-WMF (talk) 20:03, 25 February 2023 (UTC)[reply]
I'm not going to pretend to have any insights in how to get buy-in for trade-offs in a more general setting. Community Tech gives us the editor-focussed trade-offs (and tripling their budget would be good for repairing community relations, I'm sure the community is open to bribes :) ). But there is also a reader/editor trade-off.
In the V22 case, I'm sure we could have defined better metrics together:
  • For opt-out rates. A metric designed together would have taken into account the need to a one-click opt-out, rather than going through a cryptic preferences menu. Or even, we could have designed a test where people are forced to choose, rather than automatically moved to V22, or get a pop-up asking which they prefer after a week of editing.
  • When 11% or 23% of people indicated some accessibility problem with the new link colours (either too light, or affected by the fact that the distinction between visited and unvisited has been removed for colourblind people), we should have done testing with multiple colours, and asked for help from WebAIM direclty, given how difficult it is to meet their standards while
  • For ease of reading with limited width, we have no data, just a science-based hypothesis. As this is the main selling point of V22, some sort of A/B test would have been good here. Asking people if they've found the information a minute after they start their session for instance is quite common on many websites. The new skin priorites in-depth reading over skimming. Is that what people need? I honestly don't know..
The last one is something we can use to test content too. I have very frequent discussions with people about whether text is sufficiently easy to understand for those without academic degrees. These discussions always contain a lot of guessing: we don't know how much education people have, or need exactly to understand text. I have no way to ask the readers specific questions. —Femke 🐦 (talk) 17:10, 26 February 2023 (UTC)[reply]
Survey strategy - To collect diverse data, I suspect a single banner (e.g. "Wikipedia recently changed its website skin. Do you like the new website skin?") with a yes/no question and buttons, that goes away once the answer is given, delivered by a MediaWiki extension or whatever is currently used for A/B testing, is the way to go. You could collect data from almost every type of user, including users that don't participate in the back rooms of Wikipedia, at a scale of thousands this way. Keeping it simple (one yes/no question, one click, no giant survey) would make it effortless and help get casual readers to participate. And I don't think it'd cost millions of dollars.
Integrity in the survey process - It'd be very important to structure the questions clearly and honestly though. If this comment is accurate, it sounds like WMF may have collected some data like this for Vector 2022, then manipulated it, which does not sit well with me. WMF: "The majority of respondents reported that the new experience [Vector 2022] is easier to use or that the new and old [Vector 2010] experience are equally easy to use." BilledMammal: 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.
The "audience is too narrow" argument for throwing out RFCs - I guess it's a good idea to survey a wider audience. But, this idea that the results of RFCs can be thrown out because some folks don't think the RFCs have a wide enough audience is a really dangerous idea, that shakes the foundations of the entire RFC and consensus system. This argument could be applied to any RFC to argue that it is invalid. I don't think that is necessarily a line of thinking we should be embracing. If hundreds of experienced editors go to the trouble to participate in an RFC, watchlist the pages and follow the hundred diffs a day like I did with this RFC, then I think it is reasonable to expect the results of that process to be respected.
Final thoughts - enwiki didn't ask for Vector 2022 to be the default skin. This was an external sales pitch that (arguably) did not achieve consensus in either RFC. It shouldn't be forced on us if we don't want it. It's not like we're asking for the skin to be deleted. We're simply asking that it not be the default at this time. I find arguments that it'd be disruptive to roll it back (e.g. And we also recognize that rolling back for all users will be jarring for readers and cause layout issues for articles that have already been changed for Vector 2022.) to be weak. That argument just seems to reward WP:FAITACCOMPLI.
Thanks for listening. –Novem Linguae (talk) 17:25, 25 February 2023 (UTC)[reply]
Hi @Novem Linguae:, Thank you for your thoughts. I am curious how you view the two Vector RfCs in relation to one another. I’ve acknowledged that more attention could have been paid to the editor concerns, and I absolutely meant that. Now I am seeking a conversation to determine how we can improve outcomes and our relationships going forward. I’m wrestling quite a bit with what is possible when work takes years and RfCs happen in relation to that work, and are treated not as lasting consensus, but a poll that can be reversed a short time later. I share that as a reflection of what some of our staff experience, not to invalidate the rational concerns some of those engaging here are expressing about the close of the first RfC and now the discussion in the second. My view, which is just me talking here, is that there are widely divergent perspectives expressed and finding the consensus within that divergence was and also will be extremely hard. It may be tempting to treat the RfC as a vote, which I think is not what RfCs are for and I think that would be a mistake. I have been told that RfCs were designed for creating understanding and deciding editorial questions, and IMO they are not working well to determine design and software outcomes. My view is we should find better tools for specific purposes, not that we should throw RfCs out for community consensus where it works well. But to return to my curiosity — how do you view the two RfCs about Vector in relation to one another? SDeckelmann-WMF (talk) 19:21, 25 February 2023 (UTC)[reply]
Hey Selena. Thanks for the response. I am curious how you view the two Vector RfCs in relation to one another. I see two RFCs where the V22 side did not achieve a majority of support, but V22 was rolled out anyway. It's unfortunate that the close of RFC1 was worded in a way that was perceived as a green light to the V22 team, and not as a green light to a lot of en-wikipedians. One of the RFC1 closers stated somewhere recently that WMF did not make enough changes to V22 to satisfy the close of the first RFC.
If either of these RFCs had had more support for V22, I would be OK with the rollout. I just don't see that support though. Perhaps Sj said it best: ~50/50 rfc's make for fragile consensus at best.
We're a big movement with a lot of semi-autonomous projects. Perhaps not every project has to share the same default settings?
As for investing a lot in developing software that people end up not liking, well, I don't have the solution for that one. I believe that we should give people software they like to use, and not force software they dislike on them. This may occasionally mean backpedaling on unpopular software projects (WP:FLOW) and going back to the drawing board to create software that is much better liked (mw:DiscussionTools).
Hope this helps. Respectfully, –Novem Linguae (talk) 20:24, 25 February 2023 (UTC)[reply]
To add to that, the other closer also indicated that they believed the conditions for the closure were not met, hence a closure here of 'consensus in favour of rollback' should probably not be read as a reversal of a previous decision, and a closure of 'no consensus' should probably be read as an advice to go back to the status quo ante of V10. In general, RfCs shouln't be relitegated closely after one another, unless there are sufficient new arguments (f.i. because the situation has changed).
The closure of the first RfC was quite bold, as it gave the WMF a route to avoid a second RfC. Normally, closers do not try to guess what the opinion of opposers would be if their stated concerns are addressed (unless it's clear that there are unlikely more concerns). I really see this as a missed opportunity, partially due to poor communication from the community. As in: we know many WMF staff are new to the intricacies of these procedures, and can use some guidance to read the closure correctly. On the other hand, it would have been good for WMF staff to check in with the closers to see if they had understood correctly. —Femke 🐦 (talk) 22:23, 25 February 2023 (UTC)[reply]
Hi @SDeckelmann-WMF: Regarding #1, can you reaffirm that you'll revert the default to Vector 2010 for both unregistered and registered users if that ends up being the consensus of this RfC? Daß Wölf 17:30, 25 February 2023 (UTC)[reply]
WP:CONEXCEPT applies here. Graham (talk) 04:35, 28 February 2023 (UTC)[reply]
Judging by the record turnout, so could WP:IAR. It also wouldn't be the first time WMF rolled out or removed a feature based on a wiki community's consensus. The WMF is taking an interest in this discussion and they've already made some of the changes suggested in the RfC. I'd prefer to hear about this from them rather than make assumptions. Daß Wölf 13:05, 4 March 2023 (UTC)[reply]
@SDeckelmann-WMF: RfCs are fine for gauging the opinion of the editors' community. Other techniques could be adopted to gauge the opinion of the vast population of non-editing readers, who are not well into the Wikipedia mechanism; I can think of site-wide polls displayed on every page and with results updated in real time after having voted. These could work as complements to RfCs. Æo (talk) 14:39, 1 March 2023 (UTC)[reply]
@Æo, polls have their own problems, especially ones where you can see how others have voted. — Qwerfjkltalk 17:59, 2 March 2023 (UTC)[reply]
@Qwerfjkl: Well, I actually meant anonymous mass surveys available to any readers visiting Wikipedia and advertised on every Wikipedia article page just like the donation campaigns. Æo (talk) 18:59, 2 March 2023 (UTC)[reply]
@Æo, see Opinion poll#Potential for inaccuracy. — Qwerfjkltalk 12:36, 4 March 2023 (UTC)[reply]

Please tackle this as a systemic problem

[edit]
elegantly getting information

We are all trying to make something beautiful and useful for the world. No one wants to be spending time on a second RfC. The question is, can we make a better default (primarily for readers), how can we minimize disruption, and how much effort should we put into supporting user choice?

The editors include the layout designers and experience curators of our distributed network; with a wide range of exposure to different audiences. When layout designers think a new skin needs work before becoming the default for a billion readers, that's not a statement of their personal preferences. (Hiding the new skin from them would defeat the purpose. Breaking pages for everyone so that layout designers finally make them responsive is like the world's most passive-aggressive interoffice memo, translated to the Internet)

The central problems and perceived-regressions with the rollout were predictable, and noted politely and often in the design process, then more loudly in the November RfC. Our current system allowed it to move forward after only shallowly addressing those problems – with limited staging, and without burst capacity to respond to the surge of resulting issues. This rollout challenge is systemic: not reducible to change aversion or lack of communication.

A new skin is particularly delicate: a small barnraising, affecting every page and workflow. It needs attention to detail, a sense of the widespread impact of small oversights, recognition that everyone has a part to play in getting the place cleaned up and ready.

It also needs good monitoring and feedback mechanisms. Reported stats and user research have not been entirely up to the usual standard. For instance, "active editors" were redefined, opt-out preferences gently massaged, surveys not repeated, flagged mistakes uncorrected. That makes it hard to rely on the results. We could use more to work with. – SJ + 23:53, 24 February 2023 (UTC)[reply]

@Sj thanks for the note and the picture. We posted at the same time, and I need to go make dinner with my family, so I'll just quickly say thanks for the reminder to think systemically. I agree especially about the need for better monitoring and feedback mechanisms. I am talking daily about ways to improve curation, admin, steward and patroller workflows, and I keep running into issues with measurement. It's all solvable, but it will take something like barnraising to address. SDeckelmann-WMF (talk) 00:23, 25 February 2023 (UTC)[reply]
Enjoy dinner! Time for the same... I appreciate your post above very much. I started making a list of alternate approaches for alternate timelines. May not get to come back to it, so leaving it here:
 
(before rollouts)
  • Invite collective feedback, refactored by participants into something compact. Avoid RFC-style discussions, don't make people repeat one another, honor concerns the first time they arise.
    • Honor community-led design. (Did Timeless get its due? Related, awesome, a vision statement that fits on a stamp.)
    • Aim for strong codesign: shared ownership + delegation invigorates, continuous consultation tires.
  • Make research precise, repeatable, modest in its conclusions. with open data.
    • Help the community run A/B tests + learn to run experiments to validate ideas. (or to Levivich's idea above: to help design larger experiments third parties can run over time)
    • Unmake some past decisions that unnecessarily limit session-tracking, segmenting and A/B/Z testing.
  • Consistency: time-based rather than feature-based releases for interface change? This helps everyone plan for the "week before/after a push"; a feature-freeze process would help broadcast unambiguously what's in and out of each release - helpful for unambiguous feedback; there's a clear "next release" so things don't get wedged in late w/ less testing, &c.
 
(after rollouts)
  • Avoid monolithic breaking changes. Update early and often, uncontroversial changes first.
    • Have a public rollout checklist. Predict what will break, tag it, fix it, document it.
    • Have extra shifts in the week just before and after rollout, on both dev and community sides, for last-minute issues. We used to do this for press; this is an internal press event.
  • Attend to the social aspect.
    • Make switching lighthearted and delightful, not a menu chore.
    • For a big change, make it worth celebrating. Throw a party, make sure there are constructive things for people to do.
– SJ + 00:44, 25 February 2023 (UTC)[reply]
 
I think the community has to also accept that there is no one, consolidated viewpoint from all editors that will satisfy everyone. It's not possible to honour everyone's concerns, especially not immediately, because sometimes one person's con is another person's pro. Concerns should be examined and evaluated. In some cases, existing industry experience can be used to evaluate them. In others, they can be sources of user testing to pursue the matter further. Design by large group committee doesn't produce the best results because of the many differing visions. Particularly for user interface changes, more anonymous user testing is needed so we can understand what the target audience experiences. isaacl (talk) 01:40, 25 February 2023 (UTC)[reply]
That is true, not everyone can be made happy. But the current working assumption seems to be push ahead no matter how strong the dislike for the design. The initial RFC would have failed if judged by any reasonable person, the follow up RFC here is overwhelmingly negative. Throughout the comments you see mentions to other countries voting against this design, but it moves ahead. The Swahili wiki unanimously voted against this design. But it moves ahead. Web designers have taken shelter in the "nobody likes it because it is new" defense making it pragmatically impossible for a new design to fail. When a website shuts down, nobody goes around asking about the effect of the ui/ux change 5 years prior. It has somehow become the norm within the design community that every new design is somehow an improvement no matter how bad. I think vector 2022 is so bad as to be fundamentally irredeemable. I actually would prefer to have Minerva become the exclusive skin on desktop. I think their desktop focused mobile looking redesign is worse on desktop than the old made for mobile redesign. They are basically pushing ahead while gaslighting us in these comments they have already spent the money on the design and on the pr push where every website parroted their pres release. This design is bad through and through, but hey if a cold o-ring didn't stop the Challenger launch there is no way they have been acting in good faith 2601:246:CD80:8210:69EC:776D:AF88:DB28 (talk) 04:45, 25 February 2023 (UTC)[reply]

Hey, @User:SDeckelmann-WMF I have a few questions for you. Thanks for taking the time to respond to other people's concerns.

General questions

  1. @SGrabarczuk (WMF) said above: The first goal of this project (next to "keep the utility for existing users") is to improve the experience of new and occasional readers and contributors.
    • How much of a factor are the users, and where do things like A/B testing fall on the editor/reader/WMF scale?
    • Are specific user opinions more or less important than data gathered from things such as A/B testing and the like in WMF's eyes?
  2. Given the fact that WMF is not bound to any outcome this RfC comes to (WP:CONEXEMPT), will WMF respect the decision?
    • In WMF's eyes, does an outcome of no consensus constitute a rollback to the status quo or will V2022 stay?
  3. When you do these A/B tests, user studies, etc—will you be releasing the raw data?
  4. Will past surveys, tests, etc. be opened for all to see the raw data?
  5. Pertaining to this survey: @OVasileva (WMF) said It’s from that perspective – anticipating sentiment immediately after launch – that we described and interpreted the results of the survey in the way that we did. Is this a justification for this sentence in the survey: 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.
    • Considering that the data shows a 66/49/37 split against V2022 how did WMF come to the conclusion that the data showed that most liked the new skin?

UI/UX questions

  1. What about a static/floating TOC hybrid, where the TOC sinks into the sidebar (I've suggested this at least three times)?
  2. Are you planning to shrink the white space, or hide it with color, or both? (Every suggestion is better than what it is currently, but I would prefer both.)
  3. More borders and lines? Is this possible?
  4. You should be able to configure your tools sidebar, to include or exclude stuff you don't need, and you should be able to filter the random article paramaters to only select C-class articles, or stubs and featured articles, or level-2 vital articles, for example (imagine the Wikipedia game possibilities). Is this possible? It's small but I think improving the toolbar in such a way could go a long way.

Bugs and other stuff

  1. When I visited the article Space Shuttle Columbia disaster, I noticed that the featured star was blocking the coordinates partially. It's small but it bothers me. I think they should simply shift the entire body of article down a few px. Now, the coordinates don't interfere with one another, but the star is too high and touches the line above it.
  2. Link color changes are not in line with (according to others) standards for reader accessibility. I'll admit, I know virtually nothing about computer accessibility issues, but it's a common complaint that I feel like is getting little attention because it affects few people. Why did you change the link colors?

Again, thanks for responding to so many questions! Cessaune [talk] 21:31, 26 February 2023 (UTC)[reply]

This RfC is coming to a close

[edit]

AHollender, SDeckelmann-WMF, OVasileva, SGrabarczuk, MMiller: This RfC is done. Comments are dying out; people have settled into their respective positions. No more discussion is going to tease out new unexplored ideas. As such,

  1. Is WMF going to invoke CONEXEMPT?

If not:

  1. Can we end this RfC?
  2. What arguments does WMF consider valid and which ones are invalid?

Thanks, Cessaune [talk] 04:24, 6 March 2023 (UTC)[reply]

I am not under the impression that the WMF is going to close this discussion. Is that the case? Shells-shells (talk) 04:36, 6 March 2023 (UTC)[reply]
No, but the smart choice is to go through them, as they ultimately have the final say (CONEXEMPT). Cessaune [talk] 05:02, 6 March 2023 (UTC)[reply]
A closure request was made two weeks ago, see Wikipedia talk:Requests for comment/Rollback of Vector 2022/Archive1#Expedited close? and Wikipedia:Closure requests#Wikipedia:Requests for comment/Rollback of Vector 2022. Volunteer editors will close this RfC, not the WMF. InfiniteNexus (talk) 17:57, 6 March 2023 (UTC)[reply]
It is one thing for the RfC to be closed in a specific way by volunteers. It is another thing if WMF actually recognizes the consensus. Given that WMF manages the backend for us Wikimedians it would not be too surprising Wikipedia:CONEXEMPT and Wikipedia:OFFICEACTION applies. Aasim - Herrscher of Wikis ❄️ 19:54, 7 March 2023 (UTC)[reply]
Honestly, this whole RfC feels like Wikipedia:Move review/Log/2020 October#Twice to me - while I doubt there was truly consensus to make the original change, I don't see consensus to revert it, either, and while policy most likely dictates going forward with the change, I can only imagine the change will remain controversial. (I've wanted to say this for a while now, and now I feel like saying it.) -BRAINULATOR9 (TALK) 23:49, 14 March 2023 (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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Rollback_of_Vector_2022/Discussion&oldid=1175923626"