The purpose of this Request for Comment (RfC) is to improve Vector 2022 by gathering community opinions on its strengths, weaknesses, insufficiencies, etc., and ideas and proposals for concrete changes. 18:12, 8 January 2024 (UTC)
Following a September–November 2022 RfC, the Wikimedia Foundation Web team deployed Vector 2022 as the new default skin for all users on the desktop English Wikipedia site on 18 January 2023 at 15:17 UTC. This replaced Vector legacy, which had been the default since 2010.
After the deployment of the new skin, there was a community backlash, with many users expressing concerns about the new interface and wondering as to whether there was really a consensus to its deployment, and, as a consequence, a second RfC was opened on 19 January 2023 asking for a rollback of Vector 2022 and a restoration of Vector 2010. The closers of the second RfC found no consensus for a rollback, but acknowledged that "consensus can change, and one of the suggestions made during [the] discussion was to open a new RfC in six months' time" and that "editors interested should try and work alongside the WMF to acquire statistics, such as additional surveys, that could be used as the basis for the new RfC".
This third RfC on Vector 2022 has been opened in the spirit of the aforementioned suggestions, and its purpose is to improve the interface by gathering community opinions about its strengths, weaknesses, insufficiencies, etc., and ideas and proposals for concrete changes.
Users can voice their support or opposition to other users' opinions by replying +1 ({{+n}}) or −1 ({{-n}}) respectively. If a specific opinion gathers enough support, it will be added to the list of proposed changes below.
Users are asked to answer the first six questions for data collection purposes ('nothing' is an acceptable answer). To simplify review, survey response length should be kept to a minimum.
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.
In my opinion, V20>Timeless>>Monobook>V10>>Everything else.
The conversion of nearly everything to Codex, which is the flat design thing. Vector 2010 converted half of everything to flat, which resulted in it looking quite dull and not entirely complete in the flatness mission (I prefer monobook over it). With the notable exception of WikiEditor's popup, everything in V22 looks pretty consistent.
The maximum width. Finally we have a consistent content width to account for and makes reading a whole lot easier.
The organization of languages into sections.
The floating TOC and page tools, which make navigation easier.
After significant customization of the layout with CSS, the skin functions well. Every page displays well for me, and I don't have to put up with any glaring visual or functional bugs. I don't take that for granted. – Jonesey95 (talk) 01:21, 10 January 2024 (UTC)[reply]
That's the one thing that was a definitive regression, to the point that I find it entirely unusable. The other features were all fixes to things I didn't find broken, but I know those are locked in; if the readability issue was resolved I'd be at least willing to give it a shot. The Blade of the Northern Lights (話して下さい) 02:14, 10 January 2024 (UTC)[reply]
I still find the left side of my screen is pushed way too far over. Since I'm frequently on an iPhone in desktop (mobile is borderline unusable for editing) that chews up a lot of space. If it works for other people that's fine, but the Vector 2010 layout keeps paragraphs looking like paragraphs instead of walls of text. The Blade of the Northern Lights (話して下さい) 04:47, 10 January 2024 (UTC)[reply]
The maximum width and the white space. Makes reading much nicer. Also the new table of contents. I like that it floats, doesn't have useless numbers, and can be expanded and collapsed. Nosferattus (talk) 23:56, 10 January 2024 (UTC)[reply]
maximum line length (even though its a bit small next to decent sized images), and the removal of most unused menu links from the default view. —Femke 🐦 (talk) 18:04, 17 January 2024 (UTC)[reply]
−1 It is probably an effect of the limited width and the new font use and dimension, and because of it a large number of articles which were previously considered normal in length have suddenly become (and have been tagged as) "too long". Æo (talk) 13:23, 5 February 2024 (UTC)[reply]
What they’re saying is that they like the new line length, and article length does not depend on screen size; it depends on word count. I don’t think the articles newly tagged as too long since last year have anything to do with limited width. Aaron Liu (talk) 14:11, 5 February 2024 (UTC)[reply]
Nothing Sorry, not trying to be rude, but I'm not seeing how it's an improvement at all. If I want to go on mobile view, I'll go on mobile view. If there was an RfC for the original change, I would have strongly opposed it. There are lots of readers online who have opposed it as well (I'm not putting links but you can look it up). Making the desktop site look like a mobile version is not beneficial at all. If I wanted to view mobile on desktop, I can just change it to mobile view. Not to mention the issues it has caused with 2010-installed editors not being able to see what most IP readers are seeing. ~WikiOriginal-9~ (talk) 14:34, 7 February 2024 (UTC)[reply]
On viewing parity, I believe that V22 was actually an improvement. Previously, the display of an article wildly varied depending on your window size. With limited width, a lot more people see the same thing. Aaron Liu (talk) 15:53, 7 February 2024 (UTC)[reply]
Having the table of contents of a page always visible at left is something I like a lot. It's navigationally useful and makes it much easier to move quickly through an article, especially large ones, especially with being able to jump to the top immediately so I can compare the lead with the body. P-Makoto (she/her) (talk) 20:29, 22 February 2024 (UTC)[reply]
The lack of default max width for logged-out users: I think max width is more appealing than limited width and should be implemented as the default (or, at the least, there should be a persistent toggle for logged-out users). The wasted white space that the sticky TOC creates. Also, the lack of borders around the TOC and tools sidebars. Cessaune[talk]17:08, 9 January 2024 (UTC)[reply]
That's why I talked about a persisent toggle. That would be my first option but WMF already said that something of the sort was going to be hard to implement, for whatever reason. Cessaune[talk]05:04, 11 January 2024 (UTC)[reply]
Yes. It also only appears if the viewed width isn’t already equal to or smaller than the limited width. If you don’t see it, try zooming out. Aaron Liu (talk) 14:07, 12 January 2024 (UTC)[reply]
That’s because your typical screen size is already smaller or equal to the limited width, in which case the toggle wouldn’t have any effect. Aaron Liu (talk) 15:23, 12 January 2024 (UTC)[reply]
I don’t know what to say; it simply wouldn’t. Your content is already at the max width. You can get a bit more by hiding all the floating things. Aaron Liu (talk) 15:37, 12 January 2024 (UTC)[reply]
@Aaron Liu: just confirming, the toggle doesn't appear at window sizes below 1400px, but it starts to have an effect for windows larger than around 1100px. A significant range of devices (and windows on slightly wider devices) fall into that gap. @Cessaune: this is one of my least favorite things also; I like your suggestion below of addressing this with a descriptive "visual density" selection. – SJ +04:31, 6 March 2024 (UTC)[reply]
The sticky ToC and the absence of the inline ToC; the lack of borders around the ToC and tools sidebars; the hidden tools sidebars; the hidden language menu on the upper right corner of the page; the squozen article text due to the limited page width.--Æo (talk) 19:40, 9 January 2024 (UTC)[reply]
−1 Per 141 above. That was my biggest adjustment to V22, but now when I look back at pages on Vector legacy, the inline TOC seems extremely clunky and generates lots of whitespace on some articles. Ajpolino (talk) 22:05, 11 January 2024 (UTC)[reply]
The white space below the text lead, beside the ToC, was essential to distinguish the lead from the body of the text. The new design, in turn, adds a lot of useless, wasted white space on the right of the page. Æo (talk) 22:45, 11 January 2024 (UTC)[reply]
To me, a section header is enough to distinguish. I'm not sure what you mean by wasted white space to the right of the page; we're only talking about the part that is the page content, no? Aaron Liu (talk) 02:29, 12 January 2024 (UTC)[reply]
So is the ToC part of the article's content or not? The sticky ToC is like an external user menu instead of being part of the article. Æo (talk) 00:17, 13 January 2024 (UTC)[reply]
In Vector 2022, it isn't. Me and many others here don't understand the geometry. Plus, the TOC isn't to the right of the content anyways. I still don't know what you mean by whitespace to the right of the page. Aaron Liu (talk) 01:38, 13 January 2024 (UTC)[reply]
There are quite a bit of weird decisions, some of which I’ve fixed with personal CSS:
The useless "languages" section on the left and the requirement for custom configuration for it to be the top-right language selector. Something similar for "switch to old look".
The excessive width of the left and right floating things (main menu and tools) and the excessive padding below the top bar.
The incompatibility with TOC magic words and noexternallanglinks.
The choice to make the floaty top bar to not have all the buttons in the top bar and how it only appears when reading
The bastardization of dropdowns and smaller version of limited content width brought by Zebra.
+1 A lack of colour contrast that gives an indistinction between the parts of the page, the same problem yolden by the lack of borders around the ToC and menus. Æo (talk) 16:27, 10 January 2024 (UTC)[reply]
Absolutely. This makes it unusable for me (without custom css, anyway), especially given that the TOC is locked and doesn't scroll. No idea how this doesn't make everyone else sick. -- asilvering (talk) 23:39, 19 January 2024 (UTC)[reply]
+1 I completely agree, that's why I use Vector legacy. On my screen (using the main page), almost 1/3 is white space, and I just can't take it! OnlyNano22:05, 29 January 2024 (UTC)[reply]
100% Way too much wasted screen real estate. Very few that take the time to comment on structured changes to page layouts, but it is worth taking the time to do here. With over 20 years contributing to open-source and user-interfaces, the Vector 2022 layout simply does not provide enough readable information in a single screen. This is an acute issue for laptops or other smaller screens where real estate is at a premium. I switched back to the vector 2010 legacy format and it makes much more sense from a human factors standpoint. When looking for information, there is nothing worse than empty-pixels. That said, the legacy format also seems to be missing some improvements that wikipedia had made between 2010 and the time of the Vector 2022 roll-out. Thankfully, the option to use the older layout is present, kudos for providing that. If the Vector 2022 layout could lose all the wasted white space, it may be a decent layout, but staring a white pixels doesn't convey any information at all -- except the UI designer needs a few more years experience under their belt. Drankinatty (talk) 22:46, 11 February 2024 (UTC)[reply]
−1 not so much white space on my 14" laptop. The fixed width and line length are a big improvement, and looking back at the old skins - they look old fashioned and amateurish. 205.220.129.21 (talk) 15:28, 24 February 2024 (UTC)[reply]
−1 The amount of white space varies depending on your viewport (a.k.a. screen) size. The bigger the window, the more screen it wastes. Plus, even on my phone, the space between 1. the middle part and the sidebars 2. the top bar (the one before you scroll down) and the article title and stuff seems excessive. Aaron Liu (talk) 17:15, 24 February 2024 (UTC)[reply]
−1 The number of exposed links was beyond measure. Most users do not need them as they only come to read the articles, so the interface doesn't need to look like a space shuttle dashboard. Less is more, my teacher said. 205.220.129.21 (talk) 15:33, 24 February 2024 (UTC)[reply]
A Wikipedia skin should also be considered from the editing side. It's very reasonable to consider both, but to ignore one isn't. Ideally, the skin should strike a balance or be customizable to the point it satisfies both types of users. (IMO V22 does that alright) Aaron Liu (talk) 17:16, 24 February 2024 (UTC)[reply]
+1, was about to make this point too. Communicating on the talkpage should be made obvious and prominent (much more so than the userpage), especially to newer users. CMD (talk) 05:18, 10 January 2024 (UTC)[reply]
I see several reasons that the Main menu is a more obnoxious presence in V22 than in V10. One problem is that it sits above the ToC in V22, so it interferes with the ability to see the ToC. Also, its font size is bigger in V22. Also, the space between lines in it is larger in V22. Moreover, the column it occupies is wider. The lack of any shading or boundary to show where that column ends is also visually confusing and makes the column harder to ignore. Overall it is using too much screen space, shifting everything else to the right, and covering up the ToC. Can it be put into the right column instead of on the left? — BarrelProof (talk) 19:28, 26 January 2024 (UTC)[reply]
I don't really know... I hate it so much I used it for about two or three articles and then switched back to the old one. Will never use it and will quit using the site if there are no other options. I know this isn't really constructive, but it's honest... SportingFlyerT·C09:20, 10 January 2024 (UTC)[reply]
+1 At the risk of being unconstructive, I feel similarly. Some people clearly prefer the new skin but it should be optional, not a sudden new default which appears unrequested and mostly unwanted out of nowhere. Someone has been allowed to spend our donors' money on their pet project to the detriment of our readers and editors. That's a serious management failure, and I think it's indicative of the WMF's utter disregard for the editors who tirelessly tend the cash cow that pays their salaries. Certes (talk) 19:43, 11 February 2024 (UTC)[reply]
But how do you see any future development. Technology has progressed, we can't be stuck with old systems forever. Every now and then you have to rebase everything. 205.220.129.21 (talk) 15:36, 24 February 2024 (UTC)[reply]
Most of my usage is reading via Firefox for Android, 13 year old phone, with JS disabled. On the whole my experience with reading Wikipedia has become far worse since the introduction of Vector 2022.
I have to keep Javascript disabled in the browser specifically because Vector 2022 is so heavy. It adds 20-30 seconds to every page load before links become clickable.
Without JS the sidebar TOC cannot be collapsed. It takes up 30% of my screen in landscape mode. Ideally if the site detects a lack of JS, it should revert to the inline TOC.
50% of the time if I thumbscroll on the left I will scroll the TOC. 50% of the time the same gesture will scroll the body. My guess is this is because there is tiny bit of left margin that my thumb can sometimes catch. If so, a left border to make this pad visible would be helpful. (Given how much space the sidebar takes up on small screens, there shouldn't really be any left margin at all, but as removing the it would also remove the ability to scroll on the left altogether I'd request avoiding this route.)
Even with JS disabled scrolling is jerky and unresponsive much of the time.
It has been suggested that IPs use custom extensions to redirect to preferred skins. I do that when I'm on desktop, but FF Android only allows a very small list of extensions, none of which can handle URL rewriting. I have to manually add the useskin parameter to the end of every single Wikipedia URL, a fiddly process as I cannot always precisely click on the URL bar. I have to keep "?useskin=vector" pinned in my phone keyboard's pastes at all times. This means two pageloads and 2-3 minutes of fiddling for every page I want to view. Sometimes three if a search engine has dumped me into Minerva Neue. I know where to put a GET param into an URL but I'd imagine the average user does not. 216.80.78.194 (talk) 11:08, 10 January 2024 (UTC)[reply]
Why not use the mobile frontend if your phone is that old? From my experience, it’s enough for some light editing, especially with the recent introduction of user scripts. WMF really shouldn’t design a desktop skin for mobile. Aaron Liu (talk) 14:21, 10 January 2024 (UTC)[reply]
−1 Having the mobile front end is a concession that the editing experience on mobile sucks. Making a skin work on all devices shouldn't be hard. AwesomeAasim21:31, 15 January 2024 (UTC)[reply]
−1 It is a much higher maintenance workload. When doing something, you will have to account for how it looks like on all devices, instead of just desktop. In essence, it will also load two difference interfaces that are required to be combined into one package. That doubles the design resources needed for everything, makes desktop UI designers also somehow need to account for mobile, and raise the possibility of something many in the V22RfCs have tried to avoid: a desktop skin designed for mobile. Mouse and touch use quite a bit of different interaction paradigms. Not to mention they are designed for different levels of processing resources. Pretty much all other skins assume you have competent processing power, but Minerva doesn't. Minerva is designed to make a wide array of concessions to make the skin lightweight and speedy while usable. Aaron Liu (talk) 21:51, 15 January 2024 (UTC)[reply]
Huh I had no idea V22 had compatibility with a javascriptless setup. I ran Monobook for years because it could do everything without javascript enabled. 216, can't you turn on "desktop site" in your Wikipedia tabs in Firefox? It sounds like we have similar setups, and that technique works on mine. Folly Mox (talk) 02:17, 11 January 2024 (UTC)[reply]
It sounds like they have it turned on (else they would get Minerva instead of V22) and it takes too much of their potato phone's resources. Aaron Liu (talk) 02:19, 11 January 2024 (UTC)[reply]
Accessibility nightmare for those with mobility issues.... the more you have to click to reveal things the less accessible it is.Moxy-00:07, 11 January 2024 (UTC)[reply]
−1 It's just one extra click, while everything else about accessibility hasn't changed. While I admittingly don't know much about mobility, both other skins and V10 require clicking and moving, so I don't see how this is such a degradation. The page tools, main menu and contents are especially helpful as you can now skip over all of them if you have them hidden instead of going through everything.The new practice of "jump to contents" instead of jump to not-contents is a bit weird though, as V22 seems to be the more reader-oriented skin. Aaron Liu (talk) 02:08, 11 January 2024 (UTC)[reply]
+1, also New Vector sucks for screenreaders. However, there's a beta feature for New Vector called Accessibility for Reading. Right now it is really basic, but I really wish that an option to display all links will be available there. (courtesy ping Moxy) CactiStaccingCrane (talk) 13:16, 14 January 2024 (UTC)[reply]
@CactiStaccingCrane Now that I've had a chance to finally get Windows narrator working, could you elaborate on how it sucks for screenreaders? Is the reason it putting the navigation before the content? The only mention of Vector 2022 I've found on the talk page of Wikiproject accessibility is someone having trouble with the button for the floating TOC at the small screen size, which has now been marked as solved. Aaron Liu (talk) 18:00, 29 January 2024 (UTC)[reply]
That when the window narrows the "Edit" and "View History" buttons get hidden under the "Tools" menu (funny enough the "Read" button gets hidden in there too with no styling to suggest it's the current view). I don't really think of "Edit" and "View History" as "Tools". Would prefer they get shrunk to icons or just stay visible as words when the window shrinks. Ajpolino (talk) 21:54, 11 January 2024 (UTC)[reply]
The ToC on discussion-based pages is largely unreadable. For instance, WP:VPP. It seems that comments-as-subsections, like "Bilorv, 00:00, 1 January 1970" is a designed feature, but I have yet to find a situation where it improves navigation. Instead it is hard to pick out the top-level sections and important subsections. On a page like WP:FAC, the TOC should serve as a clickable list of each nomination. — Bilorv (talk) 00:16, 14 January 2024 (UTC)[reply]
What if different colored backgrounds corresponded to different levels of headers? Level 2 = white, Level 3 = light gray, Level 4 = dark gray, for example? Cessaune[talk]00:20, 14 January 2024 (UTC)[reply]
Vector 2022 TOC at VPP with custom CSS I have posted a screen shot of my Vector 2022 TOC from WP:VPP at the right. After restoring some necessary formatting via custom CSS, it works well for me. I added numbering, custom indenting, and auto-expansion. It's busy, but those pages are busy. (Also note the sticky header with notifications and other goodies, which appears on all pages, not just the ones that the WMF developers decided that it should appear on.) – Jonesey95 (talk) 02:22, 14 January 2024 (UTC)[reply]
I like this CSS version a lot. I feel like the gray number of comments achieves what may have been the point of including comments as subsections: to show which sections are longer and more commented on. Numbering also helps to see the levels of the subsections, whereas V2022's default indenting isn't that easy to skim. — Bilorv (talk) 12:23, 14 January 2024 (UTC)[reply]
Under the userscript Convenient Discussions, I have bullet points before each comment-in-ToC. Just to clarify, does the default DiscussionTools not have those? I can't see anything when logged out. Aaron Liu (talk) 01:07, 14 January 2024 (UTC)[reply]
Yes, there are bullet points, but they bring a lot of clutter when I want only the top-level section titles visible without scrolling. — Bilorv (talk) 12:20, 14 January 2024 (UTC)[reply]
It's a bit hard for me to remember why I hate the Vector22 UI so much. My reaction to learn how to disable it was pretty immediate. The main thing is the impression is that it has a much lower information density and lots of wasted screen space (especially on the sides, but also extra vertical space, especially on the sides). I did not notice any advantages to it. I really dislike what I see when logged out, so I log in to avoid it. I often click on the link to the list of my recent contributions to remind myself what I was doing recently and see whether the pages have been modified by others after my recent edits, and that link is hidden in Vector22. I also generally prefer text over icons. The stuff I now see on the left side while editing this with Vector22 is stuff I would practically never click on (except the boldfaced "Switch to old look"). At the top, I see a big spot devoted to "%& Add languages"; how often am I expected to click on that? (approximately never, I suggest). — BarrelProof (talk) 01:48, 15 January 2024 (UTC)[reply]
You can hide the stuff you would practically never click on in Vector 2022 by clicking on the "Hide" button. The menu is present in every skin where they're unhideable without some special configuration that zhwiki seems to use. +1 on the languages menu in the top bar. When a page has languages you'll be able to switch to another edition of Wikipedia from there, but I never use it either. Having the notifications interface be there would be much better. Aaron Liu (talk) 02:37, 15 January 2024 (UTC)[reply]
Thanks for the help. I'll try it some more. Generally, my gut reaction is to dislike it when a UI changes without what I perceive as some clear improvement or need. I have already invested time and energy and developed habits. Is there any way to get to the list of my recent contributions in V22 without going through a drop-down menu? — BarrelProof (talk) 02:58, 15 January 2024 (UTC)[reply]
The panel on the left is almost twice as wide in Vector22 as in Vector10, which seems like too much. If I hide the left panel, I lose the ToC completely. The font size used in that left panel also seems bigger in V22, and I think there is more vertical space between menu items in the side panels and between paragraphs in the main panel. If I hide the other stuff but don't hide the ToC, sometimes the left panel is there and sometimes it is absent, so the location of the main panel jumps left and right depending on what I'm looking at. In Vector10, the main panel is always in the same place, so I know where to look. The background of the left panel is also shaded in Vector10, which helps clarify the boundary. — BarrelProof (talk) 19:32, 15 January 2024 (UTC)[reply]
I'm slightly confused, isn't the main menu always hidden if you hide it? I agree that the left and right menus are too wide (which I think can be lumped with Jonesey's too much padding comment). If you really want to, you can use my custom css to fix that. If you like Jonesey's style (pictured above, that doesn't look like mine lol), you can also use his. Aaron Liu (talk) 20:31, 15 January 2024 (UTC)[reply]
In V22, the left panel is for two different things: the "Main menu" and the "Contents" (ToC). The Main menu is basically not something that is useful very often. If the "Main menu" is not hidden (and the ToC is also not hidden), the Main menu is shown above the ToC, so you can't see the ToC properly – the ToC is pushed down below the Main menu and doesn't fit on the screen. If the "Main menu" is hidden and the ToC is not hidden, then the left panel appears and disappears depending on what you're looking at. For things that don't have a ToC (like the Wikipedia Main page or an article revision history page or a watchlist view or a "user contributions" list), the left panel disappears, so the central content shifts over all the way to the left. So the place you need to look at on the screen moves left and right depending on whether there's a ToC or not. In V10 the left panel is rather thin and the central panel doesn't move around, so the basically useless left panel isn't as irritating. (I don't see a way to hide the left panel in V10, but I also don't feel a strong urge to get rid of it, unlike with V22 where it is too wide and covers up the ToC.) If the ToC is hidden, there is no ToC visible ever (unless I navigate through a sub-menu). — BarrelProof (talk) 23:43, 15 January 2024 (UTC)[reply]
Editing a section (without simultaneous preview) is another case where there is no ToC, so the text window jumps left. Then doing a preview while keeping the edit view open generates a ToC and makes the main panel area jump to the right. "Show changes" drops the ToC and causes a jump left. The unpredictable left-and-right shifting of the area of focus is irritating and doesn't happen in V10. — BarrelProof (talk) 20:25, 18 January 2024 (UTC)[reply]
Narrowing the left panel is not necessarily a very good solution, since the ToC sometimes has long headings in it (e.g. the headings on this page) and each level of the ToC headings gets indented more. If the left panel is too narrow, a single long heading will require lots of lines in the ToC. I guess that's why it was made wide in V22. V10 is a more clear and predictable experience. — BarrelProof (talk) 20:33, 18 January 2024 (UTC)[reply]
Hmm. I don't see an easy way to fix this or why people would vehemently want to hide the main menu that much. It already throws the balance of the screen off to the left, which I don't like. Aaron Liu (talk) 21:54, 18 January 2024 (UTC)[reply]
Nothing vehement about it. There is a very clear motivation to want to hide the Main menu. At least on my screen, it sits above the ToC, taking up basically all of the vertical space in the left panel, so the presence of the Main menu interferes severely with the ability to see the ToC. If the Main menu is there and I want to see the ToC, I need to scroll down past it before I can see the ToC. (It's also basically a waste of screen space.) — BarrelProof (talk) 22:47, 18 January 2024 (UTC)[reply]
V22 has quite a few accessibly issues for me: there is insufficient contrast between links and background colours (and no difference for colour blind people between used and unused links). It renders some pages unusable, like WP:FAC, by breaking magic words for the TOC. It's too bright, the additional white space sometimes triggers migraines. Weren't we supposed to get a slight upgrade with a better delineation between menus and text and more grey? —Femke 🐦 (talk) 18:13, 17 January 2024 (UTC)[reply]
The issue is separating the colours from one another, between used and unused links. Is there some reason why you are replying to nearly everyone in this discussion, even when you do not understand their comments? -- asilvering (talk) 01:08, 20 January 2024 (UTC)[reply]
The reason for most of my replies is that I don’t understand and wish for clarification. I don’t have trouble distinguishing the two link colors either, but webAIM does say that they have a contrast of 1.01:1. Aaron Liu (talk) 14:48, 20 January 2024 (UTC)[reply]
+1 to all of this. I would add that having no separation at all (by colour, a line, anything) between the TOC and the text of the article makes it very hard for me to use. -- asilvering (talk) 23:50, 19 January 2024 (UTC)[reply]
The links I use most often are now hidden behind a menu. In Vector2010 I have links to talk, sandbox, preferences, beta, watchlist, contributions, and mentor dashboard all right there. Personally, I don't use all of those all that often, but I don't know why Talk, Sandbox, Watchlist, and Contributions aren't available in a single click. -- asilvering (talk) 23:55, 19 January 2024 (UTC)[reply]
To me, the dropdown is alright as it shortens mouse travel by converting long horizontal over words to much closer vertical movement. Aaron Liu (talk) 01:07, 20 January 2024 (UTC)[reply]
All of it. The fact it uses a small portion of the screen, the removal of the TOC, the language choice being hidden in a menu. Worst of all it is the default and you cannot remove it without an account. Just make V10 the default and let the people who like this crap use it. Tarkalak (talk) 18:41, 11 February 2024 (UTC)[reply]
WP:V22RFC2, the RfC on roling back to V10 as default, ended in no consensus. It would make no sense to rollback when the community couldn't gather a consensus to do so.
You can enable unlimited width globally in Prefs or in the bottom-right hand conrner of your screen, which means that the width is bounded by the limits of your screen as it is in V10.
The shift to buttons without words (unless one mouses over) was disorienting. I see the idea behind why the "history" button looks the way it is, and the "edit" button, etc., but that took a long time to get used to, and I'm concerned that it's difficult for new users who may not realize how much they need to pay attention to tutorializing they're offered. Additionally, I think having page tools live by default on the right side doesn't have as much utility as having the table of contents live on the left side. I definitely prefer having the tools on the right side turned off to have a bit more space for page body. P-Makoto (she/her) (talk) 20:33, 22 February 2024 (UTC)[reply]
What features, if any, would you like to be added to Vector 2022?[edit]
Ability to decide what is hidden behind dropdowns and what isn't hidden on the header bar; ability to move items from their Main Menu sidebar to their Tools sidebar and vice versa; preference toggle between sticky and classic TOC modes. Also, max width as the default, or a persistent toggle between limited and max width modes for looged-out users.Cessaune[talk]17:08, 9 January 2024 (UTC)[reply]
+1 For max width as default (now stricken in Cessaune's comment); −1 for all the rest, per my considerations against the moddability craze under Levivich's comment below. Æo (talk) 17:26, 26 January 2024 (UTC)[reply]
I agree that both can be present, especially if the sticky ToC appears when the inline ToC is scrolled off-screen. An alternative would be to have the inline ToC as default, with a toggle to turn it into the sticky ToC. Æo (talk) 17:33, 26 January 2024 (UTC)[reply]
It is not a +/-1 !vote, and I have added a new proposal: the inline ToC as default, with a toggle to turn it into the sticky ToC. Æo (talk) 17:37, 26 January 2024 (UTC)[reply]
Add a comment to the correct section then, as opposed to as a reply on someone else's comment in an unrelated section.
You're advocating for a position—inline TOC as default—that I don't think anyone else has advocated for. People have agreed with an inline TOC/sticky TOC mix, but I can't find anyone actually advocating for reinstating the inline TOC as default. Based on this, it's reasonable to assume that the community, at the very least, doesn't dislike the new TOC. In fact, many people have expressed the opinion that they like it.
The toggle craze to accommodate the whims of any individual user only creates great confusion. I disagree, very strongly, and I'd like to know why you think this.
The website should have a main formal structure. I mean, it does. And it would, even if more toggles were added.
I dislike it so much because I think that it is the element that more than any other (or, maybe, on par with the limited width) messes up the page. I really can't see it, and use it, as a ToC; rather, I see it as a messy navigational menu. The broken and unnumbered sections' titles are an eyesore: they are unpleasant to read and useless for navigating the page. Æo (talk) 18:05, 26 January 2024 (UTC)[reply]
Hmm. "Useless" is an objectively untrue statement. That being said, I see what you're saying. How would you improve it, as opposed to simply removing it? Cessaune[talk]17:23, 1 February 2024 (UTC)[reply]
The ability for the two top bars to sync their search contents, and a way to order the links in the Tools portlet. I find it weird that userscripts can't customize which position the link will appear in the portlet, especially with WhatRedirectsHere. Aaron Liu (talk) 21:00, 9 January 2024 (UTC)[reply]
See the open Phabricator tasks, many of which have stalled. We still need better contrast, or borders, between the sidebars and the page body. We still need smaller font sizes in the sidebars and much less padding in the sidebars in order to make room for the most important part of the page: the content. We still need the sticky header and the initial page header to have the same contents. We still need the 24 pixels of dead-space padding above the page title to be removed. We still need the sticky header to be enabled on all pages. We need TOC numbering and auto-expansion on all pages. These are basic features that have been straightforward to adjust with custom personal CSS, but they are not available to normal people or logged-out readers. Many bits of Vector 2022 have been improved in the last year, but progress has stalled in the same way that progress on Visual Editor bugs stalled after it was mostly done. – Jonesey95 (talk) 01:18, 10 January 2024 (UTC)[reply]
−1 When you say "We", you mean "I", or is there some good research on what's best for everyone? I do agree there are some half-solutions around that should be worked on, like show/hide sort-of-buttons that are too distracting. 141.138.38.210 (talk) 04:14, 11 January 2024 (UTC)[reply]
The toggle craze to accommodate the whims of any individual user only creates great confusion. The website should have a main formal structure. Toggles everywhere only make it disorganic. V22 already has too many of them. Æo (talk) 15:24, 23 January 2024 (UTC)[reply]
I am aware of it, of course, and I continue to use V10 when I am logged-in. The visions I present here are not intended to criticise V22 and change it out of personal whim or from an individual point of view, but because I think that it is a bad interface for all users and for the Wikipedia project as a whole, and above all for the latter. Wikipedia's goal is to be an encyclopedia based on reliable sources, not to be a user-friendly moddable website. Æo (talk) 15:36, 23 January 2024 (UTC)[reply]
I think that encyclopedias should have a more ordered and serious interface. I think that V22 is a change towards a more social-network-like interface similar to those of Reddit and Quora. Æo (talk) 16:16, 23 January 2024 (UTC)[reply]
The V22 interface has order to it, and is reasonably "serious"; what does a non-serious interface look like? Banner ads? Icons instead of text? Hard, crisp corners as opposed to rounded ones? A floating TOC isn't what you're referring to, is it?
V10 feels and looks 'old' (something that I've thought since like 2017) and V22 simply... doesn't. It feels way more modern. Is that a good thing? Maybe, maybe not. It inevitably brings it inline with the Quoras and Reddits of the online world.
V10 does not feel "old", it feels suitable for an encyclopedia and for use on desktop devices. On the other hand, V22 does not feel "modern", but rather chaotic and more suitable for use on mobile devices. Everything in it contributes to its chaoticity and lack of solidity and therefore seriousness, from icons instead of text, to the use of spaces, to the lack of edges, to floating and togglable menus. Æo (talk) 19:56, 23 January 2024 (UTC)[reply]
Well, I think V10 feels old. Something to do with all the skeuomorphism and gradients everywhere. Feels very 2010.
Why do you think V22 is more chaotic than V10? Like, specifically, how is an icon more chaotic than text? How is a floating menu more chaotic than a non-floating one? I simply don't understand. Cessaune[talk]20:13, 23 January 2024 (UTC)[reply]
V10 is not that much skeuomorphic and the colour gradients are very slight. Remove them, and you will have a perfectly polished "modern" interface. What makes V22 more chaotic and confusing is the general disorganisation and togglability of nearly all the elements on the screen. I continue to think that it was very badly designed, driven by a mere desire to change for the sake of change itself and not by an organic vision of what Wikipedia is. Please take a look at the prototype image I added on January 13th in the section below; that is what I mean when I think of a modern interface that still maintains an order suited to the nature of Wikipedia. Æo (talk) 22:34, 23 January 2024 (UTC)[reply]
The version that you like:
has tons of white space,
has absolutely massive icons that don't need to be that massive,
places things in dropdowns,
equal "togglability" as far as I'm aware (which is somehow a negative thing),
and literally looks tailor-made for mobile.
And this version is somehow better than the current V22?
There are things that I think it does better than the current V22, and there are things that I think it does worse, but one of your main arguments is that V22 feels like a mobile skin. That prototype doesn't even feel like a mobile skin: it basically is. It look like it's been ripped from Minerva. If I were to hold a vote on which skin looked the least serious, that V22 prototype would be a contender. Even Minerva looks more professional, without the random drop shadows and there actually being a reason for there to be massive buttons. Cessaune[talk]22:57, 23 January 2024 (UTC)[reply]
When I use V10, I see a mishmash of icons and text on the top right, a worse search that is clearly too old, a non-standard watchlist icon, clashing design under "languages", needing to scroll back up to access the toolbar, etc. Even after you swap all the gradients and fading with white and flat design, V22 is just more complete in a uniform look and better. Though maybe some of that owes to WMF doing something with the Echo extension. Aaron Liu (talk) 23:13, 23 January 2024 (UTC)[reply]
+1, I stand by the idea that people who want a narrower reading area should resize their browser to exactly what is comfortable for them. ℰmi1y⧼T·C⧽08:19, 17 January 2024 (UTC)[reply]
−1 The Elements of Typographic Style, aka The Bible of typography: no line of text should contain more than 77-or-so characters. We've got more than 150. 205.220.129.21 (talk) 15:47, 24 February 2024 (UTC)[reply]
Move all the text of all the menus to mediawiki so that they can be customised on each wiki per consensus, rather than arbitrarily by devs, who shouldn't be put in that unfair position. - jc3705:03, 10 January 2024 (UTC)[reply]
Putting the right-side menu back where it was prior to this, and not have the TOC replacing it. Removing that set of menus for the TOC, then pushing it to the left side after-the fact was just problematic. Or in other words, do something "else" with the TOC and restore the menus where they were. - jc3705:03, 10 January 2024 (UTC)[reply]
Responsive mode would be something that is absolutely necessary for Vector 2022 (as a toggle) for it to work on mobile. It could be opt in or opt out but it should at least be there, maybe even for logged out users. AwesomeAasim16:03, 12 January 2024 (UTC)[reply]
+1 THIS! I can live with the other annoyances, but tiny text on tablet (TTT) is the reason I switched back to Timeless. (And yes I do use Mobile/Minerva too.) Vector 2022 works fine in narrow desktop windows, this is a viewport/scaling thing not a width issue. (As a pref rather than a toggle: if responsive can be made to work everywhere, then I wouldn't need to be switching back-and-forth.) ⁓ Pelagic ( messages ) 20:37, 1 February 2024 (UTC)[reply]
Preferences for TOCs should be possible in both wikitext and user preferences. For instance, a page like WP:FAC could add wikitext so that the TOC shows only the clickable list of nominations, not a tidal wave of user comments. Or, I could set the TOC to not display user comments (like "Bilorv, 00:00, 1 January 1970") and have numbered sections. I'm not sure what, if anything, is possible already. However, we used to have wikitext that could limit the TOC to level X and below subsections. For lists with alphabetical or numbered sections we used to have horizontal TOCs that worked well, so I think an optional horizontal inline TOC (in addition to the floating TOC) may also have occasional use cases. — Bilorv (talk) 00:16, 14 January 2024 (UTC)[reply]
Under the Accessibility for Reading tab, an option that allows users to decide how dense the layout is. I would describe the current density as 'comfortable'. There could be a 'dense' version that get rid of as much empty space as possible, and the default would be somewhere in between. Cessaune[talk]18:22, 26 January 2024 (UTC)[reply]
+1 Yeah, if I could add some custom links (with custom labels) to the top of the interface (shrinking the search box), that'd be really nice. — BarrelProof (talk) 18:29, 27 January 2024 (UTC)[reply]
If you mean get a permalink, the "Permanent link" link in the Tools menu provides a permanent link, usually to the page but if you click on a section before clicking it it provides the link to the section. Aaron Liu (talk) 12:38, 29 January 2024 (UTC)[reply]
I think there's a terminology issue here. I'm not looking for a way to create links to specific versions of pages. I'd like to be able to add a few clickable links of my own choosing (or a submenu that lists such links) at the top of the interface. For example, I could add links that take me to WP:RMCD, WP:RMTR, WP:RfD#Current list, and WT:MOS so I don't have to type those in manually. — BarrelProof (talk) 17:33, 29 January 2024 (UTC)[reply]
Thanks. I tried the Bookmarks code, and it seems to work, but I don't like the idea of linking to code that's editable by someone else – an obvious security problem. Simply copying the code into common.jsdid not seem to work. I might also prefer to put links directly at the top of the page instead of in the Tools section, which is a submenu for me because I keep that side panel hidden, and the links get listed pretty far down in the Tools menu. (A smaller font and tighter line spacing in the Tools menu would be helpful.) I looked at PortletLinks, but I don't understand what a portlet is, so I don't know what that does. I might try Quick Links. — BarrelProof (talk) 19:58, 2 February 2024 (UTC)[reply]
@BarrelProof I'm quite a bit late, but a portlet is just a collection of links, e.g. the main menu, the tools menu, links related to the user, links at the top, the log out link (yes that is its own portlet), and the portlet with the "Move" link in it. Aaron Liu (talk) 00:15, 8 April 2024 (UTC)[reply]
Yes, right. The permalink option should be visible on the page itself, not in a menu, e.g. as a "[Permalink]" marker next to the section title. I was not able to find this function in the menu(s) last time I tried. Sandstein 09:32, 1 February 2024 (UTC)[reply]
Provide a way to hide my username. Does that exist already? It's a privacy violation for everyone who looks over my shoulder to be able to see that. — BarrelProof (talk) 18:29, 27 January 2024 (UTC)[reply]
Just provide a check box in the Appearance menu to convert the Username display to a simple indicator of whether I'm logged in or not, without showing the Username itself, and provide a link to show the username under the Tools menu. I know what my username is already, so I don't need to see it, and I don't want everybody else to know it. I'm 100% sure there have been several occasions when other people have been able to see my username when I didn't want them to. Sometimes I log out just to avoid it being visible on the screen. Sometimes I scroll down just to push it off the screen. Consider what the prominent username display does to a teacher or professor or public official, or just anyone who doesn't want their whole edit history and Talk page commentary easily accessible to their random acquaintances and family members. In fact, I think the username should be hidden by default. Why is it there, at the top of every page? — BarrelProof (talk) 18:52, 27 January 2024 (UTC)[reply]
Because that's how it is, on most sites, and how it's been for a very long time. In this sense, privacy is traditionally handled by the user. Cessaune[talk]20:10, 27 January 2024 (UTC)[reply]
Whether traditional on other websites or not, it's WP:DOXING, and I see no justification for it. If done by a Wikipedia user, involuntarily revealing the connection between a real-world identity and a user account would be grounds for an immediate block. Also, Wikipedia differs substantially from other websites in its purpose. It is primarily a resource for publicly-available information, which people want to consult and show to others – but the identity behind a user account is clearly intended to be private (despite the edit histories being public, which some people don't really realize – heck, I doubt I realize the full implications of that myself). — BarrelProof (talk) 20:46, 27 January 2024 (UTC)[reply]
I very strongly disagree that this can be considered doxing. This doesn't line up with anything on that page at all. It's a completely different, separate idea.
...involuntarily revealing the connection between a real-world identity and a user account would be grounds for an immediate block—depends on the context. If you do so involuntarily? Definitely not. A lot of the time, it's barely even sanctionable. In my limited experience, someone points to WP:DOXING with a stern warning, and the comment is rolled back. A second offense is typically sanctionable, and possibly block-worthy.
despite the edit histories being public, which some people don't really realize—edit histories should be public, and I hope that you aren't saying that it shouldn't be.
There's nothing wrong with wanting privacy. I like the idea. But it is still, and should still continue to be on the user to make sure that they are staying private. It's not Wikimedia's job to make sure that you don't inadvertently divulge your Wikipedia account. Cessaune[talk]01:18, 28 January 2024 (UTC)[reply]
OK, maybe I was being a little over-the-top, but the point I was trying to make is that revealing information that connects a real-world identity to a user account should be considered a serious matter. I guess the word "involuntarily" has different meanings. I was referring to revealing someone's username without first obtaining their informed consent (i.e., that the person has not voluntarily agreed for that information to be revealed), not revealing it accidentally. I strongly believe we should not just try to blame the user for the loss of privacy resulting from this information being displayed at the top of every page. — BarrelProof (talk) 21:08, 28 January 2024 (UTC)[reply]
@BarrelProof: I spent some time looking at the W3Schools website for JavaScript [1] and the code here hides the username from being displayed from the top bar. However, I know very little JavaScript, so whether that's actually the best way to do it is unclear. 🌺 Cremastra (talk) 20:12, 27 January 2024 (UTC)[reply]
Thanks for that. I'm trying it. However, aside from being a code customization feature that only a tiny fraction of Wikipedia users might be able to comprehend and use, I notice 1) a warning saying "Note that it sometimes takes the browser a second or two to load and execute user scripts, during which interval your real username will briefly be visible, so this script should not be considered foolproof." and 2) A warning saying "Code that you insert on this page could contain malicious content capable of compromising your account." Following the instructions for manual installation does indeed appear to link to source code that can be edited by someone other than me. Both of those aspects seem worrying. To try to mitigate the second issue, I copied the code rather than linking to it, and that seems to work. — BarrelProof (talk) 18:12, 29 January 2024 (UTC)[reply]
+1 I don't normally use WP in contexts where I would need this, but now that you mention it I see the value. As Aaron says, would be nice for it to be an official feature: is more discoverable if it's listed in Preferences. ⁓ Pelagic ( messages ) 20:45, 1 February 2024 (UTC)[reply]
A fast toggle between mobile/desktop view. Currently, you have to scroll down to the bottom of the screen to find a link. This scrolling can take a long time on big pages. A standard option to jump to the bottom/top of such big pages would be useful too. See {{skip to top and bottom}}. Andrew🐉(talk) 11:09, 23 February 2024 (UTC)[reply]
I'd doubt the use of that. On mobile, it is incredibly convenient to just drag the right scrollbar, and on desktop you can edit the link on the top to add or remove dot-m. Aaron Liu (talk) 15:14, 23 February 2024 (UTC)[reply]
Don't assume people (even frequent users of desktop mode) understand how to use the mobile version. I seldom use it. When I do use it, I get frustrated quickly and look for how to switch to the desktop mode to accomplish what I'm trying to do, which should be easier to find than being buried at the bottom of the page. I just tried to use it while responding to this, and I couldn't find that right scrollbar you're talking about. We're talking about the mobile mode in a browser, right (not a mobile app)? And editing the URL is not something I would expect many people to understand or be able to do (and some mobile browsers seem to make that very difficult). — BarrelProof (talk) 17:23, 23 February 2024 (UTC)[reply]
Eh, I mean... is this an issue with the skin itself or a skill issue (can't use that term unironically without cringing)? IMO anyone who knows how to work Chrome or Safari on a phone won't have an issue with mobile Wikipedia. It's pretty standard. Cessaune[talk]17:48, 23 February 2024 (UTC)[reply]
It's a UI issue. User interfaces should be designed to be easily navigable and minimize the difficulty of switching between access modes. Please don't get in the habit of blaming users for UI difficulties. I suggest to go read some Don Norman. — BarrelProof (talk) 17:55, 23 February 2024 (UTC)[reply]
Well, what is the specific issue with the mobile skin UI that makes people not be able to understand/use it as effectively as the desktop skin, that isn't also intrinsically tethered to the browser UI? Cessaune[talk]18:01, 23 February 2024 (UTC)[reply]
We should not assume users of the mobile skin have gone through (or should go through) the learning curve on how to use that mode. Some of them will want to switch to desktop mode simply for familiarity, and the UI should be designed to make that easy to do. Making the two modes more similar (or analogous) to each other could also help. I see this is at least the second time you've voiced a "blame the user" opinion here (see "it is ... on the user to make sure that ..." above). UI design should involve trying to solicit feedback and make user experience easier, striving very hard to not blame users for problems they experience. — BarrelProof (talk) 18:09, 23 February 2024 (UTC)[reply]
I don't intend to blame the user simply to blame the user. It just seems to me that if users can't use a mobile browser (which, let's be honest, is an often clunky experience) they wouldn't be able to use the mobile skin very easily. And the vast majority of mobile users are readers, which means that they aren't doing anything intensive, unlike you. Should the mobile skin be better designed for tasks such as editing? Yes. Cessaune[talk]18:19, 23 February 2024 (UTC)[reply]
Every mobile browser has a scrollbar on the right. You can search that up. For the editing URL part, I mean that if one is on desktop but gets sent a link to mobile. Enough desktop users should be expected to know that. Aaron Liu (talk) 18:15, 23 February 2024 (UTC)[reply]
Aaron Liu's claims about scrollbars don't seem to work for my mobile device which is an iPhone. In Safari, a scrollbar does not appear initially. If you start scrolling by swiping then a scrollbar appears but you can't grab and drag it. See Apple Support for confirmation. See also Apple has gone to extraordinary lengths to make scroll bars invisible.
Looking into this further, I find that there's now an iPhone gesture to go to the top of a page -- you touch the top of the screen. But there doesn't seem to be an equivalent gesture to go to the bottom of a page, where the Mobile/Desktop toggle is hidden for Wikipedia.
Similar experience for me with Firefox on Android – no scroll bar until I start swiping, and the scrollbar is just a thin subtle indicator with no grab-and-slide capability. Maybe I'm just missing something. — BarrelProof (talk) 00:08, 24 February 2024 (UTC)[reply]
Well, it appears that I have been spoiled by iOS Safari, where you can grab-and-slide. Pretty sure Firefox for Android also offers a button in the menu to switch to the desktop view that should prevent you from getting redirected to the mobile view, though also unlike iOS Safari that doesn't automatically switch a mobile link to the desktop one. Aaron Liu (talk) 03:28, 24 February 2024 (UTC)[reply]
I found a video tip which explains that you can grab the scroll bar in iOS/Safari by doing a long press on it. It then becomes thicker and you can drag it. But, as the video demonstrates, this is easier said than done and that's my own experience of trying it just now. I'd still prefer a standard {{skip to top and bottom}} on long pages. I have this set up on my own talk page as it's long and it provides a clear visual clue. Andrew🐉(talk) 00:00, 25 February 2024 (UTC)[reply]
When I try that, it often selects some text instead. It seems too unreliable and klunky to be a good method of jumping to the bottom of the screen. The top tap as a method of jumping to the top of the screen is the sort of intuitive and reliable gesture that I prefer. But now I know and understand the way to grab, I may try it further and perhaps my finger will develop more facility. Andrew🐉(talk) 09:28, 25 February 2024 (UTC)[reply]
Aside from all that, you need to know that the link is down there hidden at the bottom of the page before you can even look for it. That's too obscure. — BarrelProof (talk) 18:14, 24 February 2024 (UTC)[reply]
Indeed. And it's not consistent. When I use the browser mobile view on Wikipedia, it offers me an option to view the content in the Wikipedia app. The link for that is at the top left of the screen. As they are both similar mode switches, it doesn't make sense to have one at the top and the other at the bottom. Andrew🐉(talk) 00:03, 25 February 2024 (UTC)[reply]
It actually does, slightly. The thing at the top is called a smart app banner in WebKit (Safari) and a native app install prompt anywhere else. It's a specific hook for the browser, for which anything other than an app install cannot be put in. That's not saying they can't put thing at the top (or the sidebar), but it's probably going to look different from the app install prompt. Aaron Liu (talk) 01:14, 25 February 2024 (UTC)[reply]
It's good to know what that banner is called, thanks. I had a lot of trouble resetting it after beta-testing the iOS Wikipedia app and it might help to know its name if I do that again. Andrew🐉(talk) 09:25, 25 February 2024 (UTC)[reply]
What features, if any, would you like to be modified in Vector 2022?[edit]
−1 For the narrower sticky ToC. It is already too narrow for the length standards of section titles of many articles and talk pages. This is indeed another very negative feature of the sticky ToC. I do not have any examples at hand, but there are articles and talk pages that require very long section titles. Æo (talk) 22:58, 30 January 2024 (UTC)[reply]
−1 For standards of "fitting everything on a single line"? Sure, it's way too narrow. But for balancing between content size and navigation? It's already more than enough. Aaron Liu (talk) 02:58, 31 January 2024 (UTC)[reply]
+1 Maybe this is partly a screen size issue. I wonder what size screen Æo is using. I use a high-quality conventional business travel-oriented laptop. My screen has high resolution, but it's only 113⁄4″ wide (14″ diagonal). Width is precious (so is height, but let's focus on width for now). I want to use my screen for the main content. By default, V22 is only using 65⁄8″ for the main content text and graphics area. Shrinking the font size in the side panels would help. Shrinking the empty margin areas would help. Providing an option to show the ToC in-line instead of in a side panel would also help. Hiding at least one of the side panels and using the full width of the screen by default would help. I doubt most readers have big monitors. — BarrelProof (talk) 17:13, 1 February 2024 (UTC)[reply]
I use an 11" Chromebook most of the time, and a 27" LG monitor occasionally. Width is very important on the Chromebook. Not so much on the monitor. Cessaune[talk]17:17, 1 February 2024 (UTC)[reply]
Hiding the ToC makes it show up as a button next to the title with maximum width when clicked, which I think along with hiding the main menu might help you. Aaron Liu (talk) 17:17, 1 February 2024 (UTC)[reply]
Too soon to say for sure, but so far I like that a lot. I really had forgotten it was there, even though there was a message telling me about it when I hid the ToC! (Maybe that message should use boldface or be highlighted with colour or should stay on the screen longer.) And now I see the ToC in the sticky top bar too, which I really like a lot. (I have pity for people who aren't familiar with the hiding and full width options – one needs four well-aimed clicks to hide the main menu, the ToC and the toolbar and to switch the main column to full width; maybe the full width option should hide both side panels, so that all takes only one click.) — BarrelProof (talk) 17:44, 1 February 2024 (UTC)[reply]
The screen of my laptop is rather large, about 17". Yes, I think that V22 does not scale well on large screens. Æo (talk) 17:41, 1 February 2024 (UTC)[reply]
Because of the big and meaningless white spaces. The white band on the right side of the page occupies 1/3 of the screen. V22 is simply not designed for wide screens. Æo (talk) 00:01, 2 February 2024 (UTC)[reply]
I have a ~35" screen and even if I disable css, zoom in to the point where the max-width button disappears, and enable the tools menu, neither floating bar comes close to taking up 1/3 of the screen. Or did you not click on the max-width button? Aaron Liu (talk) 00:54, 2 February 2024 (UTC)[reply]
On my 14″ screen (113⁄4″ wide), if the full width option is disabled and the side menus are hidden, the white areas on the sides are about 21⁄4″ each, so about 19% each or 38% total. They get a little wider, 21⁄2″ or 21% each or 43% total, if the side menus are not hidden. This includes all margins as well as the text area in the sidebars. When the side menus are not hidden, the full width option makes no difference and the central content area gets 57% of the width. — BarrelProof (talk) 02:18, 2 February 2024 (UTC)[reply]
I think the point of maximum width makes it so the center area can't get bigger after reaching a point, even if the tools sidebar is hidden. Aaron Liu (talk) 03:04, 2 February 2024 (UTC)[reply]
Vector 2022 screenshot, taken on 23 Sept 2022 or earlier
I have no white band of such a colossal size on any side of my screen regardless of how big my screen is. Are you sure you're viewing it in max width? I think that the white bands used to be mandatory regardless of max width/limited width during the V22 transitionary epoch, and that has since been changed. One of my major qualms with V22 was the almost objectively obscene amount of whitespace, as illustrated in the image. Cessaune[talk]02:53, 2 February 2024 (UTC)[reply]
The terminology may be a bit confusing here. When I refer to "full width" above, I'm referring to what the button instructions that pop up in the lower-right corner refer to as "full width". That's not the same thing as what people here are calling "maximum width", which is what the button instructions refer to as "fixed width". When I say the "the full width option is disabled", I'm referring to the "fixed width" mode. (I think the pop-up button instructions should stay on the screen longer so the user has more time to read them.) — BarrelProof (talk) 19:17, 2 February 2024 (UTC)[reply]
When I said "the full width option is disabled", I meant I was in "fixed width" mode, not "unlimited width" / "full width" mode. In full width mode, when the side bars are hidden, the margin areas are only about 3⁄8″ on either side. — BarrelProof (talk) 19:30, 2 February 2024 (UTC)[reply]
Everything that I have expressed in my answers to the previous questions, plus the numbering of the titles of the sections in the ToC.--Æo (talk) 19:48, 9 January 2024 (UTC)[reply]
I also have my personal CSS, which is forked from Jonesey but doesn't do anything too radical. It restores old link colors, also makes the sidebars have a reasonable width, and also removes unnecessary links. The last two are also done by Jonesey's, though not link colors, and his does a lot more radical changes. Oh yeah, I forgot to mention that a way to differentiate between intrawiki and outside-wiki links would be nice. Aaron Liu (talk) 03:10, 10 January 2024 (UTC)[reply]
The collapsed ToC icon could still improve. Much better from when there wasn't any, but it's still a weirdly offset in the corner icon that also leaves that corner when you're at the top of the page. This is a holdover from when the solution was a button near the title, which still doesn't work as it's more difficult to find and not obviously a button. Make it more obvious and in-frame (the whitespace remains even then the table is collapsed!), leave it in frame persistently when the ToC is collapsed. (I also don't know why it doesn't expand on click instead of coming up as a menu with an expand option, but maybe this is more stylistic.) CMD (talk) 05:23, 10 January 2024 (UTC)[reply]
I think that this early V22 prototype is greatly superior to the current V22, and at the same time an improvement compared to V10. It would embody the "rational article structure/geometry" mentioned in my comment, both the inline ToC and another version of the sticky ToC (hidden), and other interesting features. Æo (talk) 18:12, 13 January 2024 (UTC)[reply]
Restore a rational article structure/geometry (see the image with a prototype), which would entail a restoration of the inline ToC which gives a clear image of the article's contents and at the same time separates the article's lead from the article's body (a separation which is no longer well-defined in V22). Cf. Dc.samizdat's 20 January 2023 comment.--Æo (talk) 18:12, 13 January 2024 (UTC)[reply]
Yeah, but it's clear that the lead is separate from the body already. At least, I find it pretty obvious. I don't think we need acres of empty whitespace to prove that point. Cessaune[talk]21:01, 13 January 2024 (UTC)[reply]
If you want to add an argument to it, just reply to it. Especially don't just put it into "modified" when you want it to be added.The floating ToC also tells you the contents. And again, section headers should be enough for separation. Aaron Liu (talk) 20:57, 13 January 2024 (UTC)[reply]
Sticky top bar improvements:
Make it show up on every page, not just in reading mode. I especially sometimes find myself wanting to use it while editing.
Replace the languages menu in the floating top bar with the notifications interface and the button form for the accessibility prototype. (Note that I still vastly prefer its button being in the lower-right corner like the width toggle)
Differentiate the right-hand margin for pictures and tables as opposed to text. The text could be even narrower but this would limit the ability to throw pictures in and also limit the width of tables too much. Would love to see research on how table width effects readability - I would suppose skinny is better but not as much as text. Wizmut (talk) 08:17, 17 January 2024 (UTC)[reply]
I don't understand the question. On tables, I mean that tables are designed to span the entire article container's width and should not be confined to a narrow margin. Aaron Liu (talk) 01:22, 19 January 2024 (UTC)[reply]
That was my point. There's a non-zero chance that people will ask for text to be narrowed even further, and if they win, I wanted there to be a way for tables to be a little more wide, or an option for it. And (long shot) research on table width like there's been for text.
Same with letting images not get the squeeze in the future, if a further squeeze ever comes. Unless, of course, people decide it's much worse after trying it. Wizmut (talk) 01:29, 19 January 2024 (UTC)[reply]
There is an equally likely chance of your house being shrunk by a meteor or the graphs extension being redeployed before winter (or summer if you walk upside-down) ends. Aaron Liu (talk) 01:36, 19 January 2024 (UTC)[reply]
The inline ToC and the sticky ToC are two different things, and, in my view, the latter is more a side table for navigating the articles or discussions than a full-fledged ToC. Some commentators in this RfC even propose keeping both in the interface. It would be a good idea to better differentiate the two even in name. I propose "Table of Contents" (ToC) for the inline ToC and "Table of Navigation" (ToN) for the sticky ToC.--Æo (talk) 18:16, 18 January 2024 (UTC)[reply]
I strongly disagree with changing the name to “Table of Navigation”. Maybe they serve different functions, but both are ToCs. They share equal prowess in navigation and the auto collapsing by default gives a better view of the actual contents IMO. Aaron Liu (talk) 18:21, 18 January 2024 (UTC)[reply]
As further discussed below, the search box autocompletion behaviour relating to redirects in V22 is complete nonsense. It does not display the names of redirects when the user is typing into the search window. It shows the names of candidate destination articles, but not the names of redirects, and the names of the candidate destination articles often have no obvious relationship to what the user is typing. For example, typing "build a f" will display the candidate destination article Fly Me Courageous without any hint about why it is offering that article to the reader. Also, when the user selects a destination article from what is shown, the selection bypasses the redirect, so no explanation is shown at the top of the destination page to indicate why the user landed on that page. The autocompletion also seems to often ignore redirects in preference to article titles when selecting the candidate destination articles to offer to the user – for example, typing "Hurric" in the search box will generate a list of candidate destination articles about particular individual hurricanes, but the main article for Hurricane will not be offered in the list (because that is a redirect). — BarrelProof (talk) 01:59, 22 February 2024 (UTC)[reply]
Moved from #Proposed changes
Does the search box behave the same in V22 as in V10 (desktop)? For me, when I'm using V22, the search box doesn't seem to show autocomplete results for redirects. Instead, it shows the name of the destination article of the redirect. For example, if I'm in V10 and I type "build a f" in the search box, it shows the autocomplete suggestion "Build a Fire". If I click on that, it takes me to Fly Me Courageous, because that's where that redirect leads, and it puts a note at the top that says "(Redirected from Build a Fire)". But if I'm in V22, when I type "build a f", it just directly shows me "Fly Me Courageous // 1991 Studio Album by Drivin' N' Cryin'". It's not obvious why it's showing me that. "Build a Fire" doesn't appear anywhere on the screen. And if I click on the Fly Me Courageous suggestion, it doesn't pass through the redirect – there is no note at the top saying "(Redirected from Build a Fire)". I can't see what was the name of the redirect that it used to get me there. — BarrelProof (talk) 05:26, 20 February 2024 (UTC)[reply]
I definitely want to see the name of a redirect that I am being suggested to follow – even if only to figure out whether the redirect is related to what I am searching for. In the above case, if I was looking for "build a football stadium", I don't want to use the "Build a Fire" redirect to go to the "Fly Me Courageous" article, but I have no way of seeing whether the redirect is for "build a football stadium" or "Build a Fire" or something else. Also, when I end up somewhere because of a redirect, I definitely want to see some indication of what redirect sent me there. — BarrelProof (talk) 20:04, 20 February 2024 (UTC)[reply]
If you pressed enter with the redirect in the search box, you'll get the "Redirected from..." note. I don't see much use in finding out why "build a..." suggests "Fly Me Courageous". Aaron Liu (talk) 22:16, 20 February 2024 (UTC)[reply]
If I press enter after typing "build a f" in the search box, I get a page of search results that starts with "The page "Build a f" does not exist. You can create a draft and submit it for review, or you may create the page "Build a f" directly, but consider checking the search results below to see whether the topic is already covered." Then it shows a list of search results starting with Lockheed Martin F-22 Raptor, with the 'F' in boldface. — BarrelProof (talk) 23:04, 20 February 2024 (UTC)[reply]
I mean with the redirect in the search box. Pressing enter with "Build a Fire" in the search box sends. I do see what you mean by "see some indication of what redirect sent me there" now. Maybe it should display both the redirect and the target in the search? Aaron Liu (talk) 00:43, 21 February 2024 (UTC)[reply]
Yes, if it is suggesting an article as a search result because of a redirect, it definitely needs to clearly display the full name of that redirect that is causing it to make that suggestion (preferably in boldface and with a font size bigger than the name of the article that is the target of the redirect if that article title needs to be shown at all). Otherwise, what the search is displaying is complete nonsense. It should also go through the redirect to get there if I pick one of those topics, so that the displayed page contains the explanation at the top. — BarrelProof (talk) 02:45, 21 February 2024 (UTC)[reply]
Is this section just redundant with the sections for "What features, if any, would you like to be added/modified/removed from Vector 2022" above? Where should I put a suggestion to modify the search box behaviour in V22, as discussed below above? — BarrelProof (talk) 20:14, 20 February 2024 (UTC)[reply]
−1. The sticky ToC is by no means "useless", at the worst it's a separate feature from the inline ToC, which I'm pretty sure Æo also once echoed. Aaron Liu (talk) 21:00, 9 January 2024 (UTC)[reply]
−1. The sticky TOC is most definitely not useless. It is part of the practical and natural progression of the internet, and the ease at which we view text on a screen. There are arguments to be made that it could be implemented better, or that it could be improved. Cessaune[talk]21:15, 9 January 2024 (UTC)[reply]
The inline TOC should be the gadget, if anything. The sticky TOC is/was hated by editors mainly (per the previous RfC) and editors can change it in their prefs if they care. Cessaune[talk]21:23, 9 January 2024 (UTC)[reply]
it is very hard to participate here as a regular user without feeling like i'm breaking a bunch of rules. but i am primarily a read and hate the sticky TOC by default Unnecesseraj (talk) 03:22, 1 February 2024 (UTC)[reply]
@Unnecesseraj: Thank you for your opinions. Please use only one account to edit articles and participate in discussions (as I read in your <03:27, 1 February 2024> below that you created many of them just to disable V22). Feel free to add +1 or -1 below the comments you agree or disagree with in this RfC. Æo (talk) 15:52, 4 February 2024 (UTC)[reply]
−1 Having the ToC stick at the side of every page has made navigation pages much easier. I was initially skeptical but have really come around to appreciating it, in both mainspace and talkspace. P-Makoto (she/her) (talk) 18:21, 25 February 2024 (UTC)[reply]
The unlimited width toggle as width should be dynamic and based on the current width. Anything longer than the A4 or whatever ratio should be cropped. The width could be adjustable by collapsing the sidebars not by clicking some button. AwesomeAasim15:47, 14 January 2024 (UTC)[reply]
I meant window width. So the width of the content dynamically adjusts with the resize of the window until it reaches a point where it would be too large. AwesomeAasim21:07, 14 January 2024 (UTC)[reply]
Isn't that already what we have? When the width of the window is smaller than the maximum width, the width will not be made limited. Aaron Liu (talk) 23:26, 18 January 2024 (UTC)[reply]
Generally, what features are you looking for when it comes to a Wikipedia skin?[edit]
Efficiency when it comes to editing and viewing, which for me means visually simplistic design, clearly delineated sections, and a lack of unnecessary buttons to press. Cessaune[talk]17:08, 9 January 2024 (UTC)[reply]
Simplicity and efficiency. I'm not looking for a lot of fancy widgets, just something that gets done what I need done and otherwise stays out of my way. Wikipedia is not, and should not be, a clone of the Twitbookinstatube type sites. SeraphimbladeTalk to me14:04, 10 January 2024 (UTC)[reply]
Moddability and modularity, the ability for users to customize their skin as they wish to and choose which options are more convenient for them. ChaotıċEnby(t · c)15:30, 11 January 2024 (UTC)[reply]
Efficiency and ease of use for both reading and editing. For the following, I'm primarily thinking about the contrast between Vector 2010 and 2022 (and I briefly checked on a couple things while writing this, but the rest is based on what I remember from my previous tests). However, this is also generally applicable, with the important principles being:
Minimized number of clicks to access Wikipedia functions (contributions, history, Twinkle menu, etc). Nothing should require more clicks than it did on the previous skin. Dropdown menus should continue to be accessible by rollover.
Minimized requirement for scrolling. In particular, this means the screen should have maximum information density. In Vector 2022, the TOC is an improvement over 2010, but the benefit is far outweighed by the whitespace issues, which have been mitigated but not corrected. Among other things, it makes it much harder to evaluate an article as a whole or identify the parts of an article that I'm interested in.
Customizability so that I can optimize for my specific situation. For Vector 2022, this includes: 1) control over the margins, including the width of the TOC, its information density (which I would want to be comparable to the text), and the amount of whitespace on either side of it, 2) full control over the contents of the header; at minimum it should be possible to look identical to Vector 2010, and 3) ability to maintain simplicity by individually hiding links that I don't want, or moving them to dropdown menus.
Minimum necessary adaptation; it should not be necessary to relearn the interface. Links should not be moved or renamed without good reason, and text links should not be replaced with icons. If any such changes are absolutely necessary, the number that are mandatory should be no more than two or three in total. Any others should only be introduced as an option, with the previous version being the default. If that is not feasible for any reason, then the last resort would be to release multiple versions of the skin that reflect incremental changes, to allow adaptation to happen in parts.
Backwards compatibility with all commonly used scripts, such that the previous four principles are maintained, including for the functionality provided by the scripts.
Well put. I won't add walls of text to this page because, having opted out of Vector 2022 immediately, I know less about it than most. However, Sunrise's comment neatly sums up why I'm in that position. Certes (talk) 15:13, 18 January 2024 (UTC)[reply]
I feel like if anything, visual consistency should come before retaining, especially since Echo is icons-only for some reason. However, a setting for this would indeed be nice. Is V22 somehow not compatible with most scripts? The scripts on the list all seem working to me. Aaron Liu (talk) 15:56, 18 January 2024 (UTC)[reply]
Is there anything else relating to Vector 2022 that you would like to mention?[edit]
The delivery of Vector 2022, especially Zebra, was a bit opaque. Updates aren't that common, the team seems to have suddenly moved on to other stuff, and the deployment of Zebra wasn't mentioned in Tech News. Aaron Liu (talk) 21:00, 9 January 2024 (UTC)[reply]
Like many WMF projects, it has been left in an unfinished state. Developers tend to move on to new, shiny projects. Power users are left to resolve outstanding bugs and feature requests with their own CSS hacks. – Jonesey95 (talk) 01:08, 10 January 2024 (UTC)[reply]
I like it better than the old skin and I'm glad it's live. It still feels like it's a website from 10+ years ago unfortunately. It doesn't have the modern features ("responsive," "dynamic," whatever today's buzzword is) of most other top websites, like any major social media platform for example, or like the Google suite. I know that the web design for logged-out readers has limitations that no other website has because of the whole three-edits-per-second thing, but I hope the WMF allocates some resources to developing an actual modern UI for logged-in users. So basically like at any other platform, this content creator wants you to spend more money making it easier to create content on your platform and not just view it :-) Levivich (talk) 01:37, 10 January 2024 (UTC)[reply]
Oh things like... I should be able to archive a thread on my talk page by dragging and dropping it into a folder on a sidebar. Or when I go to a talk page, it should just display all new messages in all threads, grouped by thread, like an unread inbox. Or having a watchlist that looks more like a social media feed -- there are user scripts that sort of get you there with edit previews, but I should be able to read and reply to discussions without leaving my watchlist, and maybe even edit articles without leaving my watchlist. Live editing of drafts or userspace pages (and maybe even articles if they're not in super high demand?), a la Google docs, would be super helpful. As another example, I can click-and-drag a picture from Commons into a Google doc, but not into a Wiki article or talk page (Visual Editor thinks I want to upload). I'll stop here. Levivich (talk) 02:12, 10 January 2024 (UTC)[reply]
Reading and editing talk page on mobile mode is near impossible with the indenting of conversations being manually done. ~ 🦝 Shushugah (he/him • talk) 01:38, 13 January 2024 (UTC)[reply]
As I'm often involved in events with new users, I felt obliged to make it my default. I've gotten used to it and don't have any strong views on how it compares with previous versions – it does much the same job, once you know where to click. It doesn't seem significant compared to issues like the default size of thumbnails or the broken state of graphs for a year now. Andrew🐉(talk) 19:23, 11 January 2024 (UTC)[reply]
Some Wikimedia projects either never switched to Vector 2022 or at some point switched back to Vector 2010, probably because such projects' respective communities found V10 to be much better than V22. They include the German, the Italian, and the Russian Wikipedia, and possibly other Wikipedias and Wikimedia projects which I am not aware of. How will this discrepancy in choices between different projects be addressed? How could this affect the English Wikipedia? --Æo (talk) 23:10, 12 January 2024 (UTC)[reply]
How many complaints from logged-out users about the "inadequacy" of V2022 are we getting here per week or month, absolute and percentage? Do logged-out users really care what the skin is? All others can choose their skin - what's the most popular choice on the English Wikipedia? Never understood all the fuss, never understood all the rebellion. 94.44.116.76 (talk) 00:23, 13 January 2024 (UTC)[reply]
Even within the English wikis as a whole, other projects (en.wiktionary.org, for example) retain V10 as default, and no one's whining about such a discrepancy as far as I'm aware. So I don't really see why having different skins between different language projects is that big of a deal. Other Wikipedias will form their own opinions about what to do/what not to do, and it should stay like that. Cessaune[talk]22:07, 14 January 2024 (UTC)[reply]
Maybe V22 should have been called something other than Vector. V10 retained most of the Monobook interface while changing the design language while V22 did the opposite of that, which is also a pretty big change. Maybe it should’ve been called Scalar, or even da Matrix? Using the year number is a bit long and clunky. Aaron Liu (talk) 15:59, 18 January 2024 (UTC)[reply]
+1 Putting the year in the name and making that the only difference from the V10 name also implies an inevitable progression through time. Moreover, in the actual Appearance menu, V10 is called "Vector legacy (2010)" and V22 is called simply "Vector (2022)". This all labels V10 as "old" and implies that it should be avoided and will eventually be removed. These seem like pushy marketing-oriented choices rather than providing straightforward descriptive labels. I can only assume "legacy" wasn't part of the original name of V10. I suggest renaming V22 to "Spacious" and renaming V10 back to whatever name it had before V22 was promulgated (certainly removing "legacy" and removing the year from the name). — BarrelProof (talk) 19:40, 26 January 2024 (UTC)[reply]
I strongly disagree with naming V22 "Spacious". That's a terrible name. As to the legacy thing, well, it is the legacy version. Wikimedia is no longer updating it (with the old skin frozen in its pre-2022 state) and probably won't continue to do so. It is, for all intents and purposes, the "legacy" version. Cessaune[talk]14:29, 31 January 2024 (UTC)[reply]
Yes, the choice of name is pure marketing. "Legacy" is a derogatory term. "Vector" gives the false impression that V10 and V22 are in some way similar to each other but different from other skins. Both words have the effect, probably intentional, of bullying us into "upgrading". Certes (talk) 15:01, 31 January 2024 (UTC)[reply]
Indeed, the declaration that V10 has been "frozen in its pre-2022 state" and isn't being updated further adds to the obvious pressure. These are choices. — BarrelProof (talk) 00:06, 1 February 2024 (UTC)[reply]
Thank you for those insights. I don't agree with every word of it, but Vector 2022 was certainly seen by en.wiki editors as coming from “elsewhere” and being done to them,Certes (talk) 15:05, 31 January 2024 (UTC)[reply]
On desktop, I actively choose to not use V22 in every scenario. I think I would honestly prefer using Timeless (which I have zero nostalgia for, being a relatively new user), because at least things are easier to find in that skin than in V22. Suntooooth, it/he (talk/contribs) 02:19, 31 January 2024 (UTC)[reply]
it felt demeaning to be lectured on how the new design was actually better because some people in some obscure corner of a wikipedia subsite had discussed it for a while. and to see all the negative feedback get dismissed as not conforming to some wide web of acronyms wasn't fun either. I made 2 accounts in the decade before vector 2022. I've made 6 since just to disable it when i'm on a new computer since i don't remember my password offhand. --Unnecesseraj (talk) 03:27, 1 February 2024 (UTC)[reply]
ALL of it. The entire process came off as "Well, I'm the designer and I like how it looks and don't give a shit what anyone else says and how much it messes up everyone's experience. Y'all should just get over it because I know what you like better than you."--User:Khajidha (talk) (contributions) 14:33, 1 February 2024 (UTC)[reply]
Hell, the question of having a rollback to the old style was rejected despite the "clear numerical advantage for those supporting the rollback to the old skin" because "WMF has fixed several of these issues". Which makes no sense. If this new thing was truly better, it wouldn't need all the jiggery pokery to get it to work even half as well as the old one. --User:Khajidha (talk) (contributions) 14:39, 1 February 2024 (UTC)[reply]
Once upon a time V10 also had to be improved. We can't compare a skin that had existed for 10+ years to a brand-new skin. And regardless of your opinion of the close, it closed with no consensus to rollback, and the close review failed. Everything was done within process and WMF didn't dismiss any negative feedback without at least some sort of justification, and at best A/B testing/surveys. Cessaune[talk]15:40, 1 February 2024 (UTC)[reply]
+1 There was extensive prototyping and feedback, which is great. But some of the feedback seemed to be treated dismissively. Early objections to the fixed width were met with “research / best practices say this is better”. Not just on enwiki but even earlier in communities like fr and nl. Some people love the fixed width and some hate it, but adding a customisation choice was firmly resisted. It wasn’t until there was already a user script, and w:en RFC looked like torpedoing the rollout, that they considered making the toggle an official feature. At least that's how I remember it, which I admit mightn't align with other people's memory. ⁓ Pelagic ( messages ) 21:34, 1 February 2024 (UTC)[reply]
You can't please them all. Back in the old days people were against electricity, and cars. Guess what: we now have an electric car, flying in outer space. Gotta try new things, that's how it always worked. 205.220.129.21 (talk) 15:59, 24 February 2024 (UTC)[reply]
If there was an RfC for the original change, I would have strongly opposed it. There are lots of readers online who have opposed it as well (I'm not putting links but you can look it up). Making the desktop site look like a mobile version is not beneficial at all. If I wanted to view mobile on desktop, I can just change it to mobile view. Not to mention the issues it has caused with 2010-installed editors not being able to see what most IP readers are seeing. ~WikiOriginal-9~ (talk) 14:36, 7 February 2024 (UTC)[reply]
Two key points here: First, there was never any consensus to deploy this. There are nearly 47 million registered users on site, of which around 126,000 have preformed at least one action in the last 30 days or so. At the time of the rfc to push this out, only about 300 are noted to have participated. Three hundred may have held Xerxes at bay in 480BCE, but its a number that demonstrated a massive absence of consensus to roll out here since its a minuscule fraction of the roughly 126,000 active editors who were considered "active" at that time (give or take), and is DRAMATICALLY smaller than the roughly 24 million you would have needed to have involved in order to gain true feedback from the community. Second, there was no reason whatsoever for the roll out, just as there was no reason whatsoever for any other change of this nature that the WMF forces on us at the English Wikipedia. Frankly, these constant "updates" to me demonstrate a clear and ongoing pattern of disrupting wikipedia to make a point, which is a blockable offense here and one of the reasons I filed for arbitration on this matter: the WMF has never - not once in its entire history - ever had a good, reasonable, justified, or otherwise overt need to initiate these changes. There is no legal explanation for it (IE court order, lawsuit ruling, privacy concern, etc) no OS explanation for it, and therefore no reason for it. In short, leave us alone. This ongoing harassment is everything I don't like about Wikipedia, and its why I've grown distant from the project: I don't like being told by the WMF that the site is operated on the tyranny of the minority who can code. Eyes on, hands off. That should be the relevant policy for the WMF as it relates to the projects. TomStar81 (Talk) 15:27, 20 February 2024 (UTC)[reply]
There is nothing anywhere that I can see that consensus requires a large sample size, and statistics has demonstrated that increasing sample size past a certain threshold has diminishing returns in confidence. 328 samples out of 46,976,866 registered accounts is already past that threshold with a margin of error of 0.56% according some online calculator.
V10 is inconsistent and slightly dated, and limited width was said to increase reading speed in studies. That seems like a good reason to me.
To go along with the data provided by Aaron, the only issue with the sampling distribution is that it isn't random—editors in general were more likely to participate in the initial surveys and the RfCs. That's the issue with voluntary sampling, and something that is near impossible to fix. Cessaune[talk]00:37, 21 February 2024 (UTC)[reply]
+1 I agree that they should have at least notified as many users as possible about the change, inviting them to take part in the first RfC either via email or through banners, or even both. Æo (talk) 04:19, 21 February 2024 (UTC)[reply]
I think watchlist notices only reach a small fraction of the active users. Regarding banners, I don't remember seeing any. Æo (talk) 01:14, 22 February 2024 (UTC)[reply]
...And now the next problem with this roll out: there was no explanation for why it was needed. Not wanted, but NEEDED. This is something the WMF does at a constant pace, it forces these things out with no explanation for why they are needed. Essentially, this violates WP:OWN but ensure that their prefered version gets shown and the rest of us get inconvenienced. To break this down: needed would be for mandatory issues. If vector 2022 was needed because the WMF legal department had reviewed a disability warning and determined that the 2010 version was not in complaince with US laws then I would get. If the team determined that hackers could exploit a vulnerability in the interface and the only way to protect the site was to deploy this newer version, I would get it. If there had been some sort of religious reason such as there is for the Ise Grand Shrine then I'd get it. In every case though - every case - there is never a good explanation, if there was even an explanation to begin with. Frankly, from where I sit, what this demonstrates is that the WMF is guilty of disrupting Wikipedia to make a point: they own the site and they can change it with or without community input, and it appears to be done exclusively without. And in every case - EVERY case - there is considerable blow-back, most tellingly when the foundation had to deeply super protect to forcibly deploy its unwanted media viewer. That should tell you everything you need to know about these so called "updates": WE DON"T WANT THEM. Why the foundation can't seem to get that through its head is one of life's greatest mysteries, and here again all its done is piss people off. Immensely. Which is the simple definition of disrupting Wikipedia to make a point. Which in turn is a blockable offense. Do you see a pattern? I do. And sadly, there isn;t anything I can do about it because the WMF refuses to participate in consensus building processes. — Preceding unsigned comment added by TomStar81 (talk • contribs) 17:11, 28 February 2024 (UTC)[reply]
What is the point of the last question? What else would prospective answerers mention that isn't already covered by discussion or any other question? I propose replacing it with the "What features are you looking for in skins" question. Aaron Liu (talk) 18:24, 8 January 2024 (UTC)[reply]
What is the point of the last question? What else would prospective answerers mention that isn't already covered by discussion or any other question? I don't know. Rollback, maybe.
Think of this as a survey/strawpoll as opposed to a typical RfC. The +1 -1 thing isn't meant to generate consensus, merely to gage opinion, so I think it's fine. Cessaune[talk]04:18, 10 January 2024 (UTC)[reply]
Thank you for starting this RfC. Join Talking 2024[edit]
Hey everyone, this is Szymon and Olga, the community relations specialist and product manager for the Vector 2022 skin and the Web team overall.
Firstly, we wanted to say thank you for taking the initiative to start this conversation. We would like to specifically thank the RfC writers and collaborators (@Aaron Liu, @Æo, @Awesome Aasim, and @Cessaune) for the structure of this discussion. The way the questions are formulated makes it easy for participants to write their opinions and experiences, and also for us to turn these into actionable reports and requests. It's such a great idea and sets an example to follow. We hope to structure conversations like this in the future as well. Thank you!
Discussions like this help us prepare for the process through which the Foundation determines what to do each year – annual planning. We would like to invite you to the next consultations. There, thanks to this RfC, you may see some of the topics you're discussing now. That will begin in a few months, though, after the annual plan draft has been published. Currently, you may meet with our leaders as part of the Talking 2024 initiative. By contacting them directly, you may make sure they understand why working on your most/least favorite features is important. We really want this RfC and annual planning pieces to click :)
We're reviewing your comments and requests so far, similar to our tabulated lists from the previous RfC. We will post a simple analysis and continue discussions on what steps we would like to take.
Yep, we modeled this a little off WP:TPC19. I saw this would be most helpful in collecting feedback for improvement rather than proposing outright. Proposals might come later if there are ideas that people largely agree with. AwesomeAasim15:56, 17 January 2024 (UTC)[reply]
Development on the skin in 2023 and 2024 from the Web team[edit]
Hey again, like we said above, we are catching up on the conversation here and will be giving you feedback over the next few weeks. As part of this, we wanted to do our own evaluation of the skin and put together a little summary of what we've been working on for Vector 2022 over the course of the year:
Completed:
Persistence and availability of the full width toggle (March 2023). The full width toggle (available at the bottom of the page) was made persistent for both logged-out and logged-in users. This means that they see the width of their choice in spite of refreshing the page or opening a new one. The toggle was also made available at narrower screen widths.
Content separation (Zebra) development, A/B test, and next steps (May – Dec 2023). The team built a prototype to test the hypothesis that making the visual separation between content and navigation more clear will improve the overall readability of the page. We tested this hypothesis and were unable to prove readability improvements. However, we used some of the ideas from the prototype to improve the visual styling of the overall page. We deployed these improvements in early December.
Logo creation and scaling the skin to all wikis (ongoing). In order to bring the Vector 2022 skin to all sister projects, we had to design new logos for the majority of projects. Once these logos were completed, we continued rolling out to the majority of sister projects. We also released a short video about the skin. We currently plan to complete the rollout and continue with Vector 2022 as the default skin to all wikis.
Current and next-up:
We are committed to the further development of Vector 2022, with the old skin frozen in its pre-2022 state. Currently, our main focus is on improving the accessibility for reading the site. We're working on typography and font size, and building out a dark/night mode for both the Vector 2022 and Minerva skins. As we start this work, we welcome you to check out our project page and give us your thoughts.
The accessibility for reading beta feature (December 2023). We have built out a beta feature that will let logged-in users test these features as soon as they are released. To try it out, go to the “beta” option in the user menu and select “Accessibility for Reading (Vector 2022)”. The feature is available as a beta feature across all wikis, so you may also turn it on all wikis using the global preferences. This will enable a menu that allows you to set (currently) text and width preferences and (coming soon!) day or night colors. The menu is pin-able in a similar way to the tools and main menus, both placed in the side columns of the interface. When it's not pinned, it's displayed next to the user name.
Typography and text (available now) There are three available settings – small (the current default), standard, and large (for users who need additional increase in size). The standard setting may later become the new default, as recommended by both the literature research and prototype testing.
Night (dark) colors (coming soon). The menu will allow users to select a color scheme: day (light) or night (dark). If you have set these preferences on your device, we will follow your device preferences where we can.
Prior to releasing any of these features outside of beta and officially adding them to the Vector 2022 skin, we need your comments! Please, try out the new menu and the text feature, tell us where it breaks, what issues it has, and what you would like to see it become in the future. <emphasize>Getting your opinions now, while we are still in the earlier stages of development, is crucial.</emphasize>
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.
A fix to the general waste of space waste of space, particularly on the sides. This was the main theme through most of question 1, so should be high priority.
Make the user talk link not hidden by default.
Add responsive mode on mobile, as a toggle.
Provide a way to hide a username, possibly through a check box in the Appearance menu.
A thinner right-side toolbar.
Fix the poor autocomplete feature of V22's search bar, which doesn't link redirects and often gives nonsensical suggestions.
@Æo:Awesome Aasim wanted 'to see if there are recurring themes in the Phase I part that can be the basis for Phase II.' So it isn't a formal closure, more a stimulus for further discussion to hone in on specific changes. I tried to go about the themes, however almost all of the answers revolved around fixing the wasted space on the page, with only a few other miscellaneous changes getting consensus. JML1148(talk | contribs)10:14, 11 April 2024 (UTC)[reply]
Was this procedure abandoned? Has the Wikimedia Foundation considered the proposals that were made in the RfC?--Æo (talk) 17:20, 13 June 2024 (UTC)[reply]
After the implementation of the new big "standard" text size, wouldn't it be better to restore the classic ToC under the article's introduction in order to free up the left side band of the page, which would therefore provide additional space for the article's text? The Main Page gives an idea of what it would look like.--Æo (talk) 15:15, 22 June 2024 (UTC)[reply]
Why did the Wikimedia Foundation decide to destroy Wikipedia? If devastating the articles' layout was not enough, they have now implemented a ridiculously large "standard" text size that further squashes the articles' text body in the middle of the page. I simply have no words.--Æo (talk) 17:16, 13 June 2024 (UTC)[reply]
What's wrong with that? If they prefer small, they'd click back onto it. The fact that there's >16% more clicks on standard than small proves that people prefer it. Aaron Liu (talk) 20:00, 13 June 2024 (UTC)[reply]
Particularly since small is the current default. one would click small to go back to the smaller font. It is possible that some users may not know that they can click on small to go back to the smaller font, but it is seldom possible to get everyone to understand a new thing first time round. The most annoying thing for me is that so much is not affected by the size change, making many pages full of mixed font sized for the wrong reasons, like this edid box I am using right now. The font is so small I have to zoom the whole page to see what I have written well enough to make corrections, while the preview is legible, but not editable. Some improvement is indicated here. Cheers, · · · Peter Southwood(talk): 07:59, 14 June 2024 (UTC)[reply]
Sorry, but what are you talking about? The default is currently set to "standard", which is not small at all. On the contrary, it is ridiculously large, much bigger than the previous standard which has now become the "small" option. I do not think that Wikipedia's standards should be adapted to people with sight problems. Accessibility options should remain in the user's "preferences". Æo (talk) 14:52, 14 June 2024 (UTC)[reply]
Then they should create a "preferences" page for logged-out users, not impose standards for people with sight problems onto the whole Wikipedia community and all readers. Æo (talk) 14:58, 14 June 2024 (UTC)[reply]
The appearance portlet is the logged-out preferences. It's not just for "people with sight problems", most people agree that the previous text size is a bit small. Before the portlet I'd zoom into the page on my browser. It only seems ridiculously large on small screens, which can also just straight-up select the "small" option which will be remembered. I don't see what your problem with this is. Anyone can just change it. MOS:ACCESS is a guideline anyways. Aaron Liu (talk) 16:31, 14 June 2024 (UTC)[reply]
At first glance, we have a clear numerical advantage for those supporting the rollback to the old skin, but many of these !votes were based exclusively on specific issues with Vector 2022, such as fixed text width, the large amount of whitespace, and the overuse of icons, as well as some accessibility issues. Others commented on bugs they encountered while using the skin. The WMF has fixed several of these issues–for example, the fixed width toggle not persisting–and more changes are likely to come.
Similar issues weren't brought up for the font size. In fact, when I asked a bunch of random people I know in real life, they didn't care at all for the skin change (one somehow didn't even notice it) and most felt that the font was too small before. 2. Whether the WMF are hands-off dictators (they are) has no bearing on the fact that I do not understand why you consider it that big of a deal when you can always just change the setting if you don't like it. Aaron Liu (talk) 15:45, 15 June 2024 (UTC)[reply]
... you can always just change the setting if you don't like it — As I already wrote in the past, my opinion is not driven by selfish personal preference, but by considerations on the overall appearance of information as conveyed by Wikipedia. And I think that with the new interface the typical Wikipedia article structure has been destroyed in the name of an abstract and inconsistent idea of universal accessibility. Æo (talk) 23:52, 15 June 2024 (UTC)[reply]
Cf. my very first message: ... they have now implemented a ridiculously large 'standard' text size that further squashes the articles' text body in the middle of the page. Æo (talk) 15:02, 22 June 2024 (UTC)[reply]
How would that destroy the structure of the article? Furthermore, again, anyone who doesn't like it can always simply change the setting, which takes up the right sidebar by default, back. There is research that suggests that a majority of users like a bigger font, while there's no research to suggest that part of the majority had issues with the small font that have now been solved, if you're going to link this back to the RBV22 RfC again. Aaron Liu (talk) 17:02, 22 June 2024 (UTC)[reply]
I started to revert back (my login only) to the Vector legacy skin because I felt like the Vector 2022 look, in particular the infobox and hatnotes, looks like the mobile skin. ScarletViolet (talk • contribs) 13:35, 15 June 2024 (UTC)[reply]
As many indicated during the "rollback" RfC, our biggest gripe with V22 was the excessively cramped layout produced by the fixed-width default and the missing table-of-contents. Many editors agreed that this was counterproductive, takes "accessibility" to extremes, and does not make articles more readable — in fact, to many, it does the opposite. Remember, there was a whole sub-survey regarding this issue, and the closers determined there was consensus to revert this part of V22, only for the WMF to refuse to uphold this consensus. I'm astonished that the WMF has now decided to exacerbate the issue even further by making the default font size comically large. InfiniteNexus (talk) 13:43, 26 June 2024 (UTC)[reply]
00:07, 11 January 2024 (UTC)
Moved from #Proposed changes
