Talk:Reading/Web/Desktop Improvements/Archive6

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 — Preceding unsigned comment added by 77.148.113.166 (talk • contribs) 19:54, 25 January 2022

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)

This! I do this a lot too. ⚜ Moilleadóir ✍ 06:04, 16 October 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:

After switching to English from French, link to switch back to French is shown next to language menu button

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.

Prototype of pinning the language menu to the sidebar (click to view GIF)

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:

Language toolbar in Vector 2022

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 phab: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: wikt: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 do use the table of contents and I hate this new one. I dislike the need to click on each section to expand it, I feel like it defeats the point of a ToC which should allow you to quickly find the desired section or subsection. Also, in the previous one for long articles I could see more of the ToC at any given time, with this new one it requires me to scroll a lot more. Which, again, defeats the point of quickly seeing the contents at a glance in my opinion. Noxian16 (talk) 22:18, 25 September 2022 (UTC)

Same here; I do actually use the TOC frequently and found it so unusable in its new form that I switched back to the legacy UI. Newmila (talk) 14:25, 22 October 2022 (UTC)

Honestly, disagree. One of the least effective parts of MediaWiki skins were the ToCs, where most people ignored them and created a huge waste of space in the middle of the article. With the ToC now being a sticky scrollspy it makes them much more effective, in fact, resembling how documentation websites work, highlighting the section you're in. Definitely a much better UI decision. Lakelimbo (talk) 01:56, 2 October 2022 (UTC)

I use the Table of Contents all the time when editing an article or generally viewing a page and in it's current state it is unusable in Vector 2022 for editing. I Suggest

- A way to hide it when not in use without wasting space

- A way to use it in editing pages

- And a design that is largely based on the old one Ponde99 (talk) 11:11, 23 October 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)

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, {{u|Sdkb}} ^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. {{u|Sdkb}} ^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 (phab: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

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? {{u|Sdkb}} ^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, {{u|Sdkb}} ^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. {{u|Sdkb}} ^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. {{u|Sdkb}} ^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.:
  1. Traditional sidebar content
     • (or traditional sidebar content + ToC, similar to the mid-2022 prototype)
  2. ToC only
  3. 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#L-73.
• 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 #mw-navigation 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)

Same here. I really really loathe that the new TOC is at the very bottom of the lefthand sidebar; this really makes no sense from a UX perspective imo... when using an e-resource, the TOC is always visible either at the top of a page's primary text block, or at the top (not the bottom!) of a secondary or tertiary text area (or sidebar). This redesign effectively completely hides the TOC from view, making it practically unusable. I continue to be confounded as to why anyone thought hiding the TOC was a good idea. Excuses about edge cases where the TOC is extremely long do not adequately address this situation. In such cases, could it not be that a) the TOC (in its normal position not in the sidebar) the sub-items in the TOC are by default collapsed with only top-level TOC items immediately visible? and b) that users could expand sub-items in the TOC by clicking to do so? Newmila (talk) 14:32, 22 October 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? {{u|Sdkb}} ^talk 02:37, 30 April 2022 (UTC)

Bumping @SGrabarczuk (WMF) and @OVasileva (WMF). {{u|Sdkb}} ^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: scroll-behavior: smooth;. (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 (click to view GIF)

AHollender (WMF) (talk) 21:31, 18 August 2022 (UTC)

@AHollender (WMF), wonderful; I'm curious to see the results! {{u|Sdkb}} ^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. {{u|Sdkb}} ^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 back 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. {{u|Sdkb}} ^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)

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:

  1. If a sidebar ToC is currently displayed:
     1. The article inline ToC starts in its ‘collapsed’ state (but remains in the traditional location).
     2. 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)
     3. 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?)
     4. 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)
     5. 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.
  2. 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:
     1. Collapses, without visible reflow, if the inline ToC is currently off-screen.
     2. Collapses, with visible reflow, if inline ToC is currently on-screen (with the exception of #4 below).
     3. 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.
     4. 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.
  3. 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)

Fully agreed. I'd like to add that in the previous one for long articles I could see more of the ToC at any given time, with this new one it requires me to scroll a lot more (but first I'd need to click on all the sections to expand them, which would be time consuming). These facts defeat the point of having a ToC which purpose should be to allow you to quickly find the desired section or subsection.

Noxian16 (talk) 22:29, 25 September 2022 (UTC)

Fully agree. However, despite much opposition to the new TOC it seems that the criticism is not being taken into consideration by the designers. 37.163.178.20 13:49, 5 October 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?

1. The top (Contents) could be bold, so we can see that it is a menu header. This would make the reading easier, I think.
2. 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

Vector 2022, TOC "Top" section link with arrow

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 ?uselang=qqx to the end of the URL, that the name of the string is vector-toc-beginning, 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 (↑ Gora) 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)

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#Link colors): 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 #3366cc was a given, so didn't explore combinations that involved changing that. @Volker E. (WMF) could you comment on our choice to use #3366cc? AHollender (WMF) (talk) 18:46, 2 September 2022 (UTC)

Tracked in Phabricator
Task T213778

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

@AHollender (WMF): 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)

People designing color schemes should also read about color blindness. For me vector-legacy colors are a better choice. -- Formatierer (talk) 13:50, 8 October 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#Table of contents below sidebar just doesn't work. 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)

Thank you for fixing the narrow window layout

Re #Sufficiently narrow window just shows some separator lines: 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)

And, bingo. Looks good. Thanks for all the efforts. DavidBrooks (talk) 19:08, 27 September 2022 (UTC)

too conservative, not enough flexible

the new vector looks good, but it is too conservative, and displays too much stuff all the time. there is no difference between a first time user experience, and more time users. to be a little more concrete:

• major problem one is that it restricts the width. one does not buy a wider screen to display white, to choose the width with the window size is a personal preference :)
• major problem two is the edit mode. it displays everything, and additionally restricts the width. edit should be edit only no left top bottom etc menues. full width, full hight.
• the floating table of contents is cool. having the menues and TOC on the right side might be better for visually impaired using screen readers. but i'd only suggest it after a test with blind persons. i saw one read wikipedia and it took for ages until the screen reader went through this left hand menu and top menu until the text reading started - but that was too long ago.
• the traditional menu above the table of contents is *caugh* a little useless over time. maybe a first time user skin, which disappears after a couple of days? with an easy to reach button to enable it again?
• "switch to old look" should switch to what was before, and not open the preferences with options. i cannot remember what i had before without trying.
• 2 times "main page", top corner, and first menu entry. should go.
• "contents", cannot remember i ever click it. should go to help.
• "curent events", its a notification and should go in notifications, customizable with categories or so.
• "radom article", never clicked it.
• "contact us", never clicked it. i'd expect it at the bottom.
• "about wikipedia", never clicked it. i'd expect it at the bottom.
• "help", should to to the top, as ? icon.
• "learn to edit", should be in new help on top.
• "community portal", should be in new help on top.
• "edit interlanguage links", should be close to languages, or close to edit.
• language takes 2 clicks instead of one.

so, in a summary, i like it a lot, but i will not use it as long as the two major problems are not fixed: restricted width, full screen editing. --ThurnerRupert (talk) 06:07, 9 September 2022 (UTC)

I agree with you specially on this : "switch to old look" should switch to what was before, and not open the preferences with options. I cannot remember what I had before without trying.

I feel this is very annoying, since there is no simple way to go back, and I feel annoying that I feel almost forced to adopt the new look, once tried for one page, if I don't understand the settings well.

Also : when switching from the old mode to the new look, there should be an option, a pop-up that would allow me to switch:

- just for this page,

- for all future wiki pages. 188.155.249.191 04:20, 12 September 2022 (UTC)

If I may (and under the impression I am thinking correct):

1. The contents of the side-menu are customizable by the respective wiki and does not have to do anything with the skin.
2. I suppose switching back to old skin via a link in the side-menu seems a little hard, because you need to edit preferences with a single click. I'd think that's technically not possible at the moment.

Ping @AHollender (WMF): This is an example for people confusing system-community-content and who is responsible for what. Regards HirnSpuk (talk) 07:23, 22 September 2022 (UTC)

How to localize the Wikipedia logo for vector 2022?

I occasionally work for small Wikipedias (Esperanto, Alemannic German, Simple English,..) and I saw that most of them haven't localized the Wikipedia icon on vector 2022 yet. (so it is just "Wikipedia" in English without the subtitle "The Free Encyclopedia" in the language of the wiki) I couldn't find anything about this in the template localization tool and I asked one administrator, who couldn't tell how to do this as well.

Any tips on that? I guess you have to be an administrator to change it, right? But where exactly can you change it? Stefangrotz (talk) 20:00, 11 September 2022 (UTC)

This requires a wikitech:Wikimedia_site_requests. Manual:$wgLogos has information about how to set a new logo. Is that what you are looking for? Jdlrobson (talk) 21:17, 12 September 2022 (UTC)

Thanks, this helped. I created the necessary files and added them to Reading/Web/Desktop_Improvements/logos

Now I have to find a admin willing to add it to the template of Vector 2022 and the mobile template. Stefangrotz (talk) 16:12, 13 September 2022 (UTC)

Here is the ticket on phabricator for the site request https://phabricator.wikimedia.org/T318216 Stefangrotz (talk) 16:44, 22 September 2022 (UTC)

Initial impression: Feels like I'm on a mobile site

My entire screen is bright white. I never realized how much I appreciated the sidebar being light gray until now.

The thin, light blue lines between the content and the header and sidebar helped delineate the different elements of the page and added a splash of color. Don't understand why you trashed those.

The wikipedia icon, which I think looks cool, is now tiny (and consequently looks less cool since it's a fairly detailed logo [and a GOOD ONE, don't you dare go and oversimplify it]).

On a more positive note, the pop-down persistent header with the little icons also feels very mobile-y to me, but after some consideration I don't actually hate it. Give it a grey background and a blue border and I think I'd actively like it--having those options available halfway down a long page seems pretty useful. Ditto for the persistent table of contents (though the current implementation seems a bit too wide to me).

Overall, gives me very similar vibes to clicking on an m.wikipedia in discord.

