Talk:Reading/Web/Desktop Improvements

Overview

Features

Repository

FAQ

Discussions: Desktop Improvements • Accessibility for reading.

---

You can comment in any language. We are especially interested in:

• Feedback on the functionalities we have already deployed. (Please see Reading/Web/Accessibility for reading/Known issues before reporting bugs.)

• Expanding the list of existing gadgets and user scripts that are related to providing a better desktop experience.

We are discussing with many volunteers and communities at the same time. It may take some time for us to reply here. We apologize for that.

Thank you!

(Translate this page)

The new layout looks horrible

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)

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'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)

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)

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)

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)

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)

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)

More TOC concerns

On pages with long headings (f.i. en:Wikipedia:Closure_requests), the new TOC is highly impractical. The headings are difficult to parse, sometimes cutting words in two. A lot of scrolling is also required to get an overview of what discussions to close. Will it be possible to go back to the old TOC on a per-page base? I can imagine a lot of non-article pages will have similar problems (including this one).

Less importantly, I noticed that the default is having only the top heading displayed. In some pages / articles there are very few top-level headings, and this would always require the reader to uncollapse. Can this be made more dynamic? Femke (talk) 18:09, 14 July 2022 (UTC)

Would it be possible (probably only on bigger screens) to use the empty white space on the right for tools (for logged-in editors), so that the TOC is less cramped? Solves two problems in one. Femke (talk) 17:00, 18 July 2022 (UTC)

Thank you for your question! That is actually one of the next steps we hope to take for the new skin. More details are available on the page tools feature page. In terms of the ToC, we actually estimate the length of the ToC and decide whether to open or close the subsections based on that. For pages with shorter ToC's, all subsections should be open by default. OVasileva (WMF) (talk) 11:51, 23 August 2022 (UTC)

I liked Wikipedia when you didn't need to create an account to read it. Now either you create an account or you can't read it properly.

This change is BS and I don't care how cool your JS framework is, nobody likes this and you shouldn't force your frontend bootcamp brands on us. Microph123 (talk) 12:48, 22 January 2023 (UTC)

@Femke thanks for your comments. We worked with the Editing team to determine whether or not to use the updated, sidebar table of contents on talk pages. You can see that discussion here: https://phabricator.wikimedia.org/T294784. While there are some drawbacks, particularly long section titles wrapping (as you mentioned), there is also a large benefit of consistency between article pages and talk pages. Do you think that truncating the section titles in the table of contents, and making the full title available via a tooltip on hover would help with this situation at all?

Truncated section titles in table of contents, with tooltip on hover (Vector 2022)

cc @PPelberg (WMF) @NAyoub (WMF) (from the Editing team) who might have some other thoughts or ideas to add. AHollender (WMF) (talk) 17:55, 29 August 2022 (UTC)

I really like the page tools on the right. Invisible for readers (who can be converted to editors by the simple edit button), and by default visible to editors that want it. This also means I can collapse the other links on the left by default (assuming that script writers move their script links).

The current TOC I see on this page seems to have a smaller font size than previously, and (4 comments) in grey below. It's an improvement, but I still miss the overview of the numbers.

The initial link I mistyped (en:WP:Closure requests) at the moment only has the top-level heading (so it only shows requests for closure, so that seems to be a bug? Or can you only toggle between top-level / all level uncollapsed? On that same page, the end of the heading is often the most interesting, so I'm not sure that having truncated section titles will help much. You'd want a quick overview (similar to en:WP:ANI), to see what discussions you'd like to engage in. Femke (talk) 17:44, 31 August 2022 (UTC)

@OVasileva (WMF), @AHollender (WMF), @Femke: I've had a similar bad impression as Femke and other users about the new TOC. The new TOC is a mess. Please restore the old TOC and make the new TOC appear as a pop-up menu when the full TOC is off-screen. The full TOC should also be collapsed and numbered by default, as before. This would be a solution to all problems, and would also be aesthetically elegant, indeed. 37.160.249.144 10:29, 6 September 2022 (UTC)

@Femke thanks for these notes.

• Regarding: "but I still miss the overview of the numbers" — can you expand on this thought? And to clarify, are you thinking just about Talk pages here, or Article pages as well?
• Regarding the TOC on en:WP:Closure requests: the TOC is currently setup to automatically expand all sections if there are less than 20 sections & sub-sections within the page (e.g. en:Plant Stem). If there are more than 20 the top level sections get collapsed in the TOC, to allow for easier scanning of the TOC (e.g. en:Paris). In the case of en:WP:Closure requests there are more than 20 sections & sub-sections, and unfortunately they are all nested within one section. This is the least optimal page structure in terms of working well with the new TOC. Do you think it's reasonable to expect editors to eventually restructure certain pages to avoid this kind of situation where everything is nested within one (collapsed) section in the TOC?

AHollender (WMF) (talk) 15:43, 7 September 2022 (UTC)

Thanks for your response :)

I miss the numbering in the TOC most in pages that are long by necessity, to get an easy overview of how long the backlog is. So that's behind the scenes pages (en:WP:ANI, AN, CR, ..). I think I can get used to it in other places.

For the article talk pages, the TOC without numbers will probably work okay if there are less than ~12 discussions. (that is, if the plan is to break up the en:WP:sea of blue with n comments there too). And most article talk pages do not need to have more sections that that, so I hope there will be an increased tendency to set up archiving.

Would it be possible to collapse up to a lower level if there are say >20 overall and <4 top level? So for closure requests to have the 4 subsections show up, but not the subsubsections? Or, to set this per page, in a similar way as en:template:TOC limit? Restructuring CR in particular isn't trivial given that the archiving bot will have to be rewritten, and I have no idea how easy that is. Femke (talk) 17:13, 7 September 2022 (UTC)

Another example is en:WP:FAC, where the default top-level doesn't really make sense (four headings), and you'd want to show the first two levels of headings by default. The third level headings aren't too relevant either. The current TOC only gives you the option of too much or too little information. Femke (talk) 14:07, 11 September 2022 (UTC)

Hey @Femke, ok so on a high level I'm understanding your request as something like: certain administrative Wiki pages (e.g. ANI, Closure requests, FAC, etc.) would benefit from more fine tuned configuration regarding which level of sections in the table of contents are expanded/collapsed by default. While it is possible to restructure the pages themselves (rather than reconfigure the table of contents), it is unclear how easy it would be to do this because the archiving bots would need to be updated. Let me know if that sounds right to you.

My next step is to bring this up with @OVasileva (WMF) at our next meeting. I think it might also make sense to include @Jdlrobson in this discussion, as he might have more information regarding the effort involved to restructure those pages and update the archive bots. AHollender (WMF) (talk) 13:52, 14 September 2022 (UTC)

Mostly yes.

All of these pages are archived in slightly different ways, and I believe restructuring wouldn't interfere with archiving outside of closure requests. The other pages have less scope for restructuring I believe. For en:WP:FAC, the solution could lie in making the TOC responsive again to the en:template:TOC limit, which does not seem to affect the new skin. Femke (talk) 18:16, 14 September 2022 (UTC)

If we were going for the most simple solution here: do you think offering an optional table of contents configuration where all sections and subsections are expanded by default would at least improve the situation for these pages somewhat? AHollender (WMF) (talk) 18:59, 14 September 2022 (UTC)

That would resolve my less important issue, yes.

Is is technically too difficult to unbreak the TOC limit template? Femke (talk) 19:06, 14 September 2022 (UTC)

@Femke that's a good question, I'm not sure what the answer is though. I met with @OVasileva (WMF) and she thinks we should be able to find a solution. I've just opened this phabricator task: https://phabricator.wikimedia.org/T317818. Let's move the discussion over there. AHollender (WMF) (talk) 21:52, 14 September 2022 (UTC)

• TOC depth does not show enough, therby confusing say level 3=== and 4====. Made me loose TOC overview. (this for the record, will look for similar posts). -DePiep (talk) 15:00, 1 December 2022 (UTC)

  Hey @DePiep I think I understand what you mean. Can you provide a link (or several) to and article where this issue is present, just to make sure I'm properly understand what you're describing? AHollender (WMF) (talk) 17:12, 6 December 2022 (UTC)

  See File:WP_vector_2022_Menu_indenting,_illustration.png, on purpose annotated screenshot. From en:Hydrogen. Actually, first met the issue in a talkpage, en:Talk:Periodic_table, where indenting can be more .. chaotic.

  Description: The examples have up to level h4 (====), old numbering "1.2.3" then. Now, the TOC captions are indented all right, but to my eye not distinguishing (easily): it requires a second look, not by glancing. Confusion added by longer section titles.

  Opinion: Personally I support the 'sticky' idea to the max: TOC overview from every page position, yeah. I'd gladly offer some bodyspace-width for this informative TOC in LH margin. Consistently: button 'unfold/fold _all_ levels' expected. Same for page menu ("What links here"-list) btw. All this about desktop view and from heavy Editor not Reader. DePiep (talk) 09:25, 7 December 2022 (UTC)

  @DePiep some more conversation about this over here: https://phabricator.wikimedia.org/T307316#8448770 AHollender (WMF) (talk) 21:02, 13 December 2022 (UTC)

Start of redirect targets hidden by top horizontal bar

See, e.g., en:WP:RELATED: the first line of text visible reads "intended to link to topics that are simply...". In other skins, the first line of text visible is the section title: "Linking to articles that are related to the topic". Fgnievinski (talk) 03:00, 14 September 2022 (UTC)

Hi @Fgnievinski, I unfortunately can't replicate - I checked on two browsers (Chrome and Firefox) and three widths (full, which is 2,5k px, ~1000 px, and ~400 px, and every time, the section title is the first line of visible text for me. What browser and display resolution do you use? Do you use any additional browser zoom? SGrabarczuk (WMF) (talk) 14:44, 14 September 2022 (UTC)

here's a screenshot: https://pasteboard.co/v1lMc2Q1Hjn9.png

my screen resolution is 1280x720 and zoom level is 100%.

I'm using Chrome in incognito mode to avoid add-ons.

the problem only appears after I login into Wikipedia.

Here are some of my preferences:

- Skin: Vector (2022)

- Skin preferences: Enable responsive mode (Adapt layout to screen size on mobile.)

- Beta: New wikitext mode

Thanks for your support. Fgnievinski (talk) 19:18, 14 September 2022 (UTC)

I can replicate the Problem, though my first line is "Disambiguation...". I sometimes have the same Problem while using the new TOC. It seems to have something to do with the sticky Header. At first the Heading is visible for a blink of an eye, than the sticky Header pops up and the Text is blocked. HirnSpuk (talk) 07:10, 22 September 2022 (UTC)

@HirnSpuk, @Fgnievinski - could you tell me what browser version and device you were using? Thank you! OVasileva (WMF) (talk) 22:37, 9 December 2022 (UTC)

I'm using Google Chrome on a PC running Windows 10. Fgnievinski (talk) 22:46, 9 December 2022 (UTC)

@OVasileva (WMF), I'm sorry, I don't remember anymore. Might have probably been Desktop-Firefox under Linux which I use mostly. I just tested in Win/Edge. The Problem is there. Standard Configuration, no zoom, middle font. Tested in Chrome, standard-configuration, problem is there. When clicking the given Link, the heading is there for a split second, than the "sticky-header" kicks in and moves over the heading. HirnSpuk (talk) 15:06, 15 December 2022 (UTC)

@OVasileva (WMF), I noticed some other weird behavior. When jumping to a specific Heading via special:permanentlink I'm not getting to the paragraph but somewhere below that. Might be related. Compare: b:de:Spezial:Permanentlink/1008062#What_the_"faq" or b:de:Spezial:Permanentlink/1003322#Lasst_uns_über_die_Desktop-Verbesserungen_sprechen

Regards --HirnSpuk (talk) 14:20, 4 January 2023 (UTC)

I am getting this too. Any time a redirect points to a section, the sticky header bar obscures the first line or two of text at the target page, so one has to scroll up to see if it is the right place (uncover the header). It looks like the page is opened at the right place, and then the sticky header is opened on top of it, covering the top text. This must be compensated somehow to correct for the reduced space at the top of the page for visible content but it is nor immediately obvious how it should be done. I am using Firefox latest version on windows 10 on desktop, and windows 11 on laptop. Effect seems to be consistent and repeatable. I notice that this effect does not occur when using the ToC, so it should be fixable by using a similar procedure. I would guess that for the ToC case, the content frame (whatever it is called), is already defined taking the presence of the sticky header frame into account, so the content is rendered after the header is already in place, so the top is not obscured.Pbsouthwood (talk) 05:52, 10 January 2023 (UTC)

Please revert to old skin on swwiki

Hi we discussed the changes during our admin conference for Swahili Wikipedia. We request you to kindly revert to the old skin for our wikipedia. We see that we would have to rewrite our help pages considerably and presently do not have the capacity. We tried to communicate this to user:SGrabarczuk (WMF) but he did not react so far. Kipala (talk) 07:50, 30 October 2022 (UTC)

Hey @Kipala, thanks for reaching out. We apologize for this inconvenience. Because it might be helpful to us as the developers of the skin: can you help us better understand why you would have to rewrite your help pages considerably? Is it because the main menu is now different? AHollender (WMF) (talk) 14:35, 31 October 2022 (UTC)

For clarity, we're talking to that community in a few different places; currently, I think, mainly via email. SGrabarczuk (WMF) (talk) 17:14, 9 November 2022 (UTC)

Hi AHollender, you are right. Our help pages (like basically all I have looked at) refer to the menue and positions of items on the screen. See e.G. here https://sw.wikipedia.org/wiki/Faili:Menyu_Wikipedia_Chanzo.jpg . For a small wikipedia with very few users who have ever worked on the help pages it means either a huge workload for which we presently have nobody - or having misleading help pages which definitely is not a good idea.. Kipala (talk) 17:24, 11 November 2022 (UTC)

We just had a vote on swahili wikipedia. See https://sw.wikipedia.org/wiki/Wikipedia:Jumuiya#Muonekano_mpya_wa_kurasa_zetu_-_kura! We had 13 participants (which is an excellent participation) and the vote was 13-0 for returning to the previous surface as default, until we are in a position to redo our help pages. So are you the right people here to effect this? Or do we have to talk to someone else? Kind regards Kipala (talk) 17:30, 11 November 2022 (UTC)

Dear people we notified SGrabarczuk (WMF) by Email on 10.11.2022 that we had done the vote in the swwiki community, we notified you here and until now nobody gave us a reply. Are you too busy or just impolite? Or are we too small and unimportant? Kind regards Kipala (talk) 12:35, 19 November 2022 (UTC)

Hello @Kipala. I'm sorry that you were waiting so long. I needed some time to consult with the members of our team.

Again, we understand and respect your care for help pages.

According to my knowledge, most of the discussion took place in a closed channel, accessible mainly or exclusively for admins of your wiki. We've only been able to talk to your group via proxy. We would much rather be able to communicate directly with the community to figure out how we can help. I believe we might set up a meeting in addition to an on-wiki discussion. SGrabarczuk (WMF) (talk) 02:48, 23 November 2022 (UTC)

Dear ones, I find this behaviour not acceptable. We did not discuss in some closed channel but we had an open debate and vote in our community. Openly: https://sw.wikipedia.org/wiki/Wikipedia:Jumuiya#Muonekano_mpya_wa_kurasa_zetu_-_kura! You were free to contribute. You guys do not dare to act like this vis a vis a large wikipedia like dewiki, Why do you think you can do this towards a small african language version??

So when do we see the revert, please?? Kipala (talk) 07:16, 11 December 2022 (UTC)

My apologies @Kipala, I was of the impression that the topic on wiki with all these votes was a direct consequence of a discussion previously taking place in a closed group. We'll talk to you on your wiki, then. SGrabarczuk (WMF) (talk) 22:16, 13 December 2022 (UTC)

@Kipala Do you have a list of help pages that would need to be updated? The file you mentioned shows only the 2010 wikitext editor, which is not changing. AntiCompositeNumber (talk) 04:18, 12 December 2022 (UTC)

Our help page are in the respective category. So would you guys kindly respect the open and inclusive decision of the community and asap revert the change you decided to do without obtaining consent? Kipala (talk) 11:36, 12 December 2022 (UTC)

Hi @Kipala - apologies that this is taking so long to resolve! Our concern with any type of revert here would be that we are in the process of switching the majority of Wikipedias to the new skin and the new experience. Having some wikis stay on the old skin by default would add effort to the development team, and potentially confuse users on the wiki because of the switch. Would it be possible for us to assist in some way to get the help pages ready and updated in a more prompt manner instead? We'd also like to mention that we plan on making other various improvements to desktop in the future as well that are smaller and could affect existing documentation. Our advice here would be to write any documentation or help pages without referring to a specific layout or interface. Our software evolves and improves over time and it would be great to see documentation that is flexible enough to allow for this. OVasileva (WMF) (talk) 20:24, 21 December 2022 (UTC)

Dear, the confusion is in place because you changed the skin without asking for approval from us. If you would kindly take a bit of time and look thru our help pages you will see that help pages must refer to the way items are arranged on the screen. if you do not write Swahili I do not see how you will help us. As you know German wikipedia took a vote to keep the "old" skin as default. And of course, because that is a large an influential community, you have not done anything without their approval. (I guess in enwiki the situation is similar). So if you can live with dewiki for the time being, I do not see any argument why you cannot live with swwiki and old skin default as well. So kindly just tell me what hinders you from reverting? (Except the fact that you do not like it and we are a small and unimportant wikipedia?) And kindly tell me since when community decisions can be just ignored? Kipala (talk) 22:24, 29 December 2022 (UTC)

Hi @Kipala -  Our sincere apologies for the delay in response here.  Our intention is not to ignore the consensus of the Swahili community.  We do believe the merits of the new skin for readers of Swahili and want to ensure that we are giving them the best possible experience.  We have discussed internally and have prepared a few options for moving forward.  We've written up these options for next steps and plan on sharing them with the Swahili community on the Swahili Wikipedia Village Pump as well as scheduling a meeting with the community where we can make a plan on moving forward together.  How does this sound?  Thank you and apologies again for the delayed response. OVasileva (WMF) (talk) 20:47, 16 January 2023 (UTC)

Since they aren't responding to this reply, understandably, I think the plan can move forward for now. Aaron Liu (talk) 21:24, 22 January 2023 (UTC)

Hi @Kipala and all! Just a quick update - we're currently translating our message for the Swahili Village pump into Swahili and hope to have it posted there by the end of the week. OVasileva (WMF) (talk) 15:10, 26 January 2023 (UTC)

Don't you think that here, as in many other discussions related to Vector 2022, you interpret everything (even someone's silence) in a way that fits your own expectations? 83.30.229.13 19:14, 26 January 2023 (UTC)

No, why would you think that? Aaron Liu (talk) 19:33, 26 January 2023 (UTC)

"Our intention is not to ignore the consensus of the Swahili community." But we will ignore he consensus of the Swahili community. Well... 83.30.229.13 19:11, 26 January 2023 (UTC)

Hi @Kipala: ! Habari? Olga: how about just reverting the default and helping sw:wp update their help pages? The concern about having them change in lockstep seems thoughtful and probably what we should all be doing before making skin changes that change common workflows :) perhaps Swahili WP is just more keenly aware of the need for and use of those docs. Future skin updates you mention would hopefully not have so many changes at once. Warmly, Sj (talk) 03:03, 20 January 2023 (UTC)

@Kipala Although I don't speak Swahili, I would like to assist with updating the help page screenshots (as I did for some on the English Wikipedia). Could you point me to where they are? You mentioned above https://sw.wikipedia.org/wiki/Faili:Menyu_Wikipedia_Chanzo.jpg but that is a feature which has not changed with Vector 2022.

As far as I can tell sw:Wikipedia:Mwongozo and its other tabs are the main help pages on Swahili Wikipedia, but using Google Translate that says "The guide has provided information specifically for those using the MonoBook page format. Since September 2010 the shape of the pages as seen by non-logged users is Vector. The guide has not yet been rewritten." and they have MonoBook screenshots. Surely those can't be what you're suddenly so concerned about? the wub "?!" 00:03, 26 January 2023 (UTC)

Jambo Kipala! hongera! n-a-Kipala-penda, nakupenda. (kigiriki el.wiktionary, Central) Sarri.greek (talk) 04:11, 26 January 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)

> 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)

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:

.dark_mode {background-color:black; color:white}

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 .dark_mode and .white_mode 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)

Long article blurry

Tracked in Phabricator
Task T322978

Vector 2022: Long articles (for example w:Johann Sebastian Bach) show blurry (a little bit bold) fonts after scrolling to references. Mouse hover corrects artifacts to normal font. Grimes2 (talk) 21:11, 25 November 2022 (UTC)

Hi @Grimes2, thank you for the report. Can you verify if your problem is the same of this task? Patafisik (WMF) (talk) 12:27, 5 December 2022 (UTC)

Yes, same problem, here on English Wikipedia (logged in, Vector 2022), Opera 93.0.4585.37, Win 11. Grimes2 (talk) 12:42, 5 December 2022 (UTC)

TOC is the problem. How can I switch off buggy TOC in Vector 2022? Grimes2 (talk) 13:41, 21 December 2022 (UTC)

Unusable. Changed to Vector legacy (2010) Grimes2 (talk) 09:34, 7 January 2023 (UTC)

@Grimes2: Please visit this page with instructions.--Patafisik (WMF) (talk) 17:35, 18 January 2023 (UTC)

Doesn't work. Still at Vector 2010. Grimes2 (talk) 18:15, 18 January 2023 (UTC)

Seems to be fixed today. --Grimes2 (talk) 22:29, 24 January 2023 (UTC)

Purge-by-clock disappears

In old and new vector, I can purge a page by clicking the clock, somewhere top-right. OK. In Vec2022, the clock is in the usermenu (top-right, dropdown). (1) It now is invisible by default (sort of undoes its usefulness, a read-only-but-often). (2) the clock disappears from that menu when page is scrolled down. E.g., when I am down somewhere in section #4 on a /testcases page, I can unfold the usermenu all right, but the clock is not there and so I cannot purge the page. Have to go to top of page for this.

I'd expect (1) the clock be more often in view (possiby in top-of-page only, agree), and (2) the clock/purgebutton to be in the dropdown menu for purging when scrolled down (sticky-in-the-menu?). BTW for me, the purge could be a distinct menu item just as well. DePiep (talk) 15:11, 1 December 2022 (UTC)

Hey, thanks for reporting this. There are a few different issues, I don't have all the answers yet, so I'll get back to you when I know more.

A quick direct to your last thought is that there are other gadgets adding the purge as menu items, for example MoreMenu. Another one is mentioned here: w:Wikipedia:Purge#Gadgets. SGrabarczuk (WMF) (talk) 13:50, 9 December 2022 (UTC)

I posted a feature request at the talk page for the clock gadget. Jonesey95 (talk) 01:46, 15 December 2022 (UTC)

I have seen this. With Vector 2022 the purge clock appears and disappears at random; it’s often not there (as in not even as a menu item), but sometimes it’s there.

One reason I don’t use Vector 2022 (there are other reasons...). Al12si (talk) 01:20, 10 February 2023 (UTC)

• I don't see any clock in the dropdown usermenu at all, how does one switch it on? I wish we could have more control over the usermenu and what displays without dropdown TBH. Ain92 (talk) 10:42, 19 January 2023 (UTC)

  re User:Ain92 In my preferences (at enwiki), I have chosen "Vector 2022), then in "Gadgets" I choose option Add a "Purge" option to the top of the page, which purges the page's cache". DePiep (talk) 18:13, 22 January 2023 (UTC) -DePiep (talk) 18:14, 22 January 2023 (UTC)

Please, add classic style

Could you please, please, add somewhere (visible) 'Classic style' or something? For logged or not logged people? Some of us wish to stay with the classic style. I cannot find it when I am not logged. Thank you for all your efforts, but we need Classic everywhere, in all wikimedia projects. Please? Please? Sarri.greek (talk) 23:28, 9 December 2022 (UTC)

@Sarri.greek: Have you checked Special:GlobalPreferences#mw-prefsection-rendering (select Vector instead of Vector 2022)? --NGC 54 (talk | contribs) 23:46, 9 December 2022 (UTC)

Thank you @NGC 54, I clicked some buttons there. But is this for unlogged people? I would like a visible button somewhere 'Classic' (not hidden in a menu). I presume that if I go to History, at previous versions, I can see the normal style. Sarri.greek (talk) 00:02, 10 December 2022 (UTC)

@Sarri.greek: No, it is not for unlogged people. --NGC 54 (talk | contribs) 00:06, 10 December 2022 (UTC)

Boooooo. 👎👎 172.58.174.193 18:44, 18 January 2023 (UTC)

And that, my friends, is the problem. I don't want to be logged in on my work computer but the new layout is SO LOATHLY (Yet Another Change Is a Downgrade But Try Telling the UX Wags That -- Gmail, my bank [all of them actually], imdb, reddit, digg and now, heaven help us all, wikipedia -- it's all at "Gnome3" levels of hateration, folks) that I'll probably make a fake-me login there just. for. this. one. reason. That can't have been your intention. I have a number of friends and relatives who are creating users just so they can have Their Wikipedia Back, with no intention of EVER being editors or authors.

Yes, this is a must-have feature for non-logged-in people. How strongly must we put it in order to succeed in bringing about this change. There's a tribe of UX mavens who need to be reminded that Change Is A Downgrade for your existing users, even the ones who don't log in.

cheers...ank Ansak (talk) 23:08, 5 February 2023 (UTC)

Hello @Sarri.greek. This is unfortunately not possible, the same way it's not possible for logged-out users to use Monobook instead of Vector legacy. You can read more in our FAQ (Why is the opt-out link not available for logged-out users?). SGrabarczuk (WMF) (talk) 21:43, 13 December 2022 (UTC)

Thank you @SGrabarczuk (WMF). Thankfully, all wiktionaries are in classic style except the French, which we avoid. For wikipedias, we may try to find equivalent projects. Sarri.greek (talk) 10:23, 14 December 2022 (UTC)

@SGrabarczuk (WMF), why not add a permanent global little banner line with

For Classic Style, log in and click Classic2010 here

Sarri.greek (talk) 11:51, 14 December 2022 (UTC)

this

i lurk every day becuase i dont have to put up with tracking bullshit this is a spit in the face to longtime users that dont simply want another stupid platform to login to 2601:644:9180:31B0:C177:B313:1C8D:2C7F 04:00, 21 January 2023 (UTC)

That's such a bullshit non-answer. Tons of sites have figured this out without any issue. It's 100% within the capability of the servers. 24.242.64.48 16:11, 19 January 2023 (UTC)

I agree, it shouldn't be that difficult to add a simple drop-down list with a selection of CSS styles and save a cookie with the choice. 2A02:A312:C539:8D80:78DE:760D:452F:23E2 20:15, 19 January 2023 (UTC)

I agree 100%, if Reddit can do it, and if switching to Monobook (objectively the best design) is even still possible for signed in accounts, that means that the layouts merely manipulate what data is available, not build every page from the ground up... so therefore could easily be deployed and used as people saw fit. You don't want that because people would be switching back to Monobook and your designs would be discredited as being an advancement (which they aren't) IF they can't, then I want the old Vector 2010 back since the new design is absolutely laughable. there's literally twice as much white space than text. (I have a big monitor) Ikaruseijin (talk) 00:42, 21 January 2023 (UTC)

Another annoyed Wikipedia user here; corporate policy at work is 'no personal accounts on corporate computers'. Any suggestions for reverting to a usable Wikipedia skin? 192.157.110.190 02:09, 20 January 2023 (UTC)

I am afraid this might drive people to find information elsewhere. I was already considering alternative sources for quick knowledge on organic chemistry, but luckily read that you could create an account and change the style back. I find the white-spaces and compact text-boxes with short lines an eyesore and very difficult to skim through, unfortunately. Mftp96 (talk) 19:29, 20 January 2023 (UTC)

Hello, Mftp96, friend 192.157.110.190, take a look at the end of next section. I want there, and it is fun. Sarri.greek (talk) 20:04, 20 January 2023 (UTC)

Let the public decide

My opinion is this. The phsyiognomy of wikiprojects: style-structure-content is known to the public as its fundamental characteristic. If a radical change were to be introduced, it should first be monitored as a choice of the public. If the two thirds of the public show preference to a new style in a span of e.g. 5 years, then, and only then, it could be introduced as default. The technical aspect, especially for mobile phones, is a spearate issue. Sarri.greek (talk) 16:42, 14 December 2022 (UTC)

I strongly agree. People react much more positively if they get a choice like "Hey we have an exciting new Theme you might like better: click here to try and tell us what you think."

Instead of just changing the look of what is basically public utilities by now to a version that should have had more testing. This was handled poorly, IMHO.

--Real Joe Cool (talk) 00:20, 16 January 2023 (UTC)

Absolutely. If the developers think it's just going to be something like the introduction of Windows Vista—no, it is not. There is not a single thing that is preferable about this new version when compared to the old version. A timespan of 5 years is not exaggerated at all. I could even argue that it should be a decade instead, and instead of 2/3 it should be 3/4 in favour. Vector 2022 is just a bunch of random pointless modifications to the old UI, an ego booster for Wikipedia's design team. I don't even know how this ever got out of the think tank. 172.58.174.193 18:42, 18 January 2023 (UTC)

I had to dig up and use my long abandoned login just to get away from this new heinous design on all my browsers. This should be a choice at the top of the page at the very least. Yes, it should be possible for unlogged visitors via cookies. Fredirc (talk) 21:09, 18 January 2023 (UTC)

I had to create a user on wikimedia just to revert to the old design. The new design is terrible for desktop. I am not browsing on a phone so it should not look like I am. 50.53.69.99 21:12, 18 January 2023 (UTC)

I for one have made my contribution in the fight against this abominable UI on [this page](https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements). These annoying, constantly moving, constantly taking space table of contents and the bar at the top, eating my screen space, will unirinically make me stop reading Wikipedia. Yes, my mental health is more important. And if I were an editor, I would lose all inspiration to keep editing if logged out users would see it this ugly and irritating.--Adûnâi (talk) 01:19, 19 January 2023 (UTC)

Well, @Adûnâi: , I will not exaggerate. The new style is elegant. Which, I presume, is why the French wikipedia and wiktionary have been using it for some time: très chic. It is a) habit and b) the lack of Contents, Languages, that hinders me from using it. Is consistency between wikiprojects a problem? Then, small changes could have been introduced bit by bit over the years. Of style, of practical issues. This 2023 change was too abrupt. I cannot see why so many wikipedias voted for it (Have the voted? or were they told?). No unlogged reader has the time to go to some preferences and start ticking things... For wikiprojects that vote yes, to make the new vector default, please add a visible link 'switch to clasicc look' Thank you all. Sarri.greek (talk) 03:03, 19 January 2023 (UTC)

