Jump to content

Wikipedia:Requests for comment/Evaluation of Vector 2022

From Wikipedia, the free encyclopedia

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

[edit]

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

[edit]

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.

Questions

[edit]

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.


What do you like about Vector 2022?

[edit]

What do you dislike about Vector 2022?

[edit]

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 Levivich (talk) 01:21, 10 January 2024 (UTC)[reply]
    −1 I don't agree with max width for all. The look and feel should be the same across all Wikipedia language editions 141.138.38.210 (talk) 04:05, 11 January 2024 (UTC)[reply]
    −1 Max width is overrated. CactiStaccingCrane (talk) 13:17, 14 January 2024 (UTC)[reply]
    +1 to all of this. mi1yT·C 08:11, 17 January 2024 (UTC)[reply]
    +1 CosXZ (talk) 23:01, 18 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]
    Well, there's a persistent toggle, so people have a choice already. Cessaune [talk] 17:28, 26 January 2024 (UTC)[reply]
    It's persistent but not default. I support full width as default. Æo (talk) 18:54, 26 January 2024 (UTC)[reply]
    There's barely a distinction. Cessaune [talk] 19:34, 26 January 2024 (UTC)[reply]
  • Restore the inline ToC; restore the old language menu; restore the full page width as default.--Æo (talk) 19:43, 9 January 2024 (UTC)[reply]
    −1 Please don't. The look and feel should be the same across all Wikipedias 141.138.38.210 (talk) 04:05, 11 January 2024 (UTC)[reply]
    −1 It already isn't. And it shouldn't be. Each Wikipedia should come to its own conclusions. Cessaune [talk] 05:02, 11 January 2024 (UTC)[reply]
    +1 Absolutely the inline ToC should be present in addition to the sidebar one. Makes navigation a breeze. Awesome Aasim 15:42, 14 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]
    You don't have to keep repeating your !vote. You've said this like four times. Cessaune [talk] 17:35, 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 real question is, why do you dislike the sticky TOC so much? Cessaune [talk] 17:57, 26 January 2024 (UTC)[reply]
    And customization, for that matter. Aaron Liu (talk) 18:00, 26 January 2024 (UTC)[reply]
    Yes. I don't get 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.
    Toggles everywhere only make it disorganic. What does "disorganic" mean in this context? I don't understand. Cessaune [talk] 18:29, 26 January 2024 (UTC)[reply]
    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 Æo (talk) 16:44, 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]
  • Toggle TOC numbering on/off. Levivich (talk) 01:28, 10 January 2024 (UTC)[reply]
    −1 ToC numbering should always be present. Æo (talk) 16:45, 10 January 2024 (UTC)[reply]
    −1 I disagree. Takes up way too much space, and what’s this antagonism towards configuration? Aaron Liu (talk) 17:10, 10 January 2024 (UTC)[reply]
    −1 Why does it have to be one or the other? What's wrong with a toggle? Cessaune [talk] 17:14, 10 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]
    Have you heard of Special:Preferences? Aaron Liu (talk) 15:28, 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]
    Can't it be both? Shouldn't it be both? Cessaune [talk] 15:47, 23 January 2024 (UTC)[reply]
    It can certainly be both, but the personalisation options should be kept in Special:Preferences, and not made part of the main interface. Æo (talk) 15:52, 23 January 2024 (UTC)[reply]
    It’s just one, well-placed button in the bottom-right corner; I don’t see why it is bad. Aaron Liu (talk) 15:56, 23 January 2024 (UTC)[reply]
    Yet, you are opposed to a toggle, one that would very likely be placed in Special:Preferences. I'm genuinely confused. Cessaune [talk] 15:57, 23 January 2024 (UTC)[reply]
    I had in mind the button to change the width of the page. Æo (talk) 16:22, 23 January 2024 (UTC)[reply]
    Are you saying that encyclopedias don’t have to be user-friendly? I don’t really understand the argument. Aaron Liu (talk) 15:56, 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.
    What does ordered and serious interface mean to you? Cessaune [talk] 19:02, 23 January 2024 (UTC)[reply]
    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]
  • Allow both sticky and inline TOC. Levivich (talk) 01:28, 10 January 2024 (UTC)[reply]
    +1 Æo (talk) 16:45, 10 January 2024 (UTC)[reply]
    −1 Only as a user option, but not for all 141.138.38.210 (talk) 04:05, 11 January 2024 (UTC)[reply]
  • Allow user to drag and drop adjust right/left/top toolbar width. Levivich (talk) 01:28, 10 January 2024 (UTC)[reply]
  • Widen the damn reading area. It turns even ordinary paragraphs into walls of text. The Blade of the Northern Lights (話して下さい) 01:44, 10 January 2024 (UTC)[reply]
    +1 Æo (talk) 16:46, 10 January 2024 (UTC)[reply]
    −1 Please don't. It's damn too good. 141.138.38.210 (talk) 04:05, 11 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. mi1yT·C 08:19, 17 January 2024 (UTC)[reply]
    +1 CosXZ (talk) 23:01, 18 January 2024 (UTC)[reply]
    +1 🌺 Cremastra (talk) 19:23, 25 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. - jc37 05:03, 10 January 2024 (UTC)[reply]
    Every single main menu, page tools, etc link is in the mediawiki namespace. Unless you’re talking about something else? Aaron Liu (talk) 14:24, 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. - jc37 05:03, 10 January 2024 (UTC)[reply]
    So in summary, an option to put the tools on the left when the TOC is hidden? Aaron Liu (talk) 14:24, 10 January 2024 (UTC)[reply]
    @Jc37: Do you mean a reset of all menus and ToC to how they were in V10? Æo (talk) 16:39, 10 January 2024 (UTC)[reply]
    +1 Put the TOC on the right then? That could work, maybe. Needs more research. 141.138.38.210 (talk) 04:05, 11 January 2024 (UTC)[reply]
    No, it sounds like they want the tools on the left. I don’t see why you (IP)’d want everything on the right. Aaron Liu (talk) 12:42, 11 January 2024 (UTC)[reply]
    −1 It would be even worse than having the sticky ToC on the left. Æo (talk) 18:10, 18 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. Awesome Aasim 16:03, 12 January 2024 (UTC)[reply]
    +1 YES! We need more mobile editors. CactiStaccingCrane (talk) 13:18, 14 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.) ⁓ Pelagicmessages ) 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]
  • Provide a quick way to permalink a page or section. If there is such a way, I couldn't find it. Sandstein 12:42, 27 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]
    Or just add "link / permalink" labels to sections. Sandstein 10:35, 29 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]
    Yes, but that doesn't seem to be what Sandstein wants.
    There are a lot of shortcut scripts at WP:US/L#Shortcuts. Aaron Liu (talk) 17:54, 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.js did 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]
    Or if I'm sharing my screen on Zoom or Teams or projecting it in front of a room full of people. —⁠ ⁠BarrelProof (talk) 18:47, 27 January 2024 (UTC)[reply]
    +100,000 🌺 Cremastra (talk) 18:33, 27 January 2024 (UTC)[reply]
    How exactly would this work? Cessaune [talk] 18:48, 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. But I know even less about JavaScript than you do, and that's not a solution that would help most Wikipedia users. —⁠ ⁠BarrelProof (talk) 20:55, 27 January 2024 (UTC)[reply]
    As usual subscribers to WP:S++ know, there's a userscript for that. Would be nice to have an official feature though. @Cremastra @BarrelProof Aaron Liu (talk) 23:22, 27 January 2024 (UTC)[reply]
    Tried it but it didn't work. :( Maybe because my default skin is monobook. 🌺 Cremastra (talk) 23:27, 27 January 2024 (UTC)[reply]
    Works in Vector 2010. 🌺 Cremastra (talk) 23:28, 27 January 2024 (UTC)[reply]
    Fair. For some reason mediawiki doesn't provide a function to do stuff with the top bar that works with any skin... Aaron Liu (talk) 23:40, 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. ⁓ Pelagicmessages ) 20:45, 1 February 2024 (UTC)[reply]
    +1 I know what u mean. That's why I prefer to edit anonymously, people knowing my user name could learn a lot about me. 205.220.129.21 (talk) 15:50, 24 February 2024 (UTC)[reply]
  • Justified text in articles; i.e. all lines of the same length.--Æo (talk) 13:16, 5 February 2024 (UTC)[reply]
  • Dropdowns that are viewable by rollover, allowing one click as opposed to two. Cessaune [talk] 16:18, 7 February 2024 (UTC)[reply]
    +1, assuming you mean by hover Aaron Liu (talk) 16:27, 7 February 2024 (UTC)[reply]
    Yes. Cessaune [talk] 16:29, 7 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]
    Most that browse on mobile do not want to do anything other than read and browse, for which there is virtually no learning curve. Aaron Liu (talk) 18:14, 23 February 2024 (UTC)[reply]
    Yes, if we only want people to be able to consume the content as a read-only publication, maybe it's not important. —⁠ ⁠BarrelProof (talk) 18:23, 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.
    Andrew🐉(talk) 23:48, 23 February 2024 (UTC)[reply]
    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'm the one using iOS Safari. Do you mean MacOS Safari or iPadOS Safari? Andrew🐉(talk) 08:14, 24 February 2024 (UTC)[reply]
    On an iPhone 13. Can't grab and slide in iOS Safari either. Cessaune [talk] 10:31, 24 February 2024 (UTC)[reply]
    Works for me. Aaron Liu (talk) 17:26, 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]
    It's pretty easily done for me: you press your entire finger on the side (but not off the edge) of the screen onto the bar. Aaron Liu (talk) 01:11, 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]
  • Thinner sticky TOC and toolbars, so as to not waste as much space; borders around the TOC and toolbars. Cessaune [talk] 17:08, 9 January 2024 (UTC)[reply]
    +1 🌺 Cremastra (talk) 19:22, 25 January 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 1134″ 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 658″ 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]
    Ah, thanks. It's there. That's helpful. That's my new preferred choice – both side panels hidden and full screen width. —⁠ ⁠BarrelProof (talk) 17:26, 1 February 2024 (UTC)[reply]
    Do you prefer that overall? Like, if there was a thinner sticky TOC option or an inline TOC toggle, which of the three would you pick? Cessaune [talk] 17:28, 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]
    Why not? Cessaune [talk] 18:56, 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 (1134″ wide), if the full width option is disabled and the side menus are hidden, the white areas on the sides are about 214″ each, so about 19% each or 38% total. They get a little wider, 212″ 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]
    This applies to you too, BarrelProof. Cessaune [talk] 02:55, 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]
    Well, all of these terminologies are confusing indeed. So you mean that you’ve unlimited the width, correct? Aaron Liu (talk) 19:24, 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 38″ 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]
    Isn't there a gadget to add numbers to the TOC? Under Special:Preferences → Gadgets → Testing and development → Auto-number headings. I've never tried it. Folly Mox (talk) 01:22, 10 January 2024 (UTC)[reply]
    That adds numbers to the headings but not the TOC. Levivich (talk) 01:26, 10 January 2024 (UTC)[reply]
    There's a userscript that does that (insert shameless plug for WP:Scripts++). That said, scripts probably shouldn't be factored into this discussion unless V22 somehow massively impedes making scripts. Aaron Liu (talk) 00:00, 11 January 2024 (UTC)[reply]
  • To fix most of the things I say in "what do you dislike". Aaron Liu (talk) 21:00, 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]
  • See answers to the "added" question above, and the Phabricator task list. – Jonesey95 (talk) 01:23, 10 January 2024 (UTC)[reply]
  • Thinner right-side toolbar. Levivich (talk) 01:29, 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]
  1. Make it show up on every page, not just in reading mode. I especially sometimes find myself wanting to use it while editing.
  2. 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)
