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)
Background
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.
Procedure
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.
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]
What do you dislike about Vector 2022?
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]
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]
+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]
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]
What features, if any, would you like to be added to Vector 2022?
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]
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]
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]
−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]
−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 under the comments you agree or disagree with in this RfC. Æo (talk) 15:52, 4 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?
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?
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]
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
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
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>
00:07, 11 January 2024 (UTC)