Elegant? How so? The new design is clunky, awkward, hides tools and options, makes the dealing with the ToC a chore, switching languages more cumbersome... (the original full list of languages, on the left, was best. Why Wikipedia ever strayed from that, I will never understand ...and any claim, that the new design frees up space, can be countered by not only the point that the space the side-bar takes up, has never been a problem, but also with the fact that there still is a sidebar. It's just empty ...which is weird and unsettling)

It takes more time and effort, to do anything or get any information. Ones ability to get an overview of things, or to navigate, is clearly diminished. Functionality, practicality and efficiency is severely hampered. Not because it is an unfamiliar set-up, but because it is an inherently, objectively, and significantly, less functional/practical/efficient design. (and this is true of most "upgraded"/"updated"/"modern" website designs, from about the 2010's onward)

The new design makes the desktop design, closer to the mobile design ...but I have yet to see, any reasonable argument (or any argument whatsoever), for why that would be a good thing. Why one should make the desktop version, be closer to a design that has to be severely limited, by the severely limited abilities of mobiles (most notably, their minimal and extremely clumsy and imprecise touchscreens)--155.4.221.27 08:25, 19 January 2023 (UTC)

Of course, -155.4.221.27 functionality is terrible. Which is why this new Vector=default must be reversed. Currently we avoid all wikiprojects using it. Thank you. Sarri.greek (talk) 08:41, 19 January 2023 (UTC)

I've "voted" by cancelling my donation. The new UI is awful and I don't want to support its development in any shape or form. iliaarpad 10:21, 19 January 2023 (UTC)

Same. Cannot believe there is no way to change for unlogged users. 2001:4898:80E8:2:FE3F:D790:8002:69A9 22:15, 19 January 2023 (UTC)

The French Wikipedia didn't choose the new design. We were forced into it as a testing ground. And no matter what we said, it stayed. DerpFox (talk) 20:54, 21 January 2023 (UTC)

I too am one of those who sole made an account to change back to the old layout and start complaining about the change. Looks BAD on desktop. And my most used feature, changing languagebetween those I'm familiar with, is hidden behind extra clicks now. Khyprus (talk) 11:39, 20 January 2023 (UTC)

i made an account after like a decade of constant reading and occasional editing just to avoid the new layout. its hideous. way too much whitespace. hoping it gets fully reverted soon. 66.189.54.146 03:23, 21 January 2023 (UTC)

Couldn't agree more. I made an account specifically to switch back to the old layout.

I would be surprised to learn that anyone in the design team is over 40. This screams "mobile generation" to me. It's like someone was hired to improve the layout and the best they could come up with to justify their job was to turn every user into a mobile user.

I have a wide screen monitor for a reason. Let me use it. Shittylayout (talk) 04:37, 21 January 2023 (UTC)

Highly agree that desktop layout is much better than phone layout, and ditto re not donating any more. 2user2

Is there a way, for unlogged people, to copypaste texts of wikipedias in a different .htm thing, -sorry, I know nothing about computers-, so that we will have a permanent viewing medium? Something like a 'style-converter' outside wikipedia? Could a programmer make a webpage with such a thing? Preferences are for editors with a username, not for readers. E.g. I have Edge, and cannot see Contents. Languages are somehwere on top. Also, I like to see the Classic style (that is why it is called 'classic', one does not change it) I have saved lots of lemmata from earlier stages of wikipedia because they are more concise, and they look fine. Sarri.greek (talk) 22:31, 19 January 2023 (UTC)

There are websites that provide a different frontend to Wikipedia, like Wikiwand. Just note that they are usually ad-supported products. Longbyte1 (talk) 22:48, 19 January 2023 (UTC)

Thank you Longbyte1! Very good: I can see Contents there. They miss languages, like en el fr etc or αγγ ελλ γαλλ .. I like the 3 strata, a very wise approach of an encyclopaedia: basic (what is encyclic general knowledge), medium (a bit more for one interested) and expert (all details there)! This is a solution to the "curse of red shoes": lemmata that grow larger and larger; very difficult to read. Thank you indeed. Very good for older people like me. I don't install things, too scared to click changes! Thanks. Sarri.greek (talk) 04:47, 20 January 2023 (UTC)

Hello. Maybe this little trick can help you: simply add «?useskin=vector» to every requested URL. It works for non-logged users. 37.134.90.176 08:44, 23 January 2023 (UTC)

Thank you dear 37.134.90.176. I have a username, so I fixed Preferences and can read here too, in the widths and styles I choose. It is you we are worried about Sarri.greek (talk) 18:54, 23 January 2023 (UTC)

The trick 37.134.90.176 mentioned, works for non-logged-in IP users/readers. It is annoying to manually add that "?useskin=vector" to the end of every Wikipedia-URL, however ...but it's nice that one can at least do that. 155.4.221.27 03:00, 25 January 2023 (UTC)

I just used it to try out monobook, as well, to see what that is ...and man, that took me back. I'd say that "classic" vector was a slight improvement, in looks (mainly the changed font size), but no real change in functionality. The new vector, however... 155.4.221.27 03:08, 25 January 2023 (UTC)

That's a life-saver, thanks you! Here is the Google Chrome extension which does the same (analogous to the old.reddit redirect).--Adûnâi (talk) 20:54, 31 January 2023 (UTC)

Less functional article language switcher

Hello. In old skin I can simple add an new language version of particular article – in those new I didn't notice such an option. Also, an old version have link to wikidata under article's languages (as "Edit links") – again, I can't find it. So would I every time have to go to wikidata and find a requested page on myself? It is strongly uncomfortable for persons who work in few languages. --~~~~ Wojsław Brożyna (talk) 09:59, 11 December 2022 (UTC)

Here is some related discussion and a link to a Phabricator task: Talk:Reading/Web/Desktop_Improvements/Archive6#"Add_languages"_missing_"Add_links"_dialogue?. AllyD (talk) 09:40, 12 December 2022 (UTC)

Hey @Wojsław Brożyna — are you referring to the "Add interlanguage links" link? If so, it will soon be available in the page tools menu on the right-side of the page (show in the image below, with the orange arrow). You will be able to have this menu "pinned", so it is always visible. Let me know if that solves your issue or not. Thanks,

Vector 2022, work in progress showing "Add interlanguage links" in page tools menu to right of article

AHollender (WMF) (talk) 14:06, 5 January 2023 (UTC)

@AHollender (WMF) yes, it is that function (but it is visible for me as "Edit interlanguage links") :) Thank you! Wojsław Brożyna (talk) 14:13, 5 January 2023 (UTC)

Page tools move initial thoughts

Hi @SGrabarczuk (WMF) and @OVasileva (WMF)! I just tested out the move of the page tools to the right side of the page per the instructions in the recent newsletter. Overall, the approach looks good, and the rough edges I'll mention below are likely things you'll address before the full rollout, but I wanted to offer my initial feedback while it's still early:

• Twinkle isn't currently merged to the new tools menu, but I think it would be good to do so. Fundamentally, Twinkle tools are tools the same as WMF tools, and from the user angle it makes sense to clump them together.
• The menu headings could use some work. There's currently some redundancy, with "Tools [move to sidebar]" and then "Tools" again right below it, which is confusing.
• The "Edit interlanguage links" option that is showing up displays weirdly, in a small font. I'm also a bit confused why it's there at all — there's already a link to the Wikidata item, where the interlanguage info is stored, and changing the interlanguage links is a very rare task that shouldn't use up menu space.
• I try to limit the number of gadgets I install, but even with my relatively modest package, the menu goes off the bottom of the screen (and would go off the screen even farther if the Twinkle merge above is implemented). This requires me to scroll to get to some items, which is annoying. To fix this, I'd suggest considering having the different sections of the menu show up beside each other rather than above/below each other.

That's all for now. Feel free to lmk when there's a newer version to test! Cheers, {{u|Sdkb}} ^talk 23:04, 13 December 2022 (UTC)

Related to the Twinkle menu suggestion: My combined Tools/More menu requires vertical scrolling as well, which is undesirable. I could probably reduce the excessive vertical white space with CSS, but I came here to suggest that Tools be its own menu: Tools / More / TW. There is tons of space available. I love the idea of having this menu at the upper right, which is where I go to do that sort of gnome/administrative stuff anyway. Popping out the left sidebar for the occasional "What Links Here" query and then popping it back in is a lot of hassle. (And yes, I know about the What Links Here keyboard shortcut, but it doesn't appear to work with the Mac's Command key to pop up in a new tab, which is always what I need.) Jonesey95 (talk) 02:07, 15 December 2022 (UTC)

Thanks for this feedback @Sdkb. Just commenting to let you know that we've taken note of it. Some issues have already been fixed, and the others we're working on. AHollender (WMF) (talk) 14:12, 5 January 2023 (UTC)

2022 is BAD.

Vector 2010

2022. Just. WHAT. ARE. THOUSE.

Does Vetor 2010 really that bad at something? Fits in the screen too god? Uses the space in a too rational way? Like "Eeh, it's too god; users don't deserv it; we gonna screw it" There is NOTHING to argue about. Just look at it:

What ARE thouse gaps?

You can add the language switch and the table of contents from the 2022 – they ARE pretty neat. And again – if you will, 2010 will be even MORE better than 2022. But does it really mean you have to cripple THE ENTIRE page design? I don't think so. Jiira (talk) 12:03, 14 December 2022 (UTC)

Thanks @Jiira for reaching out to us. I guess you added this comment soon after you saw the skin for the first time. Am I correct? Have you maybe had a chance to read our documentation about the white space and the goals for this project? SGrabarczuk (WMF) (talk) 18:29, 15 December 2022 (UTC)

Hi @SGrabarczuk (WMF) . I had the same initial white space concerns after checking out Vector 2022 on 16:9 desktop. New format may be better for mobile users, and unification of experience across platforms is admirable, but I will be sticking to 2010 as I am primarily a desktop user. Seldom on mobile, but does this change affect the (android) app (or other apps)?

Also, I (probably like Jiira) was brought to this page directly from my account preferences - can that link be updated? Preferences > Appearance > Vector (2022) > Discussion.

If you are here like me looking for further information, I suggesthttps://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Discussion

or

Reading/Web/Desktop Improvements

Thank you Grabarczuk. MC the MD (talk) 00:22, 14 January 2023 (UTC)

I completely agree with the first post here and just look at the screenshots. The new website needs a manual switch to make text fill the whole display width in 2023?! Is this a joke? A manual switch for something which is now automatic on all modern websites made in the last decade??? The switch is not even visible on low resolution displays and we have to zoom out the browser to even see the switch-did someone even test this thing?

The first thing that should be done right away is to make the text fill the whole display automatically without any need for user actions and it should work on all widescreen resolutions on modern displays. No one needs so much white space-a little is ok but not the current amount. The users without account are not given any choice-this sucks too. To me it looks we are forced as readers to make an account just to make the site usable. If we do not make an account we have no option to use the page layout we like, no one offers anything to avoid the weird new design. Very bad design overall, I will stop my reading sessions here if this is the only option, sorry but this goes way too much in the wrong direction. I even try to edit some small mistakes but now the motivation to even read will be severely killed. 94.26.15.134 14:18, 17 January 2023 (UTC)

Kudos. Absolutely describes my sentiment. I had to browse through dozens of proxy lists for hours just to find a free working residential proxy to comment here. As an avid wikipedia reader who uses a VPN and thus cannot register an account, this new change just handicapped at least 5% of all wikipedia users who must use VPNS in order to access the website because of their country. The new design is so ugly I can't even concentrate on reading anything here anymore. 172.58.174.193 18:37, 18 January 2023 (UTC)

New layout is horrible, we don't want to know why it seemed like a good idea if we are saying it is not. Full width please. 149.170.16.251 11:16, 19 January 2023 (UTC)

Genuinely awful. It's insane that you have to make an account now to access the old look. There are myriad solutions to that problem that could have been implemented. 24.242.64.48 15:53, 19 January 2023 (UTC)

delete? 2001:9E8:6700:2B00:FA32:C515:A23D:3E1D 18:17, 6 February 2023 (UTC)

Yeah this is pretty awful, I'm not sure what documentation you followed or corporate Feng Shui web design manual you guys read, but this sucks. I didn't buy a monitor that's 2560 pixels wide only for it to be filled with content that's 1000 pixels wide, if I wanted to read things vertically, I would use a vertical device aka my phone, where the Wikipedia mobile website works just fine. Not sure why you guys decided to mobile-ify a perfectly fine Desktop site, but it's bad, genuinely bad, and whoever made this decision surrounded by yes-men needs to be told that they screwed up and made a bad decision. 104.202.250.242 16:39, 19 January 2023 (UTC)

I did read the "explanation," and the white space is still ridiculous. If someone has an issue with to many characters on a line, did you know that you can resize browser windows? So, the only thing you are achieving here is taking options away from users, as widening the window does not restore the the content to full screen width.

Also, the explanation as to why logged out users are not allowed to change the layout holds no water. Setting a cookie with the preference should be fairly straightforward. The only context where any of this makes sense is as an attempt to get users to create accounts so data can be harvested. 193.190.231.132 12:05, 20 January 2023 (UTC)

The documentation on why there's so much white space indicates it's better for comprehension but worse for scanning. Why does finding specific information not warrant any consideration? Much of it also indicates that it's a subjective prefrence. Why not assume people are using full screen or wide windows because that's their preference? There are so many options to make the screen smaller already. 38.64.242.125 23:41, 20 January 2023 (UTC)

The old design has a lot of wasted space too, just in different places. You just don't notice it because you're used to it:

https://files.catbox.moe/u2t44s.png

2001:8B0:DFDC:12BC:759:79A4:937E:9CC8 20:49, 19 January 2023 (UTC)

That whitespace is mostly isolated to horizontal whitespace at the top of an article, whereas the new whitespace persists vertically over the entirety of the page.

It's like comparing a novel with large chapter headings to a novel with 4cm margins. 144.32.240.151 17:19, 26 January 2023 (UTC)

Forcing narrow new layout has no respect for different learning styles or preferences. Before people could get a narrower or wider view by simply resizing their browser window. Now, for some reason you want to force half my screen to be blank because some other people like narrow lines? Stop being one-size-fits all and instead be inclusive. Go back to letting us choose our preferred width.

72.66.107.22 19:12, 19 January 2023 (UTC)

I would absolutely add that I'm in the users that have absolutely newly registered an account solely to get usable width of pages, visual differentiation between what is UI and what is article, and TOC on desktop again. Desktop wikipedia does not need to be a mobile browser. 63.227.213.235 20:03, 19 January 2023 (UTC)

Me too, made an account for the express purpose of reverting layout and complain about the new one. Its bad design and has hidden used features behind MORE CLICKS. Khyprus (talk) 11:44, 20 January 2023 (UTC)

Tools menu and language switcher feedback

I will use https://ro.wikipedia.org/wiki/Utilizator:NGC_54?vectorpagetools=1&uselang=en and https://ro.wikipedia.org/wiki/Fran%C8%9Ba?vectorpagetools=1&uselang=en as examples.

• The tools in the "More" sections should be above tools in the "Tools" section.
• The sister projects are missing.
• I like the idea of adding the "Add interlanguage links" in the language switcher (phab:T310259). The "Wikidata item" link could be moved there, too. Or maybe it cold be moved in the "In other projects" section.
• "Upload file" and "Special pages" are not page-specific but are bundled with page-specific tools.
• "Printable version" and "Download as PDF" are missing.
• "User contributions", "Logs", "Block user", "Email this user", "Mute preferences" and "Change user groups" are user-specific, but they are bundled with page-specific tools.
• phab:T317898: The "move to sidebar" option should also be shown to unlogged users. This menu contains links interesting to readers, like "Cite this page", "Download as PDF", "Printable version", "Permanent link", "Page information" and the links to other projects.
• There is no link to the page logs (https://ro.wikipedia.org/w/index.php?title=Special:Jurnal&page=Fran%C8%9Ba). This is not Vector 2022-specific, but Vector 2022 could fix this.

I propose the following order for pages that are not in the user space (like https://ro.wikipedia.org/wiki/Fran%C8%9Ba?vectorpagetools=1&uselang=en):

• Actions
  • Move
  • Delete
  • Protect
• General
  • Page logs
  • What links here
  • Related changes
  • Page information
• Print, share, link
  • Permanent link
  • Cite this page
  • Download as PDF
  • Printable version
• In other projects
  • (The list of pages)
• Others
  • Special pages
  • Upload file

I propose the following order for pages that are in the user space (like https://ro.wikipedia.org/wiki/Utilizator:NGC_54?vectorpagetools=1&uselang=en or https://ro.wikipedia.org/wiki/Discu%C8%9Bie_Utilizator:NGC_54?vectorpagetools=1&uselang=en):

• Actions
  • Move
  • Delete
  • Protect
• General
  • Page logs
  • What links here
  • Related changes
  • Page information
• User
  • "User contributions"
  • "User logs"
  • "Block user"
  • "Email this user"
  • "Mute preferences"
  • "User groups"
• Print, share, link
  • Permanent link
  • Cite this page
  • Download as PDF
  • Printable version
• In other projects
  • (The list of pages)
• Others
  • Special pages
  • Upload file

P.S. Please fix the phab:T322978 bug. The task was created on 13 November, and now is 14 December. It is annoying to meet it daily :(

P.P.S. See ro:Special:Contribs/79.115.125.90 and ro:Wikipedia:Cafenea#Ajutor (permalink) for some feedback regarding the limited width and the new TOC (by an anonymous reader). --NGC 54 (talk | contribs) 17:15, 14 December 2022 (UTC)

@NGC 54 thanks for this comment, it's very helpful. Regarding the missing items, those bugs will be fixed soon. Regarding the grouping and ordering of items in the menu, we've discussed enabling control of the page tools menu in a way similar to the main menu (which uses MediaWiki:Sidebar), which would allow individual wikis to customize the grouping and ordering. For now we are going to maintain the ordering and grouping that exists in Legacy Vector, but generally speaking we agree with you that there could be some improvements. AHollender (WMF) (talk) 14:30, 5 January 2023 (UTC)

And I would also like a link to Special:CentralAuth. I often use this feature, and I would like quick access to it. --NGC 54 (talk | contribs) 13:26, 23 January 2023 (UTC)

Contents missed out while printing

While printing a document, that is in Vector 2022 layout Contents list is missed out on the Print...It should be fixed. KCCian24 (talk) 08:03, 16 December 2022 (UTC)

I , again, second that! TOC is needed in Print, especially for wikibooks it's important. Regards, HirnSpuk (talk) 14:28, 4 January 2023 (UTC)

• Hi @KCCian24: thank you for your feedback; About printing or not the TOC you can read previous discussion and tasks here, here and here. I was discussing about this this morning at the Teahouse too.
• Hi @HirnSpuk: thank you for your feedback and for adding your comment on Phabricator. Actually the Web Team is especially focusing on discussions with the community of the English Wikipedia, but I agree with you, it will be useful to consider different needs of projects other than Wikipedia, like Wikibooks ones, so please remind us in few weeks if we forget it (but I hope not).--Patafisik (WMF) (talk) 16:32, 23 January 2023 (UTC)

  Hi @Patafisik (WMF), what exactly would you like to be reminded of? Fun Fact: If the toc is "hidden" it is printed. How about just "triggering" the old-style toc via the magic word "toc"? I can understand, that's normally not necessary to have the printout, right-setup and limit option for wikipedia-articles. But except for wikibooks as my "home-wiki" I also think about community, talk and help pages. Regards HirnSpuk (talk) 18:37, 23 January 2023 (UTC)

  @HirnSpuk Remember us about this issue for Wikibooks when the Team will be less busy with the English Wikipedia, but before the deployment on other projects to allow them to fix it if needed.

  What do you means with "If the toc is 'hidden' it is printed"? That the preview is not showing the same layout that is printed? Can you detail me steps to reproduce, browser are you using, the link you are using to print, with an example of page, please? If it is a bug I can open a ticket on Phabricator, or you can do it too. Thank you Patafisik (WMF) (talk) 10:27, 24 January 2023 (UTC)

  @Patafisik (WMF), thanks, I'll try to remember! Regarding the 'bug'(?): there's a little link in the toc to "hide" it at the Top-Heading. Then it's printed, though with a poor layout. If it's in the side-bar, it's not. Tested in Windows/Edge and Linux/Firefox. Although I wouldn't give it a high priority from your pov, because you are focusing on Wikipedia and V22 and I suppose nobody would ever notice in Wikipedia. I just did, because in my impression it's a thing with (at least german) Wikibooks. One could even think about this as a feature, to "choose" if the toc is printed or not. Regards, HirnSpuk (talk) 07:10, 26 January 2023 (UTC)

  New TOC is taking too much space in the print; And a messege saying "printable version is no longer available" is displayed in English Wikipedia... It should be fixed. KCCian24 (talk) 09:09, 4 February 2023 (UTC)

Could we default to (or at least allow) default collapsing of level 3+ headers in TOCs?

Currently, when a level 2 header in the TOC is expanded, all the sub-headers are shown, no matter their level, and the only visual indication of header level is then a small indent, about the width of a character. This is strange and unhelpful behavior for navigation, especially on pages with several header levels, like long disambiguation pages (e.g., expand "Arts and entertainment" on en:Star (disambiguation)). When I expand an L2, I would expect to see only the L3's, which I could then expand as needed (and same for L4's etc.) to find what I'm looking for (like in the en:Windows Registry).

I think this should be the default behavior (anyone else?), but if it can't be, can we at least get a magic word to set that behavior on a page-by-page basis? Or failing that, could we get some vertical lines to emphasize the level of indentation? Swpb (talk) 15:34, 19 December 2022 (UTC)

I agree that this behavior is contrary to how TOC UIs have always worked. They should open one level at a time, with a key-press option to allow opening of all levels (on Mac OS, this has always been the Option key). As for the visual distinction between levels, I have found that the best way to get that is to restore numbering. See task T307316 for the feature request and https://en.wikipedia.org/wiki/User:Jonesey95/common.css for implementation. Jonesey95 (talk) 19:34, 27 December 2022 (UTC)

@Swpb thanks for this feedback. Firstly I want to acknowledge that the new TOC is probably the most complex feature within Vector 2022, and I anticipate that we (community & WMF together) will continue to iterate on it for the foreseeable future. We've been hearing a lot of feedback, and it seems like some additional configurability, magic words, or other such things might be valuable (such as T317818, and more high-level things likeT318186). You can see the current collection of tasks here: T325064

Regarding your point: should we show all of the sub-sections (h3, h4, h5, etc.) when expanding an h2, or only show the next-level down (e.g. h3)?

• I think this is probably an 80/20 thing — 80% of the time (or maybe even more) it makes sense to expand all sub-sections at once (because if there are sections beyond h3s, there will not be many of them, so if we have expandable headings at each level it will require a lot of extra clicking), and 20% of the time (or maybe even less) it makes sense to have collapsable arrows/parent sections for each level.
• In general, headings below h2s don't seem to be used in a very consistent way across articles. There is not always a clear difference between an h3, an h4, and an h5. Often times it seems to be an editorial/stylistic choice. However h2s do seem to be significantly different than other headings (both in terms of how they are used, and how they are styled). Therefore I think there's an argument to be made that we can draw a line between h2 and h3/h4/h5/etc., and say that h2s are special, and therefore can be treated differently (with this unique "parent" quality, with an expandable arrow), in the table of contents.
• In specific cases, like disambiguation pages which you bring up, the use of headings might be a bit more systematic/formalized. I agree that in these cases it might make more sense to have a magic-word or something similar to allow that configurability.
• A few years ago we collected data regarding the frequency of h2s, h3s, h4s, etc. I'm not exactly sure how this data might be helpful in making decisions here, but it seems relevant. Link to data: https://phabricator.wikimedia.org/T18691#5027417

itwiki:

total number of articles: 1,510,504

... with Level 2s: 1417437 = 93.839%

... with Level 3s: 473253 = 31.331%

... with Level 4s: 92182 = 6.103%

... with Level 5s: 8402 = 0.556%

... with Level 6s: 588 = 0.039%

... with Level 1s: 12 = 0.001%

Thanks, AHollender (WMF) (talk) 15:44, 5 January 2023 (UTC)

In response to this, I think it makes more senses if L1 hearers were expanded by default (or at least with an option for this to be the case). I argue that a main use-case of this site is for rapid reference checking of something (e.g., "what's the formula for the conditional distribution of a multivariate normal distribution again?"). With the current setup of only L1 headers being shown as collapsed, a user landing on the multivariate normal distribution wiki would not see as an option and would instead have to seek through the L1 headers until they stumble on the "conditional distribution" subheader (or hope they get lucky using the right words with cntrl+F). However, if L2 headers were visible by default they could easily see that the conditional distributions section falls under the "Properties" heading (rather than the falling under the similar "Statistical Inference" heading).

I agree that we need to find a balance between information density and not being overwhelming (like the massive fully-expanded Vector 2010 TOC could sometimes be), but, looking at the stats you provided above, it seems that it makes sense for the L2 headers to at least be exposed considering they are available for 93% of articles. Further, this stat shows Vector 2022, in its current form, will slow down the majority of "quick reference use-cases" searches by not having quick navigation. Seankski (talk) 18:33, 6 February 2023 (UTC)

Dismissing ephemeral dialogs

I adopted Vector 2022 early on, and I'm coming to know its new features. I see that it's making more use of ephemeral dialog notifications. A major one I deal with is the watchlist addition. Now, this dialog has a clickable link and a dropdown option, so I was reluctant to click it. But I found that while it obscures some other interface elements I want it to go away more quickly. I recently discovered that it is clickable, so clicking an ephemeral dialog causes it to disappear on command. Unfortunately this behavior is not orthogonal to typical mobile UIs where dialogs can be swiped out of the way, or clicking outside of them causes them to disappear.

• Is this intentional behavior and does it apply to all ephemeral dialogs?
• Is it guaranteed to work going forward, i.e. is it working by design and accepted by the userbase?
• Is it possible that an enhancement will allow dismissal by clicking outside, like on mobile, or is this infeasible?

Elizium23 (talk) 04:58, 21 December 2022 (UTC)

Hey @Elizium23, thanks for this feedback. I would just like to note that the behavior of dialogs is not directly related to Vector 2022, so this might not be the best place to discuss improvements to them. Probably what would be best is reaching out to the Design Systems Team. I see they have a task regarding adding dialogs to Codex (the design system), so you could probably add your feedback there: https://phabricator.wikimedia.org/T313773. AHollender (WMF) (talk) 15:48, 5 January 2023 (UTC)

Old style TOC in Vector-2022 Skin

Is there a possibility to set up old style TOC in Vector-2022 Skin at my Mediawiki website v.1.39.0? Fokebox (talk) 11:41, 21 December 2022 (UTC)

This problem has been raised multiple times both here and on en.wiki. Many users have expressed their preference for the old style TOC. However, this has been completely ignored by the developers, both here and on en.wiki. Moreover, in the general request for comment on en.wiki a majority of users expressed themselves AGAINST the implementation of Vector 2022; it has been completely ignored, and the result has even been sold as an endorsement. 37.161.248.115 05:42, 28 December 2022 (UTC)

Basically I do like Vector 2022 except TOC style. I like how it is done in MW 1.38.x - there is a refreshed Vector skin, but with old TOC style. And I have couple wiki websites and just because of this fact I don't have desire to update to 1.39 ... if so I will have to change skin (Timeless as an example). Fokebox (talk) 07:38, 28 December 2022 (UTC)

I agree, the new horrible TOC and the white spaces and width are the main problems of Vector 2022. But the complaints have been ignored by the developers. 37.161.248.115 09:34, 28 December 2022 (UTC)

Very strange position ... I don't think it takes a lot of efforts for developers two make TOC view optional (old / new TOC style at vector-2022) for users and for those who has wiki websites!!! Fokebox (talk) 10:43, 28 December 2022 (UTC)

I 1000% agree. I had to go back to the 2010 version of the skin just so I could navigate the page. This change is complete trash. This should have had a toggle to go back immediately. 24.42.211.97 22:47, 31 December 2022 (UTC)

Hey @Fokebox and other folks in this discussion: I just want to acknowledge that the requests for the old style of the table of contents have not been ignored. We've read and responded to all of these comments, and we've written extensive documentation as to why we think the current implementation is a better approach. I understand it is frustrating: you want a certain change made, you think your idea is better than what is currently implemented, and you think we are ignoring you. However in this case your opinion represents a very small minority. It's not that we're ignoring you, instead it's that we've gotten more positive feedback than negative feedback, plus the extensive consideration of the 12+ designers at the WMF, so we've concluded to stick with the current implementation. Thankfully MediaWiki software is configurable, so you still have options. AHollender (WMF) (talk) 15:55, 5 January 2023 (UTC)

"We've gotten more positive feedback than negative feedback". Where? On en.wiki a majority of users (165 vs 154) voted AGAINST Vector 2022, and many doubted the source and reliability of the data you presented in support on your choices. 37.161.68.229 15:59, 6 January 2023 (UTC)

That would be this round of community feedback: Reading/Web/Desktop Improvements/Third prototype testing/Feedback

Positive: 110, neutral: 38, negative: 23

You can read more here if you are interested: Reading/Web/Desktop Improvements/Features/Table of contents#Prototype testing with editors AHollender (WMF) (talk) 03:15, 11 January 2023 (UTC)

Also, your summary of the RfC is misleading in this context. Around 70% of the people who opposed Vector 2022 specifically opposed the limited width (which is now optional). Maybe 3 or 4 people objected to the table of contents. Every day, here and on Phabricator, we engage in fact-based conversations about the layout and various configurations/tradeoffs with community members, and are grateful for the engagement and feedback. If your goal is to make a case that the skin is poorly designed, and the WMF is not responsive to community feedback, I am confident you will not find evidence to support that. AHollender (WMF) (talk) 03:20, 11 January 2023 (UTC)

How is the limited width optional? I'm sincerely asking as someone who has tried for the last half hour to get rid of it (without having to make yet another account on another website). It's either bugged or unintuitive... 92.234.239.124 01:28, 24 January 2023 (UTC)

My Personal concern as a Mediawiki website owner. I do like new Vector style except the placement of TOC. And I do know that my website visitors also will be against of that. So that all I ask to make an option - to have new style TOC and have the old style TOC. Fokebox (talk) 09:26, 19 January 2023 (UTC)

I haven't tried the instructions, but this FAQ entry is entitled "How to restore the old table of contents". Jonesey95 (talk) 00:55, 11 January 2023 (UTC)

@Jonesey95: I tried by adding the script to my 2022 Vector javascript, but I saw no change in behaviour. I did not get the old TOC back. Jay (talk) 04:59, 19 January 2023 (UTC)

As I said, I haven't tried it. It looks like that text was added by SGrabarczuk (WMF), who is usually pretty good at communicating on talk pages. Jonesey95 (talk) 06:51, 19 January 2023 (UTC)

Hah, thanks :D So @Jay if it's not working now, then I'll try it out and ask my colleagues, developers at the team, to update the code. It will take a few days, though. In advance, I'd like to thank you for your patience! SGrabarczuk (WMF) (talk) 00:08, 20 January 2023 (UTC)

Has vector changed in the last 36 hours?

My window looks a lot different today than it did yesterday. His anything changed? Comfr (talk) 07:59, 26 December 2022 (UTC)

Hi @Comfr. None of us was working on Dec 26, so we couldn't answer quickly. We didn't make any changes back then either :) Has the look changed since then? SGrabarczuk (WMF) (talk) 21:56, 9 January 2023 (UTC)

Sticky header not working on many en.WP pages

I don't know if this is a new thing or not, or if it is just me or not, since I just started using Vector 2022 a week or two ago, and I have many customizations. When I go to any article on en.WP article and scroll down, the sticky header is visible. When I go to https://en.wikipedia.org/w/index.php?title=Special:Watchlist or https://en.wikipedia.org/wiki/User_talk:Jonesey95 and scroll down, the sticky header does not appear. I would expect the sticky header to work on all, or nearly all, pages. I looked through the list of phab requests and did not see a matching feature request or bug report. Using Firefox 108 for Mac OS. Jonesey95 (talk) 19:26, 27 December 2022 (UTC)

Hello @Jonesey95. Thanks for flagging this. You should be seeing the sticky header on the user talk pages - let's perhaps add ?safemode=1 to the URL and see if the header appears.

As for the special pages, our way of thinking has been that the goal for the sticky header is to provide access to functionalities like Edit, Talk, Watch, or History, and these happen not to be available on special pages. What do you think about that? SGrabarczuk (WMF) (talk) 21:54, 9 January 2023 (UTC)

I tried safemode, and the sticky header displayed on my User talk page. I then went back to my User talk page without safemode, and the sticky header still displayed. Hmm, maybe this was a temporary problem. Edited to add: I just went to https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Oregon?safemode=1 and I do not get a sticky header no matter what combination of reloading and scrolling I do.

As for Special pages like my Watchlist, it is still very useful to have access to links like my user page, my talk page, my contributions, and especially my notifications (which are coming to the sticky header at some point, I hope!) if I have scrolled partway down a page. One of the potentially nice things about Vector 2022's sticky header is that it could compensate for the addition, over the years, of various bits and bobs (options, notices, buttons, white space) to the top of the Watchlist page that have made it so that my actual watchlist starts halfway down my screen. If I could see my notifications *and* most of my watchlist at the same time, that would be excellent. Jonesey95 (talk) 02:27, 10 January 2023 (UTC)

I just saw the note at Reading/Web/Desktop Improvements/Features/Sticky Header saying that the sticky header is limited to just a few namespaces. Is there a phab ticket where people are working on expanding that population of pages, or a design document explaining the reasoning behind these limits? I was just on a Template Talk page, for example, where the sticky header would have been very useful (e.g. to click the "Add Topic" button, or remove the page from my Watchlist, or go to my Contributions, or see my notifications). I would like to see it on pages in all namespaces. How can I do that, at least for myself? Jonesey95 (talk) 01:39, 20 January 2023 (UTC)

Section [edit] button disappears

Seemingly at random, the [edit]-this-section button does not appear when page is opened (like, disappears between sessions). Recently from en:User:DePiep/current; while at the same time in mainspace articles it is present (=OK). Purge did not solve it, but sometimes it reappears (by unknown action), later in a session. DePiep (talk) 09:05, 28 December 2022 (UTC)

@DePiep: thank you for making us aware of this issue. I too am NOT seeing [edit] links appearing after the H2 level section headings on User:DePiep/current...are you able to share links to pages where you are experiencing this issue [i]?

---

i. To be doubly certain we're on the same page, I understand the issue you're experiencing as follows: at random (seemingly), [ edit ] links are NOT appearing next to H2 level section headings (read: == H2 ==). PPelberg (WMF) (talk) 00:56, 7 January 2023 (UTC)

Yes, as you describe. "No [edit] button in h2 header line, in certain pages/situations". I add A: my "it reappears" remark may be incorrect (no proof of truly being time-related). Add B: same bad behaviour in lower headers (h3, h4). add C: hypothesis: cold be caused by actualy page content (templates?).

Pages that do show this behaviour:

• en:User:DePiep/current/test-2023

Pages that do not show this behaviour (that is: show & behave as expected wrt this):

• en:User:DePiep/chembox/test-2023

note: linter errors on the faulty page (<i> unbalanced). I will have to remove them first.

@PPelberg (WMF): ; I'm sorry for delaying this reply. I hope to be able do some more tests shortly (like, test by page content).

-DePiep (talk) 07:04, 16 January 2023 (UTC)

Both test-pages now ''without'' linter messages.

To be clear:

en:User:DePiep/chembox/test-2023 is OK, shows [edit] links per sectionheader as expected. h2, h3 levels.

:en:User:DePiep/chembox/test-2023 is buggy: hides [edit] links (expected in section headers).

Important note: this same report is valid when working in Vector 2010 (old skin). In other words: bug appears the same. DePiep (talk) 18:08, 22 January 2023 (UTC)

@PPelberg (WMF) @DePiep searching in en:User:DePiep/current/test-2023 with CTRL+F, the number of {{ is not the same number of }}. See Section edit links disappear following an unclosed {{. 37.103.49.5 17:03, 25 January 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? {{u|Sdkb}} ^talk 22:36, 9 January 2023 (UTC)

Sdkb, 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. {{u|Sdkb}} ^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 ?useskin=vector-2022 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. {{u|Sdkb}} ^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. {{u|Sdkb}} ^talk 16:32, 16 January 2023 (UTC)

General feedback from a multiple portrait monitor power user

I'm one of those long-term editors who has never switched from Monobook. I groused about one of the new skin preview efforts not long ago, when comments were solicited, but this edition of Vector I mostly like. I mainly view Wikipedia on 23" monitors in portrait mode, with the window full-screened. The old-fashioned embedded TOC is not a problem with this much vertical real estate. The new TOC is kind of nice in some ways, but for me, I always want it fully expanded. It's a quick way to judge the complexity of the article. There's also too much "air" in the new TOC, it wraps longer section titles (ugh), and I lose the birds' eye view.

My second problem mainly concerns use of my landscape screen. As I increase the font size on my wide screen, the page switches off the navigation side bar before I have the large font size I desire, and now the text lines are too long for comfortable reading (100 characters is nutty), and I've lost visible navigation. (The inline TOC does not reappear.) I sit further away from my screens than most people. Perhaps because I have three, perhaps because it reduces back pain. At certain sizings on my landscape screen, I get a TOC too narrow to give me a proper overview, while simultaneously the text beside the TOC has lines too long for me to comfortably read. Probably all that can be hand customized in the CSS or somewhere, if I cared enough about Vector to make it work.

The third problem seems to be a paper cut. On my portrait screen, with larger font sizes, the search bar disappears, even when room remains to fit a short one. Commonly the search bar is a target for drag and drop from an article I'm reading on another screen. More than half the time my right screen is open to Wikipedia. I'm reading on my middle screen, I see an unfamiliar term (e.g. the German tank type "Marder") and I reflexively double-click to word select, then grab the word to drop on the Wikipedia search bar on my right screen—but wait!—that control is stupidly excised because the nanny state thought that a search bar too small would — what exactly? ... cause brain problems in the common user?

Even a small target for drag and drop would permit this interaction to work seamlessly, and the search bar could pop into large mode on a responsive basis to having text input (by keyboard or by drag and drop). I like drag because it doesn't interfere with my clipboard. I have a spectacularly powerful clipboard manager, but not because I want to drive it all day to recover recent items. Even no visible search bar target would work, if it responded to text drop events as if it were really there (where it ought to be anyway, so far as I'm concerned). Make that region automatically expand the search bar—if concealed—on drag hover! Also, if you're going to leave that dotted hamburger hovering over my page all the time anyway, why can't it serve as a drop target for search text?

The search interaction could pop up in place of the TOC sidebar when activated in this way, and people wouldn't have to loose their place running to the top of the page to conduct a search query. I actually use the search bar's auto suggestion mode quite often, to explore possible resolutions, without any intent to visit a searched term. When I'm using search in that way, I'd highly prefer not to lose my place in the current article. Just now I typed "Marder" in the search bar on my old Monobook skin. The list of suggestions pops up rapidly. The second one says "Marder (infantry fighting vehicle)" and I'm done. Because I was trying to remember whether it was a real tank, or just a tankino (it's the latter). Why do we only give the Ukrainians tankinos? But so it goes.

I briefly wondered if the new design was clever enough to detect alt-shift-f to bring up a floating search control over top of my current page position. But in my test page for Vector, alt-shift-f now does nothing at all. Wow. That's a step backwards if I've ever seen one. I have to say, I frequently don't understand the priorities of today's design generation.

Sigh. Monobook is far from perfect, but there's nothing so wrong with it that I need these new hassles. Reverted to Monobook. Again. And, most likely, not for the last time, given general trends in design priority. MaxEnt (talk) 21:45, 13 January 2023 (UTC)

Hey @MaxEnt, to clarify one point: when pressing alt+shift+F are you expecting the brower's Find in page function to appear? If so, for me that appears just with alt+F (and also is outside of the control of the website). I'm not seeing anything appear in Monobook or Legacy Vector with alt+shift+F.

Interesting workflow regarding dragging a word into the search box — I've never heard of that before (also I can't figure out how to do it, how do you drag the word without it becoming unselected?).

We are working to keep the search bar visible at more narrow screen widths, so that should improve in time. We're also looking into zooming, and increasing the font-size via browser settings, to make sure all of that works as well as it possibly can.

The skin definitely has a ways to go, but from feedback, data, research, etc. it seems to be substantially better than Legacy Vector to warrant the switch over. AHollender (WMF) (talk) 15:06, 16 January 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)

Not showing interlanguage links for other Namespaces

(image 1) Shows no interlanguage links

(image 2) Shows 186 interlanguage links available

(image 3) But, Shows no interlanguage links

• This issue is noticed in Tewiki
• This is noticed in Vector 2022 skin only. There was no problem in default Vector skin
• This is noticed in Template, Help, Wikipedia and Module Namespaces. Not noticed in Main namespace. Not checked for other namespaces.
• This problem appeared on 14 Jan 2023
• This problem is observed on Windows 11, Chrome 109. Not checked in any other environment.

The interlanguage links are not shown. When clicked the languages drop down, it shows the message "Page contents not supported in other languages." See image 1 When the page is scrolled down, the sticky link shows "so many languages" (e.g. 186 languages) See image 2 When the link is clicked the drop down shows - "No languages yet No languages are available for now" See image 3 Chaduvari (talk) 15:29, 15 January 2023 (UTC)

[EDITED] Hey, this is expected. Please see an unintended consequence of https://phabricator.wikimedia.org/T316559. For more information please see the task linked in the comment below. Our apologies for this inconvenience. AHollender (WMF) (talk) 14:09, 16 January 2023 (UTC)

@AHollender (WMF): Expected??? The quoted ticket mentions the simplification of messages only for pages that that should not be associated with interlanguages links, e.g. talk pages. Meanwhile, in vector-2022 you turned off the visibility of links in all namespaces except main(!), which was considered a very serious bug and is "patched" in emergency mode (see: https://phabricator.wikimedia.org/T326788). Zdzislaw (talk) 18:06, 16 January 2023 (UTC)

@Zdzislaw, @AHollender (WMF)- Great, it is working now. Thanks for fixing it. __ Chaduvari (talk) 07:02, 17 January 2023 (UTC)

Issue with User menu drop down

This is noticed in Tewiki.

• With the page scrolled down, when the User menu is accessed, the drop down list does not show the "purge" link. I suppose it is a deliberate feature.
• But when the page is scrolled up to the top, and when the User menu drop down is pressed, the drop down does not appear. In stead, the User Talk page appears.
• After going back, the drop down works normally.

This has been there ever since I started using the skin in October 2022. Sorry if I am repeating an old, well reported issue. __Chaduvari (talk) 07:23, 16 January 2023 (UTC)

Hey, thanks for reporting this. Would it be possible for you to include screenshots of this issue? I am not sure I am entirely clear on what is happening. AHollender (WMF) (talk) 14:08, 16 January 2023 (UTC)

Fig 1 - Tool tip shows User menu and the menu list is shown

Fig 2 - Tool tip shows "your talk page". When clicked, it takes me directly to my talk page, instead of showing the drop down menu items list.

Sorry for not being clear about the issue. The issue is -

• When I scroll down a page, the "User menu" (In Telugu it is "వాడుకరి మెనూ") drop down list shows underlying links normally. See Fig 1.
• Then I scroll up the page to the top. Now, this drop down's toll tip shows "Your talk page" (In Telugu it is "మీ చర్చా పేజీ"). When it is clicked, I expected to see the drop down list items. instead, it takes me to my User talk page. See Fig 2
• When I come back or when I refresh the previous page, then its tool tip shows the usual "User menu" (In Telugu it is "వాడుకరి మెనూ"), and on-click it shows the drop down list.
• this is noticed in Windows 11 and Chrome 109. Not checked in other environments.

I hope I am clear now. Thanks. __Chaduvari (talk) 06:59, 17 January 2023 (UTC)

Chiming in to mention that it's been happening to me too. TerraCodes (talk) 09:24, 19 January 2023 (UTC)

Ended up debugging this since I found a thing about it while doing something else. It seems that if you scroll down and open the sticky nav user dropdown, and then scroll back up so the sticky nav disappears without closing the sticky nav user dropdown, the sticky nav user dropdown still is open, but invisible. If you scroll back down you can see the sticky nav user dropdown still open. Closing it "fixes" the issue, but this should be properly fixed in the codebase. TerraCodes (talk) 09:57, 19 January 2023 (UTC)

Thanks, @TerraCodes. Understood the issue now. Will wait for the proper fix.__ Chaduvari (talk) 07:42, 21 January 2023 (UTC)

Repeating an old, pending issue

Please look into an important issue at Tewiki, which was reported here on Oct 2, 2022. Posting it again here, just to ensure that it wont get buried in archives. Sorry for that. __ Chaduvari (talk) 07:31, 16 January 2023 (UTC)

@Chaduvari thanks for the reminder. I've created a task on Phabricator (T327070) and have tagged several members of the Codex team, who we have been collaborating with on the search feature. I am hoping they will be able to provide a solution. AHollender (WMF) (talk) 14:07, 16 January 2023 (UTC)

Further release plans

Very cool that English-language WP will switch this week! I was wondering if there already are concrete plans on how to make Vector 2022 default in even more language versions. I see that you write We hope to get to all the Wikipedias by the end of February 2023, but at least on dewiki I have not had the impression that there was much communication and discussion about it so far. It would be difficult to reach a community consensus in such a short time. Or are further switches delayed until the page tools update is ready? Would be nice to have some more input, I just started an initial discussion on de:Wikipedia:Technik/Werkstatt #Einführung Vector 2022. XanonymusX (talk) 19:16, 16 January 2023 (UTC)

Thanks @XanonymusX for your interest in this project. That's a good question. Right now, we're focusing on the deployment on English Wikipedia (apart from handling bugs and deploying the page tools). I'm grateful that you've initiated the discussion on the Werkstatt. It looks very good!

That said, we aren't able to be talking to two large communities at the same time. After some (hopefully short) time following the deployment on English Wikipedia, we will form a plan for the German-language community and reach out to this group. Definitely, we don't want to rush or confuse people.

In principle, though, is the skin stable and mature enough? Yes. We believe that if it's ready for deployment on English (and it is) it's also ready for German. Is the deployment on English Wikipedia a game-changer in terms of the gadgets and user scripts? Will the deployment on English make it significantly better? No, not really, because the technical English-speaking community has been familiar with the skin for a long time. A large portion of volunteer-maintained code was adjusted long ago. But who knows, perhaps something on dewiki still needs to be updated.

So... before we focus on German, we will continue running banners there, incentivizing people to opt-in individually. In parallel, you're most welcome to advocate for it wherever you deem appropriate. Writing on the Werkstatt was a great move!

Thanks, SGrabarczuk (WMF) (talk) 03:32, 17 January 2023 (UTC)

Thanks, sounds good! My feeling says that waiting for the page tools might be a good idea, so I’ll be following that development closely. For now, we will prepare the info pages on dewiki. The post on Diff tomorrow will also be in German, so sharing that one might help increase awareness. Success with deployment, looking forward to it! XanonymusX (talk) 10:07, 17 January 2023 (UTC)

In any case, we have de:Hilfe:Skin/Vector 2022 now, will try to keep it up-to-date! XanonymusX (talk) 17:41, 17 January 2023 (UTC)

Vector 2022

Wäre es möglich, die wirklich nervige Bannerwerbung für diese misslungene Oberfläche dauerhaft einzustellen? Ich glaube gerne, dass es Nutzer gibt, für die Schmiertelefone und Hochformat das Einzig Wahre sind. Für die gibt es aber schon die Mobilansicht. Was soll es bringen, allen anderen, die klassische Rechner mit üblicherweise im Querformat stehenden Monitoren benutzen, mit einem zusätzlichen weißen Streifen auf der rechten Seite zu nerven? Wer den Humbug möchte, der hat ihn. Wer ihn nicht will (und eher springe ich aus dem Fenster), der will ihn nicht und sollte der Schwachsinn mit Gewalt durchgedrückt werden, dann bin ich weg.

Bitte, macht damit Schluss. Als Option kann diese Ansicht gerne weiterbestehen, aber nicht als Voreinstellung. Schon, dass man das Anmeldemenü erst suchen muss, ist ein Schuss in den Ofen. Der Kram ist ein Fall von »gewollt und nicht gekonnt«. Das Versprechen, dass das Banner nur alle sieben Tage auftaucht, hat nie funktioniert. Zumindest bei mir werden die Cookies beim Schließen jedes Browsers gelöscht – und das ist nicht verhandelbar. Es gibt schon viel zu viele Schnüffler und in dieser Reihe möchte ich Wikimedia nicht sehen. –Falk2 (talk) 23:05, 16 January 2023 (UTC)

Die Banner werden naturgemäß so lange laufen, bis die Oberfläche Standard ist. Wie wir eins weiter oben gerade besprechen, wird das für deWP demnächst angegangen, dauert aber sicher noch. Interessant finde ich, dass ich gefühlt noch nie ein solches Banner gesehen habe, aber das wird wohl daran liegen, dass ich den alten Vector schon lange nicht mehr verwende. Du kannst Banner übrigens generell in den Einstellungen deaktivieren (auch nach Typ). Gruß XanonymusX (talk) 10:02, 17 January 2023 (UTC)

addPortletLink

Hey! Function addPortletLink loses .vector-tab-noicon class in Vector 2022. Am I doing something wrong - ru:Участник:Iniquity/related-js-css-links.js? Iniquity (talk) 20:56, 17 January 2023 (UTC)

Hi @Iniquity, sorry for the delay, we are receiving a lot of feedback and it's hard to answer to all in a short time. I reported your message to the team, I hope this should help. Patafisik (WMF) (talk) 09:20, 25 January 2023 (UTC)

@Patafisik, thanks! :) Iniquity (talk) 11:01, 25 January 2023 (UTC)

We'll look at this as part of https://phabricator.wikimedia.org/T327369 (a few other issues are being reported). Jdlrobson (talk) 16:24, 31 January 2023 (UTC)

@Jdlrobson, thanks :) Iniquity (talk) 21:21, 31 January 2023 (UTC)

