Talk:Reading/Web/Desktop Improvements/Archive4

Move other projects to the sticky header

Hi. I don't know if this is planned, however I leave the following suggestion which seems to me important. With the new sticky header which will soon be implemented —which I encourage— it would be very useful to move “other projects” (distinctly and Wikidata included) next to languages, for several reasons:

• over all, easier and more comfortable access;
• consistency with the languages tab, since it was moved;
• better recommend other projects to readers;
• “frame” templates, such as Template:Sister project links (Q5830969), create duplicate links, are heavy-looking, and often shift the layout: such a new tab would allow to improve the global rendering by making these templates useless.

Thank you in advance for looking into this issue. Best regards — Baidax (talk) 17:35, 4 January 2022 (UTC) (edited)

Hello @Baidax. We're planning to move it to the top, yes. Soon, we'll set up banners inviting volunteers to share opinions on a prototype. Add this page to the watchlist and check it in ~2 weeks. The link should be blue by then. SGrabarczuk (WMF) (talk) 14:29, 15 March 2022 (UTC)

@SGrabarczuk (WMF):  : Thank you for your answer. Awesome, I look forward to seeing it. I also draw your attention to adding Wikidata to this projects list (which is not the case for all language versions). Good luck with the work! — Baidax ^💬 16:31, 21 March 2022 (UTC)

Sticky Header won't switch between language versions

I've just noticed that you've activated the new sticky header in my account on German Wikipedia. Thanks! I think I like it. However, I'm afraid the language selector won't work. I cannot switch between languages in the sticky header. The standard language selector at the top of the page, however, works nicely. I'm running Firefox 95.0.2 on macOS 10.13.6. Thanks and Best regards, Aschmidt (talk) 20:40, 5 January 2022 (UTC)

I think this is T297579 (which will hide the language button in the sticky header). If you want to use languages in the sticky header you will need to go to Special:Preferences and select "Use a compact language list, with languages relevant to you." in Appearance/Languages. Jdlrobson (talk) 23:56, 5 January 2022 (UTC)

Thanks, @Jdlrobson, this is probably true. I'm afraid, I'd rather not use the compact language list because, as an author, I prefer to have all languages displayed in the list. I'd like to see at a glance how many language versions of Wikipedia find a lemma notable. So, I'd prefer if you please could try and solve this issue. Apart from this, I like the sticky header. :) Kind regards, Aschmidt (talk) 00:40, 6 January 2022 (UTC)

@Aschmidt: If you want to see just the amount, I think the compact language links feature is actually good for you: if you enable it, the button on voy:de:Berlin says 21 Sprachen (using old Vector, it lists the 9 most relevant ones—it’s always 9, as long as there are at least 9 languages—, and the button says 12 weitere). So you don’t even need to count the links, the software does it for you. —Tacsipacsi (talk) 12:42, 10 January 2022 (UTC)

Thanks, @Tacsipacsi, for your hints. I'm afraid, I would prefer to be given the direct links to all other language versions, too. I keep the so-called compact language list switched off. Best regards, Aschmidt (talk) 16:42, 10 January 2022 (UTC)

How to disable sticky headers?

Sticky headers really annoy me. There is absolutely no benefit, but just wasting useful space. How can I disable them without switching back to legacy Vector? --Bombenleger (talk) 18:16, 6 January 2022 (UTC)

I also immediately noticed it and came to comment my disdain for sticky headers. My browser already permanently reserves like 3% of my entire screen, now Wikipedia will double that. I don’t need a instant access to any of the buttons in the the header. I search Wikipedia through google, not Wikipedia and that search button is already part of the 3% screen space my browser reserves. I don’t need to be permanently reminded what article I am reading. Most people only speak one language, they do not need to have access to the language switcher 100% of the time. I only check my watchlist once, I do not need access to it 100% of the time, that logic applies to the other buttons in the top right.

Sticky headers are a diet version of toolbar hell from the Internet Explorer days. I really really don’t understand why people keep doing them. Akeosnhaoe (talk) 11:12, 10 January 2022 (UTC)

@Bombenleger, @Akeosnhaoe, you need to add

.vector-sticky-header {display:none;}

to your global.css. SGrabarczuk (WMF) (talk) 13:24, 11 January 2022 (UTC)

thank you @SGrabarczuk (WMF), I love it! Bombenleger (talk) 17:27, 11 January 2022 (UTC)

Sticky header zero language switcher

Hi. Is this really a good idea to create a button "0 languages" that opens a huge empty popup on click on pages with no interwikis? IKhitron (talk) 16:15, 7 January 2022 (UTC)

For that matter, I don't see why the language switcher should be prioritized for the sticky header at all. If a user has navigated to a page and read through it enough to scroll, chances are they're at the language they want to be at. They don't need a prominent button to switch languages from that point. {{u|Sdkb}} ^talk 19:55, 7 January 2022 (UTC)

Courtesy ping SGrabarczuk (WMF) and OVasileva (WMF) {{u|Sdkb}} ^talk 19:58, 7 January 2022 (UTC)

• I think the feature should be scrapped. Apparently it leads to drop of uses of Wikipedias in secondary languages (which ones they are vary by country/region, probably not important for the US). --Jura1 (talk) 20:55, 7 January 2022 (UTC)

The 0 languages is a bug we identified early in testing. That's not meant to show and will be fixed in this week's deploy.

Tracked in Phabricator
Task T298705

Jdlrobson (talk) 03:02, 11 January 2022 (UTC)

Great, thanks. IKhitron (talk) 00:20, 12 January 2022 (UTC)

A problem of cache or someone else?

(from fr.wiki 1 and 2)

Hi, reporting my personal experience, in differents pilot wikis (fr.wikipedia, fr.wikiquote, vec.wikipedia) I was not able to see the sticky header for a while, I need to change accounts, log in and log out 3 times and then refresh the page a lot of times before to see it appear and work. 5th and 6th January I was not still able to see it. Now I can. Actually, there are users on Wikipedia in French (and Wikiquote in French for an individual tester) that can't see the sticky header, Malik2Mars, Paul.schrepfer and Daehan (feedback of 9th January). One of them (Daehan) was able to use the sticky header active when deployed (the 5th January), now he can't, this is strange. There is a reason for that? Thank you for answering.--Patafisik (WMF) (talk) 10:25, 10 January 2022 (UTC)

There's an A/B test running, so 50% of user accounts will not see the sticky header. When that test finishes run you should be able to use it. There was a period while we set up the A/B test where you may have seen it if you do not see it now. Jdlrobson (talk) 02:58, 11 January 2022 (UTC)

Sticky header: issue with fixed-width space for page title

Tracked in Phabricator
Task T298885

The space dedicated for page title is always 500px wide. This number is fixed and therefore long titles will be cut even on wide screens which may look awkward. On the other hand, when the screen is really narrow, the title stays 500px wide and pushes buttons out of the screen. Here is an example. Msz2001 (talk) 15:32, 10 January 2022 (UTC)

Tracked in https://phabricator.wikimedia.org/T298885 Jdlrobson (talk) 02:58, 11 January 2022 (UTC)

Sticky header: language switch button wraps on narrow screens

When using a narrow screen, the language switcher wraps and renders as two lines of text. This looks ugly and IMO should be changed so that the content is always displayed as a single line. Example is here (second image). Msz2001 (talk) 15:35, 10 January 2022 (UTC)

Tracked in Phabricator
Task T298887

Jdlrobson (talk) 02:59, 11 January 2022 (UTC)

Talk page and page history

Tracked in Phabricator
Task T299115

Any reason why sticky is only available on the main page and not on a talk and history pages?

Seems a bit weird to me. Both talk and history have links on the sticky header, but when you navigate to them then the sticky is gone. Especially when I visit someone's talk page I would like to be able to navigate to his/her user page. And talk pages can be quite long. Also if I get an answer here I will get a link to the bottom of this page. And I should see a sticky to be able to open the main page in a new tab or view other notifications. Nux (talk) 22:30, 11 January 2022 (UTC)

Hey @Nux!

1. Talk pages - that's not entirely up to us. The Editing team is responsible for talk pages - see their current project Talk pages project/Usability. They will make the decision whether and how the sticky header will be implemented on talk pages. We're working closely with them on that issue.
2. History pages (also, special pages) - at first, we decided not to enable the sticky header there because it doesn't offer that much functionality (there's no option to edit that page, for example). We'll consider doing it, though. There will be a dedicated Phabricator task.

SGrabarczuk (WMF) (talk) 20:49, 12 January 2022 (UTC

Request to deploy the sticky header in all the namespaces in Vietnamese Wikibooks

Hi, the Vietnamese Wikibooks community is requesting the Web team to deploy the sticky header in all 3 content namespaces. I'm not really active at the Wikibooks so I don't understand why there are 3 main namespaces in it, but they are asking for it. Could it be possible for the team to do this? I'll tag the requesting person for more follow-up info if needed: b:vi:user:Đức Anh. Bluetpp (WMF) (talk) 11:10, 20 January 2022 (UTC)

Drop down menus

If I want to protect or delete a page, or something else, I have to make an extra click to the "Page" actions menu in order to collapse it. I usually delete thousands of pages each year - this means I have to click thousands more times. I am finding this extremely time-consuming. If there is any way to change this, I would really appreciate it. —user:Hasley 23:33, 22 January 2022 (UTC)

Hello @Hasley. Thanks for reaching out. After you wrote to us, we have built a prototype of the new table of contents and page tools menu, the first version of the table of contents, and soon will focus on page tools. See the prototype and, if you have some spare time, follow the instructions and add your thoughts about it. Note that when you check "advanced tools", the delete button becomes directly available. (By the way, do you know that there are keyboard shortcuts for page deletion, protection, etc.? This works across the skins and may save your time.) SGrabarczuk (WMF) (talk) 14:49, 1 May 2022 (UTC)

That works. Thank you! —Hasley 21:02, 1 May 2022 (UTC)

regarding Reading/Web/Desktop Improvements/Features/Limiting content width and transclusion

If recent changes are transcluded this change the page width. Although I appreciate the width-limit and I like the special treatment of special pages, this seems to be not really consistent. I don't really know what could be done about this. Could there be a switch within the transclusion to specify which behaviour is wanted? Though the programming-effort for this will be extremely high, I suppose, because transclusion is effected and not the mere interface. I don't know. Probably it's best to keep it as it is, because it's not a bug, but a (visual) inconvinience? Regards HirnSpuk (talk) 19:11, 23 January 2022 (UTC)

Addition: It looked like it when I hit "show preview" but it's shown correctly after publishing the page. At least for now. Maybe the effect is connected to: phab:T270802? If I notice anything else, I'll post more info. Regards HirnSpuk (talk) 23:07, 23 January 2022 (UTC)

+1: Same happens, when transcluding {{special:prefixindex}}. Slowly it seems to me being a bug? Way to reproduce: edit a page, transclude a special page, show preview. Tested with prefixindex and recent changes. Firefox 96 (64-Bit), no gadgets and stuff. At least it seems not critical. Regards HirnSpuk (talk) 23:16, 23 January 2022 (UTC)

Nice to have: personalized background

Hi, there is my "nice to have" wish. We are discussing about background color of new modern Vector skin. In addition of this, you could leave users personalize their background. Possibly with all images from Commons. Or, if there are technical constraints, you could suggest some background colors and some patterns like those ones or this one (without logo and text) from which to choose. Benefit: no more problems with grumpy comments for the limited width and too much white space.--37.103.19.52 09:16, 24 January 2022 (UTC)

Hello,

• Regarding too much unused space, see my reply in the section above where I've provided links to the prototype and page tools page.
• Regarding too much space of the white color - changing that is already possible. It can be done via a gadget. Solving the underlying issue though (the background being perhaps too bright) may be part of the last phase of the project - visual refinements, which we'll focus on after building the table of contents and page tools. Now, we're making steps "zero" of that phase. Later, we'll probably create another prototype and put up banners asking the communities to share feedback. In general though, we won't offer as the default anything dragging attention from the content :)

SGrabarczuk (WMF) (talk) 16:06, 1 May 2022 (UTC)

Claims about the current interface

I fully agree that the desktop interface doesn't match the expectations of modern web platforms. Wikimedia has always looked quite outdated. But to be honest that's less to do with the structure of the web page around articles, and more to do with the design of articles themselves in my opinion. We can only create plain boring tables, not beautiful tables and articles.

"It is challenging for readers to focus on the content." According to whom? I've never heard this complaint about the desktop experience before.

Completely agree that many people don't know how wikis function. I'd welcome changes to the interface that welcome new editors and make it easier for them.

"isn't consistent with the mobile version", this is worded as though the mobile version is somehow the default. The tone changes if this was written as "The mobile version is not consistent with the desktop version" or "The two versions are not consistent". I just want to be cautious that we shouldn't change the desktop one to match mobile just because it's easier than the other way around when that may not be the best thing for a desktop experience.

Consistency does not meant they have to look exactly the same and function the same. We should not lose the advantages that a certain platform provides (i.e. a wide screen on desktop).

Bit concerned about the claims made in this section. Supertrinko (talk) 01:37, 25 January 2022 (UTC)

Hello @Supertrinko, I'm really sorry that I'm answering to your comment so late. Although three months passed, I hope you'll find my answers useful.

1. "Less to do with the structure of the web page around articles, and more to do with the design of articles themselves" - we agree that both are issues. Our team 1. can't change the latter 2. is technically responsible for the former. We're responsible for over a million lines of code related to skins and interface, so we improve what we've been entrusted with. There could be a coordination around the article (broadly: content) design. But that most likely would not be a mission for our team.
2. "According to whom?" - I recommend digging into the reports presented on the Repository sub-page, especially the Hureo reports. It's not like readers don't know where content is. Rather, it's about the myriad of links and tools making our pages feel chaotic. At the office hours, we use a metaphor of a library vs. a cockpit. We respect that experienced editors lean towards the cockpit, having many links all around, directly available. But the bulk of users, who not necessarily will ever become experienced editors, need a library with clear entry points to the cockpit.
3. "I'd welcome changes to the interface that welcome new editors" - that's great to hear! You may be pleased to learn that we've begun working more closely with the Growth and Editing teams. Our projects are synchronized, and we talk to each other whenever our goals or activities overlap. For example, we're working together on the Edit button available in the sticky header.
4. "Isn't consistent with the mobile version" - good point, the wording might be changed. But why did I use these words, though? It's not about mobile being more important than desktop in principle. Our mobile interface is just newer and better adjusted to the present patterns or expectations than our desktop interface. So it's about what happens to be the characteristics of our mobile and desktop interfaces now.
5. "We should not lose the advantages that a certain platform provides (i.e. a wide screen)" - agreed! Example: we won't leave the currently white spaces empty. As part of the Desktop Improvements, we'll introduce a basic grid system, and put the table of contents and page tools menu on either side of the content. Check out the latest prototype. Later on, as part of the future projects, we'd like to make it configurable per-wiki, perhaps per-namespace or per-page, or even per-user, how exactly the columns/"cells" should be used.

I hope you are a bit less concerned now. Please tell me if anything is not clear. SGrabarczuk (WMF) (talk) 01:37, 6 May 2022 (UTC)

This is not an improvement

At least not at this stage. I just had the misfortune of encountering the "improvements" on the Persian Wikipedia and I have to say it is utterly horrendous to try and use. Aesthetically and functionally displeasing, the new skin does not represent an improvement over the status quo at all. If this change is to be enforced I sincerely hope it is not done in its current state. This is possibly the single most unnecessary set of changes I've seen in my two and bit years of contributing to and decade plus time using Wikimedia projects. I could complain about a lot of the proposals I've seen on this page, but in essence, why are desktop using being given a mobile-esque interface? 5225C (talk) 03:52, 25 January 2022 (UTC)

i agree. after the "improvements" users would have to click a few more times to get to the same links = it's a waste of time and effort. RZuo (talk) 08:19, 25 January 2022 (UTC)

@5225C, thanks for this comment. I'd like to understand your viewpoint better. Could you give more details why you're convinced this is a mobile-esque interface? What else you don't appreciate and why? SGrabarczuk (WMF) (talk) 03:23, 24 February 2022 (UTC)