(oops, wasn't logged in--now I am) Droideka30 (talk) 03:39, 13 September 2022 (UTC)

@Droideka30: Same impression; it seems the website is being optimised for mobile. Especially, I don't see any sense in the removal of the old TOC. 37.161.139.176 13:55, 19 September 2022 (UTC)

>Overall, gives me very similar vibes to clicking on an m.wikipedia in discord.

Essa é a mesma impressão que tive, e considero isso negativamente. Acesso a wikipedia pelo desktop e espero uma experiência de desktop. Sinceramente odeio essa ideia de que usuários do desktop são "apenas usuários mobile com telas grandes e largas", especialmente no meu caso com uma tela de baixa resolução.

É MUITO espaço em branco na tela agora, especialmente na lateral direita, o que passa a impressão de que aquela era/será uma área para propagandas. E a remoção do menu de escolha de idiomas em favor daquela lista flutuante (um clique e scroll a mais) não é nada prática para usuários de notebook, a situação chegou num nível que passei a ativamente evitar a wiki em português devido ao excesso de branco e chateação para mudança de idioma.

E não sei se sou particularmente burro ou o quê, mas simplesmente não encontro em lugar nenhum essa opção de voltar ao layout antigo sem estar logado, nem no topo ou final da página, ou com qualquer opção que consegui pensar no CTRL+F. Sem falar no quanto essa alteração foi jogada nos usuários, nenhum banner ou algo do tipo informando, e só hoje após vários meses fui esbarrar nesses tópicos (pois pela primeira vez um google com o termo "wikipedia voltar ao layout antigo" retornou algum resultado da própria wiki, e não uma reportagem aleatória de 2020).

No geral, posso dizer que odiei o tanto de espaço branco no novo layout, e mesmo a nova barra de pesquisa sendo MUITO legal e MUITO mais útil que a anterior, ao ter que pesá-la entre "função nova elegante e prática" e "poder ler o artigo sem queimar meus olhos", a barra infelizmente perde.

Acho que seria muito mais proveitoso se esse espaço em branco fosse preenchido com uma tonalidade cinza leve, assim como na aparência clássica, e a TOC fosse limitada a 1/5 ou 1/4 da largura da página sem tanta margem entra a mesma e o conteúdo (nessa mesma página posso dizer que 1/10 da largura é dedicado apenas a esse padding entre a barra e o conteúdo, o que é ridículo se comparado com a versão clássica que é de 1/15-1/20). 179.191.242.233 17:39, 17 October 2022 (UTC)

Sidebar should always be visible on the Main page

On fr.wikipedia.org, when I'm logged out, the sidebar is hidden by default. I'm not convinced that this is beneficial. On article pages, the ToC is there, so it makes sense for it to be collapsed (I really like the Moss prototype, and how the main menu can be floated or placed back in the sidebar, BTW). But on the main page, hiding the sidebar causes way too much white space and might confuse users who may think they're on the mobile version of the site. It's also disorientating. I think the sidebar should be visible by default on main pages. DFlhb (talk) 12:47, 13 September 2022 (UTC)

Thanks for the feedback @DFlhb. We've addressed some of the questions around the white space in this section of the FAQ - hopefully that's helpful! OVasileva (WMF) (talk) 12:09, 15 September 2022 (UTC)

The only relevant part of that article I see is:

"People are able to focus more easily without the distraction of sidebars or other elements."

However, I feel that doesn't apply to the main page. People don't just use the search bar to get to what they want; many like to get an "overview" of the site or its structure, or they get overwhelmed. If Apple.com, for example, didn't have a top-bar (equivalent to the Wikipedia sidebar) that helped users navigate the side and just put everything in different parts of the main page, everyone would feel lost. For example, the link to https://en.wikipedia.org/wiki/Wikipedia:Contents is very useful. I'm assuming you're relying on pageviews and click rates to make these decisions, but obviously once someone has been on those pages once, they "get" the structure better, and only go back if they feel a need to. But the website without a sidebar on the main page will make brand-new users feel lost. DFlhb (talk) 17:44, 15 September 2022 (UTC)

File:01 Würfelverdoppelung-5.svg

File:01 Würfelverdoppelung-5.svg

Long words will be truncated from the image!

• Example: Konstruktionsbeschreibung

Petrus3743 (talk) 11:18, 16 September 2022 (UTC)

Interesting. Thanks, @Petrus3743. This must be, I guess, in result of words not getting divided into syllables... But also, as you can see when you edit the page, on that very page, wikitext is mixed with CSS, so it seems to be a matter of formatting that exact content, doesn't it? SGrabarczuk (WMF) (talk) 20:22, 16 September 2022 (UTC)

Many thanks, @SGrabarczuk (WMF). I rearranged the pictures, then it is ok! :-)--Petrus3743 (talk) 07:24, 17 September 2022 (UTC)

Vector 2022 by default for every user

How can I make Vector 2022 the default desktop skin for all users of our Wiki? Lmdg2000 (talk) 09:26, 17 September 2022 (UTC)

Hello @Lmdg2000. What wiki do you mean? SGrabarczuk (WMF) (talk) 14:02, 18 September 2022 (UTC)

I use MediaWiki for my Wiki Lmdg2000 (talk) 13:36, 24 September 2022 (UTC)

Thank you @Lmdg2000. Then this may be the answer you're looking for. Am I correct? Are you asking about your own wiki? SGrabarczuk (WMF) (talk) 10:53, 26 September 2022 (UTC)

That's correct: my own wiki. Thanks for the link. Now I understand that I am supposed to have 1.39 version ( I am currently on the last stable 1.38) Have you any suggestion on how to upgrade to 1.39 without losing stuff/extensions added so far? (Wiki is hosted on A2 , I use a cPanel )...Any tip is welcome Lmdg2000 (talk) 14:42, 26 September 2022 (UTC)

Add the slogan in ms.wikipedia.org

Add "Ensiklopedia Bebas" under Wikipedia for ms.wikipedia.org just like how in en.wikipedia.org have "The Free Encyclopedia" under Wikipedia. Currently, it only says Wikipedia in ms.wikipedia.org Tofeiku (talk) 15:22, 17 September 2022 (UTC)

Thanks @Tofeiku. I don't know when we would do that exactly, but I think we definitely should do that before Vector 2022 is the default on ms.wikipedia.org. SGrabarczuk (WMF) (talk) 14:04, 18 September 2022 (UTC)

Thank you for the reply. I see that in some language edition like idwiki has the slogan in their language. I guess we have to wait for mswiki then. Tofeiku (talk) 17:25, 18 September 2022 (UTC)

You're correct, @Tofeiku. This is because on idwiki, Vector 2022 has been the default for a while now. They just needed the slogan sooner.