Watchlist icon duplication request

At the English Wikipedia, when I have scrolled down the page, the stand-alone "go to watchlist" (GTW) icon disappears, and is to be found under the silhouette icon. Observing my own behavior, I'm scrolled-down far more often than I'm at the top, and so I've quickly become accustomed to clicking 'silhouette → GTW icon'. However, this frequency is training me to—by default—reach for the silhouette to find my GTW icon, and that isn't the case when I'm atop a page. Does that make sense? Placement of the GTW icon is inconsistent and dependent on editors' location on a page, and I find myself wasting time due to the skin training me to expect the icon in one place, but only some of the time.

Can we either (a) stick with one implementation or the other all the time, or (b) put the GTW icon in both places all the time to accommodate all editors? Thanks for listening, Fourthords (talk) 22:13, 17 January 2023 (UTC)

Looks like it's already in the page (as it seems that the skin hide/shows based on screen width) so you could hide the one outside the dropdown and show the one in the dropdown, as I'm planning on doing. TerraCodes (talk) 09:34, 19 January 2023 (UTC)

Hi @Fourthords: thank you for your comment, it is an interesting suggestion. Let me give you more context: the sticky header is showing in a single bar some links that originally are distributed in 3 different menus/bars at the top of the page, so there is not the place for all, considering also narrow screens, and a choice was needed. At the beginning of the project, the watchlist button was inside the User menu, and it was at the same place at the top of the page and in the sticky header. There was consistency. Actual situation is a trade off: early adopters wikis strongly supported for a watchlist icon outside the User menu, there was a discussion about simplicity vs. intensive use reasons. Do you know that you can also use a shortcut to open your watchlist?--Patafisik (WMF) (talk) 17:42, 23 January 2023 (UTC)

So you're saying that, when scrolled-down, there isn't room for the GTW icon in the floating horizontal bar, and that's why it's tucked inside the silhouette? That behavior changes when atop the article because feedback early-adopters wanted a stand-alone GTW icon? If I'm understanding correctly, that inconsistency is frustrating and doesn't preclude including (duplicating) the GTW icon inside the silhouette menu when atop any given page. Does that make sense? Fourthords (talk) 13:59, 24 January 2023 (UTC)

Typographie des sous-sections

Bonjour,

Comme on peut le constater sur n'importe quelle page du Wikipédia français, les sections apparaissent visuellement comme en « Times New Roman 16 » alors que les sous-sections ressemblent à de l'« Arial 12 Bold ». Dès lors, bien que d'une taille soit petite, cette dernière attire davantage l’œil car elle est en gras (voir n'importe quelle page comme celle-ci avec le paragraphe « Systématique » et le sous-paragraphe « Publication originale »). Il serait sans doute bon de corriger cela pour avoir une mise en valeur plus claire de la hiérarchisation des paragraphes.

D'avance merci.

Givet (talk) 08:16, 18 January 2023 (UTC)

Bonjour @Givet, cela apparemment n'est pas dû à Vector 2022, il se produit aussi avec d'autres habillages. Cette page de discussion est dédiée au projet des améliorations du bureau qui s'occupe de Vector 2022, avez-vous demandé au Questions techniques ? Patafisik (WMF) (talk) 15:24, 18 January 2023 (UTC)

Non, en fait je ne sais pas très bien à qui m'adresser. Peux-tu le faire pour moi ou veux-tu que je transfère ma demande ? En tout cas merci pour ta réponse. Givet (talk) 15:32, 18 January 2023 (UTC)

@Givet J'ai vu qu'il y a une discussion en cours au Bistro par rapport à la police des sous-sections où des pistes sont données. Aujourd'hui se passe le deployment sur la Wikipédia en anglais de la nouvelle interface, donc à mon avis il y aura moins de monde pour répondre à cette question dans les prochaines heures hors frwiki. Patafisik (WMF) (talk) 15:34, 18 January 2023 (UTC)

Oui, c'est moi qui est lancé cette discussion, mais pour être franc cela fait des lustres que ça me gène. Alors on peut attendre un peu, pas de souci. Encore merci, je reviendrai plus tard. Bonne soirée :-) 2A01:CB05:83ED:8500:1590:B514:5B26:56D7 15:39, 18 January 2023 (UTC)

Désolé je venais de me déconnecter... C'est bien moi qui est rédigé le commentaire ci-dessus. Givet (talk) 15:40, 18 January 2023 (UTC)

@Givet pas de soucis. :) Comme disait TomT0m vous pouvez déjà lancer une nouvelle discussion au Bistro pour voir si d'autres wikipédiens sont d'accord pour modifier le MediaWiki:common.css global. Mais à mon avis avant vous pourriez en discuter au projet Charte graphique. N'oubliez pas que tout changement devrait prendre en compte l'accessibilité, voir par ici. Bien cordialement, Patafisik (WMF) (talk) 15:51, 18 January 2023 (UTC)

Table borders

It looks like the new skin has affected the borders on some tables. More specifically, the toccolours class no longer has borders:

{| class="toccolours"
| col1
| col2
|}

generates:

col1

col2

Is this a known change and intended? Pbrks (talk) 15:49, 18 January 2023 (UTC)

Hi @Pbrks, thank you for your report. Can you give us screenshot, please? Patafisik (WMF) (talk) 17:14, 18 January 2023 (UTC)

That is phab:T314254, yes. XanonymusX (talk) 17:59, 19 January 2023 (UTC)

Vector 2022

This skin is horrible, it reduces the horizontal display space for the article quite considerably which leads to a lot of sandwiching and will make articles difficult to read on mobile devices. Murgatroyd49 (talk) 16:38, 18 January 2023 (UTC)

I associate myself with these comments. Strange choices were made in developing this. Spelf (talk) 17:02, 18 January 2023 (UTC)

Hi @Murgatroyd49 and Spelf: thank you for your feedback. The Web Team has been working on Vector 2022 for 3 years, identifying problems through research with both readers and editors, and building and testing prototypes with communities. These changes are created specifically for desktop interfaces. All research and testing done for this project has been focused on desktop users only. We have, however, considered the experiences of people who use desktop in narrower screens (for example, if you have two tabs open side by side). For further information please look at this FAQ. --Patafisik (WMF) (talk) 17:47, 18 January 2023 (UTC)

Thanks for the response, for the record, I still don't like but that's my problem! Murgatroyd49 (talk) 17:49, 18 January 2023 (UTC)

I support the original post. The narrow text is horrible to look at on a desktop browser too. The full width text should be the default and the narrow text should be an option. This is a reading-heavy website and we need to see much content on our display. The old Vector skin got it right, but the new Vector 2022 fails with this task. Full width text was nice, bring it back for us. The location of the 'full width text' button is very poor and some browsers on desktop do not show the button at all. The 'full width text' button needs better placement, this function will be very important for a lot of readers! 94.26.15.134 19:53, 18 January 2023 (UTC)

I agree; the narrow width and wasted white space is very inefficient and makes it hard to read. I've reverted back to the 2010 theme. Steepleman (talk) 23:47, 18 January 2023 (UTC)

Found more problems; it breaks the div col template, leading to more unnecessary white space. Articles that have images etc alongside the menu box, see List of watermills in the United Kingdom, are now badly broken. On my tablet I still get a mixture of old and new skins depending on what article I look at. Murgatroyd49 (talk) 11:10, 19 January 2023 (UTC)

I can confirm that this bug about mixed old and new skins happens on the desktop version of Wikipedia too. With Vector 2022 active, I can see some articles show with the old skin and other articles show with the new skin. Also the table of contents is weird and random-some articles show the new style but others have no TOC anymore. This whole Vector 2022 skin feels rushed, less polished and unfinished. There are weird things about the language selection button too-it shows two different language lists if you click on it two times. 94.26.15.134 21:38, 20 January 2023 (UTC)

....

Awful decision to force this as default for me with no warning. Awful. I have a 2k monitor, I don't need this sandwiching bullshit. 24.235.56.110 16:40, 18 January 2023 (UTC)

Hi @24.235.56.110, I understand you fell frustrated. We have communicated a lot with the community, discussed and made changes only after a RfC. Please look at our FAQ and consider to personalize your experience restoring the full width. We have built a toggle for logged-in and logged-out users. The toggle is available on every page if the monitor is 1600 pixels or wider. Selecting the toggle increases the width of the page. Patafisik (WMF) (talk) 17:32, 18 January 2023 (UTC)

Where is this toggle? I can't find it, and why only 1600 pixels and wider? Why not just add a toggle that turns off the new layout completely: For all users even without an account? 172.58.174.193 18:28, 18 January 2023 (UTC)

I too can confirm that the visibility and placement of this toggle is very poor. 94.26.15.134 20:00, 18 January 2023 (UTC)

Can I get a direct link to the RFC? Not really sure where to find it. Skarmory (talk) 03:35, 19 January 2023 (UTC)

The RFC was at en:Wikipedia:Requests for comment/Deployment of Vector (2022), where opposition to the excessive white space was overwhelming. Jonesey95 (talk) 06:29, 19 January 2023 (UTC)

It is really wild to me, after reading that RfC, that this mess was pushed through anyway. Even the majority of people who knew about this upcoming change disliked it! How did you expect regular users to react?? Protospork (talk) 02:26, 20 January 2023 (UTC)

I mean, c'mon, surely you've got the data to know that most users would never see an RfC on anything? Most people just read Wikipedia. Heck I've got an account, I've even donated (you're welcome Jimmy!), & I didn't know about this mobile-style junk until it hit me in the face. WizWorldLIVE (talk) 09:35, 20 January 2023 (UTC)

Not the original poster here but this toggle thing is incredibly annoying. First - why default to a narrow view when I've got a wide desktop window (something easily detectable in JS). Second it doesn't save that setting so I have to re-click that thing on every page, which is just infuriating. Third, it still wastes a considerable amount of horizontal space on the left side. (Screenshot: [1]) Seriously, look at that screenshot. Does anyone honestly think that looks good? Not only is the functionality poor, it wastes space and simply looks bad. It looks amateurish and poorly thought-out. Likely because it is. 90.235.20.154 19:31, 20 January 2023 (UTC)

I know this toggle was mentioned a few times, but I can't trigger it on my 1600px laptop screen (ff/chrome, mac) or my ~2500px external monitor. Can someone share a screenshot showing where it appears?

I also see the "switch to old look" sidebar link still takes you to a two-click + one-scroll interface that doesn't return you to the page you were on, which I thought was going to be changed? cf, T327465.

disgusting

it is stupid as shit, incredibly boneheaded to make such a change to core page ui. making me make an account to restore functionality is driving a nail into my skull and telling me i get grab a hammer to pull it out. everybody involved in the decision to push this to people who didn't ask for it and didn't want it should be ashamed and should never be allowed to make decisions affecting other people ever again. 76.174.240.67 17:00, 18 January 2023 (UTC)

Wow. Absolutely describes my sentiment. Hope they don't just remove your topic just because it uses slur words. This new layout is absolutely disgusting—and to force it on non logged-in users instead of making it an option? Incredibly stupid and unthoughtful 172.58.174.193 18:24, 18 January 2023 (UTC)

In my couple of years of experience on Wikipedia, I have never seen a topic removed for just having swears in it. Given this isn't a personal attack, I would be very confused if it got removed. Skarmory (talk) 20:19, 19 January 2023 (UTC)

Space unutilization

With the new look, there is lot of empty space at the left and right sides of the page. All content is restricted to the middle, and this may be suitable for mobile devices. What should I do to let the content span the entire width of the page for desktop usage? Jay (talk) 17:11, 18 January 2023 (UTC)

Oh never mind! I found the toggle button on the right side bottom corner. Jay (talk) 17:15, 18 January 2023 (UTC)

Hi @Jay, thank you for your feedback. Please look at our FAQ, yes, you can personalize it. Patafisik (WMF) (talk) 17:16, 18 January 2023 (UTC)

And I'm now able to fold the left frame also. This is awesome! Jay (talk) 17:21, 18 January 2023 (UTC)

Not pixel aligned, leading to grayscale text rendering/fuzzy text on Windows Chrome

Hi, when the content does not take up the full width (e.g. with sidebar) there must be an element that is not pixel aligned. On a 1x Windows display with Chrome, this causes the text to appear fuzzy, rendered using grayscale antialiasing: https://i.imgur.com/Yju4XKA.png

The old version of wikipedia, and also the resized version removing the sidebar does not exhibit this problem, and is correctly rendered using subpixels, looking much crisper. Zebracanevra (talk) 17:12, 18 January 2023 (UTC)

Hi @Zebracanevra thank you for reporting this. Can you confirm me if your problem is described in this task? Patafisik (WMF) (talk) 17:19, 18 January 2023 (UTC)

Hah I've been encountering that bug for a while now, happens on Youtube as well. It could be related, though I don't think it is the same issue.

Maybe if the Chrome team fixes the bug in that task it will resolve my issue.

I believe the GPU rendering in Chrome Windows uses grayscale AA and otherwise it uses subpixel AA, and using some CSS properties/widths can induce Chrome to render using the GPU. See for example any page on Cloudflare's Docs, where if you open a dropdown, they use "will-change", hinting to use the GPU: https://i.imgur.com/ut0sTo5.png same result. Zebracanevra (talk) 17:41, 18 January 2023 (UTC)

Maybe just ignore everything I said about the cause being "pixel aligned". Maybe I don't know what I am talking about.

I do have a fix for what I am seeing, though:

Removing the position property from .vector-body { position: relative; } makes Chrome want to do subpixel rendering for the body. Zebracanevra (talk) 17:55, 18 January 2023 (UTC)

TOC level

Earlier the TOC at en:Wikipedia:Redirects_for_discussion#Current_list used to show only the dates and not every discussion for that day. Now it is showing all, which will go to hundreds and is not practical. I want to see only the dates like before. How can I make the TOC show the top-level heading only, and not all of them? Jay (talk) 17:32, 18 January 2023 (UTC)

The TOC needs to have the same width of the main content, or at least 50% of the main content. Having it as a sidebar which is narrow makes it hard to use. Can I have the TOC permanently as part of the main content? Jay (talk) 18:08, 18 January 2023 (UTC)

@Jay - one thing that might help with this is collapsing the ToC, then opening it using the button on the left side of the title. This allows it to show as an overlay which gives more space for the ToC on pages or namespaces where headings are generally longer. Hope this is helpful! OVasileva (WMF) (talk) 19:06, 18 January 2023 (UTC)

@OVasileva (WMF): If I may interject, it seems the primary issue is that the ToC only collapses top-level headings (marked with == title ==), but not lower level headings (marked with === title === and so on). On the linked page, when "Current list" is uncollapsed in the ToC, all of its subheadings are displayed—not just the subheadings directly beneath it in the hierarchy. I think it would be ideal if every heading with any subheadings (even if it's a subheading itself) could be collapsed/uncollapsed in the ToC display. Shells-shells (talk) 20:04, 18 January 2023 (UTC)

@OVasileva (WMF): I collapsed the TOC (by clicking Hide), clicked the (TOC) button on the left side of the title, and it is still the same as I observed before. It shows ALL the discussions from all the dates. So this did not help. Jay (talk) 04:53, 19 January 2023 (UTC)

I see that your suggestion was for my spacing concern. Yes, for that, it helps. Thanks! Jay (talk) 04:57, 19 January 2023 (UTC)

I also tried How to restore the old table of contents by adding the script to my Vector 2022 javascript, and there is no change in behaviour. I did not get the old TOC back. Jay (talk) 04:53, 19 January 2023 (UTC)

VPN Users Handicapped

As someone who reads wikipedia and its sister projects with a VPN and without an account, I have no way to revert back to the old legacy layout. The new layout is absolutely terrible especially since I am a desktop user with a wide monitor. I have no plans to ever use the 2022 vector layout as it just looks like the mobile layout which I also hate. Can you make it so that you can change the skin for your IP, so even if you don't have cookies enabled you can still have preferences? 172.58.174.193 18:22, 18 January 2023 (UTC)

Hello. Maybe this little trick can help you: simply add «?useskin=vector» to every requested URL. It works for non-logged users. 37.134.90.176 09:14, 23 January 2023 (UTC)

Make the text fit the page

I haven't read anything and I shouldn't need to. There is no justification for not making the articles take up the whole page width on desktop.

Make the pages fit, get rid of these ridiculous side margins. VanillaSeagull (talk) 18:27, 18 January 2023 (UTC)

Or maybe just stop making it the default layout entirely. The whole thing seems like an excuse for their design team to have done something significant to the site. 172.58.174.193 18:30, 18 January 2023 (UTC)

I definitely agree. I don't see any practical use to making a rather wide portion of space on each side of the page always empty. It's ultimately wasted space -- what does it add? What benefit is there is having a large chunk of every page contain no content of any sort? The text should be full-page again, it's just efficient use of page space. Theriocephalus (talk) 19:54, 18 January 2023 (UTC)

Even when switching to full-width mode (either via the toggle at the bottom right or via user preferences) the layout is wasteful.

Can the grid column width for the sticky ToC be reduced to min-content and the extra padding added by the @media screen directives be removed when full-width mode has been requested? A user that doesn't want wasteful whitespace doesn't want wasteful whitespace. Growfybruce (talk) 03:29, 19 January 2023 (UTC)

A user setting to default the ToC to hidden would be nice too. Growfybruce (talk) 03:33, 19 January 2023 (UTC)

I've decided that I like Vector 2022 right up until you reach 1000px wide. If the designers had just walked away and not dicked around with forcing their smartarse ideas on people whose browser widths they disagree with, it probably would have been fine. Growfybruce (talk) 23:27, 19 January 2023 (UTC)

On that same note, it also hides a ton of menus behind drop down menus. That's fine for most people, but if you edit on wikipedia, it's super annoying to have to open more menus when you used to just have to click a button UpdateWindows (talk) 03:39, 19 January 2023 (UTC)

Blurry text after scrolling down on Microsoft edge

After the new skin went live I noticed that pages started becoming blurry for a second before fixing themselves. The effect only comes again if the page is reloaded with Ctrl + F5 though. I'm not experienced enough in web design to know what the problem might actually be though. The effect is not present on the old vector skin. The problem can be seen here https://imgur.com/a/WvAJdlu Carvor (talk) 18:31, 18 January 2023 (UTC)

Hi @Carvor - thanks for your question. This is an upstream issue with the Chromium browser (which Microsoft edge uses). We've reached out to the Chromium team and they're currently working on a fix. Progress can be tracked here. OVasileva (WMF) (talk) 19:00, 18 January 2023 (UTC)

Missing links in diff blogpost

Reported an issue on page https://meta.wikimedia.org/wiki/Talk:Diff_(blog)#Missing_links_in_diff_blogpost_about_new_skin 185.79.217.61 18:32, 18 January 2023 (UTC)

Thanks for your question! The section on that page is for learning more about the project through our blog posts. Above that section, you will see links to the mediawiki project page and this talk page for leaving general feedback. OVasileva (WMF) (talk) 19:08, 18 January 2023 (UTC)

Vector 2022 seems to be using legacy custom CSS file

A warning that people who are using custom CSS for legacy Vector may get that legacy CSS when they are automatically switched to Vector 2022 which can seriously break the page UI. When I went to Wikipedia earlier today, I had a broken UI, links and menus not showing or working, no TOC, etc, because Vector 2022 seemed to still be using Legacy Vector user custom CSS instead of its own user custom CSS. It took a while to figure out a way to interact with Wikipedia so I could switch back to Legacy and make Wikipedia usable. Others with custom CSS may be experiencing this same problem. If you switch people to the new Vector 2022, it should not use the old custom CSS at all for this reason (their old CSS may break their UI under the new 2022 layout). For just a visual example of Legacy vs 2022 with a Legacy custom CSS : Screencaps for comparison (lack of links/menus not working obviously not depicted).
Imeriki al-Shimoni (talk) 18:38, 18 January 2023 (UTC)

Tracked in phab:T301212. Jdlrobson (talk) 22:24, 18 January 2023 (UTC)

List articles with photographs are broken

Noticed this mostly on List of Manchester United F.C. players. The photos are on top of the table with the list below, instead of the photographs beside the table. It's odd, because on other articles, the photos can be beside the list. I'm trying to figure out how to fix it on this article. MAINEiac4434 (talk) 18:44, 18 January 2023 (UTC)

Okay, it works when I toggle the wider layout, but it should also work the default layout as well.MAINEiac4434 (talk) 18:46, 18 January 2023 (UTC)

That is a very wide table. If you want those photos to appear alongside the table for all readers, you may need to wrap the larger table in a second table, where the existing table is in one cell of the only row and the photos are in a second cell. This may not be a good idea, however. Jonesey95 (talk) 05:59, 26 January 2023 (UTC)

ToC [hide] toggle state not saved

Tracked in Phabricator
Task T316060

I have had a mostly unobjectionable Vector 2022 experience for several months now. One issue I've noticed is that the toggle state of the table of contents (whether it's hidden next to the page title or displayed in the sidebar) is not saved over page changes or even page reloads. Its state should, I think, be saved just like the collapsed/uncollapsed state of the sidebar controlled by the top left hamburger button. Shells-shells (talk) 19:06, 18 January 2023 (UTC)

Thanks @Shells-shells for your question! This is coming up soon. Adding this persistence is on our list for updates to the new skin. First, we are planning on adding an indicator that will make it easier for people to know where the ToC has collapsed to. Once this indicator is in place, we will go ahead and make the collapsing persistent across pages. OVasileva (WMF) (talk) 19:12, 18 January 2023 (UTC)

(Tracked in https://phabricator.wikimedia.org/T316060) Jdlrobson (talk) 22:27, 18 January 2023 (UTC)

Customizing button shortcuts in top-right menu area?

Tracked in Phabricator
Task T326499

Tracked in Phabricator
Task T311281

I'm giving the new skin a college try but one thing that's non-negotiable is removing the direct link to My Contributions in the top-right corner. I used that as a quick way to reach my active/recent discussions so hiding it in the sub-menu is an extra click for no reason. Is there any way to customize which buttons appear directly (currently, it's Userpage, alerts, notices, watchlist) and which ones get hidden in the sub-menu? Slightly less important but still annoying is that I have the UTCLiveClock gadget active (Preferences > Gadgets > Appearance, 2nd one in the list) and that's getting hidden in the sub-menu as well. Is there any way to change this? I don't mind having extra buttons on the top-right of my screen. Axem Titanium (talk) 19:49, 18 January 2023 (UTC)

You're most likely going to have to fiddle with CSS to get a button for it, but a quick way to get to your contributions is to use the hotkey combo Alt+Y. Tenryuu (talk) 02:42, 19 January 2023 (UTC)

Here is a screen recordings showing some of the possible configurations of the updated interface with "Advanced tools"

Hi @Axem Titanium: thank you for your feedback, I opened a task on Phabricator about the direct link to My contributor.

About UTCLiveClock, please look at this section of our FAQ and here. In my opinion you should contact the Tech Village pump or who is updating the gadget and talk about your suggestion with them. Keep in mind that the design of the new skin is trying to reduce distracting links for readers, so probably it should be better a personalized script. Hope this will help.--Patafisik (WMF) (talk) 14:04, 19 January 2023 (UTC)

Thanks for opening the task. I'm not sure how to activate the Advanced tools menu like it shows in the video you added. Axem Titanium (talk) 16:53, 19 January 2023 (UTC)

Easier switching between my languages

I often browse the wiki in both English and Hungarian. With the old design, switching to a page's Hungarian version was just 1 click. (As it always displayed it among the suggested languages.)

With the new design it's a click on the dropdown, scroll down or search for Magyar, then click again. It's a minor, but noticeably more hassle than it was before.

Seeing that most people probably don't speak more than 1-2 languages, could we add a customisable shortcut to the user's selected languages? I don't need to see a list of 60+ languages I don't even speak. --Kazerniel (talk) 19:55, 18 January 2023 (UTC)

Hi @Kazerniel thanks for your feedback. Also the Language Team thinks that you "don't need to see a list of 60+ languages I don't even speak"! :) The Compact Language Links shows you only your preferred languages, you can select it in your Preferences, at the bottom of the page, checking the preference "Use a compact language list, with languages relevant to you." About the double click: actually we don't will make the hover by default, but you can personalize your CSS. See also this reply. For more customization see our FAQ. Patafisik (WMF) (talk) 14:27, 19 January 2023 (UTC)

Thank you! I managed to hide the irrelevant "suggested languages" with .uls-lcd-region-section.uls-lcd-quicklist li.interlanguage-link:not(.interwiki-hu):not(.interwiki-en){display: none;}.-- kazerniel (talk | contribs) 16:09, 19 January 2023 (UTC)

Absolutely awful

Stop forcing mobile interfaces on desktop users. Completely inexcusable and unusable. Kuinor (talk) 20:02, 18 January 2023 (UTC)

I wholeheartedly agree. This is a bullshit decision and the web design team should feel ashamed of themselves. I've used this site every day since I was a child and I have only just now made an account to switch back to the proper interface. If it ain't broke, don't try to fucking fix it. AngryAtlantan3000 (talk) 00:34, 19 January 2023 (UTC)

Same here DontLikeRedesign (talk) 13:45, 19 January 2023 (UTC)

I don't get it. If you have the screen space, use it. Force collapsing some of the most useful parts of the UI makes no sense to me. It's only intuitive when you are limited in space, otherwise people do not look for the hamburger menu, they simply get lost.

I subscribe to the school of thought that web design should be focused on enabling ANY user to find what they are looking for quickly. Hiding necessary pages like "about wikipedia" or "contact us" behind a hamburger essentially locks out many people who aren't trained to look for these things.

The left pane is empty and unused by default. I like the language dropdown, but then a box "educating" users on where to look for their language makes NO sense to me. They can't read English, but the sidebar used to show the language options in their native language, which it doesn't anymore. Why could you not do both? Asukite (talk) 05:25, 19 January 2023 (UTC)

@Kuinor, Asukite, AngryAtlantan3000, and DontLikeRedesign: Hi and thank you for your feedback.

@AngryAtlantan3000 and DontLikeRedesign: Please read this Wikipedia:Sockpuppetry#Inappropriate_uses_of_alternative_accounts, in particular the section Creating an illusion of support.

Hey @Patafisik (WMF): , you cowardly "forgot" to sign your post again, containing baseless accusations of sockpuppetry. You are not editing in good faith - you can provide evidence of sockpuppetry & report to admins, or you can shut up. It's incredible how you refuse to understand why there are so many negative comments: 1.) Users don't want Vector 2022 2.) Users cannot disable Vector 2022 without an account 3.) Vector 2022 is bad enough that users are making accounts *specifically* to disable & comment about Vector 2022. Freedomlinux (talk) 10:48, 20 January 2023 (UTC)

