Talk:Reading/Web/Desktop Improvements

Vector 2022 is just awesome, but I have some recommendations

 * Thank you very much for this new design!
 * It is clearly arranged and flexible, I really love it!
 * Here are my recommendations:
 * The buttons for "Your alerts" and "Your notices" should be in that bar too, that pops up, when you scroll down. At least in that user menu.
 * There should be an opt-in for having all the subentries in the table of content (toc) fold out by default.
 * Also I noticed, that when you hover the mouse in the toc and scroll to the top or the bottom of it, it will begin to scroll the text on the right (article for example) and the toc will reset to the position that matches the position in the text. That is really annoying.
 * Best Regards --KleinerKorrektor (talk) 19:21, 18 February 2023 (UTC)
 * Hello @KleinerKorrektor. Thank you for your ideas. I've documented your request to add the icons in the sticky header, as we call it. We're also figuring out how to build this functionality to force all the headings to be shown. Regarding the third issue, are you still experiencing this? I'm not sure what you'd expect instead. Sorry, perhaps I just don't quite understand what you mean. Thanks! SGrabarczuk (WMF) (talk) 17:57, 30 March 2023 (UTC)

Limit the screen width
I think the worst one can do is limit the screen width... I's far less relaxed for reading and a waste of screen space. Switched back to the previous version. 213.219.163.24 23:41, 21 March 2023 (UTC)
 * Hello! I'd like to invite you to read this page: Reading/Web/Desktop Improvements/Features/Limiting content width. There we've documented our arguments for this change. If you prefer the full width, you may use the button in the bottom right corner of the screen, too. I hope this solves the issue! SGrabarczuk (WMF) (talk) 17:57, 30 March 2023 (UTC)

The new layout looks horrible
No offence, but I created an account just because the new format is badly designed.

Hello,

I study education and am in deep shock about the new wikipedia layout. Why the fuck do UI designers think removing borders and cramping everything into togglers actually makes things better? Like who the fuck sparked that trend? Apple?

What used to look like an encyclopaedia now looks like a white wall of simply nothing. There no longer seems to be any visual (like actually visuable) organization of a page beyond the paragraphs.

It isn't just that there aren't any visible borders anymore, there also is no contrast whatsoever and the text flickers while scrolling! It horrid and counterintuitive as fuck, because it makes your eye get lost and is utterly immemorable and thus fails to fulfill the basic criteria of visual educational material.