Since we're talking - do you think there's anything to be done (I'm asking about technical things) before Vector 2022 has been made the default on mswiki? SGrabarczuk (WMF) (talk) 17:57, 18 September 2022 (UTC)

I don't know much about this. Is there a checklist I can see for mswiki? Tofeiku (talk) 18:15, 18 September 2022 (UTC)

🤔 No, I believe there's not... This is about local gadgets and user scripts, and possibly extensions, too. Well, if you'd like to help and if you noticed anything not working on Vector 2022 but working on any other skin, just tell us, and we'll work on that :) SGrabarczuk (WMF) (talk) 21:14, 18 September 2022 (UTC)

Элемент Викиданных

Раньше в Элементе Викиданных справа сразу были ссылки на Википедию, Викиучебник и т. д., а теперь они в самом низу и не очень удобно туда попадать — Валерий-Val (talk) 21:43, 17 September 2022 (UTC)

Menus deployment

When will the sidebar and tool menu from https://vector-2022.web.app/Moth will be deployed? --NGC 54 (talk | contribs) 15:10, 19 September 2022 (UTC)

Hey @NGC 54, we've just begun the work, which you can follow along here: https://phabricator.wikimedia.org/T302073.

We are hoping to deploy it within the next month or two. AHollender (WMF) (talk) 17:50, 20 September 2022 (UTC)

Automatic expansion of sub sections in table of contents

Currently when you scroll to a section with sub-sections, only the highest-level section highlighted and shown in the table. In other apps, the section you are currently scrolled to expands its subsection headers automatically. When you scroll from that section it closes. This helps the user understand where they are in relation to other sub-sections in the primary section. Could this functionality be added? Lectrician1 (talk) 18:53, 19 September 2022 (UTC)

Hey @Lectrician1, thanks for this suggestion. There is actually a discussion about this happening in phabricator right now (link to task). I'm not sure what the best practice is in terms of copying my response from phabricator to this talk page, versus pointing you to that discussion(?). Perhaps it would make sense for you to start by reading the existing thread?

High level: we tested that functionality but decided it should not be the default behavior because it results on too much automatic animation on the page which is disruptive to some people. Additionally, in some cases when you scroll to a section you can already see some (or all) of the sub-sections directly on the page.

What are your thoughts? AHollender (WMF) (talk) 17:47, 20 September 2022 (UTC)

@AHollender (WMF) Well, if some people find it distracting then I guess we should not make it a default feature. However, if some do like it and some also like having all of the sections expanded, then I would think having those as alternative options to view the TOC could maybe be selectable through using the settings icon in the upper right of the TOC that was in a prior prototype. Lectrician1 (talk) 23:27, 20 September 2022 (UTC)

Rename "Vector (2022)" to something else

The new skin is substantially different from the old one, and reflects a decision to halt updates on older iterations of Vector. It looks and feels different (and breaks many user scripts from "legacy" Vector). As such, it deserves a new name to differentiate itself from the older Vector skin. This would have the side benefit of making it easier to talk about during the transition to use it as default: we can clearly distinguish Vector from [some new name] by name, while comparing "legacy Vector" to "Vector (2022)" is unwieldy and potentially confusing. {{Nihiltres|talk|edits}} 18:11, 20 September 2022 (UTC)

Please see Reading/Web/Desktop_Improvements/Frequently_asked_questions#Why_do_you_use_this_naming:_Vector_2022_and_legacy_Vector? for some more context on this. Jdlrobson (talk) 15:34, 21 September 2022 (UTC)

I'm aware of the reasoning; I mean to advocate for a different approach. {{Nihiltres|talk|edits}} 16:57, 21 September 2022 (UTC)

Yes, at this point this is a Ship of Theseus problem: the fact that the new skin was built based on the old one should not be a justification for making the naming so confusing. As was mentioned by someone on Discord, Vector was also a skin that was forked from Monobook, but no one thought to call it Monobook² or to call this one Monobookmonobookmonobook since it is its distant relative. ‘New Vector’ and ‘old’ Vector have as much in common as Monobook and Vector do, which is to say, not a lot. There’s no reason why it can’t be called something different and couldn’t be called something different. Then again, DI team was pretty hesitant about decoupling the skin code, too, so it’s understandable why they are now hesitant about going away from the weird ‘legacy Vector / Vector’ dichotomy. stjn^[ru] 12:14, 23 September 2022 (UTC)

I'm also of the opinion that, at this point, Vector 2022 is distinct enough to warrant renaming - the mix of whites/greys/blues, to me at least, suggests a winter-themed name might fit it well (Snow?). Remagoxer (talk) 17:05, 23 September 2022 (UTC)

I'd agree that creating a new name is warranted, rather than just "Vector 2022". It will be simpler for everyone to have the distinction clear. {{u|Sdkb}} ^talk 20:22, 5 October 2022 (UTC)

General Points of view regarding some processes and features

There have been two discussions in the past, that I want adress because of questions I got asked. I apologize for the length of the text. If I need to make a tldr I believe it would be this:

• I do like the idea of Vector22 but I don't like the recent change in Vector22 regarding the TOC. The change at the TOC made me realize that I oppose the mix of wiki-system and wiki-content. Details below and in cited links.
• I see potential for optimizing the "process" for Vector22, though it seems to be too late.
• I'm deeply troubled that my work in the wikimedia-universe will become harder (at least for a time), because of rewriting, redesigning and discussions.

I'll try to answer to the regarding points. If you want to answer or discuss further I would like to ask two favours:

1. Please ping me because I'm pretty busy in RL right now, I'll probably not answer in an hourly or daily fashion.
2. Please sort and or structure the topics to your liking, if any.

Let me start with the older discussion (see Talk:Reading/Web/Desktop_Improvements/Archive5#General_concerns!); Ping @SGrabarczuk (WMF)

1. You tried to make your points and I can individually understand everything, but the whole picture lacks two things in my opinion:
   • a little communication. A current example: The english wikipedia seems to be given the opportunity to oppose the new skin. This seems to be new information and I don't see it reflected in the project page. Or is it an exception solely for the english wikipedia?
   • a thought of "maybe there's another vantage point!". An example here is: Reading/Web/Desktop_Improvements/Features/Collapsible_sidebar#Results. Doesn't this show, that logged in users prefer their sidebar uncollapsed? (Reason: It was uncollapsed and the clicks are nearly identical so it ends up uncollapsed. Additionally the click-number decreases) Wouldn't it be reasonable to taylor the experience to the contributing user not the reading user?
2. compare to the number 3, second bullet-point of your comment: The number of steps needed to be taken to find the "measures" are pretty high. Don't you think this is "telling" somehow? I think that needs more exposure. On the main page here for example.
3. I can't join office hours because I will not use zoom.

Summing up: I can understand your motives, though I only partly agree with them. I highly appreciate your ability to talk, listen, discuss and reflect.

Regarding the second discussion (compare Talk:Reading/Web/Desktop_Improvements/Archive3#Language_Selector_misunderstandable, especially the last two comments); Ping @AHollender (WMF):

1. Regarding system-content-duality: The idea behind a wiki is, that the system (providing the framework for the content) is woven into the page itself, so that it's easier for anybody to contribute. There is another layer in wikimedia-projects: the community. So we have three different things we need to explain:

1. What is the wikisystem, how does it work (and why).
2. What is the wikimedia-community and the corresponding project-community and how do they work.
3. What is the content of the project about and how is it to be structured/written/what is acceptable and the like.

Now, all three things are interconnected somehow and this is pretty hard to understand. I have first hand experience how interesting the journey for me was to understand, how this all is interconnected. I have second degree experience in seeing mistakes that are being made and to explain and correct them. Third we as communities use the wikisystem to taylor community-processes to our needs (RfC, templates, community-pages...). So everything is pretty much interconnected in itself. If we change the system significantly, the processes will probably change as well.

• Example: I rely heavily on the ability to reach the "recent changes" easily. In the new system I do have three options: either I use the TOC on the specific site in a manner that's sufficient or I have my recent-changes-link or I need a lot of clicks. As a side-note I must admit: You specifically asked, what functionality is needed where and I didn't think of it back than, so I did not comment than, and - last not least - this is just a process that affects me.
• Another example is: b:de:MediaWiki:Sidebar. Because of the "new system" there will probably be a significant discussion, what links should be kept there and how they should be placed otherwise.
• Next example: Because of the change of the edit-Button-location, I expect that people will mistake them for "community-servicable" (e. g. remove all the "buttons" there, "can I add my own", "can I move them up(, where they were a few months ago)?"...)

So I think a clear differentiation between content and system would be beneficial.

@AHollender (WMF), does this answer your first question?

2. Your misunderstanding might come from the rewrite and redesign issue. Thanks for the offer to help with rewriting and I know it's a necessary evil and it will be more or less fine. I don't think your help will be necessary, I suppose you have enough on your hands. But really thanks a lot. The one thing I would like to ask for, if I may is: Once vector22 is deployed as default don't change anything, except for bugfixes. It's my impression that it is planned to have more features implemented when it's already deployed. That would at least adress the continuos "rewriting" part.

The issue with the "floating ability" is a problem regarding redesign: Community-Pages, that rely on some kind of TOC, needs to be redesigned, because the positioning of the TOC with respect to a specific part of the content doesn't work anymore. So to facilitate this and everybody using the sidemenu expanded, there need to be workarounds. This will be especially tedious for pages where the TOC is deemed to be in print.

I'm just a little stressed out, because I'm unsure how this all will work out. But it'll probably will. If I would be granted just one wish: Just leave the TOC as it is or at least let ForceTOC and floating ability show the old behaviour additional to the new TOC (though I don't know if this is technically possible). I apologize for the lengthy explanation again, best regards HirnSpuk (talk) 18:15, 21 September 2022 (UTC)

I've been trying out this skin, and while it is generally fine, it has some drawbacks, which could be remedied:

• The button for editing the first section is above the one for editing the whole page. This really takes some getting used to.
• The layout of the page in preview does not match the actual layout of the page, which sort of defeats much of the purpose of being able to preview.
• It doesn't work with WikEd, so I was forced to use the old 2010 editor, which lacks many features.

Hawkeye7 (talk) 23:41, 21 September 2022 (UTC)

Opt-out for wuuwiki

I'm using Vector 2022 and feel like it's still unstable. It's better not to make Vector 2022 skin the default on wuuwiki now, also because the logo on Vector 2022 has not been localized. Local discussion. Lt2818 (talk) 05:27, 22 September 2022 (UTC)

Hello @Lt2818, thanks for your comment. I'll keep an eye on that discussion. Regarding the logo, it will be created within the next couple of days, before the announced date of deployment. Regarding the lack of stability, I admit, bugs happen, even though we catch most of those before a software update goes to wuuwiki. Do you experience any particular quirks now perhaps? SGrabarczuk (WMF) (talk) 02:13, 24 September 2022 (UTC)

One example: when you click #mw-sidebar-button to expand/collapse the sidebar, the #content 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)

Analyse by Dušan Kreheľ: To have Vector as default skin Wikipedies from 2022-10-03?

Result

Question	To have Vector as default skin Wikipedies from 2022-10-03?
Answer	No.
Analyse time	2022-09-22

Analyse details

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:
    1. Title: "User contributions for XY".
    2. The line with the new tools.
    3. 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)

@SGrabarczuk (WMF): 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? {{u|Sdkb}} ^talk 01:09, 24 September 2022 (UTC)

@Sdkb thanks for calling this out. I was also looking at that the other week. I've created a task for the change: T319315. AHollender (WMF) (talk) 16:01, 4 October 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, {{u|Sdkb}} ^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)

On section-related vs. article-related, I agree — the infobox would presumably be persistent (i.e. sticky), whereas images would scroll with the rest of the page.

On references, if reader preferences were Wikipedia's only consideration, we'd look a lot more like Buzzfeed. Luckily we're able to consider more than that. Emphasizing references more might get readers to pay more attention to them, and even if they're still not clicked all that much, it'd be an improvement to the information landscape.

To Stefangrotz's point, any of these options would be a big change and would need to be extensively tested. For now, to start off, I'd be interested in someone putting together a mockup of what a featured article would look like with references at the side, or with images/the infobox in that space. {{u|Sdkb}} ^talk 16:45, 26 September 2022 (UTC)

I do not see any problems in testing a version with refs on the side, but the readers come at Wikipedia to read articles, not to check references. I think that the infoboxes are more interesting for and read more often by readers than the references. For references, there are previews (like Reference Tooltips on English Wikipedia or Reference Previes on other Wikimedia wikis). --NGC 54 (talk | contribs) 16:53, 26 September 2022 (UTC)

I don't think its useful to completely dismiss references as something entirely editor-facing. If there were the case, we would not make them so obviously inline and hide them to editors, except for a general list at the bottom. Many readers come to Wikipedia to read, yes, but they also do look for verifiable information. The margins are an obvious place for references to fall, which is consistent with other academic works some readers may be familiar with. Additionally, placing notes (which usually are read as a pop-up) in the margins work great as well. I don't want to rely entirely on previews. JackFromWisconsin (talk) 15:59, 19 October 2022 (UTC)

For an example of a publication putting references in the margins, see the Harvard Law Review (h/t to Tamzin). {{u|Sdkb}} ^talk 16:35, 26 September 2022 (UTC)

@Sdkb: Yes, but Harvard Law Review has no images and/or infoboxes. --NGC 54 (talk | contribs) 16:37, 26 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)

@L10nM4st3r - thank you for your feedback. Could you give us a bit more detail on which browser and operating system you are using? OVasileva (WMF) (talk) 10:44, 3 October 2022 (UTC)

@OVasileva (WMF): I use w:Amazon Kindle 10th gen, with the deafult web browser. (Now I'm thinking there's a way to change the browser, but how?) L10nM4st3r (talk) 11:26, 3 October 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 [1]. Pinky sl (talk) Pinky sl (talk) 09:17, 25 September 2022 (UTC)

Hi @Pinky sl, you can read this FAQ section, and this page. Patafisik (WMF) (talk) 07:42, 3 October 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)

Ability to natively use different fonts/font sizes

A while back, I seem to recall the idea of letting the user change the skin's font/font size being mentioned by one of Vector 2022's developers. Whilst I'm not entirely sure as to whether this was mentioned/the context, I'm personally interested in such a feature, even if it was just limited to a few open fonts (e.g. Noto/Open Sans) as the default sans-serif font (in most cases, Arial) isn't that great in my opinion (especially at bigger sizes). T91201 may also be relevant. Remagoxer (talk) 00:28, 27 September 2022 (UTC)

"Add languages" missing "Add links" dialogue?

Tracked in Phabricator
Task T316559

When a page with no inter-wiki links stored in Wikidata is viewed in Vector 2010 or Monobook, it presents an Add links option under the empty Languages list on the left-side; clicking that opens the Link with page dialogue.

Viewing the same page in Vector 2022 gives Add languages at top-right, but clicking it gives only a blank pull-down. Where is the equivalent functionality to create inter-wiki links; is the only option for the user to go over to the Wikidata item and create a link from there? AllyD (talk) 19:39, 27 September 2022 (UTC)

Hi @AllyD: under the "Wikidata item" in the sidebar there is a link to "Edit interlanguage links". A task is open on Phabricator to improve the "Add languages" in the language button at top-right, see T316559.--Patafisik (WMF) (talk) 08:37, 28 September 2022 (UTC)

Ah thanks, I see it there now. It will be good to complete the functionality for the Add languages message. AllyD (talk) 08:48, 28 September 2022 (UTC)

Hi @AllyD - thanks for the question. We are currently working with the language team to make this available. In the future, we hope it will be available both from within the "Languages"/"Add languages" button as well as from the "Edit interlanguage links" link within the menu. OVasileva (WMF) (talk) 10:42, 3 October 2022 (UTC)

Postponing the change in Finnish Wikiquote

I would like to get more time to discuss the change. Smaug the Golden (talk - contributions - logs) 21:49, 27 September 2022 (UTC)

Opt Out Permanently

After conducting a wide-scale poll of the users of my wiki, the overwhelming majority of users chose to stick with the old design. We also have an extremely large amount of custom CSS which was designed with the old vector in mind. As such, we would like to never switch to the new vector.

Is there a convenient way to do this, or do I need to fork the existing legacy vector skin and force our wiki to use that as its skin? 2601:CD:4000:2290:0:0:0:BB0 00:35, 28 September 2022 (UTC)