Aaron Liu (talk) 02:41, 15 January 2024 (UTC)[reply]
  • 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]
    −1 Tables are usually full-width. I don’t think having additional blank space for every place without images is a good idea. Aaron Liu (talk) 15:24, 17 January 2024 (UTC)[reply]
    Do you mean tables are full-width and no more or full width and no less? Wizmut (talk) 01:20, 19 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]
    −1 Æo (talk) 15:31, 17 January 2024 (UTC)[reply]
    +1 For the pictures idea. 205.220.129.21 (talk) 15:51, 24 February 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]
  • With the upcoming changes to m:IP Editing: Privacy Enhancement and Abuse Mitigation, it should be possible to allow logged-out users to choose a default skin and have the page width toggle stick. This could be done either through the user_properties table for the temporary account, or through the temporary account's cookie. The WordsmithTalk to me 17:53, 23 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]
    You're correct, though I don't think either of these behaviors are better. Seeing the name of a redirect seems to have marginal use. Aaron Liu (talk) 15:02, 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]
    Since this page has lost traction and we don't have any other proposals, I'd suggest mw:Phabricator/Help#Creating a task on Phabricator. Aaron Liu (talk) 16:14, 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]
    @BarrelProof: I think that this section is for a list of the proposed changes that will be compiled when this RfC will be closed (if this is the function Cessaune intended for this section). You should put your suggestion under #What features, if any, would you like to be modified in Vector 2022?. Æo (talk) 01:29, 22 February 2024 (UTC)[reply]
    checkY Cessaune [talk] 01:30, 22 February 2024 (UTC)[reply]