@Asukite: I understand your frustration, please visit our FAQ, this presentation or this information page to familiarize with the new skin, you can find some useful explanations. We don't have removes any functionality, they are just in a different place. You will discover that we will move the Article tools on the right of the page, available also when scrolling. About the box for the language button on the top: we have been working with early adopters communities for a while, and this was asked for increasing the visibility of the new language switching button. This is just a notice that should help. About "Why could you not do both? " it is for the same reason explained here. Habits take time to form, you can try the skin but if you don't like you can go back to Vector 2010.--Patafisik (WMF) (talk) 15:07, 19 January 2023 (UTC)

I'm not a puppet account. Would you rather I create my own topic complaining about the redesign? I thought it would be more appropriate to relate to someone who shared my sentiment and only created an account so as to use Vector 2010. DontLikeRedesign (talk) 15:30, 19 January 2023 (UTC)

Can you create a version that combines some ideas of 2022 with the 2010 Vector?

I think it is a good idea for the Table of Contents being moved off the article space and imbedded toward the right-side of the webpage. I also like that the page is more centered with both left and right spaces being empty.

Unfortunately, there is a flaw in 2022 Vector that cannot be ignored. The current design has no defined space for what is article and what isn't. For example, the spacing between the TOC and the Article seems ambiguous and unclear. It's so distracting that my brain is trying to figure out where in the webpage does the TOC ends and the Article begins. It looks even worse when a TOC has a bar to scroll and the letters just start to erase through an invisible white line.

This gives Wikipedia a less deliberate design. And In my humble opinion, it makes Wikipedia look more like it came from 1990s than it does in current year. If accessibility is so important, why is it such an adjustment for every article? 2010 Vector great because almost every section of the webpage was defined by borders. Is there a way to make a version of 2022 where the borders of 2010 are reimplemented?

Blue Pumpkin Pie (talk) 20:06, 18 January 2023 (UTC)

Here's Custom CSS for a compact theme, so the space between the TOC and main article isn't so noticeable:

.mw-page-container {
	padding-left: 1em;
	padding-right: 1em;
}
#vector-toc-pinned-container {
	padding-top: 0 !important;
	margin-top: 0 !important;
}
.vector-toc {
	margin-left: 0 !important;
	width: initial !important;
}
.mw-content-container {
	max-width: 82em !important;
}

Wing gundam (talk) 22:13, 18 January 2023 (UTC)

@Wing gundam: That's not what i'm asking. I'm asking for the 2010 design as the base template with the same ideas of Vector 2022. The problem isn't just the TOC being spread far apart, its that its all border-less. none of the space is defined.Blue Pumpkin Pie (talk) 23:22, 20 January 2023 (UTC)

Worse for reading, more scrolling, more wasted space, less information.

Since the new layout wastes so much space i have to scroll way more. Thanks for making it a worse experience.

You present less information.

It is harder to read.

So much wasted space. Especially on an ultrawide screen. 50% of my page is white. Why do i even have a larger monitor if you just fill it with white.

Congratz, you made the one thing this site was good at bad. 2A01:C23:6033:BD00:302E:8B1A:582E:AD8F 20:08, 18 January 2023 (UTC)

edit: Here is an image of how it looks on a modern monitor that isn't a mobile device: https://i.imgur.com/uwDD5ss.png The same page on the old design shows me 2 additional sections. So on the old design i see more, have to scroll less, can comprehend more at once, and am generally not assaulted by a literally 62.5% white space. Why not make the next design be just a white page, would be a good approximation of how it looks now.

I actually like the max-width limit on wide displays, although a toggle would be preferred. If you don't like it and want full ultra-wide, put this in your Vector (2022) Custom CSS (found in your Preferences):

.mw-page-container {
    max-width: initial !important;
}
.mw-content-container {
    max-width: initial !important;
}

Custom CSS fixes most pet peeves. Wing gundam (talk) 21:41, 18 January 2023 (UTC)

There's a toggle in the bottom right corner of your screen. Jdlrobson (talk) 22:22, 18 January 2023 (UTC)

Bad tested. In my 1920×1080, 17" laptop screen, I cannot see the toggle button by default. I must set Chrome's zoom to 80% to see it and click, then revert zoom to 100% again.

I was tempted for a while to donate to Wikipedia, but now I'm happy not to donate a single nickel, seeing how you spent donator's money. Boo. Thump-down. 37.134.90.176 08:40, 19 January 2023 (UTC)

Holy shit, how is anyone supposed to know that's there without explicitly asking? It's barely noticeable even if you know to look for it! I would never by default think to look in the bottom right of the page for a floating button that changes the page layout, 99.999...% of the time such a control would be somewhere at the top of the page, with every single other control/option/preference/menu/etc.

Maybe if this toggle hadn't been so effectively hidden the backlash about the page width change would have been vastly minimized. Honestly I'm thinking this was hidden intentionally in order to effectively force most users of the new skin to use the smaller fixed-width version and get more feedback on that version (though whether they got the feedback they were hoping for...). NightKev (talk) 21:24, 21 January 2023 (UTC)

Why would i do any of that. Nothing like that was necessary before. Me having to manually go change stuff to get a worse version of what was already there before is bad design. Also the only reason i created a wikipedia account was so i can use the old better design. Also i have no toggle bottom in the bottom right of my screen, i have whitespace: https://i.imgur.com/T15bQMU.png

User contributions

Is there no easy way to look up user contributions? You used to be able to do it from the user's page and talk page. 2603:3005:42DF:4000:D5A:FD7F:5960:C34 20:13, 18 January 2023 (UTC)

Never mind, I found it through the hamburger menu. Not very intuitive though. 2603:3005:42DF:4000:D5A:FD7F:5960:C34 20:17, 18 January 2023 (UTC)

New layout

Just came across the new layout for the first time right now, and immediately switched back to the old one.

Sorry, but this is simply awful. There's way too much empty white space, and articles are needlessly compressed as a result while it looks woefully antiquated from an aesthetic standpoint. We don't need such massive side margins, for God's sake. What's the point of that? I thought somehow it had switched to the mobile version.

Perfect example of unnecessarily trying to build a better mousetrap. Beemer69 (talk) 20:29, 18 January 2023 (UTC)

Couldn't agree more, classic case of "fixing" that which wasn't broken. Xx78900 (talk) 21:21, 18 January 2023 (UTC)

+! from me Grl570810 (talk) 23:12, 18 January 2023 (UTC)

Hello @Beemer69, @Xx78900, and @Grl570810. Thank you for writing here.

We've briefly explained our motivation in the FAQ, and on this page, there's a longer essay. Many individuals may have different preferences and answers to the question "what settings provide you with the best reading experience", and it's possible to customize our interface. As logged-in users, you may set up a preference disabling the limited width. Early next week, we'll move the page tools to the right column, so there will be a bit less empty space. SGrabarczuk (WMF) (talk) 23:14, 18 January 2023 (UTC)

• Why can’t we leave it for readers to narrow their browser windows down?[edit]

Most users don't resize their browser windows or use browser plugins to improve the design of the websites they view. Wikis should be good-looking immediately, in their basic form.

And yet now the Wiki is worse-looking by far in its basic form. A gaudy redesign that incorporates the worst features of Britannica's online layout, seemingly in imitation thereof.

Xx78900 (talk) 08:53, 19 January 2023 (UTC)

I also don't understand why so much empty white space is needed between the article and links (to the left). If readability is such a big issue, they should increase the white space to the right (for infoboxes) and increase the vertical spacing as well. You won't be able to read a damn thing, but it would fullful the "white blank space is useful" prophecy that the FAQ proclaims. -Jetro (talk) 12:54, 22 January 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. ~~lol1VNIO🧧🐈 (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. ~~lol1VNIO🧧🐈 (I made a mistake? talk to me) 20:03, 19 January 2023 (UTC)

Forcing new UI on non account users is trash design

i wont be donating this year if this remains the default. i dont want to sign into wikipedia everytime i google cholera just to change the shitty ass template. if it isnt broken dont fix it, simple. and definitely dont make it a default change you cannot edit without an account when the majority of your users dont use accounts. all this does is make me not want to use or donate wiki for like the first time in my life. im not giving you my money to play around with graphics packages. 2404:4404:1758:400:E9A4:FEEC:61D6:A7AA 20:43, 18 January 2023 (UTC)

Why do you keep signing out to re-google cholera? Wing gundam (talk) 21:25, 18 January 2023 (UTC)

[BUG] Vector (2022) imports Vector legacy's Custom CSS

If you have Custom CSS for both Vector-legacy and Vector-2022, then Vector-2022 imports two custom CSS:

• /w/load.php?lang=en&modules=user.styles&only=styles&skin=vector-2022&user=Wing+gundam&version=zbgsm
• /w/load.php?lang=en&modules=skins.vector.user.styles&only=styles&skin=vector-2022&user=Your+Username&version=ns7t3

The first one loads Vector-2022's Custom CSS. However, the second one is wrong, and results in the import of Vector-legacy's Custom CSS. The correct URL would be /w/load.php?lang=en&modules=skins.vector-2022.user.styles&only=styles&skin=vector-2022&user=Wing+gundam&version=ns7t3, but that's redundant as the first one already loads Vector-2022's Custom CSS. Not sure if the bug affects JS too. Wing gundam (talk) 21:17, 18 January 2023 (UTC)

This likely explains the issue I commented on in an earlier section above. In my case, importing the legacy user custom CSS broke the new 2022 layout making it non-functional. I didn't investigate further on the actual mechanism like you did, but I agree with you that this is Bug level issue that needs to be fixed. Imeriki al-Shimoni (talk) 21:48, 18 January 2023 (UTC)

Do you know where we report bugs/issues? Wing gundam (talk) 22:20, 18 January 2023 (UTC)

This is not a bug but intentional behaviour to support people transfering to the new skin. The behaviour will be removed with phab:T301212. Jdlrobson (talk) 22:20, 18 January 2023 (UTC)

(you can update the selectors in enwiki:User:Imeriki_al-Shimoni/vector.css to use the .skin-vector-legacy class if you only want it to apply to the old skin. Jdlrobson (talk) 22:21, 18 January 2023 (UTC)

Icons should be labeled

Icons, like the ones at the top, or the persistent ones when scrolling, can be vague and confusing, whereas text is instantly understandable. For example, the "notices" icon at the top could be interpreted as 10 different things. Why not label it to make things easier? 73.162.34.195 21:21, 18 January 2023 (UTC)

Hello, thanks for asking this question. During our user study, we did not note any icons which were missing labels that were confusing. Users taking part in tests were able to identify the meaning of the icons quickly and correctly. We may revisit this if we have more comments pointing at specific icons, just like you've pointed at the "notices" icon. So, thank you for being specific about this! SGrabarczuk (WMF) (talk) 00:15, 9 February 2023 (UTC)

Article text reduced to half of usual page width on 1440p monitor/fullscreen browser? I scroll enough at work!

This is pretty ridiculous, although in keeping with "modern" design themes for ludicrously empty spaces. Given my monitor size, the old design lost ~5cm to the left menu. The new design loses a whopping ~25cm for a contents menu and login/user menu. The article text, the crucial content, has lost a little under half its screen space.

Did nobody notice that people come here to read text? Preferably without excessive scrolling?

This a travesty of style trumping function, and you spent my donation dollars on it? Well, that won't continue at this rate. 94.102.193.206 21:25, 18 January 2023 (UTC)

Hello! Thank you for writing to us. We've briefly explained our motivation in the FAQ, and on this page, there's a longer essay. Many individuals may have different preferences and answers to the question "what settings provide you with the best reading experience", and it's possible to customize our interface. SGrabarczuk (WMF) (talk) 22:59, 18 January 2023 (UTC)

No, actually, if you are not logged into an account, you cannot customize your interface. Because generating one single cookie would just be too hard. 142.162.17.231 02:06, 19 January 2023 (UTC)

+1 on the matter of logged-out users being unable to change theme. For such a significant change, a cookie is the least that should be done to respect users who don't have or want an account for any reason they may have. MajorArchitect (talk) 03:16, 19 January 2023 (UTC)

I would also like to add to the chorus of both 1) disliking the new width and 2) pointing out that it is still bad if you are logged out 23.84.252.165 00:10, 20 January 2023 (UTC)

Limited Content Width default on PCs

Hi Team,

I assume that the change to the limited width content is a result of the increasing prevalence of mobile phone based browsers to view the site (although why one wouldn't use the app on a phone is beyond me). However, if you are using a PC, Mac or *nix workstation that has a 'proper' monitor with a landscape aspect ratio it's purely a waste of real estate. I know you can toggle between views but I would suggest that it would be an improvement if, rather than default to limited width in all cases, the skin were intelligent to the aspect ratio and adopted full width when it's landscape, limited when portrait.

Regards,

Graham Grl570810 (talk) 23:11, 18 January 2023 (UTC)

"I assume that the change to the limited width content is a result of the increasing prevalence of mobile phone based browsers to view the site" It isn't. The reasons for the limited width are explained in the FAQ: Reading/Web/Desktop Improvements/Frequently asked questions#Why is the width of the content limited?. Fourthords (talk) 02:32, 19 January 2023 (UTC)

The designers are apparently confused about the difference between a website and a book. One of the nice things about websites is that we can set our browsers to view them as we'd like rather than getting them in a fixed format. Growfybruce (talk) 03:35, 19 January 2023 (UTC)

These are all terrible reasons. I've had several websites I use heavily make similar changes recently and they've all taken a huge nosedive in usability as a result. Who the hell is making these decisions and what user experiences are they basing these inane decisions on? What is the point in having an actual full computer monitor when every damn site is changing things to waste 50% or more of my screen space for no reason? It seems nearly every single person involved in so-called "UX design" these days is living in a completely insular world utterly divorced from how actual people use their sites/layouts. And that FAQ statement of "we want this to be the default instead of a setting" is just flat out stupid. Terrible design, terrible reasoning, terrible experience. What a waste of everyone's time. 24.251.3.86 14:05, 19 January 2023 (UTC)

I strongly agree with this. I disabled the redesign, only to re-enable it once I found there was a full-width version. With the entire browser space used, I actually feel like it's an improvement. Jadebenn (talk) 20:20, 21 January 2023 (UTC)

Bad design

This design update is not very good. It has many problems.

1. The width of the text is far too narrow, leading to wasted room. There is too much padding everywhere. It makes the page look broken. Also things need borders. The borderless design looks bad when all of the tables and boxes in the contents of the page have borders.
2. The sidebar is very confusing as it doesn't appear until you click on the top button.
3. This is relation to my next criticism, which is that icons or images are used instead of text. I could not figure out how to find the sidebar without clicking randomly across the page.
4. Why are the links to the talk page, sandbox &c. hidden in yet another menu? There is plenty of space. Also the talk page icon is very immature. It needn’t a smiley-face on it.
5. Why are the language links at the top of the page when most people would have no reason ever to use them?

Overall, while Vector could do with some modernisation, it does not need a change in layout or arrangement. Please get rid of all of these unneccesary “interactive” menus and just present the links as they are. The style of the page contents clashes with the new stuff. Steepleman (talk) 23:58, 18 January 2023 (UTC)

Whoever thought that Vector needed a design change needs to be fired. Immediately.

I'm not against making updates to make the website more readable, but I searched an article today and was greeted with the new design change which wastes 2/3rds of my monitor space. From what it looks like all they did was slap the mobile design into the desktop mode for no damn reason. Why on earth would anyone think it's a good idea to have the content of an encyclopedia page take up the middle third of a computer monitor while the sides are just completely blank for no reason? This may be the dumbest style update I've ever seen to a website since the 2010 Digg redesign which effectively killed the site. Sunjester1979 (talk) 00:27, 19 January 2023 (UTC)

@Sunjester1979: It will forever be a mystery to me how they manage to combine this horrendous mobile design with screen-eating devices such as the astronomically irritating sticky header and sticky table of contents... TolkienGateway and Liquipedia uglified their UI in this way, too. That said, not all changes are bad - for examples of good modern designs, I personally would reference Blizzard forums (with infinite scroll but with a bar that indicates the precise position in the thread), and the Korean Namu Wiki.--Adûnâi (talk) 11:27, 19 January 2023 (UTC)

I was reading an article and I clicked a redirect. I thought Wikipedia broke because there was a solid 1 1/2 inches of dead space on either side. The search bar sits near the center of the screen, occluding a massive portion of the text if you dare use it. The Vector 2022 Experience is awkward, claustrophobic, and it doesn't offer any improvements over classic Vector.

I might revisit this design after it's gone through some drafting, but for now I'm sticking with what I know. Sayer2681 (talk) 01:24, 19 January 2023 (UTC)

Desktop layouts need to be for the Desktop, not for a phone

The design update is very frustrating and follows a terrible trend of other sites doing similar things. In lieu of writing a pile of words about usability, accessibility, and general UX, I'd rather make a quick set of bullet points here.

• The abysmal width is the worst offender here. There is so little space for content that you are forced to scroll more frequently.

• There is no room for content. Pages with more media content exacerbate the problem above a great deal.

• The floating topic list is advertised as a feature to 'Scroll Less', but it's working against that goal. It's consume so much of the now very finite horizontal space that you are forced to spend more time interacting with a scroll bar...again.

• Even if you expand it with the feature in the bottom right, it doesn't remember that option, so every new page view must be manually expanded.

• This attempt is clearly a design for a phone, not for a desktop. Good software needs to have two views built for two radically different form factors. Keep your views simple, your features light, and just do the work.

• There are so many other valid complaints here that I'll avoid echoing in text, but would like to +1 in spirit.

The new design is a UX disaster. It's fixing none of the actual problems of the old design, while introducing a huge pile of new ones... And stop letting front end designers make decisions about the web - they are collectively awful at their job. Kadecgos (talk) 00:26, 19 January 2023 (UTC)

The new UI will make me leave Wikipedia

My mental health is more important than trying to fight the incredibly irritating things such as the constantly moving and flashing sticky table of contents and the sticky bar at the top eating my screen space. The ToC doesn't remember being collapsed. Requires more clicks to change the language. It's an absolute travesty as I already said over the past 1.5 years in other comments here. Mobile design breaks computers. Adûnâi (talk) 01:23, 19 January 2023 (UTC)

@Adûnâi: Just... change back to Vector 2010? It's not that hard, just Preferences > Appearance > Vector 2010. Skarmory (talk) 03:49, 19 January 2023 (UTC)

@Skarmory: I won't type my password a dozen times a day just to get a UI that doesn't make me depressed, sorry. But wait, phone users never log out, I forgot phone users are the only ones that matter, apparently.--Adûnâi (talk) 11:18, 19 January 2023 (UTC)

Oh, do you not stay logged in? That never crosses my mind as something people do because it automatically just feels counterproductive, I always forget about shared computers though. Skarmory (talk) 20:16, 19 January 2023 (UTC)

It might be easy for people with accounts, but what about those without who have this layout forced on them? DolimiccanDragon (talk) 05:08, 19 January 2023 (UTC)

I thought about that, but given the fact that I was replying to someone with an account, I figured it wasn't relevant in this case. Skarmory (talk) 20:12, 19 January 2023 (UTC)

"Missing in norsk" is nonsensical

All pages with a full Norwegian translation are missing a Norwegian translation according to the language dropdown. Norwegian has two variants, including on Wikipedia, Bokmål (common) and Nynorsk (rare), there's no other thing when both variants are covered.

Right now, it is like complaining that a page with both a British variant and an American variant isn't available in English. KristofferR (talk) 02:21, 19 January 2023 (UTC)

Hi @KristofferR, perhaps your problem should be the same of this task? I will notify the Language Team about your feedback in the Talk page of the Universal Language Selector, I think there are decisions that are better suited for other teams. Thank you for reporting this issue. Patafisik (WMF) (talk) 13:26, 19 January 2023 (UTC)

I tried reproducing this but could not. Can you give an example on which page on which wiki are you seeing this? Nikerabbit (talk) 09:14, 24 January 2023 (UTC)

CC @KristofferR Patafisik (WMF) (talk) 17:09, 26 January 2023 (UTC)

I'm seeing it on all English articles. https://en.wikipedia.org/wiki/Buckwheat for example, is missing Norsk, while being available in Norsk Bokmål and Norsk Nynorsk. KristofferR (talk) 14:33, 27 January 2023 (UTC)

Video demo @Patafisik (WMF):

https://i.imgur.com/zQOJVTD.mp4 KristofferR (talk) 14:37, 27 January 2023 (UTC)

I have a guess. Can you open a developer/javascript console of your browser and write mw.uls.getFrequentLanguageList() in there, press enter and paste the output here.

I guess you have no in the list there for some reason. Nikerabbit (talk) 13:49, 30 January 2023 (UTC)

Yup, I do. Array(5) [ "en", "se", "nb", "no", "nn" ].

I also wonder why I have the microlanguage Davvisámegiella (se) in that array, I only clicked on it after I wondered what the hell it was. However, I am interested in Swedish articles, and read them all the time, so that seems like an additional bug that should also be fixed.

I wonder if the code has a bug where it uses both ISO 3166-1 and ISO 639-1, despite the same words meaning different things, like se. KristofferR (talk) 17:48, 30 January 2023 (UTC)

Thanks for the info. We are tracking the suggestion issue in Phabricator: https://phabricator.wikimedia.org/T328435 Nikerabbit (talk) 12:08, 1 February 2023 (UTC)

New UI forces massive amounts of whitespace upon users

This new UI that was unexpectedly rolled out (to people like me who didn't have accounts before now) forces an unreasonable amount of wasted whitespace upon people using high-resolution monitors. My main work system is a 4k UHD monitor, and the new layout reduces the amount of space used in a full-screen browser window to less than half of the window. It's ridiculous and makes the site much harder to use now. From looking at the FAQ and discussions, it appears this is intentional. I would urge the Wikipedia team to do some additional design testing on users with high res monitors, since the example screenshots shown elsewhere indicate that the bulk of testing may have been done on lower-res (1080p perhaps), which doesn't have nearly the same problem. Trynn (talk) 02:23, 19 January 2023 (UTC)

Agreed, looks very tacky on my 1440p monitor and makes the site feel cramped. We already have a mobile UI that takes advantage of vertical space, so I'm baffled on why this was greenlit for desktop users. If anyone from Wikimedia is reading this, please stop forcing mobile or mobile adjacent UI on desktop users. Theangrygrunt (talk) 03:05, 19 January 2023 (UTC)

I can not stand the new layout. I actually thought something was wrong with my browser at first. It looks completely out of place on desktop. My first guess was that I was seeing the mobile site for some reason, only to look it up and find out that this is how it's supposed to look now.

It feels incredibly cramped. The previous layout allows the content to take up a majority of the screen space, as it well should, while the Vector 2022 squashes the content only into the central third or so of the screen. Worse yet, the expanded margins aren't even used for anything. They're literally just completely empty. It would have been much more tolerable if the site at least used the full width available to it.

If the intent is to accommodate users with ultra-wide monitors, then why not implement a responsive element that limits the width of the content beyond a certain aspect ratio? Seems like a much better option than picking a fixed ration that's *lower* than a typical user's monitor.

And worse yet, changing the setting on Wikipedia does not apply it to all Wikimedia sites. Even this very talk page opened up with the Vector 2022 layout after switching my preference to Vector Legacy on Wikipedia. The9thBit (talk) 06:49, 19 January 2023 (UTC)

Paternalistic decision-making and breach of trust

One of the reasons I have appreciated the old design, especially for Wikipedia, is that unlike many other websites, it doesn't try to appeal to some hypothetical "needs of internet users today", and simply provides all the desired information on the screen, with little formatting or other manipulation of the text to achieve any particular goal or express a style. It is minimalist, but for a functional purpose; perfect for an encyclopedia. It is honest and sincere, and respects the user's competence to make decisions regarding how they would like to read that text. If I think that the lines of text are too long, I will reduce the width of my browser. Just because "most users don't" isn't a reason to force it upon people. Perhaps they don't reduce their browser width because they don't want to, for any reason they might have. I see this as an insult to the intelligence of your users. I see in the FAQ that "We [the designers] want it to be default". It doesn't matter what you want. A few people, who I suspect have spent a bit too much time in their own heads, are making sweeping decisions with regard to how a great many other people are to experience a service, the whole mantra of which is to provide various freedoms to people. I do not just find this to be ironic, but also worrying. Wikipedia is a public service, not just the plaything of egotistical front-end designers.

I understand that another reason for making these changes is to increase trust in wikis. I fail to see how a visual redesign can do anything but decrease trust if not leave trust just where it was beforehand. You may say that this design process has been through a great deal of community consultation and I'm sure it has, but the community is not the public. I use Wikipedia every day and have not known of these years-in-the-making changes until this morning, and there are certainly lots of other ordinary people, without Wikimedia accounts (I had to dig up my years-old barely-used account to switch the theme back and make this comment, and users should not be expected to create accounts to do the same) who would have never been aware of such a change, let alone been involved in the discussions surrounding the design or its necessity. I think that a change like this is a breach of their trust, and my personal feeling now is that I can not trust the powers that be to not make unpopular changes in the future such as this one, but that actually affect core principles of Wikipedia. I recently donated to the Wikimedia foundation and am now regretting that small amount, seeing as this is what it is being spent on.

I am hoping that whoever is responsible for making these changes and pushing it to the public see the error in their ways and revert the decision. MajorArchitect (talk) 03:11, 19 January 2023 (UTC)

Hear, hear. Well said MajorArchitect Sarri.greek (talk) 07:11, 19 January 2023 (UTC)

I agree whole heartedly with @MajorArchitect - the big problem for me isn't the ghastly redesign, it's the fact that though I am a daily user of Wikipedia and have been for years, this has been seemingly sprung on the general community. Xx78900 (talk) 08:46, 19 January 2023 (UTC)

@MajorArchitect: I for one lent my voice to oppose this change, I think, as early as 2020. Of course, to n avail - this is the general spirit of the times, and I doubt anything can change the general décadence, downgrade of Web 3.0. All projects seem to fall to it - Liquipedia, TolkienGateway, WordPress, LiveJournal (Gamepedia was sold, so it doesn't count). The only cases of improvements I have noticed have been in the example of Blizzard forums (pagination substituted for an incredibly precise infinite scroll) and of the Korean Namu Wiki.--Adûnâi (talk) 11:30, 19 January 2023 (UTC)

I completely agree, with the above sentiments Murgatroyd49 (talk) 11:32, 19 January 2023 (UTC)

I also completely agree with this very reasonable criticism. Like the author I use Wikipedia every day and knew NOTHING about today's changes.

It annoys me extremely that there is a fixed maximum width - when people have screens of many different sizes. And indeed this seems to be a BIG gripe. See comments on this page:

● "New UI forces massive amounts of whitespace upon users";

● "Desktop layouts need to be for the Desktop, not for a phone";

● "Limited Content Width default on PCs";

● "Article text reduced to half of usual page width on 1440p monitor/fullscreen browser? I scroll enough at work!"

● "Bad design"

● "New layout"

● "Worse for reading, more scrolling, more wasted space, less information."

● "Absolutely awful"

● "Make the text fit the page"

● "Space unutilization"

● "Why the wasted space?"

● "The insolence to think you know better than me what my preferred reading arrangements are" *

● "Wide mode button not appearing"

The fact that there are so many comments on this aspect surely shows this up as the most serious mistake of the new layout?

• "insolence" sums it up really :-(

Allow the USERS to choose how much space to give the Wiki page. So now I have huge white spaces of "wasted" (but expensive!) screen space because some "trendy" designers see fixed width as the new way (one sees this increasingly on other sites). It isn't new. It is old hat. We had it last century (sic) on many websites and abandoned it to be more user-friendly, letting users choose their browser width. I know as I implemented the changes for a very large international concern at the time. Other changed aspects may have user-based reasons but I cannot imagine that for fixed width.

And the "toggle limited width" button is more or less hidden - a simple box graphic in white space completely out of the visible area, bottom right. I didn't know about it until I read it in one of these comments. For at least a few weeks put it up front high clear and in colour with text! Or BETTER, get rid of the need for it and revert to flexible width. I live in hope! ClassicalNigel (talk) 12:49, 19 January 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)

The new language list location is so dumb.

Why do web developers love to move stuff to asinine places and then leave little "This has moved!" notes in their place? You clearly know how stupid this change is, so why do it? 181.43.109.79 05:52, 19 January 2023 (UTC)

Wide mode button not appearing

I got the new design today and I'm noticing that at my computer's resolution of 1440x900, the floating button at the bottom right to widen the whole page does not display. I assume that someone decided it wouldn't be necessary at my resolution, but it really does make a difference. I zoomed out to 90%, then the button appeared, so I clicked it, then zoomed back in to 100%. The difference is extremely obvious: Before vs After. Please allow the "wide mode" button to display at this resolution. Thanks! Numbermaniac (talk) 07:10, 19 January 2023 (UTC)

I'm in the same boat and agree completely, Numbermaniac.

Although it looks like you have to click the button *in every single page*, so I question its usefulness at all. 187.180.169.255 08:32, 19 January 2023 (UTC)

Hey @Numbermaniac, thanks for your feedback. We will be updating this soon. Here is the Phabricator task: https://phabricator.wikimedia.org/T326887. Cheers, AHollender (WMF) (talk) 10:36, 19 January 2023 (UTC)

Yes, I can confirm this too. The button is not visible for many people here and even if you use it the setting is reset when you move to another page. We have to click the button on every single page to get what we want-a comfortable reading like on Vector 2010. The resolution does not seem to matter-the button is missing for low res devices but also for 4k display users. 94.26.15.134 15:10, 19 January 2023 (UTC)

Ok, I've now found where the button is to expand or shrink the text width. 😅 Well hidden; it does appear at 100% zoom on my 1600px display but that's already quite wide. I'm glad to see the phab task for this. I added one for making it less of an easter egg and more of a normal ux option. T327468

I also see what the anons above mean, logged-out users they have to do this for every page they visit, which defeats the purpose. +1 to the request for a cookie-based solution; I too am not comfortable signing in on random library + office terminals but would still like to change this feature when doing research. Sj (talk) 04:31, 20 January 2023 (UTC)

Inconsistent width (I have default settings enabled = limited width mode enabled)

I personally think the design is overall nice, simple and modern. And I think will attract more users to use Wikipedia due to the more modern design, and therefore, consistent design with other websites and operating systems. As I wouldn't be surprised if some people avoided using Wikipedia because it looked "too old". And I think this overall design combats that stigma and gets more people to use it (or use it again), which is an undeniably positive thing for the website and Wikipedia as a whole.

But I can't help and just find the width to be inconsistent within the new skin/theme. When I look at a page, the width is just a bit too thin for my liking (and apparently others as well as I've read on this page - especially for the editing page - also where is the view changes button?). But when I then go to my contributions page, the width all of a sudden is back to (basically) full width. I do use an overall large computer with a large screen, so maybe that's the reason. But I would've hoped, and are hoping, that this new theme (which I must say again, I do like the design of), is tested upon on all screen sizes (from the smallest of computer-tables to the largest of desktop screens).

Lastly, I do think there should be a short-cut button to the most used of features such as the contributions button and perhaps preferences as well. Or even better, according to the data which Wikipedia has, create shortcut buttons for the top 3 most clicked/used button. As before, I did think the top right of the theme was overly crowded and messy (with shortcuts I've never even clicked), and now I think its too simple to the point in where clicking the profile button to access my most used button (contributions) is a bit of an annoyance.

In short, I think the overall more modern and simplistic design great and I hope attracts more users back to the site of Wikipedia. But the simplicity in regards with the usability of the site should be brought back a touch. Perhaps a middle-ground of the old default theme (in regards with usability), but the simplistic design of the new default theme, would be a fantastic middle-ground and satisfy majority of users (which I assume is the goal at the end of the day).

Apart from that, I really do appreciate the fact that there is a discussion page to this new theme. It really shows how open you guys are to constructive criticism and shows how much you want to satisfy the majority of users. 81.227.94.216 08:26, 19 January 2023 (UTC)

This is actually happening to me on iPad too. The new UI is good for touchscreens (obviously) but sometimes the page layout is so zoomed in that you need to scroll for ages through large text, and sometimes it’s normal again. But the Safari page zoom settings have no effect, and there’s no place I can find to fix it on the website.

Really disappointing design and rollout 125.253.36.248 16:45, 7 February 2023 (UTC)

New UI clearly not liked by the majority of people

Seeing how the UI was made default very recent and seeing how many people are talking about it looking bad and/or having multiple mistakes makes it very clear that the majority of people don't like this new UI, so I think that the new UI shouldn't be default on desktop. The old UI was much easier to navigate with and clearly more liked by the majority of people. I personally think that the old UI is also much better than the new one. 90.145.57.18 09:19, 19 January 2023 (UTC)

I agree and I had to make an account to change back to the old one. Vector2022makesmesad (talk) 09:27, 19 January 2023 (UTC)

10/10 name 90.145.57.18 10:46, 19 January 2023 (UTC)

To be fair, I think we can say that editors who don't like it are more vociferously opposed than those who do like it. I've not seen good quantitative info that the majority of readers prefer the old interface. But, similarly, the fact that the majority of beta testers and pilot wikis were broadly in favour may stem from self-selection in those groups. T.Shafee(Evo﹠Evo)^talk 02:58, 23 January 2023 (UTC)

An example of why this was a bad idea

So here i have created an example as to why its bad, firstly, for over a decade i have been using the wikis (plural as i have been active in a 100 or so wikis) zoomed out to either 80% or 67%, now this was done when you guys enforced Vector 2010, since the change also messed up a lot of scripts for the previous 'monobook' version, we had NO CHOICE but to move to Vector 2010 but because it was clunky and you had to scroll for days to read an article, i realized zooming out helped even if it meant i could barely read it, now after this new change, it seems like you have made it worse, its feels more like 'facebook' than a wiki where you end up scrolling a lot and the sidebars are all either drop down menu's meaning every time you go to any article you have to click the drop down thing or click the three lines on top to get the previous sidebar menu which IMO is a bit irritating.. Now i have used a page i frequent here as an example in Wikipedia:In the news/Candidates, here are 2 examples https://imgur.com/a/HhKEiRM, the image on top is how that page is supposed to look in the old vector and you can see how perfectly aligned and informative it is, the image below is how it looks like now, all cluttered which poor spacing and worst of all, the date sections are now drop-down meaning someone trying to read this would have to manually do one date at a time to see what has been added, if anything, this change has made browsing harder and not simpler, infact its all cluttered in the middle with a lot of space on the sides for what "Enforced Adverts"? coming soon in 2023?.....I have 2 ideas you can try:

1.) Create a poll on the main page so when people visit the site, they can vote Yes or No to keep the new format and if more than 50% vote no, You remove this enforced skin after 7 days and only ad it as an option for logged-in users

2.) Find a way that this enforced change only affects the 'article' namespace only, sounds like a bit of work but whatever this thing you people have created will not work for all namespaces on this wiki or any wiki, infact before i could navigate farsi wiki but now i cannot because of the new skin, It also means to restore the sidebar and cross-wikilinks section for all and also it has been mentioned before but the font colouring is poor as i can barely read stuff, needs more sharpening

Please don't tell me to to disable it via preference, some of us can no longer access certain wikis due to blocks but still USE IT, if anything, all this new skin has done is forced people blocked who did not want to create an account be forced to create one just to make the wiki readable, and that socking is on you! ... lol... Stemoc (talk) 10:27, 19 January 2023 (UTC)

Comment: ITN is a great example of a set of pages designed for the old TOC, there should be a magic word that forces an inline TOC or that forces the sidebar-toc to expand by default. Sj (talk) 04:38, 20 January 2023 (UTC)

The insolence to think you know better than me what my preferred reading arrangements are

I'm actually mad at you guys. Your stupid hamburger menus and your stupid wasted space. THERE'S PLENTY OF ROOM FOR EVERYTHING. Stop hiding stuff behind stupid button presses. DON'T FORCE A MAXIMUM WIDTH ARE YOU STUPID? Skoinksx (talk) 10:54, 19 January 2023 (UTC)

If you prefer the old look, you can switch back to it by changing the skin under user icon→"Preferences"→"Appearance" to "Vector legacy (2010)" —Kri 13:12, 19 January 2023 (UTC)

@Kri: thank you for the explanation. Hi @Skoinksx: Please read this Wikipedia:Sockpuppetry#Inappropriate_uses_of_alternative_accounts, in particular the section Creating an illusion of support. About Vector 2022 you can find more information here and here, for example how to customize the content width. Please don't attack us, I understand you are frustrated but it is not very useful for us or for you. Please consider not using the capital letters too, on the internet it is considered like shouting. I'm hearing you and you are free to choose your preferred skin locally or globally. Hope those links should help. — Preceding unsigned comment added by Patafisik (WMF) (talk • contribs) 16:01, 19 January 2023‎

Hey @Patafisik (WMF): , you "forgot" to sign your post. It is considered good etiquette to sign your comments with ~~~~. Please explain why you are accusing this user in particular of sockpuppetry - there is really no need of using sockpuppets to post complaints about the new UX because many users are posting about it anyway. Freedomlinux (talk) 16:35, 19 January 2023 (UTC)

I accused nobody. If this person is not concerning by sockpuppetry can just ignore my message. Patafisik (WMF) (talk) 17:24, 19 January 2023 (UTC)

Seriously? By telling them "using alt accounts is wrong" you are accusing them of socking. Why else did you bring it up? And could you "just ignore" their personal attack? Aaron Liu (talk) 23:44, 19 January 2023 (UTC)

Alternative accounts? Do you think I'm the only person in the world that thinks your changes are idiotic? You think I'm the only person who thinks you didn't even read your own research? You REALLY think that?

And I AM SHOUTING because you're stupid and you need to be shouted at because you've forgotten yourselves. The absolutely gall to think that you know better than your users what their subjective opinions are BOGGLES THE MIND. You morons didn't even read your own UX research and that is plainly evident when you read the articles you use to explain it. They said "blank space is not wasted space" and "use blocks of blank space to separate logical blocks of information". You plonkers took it to mean that there must ONLY be blank space. How? What twisted mind led you to that conclusion?

Please tell me, exactly where in your research did someone come across the thesis: "the users will appreciate having to click multiple times to drill down into useless menus" OR "it's a good idea to hide information behind multiple disparate menus, located in every corner of the screen". You say you've been working on this redesign for years. In all those years, did not at least ONE of you say "oh you know what would be a good idea if we're limiting max text width?", and brace yourselves here, because I may just blow your little minds: PUTTING TWO COLUMNS OF TEXT PER PAGE. LIKE WORD? You know Word? You know WORDPAD? Fucking Wordpad understands stacking two pages side by side to fill the screen and Wikipedia doesn't.

The fucking gall. I wish I could take my donations back. Not because of the changes but because you've obviously grown to love the smell of your own farts to the point where you prefer them to air. Skoinksx (talk) 05:19, 20 January 2023 (UTC)

@Patafisik (WMF) Why are you bringing up of sockpuppetry for seemingly no reason when replying to people who are against the new design? You've done it multiple times on this page. I don't think it's helpful because it could end up making people assume that some of the posts that like the new redesign are actually sockpuppets, especially considering how few there are. WikEdits5 (talk) 16:41, 20 January 2023 (UTC)

He's not attacking you, he's attacking your ridiculous new layout that makes the site hard to use and makes everything unreadable. You should at least have the sense to take the current mass criticism and learn from it instead of accusing users of personal attacks. Freja Draco (talk) 22:15, 22 January 2023 (UTC)

They did say ARE YOU STUPID?, so they did use a personal attack. I agree with the rest though. Aaron Liu (talk) 02:29, 23 January 2023 (UTC)

Citations have been made worse

So I'm not entirely sure how add images to demonstrate this as I just made an account, but the new design takes the already badly formatted citations section and actually makes it worse. The citations section is incredibly useful to quickly get an overview of potentially useful sources for academic research. The problem is that there isn't much standardization to how they're formatted and they can be a bit of a visual mess and hard to read.The new UI makes this even worse by squishing them into the middle 1/3 of the screen. Using "fit to screen" fixes this by restoring it to the old format, but most people wont figure that out and frankly restoring it to the old, not very good format, isn't really a fix. Why did you send so much time and effort on a new UI which is even less reader friendly and actively makes this problem worse, that doesn't seem to be very well liked if this page is anything to go by, instead of fixing existing UI issues. You "fixed" something that wasn't broken and broke something that was broken even worse. Zapdragon23 (talk) 11:07, 19 January 2023 (UTC)

Hi @Zapdragon23, I understand you are frustrated and I'm sorry for the disagreement. We are working on the interface only, no work will be done in terms of styling templates, the structure of page contents, map support, or cross-wiki templates. I think that you can ask to fix the template in the Tech village pump instead? To know why we limited the content width please read here. For the redesign, please visit this section of our FAQ, for the the story behind the new look you can read this post on Diff. Patafisik (WMF) (talk) 15:47, 19 January 2023 (UTC)

Please read this en:Wikipedia:Sockpuppetry#Inappropriate_uses_of_alternative_accounts, in particular the section Creating an illusion of support. — Preceding unsigned comment added by Patafisik (WMF) (talk • contribs) 16:05, 19 January 2023

Why the wasted space?

Why the hell is 2/3 of the screen on desktop used blank unused space? It looks ugly and it makes reading articles in the cramped space frustreating. I implore the wikimedia team to reconsider these design changes as they are terrible 37.247.3.52 12:22, 19 January 2023 (UTC)

Thank you for your feedback. In this section of our FAQ there is an explanation of why Vector 2022 has the limited content by default. You can personalize your experience (log-out users can increase the width of the page by selecting the toggle in the bottom right corner of the screen). Zapipedia (WMF) (talk) 12:37, 19 January 2023 (UTC)

What toggle? I've yet to find it. Murgatroyd49 (talk) 13:03, 19 January 2023 (UTC)

It's in the bottom right corner of the web page (i.e., of the web browser), not in the bottom right corner of the middle third of the web page that the contents are limited to. —Kri 13:19, 19 January 2023 (UTC)

Nope, still can't find it, all I get bottom right is the Wikimedia and Mediawiki buttons. I'm using Safari (MacOS edition) if that makes a difference Murgatroyd49 (talk) 14:18, 19 January 2023 (UTC)

That toggle would be fine if it actually persisted, but having to toggle it on every single page, every single time you click a link or come to a new page from a search engine or whatever is far too burdensome to be useful or practical, and as such, basically may as well not exist for all the good it does. In all the years I've been using Wikipedia, I've never had to actually log into my account just to have an acceptable viewing experience, and I'm not willing to continually log in everywhere now just to overcome a bad design choice. Hopefully there will be a browser extension available soon that fixes this error automatically because the FAQ makes it clear this is the direction Wikipedia is intent on taking, users be damned. 24.251.3.86 14:33, 19 January 2023 (UTC)

Hear, hear. It's difficult for me to understand why making readers push a toggle on every single page on every single visit would be an acceptable alternative. Or an alternative at all. --Kizor (talk) 16:53, 19 January 2023 (UTC)

If it is really desired to have this be the default, at least allow users to override the default to their preference WITHOUT creating an account. It is extremely easy to do this with cookies.

Personally this new layout makes me want to disable max-width altogether as this one css 'feature' makes reading incredibly difficult. Reukiodo (talk) 01:29, 26 January 2023 (UTC)

Do these design principles hold for a website like Wikipedia? If I read an article on Nature, I am reading large blocks of text which, yes, I prefer to view in a smaller paragraph. But in this case, the whole article is a continuous, sequential narrative which requires sequential reading of paragraphs and strong retention of information. However Wikipedia articles are usually not read sequentially and (in my own case, at least) when someone opens a Wikipedia page they generally scroll down to the heading that they want rather than reading sequentially from the start. Having the wide layout, with more information on the screen at once, allows this by providing more points of orientation. It's why I find navigation on mobile Wikipedia so frustrating - I want to scroll up and down to the relevant section, but the restrictions of the mobile screen make it so difficult to orient myself since wherever I scroll all I see is an identical block of text (I'm not sure that can be fixed on a small phone screen, mind you).

You may say 'just use the table of contents', but with a wide layout and a scroll wheel, I can navigate an entire Wikipedia article without even moving my mouse. With the narrow layout and less points of orientation, I'm more inclined to a.) move my mouse to the table of contents and navigate that (without being able to see at a glance what each section contains) or b.) take my eyes off the article to look at the table of contents and scroll with the scroll wheel (also annoying since I can't actually see the contents of the article while I do so!) There is also c.) look at the article and scroll with the wheel, but since less information is on the screen at the time this is just less effective than before. LifeOnTheTurtlestack (talk) 21:39, 26 January 2023 (UTC)