The two that stick out the most for me (since they are the ones I've encountered) are the collapsible menu and the icons in the top right. Neither of these are in the slightest way problematic. Being able to hide the side menu does nothing in terms of functionality but just makes the top left clumsier. The icons look ridiculous and offer no advantage other than compacting what was a clear and completely unamibiguous menu into a jumble of minimalist symbols.
This is the desktop UI, and no desktop has such a small display that we need to compact all our menus out of the user's sight, which is done on mobile sites in order to maximise useable space. This isn't a problem on desktop devices so it doesn't need a "solution". Most of the other changes follow in this line of thinking, and in my opinion it is a completely misguided attempt to increase usability of the desktop site, forgetting what desktop devices actually are. 5225C (talk) 08:09, 24 February 2022 (UTC)

I find myself in exact opposition to these points: I find it quite useful to be able to minimize the items that I use very rarely, in favor of having screen space for the contents that I actually am interested in, whether I am reading the encyclopedia, or performing some work on it. Similarily, I always make my GUI hide its "status line", for the excellent reason that I need it only 0.something % of the time, and so it would be a complete waste of screen space 99 % of the time. So, I might suggest that UIs might need to take into account that we are obviously not all of the same mind and working habit, so that HAVING a few choices might be in order... Autokefal Dialytiker (talk) 18:51, 26 April 2022 (UTC)

Side panel on Wikidata item pages is forced to bottom of page

@SGrabarczuk (WMF) and OVasileva (WMF): Hello, not sure exactly what the state of deployment is for this (i.e. if all latest changes are deployed everywhere), but was trying it out on Wikidata (where I primarily edit) and the div classed as wikibase-entityview-side on item pages (which houses all the sitelinks) is pushed down to the bottom of the page (see wikidata:Q1 for example).

In legacy vector this element is at the top of the page on the right hand side, which seems more appropriate given the importance of the information (as a means to access the subject on other wikis) and the clearer separation from the data statements. I don't think it necessarily has to live in the same place, just that the current placement seems incorrect, especially considering how much scrolling is needed to reach it on some item pages. --SilentSpike (talk) 12:25, 25 January 2022 (UTC)

@SilentSpike: Oh yeah, the infamous limited content width. On my 1366×768 screen (minus a few pixels of vertical taskbar), sitelinks at the bottom with legacy Vector as well. The limited content width of new Vector forces this layout even on gigantic iMacs. (By the way, you can see the very latest version on beta cluster, every change that’s been merged immediately appears there.) —Tacsipacsi (talk) 13:19, 25 January 2022 (UTC)

Thanks for the bug report.

Tracked in Phabricator
Task T300182

Jdlrobson (talk) 18:53, 26 January 2022 (UTC)

Some Feedback on Improved Desktop View

Thanks for working on this project. I just recently switched to the Improved Desktop View and I'm loving it! It provides a cleaner and much better reading experience for me.

Just noted one issue which I wanted to mention here. I have the clock gadget enabled. When I open the "User menu" when the page isn't scrolled at all, the clock gadget appears to be part hidden [ screenshot ]. When the "User menu" is opened after the pages is scrolled a bit, the clock appears to be fully visible [ screenshot ]. One could actually argue the clock gadget shouldn't even be hidden under the "User menu" as it kind of makes the gadget less useful but I'll not get into that now. :-)

Thanks again for working on this! -- Kaartic ^[talk] 08:53, 26 January 2022 (UTC)

Fixed on wiki. Jdlrobson (talk) 18:46, 26 January 2022 (UTC)

Bug: Sticky Header is printed

When printing out a page the sticky header is included. Regards HirnSpuk (talk) 09:54, 26 January 2022 (UTC)

THanks for the report!

Tracked in Phabricator
Task T300178

Jdlrobson (talk) 18:12, 26 January 2022 (UTC)

Not at all suitable for Wikisource users

See also: wikisource:it:Wikisource:Bar/Archivio/2022.01#Aggiornamento_sulle_migliorie_all'IU_desktop_e_invito_ad_un_incontro_on_line

As other people have said, the editing box is too narrow. This is especially bad for Wikisource users, as most of the work happens in the Page: namespace. Probably no one ever thought of trying it out there. Just open a random page on en.ws and try to edit. As you can see, half of the page is occupied by the scanned image, and the other half by the editing box. As the scan is often large and hard to read, we need it to be as big as possible. And we need the editing box to be as big as possible. You are wasting a lot of screen space and making things difficult for Wikisource users. I respect your work, but it's very clear to me that no one ever thinks about sister projects when planning these changes. Every decision seems to be based exclusively on what Wikipedia needs, the other projects are never taken into account. Candalua (talk) 08:33, 28 January 2022 (UTC)

I strongly support Candalua's claim. Proofreading has specific requirements, and it needs a specific. stable editing interface and specific tools and shortcuts. Just an example: Find & Replace tool doesn't run, from years, into nsPage environment; it.wikisource built an its own powerful tool, but such "divergent evolution" of projects is IMHO a bad thing. Alex brollo (talk) 10:56, 31 January 2022 (UTC)

The problem here is the use of different namespaces. We've been testing on English Wikisource which does not have the fixed width you pointed out. It seems English Wikisource uses namespace 104 and Italian uses 108. We'll look into fixing this. Thanks for the report.

Tracked in Phabricator
Task T300563

Jdlrobson (talk) 18:34, 31 January 2022 (UTC)

Hello @Candalua and @Alex brollo. Thanks for contacting us.

We know how our changes look on Wikisource. For example, I have them enabled on all wikis (as a global preference). We know that you need the width to be long while editing the Page namespace. I guess there are two reasons why we haven't adjusted our changes to your specific needs:

1. No Wikisource has been one of our pilot wikis
2. To set up the long width exception, we need to know the number of the namespace. On different Wikisource wikis, the Page namespaces have different numbers. :O This is most surprising and irregular. We have to go through all Wikisource wikis and find out where the local Page namespace is.

Regarding #1, we are open to change that! If your community is agrees to join the pilot wikis, we'll work together more closely, and identify more bugs. We know that we will have to work with Wikisource wikis before we consider our changes as ready, anyway. What do you think? SGrabarczuk (WMF) (talk) 18:41, 31 January 2022 (UTC)

@SGrabarczuk (WMF): @Alex brollo: on it.wikisource suggests to have a pilot wikisource, like fr.source (the leader wikisource) or a very little wikisource, but with experienced contributors like vec.source with @Candalua or nap.source with @Ruthven. Patafisik (WMF) (talk) 11:10, 2 February 2022 (UTC)

Please remove the bar at the top, which appears when I scroll down

Please, I hated it. Or at least allow me in the preferencer to deactivate it. I don't want to see that. Please remove. Bageense (talk) 19:54, 31 January 2022 (UTC)

@Bageense: You mean the sticky header? Have you tried switching back to Legacy Vector? NguoiDungKhongDinhDanh (talk) 19:56, 31 January 2022 (UTC)

@NguoiDungKhongDinhDanh: No, I haven't, because I don't want to use the lecacy Vector, I want to use the new one, but without the header. Please remove that, or at least allow me to deactivate it. Please remove that. Bageense (talk) 20:19, 31 January 2022 (UTC)

I can't find that checkbox anywhere in Preferences so we'll probably have to wait for the team's reply. NguoiDungKhongDinhDanh (talk) 20:21, 31 January 2022 (UTC)

Hello @Bageense, you will find the code that removes the bar in the How to disable sticky headers? section. SGrabarczuk (WMF) (talk) 08:03, 1 February 2022 (UTC)

@SGrabarczuk (WMF): Thanks! Sorry if I seemed a bit exasperated, hah. By the way, I love the new skin, unlike literally everyone I interact with in the Portuguese Wikipedia. The skin is much more modern-looking, cleaner, the articles are easier to read. There are way less visual distractions, such as lines and borders. It's awesome. Cheers! Bageense (talk) 06:10, 3 February 2022 (UTC)

Easier to read when you have to scroll more times? --NGC 54 (talk | contribs) 12:41, 3 February 2022 (UTC)

Yes, @NGC 54, even if one has to scroll more, one may be focused more on a specific part of content, like a sentence, a paragraph, etc. Have you maybe read this explanation? SGrabarczuk (WMF) (talk) 02:21, 17 February 2022 (UTC)

I think that is not impossible to let the reader adjust the width. --NGC 54 (talk | contribs) 11:05, 17 February 2022 (UTC)

@NGC 54, our goal is to provide the best experience as default. Tech-savvy users are always able to change their CSS and create something dramatically different from the default version. This won't change this time either. SGrabarczuk (WMF) (talk) 02:48, 24 February 2022 (UTC)

But the best experience is not with limited width. Wikipedia is an encyclopedia, the text being the most important element. --NGC 54 (talk | contribs) 23:36, 24 February 2022 (UTC)

Live preview broken on 2010 wikitext editor

Tracked in Phabricator
Task T300814

File:Vector-2022-preview-problem.webp (direct link)

I'm using English Wikipedia but around 1–2 hours ago, I started experiencing some rendering issues when clicking the Show preview button when in 2010 source editor as seen in the attached video above. My global preferences is currently set to Vector (2022) theme, previously set to Vector theme with legacy option unticked, I believe Vector (2022) is the new name since I didn't change anything in my preferences.

So I rechecked on Korean Wikipedia (which was stated as one of the few Wikipedia where the changes are turned on by default) and the same issues occurred.

Please rollback the changes as this isn't ready yet, not sure why it's even push onto production server. — Paper9oll 07:49, 3 February 2022 (UTC)

This should be fixed now. The fix here however led to further Talk:Reading/Web/Desktop_Improvements#Broken_gadgets. Jdlrobson (talk) 23:25, 4 February 2022 (UTC)

Scrolling by pages + sticky header scrolls too far

Tracked in Phabricator
Task T307027

Steps to reproduce:

1. Use Firefox. (Chromium might behave the same, but I haven't tested.)
2. Scroll to the top of the page, so that the sticky header isn't visible.
3. Note where the text is cut off at the bottom, by the edge of the viewport.
4. Hit the 'page down' key.
5. Wait a moment for the the sticky header to appear.
6. Note where the text is cut off at the top, by the sticky header.

Expected results:

There would be some overlap between the text visible at the bottom before scrolling and the text visible after scrolling, so that you don't need to manually scroll up with arrow keys to re-find your place.

Actual results:

The sticky header obscures the overlapping text and effectively scrolls too far, going past some text that was not visible before to scrolling.

Ping User:SGrabarczuk (WMF) - this is pretty annoying and I would like for it to get tracked somewhere, please. FrankSpheres (talk) 21:47, 7 February 2022 (UTC)

This seems to have been fixed at some point in the last few months and no longer reproduces. Thank you. FrankSpheres (talk) 04:10, 10 May 2022 (UTC)

Enable sticky header

Sorry for the stupid question, but in which wiki is the sticky header enabled? ValterVB (talk) 08:53, 3 February 2022 (UTC)

Not a stupid question at all. Thanks for asking it.

It should be enabled on all wikis. You must however be logged in, and using a modern browser with a display resolution of 1000px or greater.

Let me know if you are having any trouble seeing it, if so we'll work out why not. Jdlrobson (talk) 23:19, 4 February 2022 (UTC)

@Jdlrobson: I'm on it.wiki, but is the same also in fr.wiki or en.wiki, and I use Vector (2022). I can see the new desktop lay out, but the header isn't fix. I use last version of Edge Browser and display resolution is 1920x1080. ValterVB (talk) 08:25, 5 February 2022 (UTC)

Strange, now it work.... ValterVB (talk) 08:58, 5 February 2022 (UTC)

Is normal that don't work in all namespace? ValterVB (talk) 09:22, 5 February 2022 (UTC)

Glad it's working! See Talk:Reading/Web/Desktop_Improvements#Talk_page_and_page_history :-). Hope that helps! Jdlrobson (talk) 05:23, 8 February 2022 (UTC)

Text in certain dropdown menus displays over sticky header drop down menu, and time is misaligned

Hello! So I started using the 2022 Vector skin yesterday and I noticed that if I'm scrolled all the way to the top and click on the dropdown menu on the sticky header, some of the text for other dropdown menus (such as the page dropdown menu) displays over the sticky header. Also, within the dropdown menu, the time is cut off, and therefor not completely displayed. Blaze Wolf (talk) 12:04, 3 February 2022 (UTC)

For the time gadget, I assume you are using the UTC live clock gadget, in which case you should discuss it on MediaWiki_talk:Gadget-UTCLiveClock.js. On MediaWiki.org and eu.wikipedia.org it has been modified to appear outside the user dropdown but Wikimedia Foundation doesn't make decisions about how gadgets should behave. Right now the gadget is appending itself to this menu. I'm not sure if that's a bug or intended.

Thanks for flagging the issue with the more menu, I've notified the gadget developers: https://github.com/wikimedia-gadgets/MoreMenu/issues/24 Jdlrobson (talk) 23:18, 4 February 2022 (UTC)

Broken gadgets

Both Twinkle and the short description helper gadget seem to have broken today on New Vector. All the Twinkle options (Warn, Wel, etc.) are displaying in a bulleted list rather than collapsed in a menu, and the short description helper is not appearing where it normally would below the title. Are these known issues, and can they be expected to be resolved shortly? {{u|Sdkb}} ^talk 21:25, 3 February 2022 (UTC)

For me, Twinkle is not displaying in its own dedicated dropdown menu (TW) but consolidated into the standard More menu on Vector 2022 but styling are retained. When loading/refreshing, I can see the space reserved for the TW dropdown menu to the right of More menu but once done loading/refreshing, the reserved space just disappear with the entire #right-navigation moving right which is the default CSS behavior since TW is not found in the source after loading/refreshing but was there when loading/refreshing. Short description helper gadget is completely broken for me, it doesn't display at all on Vector 2022. Paper9oll 01:29, 4 February 2022 (UTC)

Please direct gadget developers to phab:T300987 which has instructions on how to address any problems they are seeing. I believe Twinkle has already been fixed. Jdlrobson (talk) 23:06, 4 February 2022 (UTC)

Example at w:Georgetown University

Woah. Another big change that seems to have been rolled out yesterday is that coordinates that used to be in the upper right seem to have been pushed down in infoboxes, producing some horrible-looking results. See e.g. w:Georgetown University, where it produces the same thing twice and pushes the infobox wider than it should be because there's no line breaking.

I've never heard a compelling case for why language switching is so important that it needs to commandeer the corner there. But when it disrupts existing articles by creating things like this, that creates work for the community to fix that I don't think folks will be happy about. Does anyone know what specific change caused this, and whether it will be fixed before wider rollout? {{u|Sdkb}} ^talk 18:57, 4 February 2022 (UTC)

Tracked in Phabricator
Task T281974

This is a longstanding issue, that's been documented for some time and is waiting on changes by template admins on English Wikipedia. These were previously overlapping text (see https://phabricator.wikimedia.org/F34441718), so this seems like an improvement to me :) Coordinates are rendered by wikitext templates NOT MediaWiki code.

This conversation is currently happening here: w:Wikipedia:Village_pump_(technical)#Coord_not_displaying_correctly Jdlrobson (talk) 23:03, 4 February 2022 (UTC)

Language switching - speed, suggesion

The language switching location is great, I think you can put a button in the sidebar that jumps and highlights the new placement. But problem is now I have to click twice to change to a suggested language and suggesions don't work in no JS mode. I think it could atleast suggest my browser language in no-JS mode. The suggesions aren't good too. For example visiting the Lata Mangeskar page, I have my browser language set in Bangla and connecting from a Bangla region, yet the suggesion doesn't show that option(with js on). Greatder (talk) 15:11, 7 February 2022 (UTC)

Thank you @Greatder for this comment.

1. Regarding a button in the sidebar, can you see the text এই উইকিতে, ভাষার লিঙ্কগুলি পাতার উপরের দিকে নিবন্ধের শিরোনামের পাশে রয়েছে। উপরে চলুন। at the bottom of the sidebar, where language links used to be?
2. Regarding the speed and suggestion, our team "only" displaced the list of language links to the top of the page. We only did the interface part. Other aspects, like those two, may be up to the Wikimedia Language engineering team. Uzoma knows more about that team's activities.

SGrabarczuk (WMF) (talk) 02:45, 24 February 2022 (UTC)

1.Yup! That's a welcome change. 2. @UOzurumba (WMF): Hey, will you be able to check the language suggestion part? Greatder (talk) 08:29, 24 February 2022 (UTC)

Thank you Greatder, for pointing this out, I will notify the Language engineering team. UOzurumba (WMF) (talk) 11:00, 24 February 2022 (UTC)

Hello Greatder,

About the language switching speed, There are plans to work on the language selector to use the Vue modern technology and it should improve it.

This page describes the different criteria used for selecting languages. Previous selections are the top criteria, so those may make the results provided to be different from user to user.

I hope the above answers your questions. UOzurumba (WMF) (talk) 19:22, 24 February 2022 (UTC)

User menu and language switcher is not working in some condition.

Tracked in Phabricator
Task T302031

Hello, I have a feedback regarding new vector user experience. There are a user reported on WP:HELPDESK (at Thai wikpedia) that they cannot toggle on "user menu" and "This article in other language" button when disabled JavaScript, I myself don't know why too and when tested myself it just work. They use Mozilla/5.0 (X11; Linux i686; rv:25.8) Gecko/20151123 Firefox/31.9 PaleMoon/25.8.1 if it is needed. If you wanting more context or want translation, or have a ticket related, feel free to ping me here. Thanks!

See full feedback on: w:th:special:permalink/9910984#ปัญหาการใช้ธีมใหม่ของวิกิพีเดียภาษาไทย_โดยไม่มีจาวาสคริปต์

Patsagorn Y. (Talk)

07:51, 8 February 2022 (UTC)

We'll reply on Thai Wikipedia. SGrabarczuk (WMF) (talk) 21:05, 17 February 2022 (UTC)

Default image thumb size?

@SGrabarczuk (WMF), at this discussion back in 2020 about increasing the default image thumb size, you mentioned that you'd bring it up with the Desktop Improvements team. I'm considering resurrecting that discussion, so I was wondering if you recall how that discussion went, or if you have any more general thoughts about the possibility of larger default images?

Looking at it, one obstacle seems to be the 0.1 megapixel limit for fair use images. I'd be interested to hear from someone at WMF Legal about whether that limit has a legal basis or was just chosen arbitrarily at some point; do you know who I could ping to ask about that? {{u|Sdkb}} ^talk 22:30, 8 February 2022 (UTC)

It's been some time since you added this question @Sdkb, and we still don't have a good answer YET, so there's an initial one:

since 2019, we've been only working on changes that are on the list of Desktop Improvements. We are only working on the interface. Image thumb... doesn't turn out to be "just interface". Its default size is in the same category as the charts, maps, a-/f-/o-/tmboxes, infoboxes, navboxes, and other templates thing.

We're figuring out which team should be responsible for this area. I know this may look bureaucratic but it's about who is committed to be familiar with the related code and committed to make decisions about its development.

Also, what Whatamidoing wrote back then is still accurate - the Technology folks are going to have a word in that discussion. SGrabarczuk (WMF) (talk) 01:51, 24 February 2022 (UTC)

@SGrabarczuk (WMF), thanks for the update! Yeah, I think there are a lot of things that don't fit neatly into a particular WMF team's purview, and it's often hard to figure out where to send them. {{u|Sdkb}} ^talk 02:08, 24 February 2022 (UTC)

La nueva interfaz es muy incomoda de usar.

No fue hace unos días en la que entre a Media-Wiki y me encontré con una interfaz bastante rara y incomoda, por el hecho de que parece otro sitio web. Tornitiu (talk) 02:41, 12 February 2022 (UTC)

Hola, @Tornitiu. Me alegra que hayas encontrado esta página de discusión. Sí, este sitio web se ve diferente porque nuestros equipos están extendiendo la nueva interfaz a más y más sitios web de Wikimedia. ¿Te gustaría compartir más pensamientos? (I'm glad that you have found this talk page. Yes, this website looks different because our teams is extending the new interface to more and more Wikimedia websites. Would you like to share more thoughts?) SGrabarczuk (WMF) (talk) 01:57, 17 February 2022 (UTC)

How do I go back to full width?

Useskinversion=1 stopped working. 46.188.156.161 06:22, 14 February 2022 (UTC)

Hi @46.188.156.161, thanks for your question! We have made some technical changes due to which the new and old versions of the Vector skin are now separate skins. The new url parameters are as follows:

- Legacy version of the Vector skin (2010): ?useskin=vector

- New version of the Vector skin (2022): ?useskin=vector-22

OVasileva (WMF) (talk) 12:34, 14 February 2022 (UTC)

Thank you 46.188.181.249 18:33, 16 February 2022 (UTC)

Custom TOCs, TOCright and other templates that change the position of/remove the TOC

Copied from Topic:Wqeyb0m05zkmeemb

Well, I have a few questions:

• Can you still hide the TOC (using __NOTOC__ and similar)?
• How about templates that change the position of the TOC (like {{Tocright }} and similar)? Will they still work?
• Can you undock the TOC from the sidebar?
• Can custom TOCs be repositioned to the sidebar?
• What will happen when you "emulate" a TOC, like a custom version that uses the TOCs classes (toc)?

SuperDragonXD (talk) 02:45, 21 February 2022 (UTC)

Hi SuperDragonXD, we're working on details and soon I'll give answers. Basically, we know what settings exist now, perhaps we'll create new magic words, and definitely we'll keep/provide some configuration options. SGrabarczuk (WMF) (talk) 02:01, 22 February 2022 (UTC)

Regarding NOTOC, that will continue to work, however the other magic words e.g. tocright will have no effect.

Regarding undocking the TOC from the sidebar, that seems unlikely from a technical point of view, as that would add a lot of caching concerns. Same goes for custom TOCS. Custom TOCs exist in the article content not the sidebar, but as Szymon suggests in his reply, we could perhaps create new magic words to allow that in future.

In terms of emulating a TOC, could you give me an example? Note the styles associated with the existing table of contents will disappear with the new table of contents design, so it would be good to identify any problems prior to roll out. Jdlrobson (talk) 00:24, 24 February 2022 (UTC)

Inter-language links

Tracked in Phabricator
Task T289840

In Vector legacy, an "Edit links" option just below language list takes us to the appropriate section of connected Wikidata item allowing us to (dis)connect articles from other Wikipedias. However, under the Vector 2022 skin, it appears as just another link "Edit inter-language links" in the tools section of left sidebar, far from the new language list. I hope that going forawrd "Edit (inter-language) links" will be brought closer to the language list. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 23:02, 23 February 2022 (UTC)

Hello, @CX Zoom. It will, you are correct. This is a task for Language engineering, so a different team working on a different set of projects. You can learn more details on Phabricator, the link is in the box. SGrabarczuk (WMF) (talk) 01:15, 24 February 2022 (UTC)

The empty TOC box

Hi. Is there something new with the empty TOC box bug? Thanks. IKhitron (talk) 13:52, 26 February 2022 (UTC)

Somebody? @SGrabarczuk (WMF)? The Desktop Improvements stopped working a week ago. IKhitron (talk) 03:10, 1 March 2022 (UTC)

Hello @IKhitron. Could you share more details: on what page you experience this problem, what browser and OS you use? We'll need to figure out if this problem is related to the Desktop Improvements in the first place. SGrabarczuk (WMF) (talk) 11:35, 9 March 2022 (UTC)

Hello again, @SGrabarczuk (WMF). It's phab:T302461. Since the last time I was here, it was declared as "Unbreak now!" and fixed. IKhitron (talk) 11:59, 9 March 2022 (UTC)

Unable to switch back to Vector Legacy skin

I clicked "switch to old look" on any wiki site. However, the skin is still new Vector. I tried refreshing and using the Ctrl + F5/refresh. That didn't help much. George Ho (talk) 05:03, 10 March 2022 (UTC)

Hello @George Ho. What did you see when you clicked "switch to old look"? SGrabarczuk (WMF) (talk) 14:11, 15 March 2022 (UTC)

Still New Vector skin. George Ho (talk) 14:13, 15 March 2022 (UTC)

It's not as clear as it could be but you also need to select "Vector legacy (2010)" and hit save to complete switching to the old look. Jdlrobson (talk) 22:32, 15 March 2022 (UTC)

Oops, I should have detailed that. Tried to select that option, but that still led me to new Vector. Tried that again and again. Still New Vector. --George Ho (talk) 16:19, 16 March 2022 (UTC)

Yeah, I meant what page you see. @George Ho, after selecting "switch to old look", you should be looking at the preferences. Clicking "switch to old look" isn't enough because this link only sends you to the preferences page where you need to make more steps. SGrabarczuk (WMF) (talk) 15:24, 16 March 2022 (UTC)

It might be worth checking global preferences too. There is a conflict between the two under certain circumstances that we are trying to fix. Jdlrobson (talk) 16:27, 16 March 2022 (UTC)

Let's talk about our latest prototype and next steps

To everyone who is watching this page but hasn't subscribed to our newsletter yet:

Join an online meeting with the team working on the Desktop Improvements! It will take place on 29 March at 18:00 UTC on Zoom. Click here to join. Meeting ID: 82719061969. Dial by your location.

Agenda

• Update on the recent developments
• Presentation of the latest prototype
• Questions and answers, discussion

Learn more about the office hours. See you! SGrabarczuk (WMF) (talk) 02:11, 26 March 2022 (UTC)

How is the progress of 2 phabricator tasks?

I see the news, but the older phabricator task are not fixed in real product:

• 76 items in notice group doesnt mark as read.
• Long username/language labels leads to horizontal scroll bar on meta on 1000-1200px threshold

✍️ Dušan Kreheľ (talk) 18:49, 28 March 2022 (UTC)

Hello! Considering the tags, the first task is assigned to Growth, a separate team, not Web. Only the second task is ours. I'll let our designer know that you're asking about this. Generally though, this task might not be a priority because we now focus strictly on the features of Desktop Improvements, and visual tweaks of different types will be a priority next. SGrabarczuk (WMF) (talk) 14:21, 29 March 2022 (UTC)

@SGrabarczuk (WMF) First ok.

Second, is it so hard, to give this code into CSS @media screen for interval with bad width screen size? Dušan Kreheľ (talk) 13:02, 4 April 2022 (UTC)

Hm, with @media used is drawing bad with width under 720px. Dušan Kreheľ (talk) 13:26, 4 April 2022 (UTC)

Keep the sidebar collapsed as default

Tracked in Phabricator
Task T305668

I volunteer at Wikisource. Most of my work is done at the Page namespace, and there the sidebar works better collapsed. Every time I open a page for proofreading I need to collapse the sidebar again. Please make it so it stays as I last left it (collapsed or shown). Ignacio Rodríguez (talk) 01:32, 1 April 2022 (UTC)

I think it would be even more annoying, especially when one uses multiple tabs (if you need to open it and then open a new tab, it’s uncollapsed, but if you close it, it would be collapsed again on the next tab). Probably a preference would be a better solution: if you set it to collapsed in your preferences, it’ll be collapsed on all pages unless you manually uncollapse it, but even then, it’ll be collapse on the next page again. (And since it already differs between logged-in and logged-out users, many of the points in Just make it a user preference don’t apply here.) —Tacsipacsi (talk) 13:59, 2 April 2022 (UTC)

Whatever, just make it optional. The workflow at Wikisource is different than Wikipedia, and I prefer collapsed every single time I am proofreading. If I need something on the sidebar (seldomly) I'll uncollapse it. Now, I think it is more intuitive to be able to change quickly between the two modes. Sometimes I'm proofreading, then I need wide space to read more easily. Sometimes I'm doing manteinance, then I need the sidebar more often.

Maybe we need to have the option to control that behaviour (Even if it's a gadget. Unfortunately, I am very bad at javascript so I can't do it). I can think 3 behaviours:

1. Always on (default)
2. Always off
3. Remember the last one

What do you think, @SGrabarczuk (WMF)?? Ignacio Rodríguez (talk) 14:59, 2 April 2022 (UTC)

If I recall correctly, according to the current settings, the state of the sidebar (collapsed/not collapsed) is persistent. This means - if you collapsed it, it should stay collapsed on the page you open next. This should be the solution, and I'm not sure why you experience anything else :/ SGrabarczuk (WMF) (talk) 15:52, 4 April 2022 (UTC)

@SGrabarczuk (WMF) I just tested it: it isn't persistent, it's uncollapsed by default. On several wikisources/wikipedia, both with my main account and the tests one, both with my gadgets and with every default setting. It most definitely isn't persistent. Ignacio Rodríguez (talk) 16:11, 4 April 2022 (UTC)

Excuse me if I'm being a little too persistant, but are you going to check on this please? Ignacio Rodríguez (talk) 18:41, 7 April 2022 (UTC)

No worries! Yes, I asked my colleagues and they said there must be a bug. Thanks for reporting it! Click the link in the box to see the details. SGrabarczuk (WMF) (talk) 00:47, 8 April 2022 (UTC)

More visibility for Wikimedia and Wikidata

Based on (BTW, nie job, congrats!)

https://di-article-tools-2.web.app/Blauwal?de

I strongly suggest

(a) to move Wikidata to section in "In anderen Projekten" as the "normal user" expects Wikidata in the list of other Wikipedia projects, as it's part of the Wikipedia family and not somewhere in tools. And

(b) to add the relevant icons to the projects name as in the French language Wikipedia. Thus the family of other projects becomes more visibility and might attract users.

Finally, I suggest

(c) to shorten "Wikimedia Commons" to "Wikimedia". The term media is understood in many languages, but the expression "Commons" is not really "straight"; as a consequence, if used as an adjective with Wikimedia it should be used with all other project names as well, what would make the whole story worse, thus act in KISS spirit.

In a nutshell: Make Wikipedia family more prominent and use understandable terms for users

Thx for your work and your attention

Link: https://www.deepl.com/translator#en/de/Commons%0A%0A

cheeers, AnBuKu (talk) 22:21, 6 April 2022 (UTC)

Thank you @AnBuKu for your appreciation.

1. Wikidata link is there temporarily. We (Web team) are responsible for the most part of the interface, and Language team works on language-related links such as the Wikidata link. We have received research revealing that readers and new editors don't know that the language links exist. For example, when trying to find "Barcelona" in English, they would go to Google and type "Barcelona English Wikipedia". We suspected that putting this link on top of the page would be an improvement. It was impossible to move all language-related links because we only could do our part. Language have been planning to move the Wikidata link to the menu with interwiki links. Ping @UOzurumba (WMF), FYI :)
2. We will consider this, thank you!
3. This is way, way, way beyond our project. This is a branding thing, and we are "only" improving the interface. I'll let my colleagues working on the brand know about your opinion, though.

SGrabarczuk (WMF) (talk) 23:36, 6 April 2022 (UTC)

@AnBuKu and SGrabarczuk (WMF):

1. There are two Wikidata links in the sidebar: one is named “Wikidata item”, links to the top of the item page, and has always been in the toolbox; the other one is named “Edit interlanguage links”, links to the sitelinks (which are below the statements on narrower screens), and is in the interlanguage links section on all skins but new Vector. I think you want to move only the second one to the ULS popup. Moving the first one to the interproject links would probably make sense; however, I think if it’s done, it should be done across skins, so it may be out of the scope of this project.
3. Even worse, the name “Wikimedia” is already used: it means all WMF projects together. Wikimedia Commons is a part of it, just like Wikimedia Meta-Wiki or Wikimedia Incubator (or Wikipedia).

—Tacsipacsi (talk) 01:00, 9 April 2022 (UTC)

Thank you @SGrabarczuk (WMF) for the FYI. It is noted. UOzurumba (WMF) (talk) 19:16, 15 April 2022 (UTC)

Search box shortcut key

私は、検索ボックスにもショートカットキーを実装すべきだと思います。なぜならウィキペディアにおいて「検索」は、「編集」や「履歴」より頻繁に用いられる操作だからです。 例えば、 [Alt]+[Shft]+[?] など。240D:1E:105:5A00:5846:64CC:CDB2:F01E 00:36, 7 April 2022 (UTC)

ログインを忘れていました。「240D:1E:105:5A00:5846:64CC:CDB2:F01E」は私です。 シェン,アーナリー,ン,アーバァ. (talk) 00:38, 7 April 2022 (UTC)

@シェン,アーナリー,ン,アーバァ. the shortcut for search is [alt] + [shift] + [f]. You may also be interested in this task: phab:T307024. It's about the shortcut not working on the sticky header search widget. SGrabarczuk (WMF) (talk) 00:00, 28 April 2022 (UTC)

@SGrabarczuk (WMF)

教えてくれてありがとうございます。すでに「検索」ショートカットキーは実装されているのですね。 シェン,アーナリー,ン,アーバァ. (talk) 23:54, 1 May 2022 (UTC)

Yes @シェン,アーナリー,ン,アーバァ. See keyboard shortcuts, you may like this page! SGrabarczuk (WMF) (talk) 22:52, 5 May 2022 (UTC)

User menu switch off

I dont know what the people like on User menu, but for me it is about yet another extra click. So would it be possible to disable just this function? Juandev (talk) 14:30, 7 April 2022 (UTC)

Yes, it should be doable with a gadget. I've pinged a Wikipedian who, as far as I know, has made such an adjustment. On a side note, regarding the "what people like", see the page about the user menu feature. SGrabarczuk (WMF) (talk) 22:50, 5 May 2022 (UTC)

@SGrabarczuk (WMF) Nope, sorry. Not a gadget. I have some tweaks that add a 2nd layer of links but they are rather specific to my usage of Wikipedia... But...

@Juandev If you want you can try to copy my code to your vector.js and .css. Just note that you would need to at least adjust `items` array.

• JS: https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Nux/personalizacja.js&diff=next&oldid=67092191#L-239
• CSS: https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Nux/vector.css&diff=prev&oldid=67092139#L-25

Good luck 🙂 Nux (talk) 01:07, 6 May 2022 (UTC)

Evidence of actual improvement?

I hope that in the end there is statistically valid empirical evidence that proposed changes are actually an improvement for unregistered users or whatever other group of users the change(s) target(s). DCDuring (talk) 17:28, 26 April 2022 (UTC)

We've been discussing at English Wiktionary, but for anyone reading this here: I answered that we perform A/B tests on logged-in users of pilot wikis, we also perform before & after tests on logged-out users of pilot wikis. More information is or will be available on the sub-pages dedicated to individual changes. SGrabarczuk (WMF) (talk) 23:53, 27 April 2022 (UTC)

Move the sidebar links from the left to the top

I think that the sidebar should be converted into a top row (ex. https://www.whitehouse.gov/) rather than on the left. See in the example where there are no sidebar links. This would make Wikipedia look more like a modern online encyclopedia. Of course, it would require a consensus to change this, but I would like to know if it would be possible with current technology. If not, when can we expect the technology to be out? Interstellarity (talk) 17:33, 26 April 2022 (UTC)

Allow me to confuse or clarify this: I would dearly like to be able to hide the "left bank" of the screen most of the time, as most of the time it is completely irrelevant to me, and so I'd like to use the space for the contents I AM interested in. So, could we please be allowed CHOICES ? (Oh, as for being a "modern" thing - I'd settle for being a useful, user-configurable thing...) Autokefal Dialytiker (talk) 18:57, 26 April 2022 (UTC)

Hello @Interstellarity, thanks, that's an interesting idea. Perhaps it would turn out to have practical advantages. Unfortunately, we will not do that as part of this project :/ Most changes are done already. Now we're working on the table of contents. Next, we'll move page tools (Related changes, Download as PDF, etc.), then we'll improve the general aesthetics, and the project will be complete. SGrabarczuk (WMF) (talk) 02:04, 28 April 2022 (UTC)

Let's talk about the Desktop Improvements

Join an online meeting with the team working on the Desktop Improvements! It will take place on 29 April 2022 at 13:00 UTC, 18:00 UTC on Zoom. Click here to join. Meeting ID: 88045453898. Dial by your location.

Agenda

• Update on the recent developments
• Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English and Polish, and additionally: Indonesian at the first meeting, and French and Italian at the second meeting. If you would like to ask questions in advance, add them here on this talk page or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hope to see you! SGrabarczuk (WMF) (talk) 15:14, 27 April 2022 (UTC)

Redlink colour

Is it just me, or are redlinks lighter/brighter in this skin? I could swear their colour is a bit off... Tol (talk | contribs) @ 15:23, 27 April 2022 (UTC)

Yes @Tol, Vector 2022 uses a little brighter color. Before & after:   . This is less related to the Desktop Improvements project, and more to parallel accessibility-related work. If I recall correctly, the change of contrast ratio was mainly made for users with visual impairments and those who read in environments like sunlight. SGrabarczuk (WMF) (talk) 17:53, 27 April 2022 (UTC)

Ah; that makes sense. Thanks for letting me know, @SGrabarczuk (WMF)! Tol (talk | contribs) @ 19:27, 27 April 2022 (UTC)

Notification icon gets larger when there's a notification

Tracked in Phabricator
Task T307134

I know this is really minor, but it's been bugging me: the notification bell icon gets wider, and so moves to the left, every time you get a notification. Is there any way you could make it not move like this? Tol (talk | contribs) @ 19:30, 27 April 2022 (UTC)

@Tol, please provide details about your browser. I'm not sure if this is in any way related to our work. SGrabarczuk (WMF) (talk) 21:09, 27 April 2022 (UTC)

@SGrabarczuk (WMF): Google Chrome 101.0.4951.41 (beta) on Linux. Here's a video: File:2022-04-27 recording of Vector 2022 skin notification icon width.webm. Tol (talk | contribs) @ 21:20, 27 April 2022 (UTC)

@Tol thanks for pointing this out. I've just filed a task about it: phab:T307134. Unfortunately I don't think the echo notifications are actively maintained by anyone, but hopefully we can find someone to fix this. AHollender (WMF) (talk) 19:07, 28 April 2022 (UTC)

Whoops...I just checked Legacy Vector and realized this is a new issue, possibly introduced by our team, so I moved the task onto our work board. AHollender (WMF) (talk) 19:10, 28 April 2022 (UTC)

@AHollender (WMF): Yep; that's why I brought it up here. Thanks! Tol (talk | contribs) @ 19:38, 28 April 2022 (UTC)

Updated table of contents doesn't work with VisualEditor

Tracked in Phabricator
Task T307251

Testing out the new table of contents, one thing I'm noticing is that it doesn't appear to work with VisualEditor previews. When I add, change, or remove a section during editing, it doesn't update, and even after I click publish, it still doesn't update until I refresh the page. Is this a known issue? {{u|Sdkb}} ^talk 22:25, 27 April 2022 (UTC)

Thanks @Sdkb. This is phab:T307251, isn't it? SGrabarczuk (WMF) (talk) 22:31, 5 May 2022 (UTC)

Yep; glad it's being tracked! {{u|Sdkb}} ^talk 03:16, 6 May 2022 (UTC)

TOC subsection links fail accessibility

Tracked in Phabricator
Task T306562

The TOC subsection links are black instead of blue. This violates accessibility, a core principle of Wikipedia. See https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Color bullet two: "Links should clearly be identifiable as a link to our readers." Jonesey95 (talk) 00:14, 28 April 2022 (UTC)

@Jonesey95, sorry, I mis-pinged you in the comment above. There are more links/buttons in our interface which are grayish, not blue. @Volker E. (WMF) is the accessibility expert. SGrabarczuk (WMF) (talk) 12:24, 28 April 2022 (UTC)

@Jonesey95 thanks for pointing that out. The links should be blue and will be fixed soon. Here is the task for more details: https://phabricator.wikimedia.org/T306562 — AHollender (WMF) (talk) 13:43, 28 April 2022 (UTC)

Provide a link to this page?

Tracked in Phabricator
Task T307113

I wanted to report the weekend's Chromium regression bug but couldn't find the appropriate page, presumably this one. Along with others on the English WP I resorted to w:WP:Village pump (technical) but I'm sure other pages have also been tried. So long as it is experimental, would it be reasonable to add a collapsible banner to pages rendered using this skin, pointing here for explanations, reports, and comments? DavidBrooks (talk) 17:01, 3 May 2022 (UTC)

Or maybe add a link to the setting in Preferences/Appearance, which is another place I looked. DavidBrooks (talk) 18:24, 3 May 2022 (UTC)

@DavidBrooks - glad you found the page and thank you for the suggestions! We're actually already planning on implementing your second idea (adding a link in the preferences page). It's tracked in phab:T307113, and we hope to have it out next week. OVasileva (WMF) (talk) 11:28, 4 May 2022 (UTC)

Thank you DavidBrooks (talk) 14:23, 4 May 2022 (UTC)

Let's talk about the Desktop Improvements

Hey everyone watching this page or visiting it because of our banners. Join an online meeting with our team, people working on the Desktop Improvements! It will take place on 17 May 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 86217494304. Dial by your location.

Agenda

• Update on the recent developments
• Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English.

We can answer questions asked in English, Italian, Polish; also, only at the first meeting: Farsi, Vietnamese; only at the second meeting: Portuguese, Spanish, Russian. If you would like to ask questions in advance, add them here or send them to sgrabarczuk@wikimedia.org.

At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We hope to see you! SGrabarczuk (WMF) (talk) 03:15, 14 May 2022 (UTC)

Keyboard shortcut does not focus search field in sticky header

Tracked in Phabricator
Task T307024

When pressing the keyboard shortcut for search (alt + shift + f) the search field at the top of the page is focused, even if the sticky header is showing. It would be better if the search field in the sticky header was focused. As it is now the page will scroll to the top which is unnecessary. Sebastian Berlin (WMSE) (talk) 16:10, 12 January 2022 (UTC)

Page-title and Search

In a nutshell, I believe

• the Search would benefit from being (a) more consistently placed, and (b) more accessible from the sticky header by having a larger click-target.
  • See image at File:Vector-sticky-header-version1-search-size.png (and more details above)
• the Page-title is already visible in multiple locations, and might not need this additional instance? AFAIK only users with "Fullscreen - F11" enabled would hide the existing locations where it is already displayed, whilst scrolled.
  • See image at File:Page_title_repetition_and_cutoff.png

Hope that helps! –Quiddity (talk) 20:53, 21 January 2022 (UTC)

Feedback on new language switcher in French

As a translator, I litteraly jump from one language to another every hour of every day. It is simply unbearable to now have to go to a sub-menu to switch from French to English or Italian. That added click translates (pun intended) into lost time and nerves on a daily basis.

I'm not hostile to a more smartphone-friendly interface, and maybe that kind of switcher is perfect on a little screen. But it's not okay to make the overall experience so much unsteady (especially with the links being there for some languages and moved away for other ones) when

1. switching seamlessly from one language to another is precisely the one advantage Wikipedia has over any other encyclopedia and
2. my 32" monitor has plenty of space to display these links in the left column.

Last year I had selected the old Vector theme for this very reason and this morning, I was force-switched into the new Vector 2022 theme. So for the second time I'm back on the classic Vector theme and really, really hope it will stick. Herisson26 (talk) 22:16, 7 February 2022 (UTC)

Hello @Herisson26. Thank you for asking here.

• We've been planning to provide one-click access to preferred languages but it's dependent on the work of another team (Language). We can't promise anything in terms of the timeline yet.
• What do you mean by "with the links being there for some languages and moved away for other ones"? You saw the new Vector on some wikis, and the old Vector on some other wikis, didn't you? I think that's related to the next issue.
• Why you had to switch back again - here's my explanation. We're sorry, this was an extremely rare oversight.
• It's interesting that you write this interface is smartphone-friendly. Many volunteers note this. Out of curiosity, what makes you think that? Is this just about the responsiveness, or something more?

SGrabarczuk (WMF) (talk) 00:30, 17 March 2022 (UTC)

Hello @SGrabarczuk (WMF),

• For a translator, direct access to "preferred" languages is not enough. I need the complete list of languages, as it exists on old Vector. My preferred languages would be French, English, Spanish and Italian, but I will regularly read directly a page in Japanese, Portuguese or any other if it's the one that will get me the information I'm looking for (which is quite often the case when dealing with foreign people). So limiting direct access to a select few languages will still break Wikipedia for me.
• Yes, lots of wikis use old Vector while the French one uses the new ones. It completely breaks the user interface. It is of utmost importance to me that all Wikipedia pages have the same layout, whatever the language. I understand the need to test things, but when you make a public switch that impacts the ergonomics of the site, it should be made across all languages. Maybe make the change per-user instead of per-language if you don't want to switch everyone at once.
• Nothing to do with responsiveness. Smartphones don't have the physical space to display the language list and the article content at the same time, so having a button on the top of the page to show/hide the language panel makes sense. It does NOT on computers, which have plenty of free space for the left column and the traditional language list.

Herisson26 (talk) 08:21, 18 March 2022 (UTC)

Very bad indeed. The French version of Wikipedia, which has put all interwiki language links in a dropdown menu, is most annoying. It is a big waste of time, and not user-friendly at all. To switch to the article in another language, instead of having the whole choice displayed at once and just having to click, one now has to go back up to the right-hand corner of the article, click on the dropdown menu, scroll down the list until the desired language apears, click again... This change is not an improvement. It tends to isolate each linguistic version of Wikipedia, by rendering the language switching much harder. If ever it is useful for smartphones, please change the layout for mobiles only ("m" version of Wikipedia), but not for the desktop version. This cumbersome change should NOT be extended to other Wikipedias, and the French version should revert as soon as possible to a user-friendly layout, such as that of the English language Wikipedia. Baronnet (talk) 15:49, 20 March 2022 (UTC)

@SGrabarczuk (WMF) very cool that you bring one click different language!! would you please include the language team in this discussion here, and provide a link so people can view the progress? --ThurnerRupert (talk) 18:56, 11 June 2022 (UTC)

TOC Feedback

I noticed that the newest designs for the table of contents do not allow for it to be collapsed. I think the ability for the TOC to be collapsed is very important, specifically for users that have a touchscreen laptop. I and a friend of mine often use our left hand and our touchscreen to scroll articles because on our laptops it is often easier to scroll quicker than to use the touchpad. If the TOC remained expanded we might accidentally tap a link. A button to collapse it and a preference to expand or collapse it by default would be nice. Lectrician1 (talk) 20:07, 8 February 2022 (UTC)

Hello @Lectrician1. Indeed, the first version of the TOC was not possible to be collapsed. This was because the results of user testings (both in-person and on-wiki) didn't indicate that the functionality was important. Now, given the feedback we've collected, we've decided to consider options how to make the TOC collapsible. In this context, what do you think about our newest prototype? SGrabarczuk (WMF) (talk) 13:46, 6 May 2022 (UTC)

@SGrabarczuk (WMF) Thank you for responding!

Hi, @SGrabarczuk (WMF), I came to this page to ask whether the ToC can be moved from the sidebar, and really like the prototype. However it seems to be malfunctioning in Safari 15.4 (17613.1.17.1.13): https://imgur.com/a/O0Jhti1

Thanks. —Hugh (talk) 05:43, 20 May 2022 (UTC)

My feedback:

• I really dislike the usage of the bracket type of buttons for [hide] and think a OOUI button or a smaller alernative should be used instead.
• I like that all of the headers in the TOC are collapsed by-default, however, I think they when you're scrolling inside of a section, they need to expand and collpase as you go through one section to another. I've seen this functionality on other platforms and it allows the reader to understand the outline better when they're viewing the article.
• The hiding action of the TOC has an inconsistent navigational pattern. UIs should always require the same amount of actions to disable something as to enable something. That always feels the most natural. Hiding the TOC for its default position requires one button press, but to return it back to its previous state requires two. Also, its location next to the title and then how it switches to the upper left to become sticky is really weird too. I don't like either of those locations. I was thinking it could look something like this collapsed and you could press the icon on the right to both collapse and expand it:

Lectrician1 (talk) 00:42, 7 May 2022 (UTC)

Hi, i just cant find the table of contents, i need it for easier navigation. please, help

Sticky header in the namespace Project

(original discussion in French)

Hi,

a user suggests to add the sticky header in the namespace Project too, not only in Talk pages or History pages (see for exemple phab:T289641#7365946 and phab:T299115). Best regards, Patafisik (WMF) (talk) 09:15, 9 March 2022 (UTC)

Questions I shouldn't need to ask

I can tell WMF developers put a lot of work into this, but I'm sorry, this isn't cutting it. This latest prototype is Vector in name only. It's a completely different look and a completely different experience.

• Why do I have to click twice to get to my talk/contribs/preferences?
• Don't you think you could have fit those important links if you didn't go overboard on the whitespace or if the search bar wasn't so enormous?
• Is the language switcher really so important that it belongs in the sticky menu?
• I had to think for a few seconds about what the hamburger/star icon was (it's the Watchlist). Why are the icons necessary? I'll answer this one — too much whitespace at the top.
• Why is the new interface such a step down for the editors who will have to use it every day?
• And why are you still trying to put a hamburger menu on a desktop site?

It's not all bad — I do think the max width improves readability. But that was already present on previous less-bad prototypes.

We were promised "improvements" to Vector, and what we're getting is an entirely new (and entirely inferior) skin. If this is really going to still be called Vector, that is highly misleading. The early comments that "total replacement is not an option" don't make a lot of sense now that Wikipedia appears to be getting exactly the top-down redesign I had feared this project would produce. Pigs will fly before this gets deployed to English Wikipedia without the community getting their pitchforks. — pythoncoder  (talk | contribs) 04:45, 26 March 2022 (UTC)

I went into Preferences to turn off the changes and I saw that the software is now treating "vector-2022" as a new skin. This is better than what I thought was going on but maybe there should be a more original name>

Also, wouldn't it be a much better use of developer time to, say, work on the many unresolved Community Wishlist items? — pythoncoder  (talk | contribs) 17:09, 26 March 2022 (UTC)

Hi @Pythoncoder, thanks for these comments. I'd just like you to know that I'm working on an answer for you and I'll paste it soon. You've asked many important and basic questions (like the one about the Community Wishlist Survey), and I'm truly happy that you've done that. It's much better to clarify the basics. You don't know whether these are clear as long as no one questions it. SGrabarczuk (WMF) (talk) 00:53, 8 April 2022 (UTC)

@SGrabarczuk (WMF): I should have made it more clear above, but most of my comments are regarding the Fourth Prototype. And now that I read through my earlier comments it makes sense to make the sidebar collapsible in case readers don't want distractions. I believe the sidebar is shown by default so please disregard my complaints in that area. This is why I shouldn't edit when I'm sleep-deprived. I do still think the new skin needs a new name though. — pythoncoder  (talk | contribs) 01:03, 8 April 2022 (UTC)

Also re: wishlist, I suspect the two projects are probably worked on by completely different dev teams. Again, I'm sorry for the passive-aggressiveness above. — pythoncoder  (talk | contribs) 01:06, 8 April 2022 (UTC)

Hello @Pythoncoder, no worries, I'm really glad you've figured some issues out yourself! Would it be possible for you to state what remains unclear? SGrabarczuk (WMF) (talk) 15:05, 14 April 2022 (UTC)

I think it mostly boils down to the amount of whitespace at the top and the hiding of important links such as talk, contribs, and login under a dropdown. I think this should be fixed. — pythoncoder  (talk | contribs) 01:28, 15 April 2022 (UTC)

Sticky header doesn't show the name or the logo of the project: the risk of loss of identity for Wikimedia sister projects

(From French Wiktionary)

Tracked in Phabricator
Task T293395

"I'm still observing the same problem when using this new skin: if you scroll down the page, it's impossible to know on which Wikimedia project you're on. The sticky header doesn't include the name of the site you are on, which is penalizing users for sharing screenshots, but also for identifying the editorial lines/ editorial policies of the different projects. Sister projects have important specificities. On the French Wiktionary, we already have people complaining that they can't find the content they expect to see on Wikipedia, and we have to tell them that it doesn't belong on the Wiktionary. I'm afraid that the phenomenon will only get worse."-Translated by --Patafisik (WMF) (talk) 13:28, 29 March 2022 (UTC)

(original message: "J’observe toujours le même problème, que je constate au quotidien en utilisant ce nouvel habillage : on ne sait pas sur quel projet on est dès que l’on défile un peu. L’en-tête fixe n’intègre pas le nom du site sur lequel on se trouve, ce qui est pénalisant pour le partage de capture d’écran, mais aussi pour l’identification des lignes éditoriales des différents projets qui ont des spécificités importantes. On a déjà actuellement des gens qui se plaignent de ne pas trouver tel contenu qu’ils s’attendent à voir sur Wikipédia, et à qui on doit répondre que ça n’a pas sa place sur le Wiktionnaire. Je crains que le phénomène ne fasse qu’empirer. Noé 29 mars 2022 à 12:37 (UTC)")

some feeback on the layout

I really like the preview, it is much cleaner, a few thoughts from viewing this on desktop (I saw the Blue whale article and the Potato article):

1. The 'in other projects' section is really nice, however I wonder what would be a sensible heirachy for this. Should it be contextual based on the topic or something else? Currently its suggesting me WikiNews which isn't relevant or a particularly well maintained Wikimedia Project. Also the other projects is more about navigating to other information on that topic, rather than being a tool, I wonder if it should be under the TOC instead? Its more about navigating information on the topic rather than using a tool.
2. I'm not sure if this is intended, the images sit on top of the sections instead of being displayed along the side the text, especially for portrait format images this creates a lot of empty space.
3. When logged out having the TOC on the left is really nice, works really well. But when I'm logged in the TOC is hidden under half of the tools but then the other half is on the right hand side is quite confusing. I realise this is a really difficult thing to organise, maybe it could live under the TOC? There isn't a clear deliniation between reading and contributing which is confusing.
4. The taxonomy templates at the bottom are pretty broken and make long lists, also lists within the Potato article lose their formatting meaning on the page for potato the list of synonyms is one column wide making a very long section which isn't going to useful for a general reader right in the middle of the article. John Cummings (talk) 18:03, 12 April 2022 (UTC)

Sidepanel is bloated

Tonight size of left panel is increased too much. It covers more than ¼ screen now. https://imgur.com/3YJlcii Can I reduce size of panel, as it was before? Tucvbif (talk) 21:18, 25 April 2022 (UTC)

Agreed. I feel there's too much white space padding the left and right of the sidebar. Tenryuu (talk) 00:53, 26 April 2022 (UTC)

@Tucvbif @Tenryuu thank you for these reports. It seems like you may have your browser window zoomed in, is that correct? Also, if you are able to please add any additional thoughts, needs, screenshots, and ideas to this task: https://phabricator.wikimedia.org/T306660. AHollender (WMF) (talk) 14:54, 26 April 2022 (UTC)

No, my browser not using zoom. I using personal css with font-size 14pt, but when I login to other account without personal css, the sidepanel still terrible huge.

https://imgur.com/l8bIrDF Tucvbif (talk) 15:07, 26 April 2022 (UTC)

@AHollender (WMF): Apologies, I should have clarified. The sidebar here is fine; the one at Wikipedia isn't. Resetting the zoom level on Wikipedia doesn't address the issue; there's still a lot of white space padding the element. I'll leave this discussion and focus on #I oppose the new sidebar/TOC and the mentioned Phabricator ticket, which describes my issue more accurately. Tenryuu (talk) 15:10, 26 April 2022 (UTC)

The ambiguity and confusion evident from the preceding discussion suggests that the interface has become to complex. Aren't the original sidebar and TOC at the top of the page enough? Why change? Is another popup menu necessary to switch language? What about setting language in user preferences? Simplify, simplify, simplify. Regards, ... PeterEasthope (talk) 00:28, 25 May 2022 (UTC)

TOC limit doesn't work anymore

It seems that this "sidebar TOC" has different classes, making en:Template:TOC limit doesn't work anymore. William Surya Permana (talk) 07:46, 26 April 2022 (UTC)

Templates can only control the content of an article so en:Template:TOC_limit/styles.css won't apply outside the article area so new classes won't help here. A magic word would need to be added so support this use case if important and time allows. Jdlrobson (talk) 15:37, 26 April 2022 (UTC)

I oppose the new sidebar/TOC

Please make it possible for the users to collapse the left sidebar/TOC or to reduce the white space size. I for one use a browser sidebar (Sidebery) as well as 150% or even bigger text size. Combined with the forced sidebar/TOC, the actual line length becomes much smaller than the recommended length. PeterTrompeter (talk) 08:43, 26 April 2022 (UTC)

Hi @PeterTrompeter - thanks for your feedback. We're currently exploring better solutions for the ToC at narrow widths, which include the option of collapsing as well. Check out phab:T306660 for the details and prototypes. It would be great to get your opinion on some of these. OVasileva (WMF) (talk) 10:40, 26 April 2022 (UTC)

I wonder about one thing: Who on earth thought that having such a monstrosity as that [pejorative snipped] TOC as a PERMANENT part of the skin would be a good idea ? I mean, having it pop up might be a useful thing for newbies (and I find even that a stretch of my imagination), but PERMANENTLY wasting space on a table of contents you consult perhaps once or twice per (long) article ? So KINDLY have it fixed to be hideable/collapsible so that we can get actual article contents on our screens. (One sidenote here: Apart from my blowout here - yes, I am aware that working on these projects is a chore, and despite my invectives here, I AM grateful for your efforts. It's just that this kind of stuff goes so completely against what would be the natural idea here, that I blow my top unnecessarily hard - people generally want to read the TEXT of the articles, so when a new skin development deliberately wastes space on the table of contents - ????? ) Autokefal Dialytiker (talk) 16:43, 26 April 2022 (UTC)

Hey @Autokefal Dialytiker, we test all of the proposed changes. Editors and readers were strongly in support of this change. More details here: Reading/Web/Desktop Improvements/Features/Table of contents. Cheers, AHollender (WMF) (talk) 17:47, 26 April 2022 (UTC)

My question stands: Why having it there PERMANENTLY ??? Ok, I find something that's relevant for me to read; usually, I then want to READ just that; not the thread that led me there... So, why PERMANENTLY ??? Autokefal Dialytiker (talk) 17:54, 26 April 2022 (UTC)

Public and private views...

While thinking about this, I was struck with what appears to me to be a central point of division here: This is not a question of how THE user interface should look like; but, rather, it is a question of what we should look like to anonymous users, and what choices should be available to those of us who log in ? Does that differentiation make sense ? (I should mention that I'm coming to this from Wikipedia, and that I have very little experience with the other projects.) Autokefal Dialytiker (talk) 19:14, 26 April 2022 (UTC)

Yeah @Autokefal Dialytiker, this makes sense. With the caveat that I don't know what central point of division you are referring to :D

At the moment, except for gadgets and such little tweaks, we aren't able to offer different interfaces for logged-out and logged-in users. Also, we can't make it possible to easily switch between different settings like dark/light mode, contrast versions, font sizes, etc. We need to improve the basics of the viewing/reading experience, we can do that, so we're doing it.

As a result, readers use our interface more comfortably, we check that with regular A/B tests. As for the most dedicated editors, they can/should:

1. Help us build an interface useful to them (by giving feedback on the prototypes, on the changing interface on "pilot wikis", by adjusting gadgets, etc.)
2. Accept the arguments about the results of user testing, A/B testing, community feedback...
3. Accept the "final" version as the basic version, and
4. Configure it further if they want.

Our team would like to work the interface deeper. We would like to make it more modular and adjustable. (Of course, content would stay objectively the same for all.) A few months ago, we started working with more closely Growth and Editing. Now we're checking how ambitious we can be.

Does that answer your question? SGrabarczuk (WMF) (talk) 22:26, 27 April 2022 (UTC)

My way of thinking here, is that the main divider here is between what should be visible and available to those who are NOT logged in, and what should be available and possible for those who DO log in. This is because the big difference between the two groups, is that those who are logged in, are also able to seek detailed information and make informed choices (and possibly programmed adaptations), whereas the non-logged in can not be trusted to have any particular information about the system, do not have a way of communicating preferences, and therefore needs to be given visual cues as to what's possible and available, precisely because they are strangers here... (Sidenote: I am of the Wikipedia, and that is the project I write in relation to; each project will have some peculiarities that do not apply to the other (to the same degree, at least); for this reason I should remember to mention this.)

I hope what I'm writing here makes some sense, I try to avoid giving specific "orders" to anyone, but rather contribute to clarifying the context so that I understand it; hopefully, what I then write makes sense to others as well... (About here my subconscious can be heard muttering "and if pigs could fly"...) Autokefal Dialytiker (talk) 13:17, 9 May 2022 (UTC)

Wide-column + Multi-column options for large screens

Tracked in Phabricator
Task T335142

Readers vary in what form factor they prefer, especially for long-form high-volume reading. That's part of why this change and research into 'optimal layout' is controversial. I'm someone who finds it hard and slow to read a narrow column and have to scroll all the time, including when searching a page for a term. General feedback on width:

1. Include a comfortable default for large screens. The (potentially large) gray margins on left and right, outside large white margins, bracketing a forced-maxwidth central column, do not feel good. Wide-col or multi-col could work.
2. Offer an explicit wide-column pref that doesn't require people to change skins, even if that is less aggressively supported/tested across all platforms.
3. A multi-column design for text within sections – mimicking the style of most long-form magazines and scholarly journals – would be interesting and can be surpassingly beautiful. That's what I'd like to see our wide-screen layouts transition to. We already do this within sections for references, lists, and galleries.

Even low-end desktop monitors these days are high enough resolution to support two-column layouts. Sj (talk) 18:20, 2 May 2022 (UTC)

I think sticky elements ruin Vector

I liked vector a lot more when it didn't have the new distracting elements (sticky header and sticky TOC). I care about the contents of the page, not the interface, nor about the need to scroll to the top of the page every now and then. Tokujin (talk) 17:50, 4 May 2022 (UTC)

Hello @Tokujin. Congratulations for finding this page :D You can add .vector-sticky-header {display:none;} to your global.css. For now, I'm not entirely sure what to advise about the TOC, though. When the collapsible version has been deployed, we'll know what code you should use to make it not sticky and keep some other version. I invite you to revisit this topic in 2-3 weeks.

By the way, I very much liked the first sentence of your comment to the third prototype. Have you seen the fourth one? I encourage you to follow the instructions and share your opinion about it, too. (BTW, compare it with the newest version, also a prototype.) SGrabarczuk (WMF) (talk) 22:28, 5 May 2022 (UTC)

Hi Szymon :-) Done, thank you. Regarding the global.css setting, notice that with sticky table headers enabled (in Preferences > Gadgets > Testing and development) there's a bug whereby in tables such as those in this page the table header leaves space for the absent page header. Other tables, such as that here, don't have this issue. Tokujin (talk). 07:41, 9 May 2022 (UTC)

Skin differences between wikis

I'm using the 2022 Vector skin globally now (with some modifications to remove whitespace), but I'm noticing that some wikis' sidebars are different from others. For example, MediaWiki wiki (this wiki) and French Wikipedia have a thinner white-background sidebar which sits on top of the page body (and ToC in the page body), while Meta-Wiki, Wikidata, and English Wikipedia have a wider grey-background box which is not layered on top of the page body (and ToC beneath said box). I can't figure out why this is. Tol (talk | contribs) @ 00:12, 8 May 2022 (UTC)

@Tol - thanks for your question, and good catch! This is due to the table of contents still needing to being A/B tested on some wikis (frwiki and mediawiki wiki being two of these). The ToC functionality is not yet available there. That said, we've began some work on reducing the margins for the ToC as a whole (phab:T307004) that will make the differences in width fairly negligible. This change will be on all wikis next week. OVasileva (WMF) (talk) 10:31, 9 May 2022 (UTC)

@OVasileva (WMF): Ah; looks great! I look forward to that change rolling out. Thanks! Tol (talk | contribs) @ 14:14, 9 May 2022 (UTC)

Tool bars and tables

Hi, thanks for the update. A few observations:

1. I would suggest that users have the option to keep the tool bar on the sidebar from the beginning, instead of having to click "tools" -> "[move to sidebar]" every single time.
2. The readability of tables and graphs that are wider than the (quite tight) text column is an issue. In certain cases, the tables represent time series data (e.g. population in a country or municipality over time) that cannot just be tightened. Do you have a proposal to solve this issue? The NYT, which is a site that you explicitly mention as inspiration, lets tables and images occupy the whole width of the screen if necessary.

GeneraleAutunno (talk) 20:39, 8 May 2022 (UTC)

Next steps for the Table of Contents

Hey all - thank you for all the feedback around the issues you were experiencing with the ToC, especially on narrow screens. We've taken a few steps to fix some of these issues:

• We're reducing the margins of the ToC to more closely resemble those of the prototype (tracked in phab:T307004)
• We have a temporary solution for the ToC at narrow widths, which removes the ToC alltogether
• We are building functionality to allow for the ToC to be collapsible and expandable at narrow widths (tracked in phab:T306660)
• We are planning on making the ToC collapsible at all screen sizes and widths (tracked in phab:T307901)
• https://di-collapsible-menus.web.app/Brown_bear links to a prototype that puts all of these changes together.

We would appreciate your feedback and thoughts on the decisions made within the prototype and whether they work for you. Thanks! OVasileva (WMF) (talk) 10:38, 9 May 2022 (UTC)

cc @Lectrician1, @Alexis Jazz, @Autokefal Dialytiker, @Tenryuu, @Tucvbif, @Tokujin - in case you're interested. Apologies if I'm forgetting anyone else that was asking about this! OVasileva (WMF) (talk) 10:46, 9 May 2022 (UTC)

OVasileva, thank you, it's a solid improvement! Just one request: can the hiding/unhiding be made persistent so my choice remains in effect even if I navigate to another page? Alexis Jazz (talk) 12:35, 9 May 2022 (UTC)

Thank you, that's good news! (Adding a clarification: I'm responding to OVasileva, here.) My thinking is that making it collapsible is the only reasonable way to go; with the added point that for newcomers and anonymous readers it should perhaps be turned "on" as default; if the collapse button is clearly visible, the TOC will be useful to some, and easily removable for the rest, which should be the useful level of the intrusive/invisible conundrum... Thank you, once again. Autokefal Dialytiker (talk) 13:02, 9 May 2022 (UTC)

@OVasileva (WMF): Thanks for letting me know. Since this seems to be only in effect for the new Vector skin, maybe some work could be done to have the table of contents be shown in focus and have a button on the sticky header, as well as a keyboard shortcut for it? Tenryuu (talk) 14:07, 9 May 2022 (UTC)

Thanks for the work, I like the prototype a lot. I've missed the easily available overview that the ToC provides. Compare to the 2010 design, it is very useful to have the ToC available no matter how far down you scroll.

On small screens, the "move to sidebar" link text is not accurate with regards to what happens visually when you click on it. PeterTrompeter (talk) 16:51, 11 May 2022 (UTC)

On narrow screens this is still quite jarring, and having no TOC is a loss, being able to move the TOC back in to the body (dynamically and programmatically) seems a better compromise. A problem I see is that even when there is no TOC on a page, all that space it could use is still being consume by blank space, that wasted horizontal space needs to be able to be reclaimed somehow. We've been testing some options that are aimed at more power desktop editors so they can use vector-2022, but still have access to most of their screen (see example (will really only be strikingly noticable if you are on a wide screen)) but still are getting complaints about the huge space used by the TOC. Xaosflux (talk) 11:40, 14 May 2022 (UTC)

Banners and roadmap

Hi, I think you should consider to add banners in order to present the restyling to a much wider part of users. IMO they should link to discussion and presentation pages. You should also consider to present to the wikis a clear roadmap with dates in order to present ahead of time big changes like the adoption of the new Vector. This two changes would make you work clearer to the eyes of the users and would prevent some dissatisfactions. In particular I'd like to point out that what is happening on itwiki is being perceived as an imposition against the general consensus and I agree with the Italian users that are saying that forcing the adoption of the new skin is not the right way to act. These two are some ideas to widen the discussion, forcing something against the will of most will just radicalize the opposing positions even more. -- WikiLuke (talk) 11:44, 9 May 2022 (UTC)

I just received the good piece of news that the adoption of the new skin has been delayed for itwiki and I thank you for this. But I still think that the two ideas that I presented above would be good tools to prevent something similar to happen again. ----WikiLuke (talk) 11:58, 9 May 2022 (UTC)

Thanks @WikiLuke. These are great suggestions.

• Banners - T304839 - we've been working this for some time. Soon, the banner should be visible to some logged-in Vector users. They will be encouraged to switch to the new skin, and some time later, they'll see another banner with a link to this talk page.
• Links to the project page - T307113 - our idea was similar. We'll add a link to the list of skins in preferences.
• Roadmap - that's also a very good point. We'll consider how to present this to the community most effectively.
• Itwiki - we'll continue this topic on itwiki, alright?

SGrabarczuk (WMF) (talk) 15:33, 9 May 2022 (UTC)

Thank you for you consideration! :) And speaking of itwiki of course we will continue the topic right there. -- WikiLuke (talk) 16:14, 9 May 2022 (UTC)

Sticky header 'dead zone' in articles with long lead sections

Tracked in Phabricator
Task T307345

Steps to reproduce:

1. Visit an article with at least a moderately long lead section (e.g., en:Charles de Gaulle).
2. Scroll down a little way.
3. Observe that the sticky header appears.
4. Scroll down a little further, so that the first heading appears, but not much further than that.
5. Observe that the sticky header vanishes.
6. Scroll down even further.
7. Observe that the sticky header re-appears.

This does not seem like intended behaviour. I am testing on Firefox 100. FrankSpheres (talk) 04:14, 10 May 2022 (UTC)

Hi @FrankSpheres - thank you for your report! We already have a fix for this bug, tracked in T307345. It will be available early next week. OVasileva (WMF) (talk) 08:11, 10 May 2022 (UTC)

Feedback on new look

I like that stuff that is generally rarely used is hidden, such as the language picker.

I am not a fan of moving the table of contents off the main article body section. I didn't even register that the table of contents was there and I frequently use the TOC to get an overview of interesting sections of articles. With the TOC being isolated at the side bar, it seems separated from the article itself, while it should be a central part. Maybe it would work better if it appeared on the right of the article, where there is currently just whitespace?

Speaking of whitespace: I dislike the move to a max-width on article pages. This feature should at the very least be toggle-able with a button (without a need to log in). I feel like it makes the article feel more cramped, with less space for images and figures. There is already a very good solution to setting the effective width in the old view: Simply resize your window or zoom in on your browser. With the new look, I am forced to a max-width and I don't have a solution to control the width like I did before.

Whitespace and the TOC did something beautiful together in the old look actually. The TOC conveniently visually separated the article lead section from the rest of the article by introducing white space, which I personally found very pleasing. The new look has the lead section blend in with the rest of the article. This makes the lead appear more daunting, while its purpose is to serve as a quicker summary. Perhaps the lead section should be followed by a larger piece of whitespace than is normally found above headings, so as to separate the lead from the rest as before?

Finally I am quite sad to see that the Wikipedia globe logo is diminished - I really like the globe with the symbols and it doesn't look very good at low resolutions. I think the size of the globe was perfectly fine before. Besides, it seems there's plenty of space for it to have the same size as before so I'm kind of puzzled why this change was made in the first place.

I will also say that the arrow next to the Wikipedia globe (the one to minimize the side bar) leads to an unfortunate usability flaw. I initially thought the arrow was supposed to take me back to the front page (it is right next to the logo and the leftward direction suggests a "back" action). But that is not what it does at all. So the arrow is kind of confusing at first. --SorteKanin (talk) 16:40, 13 May 2022 (UTC)

When testing the new skin, offer a one-click way to change back

The banners inviting users to test the new skin offer a one-click option that updates your skin to new Vector. The banner is then replaced with a message saying "give us feedback!", but it should also offer a one-click way to revert the change. Users may not be familiar with how to undo the change. Sj (talk) 12:56, 14 May 2022 (UTC)

The one-click option to revert is the final item of the sidebar's top section, in bold. Are you suggesting a second method should be included, or that the link should be made more obvious and flashy by moving to the banner?

The sidebar link seems fine to me. Particularly because this is less about the theme and more ergonomics for migration. Kees Person (talk) 15:34, 14 May 2022 (UTC)

I found it eventually, thanks. Yes, putting it in the banner, or putting a js link in the banner that highlighted the sidebar link, would be clearer :) Sj (talk) 19:59, 20 May 2022 (UTC)

Too little space

It's probably fine for those who don't use wide-screen monitors, but as someone who does it is quite annoying having everything mushed together like on mobile. I have read the page on this, but I think there should be a way to keep the functionality of the skin but lengthen the screen. Lallint (talk) 13:57, 14 May 2022 (UTC)

I concur. I tried the new skin a couple of times and just could not do it. I have bought a standalone monitor for a reason - and it's not that large anyway (1920 x 1200) - yet the new skin wastes a third of my screen space. Kashmiri (talk) 12:31, 20 May 2022 (UTC)

Actually I use a 13" laptop and I initially thought that my computer switched to mobile version by mistake, but I later realized that was the desktop layout. I think the way everything is squeezed-in together takes away from the experience; there is nothing wrong with the header and tools bar they look fine to me, yet the sizing seems off for desktop users. Humanized (talk) 10:20, 24 May 2022 (UTC)

Sidebar too long

Sidebar too long and page too small on Wikimedia wikis LisafBia6531 (talk) 16:24, 14 May 2022 (UTC)

Do not use a sticky header.

I think the new layout makes much better use of whitespace on 16:9 displays, making paragraphs easier to read. However, vertical space is someone no website that serves text-rich pages to users can ever get enough of. I believe that every (non-redundant, e.g. the article name is displayed twice on most browsers in the window tab title and the sticky header) element currently placed on the sticky header would not just fit on the sticky sidebar, but by removing the sticky header the layout will better serve what readers come to a wiki to do.

As a side note though, I am awfully sentimental about the old Wikipedia header logo and type layout, that giant globe and the accompanying text beneath it is far too iconic to change in my opinion, even for a redesign. Saedes (talk) 14:18, 15 May 2022 (UTC)

Sidebar considerations for vertical monitors/half-width windows

I haven't tested this out thoroughly yet, but I'm going to be adding this section to start a discussion on how the new layout uses responsive design when display device/window aspect ratios are greater in height than width. Saedes (talk) 14:28, 15 May 2022 (UTC)

The table of contents is in the wrong place

It's nice to have a table of contents right there on the side so you can move back and forth between sections but i don't like the fact that you have to scroll down a bit to find it. If there's a way to keep it at the top of the page so you see it right as the page loads then as the user scrolls down it changes into a sticky header, that would be better. Abhaypradjha (talk) 10:04, 16 May 2022 (UTC)

Search bar UX is inefficient (Fitts's law)

I want to search.

1. If I am at the top of the article, I click mindlessly anywhere on the header and type straight away.
2. If I am down the article, I have to pinpoint an icon.

This is bad because

• The inconsistency turns my muscle memory against me
• It goes against Fitts's law: pinpointing an icon requires precision and is slower than clicking a large bar at the border of the screen without giving much thought into it.

A solution would be that clicking on the article title or empty space in the sticky header hides the article title and displays the search bar (empty and focused).

My case is that I often read the documents with the help of Wiktionary, so I use the search bar heavily and my usage pattern is fundamentally different than on Wikipedia. On Wiktionary, the interesting information is on one line or two, for each one of many unrelated entries, so searching is almost exclusively my means of navigation. Wanlpz (talk) 19:05, 17 May 2022 (UTC)

TOC: the position of the content

Hi, I like your last prototype of TOC, in particular the blu color which helps to find a menu when you collapse it.

I notice something I consider a bug: when the TOC is collapsed, if the tools menu is collapsed too the content is in the correct position, but if you move to the sidebar the tools, the content changes his position (it shifts on the left side). It feels strange. It doesn't happens when the TOC is on the sidebar, and you open/collapse the Tools menu.--151.42.0.114 13:17, 18 May 2022 (UTC)

Sidebar

The sidebar has extended a bit (and by that, I mean a LOT) too far, which makes things very uncomfortable for me. I'm fine with the skin other than that, but the overintrusive sidebar is just awful. Plus, there are these white extensions to it that shouldn't be there. I hope you understand what I'm talking about, and at least take notes on it! ARandomPage (talk) 11:33, 19 May 2022 (UTC)

Зробіть для кожного коментатора окремий відділ

Привіт я досі не можу зрозуміти чому кожен коментатор не може писати окремо це набагато зручніше...

Новий дизайн набагато простіший в візуальному плані але до нього треба звикати)))

Також я побачив що новий дизайн не працює в деяких мовах Ilolg (talk) 14:34, 19 May 2022 (UTC)

Some incoherence

Hey there! To begin with, I want to make it clear I've got nothing against updating the desktop experience at all. I wanted to make it clear in case I seem like a person ranting something like, "Give me back my good old skin!121".

What I think is that by making the skin you folks tried to reconcile the legacy appearance with some modernity. A good point, though the effect is not as optimistic. The top buttons (edit & history & etc) that retain the legacy shadowing do not fit in with the new cohesive background as seen in the left-hand sidebar. I'd consider re-adapting the former so that they better suit the new design. Mustafar29 (talk) 10:05, 20 May 2022 (UTC)

A few more issues with the Page header vs Sticky header icons

Tracked in Phabricator
Task T338923

Premise: I agree with the comments above that an update can only be a good thing; I'm sending kudos to all the teams working behind the scenes; and I only started using Vector 2022 a few weeks ago - noticing that it gets better each day. I'm not sure if the issues I'm having are slated to be improved or are haven't yet been considered.

1. Lack of coherence in the sticky header iconography I frequently work on the special pages where the sticky header is absent which makes it frustrating when I move to another page (article page) and it appears and then back to 'edit' or 'view the history' of a page and it disappears again. I feel that I should be able to move from page type to page type without noticing drastic changes in the header.

2. Order of icons and functionality is different between the sticky header and page header - specifically some items disappear completely, some move from one area to the next and others are simply re-ordered. (Until just now I thought the search bar had been remove but I just found it as an icon that was pushed to the extreme left hand side after the article title. Now I understand the others who said that with a 27" monitor the left side icons are essentially out of sight.)

• Examining the two headers more in detail we see that the icons seem to be in the same place which makes it hard to notice they are different. Starting from the right, we see that the icons are identical in both therefore, we naturally expect the two (people) dropdown menus to contian the same items.
• Moving towards the left we see two icons with a star which pertain to the same semiotic sphere yet actually have different functionalities. One icon (that looks like a drop down menu but isn't) takes you to your watchlist while the other simply indicates whether the current page is on your watchlist and fuctions as a toggle to add the page if it isn't. There is a futher issue with how similar this icon is to the 'Contributions' icon, making it hard to distinguish for those of us who have bad eyesight - but that is an issue for another post.
• Continuing to the left, the issue becomes more confusing. 'Your notices' from the page header disappears (or maybe I just haven't found it yet) and the text menu 'View history' moves into the sticky header as an icon -the tool tips are the same in both and they are basically in the same position onthe page, which helps a bit.
• And with the final icons (still moving left) the 'Your alerts' bell disappears (or hasn't been found) and the 'Discussions about this page' transform from a text menu on the left into an icon on the right, at least the tooltip is the same. I have to admit that it's not clear to me why my user name is only visible on the page header and then moves under the person icon in the sticky header. It's not exactly a problem in itself, but it does add to the confusion of icons and functionality that seems to jump around from page to page.
• Finally, it seems that the “Edit” and “Edit source” functions have disappeared along with the special menu items of “delete”, “purge” and “move” unless you scroll back up to the top of the page. I believe these issues have already been mentioned by others above.

Again a big thanks to all of you working hard to update the interface and the 'restyling'. I hope when this is all finished, the sticky header will be unobtrusive and not noticeable like the ones normally found on modern webpages. --Lepido (talk) 21:07, 20 May 2022 (UTC)

Left menu too wide

The main menu on the left is too wide and makes the rest of the page appear too cramped in relation to the menu. Urban Versis 32 (talk) 00:02, 24 May 2022 (UTC)

The TOC, again

It just makes all look too narrow and tight, at least to me. I've been working on various lists projects recently and now they all look god awful because they had the old look in mind. Tintero21 (talk) 02:08, 24 May 2022 (UTC)

I prefer the old version

It's cool but I prefer the old version. Super ninja2 (talk) 07:18, 24 May 2022 (UTC)

suggestion: collapsible table of contents

the appearance of the site is far too narrow. i would suggest making the table of contents collpasible to the left. Lettherebedarklight (talk) 12:02, 24 May 2022 (UTC)

Me too. Also could be hidden, in options, so the user can read better the text. Now, it is too narrow and tight. --BoldLuis (talk) 13:04, 24 May 2022 (UTC)

Line under title colliding with coordinates

Tracked in Phabricator
Task T310369

See image. The horizontal line under the title collides with any coordinates that are displayed on the top right. --MimiKal797 (talk) 14:56, 24 May 2022 (UTC)

Even I wanted to state this same issue. Excellenc1 (talk) 16:00, 24 May 2022 (UTC)

Also the floating title can obscure content. For example, open the front page of Oberon and scroll to the bottom. Click on instance "a" of footnote 43. That should take you to "MT, in V5, the constant address ...". In fact, the next glossary entry "native, modifies the name ..." is displayed. Not a terrible defect but baffling for a novice trying to learn. Thx, ... PeterEasthope (talk) 00:08, 25 May 2022 (UTC)

I came here for a MeToo (about the coords/line collision). Classic Vector does not have the problem. Also, I think the languages dropdown is uncomfortably close to the coordinates; if you hover over that button you can see they overlap, which generates cruft when the dropdown is activated. Did anyone write up a ticket? DavidBrooks (talk) 15:35, 9 June 2022 (UTC) - OK, I did: T310369 DavidBrooks (talk) 15:19, 10 June 2022 (UTC)

This is being discussed in en:Template talk:Coord#Coordinates bad positioning. Jdlrobson (talk) 21:32, 10 June 2022 (UTC)

Great GUI

Everything looks very appealing to me. I think the blank left space really aids in reading as the width of the line reduces its easier for me to not to confuse the line which I have to read next. Overall I loved it. One suggestion that I want to give is that it would be very nice if you could change the visual of the tab. It looks a little too classic to me and would be very nice of you if you could add dark mode ( I don't know if it already exists), this I think would give a very appealing look to the website . Thank You. Special:Contributions/ 17:59, 24 May 2022 (UTC)

If you ever want to reduce the width of the lines you are reading, I suggest you just resize your window, as the elegance of desktop browsing is that it gives you control over the size of the page. As for me, this layout takes away that control. Using it, I can no longer read an article with the full width of my screen without fiddling with my common.css, a luxury that would not be available to me when I'm not logged in, and am instead forced to use ~2/3 of that width, even when the window is reaching into every corner of my screen. There are several ways of using dark mode on wikipedia listed here, but I agree it should be made easier. --SmallJarsWithGreenLabels (talk) 16:42, 25 May 2022 (UTC)

Feedback

I was prompted to give some feedback on the 2022 Vector skin, and I have to say that it needs a bit more work.

• The mix of new and old UI elements doesn't look good; specifically the View, Edit, Edit Source etc. menu bar looks out of place among the flatter new UI
• There's uneven and unnecessary padding around the left pane with the many links that can be filled with the pane
• There should be an option to have the content filling any display larger than 4:3, as most displays are 16:9. I understand the argument that it helps some people in reading but having an option is better, as it doesn't help all people. Additionally, a poll should be run in all Wikimedia projects on which one should be the default (4:3 or full width) — Dimsar01 (talk) 23:33, 24 May 2022 (UTC)

Here is My feedback

• I see that the sections are not properly sectioned on the screen
• I am using dark mode and when I want to add reference or qualifier or something like that, I see a white suggestion screen

All in all I can say for now is that I really needs more work done and I can prefer the older one for now thank you Micheal Kaluba (talk) 05:58, 26 May 2022 (UTC)

Short description

It would be great to have the short description visible on pages, like it is on the search and on mobile, so users can more easily edit them and identify information.

Like said by other users, the mix of new and old UI looks bad. The most recent prototype, for all its faults, had a well unified UI. I also think that the page tools (and "In other projects") should be separated from links for the whole website like was done in the most recent prototype, though there were many flaws with that execution (see my comments), and all those links should be condensed by default. "Beginning" should definitely be named "Lead" or "Lead section", like said by others.

I really appreciate the effort that is going into this. I think the vast majority of these changes are for the better, it just needs more work. BappleBusiness (talk) 00:32, 25 May 2022 (UTC)

Software Gore

Software gore

This is pure software gore. If you want to explain to me why it's like this, you're wasting your breath. I've edited Wiktionary for over a decade and I understand how it's come to look like this, and I don't even have a solution to propose. But I feel terrible for anyone trying to navigate this mess for the first time. —Pengo (talk) 00:54, 25 May 2022 (UTC)

Watchlist tooltip

Hi folks! I'm vaguely used to the watchlist icon (since I've switched themes many times over the past decade or so, and use the mobile app/website), but I still need to resort to the tooltips when I'm on my desktop. It would seem I'm not the only one that takes a moment to mentally translate the icon to the concept in my brain (per @Nardog: 's earlier #Watchlist icon comment). I may stay with "Vector 2022" over on commons.wikimedia.org after trying it out for a bit, but please: could y'all change the tooltip so that the word "watchlist" is in the tooltip? Currently, the icon sports the the very verbose tooltip: "A list of pages you are monitoring for changes [Alt+Shift+I]", which takes a moment for me to mentally translate into "oh, they're trying to say 'Watchlist'!". It would be helpful if (in addition to the keyboard shortcut), the tooltip also gave the mental shortcut, perhaps with the phrase: "Watchlist: your list of pages to monitor for changes [Alt+Shift+I]". Since I'm guessing y'all aren't changing "watchlist" to another word, I can imagine it would be helpful for new users too. -- RobLa (talk) 04:12, 25 May 2022 (UTC)

Yeah, given all the other tooltips are just "Your alerts", "Your notices", and "User menu", it seems to me it should be simply "Watchlist" or at best "Your watchlist". Nardog (talk) 04:22, 25 May 2022 (UTC)

I want the code to make the sidebar TOC disappear

Please. Ping me. Bageense (talk) 05:46, 25 May 2022 (UTC)

It's probably not too hard since there seems to still be a ‎<mw:tocplace>...‎</mw:tocplace> element left -- you need to grab the element, move it back and do some style fixups. Kinda like w:zh:User:Artoria2e5/Gadget-sidetoc.js but backwards. --Artoria2e5 (talk) 11:43, 26 May 2022 (UTC)

Ah well, I am pretty convinced that having ‎<mw:tocplace>...‎</mw:tocplace> but not the actual TOC hidden there is a bug now. If that gets fixed, it should be just some CSS work in your vector-2022.css:

#mw-panel-toc {display:none;}
#toc {display:block;}

May need to sprinkle on a bit of !important. ping Bageense --Artoria2e5 (talk) 11:55, 26 May 2022 (UTC)

Yep, TOC disappeared, leaving a blank space. Bageense (talk) 16:55, 26 May 2022 (UTC)

Well, just gotta wait until they come to their senses. Artoria2e5 (talk) 00:55, 27 May 2022 (UTC)

Space for article too narrow

The article took up less than the full width of the screen in the old skin, but the increased padding and needlessly wide sidebar here make the usable region even smaller. This just reproduces the issues that have had to be worked-around on mobile, including some tables being too wide to fit in the space and causing horizontal scrolling, creating the need to scroll further to get between sections, as well as causing some large image thumbs to squish the article text into narrow strips. In my opinion, the sidebar, which I think most readers rarely make use of anyway, should be consigned to a modal rather than taking up even more space, so that the article can appear centred all the way down the page. This would make room for fairly wide margins on either side without causing as many issues. (I suggest this because it seems the most noticeable "improvement" here is the addition of extra whitespace, but really, what is wrong with making full use of the window width you are given?) SmallJarsWithGreenLabels (talk) 15:50, 25 May 2022 (UTC)

I came here to complain about the same thing - limiting the width of the pageview doesn't make sense when you have a lot of text to display. Especially the discussions became harder to read. 78.11.223.83 06:29, 26 May 2022 (UTC)

TOC should make the page slowly scroll to the right section, and not just jump

By the way, I'm still waiting for the code necessary to deactivate the lateral TOC. I've already disabled the sticky header by using .vector-sticky-header {display:none;} Bageense (talk) 07:51, 26 May 2022 (UTC)

That would make it take longer to get where you want to be, and prevent the user from scrolling during the time the page is sliding. The current TOC works using anchors linked to IDs, which means you can get back to where you were by simply paging back, but this, I think, would not be possible if the links were actually buttons triggering JavaScript animations. SmallJarsWithGreenLabels (talk) 08:14, 26 May 2022 (UTC)

TOC not appearing at all

It seems that Vector 2022 is not showing any TOC -- neither the regular one nor the side one -- when it probably should. I noticed this issue about a couple of days ago but assumed it was an error on my side. Today I checked out w:Dmitri_Shostakovich, tried to add a __TOC__ magic word, found out it does nothing, and then realized it's the skin that's broken when I retried in a logged out private tab.

In a private tab:

• https://en.wikipedia.org/wiki/Dmitri_Shostakovich?useskin=vector-2022 has no TOC right now, but
• https://en.wikipedia.org/wiki/Dmitri_Shostakovich?useskin=vector has a TOC.

What's going on here? Artoria2e5 (talk) 11:35, 26 May 2022 (UTC)

One refresh later it's showing the side one. I must be descending into some sort of madness. Artoria2e5 (talk) 11:37, 26 May 2022 (UTC)

Annd it's gone again. No outstanding errors in the console. Seems to be sone @media screen { ... .sidebar-toc {display:none; ... in one of the many load.php's ([1]). What. the. heck. Artoria2e5 (talk) 11:48, 26 May 2022 (UTC)

The intention of the code seems to be to show the sidebar only for screens wider than a value. That's a good idea, but only if the original TOC is not removed! --Artoria2e5 (talk) 11:50, 26 May 2022 (UTC)

Bold, yet very appreciated changes

At first I didn't like it. My first thought was that it took more space, so I got less content in my screen. I compared it side by side with the old skin and in fact, elements got more margin. But after giving it a try, reading and moving through the article, I fell in love. I really like that the TOC is now on the left and moves along with the page. It was OK before but now it feels fancy. And I feel more people are going to benefit from it now. The cleaner, more "plain white" look is nice.

I understand the decision of limiting the width of the page on (very) wide screens. In my opinion, it is a sensible design decision that improves readability. Because if lines get too wide, it can make it harder to read. Maybe this "max-width" setting can become a thing users can tweak?

I tested this new skin on a modern computer and a 1440p screen. If I were to use my old laptop, I'm sure I'd like to have the option to change to the old skin. As it fits more content and uses less CPU resources.

I appreciate this changes, and feel they are for the better. Thank you! -- Zazke grt (talk) 06:42, 27 May 2022 (UTC)

I've temporarily switched back to the old Vector skin in Wikipedia because some pages like this one Wikipedia:Portal:Video_games have their contents very croped or overflowing their boxes. --Zazke grt (talk) 06:49, 28 May 2022 (UTC)

TOC not immediately visible

Tracked in Phabricator
Task T309632

I am going to refrain from complaining too much as I'm prone to do with any and all UI changes :)

However, I do find the placement of the TOC particularly problematic. Personally the first thing I do when landing on a Wikipedia article is, usually, click on something in the TOC. Having to scroll down first to find it is, to me, very frustrating. Argymeg (talk) 12:24, 27 May 2022 (UTC)

Better font for Arabic/Persian فونت بهتر برای فارسی/عربی

As a Persian user, I think font of wikipedia is not good for these languages; Maybe Vazirmatn or other open-source good looking fonts could be better.

به عنوان یک کاربر ایرانی، من فکر می‌کنم که فونت ویکی‌پدیا برای فارسی و عربی جالب نیست؛ شاید وزیرمتن یا سایر فونت‌های منبع‌باز که ظاهری خوبی دارند انتخاب‌های بهتری باشند. Amiria703 (talk) 22:27, 27 May 2022 (UTC)

It seems like the Page Previews isn't working for me here

Although the new skin looks more sleek, I can't use the (very useful) feature of Page Previews here. So every time I'm in for a deep read, I have to switch back to the old look. Please implement the page previews here too. SamyakShirsh (talk) 03:31, 29 May 2022 (UTC)

Hi there! Thanks for the report! Could I get some more information on this issue? Page previews is working for me on both Vector and Vector 2022 skin. Are you talking about the user gadget https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups ? Jdlrobson (talk) 21:28, 1 June 2022 (UTC)

Use the white page on the right for TOC and navigation

The mobie version of wikipedia app has this really nice way of navigating through sections by swiping eight. I think you can imlement this in the desktop by placing the toc on the right SamyakShirsh (talk) 03:35, 29 May 2022 (UTC)

Lone value inside calc()

The style sheet of the new sticky table of contents uses .mw-table-of-contents-container { top: calc(-2em); }. Is there a reason for putting a lone value inside calc()? Anerisys (talk) 09:22, 29 May 2022 (UTC)

Thanks for flagging.

The patch introducing this is:

https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/789691/5/resources/skins.vector.styles/layouts/screen.less

The use of calc is accidental, and I think a mix up our end with the appropriate LESS mixin. Jdlrobson (talk) 21:40, 1 June 2022 (UTC)

Opt-in/out for page tools?

There've been a few discussions on this page about the page tools links, but one possibility I haven't seen mentioned here or at Reading/Web/Desktop Improvements/Features/Page tools is providing a way for each reader/editor to choose which links appear. For example, I use "what links here" quite a lot, "related changes" and "random article" occasionally, and all the others virtually never. Other editors will have different experiences. How about allowing us to reduce clutter by choosing what we want to keep in the menu and what we can do without? Arms & Hearts (talk) 19:47, 29 May 2022 (UTC)

+1. I just want to say this was the last straw that made me force legacy Vector on all sites in GlobalPreferences. Is there no opt-out aside from putting tableofcontents=0 in the URL? No "Expand all" button? Why is there a blank space beneath the ToC? Why fade it out rather than show as much as possible? This is just user-hostile. Nardog (talk) 16:16, 31 May 2022 (UTC)

Tabs misaligned?

The tabs on the left seem to be next to the tabs on the right, as depicted here. This wasn't the case last week; should this be reported here or elsewhere? Please move if need be. Ifly6 (talk) 07:01, 31 May 2022 (UTC)

Hi there, could I get a little more information on this one? What browser and device are you using? Are you viewing this on a mobile phone by any chance? Jdlrobson (talk) 21:23, 1 June 2022 (UTC)

TOC hidden for some reason

Tracked in Phabricator
Task T309632

When I put my Wikipedia tab to one side at half-width, which I often do whilst multitasking, the TOC disappears for some reason, even though the other side menu (which is the same width as the TOC) stays? I am clueless as to why. All article text is pushed way to the right for some reason. It would make more sense for it to be centred on all screen widths, or to make the entirety of the left menu a solid colour like it was before.

Basically, the sidebar should be made thinner as the tab width decreases.

Also the lack of a TOC below the lead results in images fighting for space with the infoboxes of articles. There should definitely be an option to move the TOC to where it normally resides as I and likely a lot of other editors find that placement more intuitive. Miklogfeather (talk) 16:06, 31 May 2022 (UTC)

My whole left sidebar has disappeared this morning. I had to switch themes just to get some editing done. — Xenophore (talk) 19:42, 6 June 2022 (UTC)

My many criticisms with this

Since it seems like Miraheze is also going to be using this new Vector skin as its default, I would like to offer mine and a lot of other users' criticisms with this new skin:

• First of all, the unnecessary dead space. The actual content space is now more narrow and there is a ton of dead space.
• The user menu is now completely messed up. The log in button and talk and contribution buttons are hidden behind the three dots, even though those are the most important buttons and should be readily available. In fact, there is no need for anything to be hidden.
• The giant TOC in the sidebar. It serves no purpose and just further limits content space.

I fail to see how exactly this is an "improvement". Also, the current layout of the skin looks nothing like what is described on the page. There is nothing about a smaller user menu. Currently, the new skin just feels off to me, and I would prefer that this skin be currently branded as "experimental", since it is far from finished. Blubabluba9990 (talk) 21:41, 5 June 2022 (UTC)

I'm fine with everything except the user menu changes and content width changes. Blubabluba9990 (talk) 21:50, 5 June 2022 (UTC)

Hello @Blubabluba9990. Have you maybe read our documentation where we present the reasons why particular changes are needed, why we've introduced the limited width, and what we're taking into consideration regarding how to use the unused space? I invite you to explore this page and its sub-pages. SGrabarczuk (WMF) (talk) 19:11, 8 June 2022 (UTC)

I already did. I read through them more thoroughly and while some seem like a good idea on paper, the user menu and limited width do not really seem to be an "improvement", as there are now extra steps involved. The user menu is the most important thing for me and many users, and now I have to click on a separate button to log in. Maybe less limited width, since right now 1/4 of the screen is just empty space with the new skin. I still use the original Vector as my personal default, but I usually browse logged out. Blubabluba9990 (talk) 22:40, 8 June 2022 (UTC)

Visibility Suggestions

Hi, first of all thanks for the work and the nice redesign. I really prefer it over the old vector look already.

I use Wikipedia mainly to get an overview or better intuition about topics related to my studies. For me, I prefer the narrower text for better readability and the persistent TOC on the left side of the screen. Makes reading complex pages a lot less painful with easy access to quick navigation.

I have some suggestions for the default behaviour of the current design:

• There should be an option to collapse the navigation sidebar/area by default (the area which contains Main page, Contents, Current events etc.). I am one of those people who rarely uses any of those links.
• More of an issue is due to this: The TOC is not always immediately visible as the navigation sidebar pushes it too far down. Perhaps move the sidebar to somewhere else or make it collapsible by default as suggested?
• Additionally, It should be more obvious that the navigation sidebar/area is collapsible. Currently the toggle is kind of far and disconnected from the area. I only found this out after wondering what that arrow << meant.
• A nice addition would be to add more obvious indicators for current position in the TOC (loved this new feature the most!). I think right now the text of the current headline is just black. It would be cool if there was some highlighting or perhaps a dot to make it easier to see at a quick glance.

Devin.halsted (talk) 11:21, 8 June 2022 (UTC)

I just noticed, that the toggling of the navigation sidebar/area does indeed persist. I just didn't notice because i switched between too many tabs.

Something other I noticed, is perhaps that would be good for scrollable TOC to be more visibly "scrollable"? Right now there is no indication except that maybe some text is cut off. Devin.halsted (talk) 11:27, 8 June 2022 (UTC)

Fifth prototype testing

Moved from Topic:Wx2jt9he9u1ipkpb

Nothing about sticky header? The order of icons, the present icons for IPs, etc. NGC 54 (talk) 17:08, 8 June 2022 (UTC)

Thanks for this comment, NGC 54. As we explain on the page of the fifth round of prototype testing, that round will only be dedicated to considerations around the visual design. Pure aesthetics. The order of icons, selection of icons for IP etc., are functional considerations which may be discussed right here, on this talk page, regardless of the 5th prototype testing. SGrabarczuk (WMF) (talk) 15:38, 8 June 2022 (UTC)

General Feedback on Sidebar

I agree with other feedback that complains about the sidebar being to wide. This is a waste of space, please reduce the width a bit. However, I think it's not the width of the container but the left margin that makes people (including myself) upset. Therefore, I suggest to completely get rid of the left padding of the main container. Also please reduce the left margin of the article container to just 10 or 20 px. Even more space is wasted if the side bar is collapsed: Why is the sidebar positioned higher than ToC? This leaves free space on top of it.

You discussed that the lines of text would be too long otherwise. You could significantly reduce the length if you moved the side bar from the left side to right. You then would have (from left to right) ToC, article, sidebar.

Furthermore, the ToC should be on top of the other sections because for most people, ToC is more important than the other links. Although I understand the intention behind this to invite more people to contribute to Wikipedia, I still don't like it. GeographyMasterDE (talk) 09:16, 9 June 2022 (UTC)

JPG screenshots

Just to point out that this page, in which supposed design gurus are offering a lifeline to a wikipedia supposedly plagued by unsofisticated looks, is illustrated with screenshots saved in JPEG format… Tuvalkin (talk) 14:33, 9 June 2022 (UTC)

Limited Content Width

I want to state my opposition the limited content width. I understand the research that the narrower format improves readability. However, there are number of good reasons not to adopt the change:

• Yes, many sites do use fixed width content, but in many cases their motivation is to use the space to sell advertising – a function not befitting Wikimedia. (Some news sites, such as those run by Gannett have even taken the theory one step further and display all their articles as overlays – meaning that if a user accidentally clicks in the shadowed area on either side, they are frustratingly taken back to the homepage.) For this reason, full width content suggests a more reputable website. It implies a dedication to the facts, rather than attempting to fill the page with flashy content. (A different website has a more profane take on the concept. It doesn't deal directly with the issue at hand, but the underlying issue is the same.) This change just seems like another case of mobile overoptimization.
• Additionally, as correctly the noted at the end of the page on the change is "part of what makes Wikipedia, and other Wikimedia wikis, a powerful tool for sharing knowledge is that there are very few constraints on how information is presented." For example, it's the reason that widths are specified in "ems" rather than number of columns in the div col template. Don't get me wrong, I very strongly appreciate the need for a common standard. I have fought for it on Wikipedia. However, this is not the place for it.
• It is clear to me that the majority of commenters here strongly oppose limited content width. It is not to be confused with people just being afraid of change. Note that there are far fewer complaints with most of the other proposed features. I don't have access to the survey results, but a sample size of 230 users seems exceedingly small for such a major change. Furthermore, the commenters here are likely to a better representation of the dedicated portion of the userbase, as they took the time to respond here.

I would like to end by stating I am not completely opposed to the change. However, it should only be opt-in, not the default skin. –Noha307 (talk) 03:23, 10 June 2022 (UTC)

Width and font size and color

As above, I don't like adding so much margin around the sides, or punishing people with large monitors by forcing them to change skins (which is not easy for everyone). If you are set on fixed-width columns, find a way to wrap columns within a section for wide screens :) rather than leaving huge vistas blank.

I like the move to slightly larger font.

The link color changes are most welcome. The purple could be a bit more red, to make it less pastel. Good to have a combination of "high contrast w/ other text" and "doesn't wash out on displays or projection in bright areas". Sj (talk) 00:27, 11 June 2022 (UTC)

Section number in new ToC

I noticed that there is no section number in the new ToC. I hope the section number will be added again because I can quickly see how many topics there are on the talk page. Bluehill (talk) 07:28, 11 June 2022 (UTC)

Move infoboxes out of the text area

Given that we are limiting the space for text and freeing up space on the sides, it seems to me that it would be much better to move the infoboxes to the left side, and stretch the text to its full width. Like this: https://znaniya.org/c/pushkin-aleksandr-sergeevich-8cab44. Iniquity (talk) 23:50, 11 June 2022 (UTC)

I second this. Such a shame that this request is already explicitly rejected in the FAQ. Adamant.pwn (talk) 14:15, 14 June 2022 (UTC)

@Iniquity & @Adamant.pwn, generally, we agree that it is a nice idea. From a reader's standpoint, infoboxes aren't pure content - rather, these are metadata and could totally work as something put next to the content area. However, these are absolutely content from the technical point of view (because these are regular templates). This issue makes it... impossible? to move them. For underlying infrastructural/back-end reasons I can't explain yet.

However, there's a turning point. What would we work on after the Desktop Improvements? We're considering options for functionalities put in that (currently) empty area. So this topic may be revisited in the future. SGrabarczuk (WMF) (talk) 19:45, 14 June 2022 (UTC)

@SGrabarczuk (WMF), thanks for the answer! Note: We can create a separate edit area that will be responsible for the infobox, or we can move the infobox using HTML :) Iniquity (talk) 19:58, 14 June 2022 (UTC)

July?

> We are hoping to increase the set of early adopter wikis gradually, until our improvements are default on all wikis in July 2022.
Has the schedule changed? Iniquity (talk) 00:57, 12 June 2022 (UTC)

It has, @Iniquity. Previously it was June, now it's July. SGrabarczuk (WMF) (talk) 16:13, 14 June 2022 (UTC)

@SGrabarczuk (WMF), thanks! It's just strange that there was no information about this before. And the wikis was not informed about it. Iniquity (talk) 16:15, 14 June 2022 (UTC)

Information was sent yesterday in Tech News. Also, this week, I'll send an update to the Village Pumps. SGrabarczuk (WMF) (talk) 17:30, 14 June 2022 (UTC)

Yes, I saw it, thanks for that! But the day before yesterday, when I saw this, I got scared, because the community was not ready for this. Iniquity (talk) 19:59, 14 June 2022 (UTC)

We work with individual communities to help them prepare. We also don't ask the most "demanding" communities to prepare yet because Vector 2022 isn't ready to get deployed there either. We take into account that some prefer Vector 2022 to be closer to "finished", and then they would start thinking about preparing. SGrabarczuk (WMF) (talk) 22:17, 14 June 2022 (UTC)

Incorrect language name for Czech

I noticed that for Czech (čeština in Czech) in the new look the first letter is incorrect, it says "Ceština" instead of "Čeština". I do think it is pretty funny, but would say it should be consistent with the rest of the themes.

I hope this is the right place for this, I didn't find anywhere else to post. Filiptronicek (talk) 09:46, 13 June 2022 (UTC)

Hello @Filiptronicek. Thanks for writing to us. Most likely, it's not within our area, but I'll help you if the problem still exists. Where do you see this? On Polish and English Wikipedias, I see "Čeština". SGrabarczuk (WMF) (talk) 12:42, 14 June 2022 (UTC)

Hi there @SGrabarczuk (WMF), perhaps it may have something to do with Czech being suggested to me as a language? I don't have an alt account to test this with though.

Screenshot of what I see on the English wikipedia: https://i.imgur.com/T40u7rN.png. It is some very interesting behavior. Thanks for looking into this. Filiptronicek (talk) 13:45, 15 June 2022 (UTC)

Please take the interlanguage link (aka "green link") on Chinese Wikipedia into consideration!

The Chinese Wikipedia currently uses a green-colored link for interlanguage links in articles, and it seems to fail the WCAG AAA. These links can been seen at zh:Deadmau5, for instance. These links are used a lot on Chinese Wikipedia, and I'm not sure if it is good for readers. If you want to evaluate link colors, please also take this green link into consideration, thank you. Looking forward to your professional advice! Diskdance (talk) 11:38, 13 June 2022 (UTC)

I know these links are not part of Vector 2022, but they are part of the user experience, and currently there is a discussion at Chinese Wikipedia's Village Pump about the choice of color of them, so I posted my message here. Diskdance (talk) 11:43, 13 June 2022 (UTC)

Table of content (ToC)

Hi! Since weeks ago I don't see the table of content in the sidebar like I used to do before. It just disappeared. It happens when I'm connected in my phone using desktop version. Best regards! Miaow 12:06, 13 June 2022 (UTC)

Hello @Miaow. Thank you for reporting this problem. We're working on a better look of TOC on small screens. I also strongly suggest you selecting the advanced mobile contributions mode when you're using your phone. That mode is dedicated for mobile, in contrast to Desktop Improvements. SGrabarczuk (WMF) (talk) 10:38, 14 June 2022 (UTC)

Better alignment for wide screens

Here's how the new design looks on my laptop with 2560x1600 resolution. Ok, I get it, you won't do anything about the max-width and you insist on using this path. But look, the parts highlighted with purple ellipses just look misaligned. It just begs for the following:

• Reduce the white background so that its right end matches the right end of the article OR insert something into that area. Having gray empty space is ok, but having both white and gray empty spaces look just silly.
• Reduce the header so that its right end matches the right end of the article OR extend the white background of the header so that it fills the whole width of the page (see e.g. how it's done on StackExchange or Reddit.

Again, I get your rationale that having empty space is ok. But having a white empty space on top of the gray empty space... Don't you think it's a bit too much? Adamant.pwn (talk) 01:23, 14 June 2022 (UTC)

Material for MkDocs is another example of what I consider a more successful implementation of reduced max-width. The main part has the same background (having same white background on the whole page would also look good on wiki) and the header part has background that extends beyond max-width. Adamant.pwn (talk) 01:25, 14 June 2022 (UTC)

When we look to the prototype https://di-article-tools-2.web.app/Blue%20whale?en (and https://vector-2022.web.app/Brown_bear), it's fill by "Tools", "In other projects", "Print, share, link" Koreller (talk) 08:31, 14 June 2022 (UTC)

It looks somewhat nicer, but the white empty space is still there if you collapse sidebars or scroll a bit... Also seem to have different defaults for logged in and logged out users. Adamant.pwn (talk) 14:12, 14 June 2022 (UTC)

Launching New Version

Moved from Topic:Wxf5fv5pmxyyccdy

When shall the new version (Fifth prototype) be launched? Stnts256 (talk) 08:54, 14 June 2022 (UTC)

We hope to launch Vector 2022 as default by the end of July. You can use it already by selecting this option in your preferences. SGrabarczuk (WMF) (talk) 12:28, 14 June 2022 (UTC)

Thank you SGrabarczuk Stnts256 (talk) 14:04, 14 June 2022 (UTC)

Keep watchlist in the sticky header

For an active Wikipedia editor, watchlist is likely the most popular destination when you're on some page. Would be great to keep the link there in the header, even after some scrolling. Adamant.pwn (talk) 14:24, 14 June 2022 (UTC)

Keeping alerts and notices would also be nice. And also for it to work on the talk pages... Adamant.pwn (talk) 14:26, 14 June 2022 (UTC)

Yes, it bothers me that my control panel disappears. Iniquity (talk) 16:01, 14 June 2022 (UTC)

Second that. The most-used buttons of the standard interface (watchlist, contribs, interwikis) should stay in place, accessible with one mouse click. With the proposed layout I have to press tab-tab-tab... and then ctrl-enter to get to the watchlist. Why so? I can't reliably use the proposed drop-down menu with mouse, it's a common age-related ailment. I'd highly recommend to retain at least some bits of usability-for-disabilities: no complex manipulations. Retired electrician (talk) 09:39, 15 June 2022 (UTC)

clear:both rendering on old browsers

Tracked in Phabricator
Task T309711

I have tried browsing the wiki on Internet Explorer 11 on the new skin for one last time before Microsoft disables it, and it worked well, except something I have noticed is that the CSS property @media screen .mw-body-header::after { clear:both; } causes the side bar to push down the content. When unticking clear:both in the page inspector or when the side bar is hidden, it appears as usual. While fixing it for IE11 won't be relevant anymore, earlier versions of other browsers might have this flaw too. Mentioning it just in case. Octobod (talk) 23:29, 14 June 2022 (UTC)

Where are the interwikis?

Is there a simple way to access interwikis, other than by going to wikidata? Also, having two quasi-interwikis for wikidata is quite confusing. Only the second one actually works, the first one defaults to wikidata's start page. Retired electrician (talk) 09:46, 15 June 2022 (UTC)

@Retired electrician - currently, the adding interwiki links is available from the sidebar: "Edit interlanguage links" in the tools section. In the future, we would like to add them into the language selector as well. We are currently working with our Language team on this - see Add support for empty states to the current language selector in phabricator for more details. OVasileva (WMF) (talk) 13:23, 16 June 2022 (UTC)

@OVasileva (WMF): , I see. Curiously, "Edit interlanguage links" does not appear on the main page (at least in ru-wp). Retired electrician (talk) 13:50, 16 June 2022 (UTC)

Suggestion: Round borders

I appreciate very much the efforts to make the design of Wikipedia less outdated, and imo this new design is amazing. To make it even better I would suggest you guys to put round borders in the boxes, so let's add border-radius:14px in these functions! This will make it cleaner and softer! Duke of Wikipädia (talk) 22:27, 16 June 2022 (UTC)

Top margin in title

Just noticed the new version and it looks like the title's top margin was reduced. There is an awkward amount of bottom margin for the title compared to top margin and I personally prefer the previous margins. 0xDeadbeef (talk) 06:55, 17 June 2022 (UTC)

Very minor improvements

I just got the new toolbar this morning, and I absolutely love it! Finally Wikipedia does not look old anymore. But I would like you guys to add a little more than just a border for the active section in the toolbar, probably a lighter background for active tabs and a darker one for non active tabs.

For example, if I'm reading an article, the 'Read' tab in addition to the bottom border, it should be lighter. The 'Talk' tab should be lighter also if I'm in the talk section. This should work well with something like option 3 combined with option 9 (where the header and the title has grey background) in this border and background demo here. I like option 3 a lot so it would be good if you guys implemented it, haha.

I apologize if my English is not clear. Klrfl (talk) 12:26, 17 June 2022 (UTC)

new table of contents

For pages with a long table of contents such as this one, the table of contents starts jumping to highlight the current heading. Would it be possible to consider smooth scrolling behaviour for the table of contents at the new location (as for example invoked by .vector-toc-enabled .sidebar-toc { scroll-behavior: smooth; })? Or is there something like a frozen state or is/was/will be this rejected for another reason? --CamelCaseNick (talk) 23:15, 17 June 2022 (UTC)

Support Patafisik (talk) 10:06, 21 June 2022 (UTC)

Sister project links

(From it.wikipedia)

@Friniate: suggests to gather the Wikidata link and the Sister project links in the same place.--Patafisik (WMF) (talk) 09:49, 20 June 2022 (UTC)

Impact

How does the team plan to assess/measure whether the Vector changes work towards their stated goals, so that we're able to correct course in case they don't? Nemo 00:41, 21 June 2022 (UTC)

Great addition of ToC menu through icon wrt zoom !!!

I have just discovered a few days ago, in the french version of WP, as well as here in MediaWiki, the addition of a ToC menu, just before the title, that appears when the left column is NOT visible (at least effect of zooming), and this is a GREAT GREAT improvement, MANY-many thanks to the developpers.

There still remains a small bug that appeared with this change (at least I didn't notice it before) : the upper (collapsile) bar appears no more. It reappears back when zoom permits back the side left column (tested with an article page in fr.WP ; no appearance "here" while editing, or even while just reading. but I guess it's a different thing, maybe because this is a talk page : I get the same "behaviour" in a talk page from fr.WP : no appearance of the upper collapside bar even if a left colum ToC is present. Might not be a "bug", but a feature, though I would personnaly prefer a uniform behaviour).

Whatever, great thanks to the developers.
  (Poke @Patafisik (WMF) : thanks for relaying these improvements, and back, our comments. Best :-) )
  -- Eric.LEWIN (talk) 06:17, 21 June 2022 (UTC)

Both the ToCs

(From the French Wikipedia here, here, here, here and here)

I've already reported this to Szymon, but I think it will be important to have this suggestion also in this page, visible to all and open to comments.

Different users of the French Wikipedia consider the old ToC and the new one as two complementary tools, and they want both! Reasons: 1) for the context, the ToC should be on the top of the article. If we have the first part of the sidebar occupied by the wiki navigation menu, the ToC is too far on the bottom of the page, it appears on the top only when you scroll down 2) the layout of articles with illustrations is completely disrupted.

Both why?

"When I look at the beginning of an article, I expect to see a ToC with the main sections in order to understand how the article is structured (quite like in a Word document). This makes it easier to read. The ToC on the left is then very useful when you scroll down the article and want to navigate between sections, but it is an additional feature. It should not replace the current summary, which is still useful. Or it should be displayed from the start at the top left, when you are at the top of the article (quite like on Universalis)." (summarised by Pronoia here)--Patafisik (WMF) (talk) 11:45, 21 June 2022 (UTC)

Интервики в правый блок

Сейчас правое поле статьи абсолютно пустое. Что мешает перенести туда интервики-ссылки, вместо их полного сворачивания, а также подходящие по смыслу к ним ссылки на братские проекты? Это позволит: 1) избежать совершенно ненужного сворачивания списка (бессмысленно его уменьшать, когда высвободилось столько места); 2) заполнить правое поле; 3) частично разгрузить левое поле, чтобы оглавление было лучше видно сразу на первой же странице текста (сейчас при текущих настройках экрана я во французской Википедии вижу в среднем две верхних строки оглавления). AndyVolykhov (talk) 12:51, 21 June 2022 (UTC)

Languages in the new desktop interface

In the older interface I can select the interwikis that I need most and put them on top of the interwikis' list; same possibility should be in the newer interface. Leokand (talk) 15:06, 21 June 2022 (UTC)

minor issues

• The position at which the table of contents is sticky changes with the sticky header becoming visible/hidden. (.vector-toc-enabled.vector-sticky-header-visible .sidebar-toc { margin-top: 1.5em } vs. .vector-toc-enabled .sidebar-toc { margin-top: 3.5em }) With the sidebar navigation hidden, this makes the table of contents jump up by 2em while scrolling.
• At a window width of exactly 1000px the table of contents on the left is displayed but styled like the drop-down table of contents and the drop-down button is still visible but has no influence on the table of contents.
• At 720px+ the logo is displayed, the username and potentially a language switcher. With my username on this wiki in German, the watchlist and the user menu are outside the viewport, so this threshold is chosen to narrow. Maybe a solution would be to move the username link to the user menu at 1000px and lower.

(For CSS rendering, I use Firefox v101.) -- CamelCaseNick (talk) 17:28, 21 June 2022 (UTC)

Drop-down menues = poor accessibility

Repeating prior statements for clarity: May I speak on behalf of old folks with less-than-perfect control of palms and fingers. The replacement of simple "button" links (contribution, statistics, interwikis...) with drop-down menues becomes a huge inconvenience. In plain monobook, I can simply click on the interwiki, and hopefully get the desired tab at the first try. In vector-2022, I cannot reliably pull down the drop-down list and then select something with a mouse... it almost never works as intended. A very common age-related ailment, it just happens. The only robust workaround is to use the keyboard to "tab-tab-tab..." to the desired control box, and then "enter-tab-tab-...-enter" through the list. And, in case of interwikis, selecting the main (en:) wikipedia takes atrociously long time - instead of being #1 entry, as in old good monobook with my normal preference settings, it's somewhere down the middle of the list. Retired electrician (talk) 21:46, 21 June 2022 (UTC)

TOC-Feedback

I just recognized what disturbs me the most with the new TOC. I wasn't able to access the TOC without scrolling or clicking when using a community-Page. The main thing: It's mixing system and content. The TOC is for the content, but appearing on a place of "system". The "frame" is the Media-Wikisystem: accessing Community-Pages, Help, recent changes, user-page etc. Inside the "frame" is the content (the "article", the "book"...). Although it's kind of logical to have the TOC sticky on the side there are so many problems with it:

1. the TOC can't be manipulated by magic words, which is a pretty well used functionality.
2. the TOC can't be placed to the right, which is pretty often used in german wikibooks.
3. the TOC is in competition with the other menus.
4. the TOC is now at a place where normally links to other pages are placed.

The same fear of mixing system and content goes with switching the Header and the "Editing-Tabs" (Compare https://di-article-tools-2.web.app/Blue_whale: Blue Whale first, read/edit second). BTW the TOC works at this demo-page because the Main Menu is so short. But since this is not fixed (which is a good thing!), the Main Menu might be longer. A good illustration of the problem is visible just the paragraph above this: #Irish language Wikipedia and Vector 2022. The TOC in the Vector22-Example is completely missing!

So, just as an Idea: divide system and content - say system top&left (as it's always been) and content bottom&right. the TOC could be placed "always right" next to the text. At least please let the editor choose what to do with the TOC. I mean, wouldn't it be so bad if it's within the Content and at the side?

I'm fine with the new skin and all the work that has been put in, but the TOC is becoming unusable for me like it is right now. If it's really becoming permanent, it will probably result in "self-made-TOCs" which will break pretty often, because of the "wiki"-system. HirnSpuk (talk) 17:37, 22 June 2022 (UTC)

The new design is everything I feared

Jumpable, irritatingly movable buttons? Check. Sticky UI that eats up immense space both at the top (header) and to the left (table of contents)? Check. Tiny narrow line of text in the middle? Check. Buttons not looking like buttons, thus confusing me as to what I may click? Check. The language menu made objectively worse, with more clicks necessary to use than before? Check. Every single change is atrocious, negative, and honestly makes me feel depressed - I will either try to scour Reddit for browser extensions to remove as much of it as possible (no, logged in user things are useless to me as I'm never logged in), or I will leave Wikipedia for good (mental health is more important than knowledge).

Just look at this useless eyesore of a sticky table of contents (screenshot on postimage - I hope, you aren't getting the ads, I'm getting none). Even aesthetics-wise, it's botched - the bottom is smudged, the top cut-off. And it's not even at the edge of the screen! It's an exercise in ugliness.

And just saying it here, this Wikimedia redesign is already making it unintuitive for me to write. When I tried to insert the link, I couldn't even see the upload button - because it's on the edge of the sub-menu (like on phones), not somewhere sensible, like on computers (again, compare how it is on current Wikipedia - a large nice menu with clear buttons at the bottom, computer design). Adûnâi (talk) 18:55, 22 June 2022 (UTC)

Menus — https://di-visual-design-menus.web.app/Brown_bear.

• left side menu persistency is screen wasteful, bad idea
  • use a tab like google maps?
• left side menu: should be hamburger only
  • as an option for experienced, registered users
  • need style sheet that puts left side column at bottom of page as a footer
• language list:
  • should include native and english names
  • include a user-customizable shortlist
• 0mtwb9gd5wx (talk) 00:57, 23 June 2022 (UTC)

The "sticky table of contents" is the worst among all the bad changes

I am sorry, but this sticky table of contents is such an eyesore, its sole addition might make me quit reading Wikipedia altogether. I'm not exaggerating, a similar update to Liquipedia made me want to avoid that project. It's more than an annoying waste of screen space - it also makes the different parts of the table of contents bold depending on where in the article my screen is, and thus it triggers my OCD, and it simply irritates me. I hate these moving parts in forced mobile designs.

> "The results of our 3rd prototype testing showed an overwhelming support for the proposed table of contents."

Have they? I don't see any discussion here.

> "The new table of contents will be persistent - users will have access to it at all times. It will also make it easier to understand the context of the page."

Are the TikTok memes reality? Excuse me, but I don't randomly forget what page or section I'm reading, thus I don't need a sticky title on my screen at all times.

> "In addition to that, it will be possible to navigate to different parts of the page without having to scroll all the way back to the top."

How is that "need" in any way difficult? It's one button on the keyboard - called Home. Or you hold the slider on the right and jerk it up in a millisecond. But I suspect I know where "scrolling" is an issue - on mobile phones. This entire update in an exercise in transitioning a fine desktop UI from the 2000s which I had an honour to fall in love with in the 2010s to the non-constructive, downgraded, annoying and irritating experience of mobile phones.

Thankfully, not all projects choose to go this way. For an example of a new encyclopaedia with a traditional design, see the immensely popular Korean Namu Wiki. Adûnâi (talk) 12:53, 10 April 2022 (UTC)

100% agree. Football Lab (talk) 09:12, 26 June 2022 (UTC)

Where are the watch/unwatch buttons?

Alright, if the article is long enough to be scrolled, I should scroll it down, the top row of icons will jerk left-right, and the "watchlist" icon will become the "watch/unwatch" toggle. Hopelessly inconvenient, counterintuitive, but it works. But what if the article is so short that it won't scroll at all? example Seems like "preferences/watchlist/edit raw watchlist" is the only go-around, is it not? Retired electrician (talk) 12:13, 27 June 2022 (UTC)

@Retired electrician: There's a smaller star-shaped watch/unwatch toggle to the right of the "View history"/"История" link. Scyrme (talk) 14:48, 27 June 2022 (UTC)

Thanks, that was most unexpected. I'd rather prefer old good text links. Retired electrician (talk) 15:59, 27 June 2022 (UTC) The new star looks almost exactly like the existing GA star, just a different shade of grey (but in almost the same corner location as in standard monobook). Retired electrician (talk) 16:02, 27 June 2022 (UTC)

"Thanks, that was most unexpected. I'd rather prefer old good text links" - you're a Monobook user, am I right? This may be a good reason why it's most unexpected for you. Vector 2022 is based on Vector legacy (2010), and the star icon has been there for 12 years. SGrabarczuk (WMF) (talk) 01:51, 28 June 2022 (UTC)

Language links on Wikidata are right at the bottom of the page

I've enabled the new theme (Vector 2022) globally on all wikis. I generally like the new interface. However when I am on wikidata, previously the interlanguage links were on the right. (Where an infobox usually goes on a wikipedia page) Now they are right at the bottom of the page! Some wikidata pages are massive, and having to scroll all the way down to the bottom of the screen to do the thing I do most frequently on wikidata (add new language links) is a real pain. Please can you move the language links on wikidata back to the top (top right) of the page? - Rooiratel (talk) 14:25, 23 June 2022 (UTC)

Hello @Rooiratel. Thanks for your opinion. Are you talking about the desktop view? What's the resolution of your screen? I've tried to narrow my window down and change its width, and it seems that the width thresholds when the interwiki links go from the bottom to the right are the same. Is there any setting you use that may make your experience different? SGrabarczuk (WMF) (talk) 23:50, 27 June 2022 (UTC)

Hi @SGrabarczuk (WMF): this is for the desktop view. I am seeing this behaviour on my 1080p laptop screen and my 1440p desktop screen. I haven't used the mobile view, so can't comment on that. - Rooiratel (talk) 06:32, 28 June 2022 (UTC)

Infobox element alignment is mangled in mobile view

Maybe I'm doing something wrong, but when I click on "Mobile view" with Vector 2022, many of the infobox elements are misaligned. Many elements that should be centered are left-aligned, and many elements that should be left-aligned are centered. At least that's what it looks like for me in Chrome for Mac OS at this page. Jonesey95 (talk) 02:57, 24 June 2022 (UTC)

Wow, that looks odd. Thanks @Jonesey95 for reporting this. Right now, I only have one question - why do you use the mobile view and Vector 2022 mixed together? Minerva is dedicated for mobile, and Vector 2022 is dedicated for desktop. Having these two at the same time is bold and original :) SGrabarczuk (WMF) (talk) 23:08, 27 June 2022 (UTC)

I was just doing some very beginner-level QA testing. Editors do all sorts of ridiculous things, so I try to do some QA testing by doing ridiculous things. If you want editors to use Vector 2022 for desktop-only and Minerva for mobile-only, then make the "Mobile view"/"Desktop view" link at the bottom of the screen switch between the skins. Meanwhile, I'll be over here in legacy Vector where I can fill my browser window with content.... Jonesey95 (talk) 01:15, 28 June 2022 (UTC)

Using the mobile domain with the Vector skin invokes a special mode with lots of odd behaviour. It's not part of this project but will hopefully get fixed some day. Jdlrobson (talk) 02:30, 28 June 2022 (UTC)

"Related articles" appear to be missing

I do not see the "Related articles" section at the bottom of the mobile view. I don't really care, but since the "Principles" section of this page says "We do not remove any functionality", I thought I'd mention it. It makes me wonder what other functionality has been removed, and whether this principle is really being followed in a systematic way. Jonesey95 (talk) 03:02, 24 June 2022 (UTC)

RelatedArticles appears to be working fine to me. I see it on Minerva. What do you mean by "at the bottom of mobile view"? The scope of this project is the desktop site so no changes to the mobile domain have been made.

RelatedArticles does not show on the skins of certain websites and has not shown on Vector or Vector 2022 unless the community has explicitly requested. See phab:T144812, phab:T181242 and phab:T278611 for example. Jdlrobson (talk) 14:59, 24 June 2022 (UTC)

I think this is my mistake. I was comparing this (default mobile view on en.WP) with this (Vector 2022 mobile view) and assuming that the default mobile view used some version of the Vector skin, but I think that is not correct. Jonesey95 (talk) 16:38, 24 June 2022 (UTC)

Ah okay. This mode is only accessible by a special URL and is not being worked on as part of this project. Thanks for taking the time to explain! Jdlrobson (talk) 02:28, 28 June 2022 (UTC)

Please evaluate CJK characters' font size in Vector 2022

Tracked in Phabricator
Task T311469

For your infomation, the Chinese Wikipedia already has a gadget that increases the font size for a better Chinese reading experience. Japanese and classical Chinese Wikipedia also have such kinds of gadgets. Diskdance (talk) 08:19, 25 June 2022 (UTC)

It would be nice if we could integrate these gadgets into new Vector skin directly. This would benefit other CJK and multilingual wikis. Diskdance (talk) 08:20, 25 June 2022 (UTC)

Thanks @Diskdance! @AHollender (WMF) FYI :) SGrabarczuk (WMF) (talk) 23:03, 27 June 2022 (UTC)

I think we should create a phabricator ticket for this one. Jdlrobson (talk) 02:29, 28 June 2022 (UTC)