What features, if any, would you like to be removed from Vector 2022?

[edit]

Generally, what features are you looking for when it comes to a Wikipedia skin?

[edit]
+1 🌺 Cremastra (talk) 21:27, 28 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.
--Sunrise (talk) 08:20, 18 January 2024 (UTC)[reply]
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]
I'd imagine they've all been patched, but I seem to recall a number of scripts breaking when V22 first rolled out. Compassionate727 (T·C) 16:32, 30 January 2024 (UTC)[reply]
+1 For all the points raised by Sunrise. Æo (talk) 18:28, 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]
    Responsive UI is sort of implemented. What modern features are you thinking of specifically? Aaron Liu (talk) 01:38, 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]
    I think that many anonymous editors are not aware of this RfC. Æo (talk) 20:54, 17 January 2024 (UTC)[reply]
    I agree, but I think what the IP meant is complaints anywhere about V22 in the past six months, which I can't find either. Aaron Liu (talk) 20:58, 17 January 2024 (UTC)[reply]
    Does this affect enwiki? — Qwerfjkltalk 21:54, 14 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 It is definitely a different interface. Æo (talk) 18:04, 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]
  • External feedback: I tried to write something here, but it grew until it was pretty clearly out of scope for this fora. I have published it at https://opensourceexile.blogspot.com/2024/01/the-introduction-of-vector-2022-skin.html Stuartyeates (talk) 07:26, 20 January 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]
    Could you elaborate on the negative feedback that got dismissed? Aaron Liu (talk) 12:07, 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. ⁓ Pelagicmessages ) 21:34, 1 February 2024 (UTC)[reply]
    +1 Æo (talk) 15:55, 4 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]
    Where do I go to look it up? Cessaune [talk] 16:01, 7 February 2024 (UTC)[reply]
    #c-WikiOriginal-9-20240207143400-What_do_you_like_about_Vector_2022? Aaron Liu (talk) 16:18, 7 February 2024 (UTC)[reply]