Wholeheartedly agree with this. I've used Wikipedia for 20 years now and finally bothered to make an account just so I can actually use my whole monitor. Designing for mobile is understandable considering the market share, but punishing desktop users makes absolutely zero sense, more so when it's entirely possible to adapt body size to screen size. LamerGamer44 (talk) 15:48, 19 January 2023 (UTC)

Thanks for the toggle button. I am unable to log into wiki at work and this button will be getting heavy use. Its a clean and simple design solution for something that is unnecessary but regrettably will probably stay. 2406:3400:21E:2A50:28A6:361F:3B24:1E10 00:03, 20 January 2023 (UTC)

Make TOC visible when editing a page

Tracked in Phabricator
Task T294950

Why is the new TOC hidden when editing a page? The old TOC was not, even when editing a section of a page, and you could use it to jump to a specific section or subsection while still editing, which was really convenient if the part of the page you were editing was long. With the new TOC, you cannot.

Is there any way to enable the TOC also when editing pages? If not, could you please add that option (and maybe even have this visibility on by default as I don't see any reason why it shouldn't be visible), or just change the behavior so that it is always visible even when editing a page, just like the old TOC was? —Kri 13:04, 19 January 2023 (UTC)

Hi @Kri, thank you for your suggestion, a task is already open on Phabricator, you can follow it at this link. Actually this task is not depending only by the Web Team but it concerns more the Editing Team, but you don't have to know.--Patafisik (WMF) (talk) 15:29, 19 January 2023 (UTC)

Hi @Patafisik (WMF), thanks for the answer! Good to see that this issue has already been addressed. —Kri 16:03, 19 January 2023 (UTC)

Line width limits are great, but do them right

As other comments have mentioned, using pixel widths causes zoom problems. However, CSS has a solution: `ch`. It is possible to directly limit the width to the desired number of characters, regardless of font/zoom chosen, by using `ch` and `rem` units. There's a full explanation here: https://every-layout.dev/rudiments/units/

Limiting width is a good thing - this is just a result of having binocular vision, we are better at scanning up/down because both eyes can have their center of focus on the scanned text. 2601:483:801:8480:AE50:DEFF:FE59:115 14:25, 19 January 2023 (UTC)

Maintenance templates not centred with usable line width

In articles with right-aligned templates, maintenance templates in a section are aligned to the right instead of the centre. For example, an article with a maintenance template in the first section and an infobox that reaches that section would have the template be aligned to the right. See this revision of the English Wikipedia article for Osaka (in section Facilities/Modern architecture) in a smaller window width or this revision of the English Wikipedia article for Suzume (film)for an example. Otemaci (talk) 14:46, 19 January 2023 (UTC)

Hi @Otemaci: thank you for reporting this issue, but what is happening isn't especially related to Vector 2022, the template is aligned on the right also in the old Vector, as you can see adding at the end of the URL this code ?useskin=vector [2]. We are working on the interface only, no work will be done in terms of styling templates, the structure of page contents, map support, or cross-wiki templates. Can you ask to fix the template in the Village pump (technical) instead? Hope this should help.--Patafisik (WMF) (talk) 16:32, 19 January 2023 (UTC)

TOC Priority

The TOC should take precedence over site navigation/tools/etc in the left sidebar. As matters stand, by default one must scroll to see the TOC for the article. As these changes mean that more information is below the fold than in previous iterations, the TOC should be prioritized in order to make navigation quicker. I would suggest TOC either come before other links in left sidebar, or be moved to right sidebar. SweeperX (talk) 14:56, 19 January 2023 (UTC)

Hi @SweeperX, thank you for your feedback, I agree with you: in few weeks the Article tools will be available on the right side of the page, so the TOC will be more in evidence in the left side of the page. Also Article tools will be "sticky". Look at this page for further information. Patafisik (WMF) (talk) 15:33, 19 January 2023 (UTC)

Oh brilliant, you didn't even test this before releasing it. Skoinksx (talk) 05:27, 20 January 2023 (UTC)

Why do all these nu-web designs penalise desktop users with good monitors

New design looks awful at 2560x1440, I really don't know what more to say. I had to make an account purely to be able to change the setting back to the old design.

Why do we need to be logged in to set this? Tacgnol9001 (talk) 15:33, 19 January 2023 (UTC)

Hello @Tacgnol9001. At the FAQs you can find an explanation of why the opt-out link is not available for logged-out users who want to go back to Legacy Vector. You may also use a bookmarklet. Copy that code and just replace "monobook" with "vector". Please visit also this talk page to learn more about using Vector 2010 as an IP. Thank you. Zapipedia (WMF) (talk) 16:40, 19 January 2023 (UTC)

"Use a bookmarklet" I'm sorry how many normal internet users do you think know what the hell a bookmarklet is, let alone how to use one? Did you guys do any testing with normal every day users? Not having a switch for logged out users is a bad design, no normal user is going to go into some obscure settings or talk page, and then use some script/extension/plugin to change the layout, they just want to click a button and have it all done for them. 104.202.250.242 17:02, 19 January 2023 (UTC)

exactly, its like they said a big EFF OFF to PC users... if anything, they should only enforce Vector2022 for mobile users only ala the m.wikipedia.org domain, not for everyone.. Stemoc (talk) 00:27, 20 January 2023 (UTC)

I dig it

Hi! I just wanted to say that I quite dig the new look. Judging by the above comments, I'm sure ya'll have been struggling with a quite a vocal (and vitriolic) minority who are unsatisfied, so I hope that a bit of positive feedback could be a pleasant surprise. Overall, the new look is sleek but "doesn't rock the boat" as one publication I read says.

The primary complaint I've seen is about the margins but, honestly, it fits in with most classic newspaper and encyclopedia styles, online or print. As a prolific editor, I'm just thankful that paragraphs look like actual paragraphs. Vector 2010 was so stretched out that a whole paragraph only took up two lines, it was crazy.

