Talk:Reading/Web/Desktop Improvements

Too narrow (again)
Why waste all that space? I have a nice wide screen so I want to take advantage of it. Those who want to have it narrow can just reduce their window sizes? Overall, not a great look. Not exciting. Quite boring.--Xania (talk) 11:23, 22 December 2021 (UTC)


 * Hello @Xania, you can read about our goals and motivation for limiting the width. Also, we are working on a solution to use the empty space. Could you take a look at our fourth prototype and write more on what you think about arranging the space as it is presented there? Thank you in advance! SGrabarczuk (WMF) (talk) 14:59, 26 April 2022 (UTC)
 * Oh my dear God, why don't you give an option to unrestrict the width?? It's beyond ridiculous how absolutely tiny is the page content on my monitor horizontally! I have to scroll all the time to read! Don't ruin Wikipedia the same way Fandom was ruined! 90.188.46.13 04:38, 13 May 2022 (UTC)
 * We have given this option. This can be done with the gadget one of our engineers made. SGrabarczuk (WMF) (talk) 03:39, 14 May 2022 (UTC)
 * Thanks, but maybe we should have an easy plug-in system for ordinary users or, at least, the instructions how to apply it and a place where to find those customisations. By default it is really narrow to read and it feels like a news site rather than an encyclopedia article. Krnl0138 (talk) 09:55, 15 May 2022 (UTC)
 * I agree, the toggle option should be there by default! By the way, that script does not work well currently, so I updated it here. — Arthurfragoso (talk) 13:28, 21 May 2022 (UTC)
 * I'm aware this reply is quite late but I feel this comment may be helpful:
 * What if there were options for multiple skins? For example, users could choose between the new and classic variants and possibly a dark mode for both?
 * In giving users freedom of choice, they could simply choose which one suits them best. Maybe a skin with a 'Bionic Reading' font can be used to assist users with ADHD or other conditions (seeing as some pages can be lengthy to read)? Grebles (talk) 06:06, 11 September 2022 (UTC)
 * I don't understand why you are still pushing on us that bad design choice. It still is time to pull the plug and start to work on a plain page design. You are convincing no one here. Please, please, really, please stop this nonsense. Forcing bad choices on your users because you are the only product on the market is never a good thing.
 * Since it has been forced without asking anyone on the French Wikipedia I had to register just to come back to the normal and good design. That's something, as a simple reader, I should never have had to do in the first place.
 * So one last time, please come back to reason and stop hurting your user base foolishly. DerpFox (talk) 21:33, 13 May 2022 (UTC)
 * Hello @DerpFox, thanks for your comment. Have you maybe followed the links I've shared in my answer to Xania? SGrabarczuk (WMF) (talk) 03:42, 14 May 2022 (UTC)
 * Ditto Tim bates (talk) 16:32, 30 August 2022 (UTC)
 * The lines in the fourth prototype seem to be slightly wider to me on 1080p display than in the current version of 2022 vector design, but those empty strips on the sides, each of which are almost the size of the old navigation mv-panel, constantly remind about the space wasted.
 * If the only reason of this thinning is the recommended line lengths in symbols and you want to keep it for any price, I would suggest using a dynamic font size, so, for example, starting from some resolution the symbols just grow larger. This might also reduce the eye strain connected to focusing on the small text.
 * Kageneko (talk) 13:51, 17 May 2022 (UTC)
 * I had a browse over the reasons for the change, but I still don't like or agree with the main justification more or less boiling down to "everyone else is doing it so we should too". Even in the linked examples, the page still feels a lot more "full" despite having a dedicated deadspace on the site, due to the way the page has been very carefully designed in a mixture of different kinds of block contents (images, text interactive eliments, etc).
 * Accepted Webpage standards used to be against having blank, unused and waisted deadspace, but at some point in the last 10 years there seems to have been a weird shift to the opposite where deadspace is all the rage, though it's not one I've personally ever liked or agreed with.
 * While I'm sure there are good uses of limiting page width, I'm not sure if Wikipedia, being a site that is mainly made up of text would really benefit from it as it's likely just going to squash pages and increase the amount of vertical scrolling required to navigate. Dave247 (talk) 07:32, 18 May 2022 (UTC)
 * Yeah it's too narrow otherwise. the look is very nice, it's not boring as you tell. Crater bug (talk) 15:28, 28 May 2022 (UTC)
 * I love the smaller margins. Works really well. Much cleaner. Thank you! 202.53.37.158 08:31, 16 August 2022 (UTC)
 * I'll buck the trend and note that on my 2560x1440 monitor, I very much appreciate the shorter line widths. Trying to read 12" or wider lines starts to get extremely exhausting, and vector makes it a lot easier to keep reading. I think that was the right move, matches best design practices, and is best for most users. ThatsNoMoon343 (talk) 22:25, 27 August 2022 (UTC)
 * I totally agree! I dislike the vector skin because how small it is. OverAWallOfMetaKnight (talk) 15:55, 15 May 2022 (UTC)
 * Agreed. I use a 3440x1440 screen (usually with a tiled layout), and this new layout forces all the content to occupy a comically narrow strip, instead of allowing me to choose the width myself. Emptyflask (talk) 13:47, 17 May 2022 (UTC)
 * I agree, there is simply too much space wasted that could be used for more article space and a button specifically for those who want to edit wikipedia Techny3000 (talk) 02:52, 28 May 2022 (UTC)
 * hard to read I'm glad I stayed the same as before No changes required 240B:11:E7E0:5E00:6005:3399:E6C:2B48 14:06, 2 July 2022 (UTC)
 * Strongly agree. I want to decide the readable width for me. In the old skin and most websites, I can do it by adjusting the width of window. I definitely don't want to care about "CORRECT READABLE WIDTH FOR EVERYONE" decided by someone somewhere, even if they are great scholars. Kyoku (talk) 08:32, 10 July 2022 (UTC)
 * Agreed wholeheartedly. By the way, the design is even worse on a low DPI widescreen display, like 1366x768, 1280x800/720, etc. Try it out with Device Rendering options in your browser, usually somewhere in Dev Tools. I just got hit with Vector 2022 after coming here from wikipedia where I've had Vector 2010 enabled for a while and I forgot how bad it was!
 * Wikimedia Foundation, do not forget that people all around the world use your service. People who might have a budget/old device with a low resolution display, or schoolchildren with a Chromebook or something! No default layout should ever create this much dead space and padding in a desktop environment. NONE. Nor should it ever consume nearly 1/3 of screen real estate that can never ever be used by the main content.
 * The floating ToC looks like absolute garbage at 720p. I have WUXGA and 4K devices and it isn't any better there either. I'm not sure who the design is aimed at, other than the designers pushing the modern scourge of padding and white space onto the rest of the Internet. -αβοοδ (talk) 17:41, 29 July 2022 (UTC)
 * Totally agree. Has anyone ever made a poll among the users to figure out whether they want this narrow thing? WolfRAMM (talk) 18:13, 29 August 2022 (UTC)
 * Agreed, it looks terrible on desktop. As usual, a design choice with only mobile users in mind and no one else. Jotamide (talk) 12:53, 9 September 2022 (UTC)
 * I disagree with the comment and agree with the change to make it narrower. I find that I read more slowly and have more eyestrain on excessively wide layouts. That being said, I think a toggle (like what Notion.so has) could work well. Phsource (talk) 20:26, 9 September 2022 (UTC)
 * I agree. I feel like I am wasting space. If I want a narrow reading view, then the way I previously could do that is by *resizing my window* to make the view that I want. Sometimes I do want a wide view, and when I do I make my wikipedia window full screen. And when I want a narrow view I use my desktop's built-in split-view functionality by dragging a window to either side of the screen.  But with this new narrow-only skin, readers don't have an easy way to have a wide view when they want it.  Also I don't feel like wikipedia should jump on the bandwagon of having narrow view because that is the current fad that other websites do. Em3rgent0rdr (talk) 03:13, 10 September 2022 (UTC)
 * Yet another website caving in to the forced mobilefication of the web for desktop users. I don't understand this insistence on hiding everything in drop-down menus either. I really hope someone makes a userscript or something to revert this change when it inevitably becomes site-wide because otherwise I might just start using old Wayback Machine captures to view Wikipedia pages for non-time-sensitive things. Noxian16 (talk) 21:54, 25 September 2022 (UTC)

After reviewing the posted defense of the narrowing and the feedback listed here, this feature belongs entirely as an optional setting. It most certainly should not be the website's default. RightQuark (talk) 01:29, 24 May 2022 (UTC)
 * The defence of the narrowing seems to have little real-world bonuses. It may be theoretically good but makes it bad to read because Wikipedia articles can be long Torqueing (talk) 17:10, 24 May 2022 (UTC)

I also have a wide screen monitor. I do not like this forced width shrinkage in the Vector 2022 skin. OhanaUnited  Talk page  17:24, 9 June 2022 (UTC)

In current form without a toggle for width this layout is unacceptable on large monitors. Even my old 14'' monitor. For now I am reverting to avoid having in forced horizontal white-space. phatom87 (talk) 14:32, 20 June 2022 (UTC)


 * Absolutely unacceptable, too narrow, an unjustified waste of space. Loupeter (talk) 10:39, 24 June 2022 (UTC)


 * It sounds like the fixed-max-width (assuming one's window is wide enough, and regardless of how much wider it might be) is a compromise between the needs of two different types of reading activities. I have both habits (skim vs detail-read), and felt especially the concern that the text doesn't obey what *I* do with my window. A reason I might widen my window is exactly because I want wider content. A comprimse necessarily isn't ideal for either one side. A better solution is to make it easy and discoverable how to get the *best* feel for whatever one is trying to do, rather than forcing so many to have a sub-par experience. A third-party gadget isn't discoverable and is surely more fragile than a first-class toggle feature of the skin itself. DMacks (talk) 15:16, 29 June 2022 (UTC)

In my opinion, Skin:Timeless does a much better job at restricting article space to improve readability. This is because the UI is not entirely positioned on the left-hand side of the screen, and the background colour is not blindingly bright. If the intention is to create whitespace, please don't use bright colours. Timeless also has more space for pictures. For the past 20 years, articles have been written with the understanding that 80%+ of the screen will be for content. There are width and upright tags all over the place that, once viewed with this narrow a perspective, become overwhelming.

A skin should not change the fundamental readability of the page. Compare this with this. In Timeless, when the content ends, grey begins. In Vector 2022, it looks like the HTML was corrupted and failed to load because it continues with white for no discernable reason. Vector also artificially makes articles look longer than they are, which may actually dissuade people from reading. For instance, using a 27" 16:9 monitor, on the article for Barack Obama, Vector just about lets me see the entire lead on my screen at once. Timeless allows me to see the whole lead quite easily, as well as part of the ToC. Line length may be a thing, but you must take into account the total amount of text on the screen at once, too. There's no use having the perfect 50 character line if you need 100 of them all bunched up together. Anarchyte (talk) 13:18, 13 July 2022 (UTC)


 * Quick update and aside: I just learned about wide-vector-2022. This is fantastic. I actually like the ToC being placed where it is when using that gadget. If the plan was to make the wide skin the default, I would be less hesitant. For comparison with the links in my previous message, here is Barack Obama with wide-vector-2022. Anarchyte (talk) 13:25, 13 July 2022 (UTC)
 * This "wide-vector-2022" version should be the default IMO. Some1 (talk) 02:50, 17 July 2022 (UTC)
 * It's definitely an improvement, but Vector 2010 is still better. I agree with @Anarchyte - Timeless does a better job of restricting article space than Vector 2022 does. When you look at how much of the left third of the screen is blocked off from article content, Vector 2010 restricts it the least, followed by Timeless, and then finally by Vector 2022 consuming nearly an entire 1/3 of the screen. At low DPI, it's hilariously ugly, and arguably makes readability worse, not better. Vector 2022 sure would be nice though, if the ToC was collapsible! -αβοοδ (talk) 17:48, 29 July 2022 (UTC)
 * > For the past 20 years, articles have been written with the understanding that 80%+ of the screen will be for content.
 * I'll just note that for the past 10 years that means you've written things that just do not work that way on mobile. :)
 * > A skin should not change the fundamental readability of the page. [..] In Vector 2022, it looks like the HTML was corrupted and failed to load because it continues with white for no discernable reason.
 * This seems like a lot of assumptions to me personally. Do we have wider evidence for this ?
 * > There's no use having the perfect 50 character line if you need 100 of them all bunched up together.
 * Literally every mobile user on the Barack Obama page, the majority of the readers. Screens and screens till you hit the end of the lead... —Th e DJ (Not WMF) (talk • contribs) 20:20, 14 July 2022 (UTC)
 * I'll just note that for the past 10 years that means you've written things that just do not work that way on mobile. :)
 * MinervaNeue, when viewed on normal phone screens, ignores width tags. The only difference between writing for desktop screens and mobile screens is file placement.
 * This seems like a lot of assumptions to me personally. Do we have wider evidence for this ?
 * I don't need to provide evidence to state my opinion. The page looks unfinished with the extra whitespace on the right hand side. If you do want more than just my opinion, CNTRL+F for "whitespace" on this page. 12 other posts mention it.
 * Literally every mobile user on the Barack Obama page, the majority of the readers. Screens and screens till you hit the end of the lead...
 * Difference is that my phone is in my hand. I'm not getting overloaded with line after line if the screen is only 15cm long. I can see a whole paragraph on at once and then scroll when necessary. Anarchyte (talk) 13:10, 15 July 2022 (UTC)

I'll just leave my disappointed note as well, purely for adding the length to this discussion (especially we are operating on what seems to be 500 px wide area [apparently it's 1200, so 46% of my current screen]). I tried to convince myselft to new vector at least four times now as I find most of it's designs quite pleasing. But this width thing is riddiculous. Any article starting with an infobox look like a comic strip. So much space is wasted. I'm still using a gadget hiding menu to get MORE WIDTH on the old Vector for example to use new preview mode in code editor. The most I can get from new Vecor is 2 × 740 px (if I close the menu). And then I still have 2 × 475 px of emptyness. Terrible idea. Arvedui89 (talk) 12:20, 23 August 2022 (UTC)

Hello! I feel the menu section, on the left side of the screen, is too wide. (Leaving the article page too narrow) Thanks!
 * Agreed: too narrow - Aboudaqn (talk) 17:50, 11 September 2022 (UTC)

Too narrow, that's a blocker for me, switching back, thanks. Others detailed above pretty well. --Grin (talk) 19:13, 11 September 2022 (UTC)

I've made a quick stylus script to set the container width at 100% and I'll sure be keeping that way. Having that much leftover whitespace on the right side without having it on the left really messes with the balance of the page. InvalidCards (talk) 19:51, 11 September 2022 (UTC)


 * Too narrow. How could I configure it? JOAN (talk) 03:23, 18 September 2022 (UTC)

Alternate options that preserve the primary goal
The reasoning makes sense, and the team working on this would know better than I about their merits. But are there not alternate options that preserve the primary goal (limiting character count per line) while not resulting in a too-narrow page?

The text can be enlarged on wider displays/windows. Images could be moved from in-line to the side. The information boxes could be made wider. Other options that I can't think of. I don't know how trivial this is to navigate with the multitude of screen sizes that exist out there.