Hi, thank you for writing here. I'll gladly continue this discussion, but first, I'd like to ask you what community we're talking about. Unfortunately, you weren't logged in on this wiki when you added this comment :( SGrabarczuk (WMF) (talk) 22:43, 29 September 2022 (UTC)

Thank you for your reply. We operate Dustloop Wiki, a wiki for fighting games developed by Arc System Works. Although the new vector offers some advantages and improvements, the effort required on our end would exceed the capacity of our single developer, and is unpopular with our userbase. 2601:CD:4000:2290:0:0:0:BB0 15:22, 30 September 2022 (UTC)

Thanks for your note! For third party wikis, you will remain able to set the default skin to any of the other available skins. OVasileva (WMF) (talk) 10:40, 3 October 2022 (UTC)

Opt-out on Old English Wikipedia

We are a small group who occasionally build 'ang.' It is a language with no native speakers and a modest academically-minded community who understand and can write in the language. It is essentially an educational tool. Many of the terms used are derivative as texts from a thousand years ago do not discuss concepts Modern English takes for granted, so having language links displayed on the left-hand side is immensely useful. That also allows one to dip in and out of English of Icelandic versions for content to be translated.

It works well in the existing format (and I agree with everyone above that the narrow display version is awful). Perhaps the pencil-width text columns work for looking at an English-language article on a mobile 'phone for quick facts, but the Old English site is not used in that way - overwhelmingly the site is viewed on a full-size computer screen. The current format works best for that. Hogweard (talk) 10:17, 28 September 2022 (UTC)

Accesskeys in user menu don't work on Firefox

Due to duplicate accesskey elements, accesskeys for items in the user menu don't work, such as my user page (Alt+Shift+.) or my watchlist (Alt+Shift+L). There are e.g. three elements with <a ... accesskey=".">. Skalman (talk) 18:34, 28 September 2022 (UTC)

Opt-out Dutch Wiktionary (WikiWoordenboek)

Because of the localized name and subtitle, the adaptation of the logo is an important part of the skin. Please don't make the new skin default on nl.wiktionary.org until we have had at least two weeks to evaluate a proposal for this adaptation. MarcoSwart (talk) 07:51, 29 September 2022 (UTC)

Traduzioni e File

Nel menù in alto a destra solo Traduzioni e File sono in maiuscolo. @Patafisik (WMF) . Wesldkins (talk) 08:31, 29 September 2022 (UTC)

@Wesldkins Grazie mille per la segnalazione! Ho sistemato, considera che ci vorrà qualche ora prima che le maiuscole diventino visibili. Se ti ricapita di trovare traduzioni da sistemare puoi notificarmi o cercare il pezzetto di testo da tradurre aggiungendo all'url ?uselang=qqx, e andando a sistemare la traduzione su translatewiki.net (esempio). Buon wiki, Patafisik (WMF) (talk) 11:22, 30 September 2022 (UTC)

@Patafisik (WMF) In realtà io mi riferivo a vector2022 su it.wikipedia, che non è su translatewiki, lo avevo dato per scontato da quel che avevi scritto al bar. comunque anche qui su mediawiki il menù non è aggiornato (è anche diverso da wikipedia) e su translatewiki i 2 gruppi vector non hanno le voci da tradurre del menù. Wesldkins (talk) 10:11, 4 October 2022 (UTC)

@Wesldkins Su translatewiki si gestiscono le traduzioni che impattano l'interfaccia su it.wiki, come appunto i link "Preferenze", "Contributi", ecc. Le mie maiuscole sono state annullate. C'è una discussione in corso qui sulle maiuscole e minuscole a cui sei invitato a partecipare. Patafisik (WMF) (talk) 06:34, 7 October 2022 (UTC)

"Add languages" is a confusing button

When I view a page which has no corresponding pages on other language wikis, when scrolling down the sticky header very prominently displays an "Add languages" button. When clicking the button, the dropdown says "No languages yet - No languages are available for now" which I think is confusing language.

1. "Add languages" - 'Adding' a language is ambiguous and unclear to me. What the button is really saying is 'Translate this page', as I understand it.
2. What does "no languages" being "available" mean? I think it would be clearer to write something like "This page is not available in other languages".

Additionally, this button is displayed in some namespaces which seem to never have a corresponding page, such as the article Talk: namespace. Samwalton9 (talk) 10:00, 29 September 2022 (UTC)

I think both of these are very good points, and I'd love to see them taken into consideration. —TheDJ (Not WMF) (talk • contribs) 08:17, 30 September 2022 (UTC)

I agree that the prominent position and imperative tone of the "Add languages" button make it crucial that the associated functionality is clear and robust. I had assumed the Language button to be effectively a move of the Languages list from the left-side, including its Link with page dialogue - so supporting a user who wishes to "inter-wiki-link the current article with an existing article in another language". Looking at task T316559 and task T314620, it seems to be more about for a user who wishes to "add an equivalent of the current article in another language". If that is the intention, it is more problematic, for example, in respect of use of the Content Translation tool which is under restrictions on its use in en.wiki. AllyD (talk) 10:00, 30 September 2022 (UTC)

@Samwalton9 thanks for this feedback.

cc @Pginer-WMF & @Aaharoni-WMF from the language team who are working on various updates to the language switcher (and entry points to translation) AHollender (WMF) (talk) 21:30, 12 October 2022 (UTC)

"current version" hides other links

If a page has unreviewed versions of an article, the "current version" link hides other liks such as the site history. It should be a little lower. Stefangrotz (talk) 19:01, 29 September 2022 (UTC)

Please always link to the page where you see something. Now someone needs to spend like half an hour to figure out which wikis have revision review, and which pages on said wiki have unreviewed changes.... —TheDJ (Not WMF) (talk • contribs) 08:19, 30 September 2022 (UTC)

Sorry, I wasn't aware that this feature isn't activated everywhere. Also, the pages will get reviewed, so the link won't work very long. Here is an example from the Esperanto Wikipdedia: https://eo.wikipedia.org/wiki/Red_Dwarf Stefangrotz (talk) 18:01, 30 September 2022 (UTC)

@Stefangrotz I've attempted to document this issue here: https://phabricator.wikimedia.org/T320680. AHollender (WMF) (talk) 21:27, 12 October 2022 (UTC)

Thanks a lot! Stefangrotz (talk) 11:25, 13 October 2022 (UTC)

Language options reflecting GA/FA status

Tracked in Phabricator
Task T319002

Is there a rationale for why there is no longer a star icon in the languages drop-down menu next to versions of the article in other languages that have achieved GA or FA status? Morgan695 (talk) 19:21, 29 September 2022 (UTC)

It is because Extension:WikimediaBadges does not yet have support for Vector 2022. —TheDJ (Not WMF) (talk • contribs) 08:22, 30 September 2022 (UTC)

This should definitely be fixed. Having GA/FA stars is the bare minimum the language switcher can do to help guide users toward higher-quality articles, even if it means they have to use Google Translate. There is so much beyond that, too; quoting myself from previous conversation: We have a pretty good idea of when someone might want to switch to read an article in a different language: if it is featured/good status there but not here, is substantially longer there, has substantially more citations there, or is for a topic whose coordinate location on Wikidata is in a country where that is the primary language. The WMF folks might want to consider making the switcher more prominent only in those circumstances. Someone reading about Chicago's Harris Theater in Arabic should absolutely be given a prominent link to the English article, but readers of the English article definitely don't need to know about the Arabic page. {{u|Sdkb}} ^talk 20:41, 5 October 2022 (UTC)

@Morgan695 can you (or somebody else) help me understand what the issue is here? When I open the language switcher in Vector 2022 I see yellow and gray stars. Are these different than the ones you're talking about?

Language switcher in Vector 2022 with FA and GA stars

AHollender (WMF) (talk) 21:19, 12 October 2022 (UTC)

@User:AHollender (WMF) Below is what I see in Vector 2022. (Note that in this example, the article is featured on the French Wikipedia).

Morgan695 (talk) 01:48, 13 October 2022 (UTC)

@Morgan695 thanks for the screenshot — that clarifies things. You are seeing the non-JavaScript version of the language menu. @Jdlrobson do you know if it's possible to include the GA/FA stars in the non-JavaScript version of the language menu? AHollender (WMF) (talk) 12:24, 21 October 2022 (UTC)

WMDE maintain this feature. I believe this is phab:T298220 Jdlrobson (talk) 15:18, 21 October 2022 (UTC)

menu should be accessible while scrolling an article

I would like to be able to access the menu (the one toggled with the three horizontal lines in the upper left corner) from anywhere on the page. When I scroll down on a long article I have to go back up to the top of the article to access the menu and then I have to find my place again. إيان (talk) 06:51, 30 September 2022 (UTC)

Can you please provide examples of items you need, and then have to scroll BACK to somewhere in the article ? —TheDJ (Not WMF) (talk • contribs) 08:25, 30 September 2022 (UTC)

postponing on Latvian Wikipedia

hi! we would like to ask to pospone the change on Latvian Wikipedia (if i'm not already late for asking that). generally we're ok with change, but on October 1 we have national elections. it would be important, that people are seeing the old skin, so that there are no doubts that they are on Wikipedia, not some different-looking site. we didn't reach consensus about the timing, but probably extra week with old skin as default will be fine. Edgars2007 (talk) 12:25, 30 September 2022 (UTC)

Thanks for letting us know @Edgars2007! We will postpone the deployment. Our next targeted deployment date will be October 19 - we'll plan on switching the skin then for Latvian Wikipedia OVasileva (WMF) (talk) 10:32, 3 October 2022 (UTC)

thank you, sounds good. Edgars2007 (talk) 12:33, 3 October 2022 (UTC)

Categories

Could the category bar be made more prominent and modern? My intuition say me that just a few readers know about (an thus use) categories. Before becoming a wikipedian, I was not aware of categories. Additionally, a sticky button for categories than once clicked opens a mini-window that displays the categories (similar with the language switching button) would be a good idea, in my opinion. I am not very sure about the location of the button (maybe below TOC or in the sticky header). --NGC 54 (talk | contribs) 15:06, 30 September 2022 (UTC)

I second this proposal! Stefangrotz (talk) 19:18, 4 October 2022 (UTC)

The category namespace has always ostensibly been reader-facing but in practice used mostly by editors. I'd be interested in knowing what the use cases for readers would be before deciding whether to make it more prominent. Are they ignoring category pages because the category bar isn't emphasized enough, or just because they have no use for them? {{u|Sdkb}} ^talk 20:44, 5 October 2022 (UTC)

Redirect page titles aren't autocompleted

When I start typing the name of a redirect page using the Vector 2022 skin, the page's title doesn't show up in the search box. For example: if I start typing "Demographics of New Jersey," it shows the "New Jersey" article instead of a redirect page that goes to a section of the article.

This is different from the behavior of the older Vector skin, which always showed the redirect pages' titles when I typed them. Jarble (talk) 18:41, 30 September 2022 (UTC)

@Jarble thanks for pointing this out. I believe this task we're working on soon will fix this: T303013. Could you take a look and see if that addresses the issue you're raising? AHollender (WMF) (talk) 16:38, 4 October 2022 (UTC)

Tewiki - Issue with Telugu typing in Search box

I have been using the new Vector 2022 skin for the last three days. While many features are working fine, I have issues with the Search box:

1. The search box does not transliterate the Roman skript to Telugu as soon as the [page is loaded. If I leave the page and come back immediately, then it starts working. It is not the case in the old Vector (High priority)
2. While typing the in the Search box, when I move to to type new word, the first letter is erased, and only the subsequent letters are displayed (Serious issue)
3. Some of the typed letters do not appear as they are supposed to. Ex: when I type ree,vee,kee etc., they are supposed to appear as రీ,వీ,కీ. Instead they appear as రి,వి,కి (They are "printed" correctly, but don't appear correctly). (Medium Priority)

Please look into the issues. __ Chaduvari (talk) 05:36, 2 October 2022 (UTC)

Answered here.--Patafisik (WMF) (talk) 16:43, 23 January 2023 (UTC)

ToC once more: freedom of choice in other projects

Hi!

I find the idea of scrolling for the ToC good. I have already used this idea in my projects in german wikibooks, but i prefer to put it on the right upper side, where anyone can find it quite easily and any time, sometimes using a "go up" button (see for example https://de.wikibooks.org/wiki/Mathematrix:_AT_BRP/_Theorie_nach_Thema/_Exponential_und_Logarithmus_Funktion#top using the old vector). If you decide to let it like it is, please give the option, that in other projects a change of the position is possible (which is not the case with the new vector). Thanks.

Yomomo (talk) 10:49, 2 October 2022 (UTC)

@Yomomo thanks for this comment. The scope of this task is currently more limited, but could you please add a comment here with your request (including the link and a screenshot)? https://phabricator.wikimedia.org/T317818 AHollender (WMF) (talk) 21:13, 12 October 2022 (UTC)

Postponing on Wikimedia Ukraine

Hi,

On behalf of the board of Wikimedia Ukraine (offwiki discussion) I am requesting to postpone the deployment on wmua:. The main reason is that the new skin is not fit for the chapter wiki:

• We want the sidebar to be permanently visible. It contains valuable information such as account number for donations, links to bylaws, strategy etc. It is a standard to have a menu with such information prominent on NGO websites and not hidden behind a not necessarily recognisable icon.
• We also want to have the logo visible. Not having a chapter logo visible on a chapter website is a major problem (the site might not be perceived as an official one due to the lack of recognisable symbol). While scrolling down, only the page title (usually not containing our name) is visible, having a chapter logo instead would have been beneficial.
• We would hardly ever benefit from content tables instead of the sidebar. Very few reader-oriented pages have TOCs. Some have TOC formats equivalent to grant reports (e.g. wmua:Звіти/2021/Піврічний звіт) so we need to redesign them to avoid redunancy.
• On the other hand, many pages are fit for wider, not narrower screens. For instance, wmua:Вікіекспедиції in the new Vector-2022 has a wide warning box with no content visible without scrolling, while half page of content is visible in the old Vector.
• Overall most additional Vector-2022 features are either irrelevant for an NGO website (search is rarely the most visible box on such websites) or even broken (it has an incomprehensible message about interlanguage links Цією мовою у Вікімедіа Україна посилання на інші мовні версії розташовані угорі сторінки з іншого боку від її назви and a huge Додати мови button in the bottom of the main page, while interlanguage links simply do not exist on chapter websites).

We think that a different design is needed for affiliate websites and such a design needs to be implemented in consultation with affiliates, not enforced. Two weeks cannot be a sufficient time, so please postpone the change until our concerns are addressed. Thanks! — WMUA Vice-Chair of Board, NickK (talk) 22:45, 3 October 2022 (UTC)

As I wrote on the WMUA wiki, we will postpone the deployment there.

Thank you @NickK for letting us know, and thank you for this detailed feedback. I appreciate it. Indeed, it looks like you are trying to achieve specific things for your website as an NGO website, which is a bit different than a community-developed Wikimedia project like Wiktionary or Wikibooks. I'll share your opinion with the team. Thanks! SGrabarczuk (WMF) (talk) 01:57, 5 October 2022 (UTC)

Declining deployment on Ukrainian Wikiquote and Wikinews

Hi, I would like to add a note that per m:Requesting wiki configuration changes there has to be a consensus on the wikis in order to deploy configuration changes there. I have just left my vote against the deployment of the configuration change on ukwikiquote and ukwikinews. Unfortunately no one else has participated in the votes so far, possibly because there was no message in Ukrainian that people could understand. Neither of the wikis currently has the technical capacity to adjust templates, main page, as well as the styles and scripts to accommodate the demands of the news skin. Unless there is a trusted Ukrainian speaking volunteer who is ready to work with the community to do all that work I do not see the changes to be feasible given the current capacity. When it comes to the Wikinews it would also be ill-advised to apply the new skin to older mainspace articles, as those are normally meant to be unchanged. I am not sure that is technically possible though at the moment. --Base (talk) 04:49, 5 October 2022 (UTC)

Skin not enabling for me on mobile web

I have had the skin enabled for about a week now, and wikipedia is still showing the default vector 2010 skin. Clicking 'preview' in the skin change page opens a tab with new skin, but going to any other page in that tab switches back the skin to default. Any ideas on what may be wrong? I am using Firefox on MIUI 12. (Late edit - skin is switched on desktop web.) Squeezdakat (talk) 13:23, 7 October 2022 (UTC)

@Squeezdakat ok, so is this resolved, or is there still something you're confused about? AHollender (WMF) (talk) 21:11, 12 October 2022 (UTC)

Sorry about that confuaing edit. What I meant was - I have it switched in my preferences; new skin is visible on desktop web, but not mobile web. Squeezdakat (talk) 01:53, 13 October 2022 (UTC)

Language links bug

Hello. When editing something and previewing it, the interwikis are shown on the left hand side, not the new spot (h1 header) and it is replaced by fa/ga/fs article icons and coordinates. Toghrul R (talk) 06:56, 8 October 2022 (UTC)

Hey @Toghrul R, thanks for reporting this. Would it be possible for you to add a screenshot? I would like to make sure I fully understand what you're seeing. AHollender (WMF) (talk) 21:10, 12 October 2022 (UTC)

Thumbnails should not appear when searching on Wikisource

Now, thumbnails appear along the results when performing a search. While this feature may be useful on Wikipedia and other projects, it is pointless at Wikisource, because the pages are not associated with any image (try searching for anything you want at en.wikisource.org, for example).

Is there a way to deactivate this feature on a per-project basis? Thanks. Seudo (talk) 19:13, 8 October 2022 (UTC)

For me it is also senseless on wiktionary, because there are many inflected versions of words which dont have images. In general the images are so small, that readers cannot detect something meaningful related to the searched article. I used the following CSS to disable images and to reduce the size of the search results.

/* no thumbnails in type ahead search */
.cdx-thumbnail {
 display:none;
}

/* less padding in search */
.cdx-typeahead-search .cdx-menu-item__content {
 padding-top: 4px;
 padding-bottom: 4px;
}

-- Formatierer (talk) 06:37, 9 October 2022 (UTC)

This is configurable by making a wikitech:Wikimedia_site_requests by requesting a change to VectorWvuiSearchOptions which was likely overlooked when the project was enabled and easily fixed.

Please do not follow the suggestion here of adding the CSS above as that would add technical debt to your local project. Jdlrobson (talk) 19:30, 11 October 2022 (UTC)

Thanks! Apparently someone changed that parameter, because these thumbnails do not appear any more in the search results. They still appear in the type ahead box. Seudo (talk) 10:09, 13 October 2022 (UTC)

Bug: Vector (legacy) Custom CSS seems to apply to Vector 2022

User-specific custom CSS for the Vector (legacy) skin (as in, css added at $WikiUrl$/User:$Username$/vector.css) seems to apply to Vector (2022) as well. This is probably a bug.

You can reproduce this yourself by adding

* {
    color: red;
}

to your vector.css and switching to the Vector (2022) skin. Cuniiform (talk) 22:51, 8 October 2022 (UTC)

I dont think it is a bug, i think it is by design. As far as i found out there is no vector-2022.css or something else. Also there is no vector-2022.js. That is, because both skins are named vector. All configuration has to be placed in the vector... pages. I dont think this was a good decision. An own name for vector-2022 would have been the best to avoid confusion for gadget developers and for CSS configuration. As far as i understood the documentation, you have to use CSS-classes:

skin-vector        for both skins
skin-vector-legacy for Legacy Vector
skin-vector-2022   for Vector 2022 

By the way: Is there a recommended (and stable, not changing every two weeks) way to detect in javascript which of the two vectors the current user is using? -- Formatierer (talk) 07:06, 9 October 2022 (UTC)

Yes, this is by design to minimize impact on communities using gadgets. See phab:T301212.

You can detect which skin you are in using

mw.config.get('skin')

Jdlrobson (talk) 19:28, 11 October 2022 (UTC)

Oh thanks! In the meantime, I think it would make sense to document this behavior somewhere user-facing, like in the preferences menu or on the vector.css page. Cuniiform (talk) 22:49, 11 October 2022 (UTC)

I definitely see a vector-2022.css in the preferences menu on this wiki when I go to Appearance > Skin > Vector (2022) > Custom CSS. Am I missing something? Cuniiform (talk) 22:44, 11 October 2022 (UTC)

Oh, sorry. I didn't noticed, that there are vector-2022... configuration pages. You are right, this is a bug. -- Formatierer (talk) 10:42, 13 October 2022 (UTC)

Kind of auto-selection in search suggestion box

When i use the mouse to click in the search input field to activate it and enter a word, say schöne on german wiktionary, some other words like schönem, schönen, schöner, schönes, etc. are shown in the suggestion box. So far so good. But if i accidently moved the mouse cursor below the search input field before start typing (mouse cursor has to be in the rectangle where the suggestion box will appear) then after typing in some characters the entry from the suggestion box where the mouse cursor is is automaticly selected when i press enter. This is not the case in vector-legacy. In vector-legacy the word typed in is used when pressing enter. The entry from the suggestion box is only used if i move the mouse cursor after starting typing. -- Formatierer (talk) Formatierer (talk) 07:50, 9 October 2022 (UTC)

@Formatierer thanks for pointing this out. I had not noticed this behavior. I agree that it is unexpected. I've filed a task: https://phabricator.wikimedia.org/T320679. AHollender (WMF) (talk) 21:08, 12 October 2022 (UTC)

Votings

I think it's better to do a vote in each wiki and decide if the design should be changed. Аноным (talk) 14:23, 13 October 2022 (UTC)

Completely agree, but I am afraid this will not happen, it seems that some sort of adminstration is forcing all of Wikipedia to be a mobile screen! Sunriseshore (talk) 20:13, 13 October 2022 (UTC)

Please do not make this the defaualt Wikipedia

Please do not make this the default Wikipedia, it will be deeply unfair to all computer users/editors. (Maybe this version can be for the mobile app while others can be exempted). The wide sidebar will force many articles to remove helpful and informative images/media from pages.

My first impression is that this layout degrades Wikipedia from what it is supposed to be. Wikipedia at its heart is a visual and wideranging enclyopedia; not a grab as you go mobile site.

I wish I can find something positive, perhaps the language selection option is in theory, but there are cleary problems with that (from what I have read on this talk page)

Completely oppose the 2022 layout in its current form. Sunriseshore (talk) 20:20, 13 October 2022 (UTC)

Disagree, I think it's much better than the current one.. 80.6.36.48 11:00, 17 October 2022 (UTC)

I edit on a laptop and I strongly disagree

This is a bad idea

The new design is hard to use and it is a downgrade from even the mobile version

Try and fiddle with this new design on an iPad, laptop or something else and you will see

Not bad, just needs work. Ponde99 (talk) 10:34, 23 October 2022 (UTC)

Linking a new article or new category to other languages

I write for the GA Vicipéid (Irish). Often I create new article or new categories. I need to link these to pre-existing ones in other languages. I don't see how this is ppossible any longer with the new skin (instead I go to the pages or categories in English and link back from there to GA).

I am probably missing something very obvious... can you explain to me how to do it ?

In the Vector legacy, on the LHS pane, there is

"In other languages" followed by a list of language, and at the bottom, 'Edit Links'

In the new skin. in the top right, there is a button for language preferences. I don't see how I can 'Edit Links' from here.

I have gone back to the Vector legacy until I can figure it out.

Thanks

TGcoa (talk) 20:12, 15 October 2022 (UTC)

"Athraigh na naisc idirtheanga" in the sidebar

Hi @TGcoa, thank you for your feedback. Links to articles in different languages are collected in Wikidata, where you can add the new link (ex.). To quickly add the link from ag.wp, please click on the link "Athraigh na naisc idirtheanga" in the sidebar. If you can't see the sidebar on the left of the page it means that the menu is collapsed, expand it by clicking on the burger menu on the top left of the page.

The Language engineering team is still working on the "Edit link" in the language button, please read our FAQ for more information. Patafisik (WMF) (talk) 12:46, 20 October 2022 (UTC)

I am sorry.... I don't see any sidebar and I don't see any burger menu, on the top left or elsewhere.

Without the "Edit link", it is far slower for me to edit. Again what I do a lot is add Category and Page links from Irish to English.

Disturbingly, I choose to go back to the legacy. But I was switched back to Vector 2022 by default it seems. TGcoa (talk) 22:21, 24 October 2022 (UTC)

My general impressions (sidebar, TOC, content width)

• I like the modern look and feel overall.
• The TOC sidebar should be collapsible/hideable; I want it to get out of my way most of the time.
• The wiki menu button (≡/« at the top-left, next to the site name) should be sticky (visible even when I have scrolled down the page), so that I can reveal the wiki menu (hiding the TOC) at any time without having to scroll back to the top of the page.
• I use two monitors, one 1280x800, and one 1920x1080. Here are my impressions on the content width:

• On my lower res monitor, the full screen width is used, which is nice, but the content area is still a bit too narrow for my liking. In particular, the TOC is a bit too wide (it could do with less side padding), and the content area a bit too small at 915px. IMO, it could do with being 1000–1050px, and the TOC could do with being made narrower accordingly.
• On the higher res monitor, the lack of use of the full real estate of the screen is jarring to me (as already expressed by many others under "Too narrow (again)"), though I understand and generally agree with the rationale for it being done; it is standard practice on the web for various reasons. However, for an encyclopaedia, I think using the full screen width is completely appropriate and often desired by readers, so I would like to see the option to use the full screen width. I am aware that the wide-vector-2022 gadget exists, which implements this. It would be great if this functionality could be made into a theme-specific setting/toggle, rather than remain a gadget, so that users can easily find it.

JivanP (talk) 23:39, 15 October 2022 (UTC)

Agreed, I would also like to see the full width used, though the current is a major improvement upon before. 80.6.36.48 11:02, 17 October 2022 (UTC)

White article with black border/white text?

First of all, thankyou for improving the width of the page and allowing the shrinkable side bar option, the skin is now acceptable for me to use on both widescreen PC monitor and iPad. Though I would go even further and maximise the full width of the page if possible. For me the all black dark mode is just too dark. What I would suggest is a standard white background for the article text part in the centre but only have the border and article title in black with white text, rather like the old modern skin for the title (which was dark navy). I think having the contrast with a dark frame would make the articles stand out and improve the appearance. I also think somewhere in the middle with grey tones, rather like WikiWand in graphic would be desirable, all black is a bit extreme I find. At least offer for some variations in skin preferences as I've suggested if you insist on keeping an all black page with white text. When you scroll down the page and the article title appears across the top, love that, though I would like to see it dark with white text for contrast and to make the article title stand out. 80.6.36.48 10:59, 17 October 2022 (UTC)

The language selection tab is in the wrong place

In Vector 2022, the language selection tab is to the right of the main headline. That seems off to me, because it's within the content, and it isn't easily seen or found. Also, since it's within the content, with the framing already seen in the language selected, clicking it somehow seems to break the hierarchial buildup of a page: "oh, so, clicking here suddenly even changes the framework".

I believe people are by now used to a kind of hierarchical, top-down construction of pages. The bigger mode changes happen higher up in the page and to the left and go from there. If they are even necessary, and hopefully also far and few between. The first choice of course being what you put in your browser, above and to the left of the page even. If you suddenly have a language switch in the middle of the page, that's almost as annoying as a reload to a different page, or heavens forbid, a sequence of porn-type extra tabs which you cannot back from. Decoy (talk) 18:25, 17 October 2022 (UTC)

Vertical whitespace is being used haplessly

The new, whiter, spacier look in Vector 2022 is rather nice, and comes to style. However, the current version sprinkles text all over the place, without differentianting its actual usage. It does not tabulate stuff that belongs together, together, like the earlier version did. As such, it doesn't guide the reader's eye, towards usablility. It's especially bad because it goes from bold to underlined — something very hard for older people to see, and in all of those variable length parallel lines, contributes to visual clutter.

Please revert to the established idiom of bolding out any condition in the UI in force, and absolutely limit the use of underlining. Also, make sure the typography is kind of rectangular, especially vertically, so that it guides the eye in normal reading order. E.g. the page I last was looking at, https://en.wikipedia.org/wiki/Eating_live_seafood , has an alignment issue from the top of the left-hand-menu towards the heading text.

I'd take something like 1ex off between the top and the menu-/article-top, and in vertical space, maybe a whole 1em between menu and the text. On desktop. Where there was elsewhere talk about rules, I'd cut them to the minimum; hard black lines on a page are almost stupidly visible and salient to the human eye, so that they easily detract from reading and content. They should be used *extremely* sparingly. Decoy (talk) 18:48, 17 October 2022 (UTC)

menu tab, search bar problems

hello,

i activated new vector skin on my wiki, but it still has the old tab menu, i want to have new one that is active on mediawiki (tab menu is being the menu at the top read, edit, history)

and how can i disable images on the search bar results?

Dragsugur (talk) 11:55, 19 October 2022 (UTC)

What version of MediaWiki/Vector? If it's not enabled you likely need to update one of those versions.

You can disable search images:

https://m.mediawiki.org/wiki/Skin:Vector/2022#Config Jdlrobson (talk) 22:49, 28 October 2022 (UTC)

Some Problem on me

In short, if "Header and Footer" feature is activated on Wikisource, this happened. It's also happened in Vector Legacy. It can be fixed by deactivate the Header and Footer feature, but can it be fixed? Thanks. Mnafisalmukhdi1 (talk) 13:19, 19 October 2022 (UTC)

I am not sure what the header and footer feature is. If it's a gadget you will need to raise this issue on its associated talk page. Jdlrobson (talk) 22:44, 28 October 2022 (UTC)

Mystery meat navigation

Mostly a good interface but can we please have labels on the sticky header icons at the top? This is a classic Mystery meat navigation - icons that presume user understanding, with their actual purpose only revealed on mouseover. This is considered to be poor design. At the very least offer labels as a preference setting, so those who wish can continue to enjoy the challenge of navigating by hieroglyphs. Thanks. Cnbrb (talk) 13:51, 19 October 2022 (UTC)

New Vector 2022 logo for Macedonian Wikipedia

@SGrabarczuk (WMF): Hello. I'm B. Jankuloski, bureaucrat and translator at mk.wiki. We received your message for the new localized logo of our wiki (Macedonian Wikipedia, mk.wiki), where you mentioned that you can help us create the new version of our logo to go with the Vector 2022 look. Are you able to do it yourselves, or do you need any help from us? B. Jankuloski (talk) 06:44, 20 October 2022 (UTC)

@SGrabarczuk (WMF) @OVasileva (WMF) Hi there, I`m also user and admin od mk.wiki, and I tried new Vector, and I notice that we did not have "The free encyclopedia" words into Macedonian (Слободна енциклопедија), as we had it on previous version, when logo was complete image with the text below. --Ehrlich91 (talk) 19:22, 20 October 2022 (UTC)

@Bjankuloski06, @Ehrlich91 - thanks for bringing this up! We've now updated the new logo on mkwiki prior to the deployment. Let us know if you have any additional issues or questions with the updated logo and we can follow up OVasileva (WMF) (talk) 13:39, 26 October 2022 (UTC)

@OVasileva (WMF) Can you please check my issue with the creation of the template in the topic below. Thank you --Ehrlich91 (talk) 18:22, 26 October 2022 (UTC)

Is there any option to enable toc to appear same like mediawiki, side bar

I'm trying to figure out how to enable the new TOC, Mediawiki 1.38, with the new skin installed, and enabled vector-2022 as default 86.97.130.4 14:32, 27 October 2022 (UTC)

the new table of contents was added in 1.39 and is being fine tuned in 1.40. Jdlrobson (talk) 22:40, 28 October 2022 (UTC)

So much whitespace wasted in new design

Looks like wikipedia is going from old design to even worser. Why did your designers decided to waste that much valuable whitespace in the new design?! EXAMPLE here Tbartovic (talk) 06:34, 26 October 2022 (UTC)

Consent. It's unaesthetic, impractical and arbitrary. Especially smaller Wikipedias, such as the Slovak one, are at a disadvantage. They have fewer editors, so even if these switch to an older skin, it won't change the overall stats much. Unregistered editors and readers cannot change their skin at all. Also, small Wikipedias often do not have lively discussions on such topics. Editors usually just write articles or discuss topics about them. They don't read the news at the international level. So their opinion do not spread. The announcement in the discussion about the changes written in English is another irony. (which was not even an invitation to a discussion but a simple announcement of a fact and had only one reaction). To sum up: this change affects small Wikipedias, but the creators ignorantly tick off the statistics that the minority is protesting, but it is acceptable minority. Another nail in the coffin of the little Wikipedias. PS: Another irony is that the new skin implemented in Slovak Wikipedia use Czech words (and as I see Czech Wikipedia do not use this skin yet)...----ScholastikosSVK (talk) 10:33, 26 October 2022 (UTC)

I disagree. The old design has extremely long lines on big screens, which makes reading difficult for me. Empty space isn't "wasted" for me, on the contrary, it helps me to focus on the content. I don't understand why people want to use every inch of the screen.

The only thing I don't like is that they use the whitest white for the empty space, which sometimes hurt the eye a little. Stefangrotz (talk) 09:45, 30 October 2022 (UTC)

Proper tagline for srwiki

Tracked in Phabricator
Task T321878
Resolved

Please set this File:Slobodna enciklopedija - Serbian cursive cyrillic.svg for tagline for srwiki it uses Serbian cursive, the current one uses Russian Milicevic01 (talk) 19:53, 27 October 2022 (UTC)

Hey @Milicevic01, thanks for pointing this out and sorry about the error. I've added the updated SVG you provided to the next batch of taglines to be deployed. Are you able to update the file here as well: https://commons.wikimedia.org/wiki/File:Wikipedia-logo-v2-sr.svg (which is where we got the incorrect tagline to begin with)? If not let me know and I can help with that. AHollender (WMF) (talk) 14:50, 31 October 2022 (UTC)

Updated, note its indentical to mkWiki logo Milicevic01 (talk) 23:40, 31 October 2022 (UTC)

Tagline has typo on knwiki

Tracked in Phabricator
Task T321986

Hello , new tagline has typo issue/mis alignment of letter, i have added a mock image of correct tagline at commons:File:Wikipedia-tagline-kn.svg ~aanzx ^✉ _© 02:14, 29 October 2022 (UTC)

@~aanzx thanks for pointing this out. Can you please either convert your SVG to outlines, or provide me with the name of the font used? Since it isn't outlined, and I don't have the correct font installed, I see a different version than I think you are intending. For total clarity here is a comparison of the logo that is currently in Legacy Vector and the one in Vector 2022, along with the one you provided:

kn Wikipedia tagline comparison

AHollender (WMF) (talk) 14:32, 31 October 2022 (UTC)

I used kannada webfont, but you can use https://hindityping.info/download/assets/kannada-fonts-unicode/Lohit_Kannada.ttf or https://hindityping.info/download/assets/kannada-fonts-unicode/Kedage_Bold.ttf ~aanzx ^✉ _© 16:26, 31 October 2022 (UTC)

@~aanzx ok thank you. can you double check the file I added here: https://phabricator.wikimedia.org/T319223#8357478 AHollender (WMF) (talk) 17:41, 31 October 2022 (UTC)

@AHollender_(WMF) , this https://phabricator.wikimedia.org/T319223#8357478 one is correct, thanks ~aanzx ^✉ _© 18:37, 31 October 2022 (UTC)

Zoom level for bgwiki

Hello. Two or three days ago on the Bulgarian Wikipedia has been applied the new Vector 2022 as default. There is a problem when you go to edit source on any page and after that hit "Show preview" button the zoom level changes from 100% to 110% (I'm not sure it is exactly 110%). Can this (I think) bug be fixed? Thanks a lot! 95.87.235.200 09:10, 29 October 2022 (UTC)

Tracked in Phabricator
Task T321883

Zdzislaw (talk) 15:30, 29 October 2022 (UTC)

I'm also having this problem, on enwiki. Neveselbert (talk) 18:33, 29 October 2022 (UTC)

@Zdzislaw thanks for reporting this bug. I am able to reproduce the issue. I will talk with the Editing team about it.

@Neveselbert I am unable to reproduce this on enwiki. I wonder if it might have to do with the version of the source editor being used. Are you able to provide a screen recording of what you are seeing? AHollender (WMF) (talk) 14:55, 31 October 2022 (UTC)

Tracked in Phabricator
Task T321728

Permanetly disable 2022. Vector

I view Wikipedia a lot. I cannot stand the new 2022 Vector interface. It looks and feels very bad. Can I permanently disable it for all MediaWiki sites I am viewing, or at least all Wikipedia sites and languages I am logged into at the same time? And if not, is there a browser extension I can use? Thanks! 2620:9:6000:5800:E584:5E35:B82D:CD69 18:05, 31 October 2022 (UTC)

Ok, I have actually found a solution. There is a browser script manager called Violentmonkey. And there is a script you can get called "Change japanese Wikipedia skin to the previous one". https://greasyfork.org/en/scripts/447684-%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88wikipedia%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%B3%E3%82%92%E4%BB%A5%E5%89%8D%E3%81%AE%E3%82%82%E3%81%AE%E3%81%AB%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B/code

I edited this script using the built in Violentmonkey editor. Where it said

@match          https://ja.wikipedia.org/*

I replaced with

// @match          https://*.wikipedia.org/*

So now on all Wikipedia sites it replaces the garbage and annoying (for me) 2022 Vector theme with the nice and usable (for me) old Vector theme. 2620:9:6000:5800:E584:5E35:B82D:CD69 18:13, 31 October 2022 (UTC)

Thanks for your recommendation!

I'am using the Greasemonkey extension on Firefox with the above script plus your suggested change and it works perfectly. 2001:9E8:463D:A4BA:1CC7:6B70:66AB:CBE7 19:04, 2 November 2022 (UTC)

Well, almost perfectly. The tooltip previews of the articles are now missing. 2001:9E8:463D:A4BA:1CC7:6B70:66AB:CBE7 19:49, 2 November 2022 (UTC)

Localized logo for frpwiki

Hello, could someone help correct the localized logo for the Arpitan/Francoprovençal Wikipedia in the new Vector interface. The global Wordmark Wikipedia should be replaced by the local form Vouiquipèdia and the Tagline needs to be corrected to L’encicllopèdia libra. I’m one of the local administrators of that Wikipedia, years ago I tried unsuccessfully to correct myself the old logo or to find someone able to change it. From then on till now the Arpitan Wikipedia always had only a partially localized logo containing some orthographic errors.

Thanks in advance for the help, ChrisPtDe (talk) 21:10, 1 November 2022 (UTC)

Hi @ChrisPtDe - thanks for flagging this! We can change the logo - I've opened a ticket in phabricator to track the creation of the new logo. OVasileva (WMF) (talk) 12:09, 2 November 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:

• 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.

AllyD (talk) 09:38, 25 September 2022 (UTC)

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)

@AllyD thanks for these questions and apologies for the delayed response. As far as I'm aware the logic for the order of languages displayed in the list has not changed. @Pginer-WMF @Aaharoni-WMF is one of you able to clarify what is expected here? AHollender (WMF) (talk) 21:36, 12 October 2022 (UTC)

Thanks for the input @AllyD.

The language selector uses different clues to figure out which are the recommended languages. Although different factors are considered, those are prioritized. For example, top priority is based on the previous selections. That is, a user that frequently reads in French, Japanese and Igbo would get those always in their suggestions for pages available in those languages. Similarly, the browser languages are considered next if it was not possible to fill the suggestions with the previous criteria. Additional criteria can be considered in cases where it is hard to fill the suggestions because of the languages in which content is available (something which will vary significantly from page to page).

Some of the criteria based on location or relation to content may need some polishing in some cases (data is based on CLDR and can be improved). In any case, as mentioned above, for a user that speaks and uses a given set of languages, in practical terms the suggestions are going to surface those (even if some of the additional suggestions are sub-optimal at times). In contrast, with the classical approach of a flat list, a speaker of a language with low Wikipedia coverage would have to scan long lists of languages to find whether the content is available in theirs (which may not be in mosts cases), and they would have to do that every single time without the system making it easier after the first try.

More detail about the criteria for suggested languages is described in more detail here.

Hope this is helpful to clarify some of the questions about this. Pginer-WMF (talk) 14:46, 7 November 2022 (UTC)

I love Vector 2022

I'm very impressed by the work you've all done and just wanted to post thanks. One thing that jumped out to me was being able to hide the contents bar, and then be able to view it under the title or move it back to the sidebar. Very handy for vertical screens. Frybread (talk) 05:02, 19 October 2022 (UTC)

@Frybread apologies for the delayed reply. Thanks so much for your appreciation. It means a lot to us : ) Cheers, AHollender (WMF) (talk) 22:35, 8 November 2022 (UTC)

I like the new design

I see a lot of negative feedback given by many people above. However, I have to say that I like the new design more than the previous one.

Regarding the narrow page width, I'm not sure if it has been improved since the first comment was left here, but I personally feel that it is the right width for me. Long paragraphs with long lines are sometimes hard to read. If the line is too long, when I finish reading one line and jump to the next line, I may jump to the wrong line. Currently I feel comfortable when I read long paragraphs with the new design.

I think it is a good idea to make use of the white space on the left and put the TOC there. When I am interested in only some part of the page, I can quickly jump to another section without scrolling back to the top and look for the TOC. However, I don't like the TOC sticking at the bottom of the default sidebar (with the "Related pages", "Special pages", etc). It is because when the page is opened, the default sidebar takes up so much space that the TOC is not fully visible. I would like to see the TOC at the first glance, without the default sidebar. I can see that some people who left comments above hate the persistent TOC, so if possible, it would be great to have a user preference so that we can choose to see persistent TOC or persistent default sidebar.

Not sure if additional questions are allowed here, so please ignore it if it is not appropriate. I have just set up a private wiki site with the Vector 2022 skin, but I don't see the TOC on the left. It is still the old style that is near the top of the page (the one since dinosaur era). Is the new TOC not available in the downloadable package yet?

Thank you. Chibiricky (talk) 07:44, 19 October 2022 (UTC)

Hey @Chibiricky, apologies for the delayed response. Thanks for your feedback. We are currently moving the page tools out of the main menu (aka sidebar) and placing them on the right side of the article toolbar. This will allow us to collapse the main menu by default, while allowing editors to still have the tools menu pinned open if they like. It should resolve the issue with the table of contents you mentioned. If you are interested in seeing a prototype check it out here: https://vector-2022.web.app/Moss.

Let me know if that makes sense, and if you have other thoughts. Cheers, AHollender (WMF) (talk) 22:38, 8 November 2022 (UTC)

I'm a fan of the design

Just wanted to leave some feedback in support of the new design, I've been using it for a few weeks and like it a lot! Much nicer on my eyes than the old Vector skin, and it makes the UI a lot easier to follow. Keep up the good work. Nicereddy (talk) 03:12, 20 October 2022 (UTC)

I agree, all things considered, the new design is huge progress for Wikipedia. Stefangrotz (talk) 17:01, 25 October 2022 (UTC)

@Nicereddy @Stefangrotz thanks so much for your kind words. It means a lot to us : ) And very glad to hear that the updated design is working for you both! AHollender (WMF) (talk) 22:41, 8 November 2022 (UTC)

Where can I translate new strings from vector 2022?

Some parts of the menu, for example "Switch to old look" are new strings. I searched for them on translatewiki, but I could not find them. Where can I find them? Stefangrotz (talk) 13:20, 2 November 2022 (UTC)

I found it. The search is just extremly slow, it took more than 10 minutes until it appeared on https://translatewiki.net/w/i.php?title=Special:Translate&group=mediawiki Stefangrotz (talk) 15:32, 2 November 2022 (UTC)

Hello @Stefangrotz. I believe this is the exact group for Vector-related strings. Perhaps some interface messages would remain not translated, but that would be because these are part of different extensions, so different translation groups, too. SGrabarczuk (WMF) (talk) 23:01, 9 November 2022 (UTC)

Auto-collapse TOC?

Hello,

I find the TOC gets in my way. How might I go about making it automatically hidden? Nicodene (talk) 19:01, 7 November 2022 (UTC)

@Nicodene currently you can hide the TOC but it won't remain hidden if you switch to a new article, as you probably noticed. This will be fixed soonish in: https://phabricator.wikimedia.org/T316060. Cheers, AHollender (WMF) (talk) 22:26, 7 November 2022 (UTC)

The day can't come soon enough. Thank you. Nicodene (talk) 21:59, 13 November 2022 (UTC)

Some thoughts after three months use

Switched to new interface quite a while ago, so far so good. I don't think I'm switching back to full-width skins - although, see below, I still have to regularly return to old Vector while editing.

• The most annoying issue with vector-2022 is the uncomfortably wide variety of font sizes. The left-side menu text is uncomfortably small, the heading font is unnecessarily large and, for some unexplained reason, uses serifs. Worst of all is the small monospaced font in the edit window. In practice, I need to mousewheel++ to use the edit window, and then mousewheel-- to get back to text preview. Edit window font must be increased to match main text font.
• Oh, and please fix the glitchy watchlist button.
• Why am I still using old skins? To see what the majority of viewers can see. To check if the page layout looks good in full width, that the illustrations are still reasonably spaced, etc. But there's a deeper, fundamental issue: after switching, my editing habits shifted to shorter paragraphs and shorter sections between headings. Narrow page width certainly imparts a somewhat different style of writing. Which is probably fine for all uninitiated readers, but it looks unfamiliar and undesirable to seasoned editors with 15 years of Monobook-only experience. There were any conflicts around it, but it's certainly not good for cooperative writing.

Retired electrician (talk) 11:42, 1 November 2022 (UTC)

Hello @Retired electrician, than you for sharing this. I'm grateful for your comment. The variety of font sizes is something @AHollender (WMF) has examined, and there was a Phabricator ticket for the watchlist button (can't find it at the moment).

I'd like to address the short/long paragraphs issue. This is an excellent point. It seems that Vector 2022 only sparks this discussion which would be valuable anyway for other reasons.

Those who today are seasoned Wikipedians once developed a certain style which is, I think, similar across many language versions of Wikipedia. Because the font size was small (12px), and because of full width and this encyclopedic style, long-ish paragraphs have been the standard. (Look at: w:MOS:PARA and w:WP:PARAGRAPH. It's interesting that these instructions address the issue of too short paragraphs, but there are no guidelines around too long paragraphs.)

Now, let's consider mobile devices, where the length of paragraphs and sections has always been an issue. The issue you're observing might actually encourage Wikipedians to think of mobile users more often, rethink how they write articles, and write articles that would be good both on desktop and mobile. This is important, especially since many people don't use Wikipedia on desktop, isn't it? But of course, it's a topic for all the Cafes, Forums, Maydans, Village Pumps, etc. SGrabarczuk (WMF) (talk) 05:19, 15 November 2022 (UTC)

I always check the results in Android (both mobile and desktop modes). But, IMO, Chrome-for-Android rendition is much closer to old wide desktop Monobook. Paragraphs that look "normal for Monobook" look just as normal in Android - but excessively long in V-2022. Retired electrician (talk) 06:29, 15 November 2022 (UTC)

Show sidebar by default

Hello, how can I make my sidebar not hide? Iniquity (talk) 14:16, 10 November 2022 (UTC)

Hey @Iniquity. If you’re logged in and uncollapse the sidebar, it will remain uncollapsed on new pages you open. If you’re logged out, your choices aren’t remembered, and it will always be collapsed on new pages. Is my explanation helpful? Do you experience any irregularities? SGrabarczuk (WMF) (talk) 13:28, 14 November 2022 (UTC)

@SGrabarczuk (WMF), hi! :) Yes, it's helpful. But that means it was a bug, because the sidebar was hidden on every new page for me (I am logged in). Now it works, thanks! Iniquity (talk) 13:37, 14 November 2022 (UTC)

@SGrabarczuk (WMF): similar comments are here and here.--Patafisik (WMF) (talk) 15:24, 15 November 2022 (UTC)

Were you on mobile phone by any chance? https://phabricator.wikimedia.org/T321745 is an open bug which might be causing this. Jdlrobson (talk) 17:12, 16 November 2022 (UTC)

@Jdlrobson, thanks for the link, maybe it was from the phone. But now I managed to reproduce another strange hiding.

1. Clear cache

2. Go to Wikipedia

3. Open the sidebar

4. Follow any link very quickly

5. Sidebar hiding Iniquity (talk) 20:09, 16 November 2022 (UTC)

Clicking links quickly will not work. There is an unavoidable delay in saving the preference as navigating away will halt any outgoing network requests and the save must be done via API request. It's also debounced to handle multiple clicks/saves in a short period of time. Jdlrobson (talk) 21:55, 16 November 2022 (UTC)

Giant borders

Hi, I noticed that Wikipedia is advertising the Vector 2022 skin as the "new look", I'm not sure I like it though since the borders are almost twice the size as the legacy skin, making it difficult to find screen items, since less of them appear onscreen at a time. It resembles something I would see on a mobile phone. Zooming out partially fixes this, but as a side effect it makes the text/images on said border shrink as well. Just my two cents. - Coolman2917 (talk) 12:22, 8 November 2022 (UTC)

Hey @Coolman2917, thanks for your feedback. You might be interested in the conversation here: https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Update_on_the_fixed_width_and_white_space, and some of our documentation here: Reading/Web/Desktop Improvements/Features/Limiting content width. AHollender (WMF) (talk) 22:46, 8 November 2022 (UTC)

Oh ok. Thanks! -Coolman2917 (talk) 01:45, 9 November 2022 (UTC)

I'm using it on an 21' Imac Retina display. I know, you discussed this already but still: it just looks like wasting space for nothing and I'm not able to get the overview I would need, to feel myself outside the message, I'm given. I feel like being just thrown right into it, and can't get a Point of view from above (like a neutral one should be). Sorry, I feel very unhappy with it. very POV. Please, please keep the old one. Louise d'Épinay (talk) 22:49, 17 November 2022 (UTC)

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)

Bionic reading has been experimentally tested to be largely ineffective and seems to be a VC cash grab, convincing people of a problem that is not real. Glenohumeral13 (talk) 19:48, 15 October 2022 (UTC)

I have the same problem. Only half the page is filled. And, as I get older, I would appreciate being able to increase the font size (without resorting to Chrome's Ctrl-+) 80.56.112.145 14:16, 8 November 2022 (UTC)

Why should actually using the space require a special gadget?? ☸ Moilleadóir ☎ 05:59, 16 October 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)

Please no. I don't want 28px text on a 1440p screen. Yes, it should be increased to 16px, but no dynamic size. Gugalcrom123 (talk) 16:33, 1 November 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)

Agree. Gugalcrom123 (talk) 16:34, 1 November 2022 (UTC)

I'm sorry but I have to agree with some of comments here - I have a widescreen monitor on desktop and the new format is very disappointing as a whole lot of white space is wasted, and the page is too narrow. Unskathd (talk) 02:53, 26 September 2022 (UTC)

Hey, just joining in to say that conceptually, the 4th prototype is super nice, however only actually displaying anything on 37.5% of a screen & leaving 62.5% blank is not an effective use of space...

On "The popular recommendation is that there should be between 40 and 75 characters per line." - I have measured, and on my display the new version shows 125-150 characters per line, whereas the old version shows 350-400. I zoomed in to the point where it displayed around 50 characters per line, and found it near impossible to read as either the letters had to be too big to read quickly or the width had to be so narrow that it was jarring. This seems like a great idea for mobile, however there is already a good enough interface on mobile, so why turn the pc version into it?

I also think pushing for a "common reading experience" is unwise also - it does help in a few rare situations, however enforcing a system on users because people don't check their formatting correctly is a move in the complete wrong direction. Why not add a preview rendering different screen sizes and resolutions instead? 1rre (talk) 21:44, 13 October 2022 (UTC)

If you created white side areas in order to place ethical advertising (or something similar), this is fine for me.

But please, avoid such foolish justification. 🤦‍♂️

In order to achieve an "optimal line length in reading", I act on my own hardware: first of all, I avoid buying a screen too wide for my own needs; then, I'm going to adjust settings on that hardware (like eye-screen distance and font size). DKDIB (talk) 09:53, 22 November 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)

Maybe make the article resizeable and save it using cookies? Gugalcrom123 (talk) 16:35, 1 November 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)

Strongly agree. Why artificially constrain the width of an encyclopedia, the primary purpose of which is to have high information density? There is nothing wrong with Vector 2010, at least the issues with it are not fixed by Vector 2022. What is the purpose of a floating TOC? Why have so much excessive padding on the navigation menu? The only reason in my opinion is mindless, poorly thought out copying of current design trends in other sites, all of which are not encyclopedias. This is perpetuating a worrying trend on the Web of boxing everything up into little divs with big padding.

I also find the appeal to different studies on reading line length dubious for the reason that they are for newspapers. When reading a newspaper, you want to be led quickly through the story and get on with your day. News writing is supposedly to be clear, snappy, yet still with enough narration/quotes/context that a reader understands the story. Encyclopedia writing is quite different, with an emphasis on completeness and objectivity. Especially since articles can get quite long, limiting the width seems like it could actually make navigating articles more difficult, since they will lengthen considerably.

I really hate to see the entire site essentially waste a giant 4em of padding just for the supposed sake of "readability" (and for the real motivation copying existing UI trends). Who is complaining that Wikipedia is not readable? No one, to my knowledge. This seems to fix something which is not broken. Fixing readability on WP is 99% fixing articles, not UI. Glenohumeral13 (talk) 19:46, 15 October 2022 (UTC)

Also, when did we decide that reading time is even a metric we are optimizing for? No one is trying to speed read Wikipedia. Let readers read slowly and at their own pace without trying to constantly "improve" a dubious metric.

I can only speak for myself but on an internet that is continually trending towards increasing "engagement" and advertising and this and that, I love coming back to Wikipedia (almost daily) to just browse and read something not being fed to me. The "increasing reading time" goal seems to me the first step in ruining this quality. Glenohumeral13 (talk) 19:53, 15 October 2022 (UTC)

At the end of the day, it’s my computer, it’s my browser. If I choose to read lines 10,000 words long that’s none of your business. Unnecessarily restrictive or prescriptive designs are a bad idea. I also can’t escape the feeling that the main motivation here is fashion. This is the default for Facebook, Twitter and even Joomla!, but it fails being truly responsive. It probably makes it easier to downsize the content for a phone, but it makes really poor use of a modern widescreen monitor (as do default font sizes). And suggesting ‘something’ will go in the right column is not a justification for having one.

This just feels still not ready for the real world.

Curious how the “Suggested languages” (translated as “Common languages” in Irish) are decided. When not logged in it offers me Chinese, Irish/English and Italian. I did a very little Chinese many years ago and might be able to follow some Italian, but where’s the French? It’s so random & totally unrelated to my browser settings. Why are you suggesting languages in the first place? Let me choose some, sure, but suggest? ⚜ Moilleadóir ✍ 06:44, 16 October 2022 (UTC)

Without even reading the justification, I can tell you from my personal web site experience of years yonder, every usability study out there tells you text is more readable if the line length is limited. At my [http://decoy.iki.fi] I went with *precisely* the idea that the user would just adjust their screen. Then out of principle I did that too. But only for a while. Eventually I found myself looking at my own site at the full screen width, and so struggling to find the starting point of the next line while reading my *own* text.

I haven't gotten around to changing that, but I really should, and it's nice to see Wikipedia doing that already. Too wide a paragraph, anywhere, really is a usability nightmare.

As for how the pages ought to scale, and look, after that restriction, it's a different matter. Most of the pages on Wikipedia have in fact been written in a fashion which was guided by the old Vector style. They don't look quite right under Vector 2022. Especially, paragraphs now seem overly long, and that's even exacerbated in the intro ones. The TOC is pushed further down the page on the desktop, sometimes making it really difficult to get a hold of an article as a whole.

But I'd say this is an issue of technical debt, which we'll have to just address in the coming years. We just have to rewrite a whole bunch of stuff, to suit a standard which perhaps wasn't there in the early years, or which wasn't followed, as it should have. Decoy (talk) 17:55, 17 October 2022 (UTC)

The problem is not that paragraphs are now the wrong shape (actually with the new theme paragraphs are still somewhat too wide), but that all other content is forced into the same narrow column. A significantly better solution is to limit the width of paragraphs (or other body copy) while allowing data tables to be wider and leaving diagrams/figures in the right-hand margin. –jacobolus (talk) 18:21, 17 October 2022 (UTC)

Totally agree.

I've 20-20 on both eyes but, EVEN WITH THE OLD LAYOUT was already using 125% zoom from desktop for comfort. With this new design there is too much wasted space from desktop.

While consulting wikipedia happens mostly from mobile, when I edit a page or write a new one I always do it from desktop, and the new design is not comfortable both from editor and viewer POV. Dreamaker (talk) 11:00, 18 November 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... —TheDJ (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)

Yes, I would like some grey or light blue background, and maybe even a soft page shadow. Gugalcrom123 (talk) 16:40, 1 November 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)

The new skin is an anorexia of older one to be similar to mobile version. Ed1974LT (talk) 17:37, 26 October 2022 (UTC)

What a weird idea to make the text not use the full space... reverted back and hope this crazy skin will never show up again. 2003:D3:7F40:A500:8821:B2F5:7ABA:7E7C 00:24, 20 November 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)

PLEASE DON'T INCREASE THE TEXT. I can't read 28px. Gugalcrom123 (talk) 16:41, 1 November 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 <main>…</main> 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:

p { max-width: 45em; }
li, dd { max-width: 43em; }
blockquote p { max-width: 37em; }
form p, form li { max-width: none; }‎

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)

What a good idea. Gugalcrom123 (talk) 16:42, 1 November 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)

  I agree, it is just too narrow. Long articles look even longer which may discourage readers from actually reading it (it is really just psychology, like the case of water glasses that have the same volume but different glass shapes make people think one is larger than the other). Please do not waste such a big space on the sides.... Xia (talk) 07:44, 18 October 2022 (UTC)

• I hate being that guy to pile on but it really does seem too narrow on a wide-screen monitor. My only thought is that maybe the font should be bigger and the space on both sides is smaller. That said, I know everyone involved is doing amazing work with a really difficult set of requirements. --Wwahammy (talk) 17:43, 18 October 2022 (UTC)

  Completely agree. I was interested in the new design for about 0.5 seconds until I saw how much space was being completely wasted. Until this is resolved, I (and it sounds like many other people), have no intention of downgrading to the new skin. Avereo (talk) 05:10, 20 October 2022 (UTC)

• Xania is 100% right and I see several similar comments. Mr SGrabarczuk is tone deaf to the criticism he receives, and implemented it on the Afrikaans wiki, for instance, despite a majority of negative replies beforehand. Neither do I believe in his claimed research. It looks and feels like a skin for preschoolers, intended to dumb it down (in the negative sense) for users. Ridiculous waste of space, and interference with the way we work and read, drop down menu that goes over the bottom of my page, juvenescent terminology, and messy, poorly organised and not very visible language links. JMK (talk) 12:19, 22 November 2022 (UTC)