If I had any recommendations, I'd say that giving in and letting unregistered users change to their preferred shouldn't be too big of an ask. Not sure if that would be difficult but I'm sure the people above me would be placated at least. Personally, if I had to list any gripes, I'd say that the search bar (Side note: I'm glad short descriptions are finally visible) does block an article's lead paragraph. Moving it to the currently-empty right margin and letting it follow the user in the same way the TOC does on the left could be helpful, as it allows users to search without needing to scroll to the top. Of course, they could just click the "top" button on the TOC, but some people don't want to lose their place in the article.

But that's minor stuff all things considered. Overall, I think this is rad and I appreciated the effort gone into it. Cheers! Krisgabwoosh (talk) 16:09, 19 January 2023 (UTC)

@Krisgabwoosh: thank you for your detailed feedback and for testing the new skin with a positive approach!

• Unfortunately, anonymous preferences would make the pages load too slowly, more information here.
• Can you give us a screenshot for "the search bar does block an article's lead paragraph"? Are you able to reproduce this issue adding ?safemode=1 at the end of the URL? I would like to be sure to well understand what is happening and if we can improve this aspect.
• About the right side of the page, we will move here the Article tools in next few weeks, more information here.

Patafisik (WMF) (talk) 17:41, 19 January 2023 (UTC)

@Patafisik (WMF): Oh, sure! Here's an image link to what I'm referring to. As I said, it's not a huge deal, just a suggestion. Generally speaking, it's all pretty neat. Krisgabwoosh (talk) 20:05, 19 January 2023 (UTC)

Krisgabwoosh, thank you for asking for us, the minority, a visible link to switch to Classic Style. Most of the complaints are triggered, not because of this and that, but because of the behaviour towards the anonymous readers. I am an editor of wiktionary. I have contributed my little opion as a reader of wikipedias during the survey phase. But now, I am shocked to see that «We are increasing the number of wikis where Vector 2022 is the default, until our improvements are default on all wikis.» All? No votes? For more than 10 years, we vote for 15 or more days to add a comma before the word "and". Suppose 99% vote Yes! we love it!. Why is it not possible to add a link for the 1%? It is just a link. A back-and-forth-button from Classic to V2022. Thank you. From an old woman, 150%-200% zoom (cannot see well anymore), old browser (I do not think I'll change anything in the years left; I started, quite old even then, but more excited, with Commodore64), an en. and el.wiktionarian but frequent unlogged reader of wikipedias, PS.Imagine your wordrobe... I want to see the clothes!!! Sarri.greek (talk)

Terrible!

I'm switching back to Vector Legacy. Jesus Christ, people! Glaring white borders and background? Squeezed screen contents? Really??? Some of you need to find something better to do with your hands. Pyxis Solitary (talk) 16:40, 19 January 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)

Making everyone happy: use the right-hand margin for footnotes and citations on wide displays

A lot of people don't like the new design because of the empty space on the right. I understand the motivation for the change: shorter lines are more readable. But the complainers have a point. There is, objectively, less information visible on the screen at a time.

There's a solution that might make both groups happy: on wide monitors, Wikipedia could display footnotes and citations in the right margin, parallel to their occurrence in the main text. "Footnotes" would be rendered as "sidenotes". So, if the body text says "this phenomenon was discovered by So-and-So in 1993[3]", the right margin would have "[3]: So-and-So: Discovery of an Interesting Phenomenon, Journal of Interesting Things, 1993" at that level.

That way, the page's information density remains high, and it's easier to follow up on citations and notes because you don't have to jump up and down the page. People won't feel annoyed that their monitor real estate is being wasted. But at the same time, the main body text is more readable, as intended.

See also: https://www.gwern.net/Sidenotes 2001:8B0:DFDC:12BC:759:79A4:937E:9CC8 17:56, 19 January 2023 (UTC)

+1. Sidenotes and annotations (links to discussions) in the right margin is a useful layout pattern for active reading, and would be an advance rather than a step back for desktop reading/editing. Sj (talk) 04:53, 20 January 2023 (UTC)

On further thought, you would probably have to put them in both the left and the right margin. The average page's citation density is too high for just one margin. So the left-hand ToC would have to go. 2001:8B0:DFDC:12BC:759:79A4:937E:9CC8 22:22, 20 January 2023 (UTC)

Userscript to automatically change back even if you're logged-out

If you're like me, you do general browsing in private mode. Obviously, I don't want to log in so I can have a sane layout every time I want to just read an article. Hence, I wrote a quick userscript. Have fun: https://gist.github.com/xThunderbolt/759ebf17d8562ab7720a1f2715efd760/raw/wikipedia.user.js EverfreeFaerie (talk) 17:58, 19 January 2023 (UTC)

Some more thoughts on this after a night of sleep (I've already written this below as an answer, but I wanted it here as well):

For me the dealbreaker is that it looks like I accidentally opened a mobile site. In fact, my first impulse when I saw the new skin was to go to the address bar to remove the m. in en.m.wikipedia.org only to find that it wasn't there.

It's as much about the narrow text width as it's about the fact that functionality and information (for instance, which languages the article is available in – I'm multilingual) is now hidden behind clicks, especially the since the space for the former left sidebar is now used as a TOC. I agree that the TOC can be useful, but there was nothing wrong with hitting the Home key and using the Contents box at the top of an article for navigation.

That said, however, I'd really like to use my entire screen width and artificially constraining the width while using a different background color for left and right margins to the screen border makes the layout feel very crammed and claustrophobic, to the point where I literally cannot focus on the text I'm reading.

Additionally, considering the fact that you can't easily change skins while not logged-in (I tend to make heavy use of the private mode while general browsing) makes me strongly opposing this change. EverfreeFaerie (talk) 10:38, 20 January 2023 (UTC)

After messing around with the new skin using my browser's developer tools, I have the following list of improvement suggestions:

• Make the margins to the screen border white as it's for the main text background, or, even better, remove the width limit entirely.
• Make the sidebar elements that are now hidden in the hamburger menu next to the Wikipedia logo always visible.
• Bring back the languages list in that sidebar.
• Bring back the TOC at the top of an article (formerly the “Contents” box).

As for the sidebar TOC, I'm not really sure if it can stay when the other sidebar elements are permanently visible. However, if it does stay, it would be handy if the headline of currently on-screen section was formatted bold, so you have an idea where you are in the TOC. I'm also missing the heading numbers. EverfreeFaerie (talk) 10:51, 20 January 2023 (UTC)

I created a Wikipedia account today explicitly to revert to the Old Skin.

I reckon I'm not the only one. I don't want to rant about it, but it'd be very much appreciated if that option can just... not be taken away, as many other sites tend to do a few months after a user interface redesign goes live. For years, Wikipedia's done a great job of resisting the temptation to fix what wasn't broken, and it's disappointing to see a site as reputable as this succumb to the social media trend of making desktop sites look like mobile sites. 130.76.24.17 18:11, 19 January 2023 (UTC)

Yes, you are absolutely not the only one. I too dislike, the trend to make desktop sites look like mobile sites. Because smartphone and social media over use, reduces the attention span of the average internet user, the internet gets worse and worse for power users. 2A02:1210:9235:3900:3D79:6368:7415:122A 18:55, 19 January 2023 (UTC)

god bless you two my brothers 24.24.158.34 19:06, 19 January 2023 (UTC)

Reduced line length is bad for pages, with math and science content, tables, etc.

Personally, I find the reduced line length terrible.

It is especially bad for pages with mathematics, physics, chemistry and engineering content, that contain formulae content, lengthy mathematical derivations and tables, with a lot of data entries. I doubt, that the studies about line length, take those into consideration. They are probably about text only pages.

I, find myself often use oversized paper, to write math and science content, that is not only text and, have the experience to learn much more efficient, that way. The same holds for web sites, that are not only text. They have a mind map like learning property with text portions, formulae, tables and illustrations, staying on the same spot for longer, if they are on a large screen space, that prevents the need for much scrolling.

I guess, that the studies are about text only content, about simpler subjects, that you read through once, or twice, on the way to understand it. But the more complicated the topic, the longer you stay with it. E.g. for complicated physics texts, I find myself often brooding over one page for extended periods of time. Then I read it often, jump between text fragments, formulae, tables and illustrations. In such cases, it works much better, when everything stays on its fixed spot on a large screen, and you just move around with your eyes. The need to scroll around, makes you loose focus.

Please, please, just introduce a setting, so each user can choose their maximum line length individually. A tag, for pages with above mentioned math, science and table content would be also useful, in conjunction with two separate user line length settings. One for pure (predominantly) text sites, and one for ... lets call them extended data type sites. 2A02:1210:9235:3900:3D79:6368:7415:122A 18:43, 19 January 2023 (UTC) ... or keep the setting to revert to the old legacy view.

New update not allowing me to permanently revert back to old skin

I am not a fan of the new update - It has slowed down my ability to edit pages and aesthetically I find the text too large, the white space too much, and the tools to edit or access other aspects of a page more cumbersome than before. I have repeatedly tried to change back to the old skin via preferences and every time I save my preferences it momentarily goes back to the old skin but when I click on a page or load another wikipedia tab it reverts back to the updated skin. Has anyone else had this problem? Does anyone know how I can keep the old skin permanently? CarCai (talk) 20:19, 19 January 2023 (UTC)

Update: after changing to the old skin once again, it seems to have kept. I'm not sure why it was not working before but it seems to be fixed now. I also wanted to add some clarification to my above "cumbersome" comment, since it takes more precedent than my aesthetic preferences. When the new skin was implemented the change of the Cite feature and the Link feature to a full screen page rather than the previous pop up when editing articles made it take longer to edit pages. However, upon checking this feature again it seems that it has been changed back to a pop up version. --CarCai (talk) 02:46, 20 January 2023 (UTC)

Second Update: I have changed to using the 2022 Vector skin to try it out more thoroughly. After a few days, the aesthetic of it was growing on me. I think there were only 2 thing I personally kept noticing during my use. One was how much I had to scroll with the new skin. I understand this may be more desirable for some but it was a little clunky compared to the old version. I saw that someone had found a way to disable the max width, which helped some. Secondly, I wish there was an option to customize which icons appear in the top right corner or be able to see all of the icons at once. I think the drop down menu looks cleaner but for me it is not the most practical set up. CarCai (talk) 06:35, 27 January 2023 (UTC)

Re: The iterative design of the Vector interface: the case of moving interlingual links

FAQ item Why do you use the word Improvements? links a February 2022 blog post interlingual links in Vector 2022, as if it were in support of the claim, while actually it states that the only available data confirms a drop in clicks on interlanguage links, which most people would agree is not an improvement. Nemo 20:30, 19 January 2023 (UTC)

Brilliant! Remove the road, then boast that there's less traffic on that road. It's like I'm stuck in an episode of "The Thick of It". Skoinksx (talk) 05:32, 20 January 2023 (UTC)

How to view top right words without using icons

Hi, in the new vector skin, the clock display is now in the collapsed part. Is there a way to always be able to view the clock? Also, I'm not a fan of icons, on my regular browsers I always display the words and not just the icons. Is there a way to do this too? In the meantime, I guess I'll switch back to the old vector version. Funandtrvl (talk) 20:56, 19 January 2023 (UTC)

Also, I guess the clock doesn't display because the gadgets don't work in the new skin. So, I'll have to use the old skin until I can figure out if the custom java script will work in the new skin??!! --Funandtrvl (talk) 21:03, 19 January 2023 (UTC)

Just Plain Bad

To be plain and simple, the new mode of Wikipedia is horrendous. No one enjoys it. My biggest complaint is the massive amount of blank space, it hurts the eyes and just makes for a longer article requiring more scrolling. There were never any complaints about Wikipedia's formatting, why have they decided that now is the time to suddenly change it? My guess, in all likelihood, is that Wikipedia wants to introduce advertisements, and is in the process of freeing up space to put said ads in. And this is only supported by their wholehearted refusal to make any sort of manner in which one could easily revert back to the older style of Wikipedia without an account. They claim that it's not feasible, but that's bologna. Many other websites have implemented similar practices, and this would be no different. No, I imagine their refusal stems from greed. Soon even accounts are unlikely to be able to revert back, probably unless they pay, and advertisements will become the norm on Wikipedia. 198.21.196.110 22:07, 19 January 2023 (UTC)

i hope even remembers this when it comes time to donate this year. 2404:4404:1758:400:D0DD:34B:113:A992 22:11, 19 January 2023 (UTC)

Hi - thanks for your feedback. I just wanted to clarify and confirm that Wikipedia and all Wikimedia wikis are free and we will not be putting advertising on any of our pages, or require users to pay for the information they read or re-use from the site. If you're interested in learning more about the way these changes were designed or specific design decisions, we encourage exploration of our FAQ. OVasileva (WMF) (talk) 01:03, 20 January 2023 (UTC)

My issues with this layout

On some devices (including mine), you have to zoom out to even be able to see the toggle limited content width button, and on others, it's not even visible! Why this design choice?

And even when you do manage to sleuth out where the button is, the wasted space on the right side of the TOC is just overwhelmingly large. The un-cramped layout still feels extremely cramped!

You say on the overview page that the old design isn't consistent with the mobile version. Why does this matter again? And on the FAQ page you say that a lot of websites have this same cramped look. But why do you need to conform with that design standard? Using The New York Times as an example is horrendous. Have you even looked at how much white space is on that page? 2/3rds of their pages are white space, and that's not even an exaggeration!

Overall, most of us were fine with the old look. We don't really need a pointless redesign to make Wikipedia look more "modern". All it does is make it look more corporate! EleKtr1X7881 (talk) 22:24, 19 January 2023 (UTC)

Thanks for your feedback @EleKtr1X7881. We are currently making some changes that will allow the toggle to appear at lower widths. You can track our progress in this ticket. We have some information in the FAQ about the academic studies, as well as our own research that was used to determine the new width for the page - you can find some more detailed documentation here as well if you're curious. OVasileva (WMF) (talk) 00:59, 20 January 2023 (UTC)

I'm curious

Hi. I'm trying to understand. All these people do not like the new Vector because the text has less width. I like it very much, for many reasons, but especially because this is the only skin where the text has extremally more width. Did enwiki users get different version of the design, or something? IKhitron (talk) 23:35, 19 January 2023 (UTC)

For me the dealbreaker is that it looks like I accidentally opened a mobile site. In fact, my first impulse when I saw the new skin was to go to the address bar to remove the m. in en.m.wikipedia.org only to find that it wasn't there.

It's as much about the narrow text width as it's about the fact that functionality and information (for instance, which languages the article is available in – I'm multilingual) is now hidden behind clicks, especially the since the space for the former left sidebar is now used as a TOC. I agree that the TOC can be useful, but there was nothing wrong with hitting the Home key and using the Contents box at the top of an article for navigation.

That said, however, I'd really like to use my entire screen width and artificially constraining the width while using a different background color for left and right margins to the screen border makes the layout feel very crammed and claustrophobic, to the point where I literally cannot focus on the text I'm reading.

Additionally, considering the fact that you can't easily change skins while not logged-in (I tend to make heavy use of the private mode while general browsing) makes me strongly opposing this change. EverfreeFaerie (talk) 10:33, 20 January 2023 (UTC)

Revert back to old layout

The new layout is extremely bad and useless. Please revert back to the old layout. Sunlitsky (talk) 00:05, 20 January 2023 (UTC)

+1 2600:4041:5129:A100:8CBB:AE61:E85:9B61 00:07, 20 January 2023 (UTC)

Is the extreme amount of white space just my computer or is it for everyone

Hi, long time editor here, this new format seems to have giant white spaces for me surrounding nearly everything. Is this a problem with my settings or is this how it should look? If so, why? Or is there a way to revert to the older format, this just seems like such a waste of space. Thank you. Mattximus (talk) 01:13, 20 January 2023 (UTC)

You should be able to change it back by going to your preferences → Appearance → Skin → Vector legacy (2010). Tenryuu (talk) 05:51, 20 January 2023 (UTC)

Upcoming Page Tools sidebar: font size and line spacing too large

This is a comment about the upcoming Page Tools sidebar, which is visible by going to https://en.wikipedia.org/wiki/Universe?vectorpagetools=1

At least in my browser, the font size and line height used in this Page Tools sidebar, as is true with the font size used in the Table of Contents and Main Menu when they are pinned to the left sidebar, are all much too large. My browser tools "inspector" feature tells me that the font size in all three of these sidebar menus is the same as the font size in the main body of the article. In Vector 2010, the sidebar text is considerably smaller, with narrower line heights, allowing much better information density and the ability to scan for the desired option easily without having to scroll.

I have had to use custom CSS to restore the left sidebar and sidebar TOC to a reasonable (i.e. smaller) size and line spacing in Vector 2022, and I will have to do that with the page tools if the size stays the way it is.

I can post screen shots here or to a phab ticket if I am the only one experiencing this suboptimal UI. Pinging Jdlrobson, who suggested that I post comments here. Jonesey95 (talk) 01:28, 20 January 2023 (UTC)

I see the same: standard body-text font size, and uniform line-spacing similar to a bulleted list in the body, make both right and left margins rather hard to read or to distinguish from body text. Sj (talk) 04:57, 20 January 2023 (UTC)

If the font size in those sidebars were reduced to the Vector 2010 size, the sidebars could be made much narrower while showing the same number of characters per line. This would make more space available for the page content, which is highly desirable (especially with two sidebars instead of one). Jonesey95 (talk) 05:48, 20 January 2023 (UTC)

Oops, Jdlrobson, it appears that the sidebar was deployed with these problems in place. Here's hoping for a quick fix (or temporary revert). Jonesey95 (talk) 22:12, 23 January 2023 (UTC)

The new look is objectively bad in all aspects

Title says it all. It should be removed, and should not be offered to anyone even as an option. Whoever came up with this design should absolutely get the boot for intentionally trying to make something that was good, worse. Firethenewlookdevs (talk) 01:36, 20 January 2023 (UTC)

It completely sucks. Awful change for no benefit. 2601:1C0:847C:20E0:2916:6FC4:D7FE:80E5 17:23, 20 January 2023 (UTC)

I love the new layout

Ok time for another year long hiatus DecrepitlyOnward (talk) 02:38, 20 January 2023 (UTC)

The New Layout is a Mistake

At a minimum, the old layout should be switchable to the old one without the need to create a new account simply to avoid a badly-designed alpha build of a mobile web page. No, Jimmy, I will not be donating to Wikipedia again. 72.66.99.185 02:40, 20 January 2023 (UTC)

Add a way for logged-out users to easily revert back

I don't personally have an issue since I have an account and can use Global Preferences to reinforce my dislike of the new redesign by having all wikis revert to the old one, but there are logged-out users who do not have this option. There is a lot of complaining on social media about the redesign, and people are already making Chrome extensions that revert back to the old version. I really think something should be done for those people. RPI2026F1 (talk) 02:55, 20 January 2023 (UTC)

I made an account for the sole purpose of getting rid of this skin. So I support this with both hands. 213.191.204.121 14:48, 20 January 2023 (UTC)

Why not take a new vote or do new rounds of surveys?

Seeing a lot of back and forth on the change to Vector 2022. I get that there's been rounds of feedback throughout development, even specifically called out as being mostly positive here: Talk:Reading/Web/Desktop Improvements#Old style TOC in Vector-2022 Skin.

However now that this change has actually launched, rather than making this decision on a sample size of ~170 users why not open the vote to Wikipedia users at large? Put a banner on the top of articles similar to the donation banner and see how desktop users actually respond. If the attitude of "we know change is scary, you'll get used to it, we've done research!" shown in this condescending article must be forced I'm sure a developer would love to make sure that banner shows up only on devices that have had the new layout for "long enough". You could even randomize that, see what a user thinks on day 3 vs day 15.

I appreciate the effort and research that's gone into Vector 2022, I see the value in looking forward and always trying to improve. Clearly in this thread and in many others there's a lot to be said about Vector 2022. I think it would be foolish to miss this opportunity to see if people do actually like the change over time or if they just accept it. Do the follow up on the research that's been done and see if the results are as expected. Zdwagz (talk) 02:57, 20 January 2023 (UTC)

Completely agree that this would be useful and appropriate, as would implementing viewing options for logged out/no account users. Such things would demonstrate good faith (as opposed to the "condescending" tone now being taken.)

Kilometers to Verona (talk) 04:58, 20 January 2023 (UTC)

RfC on the English Wikipedia

Please note that there is an RfC on whether Vector legacy should be restored as the default skin on the English Wikipedia. If you would like to participate in the discussion, you are invited to add your comments at Wikipedia:Requests for comment/Rollback of Vector 2022. Thank you. InfiniteNexus (talk) 05:06, 20 January 2023 (UTC)

Why not take a new vote or do new rounds of surveys?

Seeing a lot of back and forth on the change to Vector 2022. I get that there's been rounds of feedback throughout development, even specifically called out as being mostly positive here: Talk:Reading/Web/Desktop Improvements#Old style TOC in Vector-2022 Skin.

However now that this change has actually launched, rather than making this decision on a sample size of ~170 users why not open the vote to Wikipedia users at large? Put a banner on the top of articles similar to the donation banner and see how desktop users actually respond. If the attitude of "we know change is scary, you'll get used to it, we've done research!" shown in this condescending article must be forced I'm sure a developer would love to make sure that banner shows up only on devices that have had the new layout for "long enough". You could even randomize that, see what a user thinks on day 3 vs day 15.

I appreciate the effort and research that's gone into Vector 2022, I see the value in looking forward and always trying to improve. Clearly in this thread and in many others there's a lot to be said about Vector 2022. I think it would be foolish to miss this opportunity to see if people do actually like the change over time or if they just accept it. Do the follow up on the research that's been done and see if the results are as expected. Zdwagz (talk) 02:57, 20 January 2023 (UTC)

This discussion seems a copy of a precedent message, please answer above. Thank you, Patafisik (WMF) (talk) 16:05, 20 January 2023 (UTC)

Hi @Zdwagz - thank you for your comments and your ideas here! We do plan on running a survey after the change across all users, as part of our overall analysis on whether the rollout and the new skin is successful. We've posted an update with immediate next steps as well as what we're specifically looking for on the English Wikipedia technical village pump. OVasileva (WMF) (talk) 16:40, 20 January 2023 (UTC)

Challenges: TOCs + magic words; protected templates breaking; sidebars

TOC

• Magic words like / are no longer being respected.
• Some pages expect an expanded TOC by default as an important part of the page presentation. There should be a [new] magicword for this, at least
• After hiding the sidebar TOC it is impossible to find and restore again. Why not use the familiar [show]/[hide] style used everywhere else?
• Long TOC lines, and long vertical TOCs, involve line wrapping and scrolling, but it's hard to see a distinction b/t the TOC and the content (no background color difference, almost no font size difference)
• When scrolling down a long page, the flickering of the TOC as it automatically scrolls too, and as different sections get auto-highlighted, is disorienting for me. Others have described vertigo. Something that does not draw attention would be better.

Major templates (which have their own mechanism for breaking up long lines)

• < div col > now breaks on many pages. I'm not sure why. That's a traditional way of making better use of screen width with multiple narrow columns.
• References-section multicol still works, but are now constrained to the narrower body div. They should be able to use the full screen width instead.

It's one thing to leave the long tail of templates out of scope, but less so for core templates used everywhere. And in these examples, a functional way of using the entire available screen to show a lot of useful information with short line widths has been degraded. Reference display is universal enough -- and a large enough % of all page scrolling, especially on high-traffic pages -- to be worth treating with care.

Sidebars generally

These feel like they're getting the short edge of the page. The placement of the various buttons at the top (for collapsing part of the sidebar, for collapsing the TOC) seem less coordinated than the rest of the topnav; the padding between the right edge of the l.h.s. and the left edge of the main content seems large, even by the standard of the new design. The "switch to old look" and "look elsewhere for languages" notes in the l. sidebar seem hasty, somehow. The current draft of tools in the r.h.sidebar suggests further changing font and linespacing. I don't have more specific comments, just... please treat these parts of the skin with love. ~~~~ Sj (talk) 05:27, 20 January 2023 (UTC)

On my screen, the fundamental cause of the above column-related problems is the width allocated to the non-sidebar page content. Div col and reflist columns on en.WP are 30em wide by default. In my browser window, I have about 86em (950px) of page content space to work with because the wide left sidebar and TOC are still taking up too much horizontal space. And this is after I used my common.css file to reclaim a bunch of space on the left and right sides. In Vector legacy, I have 94em (1038px) for the content because the sidebar is appropriately narrow.

See the comment above about the font size in the left sidebar and the (coming soon) right sidebar. If the font size in those sidebars were reduced to the Vector 2010 size, the sidebars could be made narrower while showing the same number of characters per line. This would make more space available for the page content, possibly allowing enough space for 30em to be a meaningful column width. Jonesey95 (talk) 05:46, 20 January 2023 (UTC)

About the magic words: I mentioned that last year in phab:T273473#7873275, will try to follow up on it! XanonymusX (talk) 12:39, 20 January 2023 (UTC)

And, please consider wiktionaries which are dictionaries, not encyclopaedias. And also please consider small wiktionaries, who do not have volunteer progammers to make nice adjustments for us. See my asking for help from TOC programmers at enWP Not to mention 'interwiki languages' We rely on the mother-language-wiktionary, and heavily on en.wikt for ProtoIndoEuropean etymologies, etc. They must be immediately available (of course, we can write links with their addresses at the See also section: an extra task). Thank you for this post, from el.wiktionary, (Central)Sarri.greek (talk) 10:53, 8 February 2023 (UTC)

Too Much Whitespace?

Personally, I like the new look of Wikipedia, and I would use it except for one thing...

I read through your articles discussing the new maximum width and all the science behind why it's a good idea. I understand why you did it. That said, I like being able to see more information at once on the same screen. The new max width makes it so about a third of my screen is just empty whitespace. It looks as though someone took a UI designed for a phone screen and stuck it in the middle of my large 16:9 monitor without adjusting margins.

If you add the ability to disable the max width (even if it's just in the preferences tab for logged in users like the current UI settings are), it would be much appreciated.

I know there are going to be a lot of people hating on the new UI just because it is new and not what they're used too, but it's genuinely pretty good. I'd just like to make more efficient use of my screen real estate is all.

Until then, I'll be sticking with the old layout.

- Zman350x (talk) 05:47, 20 January 2023 (UTC)

Update: After doing some more digging, there is a setting in the user preferences to disable the max width. Gonna leave my comment here in case others w/ the same issue stumble upon it.

If you want the text to take up the full screen, uncheck the "Enable limited width mode" box.

- Zman350x (talk) 05:53, 20 January 2023 (UTC)

Thank you @Zman350x for your feedback, for other users reading this discussion: here are instructions about How to expand the width of the new skin. Patafisik (WMF) (talk) 10:45, 20 January 2023 (UTC)

This was all caused by fucking iphone users, Wikipedia was always 16:9 why change something that's not broken to appeal to people who are to dumb to change their websites in safari from moblie to browser if they wanted to have this for smartphone users only thats fine but forcing it upon people who dont make an account is smiley af

I know the JP Wikipedia does the same thing but English is the most used there should have been a vote Caspian Delta (talk) 14:52, 20 January 2023 (UTC)

Can we please have an option for the menu options (Talk, sandbox, etc.) to show in the header all the time.

Most times I visit wikipedia I click 'Contributions' first, to quickly get to articles I'm actively working on, or visit talk page sections I've recently commented on to see if there are any updates. Having to expand the menu in the top right to access this each time is annoying, having an option to put the 'Contributions' link the header next to the link to my user page (which I never use) would be ideal. Ideally all of the options could (optionally) be promoted to the header, but I think 'contributions' and 'talk' are probably the most accessed, I'm sure you have stats on that.

JeffUK (talk) 11:25, 20 January 2023 (UTC)

If anonymous switchbutton slows why not

About this: #Why are there no preferences for anonymous users? (by 'preferences' I now mean a switchbutton to Classic view with https://www.mediawiki.org/wiki/Special:GlobalPreferences#mw-prefsection-rendering hopefully placed on top of all pages everywhere because of the recent events.)
I know zero about computers. I understood that is slows everything too much, that it is very expensive. Then, why not give automatically a pseudousername to everyone who enters? For 5 minutes, for 4 hours, ... and when they leave, that username evaporates. Excuse my ignorance, apparently this is a silly thought, because too many usernames could also be a problem. But I am confident that all these brilliant young minds here, shall find a solution! Sarri.greek (talk) 14:20, 20 January 2023 (UTC)

Hi @Sarri.greek - thanks for your question! It is indeed a complicated problem. The general issue with automatically giving people a username is similar to reason stated above - we don't currently have the server capacity to show every article directly - we only show the update if an article is edited or goes through other changes. If it's static, we pull it from our cache (i.e. show a "snapshot"). However, we are currently looking into the possibility for making the toggle at the bottom of the page persistent. If you're interested in more details, progress can be tracked in this ticket. OVasileva (WMF) (talk) 16:31, 20 January 2023 (UTC)

Thank you very much for taking time to respond to a naive question. OVasileva (WMF), since the general public of unlogged people were unaware of a switch I think a notice by the foundation addressing them directly would be appropriate. Thank you. Sarri.greek (talk) 17:09, 20 January 2023 (UTC)

Style problem with Vector 2022 and Firefox

Images can overlap with references when using Vector 2022 with "Enable limited width mode" disabled and while using Firefox (no problem with chrome).

For example, on 2k22 Tunguska, the "Map of 2K22 operators" and "2S6 Ukrainian Army" images at the bottom of the page.

Can be fixed with:

.mw-parser-output .reflist { overflow: hidden; } Raptor1335 (talk) 14:25, 20 January 2023 (UTC)

Thanks for the bug report @Raptor1335! I can confirm that I'm seeing the same issue. We'll look into it and update here with a ticket for tracking. OVasileva (WMF) (talk) 16:19, 20 January 2023 (UTC)

Information hidden with Vector 2022

With the new skin, many options no longer appear. It is by no means obvious that clicking the top left unlabeled icon will make them available.

There is a huge amount of white space at the beginning of each article, forcing me to page down in order to see the changes or text. Chatul (talk) 15:23, 20 January 2023 (UTC)

Content tables years missing

Is there any way too see the year i.e. Career beginnings 1981-1983 with the year again like it used to be? Aaron106 (talk) 16:46, 20 January 2023 (UTC)

Aimed to help you

Hello everybody there. I'm critical with the changes, as I left here https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Vector_2022_Post-Deployment_Update_from_WMF_team

This said, I copy here my appreciations, with personal comments stripped, only the main improvable points.

The main strong point of the previous UI is not aestetics: it is its solid and consistent layout. With it, every page in Wikipedia has the same distribution of heading, left panel and content, no matter what content: main page, articles, view history, talk, editing, templates... everything. So it is very comfortable to use. "Show preview" while editing shows exactly what you get when changes are saved. Simple, comfortable and efficent.

Now you've broken that experience:

1) Main page items are distributed centered by default (leading to the wasted space issue, in a page in which the maximum line length has no sense, it's not an article), but if you click the "three bars" button, all moves when the left side bar appears. Collapse the menu, and all moves again to be re-centered. Not good impression.

2) Open an article with TOC and you see one thing. Open an article without TOC (example: https://en.wikipedia.org/wiki/Mystery_meat_navigation), and you see other thing. Not consistent layout.

3) About the TOC in itself, I'm not opposed it to be permanently at hand, but it should have light grey background to clear visual differentiation, and being now a tree, it has lost its numbering scheme, being hard to know at a glance where you are in the article. Please get back the numbering scheme, and let the tree expanded by default. It tracking you all time where are you reading is an annoying flickering. Have you ever read about peripheral vision? And bad layout also, in my screen TOC does not occupy the full height, more white at left-bottom.

4) Edit a page section, and there is no space at left (What happened with the maximum line length rule?) Write something, include some images and/or tables, etc. and "Show preview": you see one thing. Save changes and... you see a different thing. Inconsistent again.

5) The search bar now tries to "read your mind" offering you the guessed suggestions. Before, it was a simple, quick and efficient search by title, with an "Advanced search" option. Now the search is slower, and offers less choices when the intended page starts with very common words, like "national" or "electron", lets say. As far as I tried, no "Advanced search" option (or not obvious if it has, so not a good design anyway). Previous behaviour should be an option, at least.

6) Incidentally, if you solved the text width view issue with a toggle, Why not more toggles to switch between, lets say, the search bar behaviour, or any others? Not my favourite solution, but you opened the game.

7) And finally, the wasted space issue. If you want to implement the maximum line width, at least limit it to the article frame, not all the page, and only for articles. And if you want to make the articles more book-alike, at least draw some borders and put a grey background, like a document in MS Word, lets say. Many people has visual problems with light backgrounds. Screens emits light, they are not ink-on-paper (reflective). RGB white light emits more high-frequency (blue) than other warm hues, and it is known it hurts the eyes. If empty, please fill these spaces with light grey or similar, to attenuate.

Hope this help. Regards. 37.134.90.176 16:54, 20 January 2023 (UTC)

Simply ugly

Really? Please do it more appealing for eyes, please... Ensahequ (talk) 18:43, 20 January 2023 (UTC)

Lack of visual contrast between areas of the page

I missed the original discussions, so hopefully there's still some room for feedback here. The reduced content width is actually one of the main things I like about the new skin as someone using a wide monitor, and the main reason I started adopting it a few months ago.

My main complaint is the lack of visual contrast between different areas of the page. Only the sidebar has a visual background and border separating it from the rest of the page, as well as infoboxes and templates within the article itself. Everything else is a sea of white: the article body is narrower than the white content area, increasing the appearance of unused space to the right and leaving no defined border around the content. There is no obvious separation of the header at the top of the page, reducing the apparent personality of the site.

There are also no borders between the TOC and the article section unless the TOC is long enough to show a scrollbar, which makes its appearance inconsistent. The TOC is also harder to identify because the "Contents" header is now in normal font and less emphasized than the current highlighted section of the page, as opposed to the old skin which has "Contents" in bold, and is hidden once the contents are long enough.

There are a number of unintuitive elements in the UI as well, namely the toggles to show or hide the sidebar and TOC. The positions of the header elements (search bar, talk, edit, history, and language dropdown) shift around when scrolling down enough for the logged-in floating header to show. The search icon position in particular is unintuitive, being moved to where the logo normally is.

These issues are magnified when toggling full width or having a narrower screen. There's no background change at all and the entire page only has the single white background, and the icons and links in the header are pushed even further to the sides.

Would it good idea to move either the sidebar or TOC to the right side of the page? This stops them from fighting for the same space on the left and partially resolves the issue of the right side being completely unused. -Sonicwave ^(talk|c) 19:35, 20 January 2023 (UTC)

This lack of visual contrast is what's bothering me too, I think it makes my eyes strain more than before. I also was frozen for a moment when I clicked [hide] on the TOC for the first time and it just disappeared into the void. I actually had to reload the page and click it several times to find out how to enable it back. Sometimes I encounter very unintuitive UI on the Internet but I was surprised to see it here, on one of the most visited sites in the world. RoadTrain (talk) 02:46, 23 January 2023 (UTC)

Thank you for your detailed feedback @Sonicwave32. We were working with the American Foundation for the Blind to improve accessibility of Vector 2022 but some changes are still in progress, look at T318373 and T310033 for further information. The Article tools will be soon moved to the right side of the page (you can see a prototype here). Zapipedia (WMF) (talk) 16:43, 23 January 2023 (UTC)

I'm also sharing this complaint. What i described was it was all borderless with no defined space. It gives it a "floaty" look.Blue Pumpkin Pie (talk) 23:29, 20 January 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)

If Wikia/FANDOM already did it and it sucks, how is this any better?

When FANDOM (known back then as Wikia) updated their Oasis skin to be skinnier, it was virtually hated by every single editor at the time. All it did was make articles cramped and harder to read, and forces infoboxes and photos to take up a larger percentage of the width than intended. Fandom mostly did this to make more room for ad spaces, which everyone also universally despised.

so how is this update helping anyone? The Rim of the Sky (talk) 23:13, 20 January 2023 (UTC)

Suggestions to fill right-side whitespace

First, thanks to the new redesign, it's fantastic.

Second: could you try out a few prototypes that would fill the white-space on the right side? That might address the criticism by some people, and it would still limit the width of the contents. Here are the ideas:

• Don't include impose a content width limit on infoboxes and right-aligned thumbnails. If the page gets wider, the images & infobox can move beside the contents, so it gets more space to breathe.

• Bring up references on the right, instead of scrolling the user to the bottom of the page. It would look like this (though it could be made cleaner & more usable than that).
• The 2nd point would be especially nice if it could prevent the 2-steps necessary to read shortened footnotes (Sfn). Currently, click on a footnote, and you get scrolled down to, say, "Hawkins (2020), p. 4". Click on that, and you go to the reference, but there's no button to go back to the contents from that second reference (that button is only on the footnote). Usability could definitely be improved there. This would bring strong encyclopedic benefits, since it would help people follow the references more conveniently.

Note: I'm not suggesting that my two ideas would necessarily be better than the current version, which is basically perfect as-is. They're just things that I'd like to see tried out; maybe they'd be better. DFlhb (talk) 23:54, 20 January 2023 (UTC)

Thank you very much for your constructive feedback @DFlhb. I will pass your suggestions to the team. Indeed, whitespace at the right will be soon occupied by the Article tools. Zapipedia (WMF) (talk) 16:47, 23 January 2023 (UTC)

Preference for turning off sticky header?

I tried to disable through user global.css per Reading/Web/Desktop Improvements/Frequently asked questions#How to disable the sticky elements? but seem to hve been unsuccessful. It would be nice to simply have a display preference to disable the sticky header. Mike Linksvayer (talk) 00:00, 21 January 2023 (UTC)

Conversely, I would like a way to enable the sticky header on every page, instead of only in a selection of namespaces. If someone could post that CSS/JS here, that would be helpful. Jonesey95 (talk) 02:04, 21 January 2023 (UTC)

New layout change sucks

Too much white space and it's not immediately clear that the side bar are the contents as well as it feeling inconsistent with the rest of the design. I can see the benefit of the the contents being on the side, but I feel this only supports a small amount of work flows. I don't like reading based off of content links and instead like skimming the article and the title of each section helps remind me where I am and only like looking at the contents as an overview before and after I read. The new layout seems to assume that I will navigate the article by the content links and it reduces how much article can be read at once as a consequence. In addition, "Contents" is not bold like it used to be and, with my workflow, I'm left with this useless thing on the side while I'm trying to read the article before I remember or focus my eyes on that area rather than the article I'm trying to read and see that it's contents. I can hide it, but then I can't see and overview of the article when I'm done reading to make sure I didn't miss anything without moving my mouse and clicking something or moving my hands to my keyboard in case I'm missing that there's a keyboard shortcut for this. This is inconsistent because the description box on the right side is shaded and separated and made clear that the information and links there are separate and serve a different purpose than the rest of the article, but this context box doesn't and relies on the user seeing and judging white space to mean separation rather than a tangible, meaningful shade and/or separator. This change to the default layout is horrible the more I think and write about it. I think the amount that could be read at once being reduced could be mitigated by a visible separator, but there is still a lot of article that is truncated. Before you say that hiding the article actually increases the words on the screen compared to the previous layout, the aforementioned problem of not being able to see an overview of the article by scrolling up and not clicking anything or moving my hand persists. I can see an argument for this design change for power users as control + F existing and hiding the bar increases the words on the screen, but people with workflows similar to mine are being left out. Neverletitbe (talk) 00:09, 21 January 2023 (UTC)

Scrap the 2022 skin

This new skin has no perks at all. Just put it to rest quietly, noone will miss it. 37.247.31.205 00:21, 21 January 2023 (UTC)

Sorry, I agree. --Ensahequ (talk) 02:24, 21 January 2023 (UTC)

I agree too. Scrap this weird skin or move it to the mobile version of Wikipedia. No one will miss it. Nothing in Vector 2022 is better or attractive at all. Nothing. I'm shocked how some people say they like it, what is to like in this weird layout made for phones? 94.26.15.134 02:44, 28 January 2023 (UTC)

Why, WMF, Why

Hate it. Like many others, I legitimately thought I somehow navigated to the mobile site, but then couldn't escape. Here's why I strongly dislike it:

1. I've had neck problems since I was a child. This layout moves the article three inches off-center, more than twice what the sidebar used to be, so I have to read at a much more significant rightward angle. Normally I use Wikipedia daily and do long deep-dives at least once a week. Today, I only read one article, and I'm already in so much pain that I am currently reading this out of the right side of my right eye, with my head turned about 45 degrees left to alleviate the pain in the left side of my neck. I have never experienced this level of pain on any other website, ever. This is an important discussion that people with neck problems shouldn't be excluded from, so I've kept reading here despite the pain, but I keep having to take breaks, massage my neck+shoulder, and toss my head to relieve it somewhat.

But sure, of course, it's “more accessible.” So accessible, I'm not going to browse this website until someone develops a Firefox extension to fix this. But hey, maybe I can put some tape markers on my desk and slide the monitor three inches to the left every time I use this website, and then slide it back every time I navigate away? That's the sign of an amazing user experience, I've heard.

2. Was there even one single person who tested this who didn't have a gigantic monitor? I've seen a number of responses from defenders on various pages, insisting that the UI is superior for wider monitors. Neat. How nice for them, if true. Except many of us don't have one of those! It is terrible for smaller, or even medium-size, monitors. Why are wide monitors the only ones WMF cared about? I'm morbidly curious to try booting up my older laptop, which has a very small screen, because I suspect that the article will be crushed to literally one inch in the middle. I'm not being facetious when I'm wondering if WMF is now intending to cater primarily to rich users who can afford huge monitors, since they do probably make more donations. That would honestly make more sense than any other excuse I've heard today.

3. Why does WMF hate desktop users? If you wanted to drive us off, this was a great way to do it. People who want mobile will be on the mobile website already, even when using a desktop machine. The desktop version has essentially been entirely removed. In practical terms, there just isn't a desktop version anymore: there's two mobile versions. People who use desktops do so because we like having more power, not because we secretly yearn to to have our options amputated in favor of limblessly “sleek” mobile design.

4. I read the crap about whitespace being “restful” for the eyes, but that's trash at this sheer scale. That much white is causing me noticeable eyestrain in a far shorter time because it is blindingly bright. At least change some of it to gray! Actual people are telling you it hurts their eyes and is unfriendly to the brain, but no, you seem way more intrested in your "data" than the human people telling you it sucks.

5. It's a very interesting choice, for WMF to have only advertised the new layout in advance to logged-in users. I was bewildered when I first saw people insisting that there was over a year of banners and such, because I never saw a one. Then I realized this was not anything I would have seen, because I rarely log in. WMF is well aware that most people who use Wikipedia don't even have accounts, and yet they never solicited any kind of feedback from the readers at large?

I'm also really irritated with them trying to claim that more people creating accounts is some kind of triumph, when there is no way to reverse the changes otherwise. Guarantee you that absolutely no one looked at this layout and went, "Oh wow, I wasn't going to register, but now that I've seen this skin, I will!"

Not to mention completely ignoring the RfC, either the agreed-upon changes that were never made, or the majority opposition causing a total lack of real consensus. Y'all also did a poll and more people disliked the new layout than liked it, so what on Earth are you doing? At every point, you've seen more people disliking the skin than liking it, but you've gone full speed ahead with minimal changes anyway.

6. I asked the other members of my family about this. Neither was present for the other's experience. I did not prompt or lead either one in any way, just told them to navigate to any Wikipedia article on their desktops.

My mother, who is 66 and knows absolutely nothing about UI design, uses Wikipedia a few times a month. Her first comment was, “What is all this white?” while pointing to the TOC sidebar, and her second was to observe with exasperation that she was going to have to scroll a lot more to read. She then compared it to recent changes in Microsoft Outlook that narrowed the reading pane, which she hates.

My brother, who is 38 and knows plenty about UI, does not use Wikipedia often. When he saw the changes, he said, “Oh, they've mobilized it,” in an exhausted tone. I told him it was supposed to be better for wide monitors, in response to which he looked at his wide monitor—which was more than half empty, and half of what wasn't empty was sidebars—and incredulously repeated, “It's supposed to be better for wide monitors?” like he genuinely thought he hadn't heard me correctly. He then compared it to the horrifically bad UI at wikia/FANDOM, which he hates.

So there you have it: three people immediately hated it upon seeing it! Look, I gathered almost as much feedback as WMF did!

7. I mentioned the neck, right? PHYSICAL PAIN

8. The best way forward, IMHO, is actually to have some kind of old.wikipedia.com, similar to m.wikipedia.com, and put a toggle at the top for a few months to let people know where it is. It would solve 100% of the problems with logged-out users. Have to say, though, it's kind of grimly funny that half the alleged reasons for refusing logged-out preferences are supposedly about “privacy,” as though forcing to stay perpetually logged in (and thus precluding private browsing or sensible cookie-deletion) is more secure.

However, the obvious hostility from the WMF makes me think they're extremely unlikely to consider anything that doesn't have the ultimate endpoint of forcing everyone to use this crap. Not holding out much hope. Blustreak (talk) 01:06, 21 January 2023 (UTC)

I like the new design!

I'm a big fan of the new design, and I think a lot of comments here are ignoring the research into the benefits of the text width that's been chosen. Keep up the good work, WMF! Nicereddy (talk) 02:34, 21 January 2023 (UTC)

Research can be used to justify a lot of things, and I think its pretty clear from the response that there are issues that need to be addressed. I don't mean to imply that a lot of real research wasn't used, but vector 2022 has a way to go before it can be truly accepted. WikEdits5 (talk) 09:14, 21 January 2023 (UTC)

Improvements that could be made

I have grown to this new design and am starting to quite like it now.

However, I believe there are still a couple of big improvements that can be made to this redesign.

First, and by far the foremost: so you know how the new design has the table of contents always fixed on the left side, even when you scroll down the page, for better accessibility / navigation? Well, I would like to see the hamburger menu on top left corner (the one that the random article, recent changes, user contributions, etc handy buttons in it) be fixed in the top left corner of the screen also when you scroll down. As it is in its current state, I have to make three button presses if I want to click on a button there – press the home key on my keyboard, move my mouse to that hamburger menu button and click it, and click the button I want. With Vector 2010, all the menu buttons are there and not contracted, which means one less click. With this new design however, having that hamburger menu always shown and fixed in left sidebar would eliminate the need to press home key or scroll to top of page, which also means one less button press.

Second, and this is more of a smaller one, but: it is regarding the content width limit. A lot of the complaints seem to be coming from users that have high resolution widescreen desktop displays such as 16:9 1440p. I have an idea: have several "levels" of content width limitation for various resolutions. 'Medium' desktop resolutions use a, let's say 1800 pixels wide content width, and then for high resolutions like 2560 pixels wide, use a 2200 pixels wide content width, for example. So that there is a healthy amount of white space but not too much of it on large displays.

Thirdly, this one's also minor, but maybe provide the user an option to have all the menus (e.g. log in/out and contributions menu, and the top left hamburger menu) always expanded / display all the items instead of contract them.

I think that's pretty much it for this one.

Some things I really like about the Vector 2022 skin are the much, much better display of search results (bigger text, displaying of short descriptions and thumbnails on results) along it being in the centre, and the table of contents always being displayed on the left. Previously you had to reach top of page to find ToC to navigate to another section. AP 499D25 (talk) 10:37, 21 January 2023 (UTC)

Why is the log in button hidden behind the three dots symbol?

Currently, on Vector 2022, the top right corner shows the button "Create Account", as well as a symbol of three dots. The log in button is hidden behind these three buttons. Why is that? This means that users need unnecessary amount of clicks to log in. The corner has plenty of empty space, so the log in button would fit well next to the "Create Account" button.

If the white space in the top right corner is for some reason important, why isn't the log in button visible and account creation behind the three dots symbol? After all, users usually only need to create an account once, but they need to log in many times. Valtaisa varpunen (talk) 12:34, 21 January 2023 (UTC)

Bug: Menu icons missing from header and sticky header buttons

[MW 1.39.1, PHP 8.1, Recently reinstalled Vector for MW 1.39]

The watchlist and user menu icons are missing from the static header in the top right of the page when the page is first loaded. If I click on 'Edit' (to load the visual editor on the same page), these icons appear. If I refresh the page, they disappear again.

When I scroll down a page, icons for search, discussion, watchlist and the user menu are missing from the sticky header.

Hovering over the these buttons reveals that they are still there, it's just the icons that are missing. If you didn't know that they were there, then you might not know they existed.

Does anyone know what could be causing this? KangarooRambo (talk) 13:49, 21 January 2023 (UTC)

JavaScript for expanding nested TOC levels by default

I have created a custom JavaScript for expanding nested TOC levels by default, e.g. on en:User:J. 'mach' wust/vector-2022.js (to make your own, create a page like en:Special:MyPage/vector-2022.js):

$(function () {
  var x = document.getElementsByClassName('vector-toc-level-1');
  for (var i = 0; i < x.length; i++) {
    x[i].classList.add('vector-toc-list-item-expanded');
  }
}());

As far as I can see, this is effective at expanding all nested TOC levels. I am not much of a JavaScript coder, though. Is this a good-practice User JavaScript? Could it be improved? J. 'mach' wust (talk) 14:26, 21 January 2023 (UTC)

Suggestion for alternative look for Vector 2022

A screenshot of a wikipedia page edited to restore the 2010-colours grey sidebars with blue borders.

Vector 2010's grey sidebars (#f6f6f6) and single-pixel blue border (#a7d7f9) have been a significant part of Wikipedia's look and identity since V2010's rollout and it would be a shame to lose this, especially to a layout where there's a lot of whitespace between the sidebars and the article content itself. I understand this is so the article can appear centered, but I think it would achieve this better if the table of contents were put in the sidebar instead. I've made a quick mockup to demonstrate.

For the record, I personally have no problem with the limited-width approach that V2022 adds, but a necessary consequence of that is a lot of whitespace that could be put to use in anchoring the article and drawing the eye to it - which it would do much better if the grey colour didn't end halfway through. With current V2022, the articles look disconnected and floaty. AsmodeanUnderscore (talk) 16:43, 21 January 2023 (UTC)

Just want to chime in and say I'd personally love this!! A lot of the jarring feeling comes from the sheer amount of whitespace, and you're right, it feels quite unanchored at the moment. An edit like this may fix a lot of people's initial hesitation to adopt Vector 22. A slight problem would be in just sticking the TOC in the sidebar, which may cause a bit of user confusion, but overall I think bringing back the grey sidebars would help a lot in grounding this redesign in some familiarity. Enuui (talk) 06:34, 24 January 2023 (UTC)

https://di-visual-design-borders-bgs.web.app/Zebra#top (9) outside article background (solid)) looks better. --NGC 54 (talk | contribs) 11:59, 1 February 2023 (UTC)

(9) but with the borders staying blue would be the best iteration of this i think AsmodeanUnderscore (talk) 14:43, 1 February 2023 (UTC)

The blue borders are not bad, either. --NGC 54 (talk | contribs) 14:50, 1 February 2023 (UTC)

More feedback (ToC, logging-out, Settings menu and user menu)

I just want to underline some things.

ToC issues

I want to underline 2 issues with the new ToC:

1. See this image: https://ibb.co/DwTZH8r. Why does the ToC is so short? If the ToC would be longer, then the reader would have to scroll the ToC less often.
2. See this video: https://vimeo.com/791479775. 1. When your mouse cursor hovers over the ToC box and 2. you scroll trough the ToC 3. while the ToC scrollbar is at the lower end, the reader should not be able to scroll the content of the page. It happened to me to want to choose the last section, but I was unable because when I wanted to click that section, the content of the page moved and the ToC turned back to the upper (first) sections. This is annoying.

Log-out process

Previously, the issue described here occurred only when clicking the log-out link from the sticky header. Now, it also occurs when clicking the log-out link outside the sticky header (from the user menu that is not part of the sticky header).

Settings menu (Site preferences)

I like the idea of providing the settings menu from https://patchdemo.wmflabs.org/wikis/10b47eaaa5/wiki/Space?useskin=vector-2022 and I would like to see it deployed on Wikimedia wikis. However, I think that due to its placement (the lower right corner), most readers would miss it, even if they would like to change one or more of those settings. If this would be deployed, these settings should also include the ability to disable/enable the Page Previews (and the Reference Previews for wikis which have them), and could also include the ability to disable/enable the dark mode when and if the dark mode will ever be built and deployed (and if there would not be any better location for the dark mode toggle, of course). --NGC 54 (talk | contribs) 18:41, 21 January 2023 (UTC)

User menu

1. I have previously reported this, but it is still unfixed. 1. Make sure that you are not logged-in on Commons. 2. Click "Uploaded menu" from the user menu. 3. You arrive on Commons at Special:ListFiles/Some IP, not at Special:ListFiles/Your user name.
2. Sometimes, you can click some links from the sticky header user menu even when hidden. See this video: https://vimeo.com/793346408.

--NGC 54 (talk | contribs) 13:33, 27 January 2023 (UTC)

P.S. For me, it is often hard to tell apart sections from subsections. phab:T307316 would be a solution. --NGC 54 (talk | contribs) 13:24, 23 January 2023 (UTC)

Congrats to the Vector 22

I am not sure if this is the correct venue where to place this, but I am getting more and more fond of Vector 2022. I just noticed that the script is bigger when searching special characters like Ω. Other features are good, too. For now, the one thing I am bit worried is if the reader will also know, the TOC is hidden behind the three bullets. The solution is great for the editors, though. Paradise Chronicle (talk) 21:32, 21 January 2023 (UTC)

Thank you very much for your feedback @Paradise Chronicle. Regarding the TOC, you can learn more about our user testing research here. Zapipedia (WMF) (talk) 15:25, 23 January 2023 (UTC)

I would like to hide the switching to the previous exterior.

I wish I could set it up with css or something. 2400:4152:6600:2900:EDE8:C00D:BB73:F5F9 03:47, 22 January 2023 (UTC)

Impact and goals

Second try, reposted from Vector 2022 Post-Deployment Update from WMF team:

Thank you for this update. It's depressing that it takes a pitchfork mob on the English Wikipedia for the Wikimedia Foundation to answer an obvious question which previously went unanswered for a year: what are you trying to achieve here? How will we know that a certain version of the skin helps with the goals?

Unfortunately, this collection of cherry-picked statistics cannot tell us much, because we still have no idea what the strategy is behind this entire exercise. I could comment on the individual statistics but it would be pointless. I do notice there's nothing about onboarding new users, making editing more effective or "cross-project and cross-language functionalities" (recommended by WMF's own supposed strategy).