I have to agree with others that the pages feel too narrow, even if the reasoning is perfectly logical. The prototype 4 you link looks "right" if I zoom in by 20% in my browser... Geistbar (talk) 00:26, 28 August 2022 (UTC)


 * Hello. Thank you @Geistbar for your kind comment. I appreciate that you have thought about our reasoning.
 * We are aiming at something that wouldn't be too wide - experience which would be different than (and better from) Vector legacy or Monobook. Then, the threshold for the content area being too narrow depends on both individual user's favorite settings and the type of content on a given page. We have tried to find the optimal width.
 * Would it be possible to increase the font size? Yes, we're considering that, and if we do that, we'll make the content area proportionally wider. When it comes to moving images, infoboxes, other type of content (footnotes, for example), it doesn't appear to be possible. I mean, I think we can't move the content outside of the content area. There's a strict line of purely technical nature between the interface (provided by us, developed in collaboration with the community) and content (which we don't touch).
 * Instead, we'll be able to put other things there that would belong to the interface, be set up by the communities, but wouldn't be regular part of content. The "related pages" is more or less this kind of thing. SGrabarczuk (WMF) (talk) 23:05, 1 September 2022 (UTC)
 * Isn’t the simplist ‘alternate’ idea perhaps also the most straightforward:
 * Don’t restrict line length at all, and let users, when they choose, invoke the ‘reading mode’ included in most recent web browsers on both computers and mobile devices?
 * Most (all?) skins likely support this already.
 * (I believe browsers generally use the  HTML5 tag, when present, to identify which content to display.)
 * (If meddling ~is~ desired, perhaps only limit line length when the user is using certain text zoom levels, if that can be ascertained using Javascript.)
 * Why re-invent the wheel, especially when there is so much disagreement on ‘preferred line length’?
 * - Jim Grisham (talk) 19:02, 19 September 2022 (UTC)
 * The “reader view” in web browsers is a clumsy workaround which serves as a last resort for reading terrible (especially ad-infested) websites that have no respect for their readers, not an excuse for websites to intentionally make their pages illegible. –jacobolus (talk) 19:35, 19 September 2022 (UTC)

Surprising to see the first thing here is a complaint about not using wide screens adequately. I came to complain about the exact opposite issue. When browser window is narrow enough that I can have 2 browser windows open side by side, the left menu takes over the whole upper part of the page and creates this unwanted situation where all the content is a whole screen down.98.30.137.144 18:17, 10 September 2022 (UTC)

For anyone interested in this kind of thing, I use a very mildly customized version of the 'monobook' theme which has been working great for me for many years. All I do is limit the max-width of paragraphs and a few other elements, while letting images float all the way to the right (and also letting multi-column appendices do their normal thing). In my opinion this works much better than trying to squeeze the whole page into a smaller width including floating images and other marginalia:

This works great, allowing me to see images floating to the side out of the way of the text while the text itself doesn't get to be outrageously long. I am sure my CSS is not correctly handling rare exceptional cases, and there are probably other improvements that could be made. But the basic idea seems right. Cheers! –jacobolus (talk) 18:54, 10 September 2022 (UTC)


 * The smaller width was the first thing I noticed and I like it. It feels like less work to read the page. I recently changed my Emacs configuration to change the width because it's easier to read this way. Agree that an option for users with different opinions should be there, but tightening up the page is not universally loathed. I don't like changing my window size because I always have my windows maximized and it bothers me to see something different on the other half of my monitor.

--Skyvine (talk) 19:55, 13 September 2022 (UTC)

Just learned of this update when I went to en.wikipedia this morning. The narrow content area was a bit of a shock, but seems mostly readable (depending on page layout like infoboxes and inline images). However, the area to the right of the content is wasted screen space. Why not put the TOC there instead of below the tools? --Theodore Kloba (talk) 13:37, 22 September 2022 (UTC)

I use an old fashioned CRT monitor. The new vesrion os edit is hadr to read because of small letters in the screen. 31.46.247.19 15:49, 22 September 2022 (UTC)


 * I have just switched back. It was too narrow. Hard to work with it on a wide screen. --130.255.159.66 16:39, 25 September 2022 (UTC)

Consistent skin across the wikis
New Skin is burdening me when I switching between languages. (and I zoom when I want improve readability rather put blank space) it Should changing all language together if it is well received and appreciated. should not just some language for set a precedent. Mutyoro (talk) 19:27, 4 August 2022 (UTC)
 * @Mutyoro, thank you for your comment. First, if you want to have the same skin across all wikis, you can choose one global preferences. Secondly, the way how Vector 2022 becomes the default across more and more wikis - that's a complicated issue. Week after week, we roll out small changes to Vector 2022 that are visible across all wikis. At the same time, it's much easier (both for our team and for the communities) when some communities use this skin as the default earlier, and some get it later. SGrabarczuk (WMF) (talk) 22:54, 4 August 2022 (UTC)
 * Thanks for your comment, @SGrabarczuk (WMF),
 * Seems like I sent wrong message. what I want is, Change skin after agreed by each wikis.
 * Should not try to archive Bandwagon effect by using Sheeple.
 * Pease be aware "most of people like it because accept it" this is typical comment of crowd manupiration.
 * I thought 8 years ago some of your colleague try to narrowing width, and it was Rejected by users.
 * Talk:Typography refresh/Archive 2
 * do you have any information why try to narrower down even it was rejected before? Mutyoro (talk) 21:43, 8 August 2022 (UTC)
 * I wonder why the global preferences link here is in Japanese. That is one of the absolute worst languages to post it in, solely due to the signs etc. 178.115.79.85 20:38, 28 August 2022 (UTC)

Feedback regarding the new language switcher
Hello, I am a French person using Wikipedia in both French and English. I usually decide the language of the article depending on the topic. If it's related to France, I know the French version is going to be better. If it's a general topic, I usually select English.

However, it's been a few months that the language picker has been moved to the top of the screen when an article is display in French. And I really can't get used to it. Sure, it's easy to discover - but it's more complicated to use. Having to click twice is a regression for anyone switching language frequently. An action that used to require half a second now takes 2 seconds. If you do this about ten times every time you browse Wikipedia, it does become irritating...

I hope this feature is not shipped to other languages, and France gets the sidebar back. If you want to make this feature more discoverable, maybe you could add a shortcut but keep the sidebar. Or display a tooltip once in a while to educate newcomers. But please, keep "heavy users" of language switching in consideration. Thanks
 * I'd state this as 'what used to take me a second (finding the right language) now takes 10': Open language switcher, often don't see the language I want, have to search?  want to see which languages have a version, have to scroll; don't have a quick way to default present all languages by-alpha. Sj (talk) 16:49, 2 May 2022 (UTC)
 * I have to agree with this as another French person frequently switching languages on Wikipedia and Wiktionary. I should add, in addition to the intrinsic usability of the interface (I do agree it's a slight regression for my usage), the fact that most language editions still use the old interface (and most other sites using mediawiki, and the latter is likely to remain the case for a long time) means you don't actually get the opportunity to unlearn it. So every time I want to switch languages from a French page, I will first scroll down to the old location and waste 1s parsing the sidebar and wondering where the links are. I check out other languages almost every time I read any article and those milliseconds of irritation do add up. Anyway, I strongly think that “don't fix what ain't broke” should apply here! 37.183.2.114 12:06, 8 May 2022 (UTC)


 * +1 to Sj. --ThurnerRupert (talk) 18:58, 11 June 2022 (UTC)
 * I agree it's way less intuitive and probably less accessible. Plus it's two clicks instead of one Macslan (talk) 07:19, 6 September 2022 (UTC)

Often I use the language switcher not to navigate to the article on different language, but just to look up how that article is titled in a different language. In other words, using Wikipedia's inter-language links as a sort of dictionary. By hovering over the list of languages I can gather multiple titles, see their similarity between languages. With the New Look, language switcher became less accessible, though gathering titles by hovering still works there. Also this new dropdown-based language switcher seems either to require tricky CSS features or JavaScript. Will it make problems for simplistic browsers like w3m? _Vi (talk) 17:48, 20 May 2022 (UTC)

I find the language switcher the worst of both worlds of the two variants in the old interface. It can be annoying to scroll through 200+ languages in an idiosyncratic ordering (for example, كوردی [Kurdi in Perso-Arabic script] is filed under S for Sorani), but at least I can see them all and preview the name of the article in various target languages. With the drop-down menu in the old interface, I get the languages grouped geographically, and I can also search for a specific language, with the system recognizing many name variations. The new interface gives me a drop down menu with all 200+ languages in the same idiosyncratic order, with no geographic grouping and no ability to search for a specific language. LincMad (talk) 22:28, 25 May 2022 (UTC)


 * I agree, I hope that the language selector will show the most used languages on the top for people who switch languages a lot. (it did a few months ago if I remember correctly). Stefangrotz (talk) 20:18, 8 September 2022 (UTC)

I am primarily an active user on the Japanese Wikipedia (now defaulted to vector2022) and I agree with you completely. Why doesn't this use the blank spaces on the left and right? No need to hide buttons and functions everywhere just to make the page look hollow. As for the other features, there are so many problems with the new Vector. I definitely want the old version to remain. I will continue to use it and not the new one. --Sugarman (talk) 07:14, 6 July 2022 (UTC)


 * Hello @Sugarman. The space on the right are blank only temporarily. As you can see on our newest prototype, on the left, there are the sidebar and the table of contents, and on the right, there are some links pulled out of the sidebar.
 * As for "No need to hide [...] just to make the page look hollow" - on our pages, we explain why hide some links and functionalities. We never argue that we want the page to look hollow. We work to make the page look intuitive and welcoming. Entry points to advanced collaboration need to be clear, and not numerous.
 * Unless you are an advanced user already. We realize that advanced users may need to access specific links with one click. We encourage you to describe (some day when you decide to spend some time on it) all the problems you would like to see solved. Perhaps this may be addressed by adding/adjusting gadgets and user scripts. SGrabarczuk (WMF) (talk) 23:50, 4 August 2022 (UTC)

Hey, thanks for all of this feedback. I wanted to share a few different ideas that have come up over the past month or so as we've heard from various editors (including yourselves) about language switching.

1. For people who primarily switch between two languages: once you switch languages we could show a language link next to the language button, leading back to the language you came from. This would be somewhat similar to what happens on Commons and Wikidata when you switch languages. So for example, if you just switched from French Wikipedia to English Wikipedia the page would look like this:

2. For people who are logged-in and frequently switch to many different languages: we could make the language menu pinable to the sidebar, so that 9 (or even more) language links are exposed directly on the page at all times. We are already planning to make the tools menu and the main menu pinable in this way.

3. For people who are logged-out and frequently switch to many different languages: we could experiment with exposing more language links directly on the page. We've started exploring this in this task: https://phabricator.wikimedia.org/T301787. Depending on how many language links we wanted to expose that could look similar to the screenshot above with the link to French (plus one or two additional links), or could be more of a dedicated toolbar for language links: AHollender (WMF) (talk) 16:04, 15 August 2022 (UTC)
 * Hi, the only way I can see it working for me is 2 ("nine or even more language links are exposed directly on the page at all times") if all of the language links are unrolled down -- just like they are shown now. Option 1 is barely any different from the language picker, and option 3 makes browsing all of the language editions for pictures just as hard as the language picker on its own. Idea no. 2 with all of the languages shown is ideal for my workflow, I would greatly appreciate if you make it an option. Le Loy (talk) 05:09, 19 August 2022 (UTC)
 * the fact that there are most used languages are out of the menu isn't making it better, for starter if you need cookies or being logged in
 * the old language picker is still better Macslan (talk) 07:24, 6 September 2022 (UTC)
 * I like idea 1, most people don't use more than two or three languages. So a way to define the three most important languages for a user would be cool and having a quick link (or three) there would work for me. Idea 2 is cool as well.Stefangrotz (talk) 20:21, 8 September 2022 (UTC)
 * I would kindly ask not to decide what most users do and which three (or nine) languages are more important for them. As mentioned above, for many users it is preferable to consult a French version for a French-themed article and German or Japanese for... you know. The others use the interwiki list to check up a term or a geographical feature or whatever in different languages. For others, this would add up to the habitual but enduring annoyance of being compelled to search for features that used to be at hand. 2dk (talk) 23:06, 9 September 2022 (UTC)
 * Hi,
 * As someone who switches between French and English pretty frequently, I really love proposals 1 and 2, and think both should be implemented. These proposals, combined with the already implemented changes in the new desktop interface, make it far easier to switch languages, by allowing users to search the language list and press Enter to quickly go to the first language in the results.
 * I know the redesign is contentious, but every major rededsign of widely-trafficked websites was seen as controversial for a few days, including Youtube, Facebook, and more. This redesign offers clear usability improvements that seem to be based on good research. Specifically I think the new language switcher is a clear step forward, not a regression. DFlhb (talk) 12:31, 13 September 2022 (UTC)
 * Hello, I enabled the new Language switcher on English wiktionary. The side bar menu is now broken and takes up the whole width of the page. It is only English wiktionary which has the problem. I enabled the language switcher function in a non english wiktionary and the side bar menu was correctly displayed on the left side of the page only. Please advise, thank you. 94.181.193.111 19:22, 19 September 2022 (UTC)
 * Hello, I fixed this issue by myself. It was a display thing. I had my wiktionary page set to 150% magnification. For some reason at any magnification about 125% the left side bar suddenly decides it needs to take up the whole page width. This wasn't happening before I enabled the language switcher. Not sure if it is useful info to anyone, but there you go. 94.181.193.111 19:39, 19 September 2022 (UTC)

I hate the new TOC
I was directed here from T273473.

That left-of-the-article TOC is a horrible nightmare. I absolutely hate it. I would seriously avoid any website that forced it upon me. Can't scroll it out of sight, can't collapse it, can't disable it, takes up too much space, I hate it I hate it I hate it. This was the reason I switched back to Vector classic on beta cluster. (and if Vector classic gets it too I'll switch to Monobook, Timeless or just murder it with a userscript) I'm not much of a fan of Vector 2022 (but it's not a lost cause, just needs work), but this TOC pushed me over the edge.

As a personal note: I rarely use the existing TOC. But I can scroll it out of sight so it doesn't bother me. If the TOC went completely missing tomorrow, I wouldn't miss it. Having this big, (to me) useless thing that contrasts with the main content (it's much darker) permanently in my field of vision greatly annoys me. And because of the fixed position, my banner blindness fails to kick in. This results in pure hatred for something that, on the face it, could seem innocuous. Alexis Jazz (talk) 16:25, 19 April 2022 (UTC)
 * I was not "directed" anywhere, I blundered onto here after finally finding information about this new skin. And let me be clear, APART from the ridiculous handling of the TOC, the new skin is great, precisely BECAUSE, before the TOC-debacle, this skin allowed me to get more of the article on the screen, and allowed me to hide the standard list of menu choices that I only need 0.something % of the time.


 * So, please, Please, PLEASE make that TOC hideable! It's perhaps (!) a great default for newbies, but it's a bloody nuisance for us who usually never use the TOC, and if we do, we know where to find it! Autokefal Dialytiker (talk) 21:49, 25 April 2022 (UTC)
 * I totally agree. 185.53.157.151 08:13, 26 April 2022 (UTC)
 * @Autokefal Dialytiker, right, it's not that easy to get here. We'll put link to the project page on the list of available skins in preferences. The task is documented as T307113. SGrabarczuk (WMF) (talk) 15:25, 28 April 2022 (UTC)
 * Hey @Alexis Jazz - thanks for talking to us. It’s good to hear you were using Vector 2022. I hope that you will switch back to it. In terms of the table of contents, you raise good points. A lot has been happening since you wrote your comment, so my answer is longer than it would have been last week.
 * The first version of the design was based on the feedback we got on our previous prototypes from readers and editors (see in-person reader & editor testing and on-wiki community testing).
 * That said, we have not yet made the design final. We are working on different ideas for the visual design of the entire site. We'll make the main content of the page be the primary focus of attention, even when other navigational elements (such as the ToC) are present. If you’re interested in following along with that work, most of it will be tracked on T301780 and in subtasks of that ticket.
 * We are also considering the way the ToC will display at smaller resolutions (T306904, T306660) and looking into some options for collapsing it that could work for wider screens as well.
 * As you can see, people like you who have chosen Vector 2022 individually share a lot of feedback with us now. T307004, T306562 are some examples on things we are or will be working on.
 * In the meantime, we will be A/B testing the ToC on the pilot wikis. Our hypothesis is that the ToC will decrease the amount that people have to scroll to the top of the page to switch to a different section. The design might also vary once we have the results of the test.
 * Since these changes might take a little while to reach the beta cluster, we would also encourage technically-skilled folks to set up a script or gadget to make a temporary solution.
 * And... yeah, subscribe to our newsletter, join our office hours (tomorrow or later) and talk to us more. Thank you! SGrabarczuk (WMF) (talk) 15:23, 28 April 2022 (UTC)
 * SGrabarczuk, here's another thought: reverse. It's not a long page, but that TOC is so bloody huge a full HD display isn't enough to read any of the actual page content without scrolling. Alexis Jazz (talk) 01:39, 1 May 2022 (UTC)
 * Right, right. Let's just take a look at pl:Gramatyka języka fińskiego. I mean, this is an edge case, and as such, it's not that critical. From what I know, all TOC sections aren't uncollapsed by default, and you need to make an effort to see the full TOC. Is this your experience, too, @Alexis Jazz? SGrabarczuk (WMF) (talk) 22:45, 5 May 2022 (UTC)
 * SGrabarczuk, sorry for being possibly unclear. It was just a thought about the classic inline TOC which is disproportionally huge on Wiktionary, so it's something to think about when designing a new TOC. On the Gramatyka page on plwiki you at least get the intro without scrolling and the page actually is very long, so it's understandable the TOC also gets big. I've taken a look at the CSS (should have done that sooner) and simply disabling "position:sticky" stops the new TOC from being so infuriating. IMHO that should be the default, or at the very least, proper research should be done into this. Not only to determine by majority vote what users prefer (I wouldn't be surprised if sticky wins a binary majority vote) but also how crazy either option can drive users who don't like it. Pleasing a majority is no good if it causes a minority to be greatly aggravated. While I personally can get around it using technical means, that isn't true for most people. I'll also note that the experience on devices that are primarily controlled with a touchscreen may very well be different. With a keyboard, scrolling back up to the TOC is nearly no effort. Just press "home" or hold "page up". With a touchscreen, not so much, so I can see why sticky might have a greater appeal there. Alexis Jazz (talk) 07:11, 6 May 2022 (UTC)
 * What TOC? I don't get any such thing. Betaneptune (talk) 17:36, 25 May 2022 (UTC)
 * 1000px still seems like not enough for hiding the ToC. e.g. 1280 width on a rather large 16:10 projector screen and it is cumbersome and distracting. The floating option to hide it should definitely be implemented (closer to the left edge of the screen, hiding the TOC should make the content padding completely symmetrical left/right!) as that'd actually make Vector 2022 usable. Having it automatically (temporarily) pop out on mouse over would be quite nice, with a click to make it "stick" until clicked again, like a hamburger button you can hover over. For the record, I use Vector 2010 on smaller displays regardless of DPI, as well as high DPI larger screens, and Monobook on everything else. -αβοοδ (talk) 18:05, 29 July 2022 (UTC)
 * 100% agree. Football Lab (talk) 09:14, 26 June 2022 (UTC)
 * Wanted to mention a quick update on the state of the ToC. The ToC is now collapsible at all widths.  When collapsed, it is available via click next to the title of the page at the top as well as within the sticky header.   OVasileva (WMF) (talk) 11:29, 23 August 2022 (UTC)