Get education experts when designing the UI next time. This is shameful.--2A02:908:966:63E0:E94E:DAB1:D3A:483 12:55, 21 January 2023 (UTC)


 * I totally agree with your comment! I have no idea how someone may break so much the user experience as they did. I haven't been logged to wikipedia for more than a decade, but had to, to choose some older variant of visual style, to even usefully read an article. A shame on them, a shame! How come they have not tested it before release. Sslukt (talk) 15:11, 21 January 2023 (UTC)
 * Small correction, they did test it before release (and I hated it then too), but couldn't figure out how to put it into words. The OP states it excellently. Wiki joedirt (talk) 23:16, 30 January 2023 (UTC)
 * Same! I haven't logged in for 7 years, but now had to, just to change the layout.. why do you even need to log in for that? makes no sense. P3rttiz (talk) 14:30, 17 February 2023 (UTC)
 * I agree, but it's not just here. The entire Web seems to be going through a phase of ugly and stark being considered design statements. I do hope it passes quickly. 74.115.78.80 15:28, 21 January 2023 (UTC)
 * Absolutely agree. All the illustrations have been reduced to postage stamps. It looks fine on a phone, but is utterly unusable on a computer screen. The aesthetics have been trashed along with the functionality. The web is a visual experience and Wikipedia has just died... 2001:8003:D40E:7E00:ACDF:D45C:10E0:7BF4 17:06, 21 January 2023 (UTC)
 * Agree. Some websites tend to change themselves radically (e.h. IMDb) when old version is working just fine. Gevorg89 (talk) 17:29, 21 January 2023 (UTC)
 * I agree, the new-look looks extremely unorganized, but at least you can switch back to the old one... Telltemmne (talk) 18:54, 21 January 2023 (UTC)
 * Certainly, the new layout looks utterly dreadful, good thing we can change back to either vector legacy or monobook. Interlacing (talk) 20:02, 21 January 2023 (UTC)
 * Agree. Clear-cut downgrade. Forresthopkinsa (talk) 21:12, 21 January 2023 (UTC)
 * I've been using Wikipedia since day 1 and I had to create my first account today just so I can change the layout to the old format. What a HORRIBLE redesign.  It's looks like garbage on a widescreen laptop monitor.  Why is there so much white space on the left side?  Is wikipedia for Zoomers on iPhones now, like TikTok or some other garbage?  This is the worst website redesign I've ever seen, including that one that Digg did like 12 years ago that made literally everyone leave the site for Reddit.  Just BAD BAD BAD. 76.104.139.237 21:31, 21 January 2023 (UTC)
 * so fucking true man 71.226.203.33 23:41, 30 January 2023 (UTC)
 * It is nothing but worse. Jacob Agar (talk) 21:33, 21 January 2023 (UTC)
 * I actually came here to say the same thing; the new UI isn't just ugly, but it's genuinely painful to use on desktop, to the point of being borderline-unusable. It was clearly designed with mobile users in mind, despite the fact that, afaik, the overwhelming majority of editors prefer desktop; I say this as someone who does mobile edits from time to time. I don't want to have to log in every time I use Wikipedia just so I can even navigate a page! Change it back! Birdn4t0r (talk) 22:02, 21 January 2023 (UTC)
 * You can get the mobile UI on desktop already with .m in the url. I just switched from the mobile view that had opened up by accident to desktop view and I think the layout is even worse on desktop than the actual Mobile UI. This style is not ready for prime time and should in no way have become the default.
 * The UI getting old and stale is worse than being actively bad.
 * Shadowmaster13 (talk) 08:26, 25 January 2023 (UTC)
 * Count me in on that one: Huge waste of screen real estate, on my 1920 pixel width screen only half is used by content and it would not be more if resize the browser window to full screen. The article-outline was separated from the article, no visible connection between article and pictures/graphics, way too light UI overall, languag switcher anywhere and search-field moved anywhere else.
 * Seems like it was designed to fuck up and bug out the user. No real user experience while designing this was in mind i think. 2A02:8109:9D40:1F1C:E475:3EC8:7B5E:28CE 23:34, 21 January 2023 (UTC)
 * I made an account with wikipedia just to switch it back. It's not so much the design is horrible, but it looks exactly like the mobile layout and I don't use the mobile layout for a reason. I don't entirely unsupport the idea of re-optimizing Wikipedia for modern UI (not that I wouldn't switch it back anyways lol) but doing it in a way that just feels like copying the mobile format is so weird. 47.146.190.208 02:16, 22 January 2023 (UTC)
 * While I disapprove of the profane language used in this comment, I have to echo the sentiment. The amount of white space in the new layout is so jarring it makes articles absolutely dreadful to read on a desktop display. Does Wikipedia even care about how resoundingly negative the feedback to this new design has been? 2600:6C44:747F:98D5:E9C9:BDC3:1868:6F99 03:30, 22 January 2023 (UTC)
 * Uninspired redesign, neither better looking or more functional, so I have no idea what was the intention of whoever came up with this. There is no way someone beta tested this because it would not have gone live.
 * I have no idea why someone thought the interface needs a change in the first place since it was optimized for a dictionary, but on top of that, it made no sense to take away the access to international versions and Wikimedia on the side which represent additional references. It would make more sense to make the old one default and offer the new one as option. 2600:1700:20C1:4920:B8D9:705C:D86C:BF8F 04:31, 22 January 2023 (UTC)
 * I'm mostly reply just to increase the number of replies so they see we don't like this; while the profanity is unnecessary I wholeheartedly agree that desktop websites should have desktop layouts and mobile layouts should stay on mobile. The same complaints were made when Windows 8 came out and when Facebook did it I stopped browsing their website on desktop entirely.  At the very least you can change it back in the preferences menu (although that's only available to those of us who've made accounts), unlike Facebook and the new Steam Library (which is not that new anymore). Jacob p12 (talk) 05:49, 22 January 2023 (UTC)
 * Completely agree. Vector 2022 sucks due to clearly very little thought being put into it. Excelsiorsbanjo (talk) 05:51, 22 January 2023 (UTC)
 * I literally went to the step of creating an account just so I could complain about (and hopefully get rid of) the horrific new UI. I've seen better web design in simple html pages from the 90s. --118.149.76.228 10:27, 22 January 2023 (UTC)
 * My main issue with it was that the text was not wide enough and it was harder to read. Glad there's a button at the bottom to make the width fluid. 5.15.71.147 12:06, 22 January 2023 (UTC)
 * This mostly fixed it for me, thanks for that!
 * While I'm here, my suggestion is for a border to be added to the edges of the container. The white blends into the grey too easily and it is a bit disorientating. The border helps the user find the edge of the page/container, and it also has the benefit of looking more authoritative. Moissanite (talk) 19:59, 8 February 2023 (UTC)
 * You're totally right. I also had to make an account to select the proper UI. This is clearly some change pushed by some kid who thinks JavaScript frameworks are the best just because some marketing move told him so. Maybe some company author of the framework donated money to Wikipedia to make this change. Otherwise it makes no sense and it just makes Wikipedia worse. Microph123 (talk) 12:45, 22 January 2023 (UTC)
 * Maybe the real purpose of the change was to get us all to make accounts.... 66.214.69.101 01:46, 26 January 2023 (UTC)
 * Thıs is absolutely true, there was no need for a resign as the older one was perfectly fine and the blank white space in the sides is horrid and a waste of space. Klad 2 (talk) 13:28, 22 January 2023 (UTC)
 * The new layout sucks so bad. While I think that the old layout looked kinda ugly, I definitely prefer the old one, because it's much easier to read with the old layout. Old is gold, especially on Wikipedia 109.247.106.208 13:45, 22 January 2023 (UTC)
 * I think maybe if they added a dark mode it wouldn't suck as much though. 109.247.106.208 13:47, 22 January 2023 (UTC)
 * At least it helped for user count, I had to create an account to revert to the old appearance. 2A02:AA13:7200:8A80:B8E5:F3A9:623C:352D 17:54, 22 January 2023 (UTC)
 * Can't agree more. I don't know if it was their intention to confuse people at first, and then force them to make an account to switch back from the horrible redesign, a la Reddit style. Terrible decision. 62.167.140.205 18:40, 22 January 2023 (UTC)
 * this is what i came here to say! the only reason i created my user account is so i could revert to the old design! the new one makes me want to vomit. Jakeyounglol (talk) 23:31, 22 January 2023 (UTC)
 * I can only agree. The new design is pretty much a compilation of every awful UI design from the past decade.  It's genuinely awful and makes the experience actively worse.  It really, really, really needs to be rolled back.  And I'm hoping WMF isn't going to dig in their heels about this.  Because the old design is flat out superior. 2600:1700:1471:2550:2195:BD59:6E8E:AB0C 01:29, 23 January 2023 (UTC)
 * Couldn't agree more, the new look is atrocious and an unbelievable waste of space. This is a perfect example of attempting to fix something that isn't broken. ElaenaS (talk) 01:47, 23 January 2023 (UTC)
 * I've been trying to give Vector 2022 a chance over the last few days, and what I really don't like so far is how dead it feels. Like, this lack of visible page organization, as you pointed out, makes it very dull. All this white without much contrast actually makes my eyes uneasy. That is my experience so far. RoadTrain (talk) 02:37, 23 January 2023 (UTC)
 * I too am chiming in to say I made an account for the first time in 30 years of using wikipedia to revert to the old format. The new vector is atrocious to look at and makes reading a chore. The old layout was engaging and helped you intake information. Thats part of the reason people could get lost in wikipedia it was so easy to read. 2603:8080:A704:5A81:A800:FCEE:7F61:1D8F 10:19, 23 January 2023 (UTC)
 * I created an account just to voice my distaste for the new layout. WHY is the width limited??? I get that to some it may be easier to read, but for me, with a 27" screen, I now have to scroll quite bit to read the same content. I MUCH rather read longer lines than be forced to scroll every couple seconds.
 * The previous design was clean and compact. Some may say cluttered, but really everything was at your fingertips and super convenient.. Like an airplane. The new design hides things behind annoying menus, and the TOC being hid behind toggles is REALLY DUMB. Now I can't see the outline of a page without guessing and randomly clicking on toggles?? WTF?! The new design also wastes ~2/3rds of horizontal space on a 27" monitor which looks really goofy. It feels so sterile, and like a clone of other wastelands of the modern web. Ugh. Frustrating. At least with an account, now I can revert the look. Jammnrose (talk) 17:56, 23 January 2023 (UTC)
 * Adding my voice to those who had to create an account just to go back to the old layout. The new one is just awful. Hargan2 (talk) 22:48, 23 January 2023 (UTC)
 * Ive always donated to wiki since i graduated college. I will never give them a cent ever again. Same thing with mozilla and mdn. Its like they used the same brain dead designer Randt1234 (talk) 23:39, 23 January 2023 (UTC)
 * I don't normally comment on talk pages, but good god is this new UI design the most useless one I've ever seen. Nobody asked you to hide everything behind unintuitive buttons, it was working just fine before you fiddled with it. Hobtan (talk) 23:49, 23 January 2023 (UTC)
 * Have to agree that this new redesign looks very bad. Please revert it!! 83.254.212.105 23:53, 23 January 2023 (UTC)
 * This is garbage.. I can't resize the content in a widescreen monitor to get full viewing width. Who thinks this is actually more usable ? Psiberfunk (talk) 03:21, 24 January 2023 (UTC)
 * I'm chiming in as a UX designer–this is shameful and I'm so very tired of "new" UI improvements just turning out to be hiding functionality behind toggle screens. Enuui (talk) 06:11, 24 January 2023 (UTC)
 * I've used the new layout for two weeks. I'm switching back to the old look because it displays the article in a wider column for reading and editing, because it doesn't have a right-nav bar for Tools that I have to hide, and because it uses gray backgrounds to guide my eyes. PRRfan (talk) 16:52, 24 January 2023 (UTC)
 * Couldn't agree more. HATE the new layout. There is so much white space it almost makes me sick. I don't know how web developers get the idea that they know better than I do about what size I want my window to be. I set it to a given size, some smart a**e developer sets 5" borders other content! How arrogant is that. If I wanted it that size I could easily do so. Guess what, I didn't. IanKennedy1965 (talk) 17:08, 24 January 2023 (UTC)
 * Agreed. New format is harder to navigate, particularly on the desktop. Many articles are actively more difficult to read, between the increased white space on the page and the way the text boxes have been 'streamlined'. Not sure if anyone in authority at Wikipedia is reading these comments, but you really dropped the ball on this redesign. 128.164.30.116 19:01, 24 January 2023 (UTC)
 * If I want to read on my phone, I grab my phone. Why do developers everywhere think that a desktop website should look like a phone website. This new appearance may disappear.
 * Why must everything always be hidden for an empty appearance?
 * More search and click work for the same result. Like logging in. To create an account one click. To log in two clicks. Willem ter Haar (talk) 21:12, 24 January 2023 (UTC)
 * The new UI looks awful. It's so bad it made me come here to let my voice be heard. Please change it back to the previous version while you come up with something better ☹ 71.208.54.176 22:56, 24 January 2023 (UTC)
 * Like many, I have created an account to switch back to the old style. Maybe this was the idea? The new design is woeful. What's the point of having a large monitor if you put all the text in a ribbon down the middle, with huge amounts of white space on each side. Horrible. 81.107.32.77 23:16, 24 January 2023 (UTC)
 * I agree. I thought the site was broken at first, then came to find out that this was done on purpose.
 * If nothing else, it pushed me to figure out how discussion pages work. But I'm deeply not in favor.
 * I'm not sure where all of the content on the left side of the page went. Is there a migration tutorial? 2600:1700:EB0:3790:D07F:D785:80DD:AC07 01:28, 25 January 2023 (UTC)
 * I thought i was on the mobile version then found out this was actually a new layout. This is just all around dumb. DarmaniLink (talk) 08:56, 25 January 2023 (UTC)
 * I will stop donations immediately if this is NOT changed back to default. The new "theme" is total shit and I will have NONE of it. This is not the reason I donate money to Wikipedia. Whoever made this decision should have been ousted yesterday. Revert it back to the previous DEFAULT and MAKE people choose the crappy 2022 (genX-edition) if they feel compelled. Newlayoutsucksass (talk) 10:58, 25 January 2023 (UTC)
 * I agree. As one may guess, I made an account just to be able too change the look. Please don't make non registered users suffer, they're people too! WikiP&#39;sNew2023UIisTRASH (talk) 20:20, 25 January 2023 (UTC)
 * While you’re welcome to voice your opinions/feedback about wiki functions, please do not take it into account usernames. Tropicalkitty (talk) 20:33, 25 January 2023 (UTC)
 * Had to make an account just to go back to the old design where the content isn't squished into a tiny section just to make room for whitespace 108.31.241.8 20:26, 25 January 2023 (UTC)
 * I completely agree!! I thought that the CSS template was not loading properly to start with, then that facepalm moment.
 * I am surprised because they think MOBILE MODE is a must, that there wasn't a forced DARK MODE as well.
 * Even the Skin Appearance Preferences does NOT SAVE EITHER, Seriously WTF Shealladh (talk) 10:47, 26 January 2023 (UTC)
 * totally agree, horrible UI, but fortunately you can change it in preferences, what i encourage you to do, then they will know in theirs A/B testing that users actually really prefer old layout. 176.221.123.255 12:10, 26 January 2023 (UTC)
 * I agree that the new design isn't ideal. I am most frustrated by the large borders/sidebars on the sides of desktop monitors. Why squish all content into the middle of the screen and leave these massive blank rectangles on the side? Less information on the screen at a given time = bad, in my opinion. That is my main gripe... I like the idea of a sticky table of contents, but I am too jarred by the sudden change in page size relative to monitor resolution/aspect ratio. Donlad26 (talk) 15:50, 26 January 2023 (UTC)
 * I too can only agree. The MASSIVE amount of whitespace introduced is a complete backwards step that I cannot believe passed to the end. 2A01:4B00:8786:D00:9CCA:920:18FE:893D 19:40, 26 January 2023 (UTC)
 * I was using the "?useskin=vector?useskin=vector" thing to force the old design, but that stopped working it seems. So here I am, a glorious, new registered user.  My username conveys my feelings on the matter. Yournewdesignsuuuucks (talk) 19:41, 26 January 2023 (UTC)
 * 100% agree. At first I thought I'd accidentelly opened the mobile version, but then to my shock realised that someone at Wikipedia apparently thought it was a good idea to make this the design of the main version of Wikipedia. This should be reverted asap and the person who greenlit this should be fired. Luckily there is an option to switch back to the previous design, but the user experience should be good out of the box without having to manually change some settings first. -- Cyberhopser (talk) 18:35, 27 January 2023 (UTC)
 * Oh wow what a worseification.... i hope next time they beg you for donation they receive at most only 1/4 of the usual, clearly they have to much money to waste.
 * - Language selection, much more inefficient
 * - New right side menu distracting from the article
 * - Horrible, completley unusable new TOC
 * - Switching from a design usable at all resolutions (usually i even preferred it on mobile, as i didn't like the castrated mobile version aswell) to a fixed width is a massive step backwards too. (As others noted already: lots of wasted space) BorisSapulu (talk) 18:39, 27 January 2023 (UTC)
 * It is quite awful, and I created an account to revert to the old layout. 198.102.103.103 01:25, 28 January 2023 (UTC)
 * echoing here the new ui is eye bleed inducing i feel as if i will get a headache looking at it for too long. the cramped appearence makes reading anything a chore and makes things ugly with the spacing what is with that planing to add huge banner ads? the only reason i made an account was to revert this change will likely cause some people to leave if its not fixed this should be an optional theme not the defult your going to have infogalactic eatting your lunch. change for the sake of change is never good, if you need your ui design team to earn their keep then have them work on optional skins for the end user to select. the mobilefication of the net needs to stop theres a reason .m exists use it. Bobboter (talk) 05:13, 28 January 2023 (UTC)
 * I made an account specifically to save my preferences regarding the appearance. I'd rather check wikipedia on my phone than go through the 2022 layout. Awful. VangyTuft (talk) 08:24, 28 January 2023 (UTC)
 * I do agree with you - like I agree 100% with everything you said - but you can change back to the original layout, so I'm not too upset. I don't really see them taking away the legacy layout either. 2604:3D09:A977:3600:5DEE:6E28:6C0:7871 11:14, 29 January 2023 (UTC)
 * Yep. I actually registered on Wikipedia just to have the preferences option to switch to the old layout. It's just amazing how bad the new one is. Yegork1978 (talk) 19:29, 29 January 2023 (UTC)
 * About the only 'positive' is a separate TOC, and even that is rather badly implemented. It should be the topmost left table, separated from other menus and options, aligned with the article. Vinner19 (talk) 21:35, 29 January 2023 (UTC)
 * I totally agree!! I can live with if design is not too nice-looking, but I hate when it's unpractical. And this new look is just too horrible to use. I often switch languages, sometime even those I don't talk or read, only now its impossible task to do it quickly with that stupid select box, if there are twenty languages. Moreover, I have to log in in each language to set old layout, that is so very annoying. I could write quite a list what else is useless, but I see others wrote it down already. BeaBeta (talk) 23:38, 29 January 2023 (UTC)
 * Yes. I do not understand the disregard for users screen space. I purchased a large monitor only to find that 'designers' throw away large parts of it's space. An wiki page is not there to look beautiful (not that you could call the new design beautiful! but at the end of the day I suppose that's a matter of taste.) It's form should start with and follow function; it's there first of all to provide information, and options at your fingertips. Both are reduced significantly.
 * I am very glad to be able to switch back! 2A02:A46A:A337:1:14E3:853E:3CB2:6782 09:02, 30 January 2023 (UTC)
 * The new layout is EXTREMELY inaccessible for people with disabilities in my opinion.
 * The text being all smashed together is harder to read, the white space is distracting, and the god awful hamburger menu requires extra movements and clicks to open. Everything is so unintuitive, frustrating, and makes my head hurt. I imagine people who need screen readers are having an even harder time than I am using this site. People shouldn't have to make an entire account just so they can use an educational website without suffering.
 * Wikipedia 1000% did not have people with disabilities in mind when working on this redesign and approving it, as seems the case with most websites who push for the atrocity that is "modern" web design. I wonder if Wikipedia realises they aren't required to follow the the trend of having an ugly website that's terrible to use.  Azethes (talk) 09:11, 30 January 2023 (UTC)
 * I think it depends on the person. I have disabilities and prefer the new layout. The previous desktop version looked to me like an overwhelming wall of text. Each line was so long that I couldn't keep track of what I was reading, and constantly moving my eyes from left to right across that wide field caused fatigue. Screen readers helped me maintain focus, but I would just opt to browse on my phone instead.  The new layout provides short, digestible lines of text, and the white space creates a cleaner, focused appearance. I do agree that modern web design sucks, but I find this revamp to be helpful. Otherwise, I would love to use MonoBook!
 * I'm sorry you're having a difficult time with the new layout. It looks like many people are in the same boat. I'm glad we are able to toggle between different layouts in order to figure out what works best for us. All I can say is that I'm thankful to have the new layout as an option. TheCowboyPirate (talk) 08:39, 1 March 2023 (UTC)
 * The only good thing about the redesign is the TOC sliding down with us on the left as we scroll the article. Everything else is bad. The one thing we could have used is a dark mode and we're being told it *was* technically impossible to do, has recently become possible, but won't be done regardless. I've never heard anything like it. 81.100.55.96 00:26, 31 January 2023 (UTC)
 * THANK YOU. It looks SO bad dude. This needs to be reverted ASAP. Thank god they at least made it easy to change back. Sleampy (talk) 23:30, 31 January 2023 (UTC)
 * Agree. Created a Wikimedia account today to change my theme preference, lol Jessveness (talk) 07:35, 2 February 2023 (UTC)
 * I am so glad I am not the only one that thinks the new layout is god awful! I thought I was going insane when I was google searching "new wikipedia layout" and all the top results were news articles with headlines like "Wikipedia gets its first makeover in over a decade… and it’s fairly subtle" (link). I was so happy when I found out that I could get rid of the layout by logging into my account. Sockbucketfrance (talk) 08:35, 2 February 2023 (UTC)
 * Definitely agree. New look is a piece of shit. Hire some UX designers! and think twice - it looks ugly on the huge PC screens! 213.210.175.85 12:05, 3 February 2023 (UTC)
 * Couldn't agree more. It is absolutely horrible. 213.160.161.52 21:56, 3 February 2023 (UTC)
 * I was trying to save my appearance preferences to one of the older themes, and it straight up will not apply. Every time I re-visit a wikipedia page it is set to vector 2022. Is there a fix for this? I've already cleared my cache/cookies. CapSAR (talk) 03:40, 5 February 2023 (UTC)
 * I agree! this needs to be revised back to the older verson by default. Webpages need to be functional, and not minimal. The new layout is not even optimized to view more text! Haldardhruv95 (talk) 05:57, 5 February 2023 (UTC)
 * i fully agree!
 * been using wikipedia for all my life and this new ui is a major shock, whos fucking idea was it to change it without a poll or something? Zekromisblack (talk) 00:56, 6 February 2023 (UTC)
 * I am more worried if it gets worse, like when they start introducing a fixed sticky nav toolbar in the next design (I thought they listened in 2020) and ram it in yer face constantly as you scroll the page where it is in the way and distraction.
 * I am totally against it. It should be down the user what they want to see constantly on their viewing and not a few people who think they want it stuck constantly against their wishes in the guise that it will help and the users are somewhat stupid and confused.
 * They will loose my donations once they do that on Wikipedia. MrMobodies (talk) 02:45, 14 February 2023 (UTC)
 * Agree, less intuitive, less effective real estate. Suggest making it optional, not default and seeing how many actually opt-in. Saucypuck (talk) 01:23, 8 February 2023 (UTC)
 * Have to agree, unfortunately. While I don't have a flickering issue, the layout is absolutely terrible and seems to combine the worst of a desktop and mobile layout in one. Please go back to the previous default and save us from the weirdness of wasted space combined with restricted element sizes. There's no reason to make such a change here - sometimes something is just good and you should leave well enough alone. P.S.: it's not "subtle". Wolfbeast (talk) 08:19, 9 February 2023 (UTC)
 * I agree! I made this account just to change to Vector legacy... I love you Wikipedia but this new layout has go to go! 178.55.41.49 10:04, 11 February 2023 (UTC)
 * I would also like to express my discontent with the new layout. Like many people here, I've made a wikipedia account just to go back to the old theme. 79.186.222.249 17:26, 11 February 2023 (UTC)
 * I'm a long time donator and small time contributor to wikipedia, and I add my voice to what appears to be hundreds of others concerning the layout change. It is incredibly cramped, counterintuitive and disorienting, and overall much worse than before. "Improvement" for the sake of improvement is a modern plague. Considering the overwhelmingly negative nature of the feedback I see here, why isn't this change reverted at once? Numero4 (talk) 06:49, 12 February 2023 (UTC)
 * I know, why is it under desktop "improvements" Higuys153 (talk) 04:52, 13 February 2023 (UTC)
 * I cannot claim to be an expert in editing Wiki pages, but as a retired academic I have a lifetime of reading journals in science. I'm now not too well and most of my Wikipedia-reading is done on a 15" laptop while sitting in a reciner chair.  I typically spend hours a day reading it.  I also take the trouble to donate for this :-)   I use Firefox and I have a large collection of bookmarks, which I normally keep visible on the LHS of the screen.  For a little  while I have noticed that the longer pages of Wikipedia have lost their valuable pale blue indexes, so useful because as you read parts of a page, the sections you have previously visited change colour.  Very recently I have discovered that if I close down my bookmarks view I see a sort of quasi contents list (with nothing of the precision of the old contents lists).  Also, there is stuff on the RHS that I hardly ever look at (was it ever there before?).
 * Today I have looked around and discovered this "skins" issue, and if the changes I am witnessing are anything to do with this, then I don't like it - AT ALL. The old American saying "If it ain't broke then don't fix it" comes to mind. I pretty much agree with all the above complaints and I think it's time Wikipedia did a "revert".  I note some commentators suggested that the new presentation should have been an option to opt into for a year or so; that would heve been much sounder treatment of us users.
 * At this point I have just gone to my desktop with its 24" screen an run up tabs showing the Vector 2022 and previous skins. To me it's no contest: lots of white space on the new skin, pleasant document-style layout on the old.  Anyway, as I now know how to view pages using the old skin, that's what I'll be doing. Bicyclic (talk) 16:51, 13 February 2023 (UTC)
 * I see a SPAMMY FIXED HEADER here but thanks to this extension (CAN'T BELIEVE I expressed my concerns in 2020 to grant user a choice that I am at the liberties of browser extension like this one:
 * Chrome: Sticky Header Hider aka Fixed Header Fixer
 * Firefox:StickDucky
 * This page looks nicer
 * "Currently, many functionalities on wiki pages are only available to users at the top of the page."
 * NO I DON'T WANT THAT.
 * Main page:
 * "This becomes problematic on longer pages, when scrolling past the first few paragraphs means the user would need to scroll back up to access the tools and other resources again." I'd rather do that than have something slapped in my face constantly. Dont under stand how annoying that is". RUBBISH! Put on the side panel then.
 * If ANYTHING IS problematic it is having fixed nav toolbars and widgets rammed into my faced constantly and follows down the page as I scroll away from them totally unwanted and undneed and they are still there in the way and as a distraction.
 * "Our proposed method of addressing this is to make the site header “sticky” This means it stays fixed to the top of the screen (above the content) as you scroll up or down the page."
 * No I DON'T WANT THAT. That is NOT HELPFUL THAT IS ANNOYING.
 * It wasn't a problem before LEAVE IT ALONE.
 * Absolutely no regard for the preferences from users.
 * The side panels was fine as long as I can hide it. But when you start slapping things that span the top the follow down the page, unable to hide it that maybe unwanted by the user as in in the way, that is what I class SPAMMY BEHAVIOUR. Reminds me of the browser toolbars that came installed with flash player and adbobe web installers and also the so called "free games" last decade.
 * The tools above I see in this form that seems GOOD enough until you take them away and put them on the spammy toolbar that gets hidden by the extension.
 * Developer: "The users are very stupid and confused and don't know what they are doing, they are naturally born with a very low IQ level and low abilities which means they can't navigate websites and can be very challenging for them so a fixed header will help people in that it is always there if they want it or not which means it is quicker and easier to get to... lets plaster it everywhere for their own good."
 * No I don't want it. I want it left alone.
 * So far so good on the exisiting wikipedia. I don't sign inI just read articles. As soon as I see a fixed nav/header/toolbar on Wikipedia you can forgot the donations.
 * I do not have difficulty using it, I do however have great difficult navigating a website with unwanted fixed things that are in the way of the contents and serve as a distraction. instead of flowing with the rest of the page. MrMobodies (talk) 02:20, 14 February 2023 (UTC)
 * The new look is awful, with far too much white space. Perhaps Wikipedia should provide users some simple control over the appearance. And perhaps browser makers could get together and incorporate some sort of "style" preference (eg. navigator.style="[compact|mobile|desktop|...]" then every web site could automatically provide multiple css choices accordingly. Unfortunately CSS has become grossly convoluted and overly complicated, as have the javascript intrusions. Really this whole UI mess needs a lot of cleaning up. 208.71.172.42 03:05, 14 February 2023 (UTC)
 * It looks like it was designed for mobile not desktop, absolutely terrible and unneeded change. I hope they're listening instead of burying their head in the sand until the criticism dies down then declaring it a success based on people giving up. Thenewdesignisterrible (talk) 07:15, 14 February 2023 (UTC)
 * Replying to concur, the new layout is terrible and highly inaccessible. The design is completely inappropriate for Wikipedia. Freedom4U (talk) 03:33, 16 February 2023 (UTC)
 * the new layout is terrible on desktop, *especially* for a multilingual user like me 2601:600:C980:2DA0:80BF:252A:BF4:8EBC 12:08, 18 February 2023 (UTC)
 * I agree, I hate everything about this new layout Muddiebuddie (talk) 04:09, 19 February 2023 (UTC)
 * Agreed. Had to switch back to Vector Legacy 2010 in Preference here:
 * https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering Intrepid-NY (talk) 16:11, 21 February 2023 (UTC)
 * agreed. looks worse and harder to read 128.6.36.140 20:16, 27 February 2023 (UTC)
 * Agreed, Vector and in particular the left hand 'bookmark' or whatever it's called removes too much content. The previous version (2010) was much easier to read in my opinion. Can we improve without taking away too much of the content which the reader wants to read? Textualism (talk) 11:11, 28 February 2023 (UTC)
 * Agreed, I had to make an account just to get the old layout back.
 * For me the most annoying thing is that the language selector is hidden in the new version. As a multilingual user I usually read articles in all languages I can read to get the most of it. 88.115.148.22 07:18, 3 March 2023 (UTC)
 * The only reason I made an account was to revert it to previous layout and provide feedback on how much I HATE this new layout.
 * It reminds me of when someone sends you a mobile link on desktop and the .m.wikipedia in the URL causes it to look poorly formatted with a bunch of useless white space. RevertToLegacyLayout (talk) 08:21, 3 March 2023 (UTC)
 * Agree 2A00:23C5:DC80:6301:0:0:0:1083 16:00, 19 March 2023 (UTC)

Came here to say the new layout looks horrible. Whose idea was this? 69.245.61.93 17:32, 23 January 2023 (UTC)

Signed up just to agree how horrible the new layout is. I have a 2560x1440 display and the new design uses 1/3 of it. Why are we treating desktop sites like mobile sites. You HAVE a mobile site, mobile.wikipedia.org, use that for you vertical/skinny text display. Stop taking away my screen real estate, you are NOT fandom. Stop ruining your website experience. --Kinomora (talk) 21:30, 31 January 2023 (UTC)

It's growing on me. But there's always the option to stick with the old layout. I just got here by clicking through the "preferences" menu. PaulHammond (talk) 19:32, 23 January 2023 (UTC)

Vector 2022 must die.

Agreed, I made an account just because i read you can change the layout back to the original and when the survey asked what reason i had for creating my account today and since it didn't allow me the option of telling them to delete this new layout i'm posting it here

I agree, the new design sucks. The one function I use as a multilingual person - changing language - has for some reason been hidden behind a drop down gadget. "More prominent" my ass, it's much less usable now than simply clicking on the language on the left side. --2A00:5500:80E8:AB00:0:0:0:100 18:01, 24 January 2023 (UTC)


 * This was the key problem that drove me to log in and setup preferences. Frequently change languages. Used to be a consistent annual donor, but clearly they don't need the money if there's budget to waste on removing all the functionality out of a UI that wasn't broken. Everyone who signed off on this, the whole way up the management chain should tender their resignation immediately. Dvulrich (talk) 20:30, 25 January 2023 (UTC)
 * Fully agree with you! I don't get why websites that are LONG established and work perfectly fine feel the need to be..... *sigh* [record scratch, turns baseball around] HIP! With it! In with the crowd! Not like your parents! So don't frown! [end lame 90's nonsense that ad companies though was cool] They need to stop. They all need to stop. Pinkfluffyunicorns88 (talk) 03:29, 4 February 2023 (UTC)
 * It is more prominent. English is not my native language, but the majority of articles I read, are in English. Every now and then, I change between English, Norwegian, Danish, Swedish, and a few times in the past, even French. Heck, I've even looked at articles in German. I prefer the new drop-down in favour to the old list of languages. Now the languages are always in the same spot, there's no long list of text claiming attention when I don't need it, and most importantly: no more need for scrolling to change language. That was so annoying about the old design; having to scroll down.
 * And now that I'm here, I'd like to inform you that the old design was not perfectly functional. I've tried creating a dark mode skin on top of Vector, and that's a truly horrible experience. Technologically, the old Vector skin was terrible. And it was not built for the screens of today either.
 * I hope the redesign of Wikipedia can bring us a much easier experience for building custom skins. Imagine, a future with lots of skinning abilities. Where those that want thick borders get that, those that want no borders get that, you can freely change between light and dark modes without issues, etc. Andcraft (talk) 04:03, 26 February 2023 (UTC)

I concur: this 2022 as a default is a horrible waste of page space. 99.73.36.110 01:43, 25 January 2023 (UTC)


 * Same here. Not only doesn't it look like anything educational, it wastes space on any screen bigger than 8", and the stark whiteness leaves you lost in space. I switched back to the one with the book, that at least looks pretty. 92.200.175.206 20:36, 29 January 2023 (UTC)
 * The new layout of Wikipedia is horrible, we all know that at this point. But I noticed something entirely else. The English version of Wikipedia is downgraded with this Vector 2022 nonsense but the German and Russian Wikipedias use the superior old Vector 2010 layout. Yes this is true-you can check this right now if you don't believe me. I do not know Russian or German language, I was just clicking around to see what is going on with their layouts. So good for them and for English readers we get the bad user experience.
 * Why the team that works on this decided that the English readers and editors should be tortured with this new layout?! How and when the other non-english communities have negotiated to be spared and not suffer the Vector 2022 disaster??? They have their voice heard and opted out but we the English using community are second class citizens now? How the other communities managed to convince you and we fail when we say we do not like Vector 2022? 94.26.15.134 16:29, 30 January 2023 (UTC)
 * Agreed. This is a massive downgrade on anything but a small phone. Varixai (talk) 16:19, 13 February 2023 (UTC)
 * Created an account just in order to keep reading in the legacy layout... The UX for a multilingual user is terrible, you need to click your way through some pointless language menu rather than just select the language from the box to the left (where you also instantly see in which languages the article is available). And besides, on a UHD screen 70% of the screen surface is displaying nothing... Why would you do that? That's what the mobile layout is for, isn't it? It can be safely assumed that desktop users are using horizontal displays, so why optimize for vertical displays?
 * I really hope that this way of design does not become the new standard. Wwlaa (talk) 22:48, 5 March 2023 (UTC)

I'm making a wikipedia account just to get away from the waste of space.

Make an account? - Thank you, I didn't know about that. Vector legacy is really a more enjoyable experience. It's why people go to cinemas even though they can watch at home. What a difference. Changing the format for mobile is understandable but doesn't make sense for desktops.Preroll (talk) 16:21, 5 February 2023 (UTC)


 * Just another who thinks this 'new look' is nasty, harder to use, harder on the eyes, just plain annoying, effed up bs.  😨😡 Wikiwavy (talk) 17:24, 10 February 2023 (UTC)


 * This mess seriously undermines the credibility of Wikipedia -- as if Wikipedia didn't already have ENOUGH credibility problems.


 * The previous "skin" was clean, clear, matter-of-fact -- giving Wikipedia at least the appearance of being a no-nonsense reference -- and was far easier to use.


 * Where did the article's Table of Contents (ToC) go? It's no longer visible (unless you poke around and find the pop-up, which -- if it's a moderately long ToC -- scrolls off the screen, and is horribly awkward and frustrating to use.


 * I finally figured out I could undo the damage, at least when "I" view it, by making changes to the "Preferences" setting (I'm a Wikipedia "Veteran Editor," extensively certified computer professional, state-licensed educator in computers, and former award-winning web developer, so I should have been able to figure out a personal solution, but it was not obvious) -- and MOST ordinary (non-editor)  Wikipedia  visitors will have NO idea the option exists.


 * This screw-up is what happens when you let some amateur idiots make changes for the sake of change -- they'll "fix" what isn't broke, break it as a result, and then shout "Progress!"


 * Raises extremely serious questions about the leadership, governance and future of Wikipedia. Penlite (talk) 13:05, 12 February 2023 (UTC)
 * What do we have to do to get this eyesore reverted? It's honestly the worst change I've ever seen. Dyaluk08 (talk) 10:24, 26 February 2023 (UTC)


 * '''I finally figured out how to go back to the old look, or so I thought. Only works for the one page you are on. Surf to another page, ugly look is back. StyxinConn47 (talk) 18:05, 2 March 2023 (UTC)
 * Wanted to add that taking the advise of someone at Wikipedia, I logged in and was able to set a preference to revert page format back to the old look, which I did immediately. I cannot stand the way they shoved all this empty space on the pages over to the left side, while the meat of the site takes up the right two thirds of the screen. But now when not logged in, the "[Hide]" switch above the wasted space won't even work. This is with Firefox V. 80 something. This is so crazy. StyxinConn47 (talk) 18:52, 17 March 2023 (UTC)


 * On the assumption that sheer numbers of comments do actually count for anything: The new style is indeed (I'm afraid) really horrible. Depressing to see Wikipedia get sucked in to the current fugly flatso-design fad (that I fervently hope will quickly go out of 'fashion' soon once everyone sees it for the emperor's new clothes that it is). Painfully searing white everywhere (the previous theme wisely used gentle off-whites and grey shades to elegantly put secondary UI areas into the background and make for a more relaxing reading experience). From an accessibility perspective the biggest loss for me is the lack of that good contrast and vertical line separator between the left hand menu and the main content area: now all just an endless sea of indistinguishable searing white, and, when I am reading, without those subtle but essential separation cues (and with an excess of horizontal whitespace that doesn't have the needed tight margins to even remotely work as a "newspaper column" substitute), my eye is irreversibly drawn to the left hand edge of the window at the end of Every Single Line, causing a real 'low level' brain 'glitch' in trying to read. Ugh! --Davecykl (talk) 21:42, 14 March 2023 (UTC)
 * I agree, new design is horrible. I think the new design is very wrong way. We are in 2023, full HD, 4K, 8K, big screens, etc... why should we make narrower pages, websites??? Wiki has already responsible mobile version. For example many people are using 1920x1080 screens, in this case many pages with lists, columns with lot of information, images are broken now (I edit many of this). The left area is total empty and unused in most of the Wiki pages. And there is a big white gap on the right side of the Wiki pages also. What is the reason to make the content, the information so narrow??? Check out these pages with new and old design: I support to revert the narrow layout of the new design. OrionNimrod (talk) 10:30, 15 March 2023 (UTC)
 * As desktop computer user on Firefox, I agree with posters here about the new Vector 2022 design more difficult to navigate, less intuitive. For example, the index of sections in an article has disappeared in Vector 2022, and when I re-size browser, the index of section re-appears. Which (sub-genius) designer dreamt up this useless feature to inflict upon us?! Previously this index was static right below general summary. And so many other intuitive features/layout in Vector 2010 have now disappeared to make life so much harder for Wikipedia users. If Wikipedia is trying to lower readership with Vector 2022? Congratulations the Vector 2022 layout has soured my Wikipedia user experience that I think 3 times before clicking on any Wikipedia link now. Thank you Wikipedia for breaking was was NOT broken. Puffin10 (talk) 16:47, 15 March 2023 (UTC)
 * It's narrower precisely because we have larger screens. If there were content on every part of the screen, without any margins, then people would have to constantly swivel their heads side-to-side. I have a 32-inch-monitor and I don't want to have to adjust the size of my entire web browser just to be able to read one website without straining my neck. Galactipod (talk) 13:35, 30 March 2023 (UTC)
 * Just to add to the chorus of voices here - it's a bad new design, the last couple of defaults were both good. The new one's not without some silver linings, floating TOC is nice, but it's a very big downgrade overall. In particular the whitespace is an assault on the eyes and it's sad to see yet another website make this same mistake - an absolute cardinal sin of UI design in my book. I really hope it gets reverted back to Vector 2010 as default - I'm yet another IP user who now uses an account solely to avoid the redesign but as I use a VPN this is not exactly convenient. --AcumenDonor (talk) 10:59, 21 March 2023 (UTC)
 * Everybody expressing oneself here (in a very respectful way...) is just having a basic reaction to a change.
 * Name ONE quality website that hasn't been shrinked in width?
 * You are talking about user experience, but you are talking about your own habit only: how can reading a sentence on a 50cm width is a good user experience?
 * It also solves one of the main layout issues by being accessible by any kind of screen shapes: before, every contributor was changing the image organisation according to his own device, never caring about what screen others could have. Now everybody has the same layout: how can this be a problem?... Daehan (talk) 12:59, 21 March 2023 (UTC)
 * It's been two months. Maybe you could write it off as a reaction to change if it was two days in but the dust has settled and it's still not going down well. Personally I delayed posting (and missed the votes) precisely to not have a knee-jerk reaction, but my negative reaction is actually quite a bit stronger now than initially. I've definitely seen worse redesigns but decent ones, and even many bad ones, don't usually still rankle months later.
 * I'm not going to spend too long on the irony of saying "you are talking about your own habit only" and then immediately talking about your own preferences, but I will point it out.
 * While we're talking subjectivity - my display is 50cm across, I have my web browser at full screen and, yes, I prefer reading like that and yes, subjectively, that's a good user experience. In contrast the ~60 characters per line that's often posited as the optimum line length is nigh-on unreadable for me on a monitor, though fine in print. I don't know how solid the evidence is that this is any kind of optimum (I'm very sceptical given how vague the usual source given is) but it certainly isn't a universal optimum!
 * Fortunately the new layout isn't quite as bad as that but I personally never experienced the issues you had with the old layout (not to say they don't exist, but they're clearly not that major) and think the old layout was better at accommodating different tastes and was therefore a better default. Especially given logged-out users can't set layout preferences with cookies. --AcumenDonor (talk) 15:28, 21 March 2023 (UTC)
 * As a person with a 32-inch-monitor, the whitespace is lovely. The content is exactly where it's comfortable for me to look: in the middle of the screen. The alternative is constantly swiveling my head side-to-side and straining my neck. Galactipod (talk) 13:42, 30 March 2023 (UTC)

Dark Mode
Make any theme with native Dark Mode. Time for filling everything around with any color, on condition that it is "white", has passed.

Seregadushka (talk) 21:45, 7 November 2022 (UTC)


 * someone had a decree of the Ministry of Health of the United Kingdom on reducing the brightness of monitors. I can't find the link. The savings were measured in hundreds of millions of F (reduction of electricity consumption, equipment resource, treatment of eye diseases, payment of sick leave, ...). It's time for Wiki to listen to this. Seregadushka (talk) 00:26, 8 November 2022 (UTC)
 * Native dark mode is necessary for global environmental friendliness and for a better experience.
 * It reduces power consumption when using OLED displays.
 * Also, white screens are very glaring when transitioning from other dark-mode enabled websites. (And the new theme is more "white"!) Futchitwo (talk) 17:29, 9 November 2022 (UTC)
 * @Seregadushka, @Futchitwo, thank you for your comments. I've just updated our answer about dark mode in the FAQ.
 * In short, we are not going to do that as part of this project. At the beginning of the project, we would even say that it's not possible. It has become technically possible recently, though, and someone at the Foundation could work on that.
 * Perhaps you would consider taking part in the Community Wishlist Survey and voting for dark mode? This is an easy way for editors to ask for a specific technical change. The period for making proposals will be in January, and voting would be around late January - early February. (See the Wishlist's FAQ to learn how to take part.) Thank you! SGrabarczuk (WMF) (talk) 22:55, 9 November 2022 (UTC)
 * I can't figure out how to participate in the survey. Where is the choice of questions ? 4 periods are specified, but there are no actual tasks of this survey. Prudently. On the topic -- now absolutely all operating systems of mobile phones and computers have "Dark Mode". Stop hanging around in the past, when there was nothing but a white Apple. If the design is only white? My eyes hurt from the work of your designers ! Seregadushka (talk) 03:27, 16 December 2022 (UTC)
 * Hey @Seregadushka. We also believe having the dark mode would help. As I wrote, this mode has only been made possible recently, as a consequence of this project. (The Survey hasn't started yet - the first phase will start in January.) SGrabarczuk (WMF) (talk) 16:11, 16 December 2022 (UTC)
 * And my eyes hurt when I try to read bright text on dark background. Also you seem to be (deliberately?) forgetting that even Apple I had white text against black background (as did Apple II and MS-DOS) - I'd say there's a reason we moved away from that. 2A02:A312:C539:8D80:78DE:760D:452F:23E2 19:58, 19 January 2023 (UTC)
 * Talk:Reading/Web/Desktop Improvements|I see you don't even mention these reasons, because there is no reasonable explanation for this. What you don't know how to do working with CSS styles is not the reason. The whole world is striving for green technologies. But you don't understand (intentionally?) that millions of monitors operating in the mode of maximum energy consumption disrupt the general movement of humanity to reduce the impact on the environment. Hire other programmers who understand CSS. Seregadushka (talk) 23:26, 19 January 2023 (UTC)
 * "At the beginning of the project, we would even say that it's not possible."
 * This is a completely false statement. From a programmer's point of view I can guarantee everything that such a change is extremely easy.  But on a LARGER NOTE -- the Wikipedia Android Mobile App has had dark mode for quite some time.  And the time is far overdue for the web interface to catch up and stop being both a drain on electricity and a strain on eyes. ClimbAll (talk) 09:34, 21 January 2023 (UTC)
 * I wouldn't call dark mode easy, or impossible. Somewhere in the middle. There are dozens of CSS elements you never think about or notice until dark mode messes them up.
 * I have been using Skin:Citizen for quite some time on my wiki with very few problems. It has an excellent dark mode that automatically engages when user browser preference is set.  I think WMF should make it available for logged in users. Flounder ceo (talk) 16:18, 31 January 2023 (UTC)
 * Hello from a fellow programmer. I have tried making a dark mode of the legacy Vector skin. It's horrible. You are very much wrong when you say that it is extremely easy. It seems like you have very little experience in this field. Building a system with both light and dark modes from scratch, isn't so bad. Wikipedia wasn't built for that, and the articles written since were styled for a bright interface.
 * I also use the mobile app, and in a dark style. I like it. But you can't escape from the fact that the mobile app was built almost from scratch, and that there's several visual problems with it.
 * The Wikipedia system wasn't constructed for this. It seems like the new one is enabling that. That's great. Andcraft (talk) 04:13, 26 February 2023 (UTC)
 * > At the beginning of the project, we would even say that it's not possible. It has become technically possible recently, though
 * This is an insane thing for you to have to say. If the redesign made darkmode impossible and it has only recently allowed for it for be done very difficultly, you should consider whether the redesign is any good at all. 81.100.55.96 00:15, 31 January 2023 (UTC)
 * Hello! Let me clarify, I meant this project has just recently made it possible to build the dark mode. Before that, with the previous skins and in the early stages of the project, it wasn't possible. SGrabarczuk (WMF) (talk) 02:01, 28 February 2023 (UTC)
 * I am astounded that after such a large update to the UI, native dark mode for desktop is still not a feature. Frosck (talk) 23:31, 21 January 2023 (UTC)
 * In fact, I made a naïve assumption that a native dark mode would be a part and parcel of the new UI— calling it "not possible" is laughable at best TheLucifer0509 (talk) 04:20, 22 January 2023 (UTC)

There are several dozen applications for Windows browsers, that have the conditional name "Dark Mode". One change the display for ANY site. And they are practically not mistaken. I.e. they have a universal mechanism of operation for all Internet sites. And you can't make a "Dark Mode" specifically for Wikipedia, when you don't have to guess, all the properties are known. Almost always people make decisions (and answer questions and suggestions) who understand little in questions asked. I'm not a programmer, I haven't sold a single website, I'm not paid to know CSS, it's a hobby for me. As the programmer ClimbAll (talk) has already said, this is extremely easy to do:

And that 's all ! Currently, the whole Wikipedia works on the same CSS style, only the properties are swapped (even if you use PHP, it won't be much more difficult). You only need to provide switching  and Of course, you can choose different colors for texts of different purposes, different degrees of "grayness" of the background of the pages. But these are conventions. I assure you, the entire amount of work will not go beyond 10 KB :) Seregadushka (talk) 17:36, 24 January 2023 (UTC)


 * For users interested in Dark mode who have not yet participated in the related discussion of the Community Wishlist Survey 2023, you can do so here meta:Community_Wishlist_Survey_2023/Reading/Dark_mode. Patafisik (WMF) (talk) 11:07, 31 January 2023 (UTC)
 * Last year WMF removed dark mode from the wishlist. Flounder ceo (talk) 16:07, 31 January 2023 (UTC)


 * The Wikipedia App has already two different dark modes and a sepia one. On the desktop I always use the firefox add-on Dark Background and Light Text by Mikhail Khvoinitsky with the option "Stylesheet processor", but sadly not everything is displayed correct at Wikimedia-Projects. Links are all blue for example. Also it takes more cpu usage instead of loading a native darkmode site. --KleinerKorrektor (talk) 19:34, 18 February 2023 (UTC)


 * As an aside/work-around, the Dark Reader browser add-on, available for most common web browsers, is a very useful add-on which generates a dark mode for any website as the page loads. --Davecykl (talk) 22:11, 14 March 2023 (UTC)

Anchors imprecise
I've been encountering a problem that I think may be caused by New Vector. When I click on the table of contents links at a long page, the place it scrolls to often isn't exactly the thread I clicked on, but rather one or two above or below. Is this a known issue? &#123;{u&#124; Sdkb  }&#125;  talk 22:36, 9 January 2023 (UTC)
 * , Is this on talk pages? Pbsouthwood (talk) 06:30, 10 January 2023 (UTC)
 * Yes, or project pages that consist of discussions like w:WP:VPR. &#123;{u&#124; Sdkb  }&#125;  talk 06:43, 10 January 2023 (UTC)
 * I'm not yet able to reproduce this on w:WP:VPR. What section are you clicking on, and what section is appearing on your screen? Can you provide links to other pages you're seeing this issue on? Also can you provide other potentially relevant details (operating system, browser, browser width, etc.). Also can you check if you can reproduce this in an incognito/private window (append  to the URL). Thanks,  AHollender (WMF) (talk) 05:06, 11 January 2023 (UTC)
 * I tried to replicate it in an Incognito window with Vector and couldn't, so maybe it's an extension I'm using. I'll do some further testing and see if I can isolate the issue. &#123;{u&#124; Sdkb  }&#125;  talk 16:37, 11 January 2023 (UTC)
 * Having paid attention for a few days, the issue seems to occur when I click on notifications from conversations I'm subscribed to, not when I click on a table of contents. I'll follow up with the talk pages project. &#123;{u&#124; Sdkb  }&#125;  talk 16:32, 16 January 2023 (UTC)
 * Hi @Sdkb, thank you for your feedback, are you still experimenting this? I reported your issue here in the talk page of the Topic Subscriptions project, hope this should help. Patafisik (WMF) (talk) 16:51, 17 February 2023 (UTC)
 * Yes, I have been. Thanks! &#123;{u&#124; Sdkb  }&#125;  talk 18:28, 17 February 2023 (UTC)
 * I don't know what exactly is causing this for you (I can't reproduce), but I looked into problems with links to sections in Vector 2022 in general, and figured out why they happen and proposed a fix at T330108. Matma Rex (talk) 02:58, 21 February 2023 (UTC)
 * Much thanks, @Matma Rex! That should hopefully fix it! &#123;{u&#124; Sdkb  }&#125;  talk 03:48, 21 February 2023 (UTC)

Sticky header is not tall enough for a two-line header
The header for logged in users on the Konkani Wikipedia is two lines to accomodate two scripts. When you scroll down, the sticky header is not tall enough for two lines. Should we fix this by modifying the height of the header locally in the css, or should it be fixed globally in the software skin? The Discoverer (talk) 07:22, 14 January 2023 (UTC)


 * Hey @The Discoverer, thanks for reporting this. To clarify: does this only happen on the Main page, or on other pages as well? AHollender (WMF) (talk) 14:10, 16 January 2023 (UTC)
 * @AHollender (WMF), It only happens on the main page, because the main page is the only one that is explicitly formatted to be on two lines. On all other pages the headings are shortened using ellipses (...) and do not wrap. The Discoverer (talk) 15:52, 16 January 2023 (UTC)
 * @AHollender (WMF) / @Patafisik (WMF) / @OVasileva (WMF) / @Zapipedia (WMF): Please could you give some feedback regarding this? The Discoverer (talk) 06:36, 2 February 2023 (UTC)
 * Hi @The Discoverer sorry for the delay. I open this task. Patafisik (WMF) (talk) 12:51, 25 February 2023 (UTC)
 * Grazie, @Patafisik (WMF) ! The Discoverer (talk) 18:51, 25 February 2023 (UTC)

Enter key is not left click
When I'm finished typing something in the search bar and hit enter, I expect the top result to show up, not the page where my cursor currently rests. If I want to click on a page that's not at the top, I'll just use my mouse or touchpad's left click because that's closer to my fingers. This is a big problem for me as I often use keyboard shortcuts and therefore have to physically move the cursor away in order to search properly. lol1 VNIO 🧧🐈 ( I made a mistake?  talk to me ) (talk) 20:35, 18 January 2023 (UTC)


 * Day two of this problem and I've decided to change back to 2010. lol1 VNIO 🧧🐈 ( I made a mistake?  talk to me ) 20:03, 19 January 2023 (UTC)
 * It seems this isn't the case anymore. Now I feel more comfortable with V22. lol1 VNIO 🧧🐈 ( I made a mistake?  talk to me ) 10:27, 25 February 2023 (UTC)

Lack of left border
I tried giving Vector 2022 a shot, but the lack of any kind of border or even a change in the background colour between the text and the whitespace to the left of it is a big problem for me. It is difficult to explain, but I felt something similar to strong sense of vertigo when I started reading text after a certain point.

I identified the cause as the emptiness in the left space after you scroll far enough down. It is alright at the top, since the off-colour background of the sidebar serves the role as a border, however, there's nothing in that space once you scroll further down. This issue isn't present in Vector 2010 because it has an explicit border in addition to a different background colour beyond said border.

Oddly, the feeling of vertigo is greatly reduced with the narrow mode, likely due to the whitespace being balanced on the right side, and there being an eventual change in the background colour. However, I highly dislike the narrow mode, so I wouldn't want to use that even without the vertigo. JAK0723 (talk) 05:18, 19 January 2023 (UTC)


 * I completely agree, expanding the view and collapsing the floating menus (because i 1. dont want the TOC on my screen at all times since it creates unnecessary visual noise, 2. am not an active editor so i dont need that tools section), looks like a barren css-less html webpage, no borders, no consistent spacing, the lines between headers starting and ending in random places... vertigo is exactly how i would describe it. looking back and forth from monobook to this mess, monobook feels way more defined and grounded, you can always find where the page begins, estimate the indentation by eye... this is autism speaking but its true. 147.32.90.103 01:44, 6 February 2023 (UTC)


 * Yes, I completely agree! I'm sad-but-glad to read that it's not just me that finds this a very real and very significant irritation. I had already commented about this exact problem in an earlier discussion further up the page, but just repeating here again to add to the comment/vote count: From an accessibility perspective the biggest loss for me is the lack of that good contrast and vertical line separator between the left hand menu and the main content area: now all just an endless sea of indistinguishable searing white, and, when I am reading, without those subtle but essential separation cues (and with an excess of horizontal whitespace that doesn't have the needed tight margins to even remotely work as a "newspaper column" substitute), my eye is irreversibly drawn to the left hand edge of the window at the end of Every Single Line, causing a real 'low level' brain 'glitch' in trying to read. Ugh! --Davecykl (talk) 22:40, 14 March 2023 (UTC)

Please sort the interwikilinks alphabetically - especially for visitors without an account !
It's been said from some dicussers here already (if you search the discussion arhives related to this

discussion) here in this discussion and i want to stress that this is my point of view, too !

I like switching between articles in German, English, Croatian - and sometimes i want to surprise myself by clicking at an unknown language. Switching with your new created language switch tool is a horror and takes me - an un unregistered user - a very lot longer, compared to the 2010 interface, to find myself the language i want to switch to.

Well I haven't, an I don't think others have (some might, of course) THAT geographic knowledge to guess what language is located in which region. Knowing how a language name is spelled is a very easy thing for me. If I know the alphabet and if I search Croatian, i look at the top of an alphabetical drop-down-list, if i search German, i will look more in the middle of the list, if i search English i scroll from Croation a little more farther down. This is an easy thing. So why did you create these regional blocks ?

So please: Do unlogged users a favour and give them a chance to choose a language list option, that gives them a sorted list as from a to z. Thanks - that would be a great thing ! 188.174.249.250 17:19, 19 January 2023 (UTC)


 * THoT_-_languages.png
 * Hi
 * the selection of user interface language is only available for logged-in users, who can disable it in their Preferences (at the end of the page, uncheck "Use a compact language list, with languages relevant to you."). For English Wikipedia, the input method contextual menu is disabled by default. Logged-out or anonymous users have already the list in alphabetical order, can you confirm please? When searching, you can just type the Language codes (e.g.,   or  ) and the language will be suggested by the functionality. For more information about the Universal Language Selector please visit the FAQ page. Patafisik (WMF) (talk) 08:31, 28 February 2023 (UTC)

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

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

The designers should fix this flaw in the new interface by simply bringing back the static TOC exactly as it is in the 2010 interface. The pop-up sidebar displaying the TOC can remain too, just don't display its floating button until the display is scrolled down to below the static TOC. It would also be a diplomatic policy decision (a no-brainer, really) to provide a user appearance preference for a static TOC, a pop-up TOC, or both. Dc.samizdat (talk) 21:35, 20 January 2023 (UTC)
 * I prefer also the TOC in 2010 interface. --Ensahequ (talk) 02:22, 21 January 2023 (UTC)
 * Yeah I agree, I like the static Table of Contents at the top of the article, I don't want to have to start scrolling to find the TOC so I can skip to the particular section of an article that I want to read. B 897 (talk) 04:28, 21 January 2023 (UTC)
 * I want to add my full support to bringing back the classic ToC. The new sticky ToC can coexist with the classic one instead of replacing. I think each serve different purposes and could be complementary. I also made similar comments in the w:Wikipedia:Requests for comment/Rollback of Vector 2022#Bring back the TOC. Thank you. Al83tito (talk) 05:43, 28 January 2023 (UTC)
 * Not to say its old good numbering scheme, now lost. No matter where the TOC appears, it should retain the numbering scheme. 37.134.90.176 07:55, 23 January 2023 (UTC)
 * I spent many minutes trying to figure out why the article I was editing had no TOC -- I went as far as asking on the Discord why the article was broken, trying to add a template, etc. Could have instead used that time to contribute. I agree that the old ToC takes up a lot of space but the new treatment is too radical a change. Mrflip (talk) 20:53, 6 March 2023 (UTC)

Some opposes and supports with same argument

 * Moved at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Rollback_of_Vector_2022#Some_opposes_and_supports_with_same_argument

Search bar doesn't work at the top on Amazon Kindle
For some reason I can't type anything in the search bar at the top in the new skin... 80.6.36.48 20:05, 12 February 2023 (UTC)


 * Hi @80.6.36.48, it is still happening? To be sure to exclude some causes: this answer helps you? If you are already filling the search box with a text and nothing happens: can you give us more details and describe your configuration (browser, browser version, OS) with an example of text you are searching for, and in what wiki it is happening, please? This is happening also when adding  at the end of the URL? This may be useful to reproduce the bug. Patafisik (WMF) (talk) 12:29, 27 February 2023 (UTC) modified--Patafisik (WMF) (talk) 08:54, 28 February 2023 (UTC)

No search suggestions just in Vector-2022
Nothing drops down, as I type. What could be a problem (and solution)? Атомный трамвай (talk) 13:51, 15 February 2023 (UTC)


 * Hi @Атомный трамвай, thanks for your feedback. First of all and to be sure to exclude some causes: this answer helps you? If you are already filling the search box with a text and nothing happens: can you give us more details about your configuration (operating system, browser and browser version, screen resolution), and an example of text you are searching for to reproduce the bug, please? This is happening also when adding  at the end of the URL? Patafisik (WMF) (talk) 08:45, 28 February 2023 (UTC)
 * Thank you for attention.
 * The issue you've mentioned doesn't help me at all, because a user there experienced replacing search field with button, and I don't.
 * Firefox 110.0, macOS High Sierra, 1280×800. Also, you can check out it by yourself — https://jantanoo.info, if it reproduced at your env (I sure, it does).
 * Whatever I type in search field, I ain't see a suggestion menu. As it should be shown regardless any text one type, so, I think, no need to mention any specific text I tried to type. And this issue is just about modern Vector — in classic Vector, in Minerva Neue, in all built-in skins there is the dropdown suggestion menu. I wouldn't be surprised if it is because of some incorrect setup — I am not so experienced admin and, for example, I've got a concept of MW's Gadgets just recently (and one of damaged gadget made a huge mess for my wiki and I haven't found a problem too long). And I remember, before I upgraded from MW 1.34.1, there was no this dropdown menu in classic Vector, too. On the other hand, I've made a serious re-install of MW and now it works on classic Vector… Атомный трамвай (talk) 12:39, 28 February 2023 (UTC)
 * I can reproduce it (Firefox version 110, Windows 10). When I type "т" in the search form on the top, suggestions do not appear. But if I click on the button "search" ("Найти") I arrive on this page. However, using the second search form under "Search results" ("Результаты поиска"), typing "т" I have the search suggest drop-down list. I report this issue and waiting for an answer. The new search functionality is described here. Patafisik (WMF) (talk) 14:59, 28 February 2023 (UTC)
 * Thanks a lot, I hope we are able to develop this more perfect way (together)! Атомный трамвай (talk) 07:10, 1 March 2023 (UTC)
 * Please look at the reply here. An additional information: if I'm not wrong, the first form is using Vue.js while the second one is using CirrusSearch. Patafisik (WMF) (talk) 07:27, 1 March 2023 (UTC)

Different looks in different Situations
I would have expected, that the look is consistent between Legacy and V22. It seems not to be. The pages all look different, depending, if you are logged in/out, which "project" you are on and what "dynamic buttons" you have clicked (width, hide, pin...). Is this really intended behaviour? The biggest issue I'm startled by is the different behaviour of the same skin while logged in and out (different menu, different font-size, different behaviour, different spacing). HirnSpuk (talk) 16:11, 17 February 2023 (UTC)


 * Hello @HirnSpuk. Some of this is intended. For example, right now, logged-out users don't see the sticky header or the page tools menu. But I think font-size or spacing isn't intended. Perhaps what you saw was caused by cache, and not our intended design. Would you be able to give specific examples of differences you didn't expect? SGrabarczuk (WMF) (talk) 15:48, 10 March 2023 (UTC)
 * @SGrabarczuk (WMF), sorry, Special:Diff/5778578/5779099, expecially Special:Diff/5779099/next and last but not least Special:Diff/5816368/5817068. I think the looks should be consistent at least in one project. The look (AND the feel as well) depend on window-width, screen-resolution, login-state, button-clicks, hover-buttons, personal configurations... I'm not able to give examples, it's the whole page. Just play with the window-size on different resolutions in wpen logged in and out and you'll hopefully get it. I'd recommend using a FHD-Display with standard-configuration. Use case: I often resize the window regarding the task I'm doing, I regularly log on and off on different projects, I use different resolution monitors... Regards HirnSpuk (talk) 16:41, 10 March 2023 (UTC)

Tewiki:User menu drop down
This is about Tewiki The User menu drop down has the following issues: __Chaduvari (talk) 01:37, 18 February 2023 (UTC)
 * 1) When page is not scrolled, when the mouse hovers on Contributions menu item, a sub-menu list appears with three links - contribs, translations, uploaded media. When I move the mouse to click any of these three sub-menus, the mouse moves over the tool tip (User menu) and this sub-menu list disappears. It is impossible to click these three sub-menus. When I move the mouse around the tool tip, then, the sub-menu list does not disappear.
 * 2) In the sticky drop down (when the page scrolled down), the sub-menu is not shown at all.


 * Forgot to mention an important point: The behaviour mentioned at point #1 above, is not noticed in enwiki. __Chaduvari (talk) 01:43, 18 February 2023 (UTC)
 * Hello @Chaduvari. I was trying to reproduce #1 issue at teewiki, but I was not able to do so (in my case, I can select the sub-menu items). Are you still experiencing it? Thank you. Zapipedia (WMF) (talk) 00:21, 21 February 2023 (UTC)
 * @Chaduvari, indeed I found this related task. Thank you. Zapipedia (WMF) (talk) 01:12, 21 February 2023 (UTC)
 * @Zapipedia (WMF) Okay, thanks for the link. __Chaduvari (talk) 05:08, 21 February 2023 (UTC)

Fresh from Tewiki
Noticed this in Tewiki - the link to add inter-language links disappeared. The drop down list has only two links- "Translate this page" and "Open language settings". __Chaduvari (talk) 01:58, 19 February 2023 (UTC)


 * Hello @Chaduvari. Could you please share a page in which this issue is happening? Does it happen in all the pages? Thank you. Zapipedia (WMF) (talk) 21:29, 19 February 2023 (UTC)
 * Hi @Zapipedia (WMF),
 * Tewiki_Langlinks_screenshot_Vector2022-21Feb2023.png You can see this issue on సిపాయి సుబ్రమణ్యం page. The issue is also noticed in Wikipedia:, Template:, Module: and Category: namepaces too (didn't check the other namespaces). In these namespace pages, only "Open language settings" link is there; "Translate this page" link is not shown. The adjacent screenshot shows the Main space page. Thanks. __Chaduvari (talk) 05:06, 21 February 2023 (UTC)
 * Hello @Chaduvari. Thank you. I think there are more than one issue here. Regarding the link to add interwiki links appears now, but perhaps it wasn't appearing temporarily? We've been working on the styling of this link. Anyway, for me now, it shows up in the "General" menu. Do you still experience this issue?
 * Regarding the "Translate this page" link in non-content namespaces such as Template or Module, it's by design, because the tool inviting to translate the page is only designed to translate content. But there may be some bugs about it. For details, see T316559.
 * Was my answer helpful? SGrabarczuk (WMF) (talk) 17:05, 10 March 2023 (UTC)
 * @SGrabarczuk (WMF), I see the "Add interlanguage links" in the general menu (on the right sidebar) now. Thanks. __ Chaduvari (talk) 06:35, 13 March 2023 (UTC)

Custom CSS for the Vector 2022 skin is not working for me!
Hi, Unfortunately, I was trying to edit the Vector 2022 CSS MediaWiki page on Meowpedia (miraheze wiki btw) but it sadly doesn't work. How do I fix it? My Miraheze username is 'BlahBlahBlah666' btw. 2A02:C7C:BD2C:B500:2023:D2C3:A0D2:B5E6 12:28, 19 February 2023 (UTC)


 * Are you trying to edit site-wide or user-wide? I don't see a https://meowpedia.miraheze.org/wiki/User:BlahBlahBlah666/vector-2022.css or https://meowpedia.miraheze.org/wiki/MediaWiki:Vector-2022.css page. That's where your user styles should be loading from.
 * Note currently both https://meowpedia.miraheze.org/wiki/MediaWiki:Vector.css and https://meowpedia.miraheze.org/wiki/User:BlahBlahBlah666/vector.css should apply to both Vector skins (Seems like the former is working?)
 * For security reasons, user styles/scripts are disabled by default. You'll have to talk to the admin of your miraheze instance to fix that if that's the problem. See mw:Manual:$wgAllowUserJs and mw:Manual:$wgAllowUserCss for more information. Jdlrobson (talk) 20:35, 27 February 2023 (UTC)
 * Sitewide. I've had to delete it because it wasn't working. How do I get this CSS script working?
 * 2A02:C7C:BD2C:B500:F8A3:2178:EE47:BE 13:24, 5 March 2023 (UTC)
 * Former version only works. The CSS doesn't apply to the Vector 2022 skin. Also, I waited 10 days and you didn't reply :/ 2A02:C7C:BD2C:B500:ED36:472A:30F4:7F7B 20:12, 15 March 2023 (UTC)
 * I might think some guy who creates the stuff for MediaWiki should fix Vector 2022 CSS because it does NOT work. 2A02:C7C:BD2C:B500:ED36:472A:30F4:7F7B 20:13, 15 March 2023 (UTC)

Space inserted in page title
Greetings, When I visit commons:User talk:Elizium23 I see the page title listed as "User talk: Elizium23". That is, a space is inserted after the namespace and before my username. This is not part of the page title, and it will mess you up if you copy-paste it. If I "View history" on the same page, no space is inserted. Other wikis, no space. Safe mode, still a space.

This may have occurred on other pages, because I recall being surprised by a copy-paste failure; it's subtle, so I'll have to continue watching for it. Elizium23 (talk) 13:53, 19 February 2023 (UTC)


 * In fact, the same effect happens with Vector Legacy, so this is not a function of the skin... why just on Commons? Elizium23 (talk) 13:55, 19 February 2023 (UTC)
 * This space is not added by this or any skin. It is added by DiscussionTools extension as part of Talk pages project. – Ammarpad (talk) 21:25, 24 February 2023 (UTC)
 * so are you saying that turning the title into something that cannot be copy-pasted is somehow supposed to be seen as a feature, not a bug? (If replying please ping me, I don't have a watchlist on this wiki.) - Jmabel (talk) 04:28, 15 March 2023 (UTC)
 * @Jmabel, I am afraid, you have to direct that question to the authors of the change not me. Here's the original task T313636. Here's the task to upstream the changes to MediaWiki core T315893 – Ammarpad (talk) 05:15, 15 March 2023 (UTC)
 * I doubt any remarks I make on a "resolved" phab report would even be looked at. In my view, this was a really foolish decision. - Jmabel (talk) 15:37, 15 March 2023 (UTC)

Custom CSS is not working for the Vector 2022 skin.
I tried editing the Vector 2022 CSS page on Meowpedia (which is currently private due to some technical stuff) but it doesn’t work. How do I get it to work? 2A02:C7C:BD2C:B500:940:A9B3:53AC:5EBC 08:33, 20 February 2023 (UTC)


 * Hi, thank you for your feedback, can you give more details, please? What custom CSS are you trying to use, with a link if available? Patafisik (WMF) (talk) 11:15, 22 February 2023 (UTC)
 * And what page are you editing.... —Th e DJ (Not WMF) (talk • contribs) 13:45, 22 February 2023 (UTC)
 * Sorry for replying 1 day late. The link is right here. Btw, it's a Miraheze wiki despite... UH... yeah. The background behind the article background should be the CSS colour 'papayawhip' on Vector 2022, but sadly I deleted it because it didn't work. 2A02:C7C:BD2C:B500:F5B0:6716:1368:719A 14:20, 23 February 2023 (UTC)
 * Reply is here. Patafisik (WMF) (talk) 09:49, 28 February 2023 (UTC)

Bug? Content jumping around
While reading up on Special:Permanentlink/5784366, and wondering, why the communities wish does not seem to be accepted, I found another issue with the toc: The content is "jumping around" because of toc/notoc funcionality. See: w:sw:Wikipedia:Mwongozo, w:sw:Wikipedia:Mwongozo_(Kuhariri) and the other "subpages". To replicate: open the links and narrow the page until content and toc is more or less within window-bounds. Then, when switching the pages, the content "jumps around". HirnSpuk (talk) 18:55, 20 February 2023 (UTC)


 * I think the user means:
 * If you are on a pretty narrow page (sub 1200px but over 700px)
 * If the main menu is collapsed
 * AND the toc is not collapsed
 * AND you are on a page with a ToC
 * AND you navigate to a page without a ToC
 * THEN the content on the page (visually) jumps from being indented ( by toc-width ) to being not indented at all.
 * This might be be unexpected and jarring and messes with your navigation expectations as a user. —Th e DJ (Not WMF) (talk • contribs) 13:43, 22 February 2023 (UTC)

"Reply" button in User talk
Hello. I know that this isn't exactly an issue of skin, but I don't know better place to ask, so: it is possible to turn off a "Reply" button in User talk pages? Once it was seen as default to reply on interlocutor page bcs of notifications, now many new users just click reply on their own talk without even a ping. It disturbs a fluent discussion between editors. --Wojsław Brożyna (talk) 08:05, 21 February 2023 (UTC)


 * I reported your answer here. Patafisik (WMF) (talk) 11:37, 27 February 2023 (UTC)
 * It isn't possible to turn it off for other users on your comments. Instead, I would suggest turning on "Automatically subscribe to topics" ("Automatycznie subskrybuj wątki"), so that you will get notifications about replies to your comments even if the other user doesn't add a ping. Or if you really want, you can turn off "Enable quick replying" on the same preferences page, but this will only change how the pages look like to yourself. You can read more about these features at Help:DiscussionTools. Matma Rex (talk) 17:59, 27 February 2023 (UTC)
 * --Patafisik (WMF) (talk) 13:48, 28 February 2023 (UTC)

Links on whitespace (table of contents, etc.)
I'm using the new layout for quite some time now and I like it. Great work, thanks!

One thing I absolutely hate, though: In the left-side nav bar, all the links seem to cover the full width of the bar, even if the link text is much smaller. So e.g. if there is a table of contents with the two chapters "Some very long text" and "Short", the white space right of "Short" will link to the "Short" chapter as well. It's effectively a link like "Short _____________", where the underscore line is invisible, but anyway linked. While I personally don't see any usecase for this (if I want to open the link, I would click on the link text and not just somewhere around it, would I?), I see a disadavantage of this multiple times every day: When I want to scroll through a long page, I habitually middle-mouse click some white space on the page to enter the browser's fast scroll mode. Works in any browser and almost all websites (the only common exception: ads), just on Wikipedia I now have to be very careful where to do this, and frequently end up in opening a new background tab instead of scrolling. Karotte Zwo (talk) 09:13, 22 February 2023 (UTC)


 * Hello @Karotte Zwo. Thanks for reporting this. What OS and browser are you using? I presume you have seen this on German Wikipedia, am I correct? SGrabarczuk (WMF) (talk) 15:52, 10 March 2023 (UTC)
 * Vector2022 table of contents whitespace links.png
 * Yes, German Wikipedia is right, but I also see the same on e.g. English Wikipedia, on Commons or here. Not OS or browser dependant, seeing it on both Chrome and Firefox, and also both on Windows and Android (though on Android I don't scroll by clicking white space, so not an issue for me there).
 * It mostly affects pages with a table of contents that is long but not exceeding the screen, and where most topics have short names. A good example is de:WP:Auskunft, a village pump where topics are sorted by day. See the screenshot: A good part of the whitespace visible in it is linked with the table of contents. If I middle-click where my cursor is in this, I don't enter free scrolling mode as expected, but open a new tab with the same page again. Karotte Zwo (talk) 15:48, 21 March 2023 (UTC)

Edit source to Tools
Request: Please add "Edit source" to the Tools sidebar. This avoids scrolling. Thanks. Grimes2 (talk) 07:41, 23 February 2023 (UTC)


 * Editing button in the Vector 2022 sticky header.png Hi @Grimes2, what wiki are you trying to edit? On the English Wikipedia, the edit button is available on the sticky header which appears when you scroll down the page, you just have to click on the pencil icon to edit the wikicode. Patafisik (WMF) (talk) 09:52, 23 February 2023 (UTC)
 * Thanks, problem solved! Can be closed. Grimes2 (talk) 10:12, 23 February 2023 (UTC)

Can we have different font sizes? Because: zooming in firefox makes the toc highlighting not fit to the text

 * In the Wikipedia App such option already exists.


 * On the desktop I use firefox as a webbrowser with a zoom of 120% for all Wikimedia projects.
 * When you scroll inside the text (not the toc) between the section of two headlines, it is like that: the toc highlighting switches, when the section of a headline is at the lower border of that new dynamic bar at the top.
 * But when you zoom with firefox, it does not match.
 * Native implemented font size changing would do the trick I guess.


 * Best Regards --KleinerKorrektor (talk) 10:09, 23 February 2023 (UTC)
 * Hi @KleinerKorrektor, thanks for your feedback. OVasileva (WMF)'s answer: "In the near future, we're hoping to explore some of this in the new skin - specifically allowing users to configure their font size for the site". A task for increasing the base font-size for article text from 14px to 16px is open too.
 * I will open a new task on Phabricator about your issue, please can you describe your configuration (OS and screen resolution)? It may be useful. Patafisik (WMF) (talk) 11:06, 27 February 2023 (UTC)


 * Hey Patafisik. Thank you for your reply. My screen resolution is 1920x1200. Webbrowser is firefox-esr 102.8.0esr. I'm on Debian 11 here. Best Regards --KleinerKorrektor (talk) 11:13, 27 February 2023 (UTC)
 * Hi @KleinerKorrektor, are you still experimenting the mismatch between the text title and the table of content title when you zoom? If yes, can you give us an example of page where it is happening? Thank you! Patafisik (WMF) (talk) 08:00, 3 March 2023 (UTC)

Jump to top
Request: Please add "Jump to top" (up arrow) to the top bar, that is displayed by scrolling down. Grimes2 (talk) 11:58, 27 February 2023 (UTC)


 * Hi @Grimes2, what are you calling "top bar", do you mean the sticky header? By clicking "beginning" on the ToC you should scroll back to the top of the page. Did you try with the keyboard shortcut (e.g. CTRL + Home, or Command + up-arrow key, or similar)? I also have keyboard keys Begin and End on my keyboard, but I know not all keyboards have. A lot of browser allow an extension like Scroll to Top too. Patafisik (WMF) (talk) 13:40, 27 February 2023 (UTC)
 * Pos1 (up)/Ende (down) works. Thanks Grimes2 (talk) 13:51, 27 February 2023 (UTC)
 * Glad to have helped. I open a task however with a suggestion for a feature. Patafisik (WMF) (talk) 14:34, 27 February 2023 (UTC)

I can't find a page's table of contents
As the subject says. I managed to spot a table of contents once with the new layout, but now I can't find it any more.

I wanted to share a link to a section, but I can't even do that, because the only links provided directly at section headers are edit links. GunChleoc (talk) 10:54, 7 March 2023 (UTC)


 * Hello @GunChleoc. Thank you for letting us know about this issue. How wide is your screen? I mean the resolution. If it's large enough, you'll see the ToC on the left side (option 1). If it's narrower, it's a button at the upper left corner of the screen (option 2). It may also be in the header if it's pinned (option 3).
 * Is this helpful? SGrabarczuk (WMF) (talk) 18:35, 7 March 2023 (UTC)
 * Is this helpful? SGrabarczuk (WMF) (talk) 18:35, 7 March 2023 (UTC)

Button "Quelltext bearbeiten" wird nach einiger Zeit inaktiv
Ich habe schon mehrfach auf die neue Benutzeroberfläche umgeschaltet, musste aber regelmäßig wieder zur Vorgängerversion zurückkehren, da nach einiger Zeit der Button "Quelltext bearbeiten" (nur dieser!) nicht mehr reagierte. Ist das Problem bekannt und gibt es eine Lösung hierfür?@Der wilde bernd Der wilde bernd (talk) 17:39, 8 March 2023 (UTC)


 * I've not heard anyone else with this complaint. Maybe it is a gadget or user script that is interfering ? —Th e DJ (Not WMF) (talk • contribs) 13:10, 15 March 2023 (UTC)

New prototype. Visual separation between regions
Hi everyone,

We have been analyzing your feedback on the page layout. We have read the comments you have shared here as well as on the RfC on English Wikipedia, Village Pumps, other wiki pages, Phabricator, as well as at meetings. Here are our updates on this work. We wanted to begin a conversation around next steps on further improving the layout.

Feedback about the white space

Currently Vector 2022 uses whitespace to separate the various regions of the interface. It also has a white page background (outside of the content area). There are two areas of concern about this:


 * 1) Comments about adding more visual separation between regions of the interface. You have been wondering if this would improve the reading experience. Mainly by:
 * 2) * Drawing more focus/attention to the content when landing on the page (rather than taking in the interface as a whole first, then focusing on the content)
 * 3) * Making it easier to stay focused on the content while reading, because the content area would be more well defined (some of you have reported getting distracted by the table of contents while reading)
 * 4) Comments about adding a gray background outside of the content area. You have been wondering if this would reduce eye strain some people are experiencing from the large white area (i.e. “glare”) on larger screens.
 * 5) * Many of you have reported that the white space is too high in contrast and that adding a darker hue such as a gray decreases this strain.

Prototype – proposed changes and tradeoffs Based on this as well as feedback on further iterations, we have prepared this prototype. (T259240) This is a proposal for potential changes. The prototype focuses on:


 * 1) Adding a boundary around both the content area and the table of contents (as well as other menus). Our hypothesis is that this boundary can help to further structure and clarify the interface. It would also make it easier to focus on the content (both when the page first loads, and while you are reading). Note that you can pin the Tools menu using the dropdown on the right.
 * 2) Making the page background gray. Our hypothesis is that this should help reduce the eye strain some people are experiencing. It would also add further focus to the content area and the table of contents.

We are leaning towards the configuration which includes the white header background, borders, as well as framed menus.

But this comes with some tradeoffs. This configuration affects the width of the content. Specifically:


 * It reduces the width of the content when compared to the current version in the case where the page tools menu (the right one on the screenshot) is open.
 * It increases the width of the content when the page tools menu is closed, when compared to the current width.

Our designers are working on limiting the effects of this. They are adjusting some of the padding and margins, which will be reflected on the prototype in the coming days.

Testing

As a next step, we would like to propose an experiment or series of experiments which can validate the hypotheses above. We aim at identifying whether updating the layout in this way would improve reader and editor experiences. We have a couple of different options for this. For right now, we are considering the following:


 * 1) Qualitative testing - run user testing through interviews with readers and editors. These would aim at approximating whether the content is easier to focus on, and whether the new background reduces eye strain
 * 2) A/B testing - run an A/B test on logged-in users, which looks at the key metrics of the project, comparing the current layout to the previous layout. Specifically: opt-out rates, pageviews, edits, session length, usage of the table of contents, and scrolling. Due to our technical restrictions and privacy concerns, we are unable to perform A/B tests on logged-out users. This means that we will use the behavior for logged-in users as a proxy for all users. If the new layout is selected, we will compare key metrics (before and after the change) across all users.

Some of you have mentioned building out a survey that asks users about which layout they prefer. Sentiment surveys can be useful, but we don’t think they are the best tool for evaluations of usability. The reason for this is that we don’t think this type of survey will give us the information we need to confirm or reject the two main hypotheses above.

Our questions to you

We’re curious if the list above sounds good for the feature evaluation. If not - do you have any other ideas on evaluation? We are looking for ideas on measuring whether the new layout helps in content separation or eye strain.

Beyond the evaluation mentioned above, the opinions of our communities also play a big part in figuring out what changes are best. What do you all think of the prototype?

We will invite more volunteers and communities to this discussion. We wanted to ping some of you coming from different communities as the first group of interested editors:

Thank you! OVasileva (WMF), SGrabarczuk (WMF) (talk) 01:15, 9 March 2023 (UTC)
 * Hi. I just got the ping. I don't think I'm the right person to answer on this particular question, because I think that the unpinning to two opening lists is a very good decision, and so I do not use at all the pinned sidebars. Especially after yesterday's deployment of my phab task, which unpins the TOC. So sorry, it isn't a question to me. IKhitron (talk) 01:27, 9 March 2023 (UTC)
 * I think my involvement in the Discord meetings and phab makes my position fairly clear :) I'm a big fan of the current "Zebra #9" prototype, with borders and framed menus. It looks like since my last phab comment, the prototype has been updated to remove the border option (Now always on) and the header background option (Off without framed menus, on with.). While not absolutely required, I still prefer the framed menus myself, but with the central page content framed, that's more preference than need. If framed menus were a preference the user could select, that's probably be nice. Ferret (talk) 01:27, 9 March 2023 (UTC)
 * Hi and thanks for this write up. In A/B tests I would definitely want to see how many clicks are there in left an right sidebar in various variants. Some questions come to mind though (don't know the answers):
 * What does it mean to use the table of contents during reading?
 * What does it mean to use the main menu (left sidebar)?
 * What does it mean to use the tools menu (right sidebar)?
 * Are users distracted or do they want to do some task (do they want to read or do they want to e.g. explore linked articles)... I don't think that this can be deduced from A/B tests alone, but if you have measured clicks on various actions in A/B tests, it could be a good material for preparing tests in the form of interviews. And as a helpful side effect - statistics on the use of various actions in the tool and main menu could also help communities decide to maybe remove or move some links/actions. Nux (talk) 02:06, 9 March 2023 (UTC)
 * Hi @Nux - thanks for your feedback! I've added clicks to the tools menus to the measurement plan (will post the updated plan in the next few days). In terms of your wider questions, I agree that it would be difficult to establish what the ToC and menus are used for only from A/B testing.  We're hoping to cover this part through the user testing.  Right now, the plan is to recreate a session by the testers - for example, asking them to read a paragraph, navigate to a different section, and then read another paragraph.  This should hopefully give them enough exposure to both designs to be able to measure the hypotheses of reading focus and reading comfort/eye strain.   OVasileva (WMF) (talk) 15:13, 17 March 2023 (UTC)
 * The new prototype looks great and really easy on the eye, especially the framed menus. However:
 * The TOC makes an impression that it is too tightly packed: its padding is relatively small ( /  ) comparing to  's.
 * This is how the three boxes interact, as I see them:
 * TOC collapsed, toolbox collapsed: Content box center-aligned.
 * If I pin the toolbox when the TOC is collapsed, content box's left border moves to the right while its right border remains unchanged.
 * If I pin the TOC when the toolbox is collapsed, content box's jumps a short distance to the left.
 * TOC pinned, toolbox collapsed: Content box and TOC left -aligned.
 * If I pin the toolbox when the TOC is pinned, content box remains unchanged.
 * TOC collapsed, toolbox pinned: Content box and toolbox center -aligned.
 * If I pin the TOC when the toolbox is pinned, content box jumps a short distance to the right.
 * TOC pinned, toolbox pinned: Justified.
 * That the interface is asymmetric seems weird. Is this expected?
 * NguoiDungKhongDinhDanh (talk) 04:25, 9 March 2023 (UTC)
 * Thank you for this!
 * Is it possible for logged-in users to set their preferred width on a computer-specific basis? Cookies, maybe?
 * Is it possible to do what you did with V2022 and include different screen sizes? The image you have is good but it's what it would look like on a wide
 * What has actually changed? Like, functionally? Is it just the border color?
 * What about the width that was mentioned so much in the RfC?
 * I also have a few suggestions.
 * Test using enwiki-wide banners, fully randomly. To avoid canvassing, and to limit bias. I don't know how technically possible it is to do it for all (most) wikis, but as many as possible.
 * Opt-in A/B testing, again fully random.
 * Define right now a threshold of success for the qualitative testing/AB testing, and make sure users know about it.
 * Define right now what you mean when you say we would like to propose an experiment or series of experiments which can validate the hypotheses above.
 * Thanks for this addition! Cessaune (talk) 04:46, 9 March 2023 (UTC)
 * A couple of remarks:
 * No idea how to check this with the community.
 * The prototype does not have a sticky header anymore. Is this intentional? I would really miss it.
 * As a rather early (mid-2021) adopter of vector-2022, it appears to me that the skin has become much more cluttered and complicated after the enwiki RfC due to all the requests that have been made there. While some requests are clearly legit and some new functionality is indeed great, I find this concerning.
 * I personally prefer the prototype without backgound color—it simply looks dated with background. Particularly the thin 1px border contributes to this impression.
 * What is okay, though, is the current setup here at Mediawiki.org with a gray background left and right to the viewport, but with no gray background visible between ToC/main menu/tools menu/article boxes.
 * —MisterSynergy (talk) 10:46, 9 March 2023 (UTC)
 * Hi @MisterSynergy - sorry for the late reply and thank you for your feedback! Introducing additional clutter is something we're looking out for as well. Just wanted to confirm that the sticky header is only unavailable in the prototype - we don't have any plans on removing it.  OVasileva (WMF) (talk) 20:09, 27 March 2023 (UTC)
 * Looks great! But a small question the prototype doesn't seem to work without JScript(which is sad) or maybe it's me. Also the prototype seems to not find out about my browser language choice and doesn't suggest it at top of language choice list. Greatder (talk) 11:24, 9 March 2023 (UTC)
 * I am sorry but I don't like it. It is only slightly better than the deployed version. The ToC and user's menus should go back to the way they were in V2010, according to the views expressed by many English Wikipedia editors here and here, and by many others in the discussions above: the ToC inside the article under the lede; the user's menus in the left side column. Æo (talk) 12:09, 9 March 2023 (UTC)
 * Thanks for the invitation.
 * For testing, I would suggest to look at experienced editors, new editors and readers that do not (yet) edit as separate groups and try to use samples that represent all internet users and avoid over-representation of US and EU.
 * It would be interesting to see after say 1 or 2 months what have become the options they actually prefer to use. It took me some time to get used to the new layout, but after that it became my preferred skin.
 * The way the sidebars are used, shown and hidden, feels more natural in this new version. To me, this is a substantial improvement. In the present version I often confuse the vertical slidebar of the Tools with the window slidebar.
 * I personally like the gray background, probably because it is more reminiscent of the traditional Wikipedia look. But if readers and new editors clearly don't share my preference, I could easily do without it. Especially as there seems to be a dark mode in the works too.
 * I share the impression and concerns of @MisterSynergy about clutter.
 * Keep up the good work! MarcoSwart (talk) 15:15, 9 March 2023 (UTC)
 * Thanks for the ping and the work. I'm sorry, I think I don't want to be involved in the process anymore. I personally arrived at a stage where I'm waiting for the process to be finally finished, so that we can finally judge what work will follow for the communities. Imho the current state with the contradictions in user interface is a bad idea and no viable starting point for further work. Also I don't like if functionality is lost (like with the new toc). Best of luck with your work. I'm sorry, regards HirnSpuk (talk) 19:37, 9 March 2023 (UTC)
 * I very much support this demo. I think it looks much better than the current skin.
 * The improvements make it useful for me. MathAfrique (talk) 21:37, 9 March 2023 (UTC)
 * For me, gray background outside of the content area allows to focus on the content, provided that frameless menus are used (the "Framed menus" option is disabled):
 * Vector 2022 Zebra9 prototype with frameless menus logged-in.png
 * The frames and white background of the menu cause the eye to run over the resulting gray sections around several windows, which distracts me.
 * In addition, I would like to refer to many voices in the discussion of the new vector and the argument that the old vector works better on wide and high-resolution monitors, because... it spilled text all over the window. On the contrary, the old vector was ok for narrow monitors and small resolutions. With increasing resolutions (for the old vector), the lines of text became longer and longer, which made it extremely difficult to read and made using Wikipedia (as a reader) less and less comfortable. I do not agree with the voices to remove the white areas to gain more width for the content - that would be a return to long lines that make it difficult to read comfortably. Zdzislaw (talk) 10:53, 11 March 2023 (UTC)
 * @SGrabarczuk (WMF) That actually looks quite nice! I look forward to what gets built next :D Aasim 19:28, 12 March 2023 (UTC)
 * Cool! Thanks for the ping, this prototype looks more like a one piece design already. Iniquity (talk) 10:15, 15 March 2023 (UTC)
 * This would be greatly appreciated. While I would personally prefer the frameless variant, either prototype variant helps bring Wikipedia back in line with WCAG supplemental guidance - specifically Make the Site Hierarchy Easy to Understand and Navigate and Use a Clear and Understandable Structure. The table of contents, while still available as a useful navigational aid, is differentiated from the page itself through more than just a bit of whitespace and is rightly no longer treated as if it is equally important to focus on as the page content. While this will not be as easy to read and navigate as the old skin - hierarchy could still use work, mostly with regard to menu structure - it will be a major improvement accessibility-wise (at least for me) compared to currently existing Vector 2022.
 * One suggestion: for any testing, please keep the goals of this change in mind, not just the overall goals for the project. Decreased use of the table of contents compared to current Vector 2022 may well be something you'll have to live with for accessibility; making it less obtrusive and easier to not focus on is rather the point. 24.246.2.244 03:45, 16 March 2023 (UTC)
 * Why does prototype with current look different than current desktop site?
 * At least on my PC it has less "white"(cause it has grey boarders left and right) space than the normal desktop current site.
 * I recognize (too) much white space as highly (aggravating) distracting, so i even like linked current prototype (di-content-separation.web.app) more than actual desktop current, because it is wider.
 * I prefer unframed as i like dark mode more in general but both options are ok. Framed mode shouldn't move any content around so, which the prototype still does.
 * I think (as i have written in another discussion where it got deleted -.-) that the idea of a width limit (especially the current one) to ease reading is fine, but only for text. So taking the moss site as an example, i would suggest using whites pace on the right for things like this overview card and pictures, as well as for things like the tool toolbar. For now pinning the toolbar moves the whole content instead of it just being put into white space (which is wide enough for it).
 * Another option still would be to have the maxed setting as default, which honestly looks the best so far for me, but it obviously makes it a bit harder to read, but doesn't anger me because of too much white space.
 * This is all on a 1920px and a second 1680px width screen in maximized browser mode.
 * Now when i partition it and use half a screen which is pretty nice to use 2 files (like an opened pdf and a text file) the prototype compared to desktop current is more narrow both with current or Zebra #9 settings, which it does not need to be. Hope it will get better with the newer margins.
 * So overall i'm a) confused why current prototype(di-content-separation.web.app) is different than current desktop, b) i like the idea of darker areas (which makes big white spaces more bearable) and i still would prefer a bigger width limit which truly reduce white space and not just visually makes it more bearable. Pinned Tools should also be put into white space if it is big enough and not shrinking the actual content and still leaving white space on the right which now has 0 validity, as the toolbox itself is not longer than current max width.
 * Limited max width makes sense for each single element you need to recognizance but not a combination of multiple elements like a separate toolbar.
 * I still would hope to see a general ("sentiment") survey for all wiki users (majority is probably not logged in or even registered) between designs.
 * In this regard i think it is pretty important to give any kind of participants in studies the option between different (st least 2) designs. Telling someone if Option A or B is "better"(relative comparison?), is a lot more easy to do than rating how good one Option is. YaphitsBrother (talk) 11:03, 17 March 2023 (UTC)

If you ask me, please go ahead both with developing and testing, as laid out above. Regards Aschmidt (talk) 06:32, 9 March 2023 (UTC)


 * +1 Aschmidt. The proposed prototype seems better than the current layout. Jules* (talk) 09:42, 9 March 2023 (UTC)
 * Personally, I like the grey background because it is much easier to tell apart the page content from the rest of the wiki. However, pinning the tools menu reduces the width even more, and this is not a good thing, as the unlogged-in readers do not have the tools menu pinned, and as such, the width seen by the editor would be different than the width seen by the reader. -- NGC 54  ( talk |  contribs ) 11:42, 9 March 2023 (UTC)
 * @NGC 54 the users will most likely be using mobile device 😉 (above 60%) Nux (talk) 01:47, 10 March 2023 (UTC)
 * This is simply not relevant. There are a lot of people who read Wikipedia on desktop, and ensuring a good layout for desktop is important. -- NGC 54  ( talk |  contribs ) 12:53, 10 March 2023 (UTC)
 * @NGC 54 this is relevant and in fact very important. Even on desktop there are many resolutions out there. On a 13 inch laptop/netbook (e.g. in school) your experience will be completely different then on 15 inch laptop (gaming/work laptop) and different on 22.5 inch monitor (as my own). You should always design content so that it can be useful in different resolutions, it might seem hard, but it mostly just works on Wikipedia (unless you use weird templates or too specific html). If you don't know the term RWD, you might want to read about Responsive web design. In fact, in practice, you should never design a page for a specific width. Nux (talk) 19:39, 10 March 2023 (UTC)
 * +1 hgzh 08:48, 28 March 2023 (UTC)

I like the gray background and borders, which of course exists here on the MediaWiki site (I guess I am still using Vector 2010 here) and are very helpful. The fundamental problems of excessive white space and padding are still present (for me) on that Moss demo page, however. My browser window is 1228 pixels wide; on en.WP in Vector 2022, I have managed to remove a lot of the whitespace and end up with 835 pixels of usable width for content with the TOC and Tools menu pinned to the side. On my screen, the demo Moss page has only 635 pixels of horizontal space for content, which feels very constrained. Many display elements like tables and multiple columns that work now will either overflow, scroll, or be single columns in this new layout. Image "sandwiching" will be a significant problem, and there will be editing disputes about modifying pages to accommodate this overly narrow width (editors using larger monitors or skins with reasonable padding will not see a problem and will object to the wikitext changes).

Since the rollout of Vector 2022 to all readers, I have submitted many bug reports about excessive whitespace and padding. A few of them have been fixed, but there is much more work to do.

One other thing: If I pin the TOC and the Tools menu on the demo Moss page, and then shrink the window horizontally, the TOC responsively collapses into a button, but the Tools menu persists, shrinking the content column. I suspect that this is not the desired behavior. Jonesey95 (talk) 14:51, 9 March 2023 (UTC)

I didn't mind the all-white-bg design (loved it!), but if we're gonna have gray sides, better make the menus frameless. Too many misaligned framed boxes look&feel messy. Add sitenotice boxes (weird positioning! anyone thought of that?), infoboxes, image boxes, each of their own widths and the whole page is painful to look at. Also, page elements (boxes) should not jump as toolbars on the left or right are added, especially so when switching between namespaces. Reserve enough margin on the left and right for those menus and have the central (article) panel neatly centered. I loved and supported the new skin from the start, but this has turned into a jumping mess. Still using V2022 as I've not lost all hope, but it's an everyday hide/show/pin NS0/NS>0 struggle (I like to keep the main menu closed for articles, so the TOC is on top of the page, but as a sysop I want the menu, thus shorter text lines in other namespaces and on special pages). And, oh, did I mention ~double line spacing in those menus – why should one need to scroll the page to reach the bottom of a 15-item list? p o nor    (talk) 15:59, 23 March 2023 (UTC)
 * Strong oppose any borders, visual separation, etc (all of the Zebra prototypes). EpicPupper (talk) 23:28, 23 March 2023 (UTC)


 * A definite improvement, thanks and keep it up. Still too much whitespace: between the header and the top of the body; between the outer edge of the menus and the edge of the page (the open/close caret could line up with the burger-menu icon, rather than the latter lining up w/ the edge of the box); the main menu is much too wide; the tools menu could be slightly less wide. Still confusing font/kerning choices: It would be better to keep menu text smaller, and line height proportionally smaller, and to lightly bold the menu section-headings. That saves space, reduces scrollsing, avoids confusion with body text, and helps the eye more easily peruse a long menu. Sj (talk) 21:31, 28 March 2023 (UTC)

Hi everyone, Thank you all so much for your feedback on the prototype and proposed measurement plan. Based on this feedback, we will proceed as follows:


 * 1) User testing: we will set up user testing with readers.  In this testing, participants will be presented with either the current layout or the proposed layout and encouraged to explore an article with both layouts and interact with the different menus.  Afterwards, participants will be asked questions about their experience.  The goals of the test will be:
 * 2) Understand if the visual separation makes it easier for users to focus on content.
 * 3) Understand if the visual separation makes for a more comfortable reading experience.
 * 4) Understand if the visual separation makes it easier for people to navigate the article.
 * 5) Identify any potential improvements that could be made to enhance the reading experience.
 * 6) Gauge user preferences between current Vector 2022 and the new prototype.
 * 7) A/B testing: We also want to ensure that the new layout does not negatively affect any current high-level metrics for the project, which will be determined via an A/B test.  Due to privacy and technical restrictions, we are only able to run this test with logged-in users.    We will be able to filter the results by the number of edits a given user has, and can potentially proxy logged-out users via logged-in users with 0 edits.  We will be looking for no statistically significant decreases in the following:
 * 8) Pageviews
 * 9) Edit rate
 * 10) ToC usage
 * 11) Scrolling
 * 12) Page tools usage
 * 13) Feature review: A few of you have mentioned that there are some layout inconsistencies in the prototype related to spacing and alignment.  We are currently reviewing these and will update with any changes.

Thank you all once again. We’re looking forward to your thoughts on this updated measurement plan. We plan on starting the user testing portion later this week, and the A/B testing portion within a couple of weeks. For those interested in tracking progress in phabricator, most of the work is tracked as subtasks of this ticket. OVasileva (WMF) (talk) 16:48, 29 March 2023 (UTC)

Nowy prototyp. Wizualne oddzielenie części interfejsu
Cześć wszystkim!

Analizowaliśmy opinie edytorów na temat układu strony. Przeczytaliśmy komentarze, którymi wolontariusze podzielili się tutaj, jak również na RfC na angielskiej Wikipedii, w Kawiarenkach, na innych stronach wiki, Phabricatorze, jak również na spotkaniach online. Oto nasze aktualizacje dotyczące tej pracy. Chcieliśmy rozpocząć rozmowę na temat dalszej poprawy układu.

Informacje zwrotne na temat białych pól

Obecnie w Vectorze 2022 jest dużo białych pól służących oddzieleniu różnych części interfejsu. Do tego tło strony (poza obszarem z treścią) jest białe. Podzieliliście się dwojakimi wątpliwościami:


 * 1) uwagami dotyczącymi wyraźniejszego wizualnego oddzielenia części interfejsu. Zastanawialiście się, czy poprawiłoby to czytelność. Głównie dałoby to:
 * 2) * większe skupienie/uwagę na treści strony (zamiast patrzenia na interfejs jako na całość, a następnie skupiania się na treści)
 * 3) * ułatwienie skupienia się na treści podczas czytania, ponieważ obszar treści byłby lepiej zdefiniowany (niektórzy z was zgłaszali, że podczas czytania rozpraszał ich spis treści);
 * 4) uwagami dotyczącymi zmiany koloru tła poza obszarem treści na szary. Zastanawialiście się, czy zmniejszyłoby to zmęczenie oczu, którego niektórzy doświadczają z powodu dużego białego obszaru na większych ekranach.
 * 5) * Wielu z was zgłaszało, że biała przestrzeń ma zbyt wysoki kontrast i że dodanie ciemniejszego odcienia, takiego jak szary, zmniejszy to obciążenie.

Prototyp – proponowane zmiany i wady tych rozwiązań Na podstawie tego, jak również informacji dotyczących kolejnych wersji skórki, przygotowaliśmy ten prototyp. (T259240) Jest to propozycja potencjalnych zmian. Zmiany prezentowane w prototypie to:
 * 1) dodanie ramek zarówno wokół obszaru treści, jak i spisu treści (a także innych menu). Naszą hipotezą jest to, że ramki mogą pomóc w zrozumieniu struktury interfejsu. Ułatwiłyby również skupienie się na treści (zarówno przy pierwszym załadowaniu strony, jak i podczas czytania). Zauważ, że możesz przypiąć menu Narzędzia (Tools) za pomocą rozwijanej listy po prawej stronie,
 * 2) zmiana koloru tła strony na szary. Nasza hipoteza jest taka, że powinno to pomóc zmniejszyć zmęczenie oczu, którego niektórzy doświadczają. Sprawi to też, że obszar treści i spis treści będą bardziej przyciągały uwagę.

Skłaniamy się ku konfiguracji, która zawiera białe tło nagłówka, obramowania, a także obramowane menu.

Jednak wiąże się to z pewnymi wadami. Ta konfiguracja wpływa na szerokość treści. Konkretnie:
 * zmniejsza szerokość treści w porównaniu do obecnej wersji w przypadku, gdy otwarte jest menu narzędzi strony (to po prawej),
 * zwiększa szerokość treści, gdy menu narzędzi strony jest zamknięte, w porównaniu z bieżącą szerokością.

Nasi designerzy pracują nad ograniczeniem skutków tego zjawiska. Dostosowują niektóre odstępy, co w najbliższych dniach znajdzie odzwierciedlenie w prototypie.

Testowanie

Na kolejnym etapie chcielibyśmy zaproponować eksperyment lub serię eksperymentów, które mogą potwierdzić powyższe hipotezy. Naszym celem jest określenie, czy aktualizacja układu w ten sposób poprawi doświadczenia czytelników i edytorów. Mamy kilka różnych możliwości w tym zakresie. Na razie rozważamy następujące:
 * 1) Badania jakościowe – przeprowadzenie testów użytkowników poprzez wywiady z czytelnikami i edytorami. Testy te miałyby na celu określenie, czy łatwiej jest skupić się na treści i czy nowe tło zmniejsza zmęczenie oczu,
 * 2) Testy A/B – przeprowadzenie testu A/B na zalogowanych użytkownikach, gdzie przeanalizowalibyśmy kluczowe wskaźniki projektu, porównując obecny układ z poprzednim. W szczególności: odsetek rezygnacji ze skórki, liczbę odsłon, edycji, długości sesji, wykorzystania spisu treści i przewijania strony. Ze względu na ograniczenia techniczne i ochronę prywatności nie możemy przeprowadzić testów A/B na użytkownikach niezalogowanych. Oznacza to, że będziemy używać zachowania zalogowanych użytkowników jako czegoś podobnego do zachowania wszystkich użytkowników. Jeśli zostanie wybrany nowy układ, porównamy kluczowe wskaźniki (przed i po zmianie) wśród wszystkich użytkowników.

Niektórzy z was wspomnieli o zrobieniu ankiety, w której zapytalibyśmy użytkowników o to, który układ wolą. Badania opinii mogą być przydatne, ale nie sądzimy, żeby były najlepszym narzędziem do oceny użyteczności. Nie uważamy, aby tego typu ankieta dała nam informacje, których potrzebujemy, aby potwierdzić lub odrzucić dwie główne hipotezy zaprezentowane powyżej.

Nasze pytania do was

Jesteśmy ciekawi, czy uważacie, że powyższa lista brzmi sensownie. Jeśli nie – czy macie jakieś inne pomysły na ewaluację? Szukamy pomysłów na zmierzenie, czy nowy układ pomaga w oddzielenia treści od reszty interfejsu i zmniejszeniu zmęczenia oczu.

Poza oceną wspomnianą powyżej, opinie naszych społeczności również odgrywają dużą rolę w ustalaniu, jakie zmiany są najlepsze. Co sądzicie o prototypie?

Dziękujemy! OVasileva (WMF), SGrabarczuk (WMF) (talk) 22:55, 10 March 2023 (UTC)


 * Podoba mi się nowy prototyp, znacznie bardziej niż obecny wygląd Vectora 22. Moim zdaniem strona jest znacznie bardziej czytelna i przejrzysta niż obecnie.
 * Zdecydowanie popieram opcję Framed menus – poza możliwością skupienia się na treści, ułatwione jest z nią także znalezienie odpowiedniego narzędzia (najpierw kierujemy kursor nad wyraźną ramkę, dopiero potem skupiamy się na szczegółach). Całość – moim zdaniem – wygląda bardziej schludnie i elegancko (zarówno przy przypiętym jak i odpiętym prawym polu Narzędzia): Wyraźnie widać odstęp od górnego paska, równy dla wszystkich elementów. Delikatnie ciemniejszy kolor linii wyraźnie rozgranicza treść i narzędzia od tła – choć uważam, że jeszcze większe grono zwolenników zyskałby wariant z tą linią w błękitnym kolorze ze starego Vectora (albo może wokół treści błękit, a przy innych polach – szarość?).
 * Jednym słowem – jest to skórka, którą ustawiłbym jako domyślną (czego nie mogę powiedzieć o obecnym wyglądzie V22).
 * Nie wiem tylko, jak miałoby wyglądać pole edycji (kod!). Zakładam, że byłoby po prostu polem edycji wyświetlonym w miejscu treści artykułu (i takie rozwiązanie wydaje mi się najlepsze).
 * Nie wiem czy celowo zniknęły poziome linie pod tytułami sekcji (?) (u mnie ich w każdym razie nie widać) – uważam, że dobrze wygląda jak są w tamtym miejscu. Tak samo „rozjeżdża mi się” formatowanie obrazków, zakładam że zostałyby w takiej formie jak teraz.
 * Myślę, że w celu zaoszczędzenia miejsca można zmniejszyć nieco szerokość spisu treści (podobnie jak dzieje się na tej stronie po kliknięciu przycisku w prawym dolnym rogu).
 * Zaznaczam, że nie czytałem wszystkich komentarzy w anglojęzycznej wersji dyskusji, więc nie wiem czy nie powielam czyichś opinii.
 * Z mojej strony to chyba wszystko – Pyrlandczyk (talk) 08:20, 11 March 2023 (UTC)
 * Jeśli chodzi o sam wygląd, to szary naokoło oczywiście pomaga w skupieniu i zmniejsza natężenie białego... No i oczywiście wolę taką wersję. Oczywiście, bo takiej wersji z szarym używam od roku jak pewnie wiesz Szymonie :-) w:pl:Wikipedysta:Nux/Fixed top bar.css.
 * Ostatnio zacząłem się zastanawiać nad tym czy narzędzia i spis treści powinny mieć białe tło. W tej chwili mam duży, biały spis treści z boku i w sumie to trochę mi przeszkadza... Powoli dochodzę do wniosku, że może za bardzo odciąga mój wzrok ten biały. Nux (talk) 09:20, 11 March 2023 (UTC)
 * tak, dlatego preferuję nową propozycję z nieaktywną opcją "Framed menus", talk jak to opisałem powyżej w dyskusji en (i zilustrowałem w File:Vector 2022 Zebra9 prototype with frameless menus logged-in.png). Zdzislaw (talk) 10:58, 11 March 2023 (UTC)
 * Podoba mi się, że domyślnie menu są poukrywane (przy małej rozdzielczości, której używam). (Szare) Ramki - spis treści oraz sam artykuł (bez widocznych menu) "ładniej" wygląda z ramkami (ale to może być przyzwyczajenie do starej skórki wektor). Z przypiętym menu Tools brak ramek wokół artykułu (i menu Tools) już tak mocno mnie nie razi. MarMi wiki (talk) 12:35, 11 March 2023 (UTC)
 * Mnie interesuje czy będzie opcja scalenia lewego i prawego menu w jedno. Obecnie w pl.wikt zarówno w lewym jak i w prawym mam często używane opcje (w lewym np. ostatnie zmmiany, w prawym np. wkład użytkownika albo linkujące) więc nie mogę tych menu schować ale jednocześnie ponieważ są po przeciwległych stronach ekranu muszę co chwila wykonywać długie posunięcia kursorem na touchpadzie. Jest to szalenie nieergonomiczne. Poza tym obecna implementacja prawego menu jest (przynajmniej w pl.wikt) kolidująca z układem stron np. tutaj https://i.postimg.cc/GtXxR7Kz/Screenshot-2023-03-05-04-34-05.png albo tutaj https://i.postimg.cc/Wp8BtsfY/Screenshot-2023-03-05-04-43-30.png - wygląda to fatalnie. Proszę o sprawdzenie czy w dyskutowanej tu nowej odsłonie będzie tak nadal. KaMan (talk) 18:46, 14 March 2023 (UTC)
 * @KaMan tak, ten podział zostanie już tak jak jest. Podział na menu główne i menu narzędziowe jest celowy. Z nielicznymi wyjątkami menu po prawej powinno dotyczyć bieżącej strony, a menu głównej ma funkcje dotyczące całej witryny.
 * Co do tych zrzutów, to właściwie jest problem z treścią. Jeden z wielu problemów z szablonami i tabelkami, które są za duże na wąskim ekranie. Jak używasz skórki V'22 na wąskim ekranie, to lepiej mieć schowane przynajmniej jedno z menu (lewe lub prawe menu), albo w ogóle oba. Mi się na laptopie wygodnie pracuje ze zwiniętą lewą stroną (zwijam menu i spis treści).
 * Jeśli ten układ menu nie pasuje do Twojego stylu pracy, to zawsze możesz zmienić skórkę na starego Vectora. Jakby co możesz zrobić to globalnie: Special:GlobalPreferences (to jest dla wszystkich projektów Wikimediów). Nux (talk) 22:45, 14 March 2023 (UTC)
 * @Nux: skórka Timeless automatycznie zwija szerokie tabelki z użyciem JS, tj. nadaje im poziomy scroll . Czy jest szansa, by domyślnie Vector 2022 też miał taką możliwość? Peter Bowman (talk) 23:01, 14 March 2023 (UTC)
 * @Peter Bowman O, ciekawe. Trochę hack, ale wygląda na to, że skuteczne. Myślę, że można by na phabie zgłosić coś takiego. Nie żebym znał wszystkie zgłoszenia, ale nie kojarzę, żeby coś takiego było omawiane. Ten konkretny przypadek KaMana działa całkiem przyzwoicie Timeless: Słownik z szablonem z literkami, Wiktionary (testowałem na Firefox, CTRL+SHIFT+M).
 * W sumie to że oba menu przeskakują na lewo na wąskim ekranie, to też wygląda na dobry pomysł... Myślę, że jest szansa, że po zrobieniu docelowej Zebry #9 będzie łatwiej coś takiego zrobić (o ile będzie zachowany układ z prototypu)... Nux (talk) 23:20, 14 March 2023 (UTC)

Special pages and upload
I was just looking for a link to special pages on another wiki and noticed it was in the page's tools menu. My mind has already shifted to the idea that the right side is for page specific tools and the left (main) menu is for general, site wide links.

There are currently two default links that are in the wrong place (at least in my mind):
 * Upload file.
 * Special pages.

I think these links should go to the main menu. Alternatively, you could also create a new section in the tools menu. But that would break the division into page and general actions.

Or is current placement only weird for me? 😅 Nux (talk) 13:03, 11 March 2023 (UTC)


 * The (un)logical division of menu's is a known problem and on the todo list, but as these menu's are shared between all the skins, splitting them up and making them more logical without breaking other skins is a complex operation that will take some time. There is a ticket about this somewhere.... —Th e DJ (Not WMF) (talk • contribs) 10:36, 14 March 2023 (UTC)
 * Thank you @TheDJ for this clear and concise answer, @Pequod76 was talking about this issue few weeks ago on itwiki. Patafisik (WMF) (talk) 16:01, 14 March 2023 (UTC)

Truncated text in Tools Navigation


I have a problem with a truncated text in the German user interface in connection with this theme. The entry "Edit interlanguage links" in the tools navigation is cut off at the front due to an invisible edit-icon.

I haven't found a similar report on this page. I hope I am in the right place here. --F10sh (talk) 19:46, 13 March 2023 (UTC)


 * Hi @F10sh thank you for reporting this bug. Something similar was happening on other wikis last weeks, I will add your feedback on the task concerning this issue. Patafisik (WMF) (talk) 14:33, 14 March 2023 (UTC)
 * @F10sh This should be fixed on March 16th. Patafisik (WMF) (talk) 12:43, 15 March 2023 (UTC)

Access to right side toolbar
When scrolled down the page with the left side toolbar hidden, it becomes impossible to set to show without going back to the top menu as the tools menu is not in the sticky header. This is annoying and a bit of a time-waster.

Also, the right sidebar is wastefully wide and the scroll bar is inset unnecessarily far from the page edge. Due to vision problems I often zoom in a bit to make the body text more legible while editing and with the side by side preview I cannot afford the wasted space on the right.

I really like the live-ish preview, but it should show what I have last edited, not require me to scroll around in what can be a very large piece of content until I find it or use the page search function. Try editing a references section with about 200 list formatted references to see what I mean. Cheers, Pbsouthwood (talk) 09:38, 14 March 2023 (UTC)
 * Hello @Pbsouthwood. I've taken the liberty to split your comment into three different paragraphs. Would you agree with how I've done that?
 * Regarding the first part, I think the simplest follow-up is – what prevents you from pinning the menu when you're about to use it more often, and unpinning it when you need to have a wide view to enjoy the Real Time Preview? What practical disadvantages does this method have in your case?
 * Regarding the second part, could you share a screenshot with too wide areas marked? This will help us understand what you see. Thank you!
 * SGrabarczuk (WMF) (talk) 17:01, 30 March 2023 (UTC)

Новый прототип. Визуальные различия между интерфейсами
Привет всем,

Мы проанализировали ваши отзывы о макете страницы. Мы ознакомились комментариями, которыми вы поделились здесь, а также на RfC (страница для коментариев) в Английской Википедии, на форуме, на других страницах Вики, в Фабрикаторе, а также на встречаж. Вот обновления по этой работе. Мы хотели начать дискуссию о следующих шагах по дальнейшему улучшению макета.

Отзывы о пустом пространстве

На данный момент «Vector 2022» использует пустые пространства для разделения различных областей интерфейса. Оно также имеет белый фон страницы (за пределами области контента). В связи с этим есть две области, вызывающие вопросы:


 * 1) Комментарии насчет добавления дополнительного визуального различия между интерфейсами» в интерфейсе. Вам было интересно, улучшит ли это процесс чтения. Главным образом за счет:
 * 2) * Привлечение большего внимания/фокуса к контенту при переходе на страницу (вместо того, чтобы сначала рассматривать интерфейс в целом, а затем сфокусироваться на контент)
 * 3) * Чтобы было легче сосредоточиться на контенте во время чтения, поскольку область контента была бы более четко определена (некоторые из вас сообщали, что отвлекались на содержание во время чтения)
 * 4) Комментарии по поводу добавления серого фона за пределами области контента. Вам было интересно, уменьшит ли это нагрузку на глаза, которую испытывают некоторые люди из-за большой пустой области на больших экранах.
 * 5) * Многие из вас сообщали, что пустое пространство слишком контрастно и что добавление более темного оттенка, такого как серый, уменьшает это нагрузку.

Прототип – предлагаемые изменения и компромиссы Основываясь на этом, а также на отзывах о дальнейших итерациях, мы подготовили этот прототип. (T259240) Это предложение о потенциальных изменениях. Прототип основывается на:


 * 1) Добавление границ как вокруг области контента, так и вокруг содержания (а также других меню). Наша гипотеза заключается в том, что эта грань может помочь в дальнейшем структурировании и уточнении интерфейса. Это также облегчило бы фокус на контенте (как при первой загрузке страницы, так и во время чтения). Обратите внимание, что вы можете закрепить меню «Инструменты», используя выпадающий список справа.
 * 2) Сделать задний фон страницы серым. Наша гипотеза заключается в том, что это должно помочь уменьшить напряжение на глаза, которое испытывают некоторые люди. Это также придало бы дополнительный акцент области контента и содержания.

Мы изучаем конфигурации, которая будет включать в себя белый фон заглавления, границы, а также меню в рамке.

Но это сопряжено с некоторыми компромиссами. Эта конфигурация влияет на ширину контента. Конкретно:


 * Это уменьшает ширину контента по сравнению с текущей версией в случае, когда меню инструментов страницы (справа на скриншоте) открыто.
 * Это увеличивает ширину контента при закрытом меню «Инструменты страницы» по сравнению с текущей шириной.

Теститование

В качестве следующего шага мы хотели бы предложить вам эксперимент или серию экспериментов, которые могут подтвердить вышеприведенные наши гипотезы. Мы стремимся определить, улучшит ли обновление макета таким образом впечатления на читателей и редакторов. У нас есть несколько различных вариантов для этого. На данный момент мы рассматриваем следующее:


 * 1) Качественное тестирование — проведите тестирование пользователей с помощью интервью с читателями и редакторами. Это будет направлено на то, чтобы приблизительно определить, легче ли сосредоточиться на контенте и снижает ли новый фон нагрузку на глаза
 * 2) A/B тестирование — запустите A/B тест для вошедших в систему пользователей, который проверяет ключевые показатели проекта, сравнивая текущий макет с предыдущим макетом. В частности: количество отказов, просмотры страниц, правки, продолжительность сеанса, использование содержания и прокрутка. Из-за наших технических ограничений и соображений конфиденциальности мы не можем выполнять A/B тестирование для вышедших из системы пользователей. Это означает, что мы будем использовать поведение для вошедших в систему пользователей в качестве прокси для всех пользователей. Если выбран новый макет, мы сравним ключевые показатели (до и после изменения) у всех пользователей.

Некоторые из вас предложили создание опроса, в котором пользователей спрашивают о том, какой интерфейс они предпочитают. Опросы настроения могут быть полезны, но мы не думаем, что они являются лучшим инструментом для оценки удобства использования. Причина этого в том, что мы не думаем, что этот тип опроса даст нам информацию, необходимую для подтверждения или опровержения двух основных гипотез, приведенных выше.

Наши вопросы для вас

Нам интересно, подходит ли приведенный выше список для оценки функций. Если нет - есть ли у вас какие-либо другие идеи по оценке? Мы ищем идеи по измерению того, помогает ли новый макет различию контента или снижает нагрузку на глаза.

Помимо оценки, упомянутой выше, мнения наших сообществ также играют большую роль в определении того, какие изменения являются наилучшими. Что вы все думаете о новом прототипе?

Мы пригласим больше добровольцев и сообществ к этому обсуждению. Мы хотели бы пригласить некоторых из вас, представляющих разные сообщества, в качестве первой группы заинтересованных редакторов:

Kaganer, MBH, Vladimir Solovjev, Abiyoyo, Deinocheirus, VladimirPF, Putnik, DR, Stjn, Q-bit array, DonRumata, Jack who built the house, Adamant.pwn, Alex Spade, AndyVolykhov, Bezik, Ghuron, Джекалоп, Ле Лой, Сайга.

Спасибо — Mehman (WMF) (talk) 21:36, 16 March 2023 (UTC)
 * @Mehman, пинг не прошёл (не знаю почему). MBH (talk) 22:26, 17 March 2023 (UTC)
 * Спасибо, что сообщил, попробую по-другому – Mehman (WMF) (talk) 07:49, 18 March 2023 (UTC)


 * Не увидел разницы. Пришлось изучить скриншот в гимпе, чтобы обнаружить бледно-серые границы. Вариант с серым заполнением полей был удачнее. Что же до сомнений в "уменьшает ширину" - помилуйте, даже в вашем скриншоте слева и справа от колонок с меню по целой ладони белого поля. Сдвиньте колонки меню к краям экрана, вот и место для текста освободится. Retired electrician (talk) 08:04, 21 March 2023 (UTC)
 * (In English for simplicity) As I’ve said many times before, I would prefer frameless menu because this is a more visually appealing design (no opinion on header because it’s not as distracting/concerning). Thankfully, most of the people who have commented here seem to agree. Not sure if this will make the new Vector team to proceed in the better direction, though, since framed menus were, from our discussions, by the insistence of AHollender. stjn[ru] 23:18, 2 April 2023 (UTC)

Tagline issue
On Romanian language Wikipedia, the tagline („De la Wikipedia, enciclopedia liberă”) is a little misaligned. Compare ro:Zebră with en:Zebra. -- NGC 54  ( talk |  contribs ) 16:05, 17 March 2023 (UTC)


 * Hello @NGC 54. I think we have talked about this before, but can't quite remember the conclusions. Because I know you're skilled technically, I'd like to double-check before I ask the engineers for their attention – are you sure this isn't a local matter that could be solved on the community side? SGrabarczuk (WMF) (talk) 15:54, 30 March 2023 (UTC)
 * I do not know how to solve the issue, so I have opened a local discussion: ro:Wikipedia:Cafenea. -- NGC 54  ( talk |  contribs ) 17:02, 3 April 2023 (UTC)

Can't see annotations
My friends told me to look at commons:Category:Images with annotations but I couldn't see any hint of them with this skin. Jidanni (talk) 22:57, 17 March 2023 (UTC)


 * Hi @Jidanni, thanks for your feedback, I can't reproduce it (for exemple, here annotations appear on hover). Can you give us more detail (browser, OS, screen resolution) please? Patafisik (WMF) (talk) 09:05, 20 March 2023 (UTC)

Timeline - Finnish Wikipedia?
The Finnish WP is mentioned in the timeline for discussions in January, but no discussion has yet been had there. Are there plans on when it might be happening in the Finnish WP? There have been a couple of discussions among users about the new layout, and I'd be interested to know if the "official" discussion is coming (or not coming) any time soon. kyykaarme (talk) 13:06, 19 March 2023 (UTC)


 * Hello @Kyykaarme. Thank you for coming here and asking this! At the moment, we don't have any strict plans. I've subscribed to the discussion Vector 2022 -ulkoasun käyttöönotto?, though, and I'll post a message there! SGrabarczuk (WMF) (talk) 14:48, 21 March 2023 (UTC)

External Link Colors
Could you respond to my proposal for external link colors made in a comment in the Wikipedia RFC thread? If the proposal is doable can we implement it? If not, why not and what solution would you suggest for addressing the lack of distinction between internal and external links that the Vector 2022 link color change has caused? (The reasons for the need for this distinction are explained in another comment.)

My understanding, based on an earlier post in this thread I came across that linked to a blog post that explains the problem, is that the WCAG 2.0 AA requirements are so excessively strict that they leave a very limited amount of colors that can be used. However, while less than ideal, if we insist on meeting the AA standard, the same blog post links to a few other options that we can use. –Noha307 (talk) 18:44, 19 March 2023 (UTC)
 * Hello @Noha307. Thanks for coming to us with this issue. I've asked my team mates to document our decisions. Hopefully it will be clarified. SGrabarczuk (WMF) (talk) 15:51, 30 March 2023 (UTC)
 * Thanks for following up on this. I particularly appreciate the effort to document decisions. The WCAG standards are complicated – both in terms of the multiple levels of compliance (e.g. A, AA, AAA) and the different standards for different types of text (e.g. link text versus body text color and body text versus background color) – so trying to parse them out was confusing. The Link Colors section on the Visual Refinements page does not mention any of the standards by name and only internal link colors are discussed, so it was difficult to determine what the self-imposed requirements were.
 * Also, I realized the wording of my comment and use of multiple pings might have seemed a bit aggressive, so I apologize if it appears that way. –Noha307 (talk) 16:47, 31 March 2023 (UTC)

Nuevo prototipo. Separación visual entre áreas
Hola,

Hemos analizado los mensajes que nos habéis hecho llegar sobre el diseño de la página aquí, así como en el RfC (Request for comments) en la Wikipedia en inglés, los Cafés o Village Pumps, otras páginas wiki, Phabricator, así como en reuniones. A continuación, compartimos nuestras actualizaciones sobre este trabajo. Nos gustaría iniciar una conversación sobre los próximos pasos para seguir mejorando el diseño.

Opiniones sobre el espacio blanco

En la actualidad, Vector 2022 utiliza espacio blanco para separar las diferentes regiones de la interfaz. También tiene un fondo de página blanco (fuera del área de contenido). Hay dos cuestiones acerca de esto:


 * 1) Comentarios sobre añadir más separación visual entre regiones de la interfaz. Se ha preguntado si esto mejoraría la experiencia de lectura. Principalmente por:
 * 2) * Centrar más la atención en el contenido al entrar en la página (en lugar de ver primero la interfaz en su conjunto y luego centrarse en el contenido).
 * 3) * Facilitaría la concentración en el contenido mientras se lee, ya que el área de contenido estaría mejor definida (algunas personas han informado de que se distraen con el índice de contenidos mientras leen).
 * 4) Comentarios sobre añadir un fondo gris fuera del área de contenido. Se ha preguntado si esto reduciría la fatiga visual que algunas personas están experimentando debido a la gran área blanca (es decir, deslumbramiento) en pantallas más grandes.
 * 5) * Muchas personas han informado de que el espacio en blanco tiene un contraste demasiado alto y que añadir un tono más oscuro, como un gris, disminuiría esta tensión.

Prototipo - cambios propuestos y alternativas Basándonos en esto, así como en los comentarios sobre iteraciones posteriores, hemos preparado este prototipo. (T259240) Se trata de una propuesta de posibles cambios. El prototipo se centra en:


 * 1) Añadir un marco alrededor del área de contenido y del índice (así como de otros menús). Nuestra hipótesis es que este marco puede ayudar a estructurar y clarificar la interfaz. También haría más fácil centrarse en el contenido (tanto cuando la página se carga por primera vez, como durante la lectura). Ten en cuenta que puedes fijar el menú Herramientas utilizando el desplegable de la derecha.
 * 2) Hacer que el fondo de la página sea gris. Nuestra hipótesis es que esto debería ayudar a reducir la fatiga visual que algunas personas están experimentando. También añadiría más atención al área de contenido y a la tabla de contenidos.

Nos inclinamos por la configuración que incluye el fondo blanco de la cabecera, los bordes y los menús enmarcados.

Pero esto tiene algunas desventajas. Esta configuración afecta a la anchura del contenido. Específicamente:


 * Reduce el ancho del contenido en comparación con la versión actual en el caso de que el menú de herramientas de página (el de la derecha en la captura de pantalla) esté abierto.
 * "Aumenta el ancho'' del contenido cuando el menú de herramientas de página está cerrado, en comparación con el ancho actual.

Nuestro equipo de diseño está trabajando para limitar sus efectos. Están ajustando parte del relleno y los márgenes, lo que se reflejará en el prototipo en los próximos días.

Testing

Como siguiente paso, nos gustaría proponer un experimento o una serie de experimentos que puedan validar las hipótesis anteriores. Nuestro objetivo es determinar si esta actualización del diseño mejoraría la experiencia de lectura y edición. Tenemos un par de opciones diferentes para ello. Por ahora, estamos considerando las siguientes:


 * 1) Pruebas A/B: realizar una prueba A/B con usuarios registrados que analice las métricas clave del proyecto, comparando el diseño actual con el anterior. En concreto: tasas de abandono, páginas vistas, ediciones, duración de la sesión, uso del índice y desplazamiento. Debido a nuestras restricciones técnicas y a cuestiones de privacidad, no podemos realizar pruebas A/B con personas que hayan cerrado la sesión. Esto significa que utilizaremos el comportamiento de quienes hayan iniciado sesión como aproximación para el resto las personas usuarias. Si se selecciona el nuevo diseño, compararemos las métricas clave (antes y después del cambio) entre todos los usuarios.

Hay quienes han mencionado la elaboración de una encuesta en la que se pregunte a las personas qué diseño prefieren. Las encuestas de sentimiento pueden ser útiles, pero no creemos que sean la mejor herramienta para evaluar la usabilidad. La razón es que no creemos que este tipo de encuesta nos proporcione la información que necesitamos para confirmar o rechazar las dos hipótesis principales anteriores.

Nuestras preguntas para ti

Tenemos curiosidad por saber si lo que hemos enumerado más arriba te parece adecuado para la evaluación de las características. Si no es así, ¿tienes alguna otra idea para la evaluación? Estamos buscando ideas para medir si el nuevo diseño ayuda en la separación de contenidos o la fatiga visual.

Además de la evaluación mencionada, las opiniones de nuestras comunidades también desempeñan un papel importante a la hora de decidir qué cambios son los mejores. ¿Qué os parece el prototipo?

Muchas gracias por vuestra colaboración. Saludos. Zapipedia (WMF) (talk) 00:52, 20 March 2023 (UTC)


 * Gracias por escuchar los comentarios y proponer este nuevo prototipo. Desde mi perspectiva, enmarcar el contenido y añadir un fondo gris mejora bastante los problemas que genera la nueva interfaz. Sin embargo, me parece que el diseño sería más limpio si solo el contenido (columna central) estuviera enmarcado; los menús deberían permanecer con fondo gris, tal como se puede visualizar en el prototipo desmarcando la opción framed menus.
 * De igual manera, me parece que la tabla de contenidos debería permanecer fija en la columna izquierda. Al seleccionar hide, la tabla de contenidos se oculta en una posición poco intuitiva; volverla a su lugar requiere encontrar el botón, y hacer dos clics consecutivos, lo cual me parece un esfuerzo absurdo considerando que ocultarla no aporta ventaja alguna. En caso de mantener la opción de ocultar la tabla de contenidos, por favor consideren reemplazar el enlace [ocultar] (con corchetes) por una flecha u otro ícono.
 * Finalmente, me parece que los menús desplegables estilo pop-up son inconsistentes con la estética minimalista propuesta. Particularmente el menú principal impresiona que está sobrando, porque no queda bien ni como pop-up ni fijo en la barra lateral, desplazando a la tabla de contenidos. Una posible solución sería desplegar los enlaces (Portal de la comunidad, Actualidad, etc.) de forma horizontal entre la cabecera y el contenido al hacer clic en el botón de sándwich, y permitir ocultarlos con el mismo botón. DEGA MD (talk) 04:04, 1 April 2023 (UTC)

Un nuovo prototipo: separazione grafica tra le aree
Ciao,

abbiamo analizzanto il feedback che ci avete dato sul layout della pagina. Abbiamo letto sia i commenti che ci avete lasciato qui che quelli nella Request for Comments (RFC) sulla Wikipedia in inglese, nei bar e nelle pagine di discussione, in altre pagine wiki, su Phabricator, o ancora durante i nostri incontri on line. Ecco il nostro aggiornamento sul lavoro svolto. Ci piacerebbe iniziare una conversazione sui prossimi passi da fare per migliorare ulteriormente il layout.

Feedback relativo allo spazio bianco

Attualmente Vector 2022 usa lo spazio bianco per separare le varie aree dell'interfaccia. Ha anche uno sfondo della pagina bianco (al di fuori dell'area del contenuto). Ci sono due aspetti che destano perplessità:


 * 1) Commenti relativi all'evidenziare maggiormente la separazione grafica tra le aree dell'interfaccia. Vi siete chiesti se questo migliorerebbe l'esperienza di lettura. Principalmente:
 * 2) * Permettendo di focalizzare l'attenzione/dando maggiore risalto al contenuto fin da subito, quando si arriva sulla pagina (anziché focalizzarsi sull'interfaccia nel suo insieme, e poi sul contenuto)
 * 3) * Rendendo più facile concentrarsi sul contenuto mentre si legge, perché l'area del contenuto sarebbe meglio definita (alcuni di voi hanno riportato che l'indice li distraeva durante la lettura)
 * 4) Commenti relativi all'aggiungere uno sfondo grigio al di fuori dell'area del contenuto. Vi siete chiesti se questo ridurrebbe il senso di affaticamento della vista che alcuni utenti sperimentano per via della grande area bianca (tipo “abbagliamento”) su un monitor grande.
 * 5) * Molti di voi hanno riportato che lo spazio bianco è troppo contrastato e che l'aggiunta di una tonalità più scura come il grigio diminuirebbe questo affaticamento.

Prototipo – cambiamenti proposti e compromessi Sulla base di questo e del feedback sulle iterazioni successive, abbiamo preparato questo prototipo. (T259240) Questa è una proposta per dei potenziali cambiamenti. Il prototipo si focalizza su:


 * 1) L'aggiunta di una linea di demarcazione sia intorno all'area del contenuto che intorno al sommario (e agli altri menu). La nostra ipotesi è che questo limite grafico possa aiutare a strutturare e chiarire ulteriormente l'interfaccia. Renderebbe anche più facile concentrarsi sul contenuto (sia quando si carica la pagina che durante la lettura). Tieni conto che puoi fissare il menu degli Strumenti della pagina utilizzando il menu a tendina sulla destra.
 * 2) Rendere grigio lo sfondo della pagina. La nostra ipotesi è che questo possa andare incontro alle esigenze di chi sta provando un affaticamento oculare. Inoltre ci si focalizzerebbe maggiormente sull'area del contenuto e dell'indice.

Noi propendiamo per la configurazione che comprende lo sfondo bianco dell'intestazione, i bordi e i menu incorniciati.

Ma questa scelta richiede di accettare alcuni compromessi. Questa configurazione ha delle ripercussioni sulla larghezza del contenuto. Nello specifico:


 * riduce la larghezza del contenuto rispetto alla versione attuale quando il menu degli Strumenti della pagina (quello a destra nello screenshot) è aperto.
 * aumenta la larghezza del contenuto rispetto alla versione attuale quando il menu degli Strumenti della pagina è chiuso.

I nostri designer sono al lavoro per limitare questi effetti. A livello grafico stanno aggiustando alcuni margini esterni e interni (padding) che saranno visibili sul prototipo nei prossimi giorni.

Test

Come passo successivo ci piacerebbe proporre un esperimento o una serie di esperimenti per convalidare le ipotesi di cui sopra. Il nostro proposito è quello di capire se, aggiornando il layout in questo modo, l'esperienza dei lettori e dei contributori sia migliore. Per questo abbiamo pensato a un paio di opzioni. Per il momento, stiamo prendendo in considerazione quanto segue:


 * 1) Test qualitativi – condurre test di usabilità attraverso interviste con lettori e contributori, per valutare se sia più facile concentrarsi sul contenuto e se il nuovo sfondo riduca l'affaticamento oculare.
 * 2) Test A/B – condurre un test A/B sugli utenti loggati, che analizzi le metriche chiave del progetto, confrontando il layout attuale con quello precedente. Nello specifico: i tassi di abbandono  (opt-out), visualizzazioni della pagina, edit, durata della sessione, uso del sommario, e  scorrimento della pagina. A causa di limitazioni tecniche e problemi di privacy, non siamo nelle condizioni di condurre test A/B sugli utenti non connessi. Questo significa che useremo il comportamento degli utenti registrati come indicatore del comportamento di tutti gli utenti. Se il nuovo layout è selezionato, compareremo le metriche chiave (prima e dopo il cambiamento) per tutti gli utenti.

Alcuni di voi hanno menzionato la preparazione di un sondaggio che chieda agli utenti quale layout preferiscano. I sondaggi sul gradimento (sentiment surveys) possono essere utili, ma non riteniamo che siano lo strumento migliore per valutare l'usabilità. Questo perché non riteniamo che questo tipo di sondaggi possa fornirci le informazioni necessarie per confermare o confutare le due ipotesi principali di cui sopra.

Cosa ti stiamo chiedendo

Siamo curiosi di sapere se l'elenco qui sopra ti sembri adeguato per la valutazione delle caratteristiche.

Se la risposta è no – hai un'altra idea da proporre per la valutazione? Stiamo cercando idee per misurare se il nuovo layout aiuti a separare i contenuti o con l'affaticamento oculare.

Oltre alla valutazione di cui sopra, anche le opinioni delle nostre comunità giocano un ruolo fondamentale nel capire quali cambiamenti siano i migliori. Voi cosa ne pensate del prototipo?

Grazie dell'attenzione! OVasileva (WMF), SGrabarczuk (WMF) --Patafisik (WMF) (talk) 09:31, 20 March 2023 (UTC)


 * Notifico in ordine sparso ho dimenticato sicuramente molti utenti interessati o che sono intervenuti in passato nelle discussioni sull'interfaccia, se pensate che a qualche altro wikicollega possa interessare dire la sua invitatelo alla discussione. Il team sta lavorando anche su altri dettagli di Vector 2022, posso aiutarvi a trovare i task esistenti o aprirne di nuovi se vi interessa. Se avete delle domande sono a disposizione. Buona giornata, Patafisik (WMF) (talk) 12:29, 21 March 2023 (UTC)
 * Invito anche a testare il nuovo prototipo e a dare un feedback anche sulla modalità dei test qualitativi e quantitativi. Grazie! Patafisik (WMF) (talk) 11:28, 23 March 2023 (UTC)

Le nouveau prototype : séparation des régions du gabarit
Bonjour à toutes et à tous,

Nous avons analysé vos remarques sur la mise en page. Nous avons lu les commentaires que vous avez partagés ici, ou dans la Requests For Comments (RFC) sur la Wikipédia en anglais, aux Bistros et sur d'autres pages wiki, sur Phabricator ou encore pendant les rencontres en ligne. Ci-dessous notre mise à jour par rapport à ce travail. Nous aimerons entamer une conversation autour des prochaines étapes de l'amélioration de la mise en page.

Retour sur l'espace blanc

Actuellement, Vector 2022 utilise l'espace blanc pour separer les différents éléments du gabarit de l'interface. Le fond de la page de l'habillage s'affiche en blanc (en dehors de la région du contenu). Deux sujets de préoccupation ont émergé par rapport à ceci :


 * 1) Certains commentaires concernaient l'ajout d'une majeure séparation visuelle entre les régions de l'interface. Vous vous êtes demandé si cela améliorerait l'expérience de lecture. Surtout :
 * 2) * en attirant davantage l'attention sur le contenu dès l'arrivée sur la page (plutôt que de considérer l'interface dans son ensemble, pour se concentrer sur le contenu ensuite).
 * 3) * en facilitant la concentration sur le contenu pendant la lecture, puisque la région du contenu serait mieux définie (certains d'entre vous ont signalé que le sommaire les distrayait durant la lecture)
 * 4) D'autres commentaires concernaient l'ajout d'un fond de couleur grise en dehors de la zone de contenu. Vous vous êtes demandé si cela pourrait réduire la fatigue oculaire que certaines personnes ressentent à cause de la grande surface blanche (une sorte d ' éblouissement) sur les écrans de grande taille.
 * 5) * Beaucoup d'entre vous ont signalé que l'espace blanc était trop contrasté, et que l'utilisation d'une teinte plus foncée, comme le gris, diminuait cette tension.

Prototype – changements et solutions de compromis proposés À partir de ces éléments et des commentaires sur les itérations successives, nous avons préparé ce prototype. (T259240) Il s'agit d'une proposition de changements potentiels. Le prototype se focalise sur :


 * 1) L'ajout d'une ligne de démarcation autour de la zone du contenu et du sommaire (ainsi que d'autres menus). Notre hypothèse est que ce contour permettrait de structurer et de clarifier davantage l'interface. Il permettrait également de se concentrer davantage sur le contenu (à la fois lors du chargement initial de la page et pendant la lecture). Notez que vous pouvez épingler le menu Outils à l'aide du menu déroulant sur la droite.
 * 2) Le fond de la page en couleur grise. Notre hypothèse est que cela devrait contribuer à réduire la fatigue oculaire dont souffrent certaines personnes. Cela permettrait également de mettre davantage en évidence la zone de contenu et le sommaire.

Dans ce contexte, nous penchons pour la proposition avec le fond blanc de l'en-tête, les contours et les menus encadrés. Mais cela implique quelques compromis. Cette configuration affecte la largeur du contenu. Notamment :


 * Cela réduit la largeur du contenu par rapport à la version actuelle quand le menu des Outils de la page (celui de droite dans la capture d'écrans) est ouvert.
 * Cela augmente la largeur du contenu par rapport à la largeur actuelle quand le menu est fermé.

Nos designers sont au travail pour limiter ces effets. Ils sont en train d'ajuster certains éléments graphiques tels que les marges intérieures (« padding ») et extérieurs qui seront affichés sur le prototype dans les prochains jours.

Phase de test

Comme étape suivante, nous aimerions proposer une expérience ou une série d'expériences permettant de valider les hypothèses ci-dessus. Nous cherchons à déterminer si une telle mise en page améliorerait l'expérience des lecteurs et des éditeurs. Pour ce faire, nous disposons de plusieurs options. Actuellement, nous envisageons les options suivantes :


 * 1) Tests qualitatifs - effectuer des tests utilisateurs en réalisant des interviews de lecteurs et de rédacteurs. Ces tests viseraient à déterminer si le contenu est plus facile à focaliser et si le nouvel arrière-plan réduit la fatigue oculaire.
 * 2) Tests A/B - effectuer des tests A/B avec les utilisateurs connectés, examiner les indicateurs clés du projet en comparant la mise en page actuelle avec la précédente. Plus précisément : taux de retrait (opt-out rate), pages vues, modifications, durée de la session, utilisation du sommaire et défilement de la page. En raison de nos restrictions techniques et de nos contraintes en matière de protection de la vie privée, nous ne sommes pas en mesure d'effectuer des tests A/B sur les utilisateurs déconnectés. Cela signifie que nous utiliserons le comportement des utilisateurs connectés comme indicateur pour tous les utilisateurs. Si la nouvelle mise en page est choisie, nous comparerons les indicateurs clés (avant et après le changement) pour tous les utilisateurs.

Certains d'entre vous ont mentionné l'élaboration d'une enquête demandant aux utilisateurs quelle mise en page ils préfèrent. Les enquêtes de satisfaction (sentiment surveys) peuvent être utiles, mais nous ne pensons pas qu'elles soient le meilleur outil pour évaluer l'utilisabilité. En effet, nous ne pensons pas que ce type d'enquête nous fournirait les informations dont nous avons besoin pour confirmer ou rejeter les deux principales hypothèses ci-dessus.

Ce que nous vous demandons

Nous sommes curieux de savoir si la liste ci-dessus vous convient pour l'évaluation des caractéristiques. Si ce n'est pas le cas, avez-vous d'autres idées pour l'évaluation ? Nous cherchons des idées pour mesurer la fatigue oculaire ou si la nouvelle mise en page permet de mieux séparer les contenus.

En plus de l'évaluation mentionnée ci-dessus, les opinions de nos communautés jouent également un rôle important dans la détermination des meilleurs changements à apporter. Que pensez-vous du prototype ?

Merci! OVasileva (WMF), SGrabarczuk (WMF) -- Patafisik (WMF) (talk) 10:29, 20 March 2023 (UTC)


 * Bonjour,
 * Personnellement, j'apprécie beaucoup la séparation des régions et le fond contrasté : on n'a plus ce sentiment de "fourre-tout" où l'on ne distingue pas bien ce qui concerne l'article et ce qui est plus général.
 * Merci pour ces changements ! Daehan (talk) 10:59, 21 March 2023 (UTC)
 * +1. Jules* (talk) 11:13, 21 March 2023 (UTC)
 * +1. Reptilien.19831209BE1 (talk) 16:00, 21 March 2023 (UTC)
 * +1 Pas mal du tout ! Thomas³ (talk) 04:37, 22 March 2023 (UTC)
 * +1 Cela met effectivement en lumière les limites des différentes zones de la page et est appréciable. Epok (talk) 06:38, 22 March 2023 (UTC)
 * @Patafisik (WMF) Pas mal en effet, mais pourquoi n'y a-t-il plus d'entête fixe ? Est-ce uniquement dû au prototype ? Ayack (talk) 11:04, 22 March 2023 (UTC)
 * @Ayack tout à fait, l'entête fixe est voué à être présent dans l'habillage. Patafisik (WMF) (talk) 16:00, 22 March 2023 (UTC) P.S. Sur le même prototype, on peut se connecter et il apparaît. Pour plus d'information voir la page dédiée.--Patafisik (WMF) (talk) 08:40, 23 March 2023 (UTC)

Reference columns
Forgive me if this has been discussed. I did look!

I just noticed that the new skin seems to force references set to be in two columns into one. See the references at the foot of en:Don Bradman. Is this deliberate? If so, I can't understand why it's considered a good idea. --Dweller (talk) 15:03, 22 March 2023 (UTC)


 * Hello @Dweller. Thanks for coming here with your question. I think what you're referring to is a consequence of Vector 2022 having different width settings than legacy Vector. With V22, by pinning or unpining side menus, you may choose between one, two, and three columns, and the content area is only one of them. If the width of your screen is below a certain threshold, the content area gets narrower because the columns on both sides don't. So even though above some threshold, there are two columns of references, below it, there may be one. Is this helpful? SGrabarczuk (WMF) (talk) 14:08, 23 March 2023 (UTC)

Nguyên mẫu mới. Việc tách biệt trực quan giữa các khu vực
Xin chào,

Chúng tôi đã phân tích những phản hồi của các bạn về bố cục trang. Chúng tôi đã đọc các bình luận mà các bạn đã chia sẻ ở đây cũng như trên RfC trên Wikipedia tiếng Anh, các trang Thảo luận chung, các trang wiki khác, Phabricator, cũng như tại các cuộc họp. Dưới đây là những cập nhật của chúng tôi về việc này. Chúng tôi muốn bắt đầu một cuộc trò chuyện xoay quanh các bước tiếp theo để cải thiện bố cục giao diện hơn nữa.

Phản hồi về những khoảng trắng

Hiện tại Vector 2022 sử dụng khoảng trắng để ngăn cách các vùng khác nhau của giao diện. Nó cũng có nền trang màu trắng (bên ngoài khu vực nội dung). Có hai mối lo ngại chính về điều này:


 * 1) Các nhận xét về việc bổ sung thêm một phương thức giúp tách biệt trực quan giữa các khu vực của giao diện. Bạn đang tự hỏi liệu điều này có cải thiện trải nghiệm đọc hay không. Chủ yếu bằng cách:
 * 2) * Thu hút sự tập trung/chú ý nhiều hơn vào nội dung khi truy cập vào trang (thay vì toàn bộ giao diện đập vào mắt trước, sau đó mới tập trung vào nội dung)
 * 3) * Giúp bạn dễ dàng tập trung vào nội dung trong khi đọc hơn vì khu vực nội dung sẽ được xác định rõ hơn (một số người dùng cho rằng họ bị phân tâm bởi phần mục lục trong khi đang đọc)
 * 4) Các nhận xét về việc nên thêm phần nền màu xám bên ngoài khu vực nội dung. Bạn đang tự hỏi liệu điều này có giúp 'giảm hiện tượng mỏi mắt mà một số người đang gặp phải do có quá nhiều vùng trắng (khiến "bị chói lóa") trên màn hình lớn hơn hay không.
 * 5) * Nhiều người dùng cho rằng khoảng trắng có độ tương phản quá cao và việc thêm màu tối hơn chẳng hạn như màu xám sẽ làm giảm việc khiến mắt căng thẳng.

Nguyên mẫu – đề xuất những thay đổi và sự đánh đổi Dựa trên những điều trên cũng như những phản hồi về các bản thử, chúng tôi đã chuẩn bị nguyên mẫu này. (T259240) Đây là một đề xuất cho những thay đổi có thể xảy ra. Nguyên mẫu tập trung vào việc:


 * 1) Thêm một ranh giới xung quanh cả khu vực nội dung và mục lục (cũng như các menu khác). Giả thuyết của chúng tôi là ranh giới này có thể giúp cấu trúc thêm và làm rõ giao diện hơn. Nó cũng giúp bạn tập trung vào nội dung dễ dàng hơn (cả khi tải trang lần đầu và khi bạn đang đọc). Lưu ý rằng bạn có thể ghim menu Công cụ bằng menu thả xuống ở bên phải.
 * 2) Làm cho nền trang có màu xám. Giả thuyết của chúng tôi là điều này sẽ giúp giảm chứng mỏi mắt mà một số người đang gặp phải. Nó cũng sẽ giúp người đọc tập trung hơn nữa vào khu vực nội dung và mục lục.

Chúng tôi đang nghiêng về cấu hình bao gồm nền tiêu đề màu trắng, đường viền cũng như các menu được đóng khung.

Nhưng điều này đi kèm với một số sự đánh đổi. Cấu hình này ảnh hưởng đến chiều rộng của nội dung. Đặc biệt:


 * Nó làm giảm chiều rộng của nội dung khi so sánh với phiên bản hiện tại trong trường hợp menu công cụ trang (cái bên phải trên ảnh chụp màn hình) đang mở.
 * Nó làm tăng chiều rộng của nội dung khi menu công cụ trang đang đóng, khi so sánh với chiều rộng hiện tại.

Các nhà thiết kế của chúng tôi đang tìm cách để hạn chế tác động của việc này. Họ đang điều chỉnh một số phần đệm và lề, điều này sẽ được phản ánh trên nguyên mẫu trong những ngày tới.

Thử nghiệm

Bước tiếp theo, chúng tôi muốn đề xuất một thí nghiệm hoặc một loạt thí nghiệm có thể xác nhận các giả thuyết trên. Mục tiêu của chúng tôi là xác định xem việc cập nhật bố cục theo cách này có cải thiện trải nghiệm của người đọc và biên tập viên hay không. Chúng tôi có một vài lựa chọn khác nhau cho việc này. Hiện tại, chúng tôi đang xem xét những điều sau:


 * 1) Thử nghiệm định tính - chạy thử nghiệm người dùng thông qua việc phỏng vấn người đọc và biên tập viên. Những điều này sẽ nhằm mục đích ước tính xem có dễ tập trung vào nội dung hơn không và liệu nền mới có làm giảm việc mỏi mắt hay không.
 * 2) Thử nghiệm A/B - chạy 'thử nghiệm A/B trên người dùng đã đăng nhập, xem xét các chỉ số chính của dự án, so sánh bố cục hiện tại với bố cục trước đó. Cụ thể: tỷ lệ chuyển sang dùng giao diện khác, số lần xem trang, chỉnh sửa, thời lượng phiên, việc sử dụng mục lục và thao tác cuộn. Do các hạn chế kỹ thuật và lo ngại về quyền riêng tư, chúng tôi không thể thực hiện thử nghiệm A/B đối với người dùng đã đăng xuất. Điều này có nghĩa là chúng tôi sẽ sử dụng hành vi của người dùng đã đăng nhập làm đại diện cho tất cả người dùng. Nếu bố cục mới được chọn, chúng tôi sẽ so sánh các chỉ số chính (trước và sau khi thay đổi) trên tất cả người dùng.

Một số người đã đề cập đến việc xây dựng một cuộc khảo sát hỏi người dùng xem họ thích bố cục nào hơn. Khảo sát cảm tính có thể hữu ích, nhưng chúng tôi không nghĩ rằng chúng là công cụ tốt nhất để đánh giá khả năng sử dụng. Lý do là vì chúng tôi không nghĩ rằng loại khảo sát này sẽ cung cấp cho chúng tôi thông tin cần thiết để xác nhận hoặc bác bỏ hai giả thuyết chính ở trên.

Câu hỏi của chúng tôi tới bạn

Chúng tôi muốn biết liệu danh sách trên có phù hợp để đánh giá tính năng hay không. Nếu không - bạn có bất kỳ ý tưởng nào khác về việc đánh giá không? Chúng tôi đang tìm kiếm các ý tưởng để đo lường xem liệu bố cục mới có giúp phân tách nội dung hay chứng mỏi mắt hay không.

Ngoài sự đánh giá được đề cập ở trên, ý kiến của cộng đồng cũng đóng một vai trò quan trọng trong việc tìm ra những thay đổi nào là tốt nhất. Các bạn nghĩ sao về nguyên mẫu?

Xin phép tag một số bạn, , , , ,. Nhờ các bạn tag thêm ai khác có quan tâm về giao diện. Ý kiến của bạn sẽ giúp đóng góp thêm cho giao diện của toàn wiki.

Cảm ơn rất nhiều! Bluetpp (talk) 15:33, 22 March 2023 (UTC)

Special pages link
Hi. If the menu split should put current page related links in the Tools menu, and all pages related links in the Main menu, why the Special pages link is in the Tools menu? IKhitron (talk) 21:03, 22 March 2023 (UTC)


 * Tracked as T333211. Jdlrobson (talk) 01:06, 28 March 2023 (UTC)

Magic word, built-in, or testable property needed
Some situations are arising that could be solved, or mitigated, through the provision of a magic word, built-in, or a property testable by parser function or otherwise. Something like " " would be nice. An example where this may be occurring is this discussion, concerning the en-wiki template Template:Compact TOC's use of which has consensus (developed while Vector 2010 was the default), but with the advent of Vector 2022 results in the suppression of the ToC from the left sidebar, which is an undesirable result according to one user. (Note: regardless whether it is determined that this example is or isn't something directly related to changes in ToC handling by Vector 2022, I'm sure there will be other examples where a testable property would be helpful.) Mathglot (talk) 06:55, 25 March 2023 (UTC) updated by Mathglot (talk) 20:57, 26 March 2023 (UTC)

I think navigating would be better if TOC and tools positions were swapped
This way, the position would be similar to the old version, and it's the one most people commonly associate with Wikipedia. It also allows to better research the way the encyclopedia works and find new topics, both necessary steps to understand how the project works, how most thing people find on the page are human-made or human-conducted, and it's in general more trasparent on how Wikipedia works and what guarantes and accuracy it can give 37.103.218.189 19:57, 26 March 2023 (UTC)

Sommaire replié par défaut
Bonjour, y a-t-il un moyen d'avoir le sommaire replié par défaut ? Reptilien.19831209BE1 (talk) 05:38, 30 March 2023 (UTC)


 * Bonjour @Reptilien.19831209BE1, je voudrais être sûre de bien comprendre votre commentaire. Aimerez-vous le sommaire masqué sous l'icône [[file:OOjs UI icon listBullet-ltr.svg|link=]] par défault ? ou au contraire le sommaire présent sur la gauche mais avec toutes les sections cachées ? ou les sections présentes, mais avec les sous-sections fermées par défault ? Pouvez-vous m'en dire plus, sur votre motivation aussi ? Dans le premier cas, je vous informe que vous pouvez réplier le sommaire une seule fois et le masquage sera persistant d'une page à l'autre durant la navigation. Cordialement, Patafisik (WMF) (talk) 10:19, 31 March 2023 (UTC)
 * Une image valant mieux qu'un long discours, voyez celle-ci. Il y a deux pages : à gauche fr:w:Bruce Willis, à droite fr:w:Bruxelles. Pour je ne sais quelle raison, à l'ouverture de ces pages, le sommaire (de l'article) à gauche est ouvert alors que celui de droite est fermé. Je souhaiterais que le sommaire soit toujours replié (comme à droite), peu importe si j'ai déjà visité la page. Comment puis-je faire ? Reptilien.19831209BE1 (talk) 12:50, 1 April 2023 (UTC)
 * @Reptilien.19831209BE1 Merci pour les détails. Je viens d'ouvrir une tâche sur Phabricator, vous pouvez la suivre à ce lien. Au cas où cette solution ne sera pas retenue pour tout le monde, veuillez me notifier à nouveau, nous chercherons une solution individuelle et personnalisée (voir cette section des FAQ). Cordialement, Patafisik (WMF) (talk) 09:12, 3 April 2023 (UTC)
 * Merci @Patafisik (WMF) d'avoir ouvert cette tâche sur Phabricator. Vous avez écrit dans celle-ci « user would like to see sections always closed ». C'est vrai que c'est personnellement ce que je souhaiterais, mais peut-être que d'autres préféreraient que le sommaire soit toujours déplié. À mon avis, c'est quelque chose qui devrait être paramétrable (dans ses paramètres personnels). Je précise ici mais c'est peut-être une information qu'il faudrait faire remonter sur Phabricator, non ? Reptilien.19831209BE1 (talk) 09:32, 3 April 2023 (UTC)
 * @Reptilien.19831209BE1 Modifié. N'hésitez pas à écrire vous même sur Phabricator si vous le souhaitez. L'équipe Web est en train d'explorer comment rendre possible le paramétrage du sommaire, voir T317818. Patafisik (WMF) (talk) 12:47, 3 April 2023 (UTC)

Text selection scrolls rapidly upward
When I select some text that is at the top of the screen the page rapidly scrolls upwards, making me lose control of navigation and I end up selecting a bunch of text. So selecting any text if it is at the top of the screen is damn near impossible, I have to scroll the text toward the middle and then make my selection. I absolutely hate websites that mess with anything to do with scrolling, it makes me dizzy.

On another note I quite like the new design, good job. The toggle limited content width button seems useless though. Hrs70 (talk) 22:22, 31 March 2023 (UTC)


 * Hello @Hrs70. Thanks for coming here. Are you experiencing this on desktop/laptop? By the text that is at the top of the screen you mean page content only, not the interface, right? SGrabarczuk (WMF) (talk) 23:23, 31 March 2023 (UTC)
 * Yeah I just mean the text in some article. Say I have scrolled to the middle of some article, then selecting the text at either of the first 4 lines of text causes the page to scroll rapidly.
 * I went through a bit of debugging and it seems this event listener is being called which causes the scrolling,
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109
 * although  returns immediately the scrolling happens sometime after, seems to be in , but not sure, I don't really have the time to debug this now. EDIT: Forgot to mention, I am running on a desktop PC with linux and Firefox v.109

Hrs70 (talk) 01:08, 1 April 2023 (UTC)