Because interfaces are a trade-off, changing things for the sake of improving some metric will inevitably worsen some other metric, so I can only assume that overall strategic goals are affected negatively by the changes.

Separately I also posted a comment on the strategy, which evidently failed to provide useful guidance for this project. Nemo 10:42, 22 January 2023 (UTC)

Wikipedia is wasting donation money on pushing some JS framework nobody cares about.

While you could be doing something useful with the money, you decided to invest a lot of time and money on creating a problem that now requires a lot of fixes because nobody likes it or just features don't work/are missing.

I believe it's an insult to Wikipedia readers to do such move. You wasted the money on creating a "postmodern low-quality Wikipedia" just because some JS framework marketing campaign washed your brains.

Change it back. Use the money properly, adding value instead of breaking what didn't need to be fixed. Microph123 (talk) 12:57, 22 January 2023 (UTC)

This response makes little sense. You might not like the design, but the entire implementation is standard CSS and HTML and the only thing that requires JS is to move the ToC while you turn your view from wide to narrow or the other way around. If anything, this is probably the least amount of JS an interface like this could be built with. I get that some people don't like the new design, but this technical argument brought forward here definitely does not apply. —TheDJ (Not WMF) (talk • contribs) 15:56, 23 January 2023 (UTC)

Translations link

I cannot find any feedback or question page and I hope I can get information from here, and that the pinging is OK. In the User Menue drop down list "Translations" is shown for me, taking me to the translation tool. That is all good and it might be some setting I have activated. But on the Sticky header, when scrolled down, the "Translations" choice is not available. It had led to some confusions when it has been missing.SGrabarczuk (WMF) Is that a feature or a bug? LittleGun (talk) 13:43, 22 January 2023 (UTC)

Hi @LittleGun, thank you for your feedback. Please look at this comment for more information about this change. Patafisik (WMF) (talk) 09:07, 25 January 2023 (UTC)

Patafisik (WMF): OK, thanks for linking my comment to the phabricator task. LittleGun (talk) 12:38, 25 January 2023 (UTC)

Hi @LittleGun I'm not sure you are reading the correct line. What is your account on Phabricator? Are you reading the comment by the Principal Software Engineer, Language Engineering team writing Dec 12 2022, 11:59 AM "I just removed these menus from sticky header for now. Will revisit later(or even remove them permanently as persistant entry point for translations is ready)"? CC @Santhosh.thottingal: Patafisik (WMF) (talk) 13:03, 25 January 2023 (UTC)

Patafisik (WMF): I do not have any account on phabricator, and I hardly ever understand the threads the few times I have read any.

In this case I understood the topic was the same as mine, that the work was paused by "santosh" ("removed for now"), and that you added the comment:

"Hi @santhosh, just FYI here a user is confused by this change."

And "here" was link to this thread.

So I thanked you for linking my feedback in the Phabricator thread. LittleGun (talk) 13:30, 25 January 2023 (UTC)

Line-length Study

There really ought to be a better reference here. This "study" is just a random PDF - it appears to be unpublished, unreviewed, has no citations and scant details on data. 98.14.66.93 14:09, 22 January 2023 (UTC)

Thanks for your comment. I'm not sure which particular study you're referring to - could you give us some more detail? As a part of our research, we reviewed 7 academic studies, as well as the WCAG accessibility guidelines. More information on our sources and motivations are available on this page. OVasileva (WMF) (talk) 15:39, 10 February 2023 (UTC)

Deployment roadmap on Chinese wikis

Hello, there is currently a local discussion about postponing the deployment on Chinese Wikipedia. In the discussion, some editor have shared concerns about the issue of Chinese Language Converter not working in Vector-2022 (phab:T306862). Although Vector-2022 has already been deployed on most wikis, when will it be deployed on Chinese wikis? Will Vector-2022 be deployed on Chinese wikis after the issue of the Language Converter is fixed? Thank you. cc @SGrabarczuk (WMF) and OVasileva (WMF): SCP-2000 (talk) 16:39, 22 January 2023 (UTC)

@SCP-2000 According to the ticket the issue is marked as a blocker and it seems last friday there was a new patch started to work on a fix for it. —TheDJ (Not WMF) (talk • contribs) 15:52, 23 January 2023 (UTC)

Hello @SCP-2000! Thanks for letting us know about that discussion. Right now, we are focused on the feedback coming from English Wikipedia where Vector 2022 became the default last week. We don't have any specific deadline set up for discussing with the communities of the Chinese-script wikis. SGrabarczuk (WMF) (talk) 16:07, 23 January 2023 (UTC)

I don't like it.

For me, the old skin was fine. I was used to it, I knew where things were. No problem.

The new skin seems pointlessly different. Different isn't always bad, but in this case, there seemed to be way too much exra whitespace, meaning that the information density is lower.

I apologize to the people who I'm sure worked hard on it, but I did not follow the suggestion to "try it for at least one week prior to deciding whether to switch". I switched back to the previous Vector as soon as someone gave me the link. (Thanks, @JackofOz: ). It was an easy decision.

This is unfounded speculation, but I suspect there's a certain amount of w:Politician's logic involved here. There was a (doubtless well-intentioned) goal to "make the interface more welcoming and usable", and there was money available to do the work... but once you've got a mandate and some money, you're not going to just tinker around the edges, you've pretty much got to do something big and bold and different, which means it's bound to be disruptive. —scs (talk) 17:09, 22 January 2023 (UTC)

purge-by-clock: slowness effects

About the purge-clock in my user-dropdown menu (top-right on desktop). When I open a page, in the Usermenu (top right), circa position #6, a ''clock'' appears as menu option (showing UTC time), to Purge the page. All fine.

Now when I click that menu option directly after opening that page (purge the page as first action), the clock is not added completely: ''when clicking the clock, it activates menu option "Log out". That is: the menu option previously in that position (before the clock was added in between). This situation exists some 1 or 2 seconds.

This is a nuisance (logout-screen appears unexpectedly; though very strange unexpected so logout by mistake is not often.). But also, the logout screen looks similar to other screens (like, "purge" manually alternate GET\POST screen), and so logout may easily happen.

TL;DR: The Purge Clock in Usermenu installs slowly, thereby connecting to a ''different'' menu item -- namely the menu item "Logout". (for 1 or 2 seconds after page opening). DePiep (talk) 18:27, 22 January 2023 (UTC)

Hi @DePiep, thank you for reporting this, can you verify if this subject has already been addressed, and if your can found an answer, in replies in this talk page? Thank you, Patafisik (WMF) (talk) 12:24, 24 January 2023 (UTC)

Moot by now: the clock-to-purge is repositioned to outside of the menu (now in top usermenu bar).

In the new situation, the issue does _not_ appear.

(FWIW, aftertalk: in the problematic situation and _after_ the request by Patafisik (WMF) was posted here, I experienced the old (bad) behaviour. The clock appeared, and for circa 3 seconds - the clock counts itself ;-) - clicking meant opening the Logout screen (the unexpected behaviour).

At this moment, with the repositioned clock, some seconds of time delay is still present but *no* wrong page is opened.)

This report may be Closed as Moot/Resolved. DePiep (talk) 21:12, 5 February 2023 (UTC)

Font and Scrollbars — Bad Choice!

Font. The new skin turns every page into a section of the Great Text Wall, it's basically unreadable. Wikipedia is supposed to be read. A standard Wiki page has a great deal of text with a few illustrations. That's why Wiki's most important GUI feature, IMHO, is readability.

The basic readability requirements for websites are very simple. It's color (standard choices: white on black, black on white, and brown on sepia) and font. Font should be easy to read, that's all, nothing fancy, nothing "pretty", no personal preferences, nothing special. It should not be "stretched out" vertically or horizontally. There should be clear separation between paragraphs, a suitable interval between words and between lines, and even larger space before headers. Check any novel from a reputable publisher in any book store, see the width-height proportions, space between letters and words, and the paragraph formatting. Choose similar sans serif font and use the same formatting. That's all. Isn't it easy?

Scrollbars. I have 3.5" (9 cm) empty space between the content and the article (27" monitor), and 3 scrollbars to use (additional vertical scrollbar for the content). That's really ridiculous. Back in the 90s, all web designers raved about "liquid" design and scorned frames. 30 years later — yay! we've got our scrollbars back! I can still kind of understand 4-6 scrollbars in Google Sheets, but here?

In short.

The first time I opened Wikipedia with its new skin, I was greeted with a message like "We did some improvements". Was that a joke?

Spljushka (talk) 22:23, 22 January 2023 (UTC)

Just to put this out there.. The font of the content and it's spacing didn't change, as far as I can tell using the web inspector...... —TheDJ (Not WMF) (talk • contribs) 15:46, 23 January 2023 (UTC)

Why, Wikipedia, why?

If I wanted to use the mobile version, I would use the mobile version. But I want to use the desktop version on a desktop computer, so why are you forcing me to look at a mobile-like layout? The mobile-like layout is NOT optimized for use on a PC. Freja Draco (talk) 22:38, 22 January 2023 (UTC)

Hello @Freja Draco. These changes are created specifically for desktop interfaces. You can learn more in our FAQs and at the Desktop Improvements project page. Thank you. Zapipedia (WMF) (talk) 15:34, 23 January 2023 (UTC)

That's not true. You do not listen to the voice of users at all and do not address the allegations. You just keep repeating your corporate talk about how "great" your ideas are. It's sad. 83.30.229.13 16:28, 24 January 2023 (UTC)

Much harder to read, lowers accessibility

I have problems reading text on screen if it is not black text on a light background, but of course having the entire page bright white is also not brilliant for eyestrain.

The previous style was great for me because parts of the page were a darker grey colour which evened out the eyestrain and I never had a problem reading wikipedia pages, but now everything is bright white and makes it very hard for me to read the page.

I don't see how the new design is intended to actually help accessibility for people like myself. RCTJ1991 (talk) 00:22, 23 January 2023 (UTC)

Hello @RCTJ1991, thank you for your feedback, I will pass it to the team. We were working with the American Foundation for the Blind to improve accessibility of Vector 2022 but some changes are still in progress, look at T318373 and T310033 for further information. Zapipedia (WMF) (talk) 15:45, 23 January 2023 (UTC)

Don't fix what ain't broke

Oh come on Wikimedia, you know better than that! What was wrong with the old layout? What problem did you solve?

For me, everything was right! It was clear, it worked in old browsers, and it allowed me to quickly switch between languages by a simple click. Is someone suffering from "new is always better" syndrome over at Wikimedia? ;) There was no better way to spend the money I send you every year? If we all sent you less, would such "upgrades" be out-of-budget in the future? :) I fear that Wikimedia got infected by Parkinson's Law, project managers looking for some raison d'etre, wasting resources. I hope I'm wrong.

If you must have this new "better" layout, please, at least give people an easy way to go back to the one they prefer. Without logging in of course - such nonsense! Write a flag in a cookie, problem solved.

Thank you for the otherwise awesome and free encyclopiedia! I use it daily, can't imagine internet without it!

Success metric tracking

Hi, is there a place we can follow along with the initiative's success metric tracking? czar 05:58, 23 January 2023 (UTC)

menu design

Designing menu's is a tough puzzle. What helps:

1. mutually exclusive options should be excluding each other in one menu. For example:
   • article/talk/history/wikidata item/page information
   • Chinese/English/French/Italian
   • read/edit/print/add-to-watchlist/download to PDF

   This rule ensures that a user needs to look only in one menu to see mutually exclusive choices. This is hard to get right. It is tempting to move low frequency options to a separate menu.

2. Options that can be combined should be in separate menu's, but close together. For example:
   • article English read
   • article English edit
   • article English add-to-wachtlist
   • article Italian print
   • talkpage French edit

An object - action approach 'article English read' deviates from spoken English 'read English article' and that is OK. It's UI design, not spoken language design. An object - action approach will make it easy to show the available actions for a chosen object. For example

• article English: read, edit or print
• article Afrikaans: create, translate from English, translate from French
• history English: read, print

Uwappa (talk) 17:47, 23 January 2023 (UTC)

Menu inefficiency

It is counterproductive to place Talk, Sandbox, Preferences, Contributions, and Logout into the account submenu. Users (myself included) have to search around for these, and likely ask for assistance. There is plenty of space to place them visibly on the main menu line where they have been in the past. This (a) informs users that these functions are available, and (b) allows users to access these functions without wondering where they are and clicking around to find them.

Removing and hiding features may give the page a cleaner look, but functionality must be the most important design criteria. Otherwise, we could just serve a blank page.

Edibobb (talk) 20:27, 23 January 2023 (UTC)

• Putting commonly-used links like my Talk and Contributions into menu lists is the biggest effect of the new skin for me. My beef is that the order of the items in the menu lists seems to be random. It doesn't seem to be alphabetical, adaptive, functional or anything but arbitrary. Please can you make the order alphabetical and/or provide some ability for the user to control and customise the sequence. If there's something missing in my understanding, please clarify. Andrew Davidson (talk) 14:21, 10 February 2023 (UTC)

Changelog?

I notice many big (realtively speaking) changes happening to Vector 2022 on English Wikipedia today.

I went to check this thread but it only lists updates up until December.

From what I see, 'Tools' now appear in the right column (was empty), and the main menu has increased font size and spacing, and also the empty margin between the menu and main content seems to have been lessened. The menu has a hide option on top and the "back" button (which was actually a menu button) on the top left has been removed.

Where can we see a list of changes like this that are currently being done? Many of the complains that have been made are being invalidated by changes like this happening.—Jetro (talk) 22:30, 23 January 2023 (UTC)

Hi @Jetro, for exemple you can follow Desktop Improvements on Phabricator. Please look at this presentation and at this page for more details about the Desktop Improvements in general. About updates, you should be interested also in this update on the Village pump (technical) of January, 20th. The team is still receiving a lot of feedback and improving Vector 2022 according to some community requests. An update in the dedicated sub-page will be published in few weeks as usual. Patafisik (WMF) (talk) 11:30, 24 January 2023 (UTC)

New font size + linespacing for sidebars is very confusing.

Please revert to the original styling of the sidebar, for the l.h. sidebar and for the new r.h.s. presentation of tools.

The current setup is more linespace than the body text, rather than less; and the same font-size as body text. That's hard to read. The lack of different style for the sidebar section-headers makes it hard to find where you are. The extra linespacing also makes it hard to see all options at once... Written up as task T327732 Sj (talk) 22:31, 23 January 2023 (UTC)

Hot Take: I love the Redesign. But...

Okay, I love the redesign. I've been an early adopter since I heard about it, and seeing it actually put into mainspace is glorious. The latest update (the one that moved the "additional tools" box to the right hand) really gave me a little rush of giddy excitement. Sad to see people don't quite like it, but then again, that might be the doomscrolling I've been witnessing.

However, I have some icks about it.

I feel as though that the ToC navbox should be contrasted with the background, possibly using #f6f6f6 or similar. It should also have a border, colored #d8dbdf or similar. Also, the ToC tab (for small screens) should be circular, similar to the hide bar on en:Chinese Wikipedia with a hint of Material Design's "hamburger menu".

Either way, great job on the work going on! I really wish people could have a more open mind about the new layout. Explodicator7331 (talk) 00:03, 24 January 2023 (UTC)

Hi @Explodicator7331 thank you for your feedback. About colors, the Web Team has tested a prototype and collected (and still collecting) feedback to improve the visual design. A very specific request about colors might be better suited to a customization, perhaps? What do you think about this possibility? Please read our FAQ, in particular this section. Patafisik (WMF) (talk) 11:17, 24 January 2023 (UTC)

Hmm, I'll try editing the CSS/JS for my skin, and see if I prefer it over the main settings. If I actually think it could come into fruition as a feature, I'll see my inquiry as a serious proposal, as opposed to a silly suggestion. Explodicator7331 (talk) 14:50, 24 January 2023 (UTC)

New screenshots needed.

I thought I'd done something stupid that had altered my page layout today, but after the earlier Vector 2022 I'm now loving the Tools menu being moved from the left side of the page to the right. A great idea to also be able to hide it in with the other 'tabs', too. We now need some new screenshots to reflect the default appearance of Vector 2022, please. Nick Moyes (talk) 00:17, 24 January 2023 (UTC)

Thank you @Nick Moyes for your feedback, I reported your request for screenshots to the team. Patafisik (WMF) (talk) 11:41, 24 January 2023 (UTC)

@Nick Moyes I would be happy to upload some screenshots for you. Are there any particular things you'd like in terms of projects, articles, etc? AHollender (WMF) (talk) 17:28, 24 January 2023 (UTC)

Thanks, AHollender (WMF). At this stage I'm still getting used to things, and haven't got my head around precisely what's going to be outdated. A few years back I spent quite a few days checking and making new images and fixing all the inconsistencies in our en.wiki 'How to' pages when we simply swapped from 'Save changes' to 'Publish changes' (see here). So I suspect there's now a lot of out-of-date imagery and instructions that'll need altering to reflect Vector 2022. It depends whether more layout changing are coming as to whether it's worth doing immediately or waiting a month or two (e.g. the tools menu oving to the right).

I do tend to like demonstration images that focus on neutral topics, such as 'The Earth' or a globally-known animal species such as a lion or elephant, but at this stage I can't suggest specifics. What will be key is good nomenclature and categorisation of every screenshot - we have a wealth of old and new images, often shoved all together on Commons, and it can often be hard to work out which are the most up-to-date ones to use. I accept that it's not just examples in English that will be needed, but I can only really comment on my own native language. Nick Moyes (talk) 11:04, 25 January 2023 (UTC)

@AHollender (WMF): Just to merge information: Nick Moyes suggests here to have also a category on Commons for icons used by Vector 2022 for helping volunteers who will update help pages.--Patafisik (WMF) (talk) 10:32, 1 February 2023 (UTC)

You promised a skin, you touched the veins

and trampled our hearts.
Why, o why, didn't you put it up there^{not default} for a year? That is what good manners and respect dictate. We would try it out (at all projects) in good faith. Ample time to fix bugs. Ample time to propose improvements.
The question would be: Even if you like it or even if you are indifferent to it, do you think, with your experience as editor,

• that it will satisfy the needs of editors of all wikiprojects, all kinds of pages, all languages. Is it tangible to apply this format everywhere?
• that it will satisfy readers?

Fellow editors of English wikipedia, who say you like it. (I might like things there too). You are the flagship of all projects. Think global. Not just wikipedia. Think of small wikis who have no chance, no power to influence decisions. Please, allow it be non default for a transitional phase.
Wikimedia, please, rework it and present it anew. Preferably call it Vector2023, notify the press of your brave decision and let us all forget this unfortunate incident.
I am so sad. A wiktionarian Sarri.greek (talk) 04:30, 24 January 2023 (UTC)

While no, I'm not the hugest fan of it, it was there in the preferences; this wasn't some random change. Unknown-Tree (talk) 00:55, 25 January 2023 (UTC)

Was it, Unknown-Tree. I never got a message that a trial was commencing (I come from other projects). Thank you, Sarri.greek (talk) 01:05, 25 January 2023 (UTC)

I'm not sure if there was a message, but it was definitely in the preferences. Unknown-Tree (talk) 03:37, 25 January 2023 (UTC)

Καλημέρα @Sarri.greek. I've seen your user name in many different sections here and on English Wikipedia. Thank you for those. I wasn't sure which of the points you've made so far I should address first, but I'll try with this one.

• "Why, o why, didn't you put it up there not default for a year?" - as you may find out reading the main project page (Deployment plan and timeline), we began working on this in 2019. Since 2020, this has been the default on a growing number of wikis, and at the same time, it's been a non-default everywhere else. Over time, it has become the most popular non-default skin on English Wikipedia and a number of other large Wikipedias. We've been working with the early adopter wiki communities since 2020, and they've helped us with many decisions and bugs. Recently, after several months of discussions, we have deployed Desktop Improvements on English Wikipedia. Perhaps it's more easily noticeable now, especially for those who don't read Portuguese, Indonesian, French, Hebrew etc., but do read English.
• Will it satisfy the needs of users (incl. readers) of all wikis - among the early adopter wikis, there are both small and large projects, Wikipedias, sister projects, written in different scripts and different parts of the world... so in principle, yes, this project is dedicated to be working everywhere. But each wiki may need some adjustments, sometimes mostly on our side, sometimes mostly on the community side, sometimes impossible without collaboration. We haven't talked to the Commons community yet. Certainly, we'll need to change something for Wikisource. We still need to discuss adjustments to Wikidata. I see now that the English Wiktionary community will also need to update their custom code. But yeah, we work on this to meet the needs of all or almost all projects. (Also, I encourage you to take a look at the blog post Prioritizing equity within Wikipedia’s new desktop and to explore the Repository tab.)
  • Will it satisfy the needs of all users on those wikis? No, but we don't expect that. Still it will be better than the previous interface which didn't satisfy the needs of users, as our research shows.
• To make a product without the disadvantages only active editors may help to solve, we need to work with active editors. I'd like to invite you to follow us closely; look at the section Get involved & Contact, and help us with our future projects.

Thank you again. Personally, I like answering this kind of questions about the "general approach". Hopefully, this clarifies something. What do you think about my answer? Do you have additional questions? Later this week, I think, we'll post a large update on the English Wikipedia RfC. I recommend opening that page before the weekend! SGrabarczuk (WMF) (talk) 03:03, 9 February 2023 (UTC)

Thank you, Sir, for your time. SGrabarczuk (WMF), Apart from my personal opinion, which is anti-commercial.mobile.look, and pro 'least possible design', We have seen banners for wikimania. Banners for 'vote photo'. Banners for Conduct. We have never seen a Banner: In the following months, our pages will have a new look for desktop readers. Please try it out here and... And after it is deployed: Our desktop pages have a new look. Please try it and tell us.. Logged readers may choose ... here, not-logged readers may add ?useskin=(their choice).. or something. These banners should be permanently shown everywhere. For months. I think, it is basic courtesy. Even if only for 1% of readers.

Of course I understand that WMF has the right on the skin and all technical issues. I did not imagine that a new look would be applied outside wikipedias.

Wiktionaries (at least el.wikt) would have to rewrite many pages to also show _TOC__ manually (present at hundreds of pages like Appendices). Also, we will have to add the addresses of recommended interwiki links in the See also section. We already show the mother language wiktionary. Dictionaries are different from encyclopaedias. Thank you. Sarri.greek (talk) 09:13, 9 February 2023 (UTC)

Thank you @Sarri.greek. We have been running banners on Wikipedias (English, Greek, Spanish, German, and others) for many weeks since May 2022. Perhaps for some reason you haven't noticed them? Anyway, it is because of those banners that so many individual users have opted in. If the numbers of edits you've made across wikis indicate how much time you spend on a given wiki, the reason why you haven't noticed the banners is because we haven't run them on Greek or English Wiktionary. Simply, we're focusing on Wikipedias now, and because Wiktionaries may be different in some ways, we think we'll focus on those issues later. But shortly before we know we have the capacity to talk to the sister project communities, we will turn these banners on. (We can't run them for months continuously because it's a practice not to run more than two different banners for the same audience at the same time.)

It's interesting that you mention the TOC "magic word" and other potential issues for Wiktionaries. If you have the time, let's perhaps take notes on what, according to you, should be adjusted on Wiktionaries, on a separate page? This way, it will be less likely for your comments to be lost in the archives.

What do you think about that? SGrabarczuk (WMF) (talk) 01:44, 10 February 2023 (UTC)

Some examples

Please compare at both vectors.
el.wiktionary appendices (about Tables of Contents)

• The ToC is in the div=right Used in numerous non lemma pages (talks, rooms, appendices). E.g. all declension tables lead to an appendix like this one OO the hidden Contents are not numbered 1. 1.1. 1.2. ...,
• In this grammar appendix, it is written manually. Glad to see NOTOC works.

wikisource el./fr... (about ?match)

• https://el.wikisource.org/wiki/Τα_ψηλά_βουνά/Το_ξεκίνημα This one has languages with arrows opening frames. I cannot see the arrows to get

  https://el.wikisource.org/wiki/Τα_ψηλά_βουνά/Το_ξεκίνημα?match=fr

  now click the blue link Τσιριτρό which directs to https://el.wikisource.org/wiki/Τα_ψηλά_βουνά/Τσιριτρό?match=fr

  And now, how does one go back to 1 language.. The 'match' is now rare but very useful. All wiktionary 'quotations' link to wikisource. I presume, wikipedia's too.

While changes and fixes are happening in real time, we cannot be sure which of our tests & comments is dated or not. Please keep announcing versions of that vector so that we re-test our pages to see what is solved.
Plus: Contents should be immediately viewable. This is their natural place. To seek them is not. Thank you Sarri.greek (talk) 06:57, 24 January 2023 (UTC)
The sticky line: it cannot be different from what it is initially: to recongnize it as 'the same thing'. Searchbox cannot 'walk' across the page. Sarri.greek (talk) 07:11, 24 January 2023 (UTC)

Please give a democratic Vector2023 for all readers

• A democratic principle in designing would be: Allow maximum possible freedom to the users. Make it possible to not impose sizes, lengths. Allow everyone to feel comfortable.
  Do not force them to log in.
• Transitional periods for switching environments, allow some months of easy choice between old and new.

It was explained that the Wikimedia Foundation, has not released the funds needed for buying the equipment necessary for a button that switches back and forth for Classic VectorLegacy (2010) and the new Vector 2022 (for unlogged readers).

• Uniformity between projects is not strict. The necessities and idiocyncracies of each project, each language are different.
• Uniformity between mobile view and desktop, is not desirable to many. Also, the rapidly advancing technology will probably set new challenges in the near future.

Please, board of trustees. Give us a democratic Vector 2023 or 2024, Give us ample time to adapt. Thank you. Sarri.greek (talk) 16:38, 21 January 2023 (UTC)