I don't like it either. A large TOC is all you will see at first! 128.163.238.44 19:53, 22 September 2022 (UTC)

Watchlist icon
Schierbecker wrote: "The watchlist icon too closely resembles a hamburger menu button. I can see many clicking the button thinking it is a dropdown menu. Some may lose unsaved edits after clicking it."

I completely agree, but not really because it resembles a hamburger button but because it's sandwiched (no pun intended!) between dynamic menus. If there was the dropdown arrow next to the interlangs, alerts and notices buttons just like the personal menu, it would communicate more clearly that the watchlist button is a simple link and not a menu. Nardog (talk) 02:38, 21 April 2022 (UTC)


 * Thanks for this comment, @Nardog. We'll think how we could improve this. SGrabarczuk (WMF) (talk) 23:55, 27 April 2022 (UTC)
 * Information on the design process that led to the current icon can be found here:
 * https://phabricator.wikimedia.org/T297979
 * Nardog is already involved in that task. It's probably best to add this feedback there, as not all designers are reviewing this talk page. Jdlrobson (talk) 17:01, 6 July 2022 (UTC)
 * thanks @Nardog. the badge on the notifications icons complicate their layout slightly, but perhaps in the future we could have something like this (which assumes we've consolidated notices and alerts into a single button):
 * Single_notification_button_with_dropdown_arrow_indicator_(Vector_2022).png
 * AHollender (WMF) (talk) 20:58, 18 August 2022 (UTC)
 * Yes, that would be a welcome improvement. Nardog (talk) 21:21, 22 August 2022 (UTC)
 * @AHollender (WMF): btw, that screenshot contains a non-free image so I suggest you delete or redact it. Nardog (talk) 21:23, 22 August 2022 (UTC)
 * @Nardog oh whoops, just blurred it out. Thanks for the heads up. AHollender (WMF) (talk) 23:56, 24 August 2022 (UTC)

Table of contents below sidebar just doesn't work
On a broader note than the two pieces of feedback above, I have to say that my experience so far with the new table of contents has been really frustrating. As an editor, I use lots of the links in the left sidebar quite frequently, so I don't want to collapse it (and even if I did, the way it persists in whatever state you leave it in means that every time I used it it'd return). But preserving the left sidebar forces the table of contents below it, which is just awful. The number one time I want to use the ToC is when I first navigate to an article, and I either want to jump to a specific section or just to see what sections it has to get an overview. Forcing me to scroll to get to that information is extremely annoying, and if it's kept in the final version, I predict the outcry will be intense. You could resolve this either by retaining the old style ToC alongside the new (which would also solve the sandwiching concerns I've previously raised) or by moving the ToC above the left sidebar. From your previews, I know you've been working on moving some stuff around and introducing pinning, so I hope this will be resolved in future iterations. But the initial version being introduced here is clearly not ready yet. Best, &#123;{u&#124; Sdkb  }&#125;  talk 22:53, 27 April 2022 (UTC)
 * For me it seems the table of contents and the sidebar seems to be two different things. On Wikipedia, I collapsed the sidebar and the table of contents still remain. Tenryuu (talk) 03:09, 28 April 2022 (UTC)
 * I want ToC collapsed too. But there is no way to do it. It uses almost 1/3 of my screen and makes reading very difficult.- Nizil Shah (talk) 05:32, 28 April 2022 (UTC)
 * Same here. 14" Screen, collapsed sidebar menu, open only when needed. With the new TOC I cannot collapse the sidebar, it's just a toggle between navbar and TOC. I appreciate the effort and that it's a first attempt, but it definitely should be optional. And yes, I was involved in feedbacks and testing earlier. Regards Elya (talk) 14:24, 29 April 2022 (UTC)


 * +1, the TOC should be accessible from the top of the page, and collapsible (vertically; also horiz if it is making the sidebar too wide - many pages have section heads that are quite long). Sj (talk) 17:35, 2 May 2022 (UTC)
 * @SGrabarczuk (WMF) and @OVasileva (WMF), neither of you have replied here. This is a major concern, and I predict that if it is not addressed, it may single-handedly prevent the community from being willing to accept New Vector. &#123;{u&#124; Sdkb  }&#125;  talk 17:14, 6 July 2022 (UTC)
 * Hi @Sdkb - thanks for the ping! Currently, we're working on making the ToC collapsible, especially on narrow screens (T306660).  Collapsing it would allow for access further up in the page, but won't completely solve the issue you're describing.  To make using both the sidebar and the table of contents a bit easier, we are planning two things.  For logged-out users, we plan on collapsing the sidebar by default so that the table of contents will be shown further up in the page.  We are also planning on separating the tools related to pages in a separate menu.  This will significantly shorten the space for the sidebar, and create a clear definition between which tool acts on the page as a whole, and which one acts only on the page itself.  In this example, this puts the ToC above the end of the introduction section, which is higher than the previous ToC location (admittedly, this will not be the case for all articles).
 * Prototype_of_table_of_contents_and_tools_menu_for_desktop_Wikipedia.png
 * OVasileva (WMF) (talk) 14:07, 11 July 2022 (UTC)
 * Thanks for the reply, @OVasileva (WMF)! Moving the tools elsewhere (ideally to a Twinkle-like menu) is something I certainly support and have been trying to set up since the 2020 revamp, and it would help with this. Your screenshot appears to be from a standard resolution display rather than a widescreen display, so I can't tell whether it's going to help enough to ensure that the ToC will always be visible on a normal monitor with neither it nor the main menu collapsed. Getting to a point where that's the case will be essential for getting community consensus.
 * Is there a reason you don't seem to be considering placing the ToC above the main menu? &#123;{u&#124; Sdkb  }&#125;  talk 23:49, 13 July 2022 (UTC)
 * Hey @Sdkb, firstly I understand your frustration. From the data we've seen the most used links in the main menu are article tools, which as you saw we're going to be moving to the article toolbar (like TW), and also making pin-able on the right sidebar. At that point the main menu will contain many fewer links, and we don't expect many people to keep it pinned open. So the problem of the TOC being pushed down by the pinned main menu should be mostly resolved.
 * Now regarding people who might still want to pin the main menu, and are frustrated with the TOC getting pushed down the page. Unfortunately we don't have great solutions. We've prototyped putting a menu below the TOC and it gets a little complicated because if an article has many sections, and the TOC is expanded, the TOC will be very tall. And since it's fixed in place on the screen it means we'd have to introduce additional scrolling containers in order to ensure that people can always see that there is a menu below it. And then if they want to actually access the menu they would have to expand it and collapse the TOC. So it causes a lot more interactional complexity for the interface and the person using it. Placing the non-fixed main menu above the fixed TOC avoids this complexity. And since we've gotten very positive feedback about the TOC being fixed in place we don't want to change that. Here are a few prototypes we were playing around with which allow you to see the problem I'm describing:
 * - https://di-sidebar-accordion-menus.web.app/Cher (expand the first section)
 * - https://di-tools-left-collapsible.web.app/Cadmium
 * - https://di-tools-left-collapsible-belo.web.app/Cadmium
 * A secondary concern with putting the main menu underneath the TOC is that the hierarchy of information makes less sense. The site header (which the main menu will live within as a dropdown menu, which is optionally pin-able) contains global navigation. The article area contains navigation specific to the article. Placing the main menu below the table of contents breaks this organization.
 * A third concern is that, again based on the data we collected, most people (readers and editors) won't have the main menu pinned open. They will use it as a dropdown menu every so often. But we do want it to be pin-able. So then you'd have a menu in the site header that gets pinned below the table of contents. Not a huge problem, but also not intuitive or super clear.
 * Please let me know if all of that makes sense, and if you have other questions regarding this. AHollender (WMF) (talk) 21:18, 18 August 2022 (UTC)
 * @AHollender (WMF), what you mention about the expected use mode being to have the left sidebar collapsed makes a bunch of sense. From an editor standpoint, I'm looking forward to seeing the article tools moved to the article toolbar, since at that point I'll likely collapse the left sidebar myself, and after I sit with that for a little bit I'll be able to give you feedback about how well it's working.
 * There may be some editors who don't like having to make one extra click to get to the article tools, but I think you have a really low-hanging fruit way of staving off that complaint, which is to make it so that the "More", "Twinkle", article tools, and user menus open automatically after you hover the cursor over them for a quarter second or so (rather than making you click). Have you considered doing that? Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 22:39, 18 August 2022 (UTC)
 * "There may be some editors who don't like having to make one extra click to get to the article tools" — right, for sure there will be. These people will be able to pin the article tools to the sidebar, which gives them immediate access to them. We're also looking into making the article tools menu sticky, so that it remains there (like the TOC) as you scroll down the page. We have looked into menus opening on hover vs. click in the past, and think that opening on hover is less expected and sometimes distracting. If you haven't played around with it yet check out: https://di-pinable-language-menu.web.app/Moss — that one actually allows for both the language menu, and the tools menu, to be pinned to the right sidebar. Let us know what you think. AHollender (WMF) (talk) 13:28, 19 August 2022 (UTC)
 * @AHollender (WMF), I like the tools menu there a lot! Regarding menus opening on hover vs. click, when you previously looked into that, did it include the tiny delay? My (granted, limited) understanding of UX is that the delay means that it won't open when you're just moving the cursor by on the way to somewhere else, reducing the potential for it to open unexpectedly and cause distraction. The difference is small, yes, but I think that the tiny bit of reduced friction from going with open-on-hover rather than open-on-click could really help make it an easier pill to swallow for many editors. &#123;{u&#124; Sdkb  }&#125;  talk 16:46, 19 August 2022 (UTC)
 * @Sdkb I agree that adding a slight delay might help the issue of the menu accidentally opening. I guess a new issue would then be: if a menu opens on hover (with a delay), do we also allow it to be opened via a click? If so, what happens if you click it (which means you're also hovering it), and then the click and hover sort of conflict and the menu ends up opening, then closing right after? This is something I've experienced on other websites. And if we disable the click, so the menu can only be opened on hover, might some people complain that waiting for the hover delay is more friction than having to click? I wonder if 80-90% of the effort involved is moving your cursor over to the menu, and then the additional effort of clicking is minimal? Also, once we've further standardized our menus as Codex components, I imagine a gadget that switches the mechanism for opening menus from click to hover would be relatively easy to make. AHollender (WMF) (talk) 21:53, 29 August 2022 (UTC)
 * @AHollender (WMF), hmm, if that clicking conflict happens, I'd guess it means the delay is far too long. I'm not sure what the best practice length is, but I'd presume there's extensive research on it somewhere and/or it'd be possible to user test. &#123;{u&#124; Sdkb  }&#125;  talk 21:50, 30 August 2022 (UTC)
 * I will look around for research. When I Google "clicking vs hovering menu" the first few results unambiguously recommend clicking vs. hovering to open a menu:
 * https://www.liquidlight.co.uk/blog/navigation-drop-downs-should-they-be-hover-or-click/#:~:text=The%20natural%20instinct%20is%20to,the%20users%20train%20of%20thought.
 * https://wecreate.digital/blog/menu-clicks-vs-hover/
 * https://uxmovement.com/navigation/why-hover-menus-do-users-more-harm-than-good/
 * https://www.smashingmagazine.com/2021/05/frustrating-design-patterns-mega-dropdown-hover-menus/
 * AHollender (WMF) (talk) 22:05, 30 August 2022 (UTC)
 * What if the sidebar was able to be toggled with a single click between the ‘normal/traditional sidebar contents’ and the article ToC?
 * Importantly, the main article ‘column’ would not visually appear to refresh/reflow when the sidebar contents are toggled.
 * As an additional enhancement, the sidebar could be toggled between three (or more) states, e.g.:
 * Traditional sidebar content
 * (or traditional sidebar content + ToC, similar to the mid-2022 prototype)
 * ToC only
 * Blank space (except for the ‘toggle’ button, of course)
 * Perhaps as a user preference, items could be added/removed from the rotation for logged-in users (or anonymous users with cookies enabled), and possibly even re-ordered, e.g.:
 * Add the language list/menu to the rotation before the ‘blank space’ option
 * Remove the ‘blank’ option, so it is just a two-position toggle between tools and ToC
 * Remove all options but one (and when only one option was enabled, the ‘toggle button’ would of course be either ‘greyed-out’ or omitted)
 * Precedents:
 * Some software does this with a tabbed interface (e.g. 1: PDF readers than can show a list of bookmarks, or ToC, or search results, all in the same area; 2: palettes in applications like Adobe Photoshop/GIMP).
 * Sometimes a ‘toggle’ mechanism is used instead, for simplicity or economy (e.g. 3: Automobile stereos that allow multiple ‘banks’ of radio station presets often display them )
 * For our purposes, ‘toggling’ may make more sense than ‘tabs’ (the sidebar could optionally could upgraded to allow navigating the alternative content via swiping, in addition to button clicking, in the future regardless of which method is used).
 * - Jim Grisham (talk) 19:35, 19 September 2022 (UTC)
 * I really miss being able to see - at a glance - how long the article could be, and the general topic areas in the article itself. Could it be possible that the TOC sits under the header AND then stays in the sidebar as you scroll? Turini2 (talk) 18:14, 27 August 2022 (UTC)
 * @Turini2 can you clarify what you mean by:
 * - "see how long the article could be" — what enabled you to do this previously, and what has changed here?
 * - "see general topic areas in the article itself" — what enabled you to do this previously, and what has changed here?
 * - "TOC sits under the header" — which header do you mean?
 * If you are able to add a mockup or annotated screenshot that would be helpful. AHollender (WMF) (talk) 16:16, 29 August 2022 (UTC)
 * @AHollender (WMF) https://imgur.com/a/dl4TOza I hope this helps. Turini2 (talk) 17:01, 29 August 2022 (UTC)
 * @Turini2 thanks for adding the screenshot. I'm not sure I understand what issues you're experiencing. Can you respond to the questions I wrote in my comment above, to help me understand? AHollender (WMF) (talk) 17:11, 29 August 2022 (UTC)
 * Previously, the TOC located underneath the lead allows you to see the general length (and topics) that the article contains. In the new layout, the TOC is off to the side, and is hidden from view until you scroll down. Furthermore, the nested nature of the new TOC means that it is more of a chapter list, than a useful TOC.
 * With regards to my suggestion - I think it would be nice to have a TOC similar to previous underneath the lead, while also maintaining the position in the sidebar. Turini2 (talk) 17:15, 29 August 2022 (UTC)
 * @Turini2 thank you for clarifying, I understand now. A few notes:
 * If you collapse the main menu the TOC is available at the top of the page (which for many articles is not the case in Legacy Vector, because you have to scroll past a sometimes long lead-section in order to get to it). Soon we will be moving the tools menu to the article toolbar, making it less necessary for people to keep the main menu pinned open. You can see that in a prototype here: https://vector-2022.web.app/Moss. At that point we think most people will be satisfied with having the main menu collapsed.
 * Re: the sub-sections of the article being nested/collapsed in the TOC — I think there are tradeoffs either way. When they are nested/collapsed you can more easily scan the top level sections of the article, vs. if they are not nested you might have to scroll quite a bit to see the entire TOC (for example en:Paris). We do have a bit of logic in there so that if the TOC sections can be fully expanded while still fitting on a screen of average height, they will be (e.g. en:Plant Stem). @Quiddity (WMF) has written some CSS that automatically expands the sections in the TOC, which you can find here: User:Quiddity/Vector-2022-condensed.css.
 * We looked into having the TOC both as a sidebar, and inline within the article. Ultimately we decided that it would be confusing to have the same element in two places on the page, especially considering they would be right next to each other at times. We also looked into having the TOC inline, and then once you scroll past it making it available as a floating/fixed element. You can see that prototype here: https://di-toc-supplementary.web.app/Sushi. We tested this and ultimately decided against it because (a) it's more simple for the TOC to always remain in the same location, and (b) if the lead section is long you have to scroll for the TOC rather than it being at the top of the page.
 * AHollender (WMF) (talk) 22:12, 29 August 2022 (UTC)
 * the menu shouldn't be collapsed on a desktop. Macslan (talk) 07:28, 6 September 2022 (UTC)
 * I fully agree with @Turini2 on having both the old TOC and the new one when the old goes off-screen. 37.163.183.27 16:51, 20 September 2022 (UTC)
 * +1, I like the new TOC itself but pushing it all the way down past the  tools sidebar is bad. TOC should be immediately visible from the start, without any scrolling. The tools block eats a huge amount of prime real estate, and I don't think I've ever used it in decades of Wikipedia-ing. 2A00:23C7:7B23:5201:15F5:8B5B:2459:D3F3 03:58, 9 September 2022 (UTC)

Instant jumping vs. animated scrolling for table of contents
As you're polishing up the table of contents, one thing it'd be nice to consider is the behavior when you click on a section in it. Currently, it instantly jumps to that section, but I think it'd be better if it instead did a very quick scroll (maybe a quarter of a second). This would help readers to more easily understand what's happening when they click the link, and to get a better intuitive sense of what the article contains by seeing it flash by. Would that be possible? &#123;{u&#124; Sdkb  }&#125;  talk 02:37, 30 April 2022 (UTC)


 * Bumping @SGrabarczuk (WMF) and @OVasileva (WMF). &#123;{u&#124; Sdkb  }&#125;  talk 17:12, 6 July 2022 (UTC)
 * Hey @Sdkb, thanks for raising this question. Yes that would be possible and is a very easy change. All it requires is adding this CSS rule to the HTML element: . (If you know how to use the developer tools in your browser you can add this rule yourself and then see how it feels to you). We looked into this in the past and decided that since pages can be very long the animated scrolling transition might be dizzying (especially if you jump between a few different sections somewhat rapidly). However I do see value in it (for the reasons you mentioned), and we did not test the two options with people. I will setup a simple test on usertesting.com and gather some feedback. I've added a GIF below that demonstrates the animated scrolling.
 * Animated_scrolling_when_clicking_table_of_contents_links_in_Vector_2022.gif
 * AHollender (WMF) (talk) 21:31, 18 August 2022 (UTC)
 * @AHollender (WMF), wonderful; I'm curious to see the results! &#123;{u&#124; Sdkb  }&#125;  talk 22:21, 18 August 2022 (UTC)
 * Please please please, no animation during the scroll! I'm disabled and that gives me headaches and it would decrease the amount of time I could spend reading and editing, which are already reduced due to illness. Thank you for your consideration! I already had to change a browser when it started scrolling instead of jumping when searching a page for a particular word. I don't remember which one it was even at this point because I had to run away so fast. Thanks again! Geekdiva (talk) 11:15, 13 September 2022 (UTC)
 * I didn't realize some people experience that, @Geekdiva; that's very good to know. I'm still interested to know whether animated scrolling would help out the average user, in which case it should be the default, but if so there should certainly be a setting or at least a gadget so that you and any others with a similar reaction can opt out. &#123;{u&#124; Sdkb  }&#125;  talk 16:30, 13 September 2022 (UTC)
 * Hey @Sdkb, following up with notes from a WMF design review, and the simple test I ran on usertesting.com.
 * Firstly, here is the prototype I used for both the design review and the user tests: https://di-toc-instant-animated.web.app/China. The options panel in the lower right hand corner allows you to switch between instant jump and animated scroll. Give it a try.
 * WMF design review notes:
 * There were 5 designers present at the review
 * All 5 designers preferred instant jump
 * The main reasoning was that animated scroll is dizzying, especially if you are flipping through several sections in order to try and find something
 * Secondary reason was that animated scroll is not necessary, and does not add value to the experience
 * Carolyn mentioned that animated scroll has the risk of causing seizures, and referenced this case study, and this blog post
 * To note: in my experience it's not very common for all designers at a review to be aligned on one option. In other words it's a fairly convincing thing when it occurs.
 * Usertesting.com test results:
 * 13 people tried both instant jump and animated scroll
 * 7 people preferred animated scroll. Reasons for this preference were:
 * It's more fun / exciting / engaging
 * Gives a better sense of the layout of the page / directionality / orientation
 * 6 people preferred instant jump (two of which expressed a very strong preference, i.e. "definitely not animated scroll"). Reasons for this preference were:
 * Faster / more direct / more simple
 * Animated scroll is distracting / dizzying / "yucky for my eyes" / too much going on on the page
 * Other notes:
 * None of the testers who preferred animated scroll disliked instant jump, whereas all but one of the testers who preferred instant jump expressed a dislike (or strong dislike) for animated scroll
 * Two of the people noted that while animated scroll might help with orientation on the page, this is already clear/obvious from the order of the links in the table of contents
 * For some people scrolling was laggy with animated scroll
 * With animated scroll there is the side-effect of each section heading in between the section you are currently on and the one you've clicked on getting bolded/unbolded in rapid succession
 * With animated scroll if you press the  button (as one tester did several times) it animates between each section in your browser history
 * Given this feedback I think the best decision is to stick with the current behavior, rather than switching to animated scroll. The way I'm thinking about this is: the user testing was roughly equal in terms of preference, though about half of the people expressed a dislike for animated scroll (whereas none expressed a dislike for instant jump). Additionally, the WMF designers were all in favor of instant jump. I ultimately trust the WMF designers to have a slightly better sense of how a design/interaction will be received over time, whereas the limited tests give more of a first impression type of feedback (which may not hold true over time).
 * Let me know what you think about all of this, and thanks again for raising this topic. AHollender (WMF) (talk) 23:45, 13 September 2022 (UTC)
 * Thanks for looking into this! Sticking with instant jumps seems reasonable given that research, although with more than half of participants preferring animated scroll, it seems like it'd be worthwhile to have a gadget to enable that. &#123;{u&#124; Sdkb  }&#125;  talk 04:28, 14 September 2022 (UTC)
 * @Geekdiva thanks for adding your perspective and preferences here, it's helpful. AHollender (WMF) (talk) 23:11, 13 September 2022 (UTC)

Trouble With Zooming In
My vision is poor so I usually zoom to 200% on my browser and it is no problem. With the new skin that same magnification causes the sidebar to take up the top of my screen and I can't see the title of the article and know what page I'm on without scrolling.

Language switcher opt-out
The new language picker is a deal breaker for me as an active editor who is working with a very diverse array of topics on Wikipedia. I write about Māori language, Japanese geisha, Taiwanese literature, Inuit cuisine, Paraguayan instruments, Vietnamese temples, Algerian regions, Berber cuisine, Arabic professions. I write articles that compare dozens of cultures or languages.

I need a way to hover over the list of languages to see the name of the page in a different random language (which can be anything from Korean to Twi). I need to be able to open 50 language editions very quickly to estimate if any of them have good illustrations or any new literature on the topic that I am working on. I often read the same article in 4 languages simply because I can read in a lot of languages and I am wondering which language edition has the best article. The workflow with the new language picker is tremendously stunted.

The main idea of the new interface seems to be making the page width more narrow. With that, there is a lot of free space at the sides, and I would like to propose putting a full list of languages there, as an option. Le Loy (talk) 00:29, 13 June 2022 (UTC)
 * Yes, I agree, the decision taken now does not help advanced editors work in projects, but hinders them. I think we need to make a separate setting for the "always open" list. The problems of this list have still existed since sorting was removed. Iniquity (talk) 15:43, 14 June 2022 (UTC)


 * --Wdpp (talk) 11:47, 3 July 2022 (UTC)
 * Hey @Le Loy, thanks for your feedback and I'm sorry for your frustration with the language switcher. Can you please see my comment on the other language switcher thread above (link to thread) and reply there with any feedback or thoughts you have? Thanks AHollender (WMF) (talk) 21:33, 18 August 2022 (UTC)

Feedback regarding Vector (2022) TOC
I've had Vector (2022) enabled for a while, and generally like it. However:


 * I don't feel the new way of handling the TOC and side menu is user friendly. It took me a while to notice I could hide the side menu only to raise the TOC up the page, as I assumed it would also hide the TOC since the two are part of the same sidebar. With the side menu visible, I had to scroll much further down than usual to find the TOC on many articles with short lead sections, which undermined the convenience previously provided by the TOC as a way to skip scrolling and quickly navigate to a desired section.
 * It also doesn't help that the new TOC breaks the functionality of Skip to talk, widely used on talk pages on Wikipedia, but I now understand that the change is intended to make that template unnecessary.
 * The prototype linked by others above deals with some of these issues but is still a bit confusing. It's not clear that clicking "hide" on the TOC should result in a menu appearing by the article title rather than just collapsing it like collapsible lists which use the same "[hide]" links; while this behaviour can be learned, it's not clear why the hidden TOC menu button doesn't persist between the search icon and article title when scrolling down, which is what I expected after seeing it collapse to a button beside the article title.


 * The new sidebar is wider to accommodate the TOC, but much of that space is blank so I'm not sure it needs to be quite so wide, particularly as the added width can cause issues such as galleries by default having less space for images per row. I understand the motivation is to limit the characters of text per line, but doing so by padding the sidebar with empty space seems like an unhelpful way to achieve that. Scyrme (talk) 16:57, 26 June 2022 (UTC)


 * I want to chime in about the "hide" behaviour. I noticed the link for the first time right now, tried clicking it and was a confused when it disappeared altogether. I would have expected the link to change to "show" and the table itself to hide. It took me a while to find the icon in the header. I think that if it should behave this way, it needs to somehow be communicated to the user where the TOC goes. Sebastian Berlin (WMSE) (talk) 10:42, 3 August 2022 (UTC)
 * Hey @Sebastian Berlin (WMSE), thanks for your feedback.
 * For people with smaller screens we want to be able to get the space back when they hide the table of contents. That's why it moves next to the article title, rather than staying in place and taking up space in the sidebar.
 * We will be working on https://phabricator.wikimedia.org/T311160 soon, which will help people understand where the table of contents has been hidden.
 * AHollender (WMF) (talk) 17:16, 29 August 2022 (UTC)
 * Thanks for these comments @Scyrme. I'm curious if your thoughts have changed at all as you've spent more time with Vector 2022? A few notes and updates from our end:
 * Re: "With the side menu visible, I had to scroll much further down than usual to find the TOC on many articles with short lead sections" — as you've seen we're working on addressing this by moving the tools menu to the page toolbar, making it much less necessary to keep the main menu "pinned" open. Here is a more recent prototype: https://vector-2022.web.app/Moss
 * Re: "Skip to talk" — right, that template is not necessary in Vector 2022
 * Re: "It's not clear that clicking "hide" on the TOC should result in a menu appearing by the article title rather than just collapsing it like collapsible lists which use the same "[hide]" links" — we're aware of this. We're going to see if we can come up with something better than "[hide]".
 * Re: "it's not clear why the hidden TOC menu button doesn't persist between the search icon and article title when scrolling down" — we're almost done with T311103 which adds this functionality
 * Re: "The new sidebar is wider to accommodate the TOC, but much of that space is blank so I'm not sure it needs to be quite so wide" — because some articles have longer section titles than others it's difficult to find the right width for the TOC. For example on en:Cher, if you expand the "Life and career" section, the section titles wrap onto multiple lines. Whereas on other articles there is more than enough space. We're working with the design systems team to fine-tune the spacing here.
 * AHollender (WMF) (talk) 17:00, 29 August 2022 (UTC)

New feedback

 * Thanks for the response!
 * The new sticky TOC menu button is a great change! It resolves my earlier complaints specific to the TOC and makes navigating long articles much easier. I feel the only major issue in regards to user-friendliness is the use of "[hide]" links, and I'm glad to read that you're investigating alternative solutions. My only new issue is that the TOC doesn't seem to remember that you pinned it to the toolbar when clicking over to a different article. That might be deliberate, as it would save a click if you wanted to go straight to the TOC of the next article, but I'd like an option to keep it pinned until I unpin it.
 * Re: the more recent prototype; I like the narrower toolbar and the revised main menu and TOC. I particularly like that the main menu and TOC both consistently use "hide"/"move to sidebar", making how they function much clearer. I also really like the "Tools" menu. In general the new prototype looks much tidier and is an improvement. I don't know whether the prototype lacking the option to pin the TOC to the toolbar is intentional. If it is, I feel a sticky button beside the title is much more helpful and user friendly than a popout that sticks to the page only if you scroll with the TOC expanded.
 * A minor issue I've noticed on both the prototype you linked and in the current version of Vector (2022) is that the article content appears slightly off-centre, to the left. It seems that the design doesn't take into account the width of the scrollbar on the right side of the page.
 * A different issue I've noticed is that when switching between articles and special pages, the content jumps jarringly to the left as the page's content takes up the full width of the page unless the main menu is unpinned. I understand special pages were deliberately allowed extra width, but it creates an uncomfortable discontinuity when switching between the different areas. Having the sidebar expanded on special pages alleviates this, but it also negates the benefit of allowing special pages extra space. I would suggest only allowing special pages to take up the same width as an article with the sidebar and TOC both hidden; this would ease the transition between different types of pages, and would only narrow the space to about as much as was previously available in the old default theme.
 * I'm looking forward to seeing the next revision of the theme. Scyrme (talk) 20:41, 29 August 2022 (UTC)
 * @Scyrme thanks for this helpful reply.
 * Great point about the TOC remaining pinned when switching pages. I've added this as an open UX question to review with the Web team and the Design team next week. I will follow up with you once we've taken some time to consider the tradeoffs.
 * Re: "I don't know whether the prototype lacking the option to pin the TOC to the toolbar is intentional" — can you clarify what you mean here?
 * Re: "It seems that the design doesn't take into account the width of the scrollbar on the right side of the page" — interesting, I hadn't noticed this. I know that the width of the scrollbar varies based on the operating system and browser. We've also started discussing using a customized scrollbar (though it's difficult to ensure consistency across browsers). I've made a note to look into this.
 * Re: switching between article pages and special pages — yup, this is a challenge we've also identified. A longer-term hope is that with some light reformatting most special pages (in particular Log pages) will no longer need to be full-width (and would even be easier to read with the limited width). In terms of "only allowing special pages to take up the same width as an article with the sidebar and TOC both hidden", I'm worried that editors wouldn't be satisfied with this, as it would be only 960px. Currently, in Legacy Vector, if you have a large monitor Special pages can be as wide as your screen is (minus the width of the sidebar). Though perhaps I'm misunderstanding your suggestion. Also, could you add a bit more context regarding a specific workflow here, and how often you end up switching between pages with a limited with, and special pages that don't have a limited width?
 * AHollender (WMF) (talk) 21:43, 29 August 2022 (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)
 * @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?
 * [[File:Truncated_section_titles_in_table_of_contents,_with_tooltip_on_hover_(Vector_2022).png|thumb|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)

The new sidebar TOC is confusive, not intuitive, unusable
I strongly oppose the new sidebar TOC. It is extremely confusing, not intuitive, and unusable. The removal of the numbering for paragraphs and their transformation into collapsible lists, will make the articles and discussions unreadable, as their structure will be completely unclear.

The TOC at the top of the article right below the lead text was perfect for giving a clear impression of the article's structure and for exploring its contents.

I think that keeping both the old and the new TOC (if the latter is really necessary) would be a good solution. The new TOC proves useful only in the bottom sections of very long articles. 2001:B07:A2A:1884:D5D:3606:C70C:5366 14:03, 17 July 2022 (UTC)
 * Second that. Another point of note is that the narrow sidebar is a poor match for long section titles. Even in English wikipedia, some headings must be split in two narrow lines, or three. Other languages, that are naturally more verboise than English, are even more affected. Retired electrician (talk) 08:16, 29 July 2022 (UTC)
 * Thanks for your comments. I just replied to a different topic on this page regarding why we decided not to put the TOC both inline and in the sidebar. I am pasting that reply here:
 * We looked into having the TOC both as a sidebar, and inline within the article. Ultimately we decided that it would be confusing to have the same element in two places on the page, especially considering they would be right next to each other at times. We also looked into having the TOC inline, and then once you scroll past it making it available as a floating/fixed element. You can see that prototype here: https://di-toc-supplementary.web.app/Sushi. We tested this and ultimately decided against it because (a) it's more simple for the TOC to always remain in the same location, and (b) if the lead section is long you have to scroll for the TOC rather than it being at the top of the page.
 * AHollender (WMF) (talk) 22:17, 29 August 2022 (UTC)
 * @AHollender (WMF): 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 be aesthetically elegant, indeed. 37.160.249.144 10:21, 6 September 2022 (UTC)
 * Instead of having both versions showing simultaneously, we could use the model used by the original Macintosh OS Finder (Note: this was never ~intentionally~ removed by Apple; rather, the new interface was included with their purchase of NeXT and some features from the original Finder were never re-implemented, likely since this model was intellectually/logically incompatible with the ‘column browser’ feature imported from NeXTStep); it worked something like this:
 * A Finder directory window could only ever exist in one place on the screen at a time, since just as in the physical world, no single object is allowed to exist in more one place simultaneously.
 * If double-clicking on a folder (i.e. to ‘open’ it) would result in a opening new window with the ~same filesystem path~ as an existing window, the matching existing window would be automatically closed immediately prior to the new one appearing.
 * Additionally, when the contents of a folder were being displayed in a window, the icon for that folder would appear in a grey silhouette, as an un-changed icon would violate the rule in a different way.
 * (a physical file folder placed on a conference table looks very different when closed than when that same folder is open and displaying its contents, after all)
 * How would a similar principle work with this skin on MediaWiki? One possibility:
 * If a sidebar ToC is currently displayed:
 * The article inline ToC starts in its ‘collapsed’ state (but remains in the traditional location).
 * If the user clicks to expand the inline ToC, the sidebar ToC disappears, collapses, or the sidebar rotates to display tools or blank space (if a ‘toggle’ or ‘carousel’ model is chosen for the sidebar, as discussed elsewhere on this page).
 * (without changing the width of the main article column or causing any reflow in article parts above the inline ToC, of course)
 * If the user decreases the window/viewport width or increases browser zoom level, such that the sidebar itself will no longer be displayed, the inline ToC should probably not auto-expand. (…but there ~may~ be some users/use cases where auto-expanding might be appropriate in this case?)
 * If the sidebar ToC was displayed automatically due to the user scrolling the article entirely past the inline ToC (i.e., per the next set of rules), the inline ToC should remain collapsed if the sidebar ToC is scrolled off of the screen, unless the scroll is ‘jumped’ directly to the top (e.g. by pressing the ‘home’ button on a keyboard).
 * (Once a user scrolls ~entirely~ past an in-line ToC, its utility is likely marginal for the remainder of that page viewing session)
 * If the wikitext on a particular page explicitly specifies the inline ToC should be initially collapsed (i.e. by using a Template, Magic word, or Parser function), it should never be automatically expanded, regardless of what happens in the sidebar.
 * In this case, it might be prudent not to automatically display a sidebar ToC, either.
 * If the sidebar ToC is not currently visible (e.g. on initial page load for anonymous users), if the user expands the sidebar ToC (or takes any action to display the sidebar ToC), the article ToC:
 * Collapses, without visible reflow, if the inline ToC is currently off-screen.
 * Collapses, with visible reflow, if inline ToC is currently on-screen (with the exception of #4 below).
 * Collapses, with visible reflow, if the sidebar ToC is now displayed due to user action such as scrolling, enlarging the window/viewport size, or increasing the browser font display size/zoom level.
 * Is greyed out but left expanded, if the sidebar ToC appears due to article scrolling, or collapses and is replaced with whitespace to prevent visible content reflow, until it is scrolled completely out of the viewport.
 * If while viewing a page, the user explicitly expands or collapses the inline ToC, any automatic expansions should be disabled until the page is reloaded.
 * (Note: The above logic, modified or not, can likely be expressed in a straightforward Truth table to check the logic, aid the developers, and to inform anyone writing documentation.)
 * If the above was implemented, a user preference to Display table of contents in both article body and sidebar could be provided to turn off this ‘auto-collapsing’ behavior.
 * - Jim Grisham (talk) 21:38, 19 September 2022 (UTC)

Sorry but user expereince is kind of awful
Okay. I've given "Vector 2022" a shot for a while and it is just confusing and difficult to use. Too much animation-style issues. Too much whitespace. Difficult discovery of functions. Difficult to obtain a feeling of confidence in mastery. If I would have been keeping a log, I'd have dozens of gripes by now. I don't wish to waste time enumerating specific things because it's besides the point because the entire experience is bad. I can't hack it anymore. I thought I'd get used to it but I'm going back to Vector 2010. Keep things simple. Keep it static. I know many people but a lot of work into this and it was a valid attempt but it just didn't suceed in improving over Vector 2010. Jason Quinn (talk) 02:24, 26 July 2022 (UTC)


 * @Jason Quinn thank you for trying it out, and I'm sorry to hear that it is no longer working for you. If you end up giving it another chance at some point I highly recommend these CSS adjustments written by @Quiddity (WMF): User:Quiddity/Vector-2022-condensed.css. They result in a more dense, and I suppose somewhat more static, version of Vector 2022, which might be closer to some of the things you like about Vector 2010. AHollender (WMF) (talk) 22:28, 29 August 2022 (UTC)

Sticky header causes TOC to instantly offset on appearing
When scrolling down a page, at the moment the sticky header shows up (smoothly), the TOC offset is incremented to display below the header. However, the TOC offset change is instant, unlike the header. It's just a small visual thing, but I think making the TOC offset to follow the smooth header apparition would make pages look more reactive. Regards, Epok (talk) 18:54, 29 July 2022 (UTC)


 * @Epok thank you for this perceptive comment. We recently got a similar report from @Quiddity (WMF) and have created a task to address this, which you can find here: https://phabricator.wikimedia.org/T314330. This issue will be fixed in the next few weeks : ) AHollender (WMF) (talk) 22:32, 29 August 2022 (UTC)

Sticky sidebar overlaps footer
I wonder if anyone have noticed it: when you scroll down until the end of the page (from a desktop) the sticky sidebar overlaps the footer. Because of this, it's impossible to read part of its content and it looks pretty weird. I don't know much about how MediaWiki works, but maybe applying z-index and background-color (or something similar) to the footer could be a possible solution?

Cheers, Anidae (talk) 22:18, 29 July 2022 (UTC)
 * Hello @Anidae. Thanks for writing here. Yes, we've noticed the bug and we'll fix it. SGrabarczuk (WMF) (talk) 11:49, 1 August 2022 (UTC)

(merged threads)

I'd first like to say that I love having the table of contents over on the left, it makes so much sense and is really helpful. But one issue is that the text at the bottom (where it says "This page was last edited on ..." and "Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.") is cut off by the TOC.

I could imagine two solutions for this: either the bottom text could remain the width it is now and the sticky TOC would stop above it, or the width would be the same as the article and the TOC would just continue. As it is now, it's just really visually irritating. BappleBusiness (talk) 19:07, 29 August 2022 (UTC)


 * @BappleBusiness thanks for reporting this issue, and super glad to hear that you like the new location of the TOC. Does this task appropriately describe the issue you're seeing: https://phabricator.wikimedia.org/T313060? If not, would it be possible for you to add a comment to it?
 * Thanks! AHollender (WMF) (talk) 17:52, 30 August 2022 (UTC)
 * Yes, this is the issue, thank you. BappleBusiness (talk) 19:05, 30 August 2022 (UTC)

Design decision against the Wikimedia Movement strategy recommendations
Hello! The Desktop Improvements (sic) project has decided, against the Wikimedia Movement recommendations, to hide by default the links to sister projects to non logged users. The Improve User Experience recommendation textually says:


 * Tools to connect cross-project and cross-language functionalities to provide an enhanced experience of the knowledge contained in the Wikimedia ecosystem for a particular interest, informational need, or inquiry. (bold text is mine).

We can have different views on aesthetics, but hiding the cross-project links instead of making them more prominent is against the recommendations. I have tried to discuss this in Phabricator, but there doesn't seem to be any way to discuss seriously this error. Thanks. Theklan (talk) 20:27, 1 August 2022 (UTC)


 * Theklan, thank you for your concern and for keeping us on our toes. To clarify: the idea behind the goal that you've quoted is is to build systems and tools (such as structured data) that allow us to incorporate content from sister projects within Wikipedia. As we know from data collection simply linking to sister projects does not work effectively. So I respectfully disagree that we're are going "against the Wikimedia Movement recommendations".
 * Secondly, as we've discussed in the past: with each improvement comes a tradeoff, and sometimes when our principles/goals conflict with one another we are forced to make difficult decisions. So even if we had a movement goal to provide links to sister projects (which we do not), it still might be okay to collapse those links in some cases. We cannot offer people every link at all times — we know from research that this decreases the quality of the overall reading experience. So yes, the links in the sidebar are more difficult to access now. We are already aware of this. But the overall improvement to the reading experience makes this tradeoff worth it. This is the conclusion we have arrived at through data collection and testing. These decisions are not easy to make, and we know that certain people will be upset by them. I am sorry if you disagree with the conclusion we have come to.
 * Thankfully the Structured data team are actively working on various experiments that bring content from sister projects directly into Wikipedia. You can read more about that project here: https://phabricator.wikimedia.org/T306341. AHollender (WMF) (talk) 22:31, 1 August 2022 (UTC)
 * "Bring content from sister projects directly into Wikipedia" doesn't seem like a recommendation, because we can also bring content from Wikiquotes to Wikisource, without using Wikipedia. So, sorry, but no. This recommendation is clear: disconnecting cross-project links goes against the recommendation. Theklan (talk) 07:58, 2 August 2022 (UTC)
 * @Theklan you can read more about how content from sister projects is being incorporated into Wikipedia here: Structured Data Across Wikimedia/Search Improvements AHollender (WMF) (talk) 16:03, 2 August 2022 (UTC)
 * That's a good initative, yes. Is not related to what we are discussing here. What are the steps to make links to sister projects more prominent in the new design? Theklan (talk) 08:04, 3 August 2022 (UTC)
 * In my understanding that question was already answered above: "simply linking to sister projects does not work effectively". --AKlapper (WMF) (talk) 10:35, 3 August 2022 (UTC)
 * "Simply linking to sister projects does not work effectively" can be a good sentence. Just deleting the links is, surely, less effective than having there. If the links there are not effective, we should have a place to put them on (that was my only point in the Phabricator ticket, but as usual it gets ignored, or the discussion goes to harassment if I have a point). Is there or will there be a place to put the links, or are we going to get rid of them just because they weren't prominent? (I remember that I have been constructive in this discussion, I even presented a mock-up to make my point more clear). Theklan (talk) 17:49, 3 August 2022 (UTC)
 * @Theklan I think collecting data is a good first step, so we can better understand how the previous solution was being used. I am hesitant about adding more menus/links around the content, again because we know from the data that the links in the sidebar weren't being used much, and that they distracted from the reading experience.
 * Would it be possible to explore the usage of these sister project link templates on Basque Wikipedia? I wonder if we can also collect data for clicks to those templates. Also would it be possible to experiment with adding these links to infoboxes on some articles?
 * Screenshot_of_sister_project_links_template_on_Albert_Einstein_article.png
 * Screenshot_of_sister_project_links_template_on_Muhammad_Ali_article.png
 * AHollender (WMF) (talk) 18:56, 8 August 2022 (UTC)
 * Links to Commons are added to every infobox at Basque Wikipedia if a Category exists. All those links are at the bottom, and are included by hand. Some big wikis have it automated, and we also have it automated at Basque Wikipedia, because we use Wikidata extensively. Is not the case for 800+ wikis. We could just make things easier, and add the links to cross-wiki projects (as intended in the Movement Strategy) somewhere visible. For example, below the title. That would be a move along the Movement Strategy. Theklan (talk) 19:21, 8 August 2022 (UTC)
 * which data collection? David Wadie Fisher-Freberg (talk) 13:33, 7 August 2022 (UTC)
 * @David Wadie Fisher-Freberg my apologies — after reviewing the data I realized that those links were not included (to clarify: "wikidata" refers to all sister project links):
 * "'Donate, store and wikidata links currently excluded. Unable to track as they direct to external sites. Need instrumentation.'"
 * The report is here: https://nbviewer.org/github/wikimedia-research/Desktop-behavior-analysis-Aug-2019/blob/master/Desktop_usage_behavior_analysis.ipynb#Sidebar-links
 * So we know, high level, that people were hardly clicking most of the sidebar links (which is why I made the assumption about the sister project links). We are now discussing as a team how we can collect data about these links. I apologies again for providing incorrect information. AHollender (WMF) (talk) 17:44, 8 August 2022 (UTC)
 * thank you for your reply. I am deeply concerned with this change, and without more information I doubt that I could buy the "no one's clicking this so we should remove it" argument. Would appreciate if there is a clearer timeline and plan from your side on the planned data collection for the links. Thanks, David Wadie Fisher-Freberg (talk) 12:26, 9 August 2022 (UTC)
 * At the same time, it would be a wise move to reverse the sidebar hidding, while a solution to the cross-wiki links is found and we gather data about real usage. Theklan (talk) 11:33, 10 August 2022 (UTC)
 * @David Wadie Fisher-Freberg right, so the tricky thing is that we can't have everything on the screen at once. In order to improve the interface there are tradeoffs we have to make. What is more important: having the best reading experience possible, or having links to sister projects immediately available on the screen? What is more important: having immediate and persistent access to the table of contents, or immediate access to links to the sister projects? Collapsing the sidebar allows us to significantly improve the reading experience, and make the table of contents immediately accessible. In our opinion these features are of higher order importance. We want the site to be welcoming to everyone, and ideally be the best place on the internet for reading and learning. I think we can work together to figure out what to do about these links, but it would be helpful if you could acknowledge that the changes we've made are for good reasons. We need to think about the "forest", not just individual "trees" (or we will end up again with a cluttered, confusing interface). AHollender (WMF) (talk) 17:17, 12 August 2022 (UTC)
 * I understand the perspective which you came from. I don't agree that removing the links to sister projects would obstruct the aim to have the best reading experience possible. Our Strategic Direction explicitly stated that by 2030, "we will become a platform that serves open knowledge to the world across interfaces and communities". This decision of yours would stand in its way. I agree we can work together to figure out what to do about these links. My suggestion is to keep it where they have been for many years. David Wadie Fisher-Freberg (talk) 04:03, 13 August 2022 (UTC)
 * There's even a better suggestion: make them more prominent. Just use the tagline, that is the most visible place in all the screen. Theklan (talk) 09:55, 13 August 2022 (UTC)
 * @AHollender (WMF) Can we at least get confirmation that you will not try to sabotage local language versions that will add these links back in their common css/js files because they think they are important? Perhaps will you even make sure such local changes are easy (in line with the strategy Enable the empowerment of local communities) by providing simple configuration and documentation? Ainali (talk) 13:46, 7 August 2022 (UTC)
 * Just to clarify, @Ainali, the links won't disappear, but will be hidden if you don't click on the menu button. Istead of looking for a better and more prominent place for them, they will be hidden from general public, making our ecosystem poorer. Theklan (talk) 17:15, 7 August 2022 (UTC)
 * Yes, I understood. I meant "add back" as in make them easily available again. Ainali (talk) 17:37, 7 August 2022 (UTC)
 * @Ainali thanks for your question. As I mentioned above, each link in the interface comes with a tradeoff (often to the reading experience). If communities decide that the inclusion of these links directly on the page (i.e. not within a menu) is important to them, we will support them in figuring out a way to make this modification. AHollender (WMF) (talk) 17:48, 8 August 2022 (UTC)
 * Again, Alex. Is not that is "important to them". Is that is important for the whole movement as stated in our Movement Strategy. I was part of the team who made the recommendation, so trust me: we were talking about this. Theklan (talk) 19:23, 8 August 2022 (UTC)


 * As a courtesy notification, I've also inserted this to the ongoing discussion at English Wikipedia. David Wadie Fisher-Freberg (talk) 04:46, 13 August 2022 (UTC)
 * any follow-up on this? David Wadie Fisher-Freberg (talk) 03:57, 26 August 2022 (UTC)


 * It seems pretty straightforward to me that it's better for the sister projects if there are fewer but more obvious ways to get into the community, as someone who's involved in the community is far more likely to also find the sister projects. The status quo, where we show links to the sister projects indiscriminately to - statistically speaking - people uninterested in them, comparatively would be less effective. Enterprisey (talk) 19:52, 30 August 2022 (UTC)

ToC in the diff view
In revision comparison mode, ToC looks like a regular bulleted list without styles https://en.wikipedia.org/w/index.php?title=Botany&diff=1101340041&oldid=1098510198&diffmode=source Sunpriat 21:18, 2 August 2022 (UTC)
 * Thank you, we'll work on it. You can follow our activities on Phabricator. SGrabarczuk (WMF) (talk) 12:08, 4 August 2022 (UTC)
 * I think it's a wrong phabricator task. There are no images with "* 3.5" there. IKhitron (talk) 23:17, 10 August 2022 (UTC)
 * @Sunpriat, IKhitron, what should be there instead? What would be the expected look of the ToC in the diff view? SGrabarczuk (WMF) (talk) 16:29, 28 August 2022 (UTC)
 * IMHO, just like now, but removing the black bullets. IKhitron (talk) 16:34, 28 August 2022 (UTC)
 * In uniformity with the new way - in the sidebar and the sticky header drop-down list. Sunpriat 17:46, 28 August 2022 (UTC)

The search widget
In the search widget, there should be a technical wheel button for changing the settings available (the advanced search and the namespaces) on Special:Search (maybe the button opens a mini-window). I think that the presults should be as follow:
 * Featured article with 1 article
 * The most popular articles yesterday with 3 articles (in the right upper corner a button that links to https://pageviews.wmcloud.org/topviews/?project=en.wikipedia.org&platform=all-access&date=yesterday&excludes=)
 * Similar/Related pages/articles with 1–3 articles
 * Random article with 1 random article (in the right upper corner a button that replace the shown article)
 * Explore other projects should have buttons that send you to another 4 projects and so on (there are 12 wikis at https://www.wikipedia.org/, so 3 slides with 4 wiki each should be enough) -- NGC 54  ( talk |  contribs ) 11:58, 10 August 2022 (UTC)


 * Just commenting to say I think it's so great you found the "presults" tasks, and I am happy that you think it's a good idea. Can you add your thoughts to the task to make sure they don't get lost? AHollender (WMF) (talk) 19:07, 30 August 2022 (UTC)
 * Added. -- NGC 54  ( talk |  contribs ) 23:14, 21 September 2022 (UTC)

Borders and backgrounds
When does Borders and backgrounds will be deployed on the first wikis? -- NGC 54  ( talk |  contribs ) 16:46, 10 August 2022 (UTC)


 * Hi @NGC 54 - thanks for your question! We are currently working through our visual refinements and are making individual ones available over the course of thee month of August and early September. However, we will be continuing with the minimalist layout for borders and backgrounds, so not too much change is expected there.   OVasileva (WMF) (talk) 11:53, 22 August 2022 (UTC)
 * After some time using it you get used to the new design, but there's something missing, and I think that is related to borders and backgrounds. With the minimalist look, the TOC is not prominent enought, and it is difficult to even understand what it is. As a proposal, have you thought on making two small improvements?
 * The top (Contents) could be bold, so we can see that it is a menu header. This would make the reading easier, I think.
 * The first entry, is to say "(Top)" could be easier to use if it has an arrow pointing to the top. It may be a little icon, and actually it may even be redundant if you add the little icon to the "Contents" title, instead of creating a new one.
 * What do you think? Theklan (talk) 12:10, 25 August 2022 (UTC)
 * @Theklan I've mocked up the two suggestions you've made (to the best of my understanding). Here are my thoughts currently:
 * "Contents" being bold does help the TOC stand out more, however it also conflicts a bit visually with the active section, which is also styled in bold.
 * Adding an arrow to the "Top" link within the TOC adds some clarity, but also conflicts a bit with the other arrows already in the TOC for expanding/collapsing sections.
 * Using the "Contents" heading (with an arrow) as the "back to top" link simplifies the TOC, because there is one less link. However I think it makes the "back to top" functionality less discoverable, and comes with the possible issue of the conflicting arrows mentioned above. This however would be quite easy to test, and I know is a topic of discussion over on the Village Pump.
 * Vector_2022,_TOC_"Contents"_heading_with_arrow.png
 * Vector_2022,_TOC_"Top"_section_link_with_arrow.png
 * What do you think? AHollender (WMF) (talk) 19:06, 30 August 2022 (UTC)
 * Both looks good. I think that the "Top" is better, because is bold and actually is different from having a section. Let me explain this: one thing I have learnt by being with more than 5.000 students in our Education Program is that they like to start the articles with a " == Start == " section. We always explain them that the articles start directly, without a title for the Lead section. Adding something that seems a section called "Top" (I don't know why is called Start in Basque Wikipedia) could cause more confusion, making them believe that they actually have to create a section called "Top". That's why making it a little bit different would be better in terms of understanding what is happening.
 * You also said that the "current section" is styled in Bold, but is not: the weight doesn't change, only the color. It would be interesting to have the current section bold, by the way.
 * Thanks for the designs! -Theklan (talk) 21:07, 30 August 2022 (UTC)
 * Just one quick clarification: the active section link in the TOC will soon be styled in bold. See: https://phabricator.wikimedia.org/T314670. Already live on the beta cluster, e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Water. I will think a bit more about your other points and reply soon. Thanks @Theklan. AHollender (WMF) (talk) 22:08, 30 August 2022 (UTC)
 * That's better. And you have a point, if two are bold, then it could be more difficult to understand why. I still think that "⇈ To top" could be more graphic and easier to discover. (Honestly, I have been a couple of months scrolling up without noticing that I could go up, because the Basque tag is "Introduction" and not "Top"). Theklan (talk) 07:29, 31 August 2022 (UTC)
 * Ok, I am planning to reply to the larger conversation about this on the English Village Pump (link) and will include the "⇈ To top" mockup.
 * Regarding "Introduction" vs. "(Top)" on Basque Wikipedia — you are able to change this on your own, by changing the translation string. I think that happens on translatewiki.net, though I can't seem to find the string (link). I can see, by adding  to the end of the URL, that the name of the string is , in case that is helpful. AHollender (WMF) (talk) 18:55, 2 September 2022 (UTC)
 * @Theklan, @Jdlrobson showed me, you can edit the string here: https://eu.wikipedia.org/wiki/MediaWiki:Vector-toc-beginning AHollender (WMF) (talk) 19:13, 3 September 2022 (UTC)
 * Thanks, I changed it at Translatewiki, but I don't know why this wasn't reflected. Theklan (talk) 08:22, 4 September 2022 (UTC)
 * Ok, looks like it's working now : ) On https://eu.wikipedia.org/wiki/Juan_Sebastian_Elkano I see  AHollender (WMF) (talk) 15:55, 6 September 2022 (UTC)
 * @Theklan one thought/suggestion: since you've added an arrow ↑ I'm not sure you also need the parenthesis. I think the arrow is sufficient to distinguish the top item, Gora, from the other table of contents items, and that it looks quite nice with the parenthesis removed. Of course this is up to you and your community. AHollender (WMF) (talk) 13:59, 14 September 2022 (UTC)
 * I think you are right. I wish there was a bolder arrow. Theklan (talk) 14:41, 14 September 2022 (UTC)

Support for Different Chinese Writing System
I saw the language switcher list "Chinese" only. However in Chinese Wikipedia, there are 6 different modes to trans characters and regional words automatically. Hope the new skin won't broke the transforming system, or maybe making all Chinese writing system (zh-cn, zh-tw, zh-hk, zh-sg...etc.) in the list will be better. --Reke (talk) 09:02, 13 August 2022 (UTC)


 * @Reke The chinese wikipedia has a separate variants menu which switches between different transliterations of Chinese. That functionality is completely standalone. —Th e DJ (Not WMF) (talk • contribs) 14:32, 22 August 2022 (UTC)

Object placing is suddenly out of whack as of today
This is the best skin so far but today the placing of objects started being glitched. There are huge blank gaps in between the top of the page and the article and the icons on the top are out of place. When you scroll down the sidebar goes directly over the text on the actual page. I'd post screenshots but I can't Carolina Heart (talk) 23:30, 18 August 2022 (UTC)


 * Hi @Carolina Heart - thank you for your report! We were having some issues last week with bugs and regressions. Are you still seeing these issues and if so, could you tell us which browser and wiki you are seeing them on?  OVasileva (WMF) (talk) 11:46, 22 August 2022 (UTC)

XTools statistics no longer visible
XTools statistics which are usully just below the article title are no longer visible. Since yesterday. Krayon95 (talk) 06:20, 19 August 2022 (UTC)


 * Thanks for the report @Krayon95! Could you give some details so that we can reproduce. Which wiki are you testing on and which browser? Xtools statistics are still showing for me on English Wikipedia in Chrome.   OVasileva (WMF) (talk) 11:45, 22 August 2022 (UTC)
 * This was covered here - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?&oldid=1106002109#Is_there_an_update_to_Vector-2022_today/yesterday?
 * Apparently this was related to a change in discussion tools. Jdlrobson (talk) 20:22, 22 August 2022 (UTC)
 * @OVasileva (WMF) @Jdlrobson. Its happeneing again since yesterday. Last time, XTools was working in classic vector skin. This time, its not visible in any of the skins. Thank you. Krayon95 (talk) 10:54, 9 September 2022 (UTC)
 * Which version of XTools code are you referring to? Jdlrobson (talk) 16:37, 9 September 2022 (UTC)
 * Sorry for replying late. I meant XTools Statistics which no longer appear. But I noticed something strange: XTools Statistics appear when I am using a vpn/proxy ( brave browser extension) but not when VPN's off.
 * The problem is not with my IP as I can make edits as usual on wikipedia. Morever, there's another older issue with wikimedia commons where the whole site is unavailable for me unless when using VPN. I am not sure how its connected. Krayon95 (talk) 21:03, 13 September 2022 (UTC)

The "new" version of the Vector skin, or at least a very good lookalike of it, has actually been in use for a few years on certain wikis so...
Please consider changing the name of the skin to either "New Vector" or simply "Vector II/2". It is COMPLETELY MISLEADING to label it as a version from this year when in fact it has been used on certain other wikis, such as French WP, since at least 2019. 46.208.36.113 01:48, 24 August 2022 (UTC)


 * Hello! You are right, the context of this version being in use since 2020 (summer 2020) may be lost. Strictly speaking, it's now called Vector (2022), and the old version is Vector legacy (2010). At some point, we may drop the dates, thus naming these: Vector and Vector legacy. The ex-default may become the past, and the ex-new may become the default. What do you think? SGrabarczuk (WMF) (talk) 15:56, 28 August 2022 (UTC)
 * FWIW the name is purely a technical artifact which marks when the new Vector was available to 3rd parties who install MediaWiki. Despite being on French since 2020, it's not been supported for 3rd parties until 2022.
 * Any wiki can name this to something the prefer by changing MediaWiki:Skinname-vector-2022. Jdlrobson (talk) 22:02, 1 September 2022 (UTC)

Link color change?
Was there a recent change to the link text colors in the new skin? I don't think previously I was seeing visited links turn purple, and now I do, in addition to the base link blue being lighter. Purple visited links might be recommended for readers, but it's pretty annoying for editors because when we look at a watchlist or our own contributions page... the majority of the list will be purple and the distinction isn't super meaningful. I can alter this in my personal CSS of course, but I thought I'd ask because it seemed new. Steven Walling (talk) 17:41, 26 August 2022 (UTC)


 * Yes, both clicked and non-clicked links were changed to increase the contrast with the black text to comply with accessibility standards (Reading/Web/Desktop Improvements/Features/Visual Refinements): the contrast between normal text and links was too small. With links forming such a large fraction of the text on Wikipedia, I think the contrast with the white background is more important. A very small percentage of links is visited / used as a link. The purple in particular fails the WCAG AAA contrast test: https://webaim.org/resources/contrastchecker/?fcolor=795CB2&bcolor=FFFFFF. As an editor with large parts of my text being visited links, this is a blocking change. I cannot read my watchlist like this, and struggle in other link-heavy pages. Femke (talk) 18:47, 26 August 2022 (UTC)
 * @Femke I definitely hear your frustration. And I appreciate you helping answer @Steven Walling's questions. As it seems you know it was a difficult challenge to find colors dark enough to sufficiently contrast with white, but light enough to sufficiently contrast with black. We ended up choosing a purple that is AAA against black links, but only AA against white backgrounds. I think we should continue to test and monitor this situation. I agree with you that the purple feels a bit light. Do you have any suggestions for a better purple to use? AHollender (WMF) (talk) 18:47, 30 August 2022 (UTC)
 * According to https://webaim.org/blog/wcag-2-0-and-link-colors/, there seems to be only one option for both the blue and the purple that meets the WGAG AAA contrast requirement (#3344dd, and #804180). Up till now, only the purple has caused me accessibility issues, with my long COVID brain not coping. This purple colour also easily meets the WCAG AA requirements for use on light grey text (infoboxes / quote boxes / current version of tool menu / reply preview and a lot of behind the scenes places). If you only want to meet the WCAG AA requirement for white/light grey backgrounds (other backgrounds are somewhat common too), there is of course more wiggle room. I don't have the energy to figure out how CSS works to test if this is pleasing to the eyes. Femke (talk) 17:26, 31 August 2022 (UTC)
 * Thanks for finding those colors. I like them. My color explorations were more limited because I assumed  was a given, so didn't explore combinations that involved changing that. @Volker E. (WMF) could you comment on our choice to use  ? AHollender (WMF) (talk) 18:46, 2 September 2022 (UTC)
 * @AHollender (WMF): I've done a more thorough job of evaluating colours with respect to the two accessibility criteria in the phab ticket. I was wrong that both accessibility criteria can be met (I used the wrong black). The purple can be made ever so slightly darker while still meeting the link contrast criterion. Better is likely to compromise on the two criteria, and almost meet both. Femke (talk) 08:27, 6 September 2022 (UTC)
 * Links are often placed on non-white backgrounds, for instance infoboxes. In that case the contrast is 2.04:1, and fails even the WCAG AA standard: https://webaim.org/resources/contrastchecker/?fcolor=B7AAD5&bcolor=F8F9FA Barely meets the WCAG AA criterion: result . This change seems to be replacing a small accessibility issue (not able to distinguish links) with a larger (not able to properly read text). Femke (talk) 19:41, 28 August 2022 (UTC)
 * @Steven Walling thanks for adding your feedback here. It's nice to hear that the visited link distinction is more noticeable to you now, that was part of the intention of the change. However I'm sorry to hear that the visited links on your Watchlist are annoying you. Do you think it would be better if links on the Watchlist page never showed visited styling? Are there some situations in which it's helpful to know that a link on your Watchlist has been visited? AHollender (WMF) (talk) 18:39, 30 August 2022 (UTC)
 * Yes, I actually edited my Vector 2022 personal CSS to completely hide the visited links color, since it's easier to just do that globally. Watchlists in particular already have seen/unseen filters which serve a similar purpose, and on my Contributions page... by definition you will have visited a page you have edited so the color distinction is useless. On the other hand, it's inconsistent and therefore maybe confusing to people to have visited link color differences on content pages but not in Special pages? Personally I think it's only useful in articles but I could be wrong there. Steven Walling (talk) 03:00, 31 August 2022 (UTC)
 * How would you feel about starting a thread on the English Wikipedia Village Pump to ask about this? I see the value in removing the visited styling from Watchlist and Contributions (and potentially other places, like the User menu and Main menu), and agree with you about the tradeoff — the inconsistency might be confusing to people and cause other problems. AHollender (WMF) (talk) 18:28, 2 September 2022 (UTC)
 * How would you feel about starting a thread on the English Wikipedia Village Pump to ask about this? I see the value in removing the visited styling from Watchlist and Contributions (and potentially other places, like the User menu and Main menu), and agree with you about the tradeoff — the inconsistency might be confusing to people and cause other problems. AHollender (WMF) (talk) 18:28, 2 September 2022 (UTC)

Too minimalist user menu
Hey. I like / got used to most of the changes, but I really don't like the user menu. It is too minimalist and inconvenient. With this skin I'm forced to make additional mouse movements and additionally click to enter the sandbox or other stuff. It's page states its for "increased clarity" and "decreased visual clutter" but I don't see how more icons are cluttery here. It looks good on my test preview. Can we change it, or atleast give option to change that? Sławobóg (talk) 17:59, 26 August 2022 (UTC)


 * @Sławobóg thanks so much for your thoughts, and this awesome screenshot. Is that something you did with custom CSS, or is that a mockup of what you would like to see? We have discussed making the user menu configurable so that people can decide which items to pull out of the menu into the site header. One thing to keep in mind is that there are many features we plan to develop in the future (for example "Dark mode"). Part of why we are trying to be minimalist because we know there are other things coming, and we want to leave space for them. AHollender (WMF) (talk) 18:32, 30 August 2022 (UTC)
 * @AHollender (WMF) Hey, I made it up in GIMP. A customizable menu would probably be the best thing, everyone would be happy about that. I understand you might want to add more stuff there (few more icons would still fit) however, it should be remembered that it is more important for editors to have easy and quick access to editing tools. Wikipedia is an encyclopedia, not a blog, and making the editors' job more difficult by removing everything unnecessary for the casual reader is a mistake in my opinion, yet someone who is not logged in will not have most of these buttons. Sławobóg (talk) 20:25, 31 August 2022 (UTC)

Option to fully expand ToC / have it expanded by default
Often when deciding whether to read an article, or what portions of it, I skim the whole table of contents, and it's frequently the first thing I do when opening an article (after skimming the introduction). Please,

0. let me see the ToC on the top of the page

1. either make it expanded by defaut, as it was in the old design, or at least give me as a user the option to have it expanded by default Susy 11 (talk) 19:52, 27 August 2022 (UTC)


 * @Susy 11 thanks for taking the time to add your thoughts here. We experimented with an "expand all sub-sections" button: https://di-toc-expand-collapse-all.web.app/Mount_Fuji — is that what you're describing? AHollender (WMF) (talk) 18:29, 30 August 2022 (UTC)
 * Yes, and/but mainly the option to have it on by default. Also, I just noticed the new ToC makes it harder to distinguish different levels (sections, subsections, etc). Indents would be nice as well (or something) Susy 11 (talk) 20:06, 30 August 2022 (UTC)
 * Do you mean have all of the sub-sections expanded by default? If so, could you please see my comment here where I've addressed this topic: https://phabricator.wikimedia.org/T310893#8199755. Let me know what you think.
 * Regarding increasing the indentations, it is possible but would also mean that long section title links in the TOC would wrap more. We are trying to find a balance there. AHollender (WMF) (talk) 22:14, 30 August 2022 (UTC)
 * @AHollender (WMF): I have had the same impression as Susy 11 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:23, 6 September 2022 (UTC)
 * This is a really cool solution the IP shows here! This needs more attention, so I paste that link to the Mediawiki-Mockup here once again: https://di-toc-supplementary.web.app/Sushi
 * I totally second that idea as a compromise! Ping @AHollender (WMF), @SGrabarczuk (WMF) HirnSpuk (talk) 07:42, 22 September 2022 (UTC)
 * @HirnSpuk to clarify, the prototype linked is one we created and tested with readers in three different countries. The feedback was quite clear: people prefer to have the table of contents directly at the top of the page (not after the lead paragraph, which can sometimes be quite long), and they prefer to have the table of contents remain in the same location always (not switching from inline, to a floating element). There is a bunch of additional information in this thread: Talk:Reading/Web/Desktop Improvements. Cheers, AHollender (WMF) (talk) 13:31, 22 September 2022 (UTC)
 * @AHollender (WMF), Thanks for the clarification! I wasn't aware of that. To clarify myself: it's not important for me, if the toc is after the lead paragraph or before. I would like to have it "within" the content and not beside it (you argued that yourself regarding information hierarchy there Special:Diff/5422314/5422316: "A secondary concern [...] is that the hierarchy of information makes less sense...") and printable if wanted. Keeping it available while scrolling is totally fine, the precise location is probably something of personal taste. HirnSpuk (talk) 15:32, 22 September 2022 (UTC)

Increase default size of root element
By "default size of root element" I mean the equivalent of browser zoom-in. I suggest using the equivalent of 120% zoom.

On one hand, this would align more closely with the standard recommendation to use a ~16px font size.

On the other hand, it would improve the layout on bigger screens in reducing dead space. Orpheus Lummis (talk) 12:53, 28 August 2022 (UTC)

Right side has way too much space
Why is there space on the right side of the screen? The screen is way too compact. Otherwise, it's not bad, just not really my taste. I kind of personally like the screen as how it is, but do wish that there was a dark mode. PoliticallyPassionateGamer (talk) 16:12, 28 August 2022 (UTC)

Infuriatingly narrow
I can not put into words how infuriatingly narrow this new design is. That is a terrible design decision. Looks great otherwise. Mogery (talk) 17:20, 28 August 2022 (UTC)


 * @Mogery I am sorry to hear about your frustration. Also glad to hear that you like other aspects of Vector 2022. Have you checked out any of the gadgets and user scripts here: Reading/Web/Desktop Improvements/Repository? There are several that make Vector 2022 full-width. AHollender (WMF) (talk) 18:28, 30 August 2022 (UTC)

Not good for me...
Pushed the left side items down Volten001 (talk) 20:58, 28 August 2022 (UTC)


 * @Volten001 thanks for taking some time to visit our talk page and add your thoughts. Can you expand upon your comment? Do you mean that the table of contents is pushed down by the main menu? If so, have you tried collapsing the main menu? Also, we will soon be moving "Article tools" and "In other projects" to the article toolbar (with the option to be pinned open on the right-hand side, as you mentioned), making it less necessary for people to keep the main menu pinned open. You can see that in a prototype here: https://vector-2022.web.app/Moss. At that point we think most people will be satisfied with having the main menu collapsed (and therefore the TOC not pushed down). AHollender (WMF) (talk) 18:26, 30 August 2022 (UTC)

Too narrow and unneeded
I would argue that the new design is not needed. What are you trying to achieve?

When the new design is activated, I'm getting moderate space added to the left, moderate space added on top, big spaces on the right.

This reduces the amount of information, and gives an unsatisfying feeling pushing the user to resize the page. Or just leave the website.

If you're trying to make a design for mobiles, this is called a "responsive" design and it shall be completely different from a desktop design. The responsive design shall be handled differently.

The current desktop design is fine going forward.

If you want to provide an extra feature, for a reason unkown, add it as an option for those who want it, since it clearly isn't something the general user needs.

I think that the design is something especially sensitive for users. When something is released, it's pretty much set in stone forever. If you change it, it stops being what the user remembers.

Regards GeorgesDupond (talk) 23:16, 28 August 2022 (UTC)


 * @GeorgesDupond thanks for adding your thoughts. The reduced width of the content is based on readability research which shows people prefer reading text with shorter line lengths. It is more comfortable for their eyes, and leads to better understanding and retention of the information. We've done a writeup on this topic here: Reading/Web/Desktop Improvements/Features/Limiting content width.
 * Many people have responding saying: if people want the width of the content to be more narrow they can adjust the size of their screen. While this is possible, the research shows that many people don't think to do this. Instead they struggle to read text that is not properly optimized for reading comfort. Our goal is to have the best possible reading & learning experience possible, and we don't want people to have to make any adjustments when they land on the page.
 * However, for people like yourself who prefer more density and longer line-lengths, there is thankfully some great CSS that has been written by @Quiddity (WMF) to address these preferences: User:Quiddity/Vector-2022-condensed.css. I think you may like these modifications, and would be curious to hear about your experience.
 * Thanks AHollender (WMF) (talk) 18:24, 30 August 2022 (UTC)
 * I see, thank you for your explanation. I understand. If the comfort is worth the change then I think the current space size is a decent compromise.
 * Regarding the css, if it requires to add an extension or isn't added as an option in the wiki then I think people will not bother I'm afraid.
 * I don't see much more to say about the new design.
 * Maybe the contents menu added in the left panel can be confusing. After so long using the wiki, I associate the left panel as some meta links related to the wiki as a whole, not something related to the article.
 * I understand that it allows to jump to other sections but I feel there's something currently off. The contents of the article aren't noticeable enough in my view. Maybe it's just a matter of color. Or maybe it comes from the fact that the design of the frame is different (it might miss the numbers in front of each sections, or a more similar design).
 * Regards GeorgesDupond (talk) 19:29, 30 August 2022 (UTC)

TOC useability
before nitpicking: I like where you're going with this, i think it's largely working.

I do see a usability problem with the TOC: when you click on the "hide" link, the TOC just disappears. You have to struggle for a moment to figure out how to make it reappear. I've seen the solution in the newer prototype, but it feels like a dirty hack: it's unintuitive. there should be a "show" link right where you clicked "hide".

Also, it's not nice to have to search for the hidden table of contents down there beyond the cluttered main menu. It seems like an obvious candidate for that empty space on the right...

While I like the general direction, i'm also looking forward to a solution to that waste of screen space, especially the huge white hole on the right. I'd like a simple one-click solution to basically fill my whole screen with the actual content...

(And - when will this cluttered main menu finally be cleaned out?.. E.g., who has an actual practical everyday use for the "random article" link to justify its presence in that prominent position? :-O) Reseletti (talk) 09:05, 29 August 2022 (UTC)


 * @Reseletti thank you for taking the time to share your thoughts with us, and thank you for the general encouragement.
 * Regarding: "there should be a "show" link right where you clicked "hide"." — if we collapsed the TOC in place, with a label of "Contents [show]" it would take up space in the sidebar (~110px on English Wikipedia...more/less on other Wikipedias, depending on the length of those words). For people on screens less than ~1300px wide, this makes collapsing the TOC much less useful than it would be if we re-captured that space; because they collapse the TOC but get no horizontal space back. We then explored collapsing the TOC in-place, but using an icon instead of a label, which you can see here (the prototype doesn't have much functionality beyond collapsing the TOC into an icon): https://di-toc-collapse-in-place.web.app/Moss. It helps with the discoverability of the collapsed TOC, but at the expense of the general visual balance of the page. Therefore we think collapsing the TOC into an icon next to the article title is our best option.
 * Regarding: "Also, it's not nice to have to search for the hidden table of contents down there beyond the cluttered main menu. It seems like an obvious candidate for that empty space on the right" — we will soon be moving "Article tools" and "In other projects" to the article toolbar (with the option to be pinned open on the right-hand side, as you mentioned), making it less necessary for people to keep the main menu pinned open. You can see that in a prototype here: https://vector-2022.web.app/Moss. At that point we think most people will be satisfied with having the main menu collapsed. The reason why we don't want to put the entire main menu over on the right side is that it would break the information hierarchy of the site. The main menu contains global navigation, therefore we want it to remain associated with the site header which also contains global navigation. The article area contains navigation specific to the article. Placing the main menu within the article toolbar breaks this organization.
 * Regarding "a solution to that waste of screen space", I recommend taking a look at some of the CSS that @Quiddity (WMF) has written, which results in a much more dense version of Vector 2022. You may find some bits and pieces within it that you like. User:Quiddity/Vector-2022-condensed.css.
 * Please let me know if the above makes sense to you, and thanks again for your involvement. AHollender (WMF) (talk) 18:18, 30 August 2022 (UTC)

Language links on wikidata still not solved
Please see the discussion in Archive 4 section: "Language links on Wikidata are right at the bottom of the page".

There still have not been any comments on this issue, and it is something that bothers me everyday when using wikidata. - Rooiratel (talk) 10:19, 30 August 2022 (UTC)


 * Hi @Rooiratel, could you send a screenshot? Let's try to capture very precisely, step by step, what you experience. Based on that, I'd like to report a bug, so I need answers to these predefined questions. SGrabarczuk (WMF) (talk) 11:50, 31 August 2022 (UTC)
 * Sure here is a screenshot with the Vector2010 skin. You can see the language links on the right. And here is the screenshot with the Vector2022 skin. You can see the language links are at the bottom of the screen. (Pls note I made an error with the second file name and requested it be renamed to "Wikidata lang issue Vector2022.png") - Rooiratel (talk) 14:52, 31 August 2022 (UTC)
 * it looks like this was solved but regressed again. :(
 * Unfortunately the team building desktop improvements doesn't have much to do with Wikidata (it's not one of the wikis we are focusing on right now) but I've let them know of the issue and hopefully they'll fix it.
 * Jdlrobson (talk) 17:49, 31 August 2022 (UTC)
 * Thanks @Jdlrobson. Much appreciated. Is there a bug or something that I can track to follow progress/check the status of this issue? - Rooiratel (talk) 09:38, 1 September 2022 (UTC)
 * Lol never mind, I just noticed the Phabricator link now. Thanks again. - Rooiratel (talk) 10:07, 1 September 2022 (UTC)

Too much scrolling down required
I really dislike having to scroll down just to see the main content on each page. I don't see why the menu on the left side has to take up all the space at the top of the screen, without the main content being displayed beside it. — Cheers, SMUconlaw 13:27, 31 August 2022 (UTC)


 * Hello @Sgconlaw. Thank you for writing here. We understand that this is uncomfortable. We're working on a change that hopefully, will make things more user-friendly - one possible option here is to disable sidebar persistent at low resolutions (opening or closing the menu won't set a preference for the next page view). Source. How do you feel about this solution? SGrabarczuk (WMF) (talk) 19:20, 1 September 2022 (UTC)

Thank you for fixing the narrow window layout
Re : I just tried Vector-2022 again (en wikipedia), and you fixed it (sorry, I haven't been checking frequently so missed the update). Thank you! DavidBrooks (talk) 15:51, 4 September 2022 (UTC)


 * Oh, I spoke too soon. I was testing on a slightly different resolution screen from my original repro. Still waiting for a fix! DavidBrooks (talk) 18:44, 6 September 2022 (UTC)
 * Hey @DavidBrooks, the fix is almost ready. If you would like to track it you can do so here: https://phabricator.wikimedia.org/T316191. We will then be following up with a more elegant solution, which you can preview here: https://vector-2022.web.app/Flamingo. AHollender (WMF) (talk) 22:49, 7 September 2022 (UTC)

wikEd
Hi, I can't get wikED to load using vector (2022). Am I doing something wrong? Graham Beards (talk) 10:44, 6 September 2022 (UTC)


 * I'm not too familiar with this gadget. Have you reached out on the gadget talk page? Hopefully it's a straightforward fix! Jdlrobson (talk) 16:08, 7 September 2022 (UTC)

Add language links without jumping to Wikidata
Hey, I love the new design, thanks for your work! The only reason why I regularly have to switch back to the old design is when I want to add language links after I created a new article. In the old design, there is a small tool to add the page to Wikidata inside of Wikipedia. In vector 2022 there is an "add languages" link as well, but it does nothing when I click on it. In some language versions of Wikipedia (for example in french) it opens a dialogue with the language preferences, which is not what I expected there. Is this a bug, or am I doing something wrong? Stefangrotz (talk) 20:18, 7 September 2022 (UTC)


 * Hey @Stefangrotz, thanks for your kind words. I believe the tool you are looking for is in the main menu (i.e. left sidebar menu) which can be accessed by clicking the hamburger icon in the top left. Within the section called "Tools", the last item should be . Do you see it? AHollender (WMF) (talk) 22:48, 7 September 2022 (UTC)
 * I found it, thanks, that'l work for me. Is there any chance that this link will also appear in the language menu some day? Stefangrotz (talk) 19:16, 8 September 2022 (UTC)
 * @Pginer-WMF are there any plans to incorporate the  button into the language menu? AHollender (WMF) (talk) 03:08, 9 September 2022 (UTC)
 * @AHollender (WMF) I came to ask the same. I also expected to find that link in the language menu, that's the intuitive place for it. Keep it where it is if you want but clone it there as well, please. 114.203.14.24 05:03, 12 September 2022 (UTC)

Remove single tab on Special pages?
Hey, a few months ago we moved the article toolbar below the article titlebar. One of the results of this change is that it's now more noticeable, and arguably more awkward, that many/most Special pages have a nearly empty toolbar, with just a single tab that says "Special page". In the spirit of minimalism/simplicity, and removing unnecessary elements from our interface, we think it would make sense to hide the toolbar on Special pages (see mockup below). We would make an exception in cases where people have a gadget enabled (such as Twinkle) that appears in that toolbar on certain special pages (such as Recent changes), and the toolbar would be shown in those cases.

What do people think about this proposed change? In the phabricator task (link) we've heard from @Quiddity (WMF), @Jonesey95, and @Xover that they use the "Special page" tab as a way to reset any filters they may have added to the given Special page they are on (e.g. Recent changes, User contributions, etc.). A potential workaround/solution there would be to make the page title itself a sort of hidden link, that leads back to the "base" version of the page.

@Jdlrobson will be following up with details regarding patches in progress, as well as a window of time where you can try out the proposed change to Special pages with a hidden toolbar.



AHollender (WMF) (talk) 22:42, 7 September 2022 (UTC)


 * Firstly note that the tab is only being removed on special pages. One of the motivations for this change is to make more meaningful use of this space. See T315553, T286466 and T316818 for possible usages inside the Watchlist, Contributions, and AbuseFilter special pages.
 * If the only problem with this removal, is the lack of a link back to the reset version of the form, I think there are 2 viable solutions here:
 * We restore a more meaningful tab in pages like RecentChanges that need it which says "reset".
 * We add "reset" to the form itself
 * As a temporary measure, if we need more time to think about this, we can restore the tab to all special pages while we think this through. I'm not sure if RecentChanges is the only page that suffers from this issue.
 * Very interested to hear in other use cases that are broken by the removal of this tab so we can address them. Jdlrobson (talk) 22:58, 7 September 2022 (UTC)
 * Re "make more meaningful use of this space": When I compare my Watchlist in legacy Vector and Vector 2022, the actual content of the Watchlist (the first entry showing page diffs) is lower on the screen in all cases in Vector 2022. In other words, less of the useful content of the page is being shown to me, the active editor. In legacy Vector, the helpful "Special" tab that refreshes the page doesn't take up any extra space, because it is integrated into the design of a row that is already being used by useful UI elements. If making better use of the space in the browser window is the goal, the overall design of the page needs some rethinking, rather than removing a useful UI element. Why is it that in all cases, the content that I, the reader or editor, have come to see requires my eye (and my scroll bar) to travel farther down the screen in this new skin? I think this may be related to the objection that some editors have about the excessive whitespace in Vector 2022. Jonesey95 (talk) 01:38, 8 September 2022 (UTC)
 * Hey @Jonesey95, can you help me better understand your comment? As far as I can tell the Watchlist in Legacy Vector begins at the same point on the screen as the one in Vector 2022. I think I'm missing something here?
 * Comparison_of_Watchlist_between_Legacy_Vector_and_Vector_2022.jpg
 * AHollender (WMF) (talk) 14:57, 8 September 2022 (UTC)
 * Here's what I see:
 * Screenshot watchlist Jonesey95 2022-09-08.jpg
 * At a glance, it appears that there is excessive white space above the large "Watchlist" header in Vector 2022, the sidebar and padding eat valuable horizontal space needed by page content (making some things wrap that don't wrap in legacy Vector), and it does not make sense to me that the "Special" tab header (along with Talk and the other headers that assist with page navigation) resides below the contents of the tab that it contains. Someone more skilled in UI comparisons and modern UI testing could probably give you a better explanation; I'm just a person who has been using the web daily for 28 years. Jonesey95 (talk) 15:53, 8 September 2022 (UTC)
 * Thanks so much for the screenshots. As far as I can tell in your screenshots the Watchlist on Vector 2022 starts about 28 pixels lower than in Legacy Vector. The toolbar we are discussing removing is about 30 pixels tall, so with that removed (which is what is shown in my screenshot above) it will be equal. So I think we're all set in that department.
 * Regarding placing the toolbar below the titlebar, this is a change we asked the community about during our fourth prototype testing (link to questions & prototype, link to responses). We had 33 community members saying they prefer the toolbar below the titlebar, and 5 community members saying they did not, which seemed like a clear enough preference to us. Also, from a logical standpoint, if someone is on the article about Water, we think it makes sense for the information architecture of the page to say Water first, then say Article, Talk, History, etc., because from the perspective of someone using the page those are effectively sub-pages of this overall topic: Water. We understand that from a technical perspective it might be different, and we are okay with that.
 * Thanks again for your input here. AHollender (WMF) (talk) 16:15, 8 September 2022 (UTC)

Conflict with references responsive and box objects on the right
Greetings, this is not only a problem with the new vector skin, but it could be solved with it: When in a Wiki article, the references are tagged with to expand/collapse the sidebar, the   will move left and right. It can be reproduced on pages such as MediaWiki.
 * My previous opinion was written here, harsh but still applicable. No research result will support an inharmonious layout. Many changes in Vector 2022 are good, but there's still a long way before it can replace the old Vector. --Lt2818 (talk) 03:26, 24 September 2022 (UTC)

Opt-out for kkwiki
We need more time to duscuss this major change. Because this skin more confusing, many user links hiden, this is more unconfortabe for newcomers. And most imfortant thing is in the rigth side big space not used. Why? All space used effectively and economically. Arystanbek (talk) 08:45, 22 September 2022 (UTC)

Don't make it default on the Setswana Wikipedia
I seriously don't like this new vector it is not new user friendly the old one (the current one on the Setswana Wikipedia) is much better than this one we need more time for Setswana Wikipedia, thank you.Rebel Agent (talk) 13:10, 22 September 2022 (UTC)

The community
Revision activities of this page reach the peak of a normal distribution. The last 3 week are in TOP4 of maximal count of revisions.

Graph of the count of revisions for the weeks from 2022-04-25 (because) to 2022-09-18 in year 2022:

Wrong realise

 * User page Special:Contributions:
 * To change the page sections on:
 * Title: "User contributions for XY".
 * The line with the new tools.
 * The user contributes.
 * Now, the page have the two H1 titles.
 * Current solution: It does not look the most elegant on a monitor with a width of 1024 and less.

--Dušan Kreheľ (talk) 13:11, 22 September 2022 (UTC) Dušan Kreheľ (talk) 13:11, 22 September 2022 (UTC)

Compromise proposal for ToC and Rollout
We got the message in de.wikibooks, that the Skin will be default in the next two weeks. I'm curious if and how the community will react. If I understand correctly there is the option of opting-out? I did not get any response from the community at the moment, but if I do and the community doesn't like the new skin as a default, would we as a community be allowed to opt-out?

As I already argued for, I do see some Problems. My main concern is the ToC.


 * 1) It is mentioned there Special:Diff/5333819/5333835, that there will be work after going live, that is quite significant: The move of tools in location. I think this is a major change (which would probably solve some problems with the TOC) and will need work by the communities (updating a significant number of help- and community-pages).
 * 2) FORCETOC (and floating) doesn't work anymore, and wikibooks loose the ability to specify the location of a ToC to be printed out and this is not even possible anymore (or did I miss anything?).

So I would like to kindly propose two things:
 * 1) stretch the schedule until major changes are done. I expect a move of the tools to be significant, if it happens while the skin is the live-default.
 * 2) What about using FORCETOC to explicitly switch back to the old behaviour? So the "new" behaviour will be default, but the old behaviour is kept functional for pages where it's needed. The new ToC might even stay where it is, if it's technically possible.

Best regards HirnSpuk (talk) 15:59, 22 September 2022 (UTC)

The stiky header is appearing again, after I deactivated it via CSS
Please don't force me to see this. I don't want this thing. Bageense (talk) 18:56, 22 September 2022 (UTC)


 * Hi @Bageense. I'm sorry, I think this must have been not intentional. Is the solution advised here not working for you now? SGrabarczuk (WMF) (talk) 02:05, 24 September 2022 (UTC)
 * Yes, that's what kept the sticky header from appearing. Of course, you made it appear again unintentionally. I hope this gets fixed. Maybe the readers won't mind the header, but as an experienced editor, it's pointless and a bit disruptive. Bageense (talk) 03:22, 24 September 2022 (UTC)

Navajo wrong
Vector 2022 ignores common.css and sets articles' titles to Linux Libertine font, which does not work for Navajo and displays it wrong (ą, ą́, ę́, į́, ǫ́). This needs to be fixed before the switch. Font must be Noto Serif or Noto sans as specified in common.css. Seb az86556 (talk) 22:00, 22 September 2022 (UTC)

Postponing the change in the Estonian Wikipedia
We would want to postpone the change in the skin. It also seems likely, that we would want some more specific fixes, but as the discussion has only recently started (notice was given to us yesterday) then there haven't been enough participants to make a summary of it. What is clear thou, is that the beginning of October is unrealistic time for the change. Kruusamägi (talk) 15:46, 23 September 2022 (UTC)


 * @Kruusamägi, thanks for writing here. Next week, I'll take part in the conversation on etwiki. Considering the number of valuable points, it seems we'll have a nice discussion! SGrabarczuk (WMF) (talk) 02:03, 24 September 2022 (UTC)

Bottom margin of ToC


Hi Szymon/Olga! I wanted to circle back about one smaller issue, which is the bottom margin of the table of contents. Currently, when you're mid-way down a page, there's a substantial whitespace margin at the bottom (see annotated photo at right), which increases the likelihood of users having to scroll. The much shorter top margin seems like a more reasonable buffer. Would you be able to adjust the design a little so that the bottom margin is the same as the top margin? &#123;{u&#124; Sdkb  }&#125;  talk 01:09, 24 September 2022 (UTC)

Infoboxes, images, or references in the right margin
You write in your update on screen width that Community members have suggested to put infoboxes, images, or references there. As a separate project, we will consider ways of using this space. I wanted to offer some initial comments on these options, all three of which are intriguing.

Infoboxes are an attractive option because they would be potentially useful as a sticky element that persists as you scroll. Moving them to this space would also solve an issue that you introduced by removing the table of contents from the lead section. In most articles in legacy vector, the infobox does not run into the first post-lead section only because of the vertical space of the ToC, but with that gone, it's started doing so, creating a conflict or sandwich with the images often present in that section.

Images are also an attractive option. They're an element that makes the text much narrower than the default wherever they appear, which can cause issues. By moving part of them to the right margin, we could reduce that impact, and also potentially explore eventually making the default size larger to adapt to modern standards. The design of Signpost articles (example) offers a vision of how this could look.

Lastly, references are attractive because they're an element that readers too often ignore, but that they really ought to pay more attention to as part of intelligent media literacy habits (a topic that also relates to my ongoing comments about the GA/FA icons). Moving them from the bottom to the sidebar would give them more emphasis, helping with this. It would also fix the issue we currently have, where the scrollbar gives an inaccurate sense of how far down an article you are because a large portion of it is just the reference section.

Feel free to let me know if you have additional thoughts/questions about any of that! Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 07:25, 24 September 2022 (UTC)


 * I like this idea a lot, but it has to be tested intensively. I don't see much problems with infoboxes, since they have a fixed width. but pictures vary a lot and are often integrated in the article in creative ways. I have seen all sorts of custom HTML combined with pictures. So I would start with only info boxes. Stefangrotz (talk) 09:19, 24 September 2022 (UTC)
 * The infobox is the obvious decision. The image are section-related elements, while the infobox is an article-wide element, so you should be able to acces it anytime. Why would you insert the references there, if the readers do not use them very often? The status quo for references is OK. -- NGC 54  ( talk |  contribs ) 12:12, 25 September 2022 (UTC)

The login button
My device doesn't seem to support the sidebar (if there is one) - which to me I think is a toggle sidebar. If the login button is there, then I won't be able to find the login button, and typing Special:Login every time will get tiring really fast. Could it possibly be moved to the top of the screen? Or at least fix the sidebar to be like the one on the mobile site (for me there is a button and a top bar, but no sidebar). If it doesn't work like that at all, then I got no idea what's going on. L10nM4st3r (talk) 12:23, 24 September 2022 (UTC)

Coordinates and Feature article star on top of the page
I am struggling with the positioning of the coordinates in the upper right corner of the page. I have successfully fixed the star for the Featured Article. Any suggestion to fix this? See sandbox page. Pinky sl (talk) Pinky sl (talk) 09:17, 25 September 2022 (UTC)

Choices in Language Switcher
In February 2020 and May 2021 I commented on the prototypes. Prompted by the RFC, I have been reviewing using fr.wiki. Though I still prefer the way that other languages are presented in Monobook and the earlier Vector, the Language Picker has definitely improved with the Suggested languages. However that leads me to a query concerning inherent decisions which have been made over which languages to privilege: AllyD (talk) 09:38, 25 September 2022 (UTC)
 * If I look at the Nouvelle-Écosse page (and similar for Écosse), the Langues suggérées include English and Scots (I'll leave aside the concerns about the latter) among others.
 * Despite Gàidhlig being one of the languages spoken in the place in question, the gd.wiki link is omitted from the suggested languages, nor does it appear in the sublist of languages spoken in the Americas; one has to scroll down to the 2nd group of European languages to locate a link.


 * Replying to myself... After temporarily switching my en.wiki preferences to the new Vector, I see that the Language Picker presents a full alphabetic list rather than the Suggested and By-Continent Language partitioning that I see when using fr.wiki. What is the intended future direction: the partitioning on which I was raising a concern about privileging, or the raw drop-down list? AllyD (talk) 10:46, 25 September 2022 (UTC)

Postponing the change in Chinese wikis
Vector 2022 should not be further deployed to any Chinese wiki before T306862 gets resolved. —— Eric Liu（Talk） 16:49, 25 September 2022 (UTC)