Hello, desist from continuing to make changes to Wikipedia's typography, in the mobile version you are experimenting with new unnecessary forces https://en.m.wikipedia.org/wiki/Wikipedia:Vector_2022 190.219.223.169 (talk) 05:10, 20 February 2024 (UTC)[reply]

These changes are unrelated. If you have concerns about the new mobile line spacing changes, make an account and join us at T357770. Aaron Liu (talk) 15:03, 20 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]
  1. 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.
  2. 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.
Aaron Liu (talk) 22:09, 20 February 2024 (UTC)[reply]
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]
There was a watchlist notice, and I'm pretty sure there was a banner for all logged-in users somewhere... Aaron Liu (talk) 16:11, 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 (talkcontribs) 17:11, 28 February 2024 (UTC)[reply]

General discussion

[edit]

Format of the discussion

[edit]

Note that this was copy-and-paste moved from User:Cessaune/V22RFC3 Draft which had a format from User:Awesome Aasim/Vector 2022 Feedback Survey.

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.
"What features are you looking for in skins" will be covered by the other questions. Cessaune [talk] 18:49, 8 January 2024 (UTC)[reply]
I agree with Cessaune on this. Æo (talk) 18:59, 8 January 2024 (UTC)[reply]
We should either just not think of rollback for reasons you've mentioned, or include it as its own question here. Leaving it grey like that is not very good.
As for the question I proposed, I'd like to link back to my response from November. Aaron Liu (talk) 19:08, 8 January 2024 (UTC)[reply]
Hmm. It would be a little interesting, but I think we'll be able to find that info from the discussion and survey. Cessaune [talk] 16:31, 9 January 2024 (UTC)[reply]

I think +1 -1 goes against the spirit of WP:NOTVOTE in that it makes it seem like it is a tally instead of consensus. RudolfRed (talk) 20:58, 9 January 2024 (UTC)[reply]

I mean, this already doesn't seem like a consensus-thing either. Aaron Liu (talk) 21:02, 9 January 2024 (UTC)[reply]
Definitely agree. — Frostly (talk) 01:09, 10 January 2024 (UTC)[reply]
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]
+1 (sorry) Remsense 03:04, 11 January 2024 (UTC)[reply]

Announcements from the Wikimedia Foundation

[edit]

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.  

Thank you! Check out our post below for some updates on what's happened with the skin over the past few months. OVasileva (WMF) and SGrabarczuk (WMF) (talk) 15:11, 17 January 2024 (UTC)[reply]

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. Awesome Aasim 15: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>

Thank you again! As mentioned above, expect a data and next steps update from us over the course of the next week or so. OVasileva (WMF) and SGrabarczuk (WMF) (talk) 15:11, 17 January 2024 (UTC)[reply]