Hello again @Sarri.greek. From our perspective, we are offering the freedom to the users. In the FAQ (Why don't you provide preferences to choose between different versions of the features? as well as Why are there no preferences for anonymous users? and other sections), we've explained what are the limitations to this. I hope I've addressed the remainder of your concerns above. SGrabarczuk (WMF) (talk) 13:27, 10 February 2023 (UTC)

Now there are many solutions at the internet. I have not downloaded one yet, so I keep adding ?useskin=vector or other (because I view wikipedias unlogged). Thank you SGrabarczuk (WMF). Sarri.greek (talk) 13:37, 10 February 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

Language-switcher pushing translations

I've been using the new layout for quite a while and haven't had any big issues with it, until now. I was quite surprised to see that the language-switcher now suggests that the user/reader can create a translation if the article doesn't yet exist in a specific language. Has there been discussion about this feature, and if so, where could I find it?

The Content translation tool (CX) is not a universally loved tool, and I think it's quite problematic that it is suggested to pretty much anyone who clicks the language-switcher in any wiki that has Vector 2022 on it. "You can translate it in minutes!", it claims. There are often quality issues with CX articles, and the worst problem is that inexperienced users are not told that their CX creations might not be well-received by the community. kyykaarme (talk) 13:51, 24 January 2023 (UTC)

Thank you @Kyykaarme for your feedback, you are pointing out some interesting issues. As specified in the Content translation project, section Purpose of the tool, the tool should properly communicate the purpose of translations in Wikimedia context and help the user to avoid bad quality translations. I reported your comment to the Wikimedia Language engineering, if you prefer you can leave a feedback also here. For more information about the Language switching as part of the Desktop Improvements project look at here, for providing an entry points to translation see this task and this one. Patafisik (WMF) (talk) 12:42, 2 February 2023 (UTC)

@Patafisik (WMF) Thank you for the comment and the links! I might look into it more later. kyykaarme (talk) 20:39, 5 February 2023 (UTC)

Option to auto-hide content bar

I do quite like the new redesign layout in general but the content bar to the left of the screen irritates me for some reason. It just doesn't seem to fit and is static while scrolling the page so it is quite jarring as well. I find it distracting when reading, so I often have to hide the content bar by clicking on it to hide it away, so I would like to have a toggle to auto-hide the content bar. DR333AD (talk) 18:58, 24 January 2023 (UTC)

Hello @DR333AD! Thank you for reaching out to us here. Are you referring to the table of contents, so a list of headings, or the sidebar, a list of links to other pages on the same wiki? You may hide both of those menus: in the table of contents, there's a link [hide] next to the "Contents" label, and in the sidebar, the same link is next to the "Main menu" label. If you hide either of those, it should stay hidden even if you go to a different page or refresh the page. This only works for logged-in users, though.

Does that help you? SGrabarczuk (WMF) (talk) 00:07, 9 February 2023 (UTC)

Doesn't really help me since I usually have either multiple tabs opened at ocne or come back to Wiki randomly. Also, I often use devices that I don't want to be logged in either (public devices with multiple accounts), so an option that saves the preference to a browser instance would be nice. DR333AD (talk) 16:21, 10 February 2023 (UTC)

The Redesign Does Not Work for Wikipedia

Hello,

Like many people, I recently pulled up a Wikipedia page and immediately felt something was off. The new redesign is definitely a big departure from Old Wikipedia, and I've been trying to figure out whether my and many other people's distaste for it was due to an aversion to change or an actual design issue with the new look. While I can appreciate the intent behind the redesign, to improve readability and comprehension by shortening line length, I believe this mission fundamentally misunderstands how people use Wikipedia. People don't go on Wikipedia and sit down and read the full article on a topic, like they would on the New York Times (an example used by admins to support this design) they quickly skim an article for information relevant to the purpose they came on Wikipedia for. Therefore, the primary motivation behind the design of a Wiki page should be on making it as easy as possible to find relevant information, i.e. skim the page. The old design did this extremely well, the page's width being filled with text, and the new design fails spectacularly, requiring way more scrolling and fitting less information on the page at once. There are other issues with the new design, but those have been brought up already. Wikipedia's design should fit Wikipedia, not follow the example of other sites with completely different purposes and use cases. BringBackOldWiki (talk) 00:56, 25 January 2023 (UTC)

Hello @BringBackOldWiki. Thank you for your feedback, you can personalize your experience and use the full width. Zapipedia (WMF) (talk) 16:15, 25 January 2023 (UTC)

Open RfC

For those weighing in here on the theme, you may want to weigh in on the open "Request for Comments" linked to here: https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Rollback_of_Vector_2022#RfC:_Should_Wikipedia_return_to_Vector_2010_as_the_default_skin? 192.184.150.142 03:38, 25 January 2023 (UTC)

Jan 23 update from Web team

Hi all,

if you haven't still read it please look at the latest update from the Web Team here.--Patafisik (WMF) (talk) 14:33, 25 January 2023 (UTC)

Just for entertainment...

While switching back and forth in "appearance" and trying out some of the other/older alternatives, I noticed: Is V22 becoming more or less like the timeless skin? Though I was initially liking V22 but really don't what's done with the toc, I like timeless more than V22 in it's current form. Strange feeling. Regards HirnSpuk (talk) 07:23, 26 January 2023 (UTC)

Hi @HirnSpuk. That's interesting. Have you perhaps figured out what exactly has made you change your mind? (And yes, V22 feels a bit more similar to Timeless now with page tools on the right side of the screen.) SGrabarczuk (WMF) (talk) 00:00, 9 February 2023 (UTC)

Contrast and spacing

Coming from en Wikipedia here. I kind of like the change with the table of contents so I'm interested in using this new look. However, I find it hard to read the content when it isn't separated from everything else. The old layout put everything outside the article content in a grey (or blue) background – is there any way of doing this in the new layout?

Also, I feel the left sidebar takes up much more space than it needs to. Is it possible to adjust its width to be similar to what we had before.

Thanks. –CheChe (talk) 19:41, 26 January 2023 (UTC)

Hi @CheChe: thank you for your feedback. About the background color, discussions are going on and you can follow two tasks on Phabricator: T259240 and T328111. For more information about Visual Refinements, please look at this page and this one. Patafisik (WMF) (talk) 10:09, 7 February 2023 (UTC)

How to change the logo to a temporary one?

To change the logo image,wordmark and tagline, which CSS file should be changes ? Global.css ? Lotusccong (talk) 06:37, 27 January 2023 (UTC)

https://m.mediawiki.org/wiki/Skin:Vector/Customizing_the_logo_for_special_events is probably the most up to date reference. Hope that helps! Jdlrobson (talk) 22:32, 27 January 2023 (UTC)

Separate scrolling for the TOC bar is not helpful

Hopefully these criticisms are constructive. I'm not here just to harangue you guys or send abuse.

It's much harder to find things in the TOC than it used to be for the following reasons:

1. The TOC sidebar doesn't appear at all on some pages until you scroll down. If I'm looking for something specific, I can't even see where to look for it until I scroll.

2. Long TOCs (like the one on this page!) are difficult to use because you have to scroll through it to see it all. It's not possible to see the whole thing at once.

3. If you briefly navigate away from the TOC, e.g., to scroll on the main reading area (IDK what to call this, apologies), the TOC resets, making you lose your place again, so that you have to scroll through it all, again.

4. Because the TOC is narrow, long headings are hard to read, making it still harder to use. This is ironic because readability is a key reason that's been given for the re-design: yes, very long lines can be hard to read, but so can very short ones!

5. The contents aren't numbered so it's difficult to know where you are. This makes it especially annoying that the table insists on resetting itself!

I don't like having to log in separately on every sister project, just so that I can make the page not broken. And I say 'broken' because, when I saw the new design, I genuinely didn't realise it was a new design at all: I thought something had gone wrong with my browser settings. It didn't occur to me that it could be a deliberate choice to make Wikipedia look as it now does. I may be in the minority but I do think the designers should reflect on that. I think even if I were aware the change was coming (which even as a daily Wikipedia user, I wasn't), I wouldn't have realised this was it. (This is strictly a separate issue, but I'm raising it here because I don't want to create yet another heading which will be impossible to find in the TOC sidebar!)

Finally, there's a note at the top of this page asking me to 'link a username' if I want to notify a member of staff (which I do, because I'm genuinely trying to be constructive and help the project), but I don't know how to do this. This is, ironically, a very good example of the failures of communication around this whole redesign. Do I type @OVasileva? Do I type User:SGrabarczuk_(WMF)? I can see what other people have done but I have no idea if this did successfully notify the staff members in question. — Preceding unsigned comment added by FrankSanPod (talk • contribs) 11:35, January 27, 2023 (UTC)

I aggree, FrankSanPod. I come from el.wiktionary and Contents are very important for us to see immediately, full and numbered. You can change your preferences for all wikiprojects here

https://www.mediawiki.org/wiki/Special:GlobalPreferences#mw-prefsection-rendering

Remember to scroll down the page to click Save

Also, we sign at Discussions with ~~~~ at the end. Thank you for your comments! Sarri.greek (talk) 02:20, 28 January 2023 (UTC)

Re: How the new Wikipedia design focused on accessibility

(Reposted from How the new Wikipedia design focused on accessibility.)

It's very significant that accessibility testing was performed, thanks for stressing this.

Overall, the results were positive, and we saw noticeable improvements comparing the original experience with the new.

Can you clarify where this finding comes from?

T263834 doesn’t mention anything of the sort. T323634 doesn’t mention any question about the overall accessibility improvements; it mentions 4 specific points on which feedback was sought, of which 2 received positive feedback. No positive assessment is mentioned for the remaining 2 points, which are arguably the most impactful changes in the new skin: the table of contents and the language selection.

Not quite a ringing endorsement. Nemo 18:46, 27 January 2023 (UTC)

I see the report is at Reading/Web/Desktop Improvements/Repository/Accessibility testing. It confirms what above: mixed ratings for TOC and language selection. Nemo 11:10, 28 January 2023 (UTC)

Disabling Limited Width Mode leads to horizontal scrolling

Hi, I've disabled Limited Width Mode and I've hidden each of the sidebars to permit full-width text display from this English Wikipedia talk page, and it's still got a horizontal scroll bar for about 10% of the overflow text to the right. w:Talk:Byzantine Empire

This is uncommon; not all talk pages overflow like this, so I suspect it is due to some object on the page forcing a width beyond my web browser's ability to display.

Windows 10 Professional with all updates; Google Chrome Version 109.0.5414.75 (Official Build) (64-bit), 1920x1080 full-screen resolution, maximized browser window. Elizium23 (talk) 22:37, 27 January 2023 (UTC)

Hi @Elizium23, thank you for your feedback, this task was closed recently about a similar issue. Are you still experimenting this problem? For debugging javascript gadgets, can you verify if this is still happening adding ?safemode=1 at the end of the URL? Patafisik (WMF) (talk) 09:58, 7 February 2023 (UTC)

@Patafisik (WMF), thanks for the reply and the reference! No, I have not experienced this basically since I reported it, and even on the page I linked, the problem has gone away, so I'd say that this was precisely the fix we needed. Cheers! Elizium23 (talk) 12:51, 7 February 2023 (UTC)

Why fix what wasn't broken?

As many others have said in the threads here, I made an account after all these years of using wikipedia simply to complain about the new layout and view the old one. Vector 2022 looks atrocious. Gives me a headache just looking at it. The old layout was in use for a decade for a reason: it worked. It was simple, clean, functional, and easy on the eyes. The new one looks like garbage. Please reevaluate forcing this garbage on people. 2600:8800:22C:E00:D5A2:9E15:C7CE:BAFC 05:10, 28 January 2023 (UTC)

Hello! Thank you for sharing your viewpoint. I understand that you may have other needs and this interface may not be the best for you. I'd like to encourage you to read our documentation pages, such as the FAQ, to explore how many different tests we have performed and what were our findings (for whom the previous interface didn't work and why). That said, we will continue working on the skin, and we hope to make more improvements, some of which you may like. For instance, this may include the dark mode. SGrabarczuk (WMF) (talk) 02:07, 9 February 2023 (UTC)

Better insight about the "Feedback summary" section

I don't know why but my question was archived two times without having been answered so I'm posting it again.

It was archived with these diff and diff.

Moved from Topic:X8tm9pidprwslpdt

Hi @SGrabarczuk (WMF), since the new page tools are going to be implemented in the next weeks into the Vector 2022 skin I was wondering if it would be possible to have a better insight of the data roughly presented in the "Feedback summary" section in the Prototype testing with editors paragraph.

IMO a presentation of the data with percentages and numbers like it was done in this paragraph would be clearer and more transparent than words like "the majority", "split pretty evenly" and "many people".

Thanks in advance for your disponibility and your work.

Please ping me when you'll answer to my question. WikiLuke (talk) 12:41, 28 January 2023 (UTC)

Hey @WikiLuke! I'm really sorry this happened to you. I've shared your suggestion with my team mates. SGrabarczuk (WMF) (talk) 23:38, 8 February 2023 (UTC)

wardrobe is a poor metaphor, wiki is a workbench

Clothes you use once a day, but when you work all the time, you need everything to be easily accessible. Look at what the workbench looks like:

https://upload.wikimedia.org/wikipedia/commons/1/11/Work_area_of_a_jeweller.jpg

The "argument" about consistency with the mobile version is completely pointless. Desktop and mobile are completely different environments that work differently, and mobile is much more limited. Trimming the desktop version to the limitations of mobile systems is counterproductive. Freja Draco (talk) 14:17, 28 January 2023 (UTC)

Hi @Freja Draco! Thanks for your comment and for the link to the file. You're right, we might use a different metaphor. In addition to the wardrobe, in presentations we've been giving at events, we've been using a metaphor of a library vs. an airplane cockpit. I suppose a workbench would work just as well. Anyway, the point we tried to make is that there are users who need many tools because they work on wiki, and a different audience needs to focus on content because they simply want to learn. And since the goals of the project are to improve the latter without harming the former, there are some tradeoffs to be made.

Regarding the consistency with mobile, we didn't want to trim the desktop version to the limitations of mobile. There are other similarities we need to bear in mind. For example, the styling of links, icons, etc. When people interact with the same website on mobile and on desktop, they should understand that this is the same website. I'm not sure if this is the best thing I may be pointing at; I've asked the team mates to give better examples. SGrabarczuk (WMF) (talk) 23:57, 8 February 2023 (UTC)

Link color

I don't completely hate the new layout; I've known it was coming for a long while now, and while it is rather jarring, I think I'll eventually get used to it if forced to do so – I prefer the older layout, though, out of strong familiarity.

I do have one very concrete qualm, though: years of reading Wikipedia with the old skin (and the one before Vector, also) very strongly conditioned me for two things: inside-wiki links are a darker blue, this one, #0645ad, to be exact, and external links are a lighter color, #36b. External links are also followed by a small squared-arrow icon, but for me the strongest identifier has been the color: dark, high-contrast for wikilinks that I'm probably interested in, and light, faded-out blue for external ones that I can skip over with my eyes. The new skin makes all links the same color as external links, and it's really tripping me up. The slight color differentiation was an excellent usability feature, and I just don't see why that needed to be given up along with everything else.

(Visited links used to be #0b0080, while they're now #795cb2 – I don't hate this cange as much, visited links were always a bit hard to see (although that's kind of the point, since they've already been read), but it's still a bit weird having them be so light in color, with so much less contrast between text and background.) All the best, Oatco (talk) 22:42, 28 January 2023 (UTC)

Hi @Oatco, thank you for your feedback. The new external link icon was deployed to follow the Wikimedia DSG's icon guidelines (T261391), link colors to fit the Web Content Accessibility Guidelines. More information about the choice of colors here on the prototype testing page, here with the answer of AHollande (WMF), and here on frwiki for a suggestion of customization, hope this should help. Patafisik (WMF) (talk) 09:50, 7 February 2023 (UTC)

Inconsistent edit page width

Vector-2022 has max-width limits for large screens. But on edit pages, unlike read pages, max-width limit is disabled and page width is stretched. Why edit pages are exempted from max-width limits? Moreover, when I preview or view diff when editing, max-width limit is enabled still even on edit page yet. I think page width should be consistent. Gustmd7410 (talk) 15:50, 29 January 2023 (UTC)

Tracked in Phabricator
Task T322385

Hi @Gustmd7410, thank you for reporting this issue, it was pointed out few days ago and a task is already open on Phabricator. Patafisik (WMF) (talk) 08:23, 31 January 2023 (UTC)

Thanks for information. But the task already open only points that preview page ignores disabling limited width setting. I meant that edit page without preview ignores enabling limited width setting. I think my problem and the task already open are similar but different problem. The existing task is trying to fix by removing max-width of preview section even though the page's max-width was disabled and it doesn't fix my problem. "vector-feature-limited-width-disabled" class of body element should be removed on edit page when limited width setting was enabled. Gustmd7410 (talk) 09:12, 31 January 2023 (UTC)

Tables

Hi! I've previously mentioned that I'm actually quite fond of the new look, but if I had to have one complaint, I'd say something needs to be done about tables. From my experience these past few days since the change, most articles with wikitables have seen those tables become really squished, which is just plain unpleasant to look at (Example). I'm not sure how Wikipedia handles tables, but perhaps adjusting them to simply display at a smaller size would be helpful. Krisgabwoosh (talk) 18:50, 29 January 2023 (UTC)

Hi @Krisgabwoosh, thank you for your feedback. This issue is concerning more skins then Vector 2022 and there is not a easy solution, discussion is still going on. Please look at this task on Phabricator about it, especially this comment. Patafisik (WMF) (talk) 08:35, 31 January 2023 (UTC)

Suggestion for "in other projects"

I think the in other projects menu would be better located beside the "Add languages" button as these serve broadly the same purpose - finding content on the same topic on other projects. Garuda3 (talk) 21:40, 29 January 2023 (UTC)

Watchlist - "Live updates" button gets hidden unnecessarily

In my watchlist views, there is a list of filters and controls for changing them, and this box contains a "[Hide]" link which allows me to collapse the box, which is large and usually unnecessary. Unfortunately, the "[Hide]" control also affects the "Live updates" button for no good reason. This button could easily be placed to the right of the hidden filter box. But it is hidden and the user then loses control of the Live Updates feature with no explanation.

"Live updates" seems to be an entirely separate feature from the application of filters. It does not make sense to group this in the same "Hide" collapsible box, especially because a hidden filter box leaves plenty of lateral space for the button. Please ungroup this so that the user may retain control of Live Updates even while others are hidden. Elizium23 (talk) 13:39, 30 January 2023 (UTC)

Hello @Elizium23. Thanks for sharing this. The problem you've described appears in other skins, not just Vector 2022, doesn't it? I think it may not only be beyond the scope of this project, but it perhaps belongs to a different team overseeing the code of watchlists. SGrabarczuk (WMF) (talk) 02:13, 9 February 2023 (UTC)

@SGrabarczuk (WMF), thank you for your prompt reply. Yes, I understand that this is more of a deeper interface issue and watchlist-specific. Is this a job for Phabricator, then, you think? Is that where core watchlist code is maintained? I'll poke around a bit. I'm a noob over there. Elizium23 (talk) 10:37, 9 February 2023 (UTC)

It's ok, it doesn't matter if you're a noob to these things :) This would be documented on Phabricator anyway. The problem I'm pointing at is that it would be a job for someone else. I checked out in the meantime and confirmed. It'd be a job for the Growth team if Growth weren't all busy with their most important job - Newcomer experience. I'll just ping my colleague working with Growth - @Trizek (WMF), FYI! SGrabarczuk (WMF) (talk) 00:50, 10 February 2023 (UTC)

Thank you @SGrabarczuk (WMF) for the ping.

Hello @Elizium23. Back in the days, when we designed this interface, we received feedback regarding the space the new filters take on the RC page. As a consequence, the solution offered (and prefered) was to hide everything. Hence, all components are hidden: the filters, the edits/days selection and the live update button.

I documented your idea. However, I can't promise anything regarding changing it. First, because there are no plans at the moment to change RCs and Watchlist (Growth only takes care of major, impacting bugs regarding RCs and Watchlist), and also because some other users might not like this change (as they didn't liked it when we worked on it). I wish you to see your idea considered when some efforts will be put back again on this interface!

Trizek (WMF) (talk) 12:28, 10 February 2023 (UTC)

Uploads link gone

Commons New Look lacks "Uploads" link

1. Visit https://commons.wikimedia.org/wiki/Main_Page logged in.
2. Look for the Uploads link (https://commons.wikimedia.org/w/index.php?title=Special:ListFiles/...

There is none. There should be one.

Sure "Switch to old look".

Anyway, all the emphasis is on Uploading things, but never looking back to see what you uploaded.

In Preferences there is a whole section for Upload Wizard, but no way to get a link to click to see what one already uploaded.

Sure, "Use the browser's bookmarks." Jidanni (talk) 05:47, 31 January 2023 (UTC)

Hello @Jidanni. Are you still experiencing this? When I go to Commons and use Vector 2022, I see the "Uploads" link. If you don't, please add ?safemode=1 to your URL and then check, and if it's not there, tell me what browser and operating system you're using. SGrabarczuk (WMF) (talk) 23:36, 8 February 2023 (UTC)

Why is the main menu hidden by default?

This is not covered in the FAQ.

Why is the main menu hidden from the main page non-registered users? What is the reasoning for that? Jetro (talk) 02:08, 1 February 2023 (UTC)

Hi @Jetro, thanks for reading our documentation and asking us here!

This is explained in detail on the page about the collapsible sidebar feature. Essentially, readers mostly don't use the sidebar, and if they're able to collapse it, they mostly choose to do that, and they rarely un-collapse it. From the technical perspective, the state of the un-collapsed sidebar is a preference, and logged-out users don't have preferences, so the un-collapsed state isn't saved anywhere for them.

Regarding the risk of some important things being missed if users don't see those links - as part of the Core Experiences group, we're working on exposing the community side of the wikis. Growth is working on visible points of entry to contributing, and after Vector 2022, we'll try to make further changes to the interface to, metaphorically, "open the kitchen" of Wikipedia. For example, we're thinking about a text "recently edited by X" instead of the enigmatic "View history". But the future project is not something we're discussing in detail since our work on the Desktop Improvements isn't done yet.

I hope this answers your question! SGrabarczuk (WMF) (talk) 23:33, 8 February 2023 (UTC)

I can't change the theme

Hello,

I have a wierd issue, whenever I change the theme, the theme I've choose last for 1 second and then goes back to the old one.

Did anyone knows how to fix that ? 91.206.189.246 10:42, 2 February 2023 (UTC)

Hi @91.206.189.246: , thank you for your feedback, can you give us more details? Can you describe your configuration (browser, OS, etc.) and how you change the theme, and what happens, step by step? Please look at this task on Phabricator about the persistent settings and check if your problem should be described and resolved by this task. Patafisik (WMF) (talk) 09:32, 7 February 2023 (UTC)

Hello, I have find the problem, it was due to a chrome extension ! (odern for Wikipedia

)

MaitreGuigz (talk) 15:10, 7 February 2023 (UTC)

Jan 31 update from Web team

Hi all,

if you haven't still read it, please look at the latest update from Web team: the persistence for fixed width for all users is coming this week.--Patafisik (WMF) (talk) 12:29, 2 February 2023 (UTC)

Why are you ignoring the majority of Wikipedia users who DON'T WANT THE NEW LAYOUT? Why are you bandaiding these features when in the big picture, a big majority don't want this layout-change *AT ALL*! Not ONCE have you acknowledged the critizism from users regarding shoe-horning a design far from finished! Fixed width is only one of many complaints, why aren't you honouring the majority of voters who DON'T WANT THE VECTOR 2022 DESIGN AT ALL!! The default layout for everyone logged-in or not, should be Vector 2010.. Vector 2022 should be OPT-IN with a big banner. You guys are professionals at skewing results in your favour, if you'd actually made a vote for EVERY WIKIPEDIA USER, LOGGED IN OR NOT, you'd get humiliated in the results.. what a sham! Holundiman (talk) 13:25, 4 February 2023 (UTC)

radical idea

Tracked in Phabricator
Task T318168

hi.

latest announcement ("Desktop improvements. A new change is coming!") says:

".... This change also addresses the concern for the location of the table of contents. Previously, some editors using an earlier version of Vector 2022 told us that because the table of contents appeared below the sidebar, it was placed too much down below the page. After this change, the sidebar will be shorter...."

here's a radical idea: how about bringing back the ability to _fold_ the different sidebar sections?

we had this in original vector for a long while, but at some point (around 2014?) this was removed, and i've been missing it ever since. never understood the rationale behind this removal - it was good UX, and we actually have it now for the new TOC, when there are "subsections". why not for the menus too?, קיפודנחש (talk) 21:41, 3 February 2023 (UTC)

Hey קיפודנחש. Thank you for your suggestion. We have noted that this is a possibility (T318168) but right now, it seems that we don't consider this as a priority. I've copy-pasted your comment into a comment on Phabricator - perhaps this would initiate a discussion. SGrabarczuk (WMF) (talk) 21:34, 9 February 2023 (UTC)

Preference toggle for article preview fade in animation/fade in rate adjustment

Hi, I really like the visual and accessibility improvements incorporated with the new Vector 2022 theme, however I've noticed that hovering over a link to preview an article feels sluggish and unresponsive in comparison to the legacy Vector theme. In relation to accessibility, animations triggered by motion such as moving a cursor over a link to display may be problematic for people with motion sensitivities. Perhaps a more immediate or subtle fade in effect could alleviate both of these issues? Better yet, an option to turn off all animations on the website entirely would in my opinion be a positive step forward. 2001:BB6:7A0C:5A58:7C32:BD56:5D3C:17AD 18:12, 4 February 2023 (UTC)

Thank you for your feedback. At the user Preferences, in the Appearance tab, is it possible to disable the page previews. Zapipedia (WMF) (talk) 10:21, 9 February 2023 (UTC)

“In other projects” in “Tools”?

Love that page tools have finally been moved to their own menu!

However, I’m not sure “In other projects” is in the right place. Sure, these links are specific to the current page, but they are not tools for editors, not even tools at all, they are navigation links, mostly for visitors that won’t open that tool menu. In the medium term, I think finding a better place for those, along with a better way to think of cross navigation between projects, could be necessary. The closest feature that has already been redesigned is the interwiki, with links between languages but within the same project, with the nice new language selector. One direction to go could be to have a project selector next to it? Just an early thought. At least I think these links are not discoverable enough by readers now that they are in the page tools menu. Nclm (talk) 16:08, 6 February 2023 (UTC)

Other option for borders and backgrounds?

I’ve seen quite many comments here and there from people who find that the all white pages, without delimitations, makes it hard to mentally process the interface: what’s the article, what’s around, etc.

I remember from the Visual refinements stage that there were a few options, notably number #9, that were addressing this issue quite successfully.

I do like option #1 myself, but I do agree that #9 creates a very nice demarcation between content and container, as well as feeling more “Wikipedia” (which almost always had a white article page over a gray background). Option #9 also got the most votes.

I’m wondering if it would be beneficial now to reconsider going for #1, and to implement something akin to #9 instead.

Alternatively, we could imagine that #1 would be the default for MediaWiki, and #9 the default for Wikimedia projects. It would create a nice distinction between random other wikis that just happen to run MediaWiki (and also provide them with a blank state on which to customise), and actual Wikimedia projects (which would look a little bit more “traditionally Wikipedia” with the gray around the article). Nclm (talk) 16:24, 6 February 2023 (UTC)

I made myself a rough userstyle for trying out something like this, so I thought I could share it here maybe :)

Preview:

With all menus open

With TOC only

Code: meta:User:Nclm/global.css

Nclm (talk) 20:58, 10 February 2023 (UTC)

Full width toggle is great!

I liked everything about Vector 2022, even the table of contents, now that it's always there maybe I might use it for once lol. Now both wiki languages I use (French and English) look more consistent now.

I just discovered the Full-width toggle and it's a super convenient feature. I retract all my previous complaints about the design. I don't think this was part of the original release, but if it was I don't think I noticed. Nor did I know you could revert back to the old skin— I had been using a janky browser extension to modify the CSS sadly.

Hopefully most users' grievances will so easily resolved by the FAQ page... probably not but it did for me!

Symphoricarpos albus (talk) 17:50, 6 February 2023 (UTC)

Hey @Symphoricarpos albus. Thank you for your kind comment. Indeed, this wasn't part of the original design. We built it last year. Thanks again! SGrabarczuk (WMF) (talk) 23:10, 8 February 2023 (UTC)

The new design is a nightmare! Please revert to classic design

The new design is a horrible mess for a multitude of reasons well explained by many users above and elswhere:

• unused whitespace over half the screen width wasting resources, hardware, energy, money and sympathy of the readers
• diffuse page layout, no guidelines or orientation lines for reading, very bad page overview and orientation
• buttons, menus and interaction elements erratically scattered all over the page/screen
• more clicks neccessary for accessing menus and other features (as for restoring page usability)
• ... and much more!

Trying to circumvent some of the problems caused by this horrible design and broken defaults by adding even more complexity to this mess by just somewhere adding a few more buttons as for for skin selection, textwidth, or else does not help at all!

• For just reading a page as Wikipedia without neccessity for interaction I do not want to log in for privacy and further reasons - and this should not be neccessary!
• I deeply hate the new habit on Wikipedia of forcing "page previews" to popup everywhere, where my pointer happens to accidently touch one of the countless links on a wikipedia page, thus completely blocking my view to the page and making it impossible to read. For preventing these horrible popups as a non-loged-in user I *have* to disallow scripts on Wikipedia (fine with me - I generally like to disallow scripts if they are not needed for good reason; it also makes the pages faster)
• with scripting disallowed I do not get any of your fancy added extra-buttons scattered over the page as for full-width, etc. for partly restoring the usability of the page for me.

All the above was not any problem with any of the previous designs!!!

Please refrain from unilaterally forcing this horrible new design on Millions of Wikipedia-users which are very happy with the excellent, fully funktional and beautiful classic design and just love Wikipedia with its well-kown characteristic wonderful face. 77.12.135.231 07:48, 7 February 2023 (UTC)

New sidebar terrible, not tested properly

I don’t usually use Vector 2022 so I didn’t notice this until a couple of days ago when I happened to land on the English Wikipedia, but the new sidebar is terrible; and it was not tested properly.

On portrait monitors (very common in editorial circles) the content area is now so narrow that on a 1080p monitor, the first screenful of en:Xhosa language has measures that are only about 25 characters wide. The measure is so narrow it feels like reading a newspaper.

On portrait monitors, Vector 2022 was already borderline unusable for some languages; with this new sidebar it’s unusable even for English. I’d suggest developers dedicate a monitor to portrait orientation to make sure their designs still work when hardware screen width is only 1080px.

More generally, I’d suggest developers not use the latest and greatest hardware; normal users don’t have super-wide screens. Al12si (talk) 00:59, 10 February 2023 (UTC)

Large margins and gaps on 1280x1024

I have 1280x1024 monitor and I can say gaps and margins are too big. While I personally can agree that on a widescreen it is better to have narrow centered content, on a "box" screen this feels less readable. With the old design on my monitor I get the best reading experience - content is not wide and is not narrow. I tested the new design on widescreen (with Firefox Devtools help) and the article width is perfectly good for me as the old design on my real monitor. Though I can make a userstyle for it I'd like the new design by default get rid of (or make smaller) these unnecessary gaps (1, 2, 3 on a screenshot - https://imgur.com/a/2lju5cJ ). 188.168.117.1 05:09, 10 February 2023 (UTC)

When will the blue pulsing dot under the Preview tab on the source editor be removed?

When will the Wikimedia Foundation remove the pulsing blue dot that appears under the Preview tab when editing a page's source? As an IP editor, I honestly find the pulsing animation annoying, and I hate how it appears every time I edit and how I have to click twice in order for it to stop. I'm sure many people already know about the existence of the feature, so why continue to display the distracting animation? I honestly hate it more than I hate Vector 2022, and that's saying something. When will the dot be removed completely? 2001:4453:565:1C00:EC96:CEBD:68FD:9AB 11:06, 10 February 2023 (UTC)

This is not related to Desktop Improvements. I've replied on the original thread at w:Wikipedia:Village pump (technical)#When will the blue pulsing dot under the Preview tab on the source editor be removed? the wub "?!" 11:58, 10 February 2023 (UTC)

Nochmal Vector 2022

Lieber Programmierer, der Du diesen Zirkus verbockt hast, möglicherweise bist Du Mitte zwanzig und mit Schmiertelefonen aufgewachsen. Das wäre alleine kein Problem, aber versuche doch endlich einzusehen, dass es längst nicht jedem so geht und das alle, die einen klassischen Rechner mit echter Tastatur und Monitor in Querformat nutzen, von dieser platzverschwendenden Oberflächenmissgeburt genervt sind. Ist es so schwer, zu akzeptieren, dass hier der Neuerungsgaul durchgegangen ist? Ich bitte darum, die penetrante Bannerwerbung, die nicht einmal pro Woche, sondern täglich mehrfach auftaucht, auf Dauer einzustellen. Stell Deine seltsame Kreation auf derselben Ebene wie die anderen Oberflächen zur Auswahl, aber versuche nicht mehr, sie mit Gewalt durchzusetzen. Die, denen das Ding gefällt, haben es. Die anderen bekommen davon nur Hypertonie.

Solltest Du Dich langweilen, dann kümmere Dich darum, dass das Aufrufen eines anderen Wikis durch einen angemeldeten Nutzer dazu führt, dass das neue in der Sprache und Ansicht des Aufrufenden erscheint. Spätestens seit Donald T. finden nämlich viele US-englisch gar nicht mehr toll. Insbesondere das hier und Wikidata sind davon betroffen und es ist keine Schande, über den Tellerrand zwischen Maine und Kalifornien zu gucken. Der Nabel der Welt befindet sich dort nicht. –Falk2 (talk) 11:43, 10 February 2023 (UTC)

New Design absolute trash

This new design is so horrible it made me create an account to complain. When I think about it the only possible reason to destroy the website like this is to force people to create an account so that they can use the old layout. What they hope to accomplish through this I don't know since everyone who has to do this will use a 10minutemail like me and also never use wikipedia again unless forced so there's not going to be any way to sell user data regardless. Absolutely trash choice both from a commercial perspective (Not supposed to be wikipedia's goal anyway) and especially a user perspective. Who the fuck is ever going to want to donate to wikipedia ever again if the money goes to destroying the website. BringBackOldWiki1 (talk) 19:42, 10 February 2023 (UTC)

Creating links to other projects is not given as an option

At the old skin, if an article is not connected to other wikipedias via wikidata, there is an option to "add links" At the new skin, if an article is not connected to other wikipedias via wikidata, there is an option to "add languages" giving the option to translate, but no option to add links at wikidata. This has to be corrected. FocalPoint (talk) 21:46, 10 February 2023 (UTC)

Hello @FocalPoint. At the page tools (now located at the right of the page) you may find an option called "Edit interlanguage links" to connect the article via Wikidata. Thank you. Zapipedia (WMF) (talk) 09:50, 11 February 2023 (UTC)

@Zapipedia (WMF), yes, I found it, thank you. Still... why not keep it in the Languages box? Just change for change's sake? Isn't it a Language issue? Think about it. FocalPoint (talk) 14:02, 11 February 2023 (UTC)

@Zapipedia (WMF), I want to add that it works fine in the language menu if there is at least one interlaguage link. If you click on "add languages", an option appears with the same name "Edit interlanguage links". However, this option does not come up if there is no interlanguage link in the first place. FocalPoint (talk) 16:22, 11 February 2023 (UTC)

Read My username

Read it and understand IOnlyMadeThisAccountSoICanRevertToTheOldLook (talk) 03:20, 11 February 2023 (UTC)

You can easily revert it for yourself.

This is no proper way to communicate. I suggest that this paragraph is deleted. FocalPoint (talk) 16:24, 11 February 2023 (UTC)