I’ve left my comments on the beta on the beta’s discussion page. Aaron Liu (talk) 15:19, 17 January 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposed changes

[edit]

List

[edit]
  • 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.

Sorry this took so long to post. To be honest, I completely forgot about this. JML1148 (talk | contribs) 11:18, 5 April 2024 (UTC)[reply]

Would the changes in m:User:Aaron Liu/v22.css satisfy points 1 and 5? Also, I don't think responsive mode should use a toggle. It should just adopt to screen size like it currently tries to. Aaron Liu (talk) 11:29, 5 April 2024 (UTC)[reply]
@JML1148: Is yours a formal closure or just a list of your answers to each of the questions? Æo (talk) 12:31, 8 April 2024 (UTC)[reply]
@Æ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]

@InfiniteNexus, @Cessaune: 🡹? Æo (talk) 15:11, 22 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]
    No. The "Wide" button is for the bigger space if anyone wants it. Aaron Liu (talk) 17:04, 22 June 2024 (UTC)[reply]

Discussion

[edit]

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]

Actual research has been done to show that the plurality (only 5% short of the majority) prefer the "standard" size. Indeed, especially on desktop, the former text size is a bit too small. Changing is available through a menu that even logged-out users can change and save anyway. Aaron Liu (talk) 18:00, 13 June 2024 (UTC)[reply]
So it was decided based on the number of clicks? Again, no words! Æo (talk) 18:15, 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]
Logged-out people can't go to preferences. Aaron Liu (talk) 14:54, 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]
It only seems ridiculously large on small screens — I disagree; I am using a 17" screen. Æo (talk) 18:58, 14 June 2024 (UTC)[reply]
I also have a 17" and I disagree with you; and so do 55%. Aaron Liu (talk) 19:49, 14 June 2024 (UTC)[reply]
Notice that a bigger percentage of the Wikipedia community asked for a rollback of V22, and yet their will was not respected. So are double standards being used? Æo (talk) 20:30, 14 June 2024 (UTC)[reply]
1.

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]
How does a bigger font size destroy the structure in any way? Aaron Liu (talk) 00:31, 16 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]
Are you familiar with the word "hyperbole"? Cheers, · · · Peter Southwood (talk): 07:48, 14 June 2024 (UTC)[reply]

I've noticed that the format of infoboxes and some templates have been changed on Vector 2022 in the past day or so. I'm not too clued in on all this website layout stuff and I'm not sure if this is the right place, but just as a heads up this has messed with the images in several sidebar templates and in some infoboxes too. The images seem to have either shrunk considerably at their default size, stopped loading or completely disappeared. Examples include: Next Senedd election, 2024 United States presidential election, Template:Donald Trump series, Template:Joe Biden series, Template:Keir Starmer sidebar, Template: Rishi Sunak sidebar, Template:Elon Musk series, etc. I remember a similar change to infoboxes was made a few months ago but dropped within a day or two. Is this one permanent and what measures will be made to fix the formatting issues that have come as a result of the change? ThatRandomGuy1 (talk) 19:10, 13 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]

The only hope at this point is represented by those Wikipedias that have not adopted V22 and/or have reverted to V10 (German, Russian, Ukrainian, Italian, etc.). I hope that from them will come a wave to change the situation also in the English Wikipedia and in all Wikimedia projects. Æo (talk) 13:52, 10 July 2024 (UTC)[reply]
I really, really hope that wave of change comes too. If people want comically large text, they can change the text size in their browsers. It makes zero sense to force a non-standard text size onto everyone(for the normal article text). If people want a very limited line width, they can adjust the size of their browser windows. I also strongly oppose the huge "Appearance" side bar, that asks users to customize the site. Now don't get me wrong, it's a really good thing if users are able to customize things, especially if they are logged in. But perhaps that can be an option, like a button to press for those who wishes(a button that doesn't change the overall layout of the page), rather than an assault on everyone that enters the website. Sorry to all who helped make Vector 2022. I realize you put a lot of effort into this, and that you had the best intentions. And I read through some explanations of Vector 2022 to help me understand your perspective on it, but frankly I felt they were very biased in favor of the changes, and they really didn't alleviate my worries. Please don't let this be what Wikipedia is going to be like from now on. FreeToDisagree (talk) 13:42, 25 August 2024 (UTC)[reply]
Changing the text size through the browser is a lot more complicated than facilitating it through the interface. Not everyone is a hacker. Making most people have the least hassle seems good to me.
You can hide the appearance sidebar by clicking “hide”. Aaron Liu (talk) 14:16, 25 August 2024 (UTC)[reply]