Talk:Reading/Web/Desktop Improvements

Larghezza finestra
Veramente pessima la larghezza dello spazio utilizzato, si perde da un terzo (pagine in ns0) a metà (pagine di discussione) dello spazio attualmente disponibile ValterVB (talk) 18:06, 21 December 2021 (UTC)


 * Ciao @ValterVB, thank you for your opinion in Ambasciata. Could you check out our fourth prototype again and write more on what you think about arranging the space as it is presented there? SGrabarczuk (WMF) (talk) 14:56, 26 April 2022 (UTC)

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


 * Hello @Xania, you can read about our goals and motivation for limiting the width. Also, we are working on a solution to use the empty space. Could you take a look at our fourth prototype and write more on what you think about arranging the space as it is presented there? Thank you in advance! SGrabarczuk (WMF) (talk) 14:59, 26 April 2022 (UTC)

What is our objective? > Currently the interface doesn't highlight the community side & list item 4
List item 4 under https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements#Currently,_the_interface%E2%80%A6, (connects with "...doesn't highlight the community side"):

"The large difference in experiences among our desktop interface, apps, and the mobile web, makes it difficult for readers to connect our products. There is a lack of unity in the concept of Wikimedia sites."

I think this is saying that if user experiences across devices and Wikimedia sites are similar, it'll be easier to help connect the products together. But does that help the user? Maybe it'll help discovery of other, less popular Wikimedia sites, but this new design hides many community links behind a menu...

(Sidenote: Hmm, maybe increasing the size of many user controls on the top right could help, but wait what's the difference between alerts and notices again? I guess alerts are just more important notices, since they both show the "All notifications" and "Preferences" buttons at the bottom.)

I'm probably confused about this particular objective. Like how it relates to the table of contents + menu sidebar change.

AltoStev (talk) 18:08, 22 December 2021 (UTC)


 * Hey @AltoStev, I'm sorry for not answering earlier! It took me a while to talk to the team about this, and then I was occupied with urgent tasks. I'm really sorry.
 * "But does that help the user?" - the assumption is that yes, it helps to understand that what you see in your mobile app, mobile browser, and on desktop, is the same website.
 * "This new design hides many community links behind a menu" - according to our quantitative data pulled via API, readers don't click links presented to them that much. Quite the contrary, they ignore these, and ignoring the links in the sidebar is a perfect example. By de-clustering the interface, we are making the really most important links and "community entry points" (like "Edit" or "Log in") more intuitive to find, understand, and use. Perhaps at the last stage of the project, we'll highlight some links in blue, or something... we haven't started thinking about the details yet.
 * Alerts and notifications are (unfortunately or fortunately) out of the scope of this project. We aren't going to touch them... for now.
 * SGrabarczuk (WMF) (talk) 16:36, 27 April 2022 (UTC)
 * @SGrabarczuk (WMF) Thanks for your reply - very insightful that readers don't click these links. That completely changes my view. I'm pretty sure I fell for multiple different biases there.
 * Incorrect tab positions - Page history - Wikipedia Desktop Improvements.png
 * This is a separate issue, but is the positioning of the tabs in the page history a bug or a feature? (see image right) AltoStev (talk) 00:17, 6 May 2022 (UTC)
 * @AltoStev, currently, the tabs should be displayed in the same place both in full width and in limited width. This will be changed, because people consider it more as a bug than a feature. Later, the design will be changed. See our newest prototype and the task on Phabricator: "Visual design & layout refinements". SGrabarczuk (WMF) (talk) 00:38, 6 May 2022 (UTC)
 * @AltoStev, currently, the tabs should be displayed in the same place both in full width and in limited width. This will be changed, because people consider it more as a bug than a feature. Later, the design will be changed. See our newest prototype and the task on Phabricator: "Visual design & layout refinements". SGrabarczuk (WMF) (talk) 00:38, 6 May 2022 (UTC)

Unecessary "deadspace" on the sides of the site
Why is there empty space on the sides of the articles? It just gives off, to me, an unprofessional vibe, as well as squishes the actual contents of the article. What is gained from the unused space? --Lamaredia (Kasper D.L) (talk) 14:31, 26 December 2021 (UTC)


 * Please see Talk:Reading/Web/Desktop Improvements/Reading/Web/Desktop_Improvements/Features/Limiting_content_width. Jdlrobson (talk) 23:57, 5 January 2022 (UTC)
 * Please make it possible for the users to collapse the left sidebar/TOC. I for one use a browser sidebar 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:19, 26 April 2022 (UTC)
 * @PeterTrompeter, noted! We are working on it. See the task on Phabricator for more details. SGrabarczuk (WMF) (talk) 14:18, 26 April 2022 (UTC)

Keyboard shortcut does not focus search field in sticky header
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)

Scrolling by pages + sticky header scrolls too far
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)

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)

Page-title and Search
In a nutshell, I believe Hope that helps! –Quiddity (talk) 20:53, 21 January 2022 (UTC)
 * 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

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. &mdash;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! &mdash; Hasley 21:02, 1 May 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 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.
 * "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.
 * "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.
 * "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.
 * "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.
 * "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)

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

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

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

Feedback on ToC functionality
Hello,

I’m not sure how far you are in the development of the new table of content functionality, but I was looking at this prototype and noticed a potential problem. Here the ToC is on the side and that’s a good thing, but the ToC in the text have also been deleted and that’s not much a good thing. When there is a big infobox, the in-text ToC compensate partly or totally for it, hence the page arrangement take it into consideration for the position of the images. Now if you delete it, all the text will go up, along with the images, but the images can’t always follow, because the infobox, so the right-aligned images are going to pile under it, while the left-aligned will reduce the text to a very small column between them and the infobox. On fr:wp, infoboxes are very widely used, so deleting the in-text ToC is going to break the page layout of most articles (and rather probably upset the community). So I’d suggest that, whatever you do with the ToC, to not delete the in-text ToC until there is also a functionality to move the infobox outside the text too (that would be great by the way, as infoboxes always cause difficulties with page layout). --Runi Gerardsen (talk) 09:30, 7 February 2022 (UTC)
 * I would like to add myself as having this same concern about images. At present, image placement in many articles was determined by this factor of the TOC being inline, sometimes offsetting the issues of long infoboxes and allowing the first image in the first section to be right-justified (like anyone with any experience in professional publishing, I really hate left-justified lead images as they break up the flow of the text by interposing themselves between heds and text. Similarly, I try to maintain alternation in the justification of images since that mirrors the sweep of our vision and makes text with images easier to read (but of course you don't do this when it creates other layout issues). When this is deployed, a lot of articles are going to suddenly have image placement issues at the top that didn't previously. And this will probably make a lot of people very angry. I can see the need for the sticky TOC but I think it would still be better as something that could be toggled there from its current position while reading depending on how the user prefers it in an individual article. Daniel Case (talk) 05:50, 29 April 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)

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!
 * My feedback:
 * I really dislike the usage of the bracket type of buttons for  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:
 * MediaWiki table of contents collapsed idea.png
 * Lectrician1 (talk) 00:42, 7 May 2022 (UTC)

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 T289641 and T299115). Best regards, Patafisik (WMF) (talk) 09:15, 9 March 2022 (UTC)

Left margin menu pushes down content
I normally use Monobook, but happened to get into the new Vector. Odd experience. The search box was absent and I had to scroll down for the content. I now see that you are supposed to click the magnifying glass to get the search box. OK. But the scrolling?

It seems the new Vector tries to guarantee wide enough space for the content. Perhaps that's what people surfing with maximised windows expect, but if you have a narrower window, is that really optimal? To get the left margin menu to the left of the content, I need a window some 1000 px wide. This "minimum" width gives me lines of about 100 characters, while I've heard reading is easiest at 47–72 or something like that. I like to have several windows open in parallel, and a narrower windows makes them fit better.

Anyway, if one's browser window is narrow, for whatever reason, does the empty space to the right of the margin menu really give the best possible experience? Is the 100 char width something that needs to be guaranteed for those planning layout of individual articles? (This experience is with Firefox 91.7.0esr on Debian.)

–LPfi (talk) 20:07, 17 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. —  python coder    (talk &#124; 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? —  python coder    (talk &#124; 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)
 * 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. —  python coder    (talk &#124; 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. —  python coder    (talk &#124; 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. —  python coder    (talk &#124; 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)

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

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

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)

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)

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

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

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


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

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

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


 * Thanks for this comment, @Nardog. We'll think how we could improve this. SGrabarczuk (WMF) (talk) 23:55, 27 April 2022 (UTC)

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 and the mentioned Phabricator ticket, which describes my issue more accurately. Tenryuu (talk) 15:10, 26 April 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 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)

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)

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:
 * 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.)
 * Accept the arguments about the results of user testing, A/B testing, community feedback...
 * Accept the "final" version as the basic version, and
 * 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)

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 &#124; 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 &#124; contribs) @ 19:27, 27 April 2022 (UTC)

Notification icon gets larger when there's a notification
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 &#124; 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 &#124; contribs) @ 21:20, 27 April 2022 (UTC)
 * @Tol thanks for pointing this out. I've just filed a task about it: 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 &#124; contribs) @ 19:38, 28 April 2022 (UTC)

Updated table of contents doesn't work with VisualEditor
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? &#123;{u&#124; Sdkb  }&#125;  talk 22:25, 27 April 2022 (UTC)
 * Thanks @Sdkb. This is T307251, isn't it? SGrabarczuk (WMF) (talk) 22:31, 5 May 2022 (UTC)
 * Yep; glad it's being tracked! &#123;{u&#124; Sdkb  }&#125;  talk 03:16, 6 May 2022 (UTC)

"Beginning" is confusing
More feedback: when I was at Gotcha journalism just now, I became confused because there appeared to be a section titled "beginning", which I assumed covered the early history of the term. It took me a minute to figure out that that wasn't referring to a section but rather a way to scroll to the top of the page. Many other articles are going to have a similar problem, since we often begin with history sections that might reasonably be titled "Beginning" for early history. &#123;{u&#124; Sdkb  }&#125;  talk 22:42, 27 April 2022 (UTC)


 * @Sdkb - good catch! This is something we discussed quite a bit internally in order to finally settle on beginning, although I agree that it's still imperfect. Previously we were using "introduction".  The issue there was that many articles have "introduction" as the name of their first section, causing duplication.  Other options we were considering were location-based (back to top, beginning of page, etc).  We are welcome to ideas on how to make this clearer.   OVasileva (WMF) (talk) 09:05, 28 April 2022 (UTC)
 * The name used by wikipedians? Lead section in English, résumé introductif in French, etc (Q10966628) Pyb (talk) 11:07, 28 April 2022 (UTC)
 * On Translatewiki.net I found "Début" for fr.wiki and "Inizio" for it.wiki (on it.wiki we use also "Incipit" or "Introduzione", see T306990). Patafisik (talk) 15:09, 28 April 2022 (UTC)
 * @OVasileva (WMF), did you consider different design approaches in addition to different names? If the word had been accompanied by something like Font Awesome 5 solid caret-up.svg, it might have been a lot clearer. I also think there's some benefit to matching the terminology we already use as editors ("lead section" or "introduction"), since that makes it easier for newcomers. The Wikipedia articles that currently have "Introduction" as their first named section should not—they should be tagged with w:Template:Overview section. &#123;{u&#124; Sdkb  }&#125;  talk 20:16, 28 April 2022 (UTC)

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


 * +1, the TOC should be accessible from the top of the page, and collapsible (vertically; also horiz if it is making the sidebar too wide - many pages have section heads that are quite long). Sj (talk) 17:35, 2 May 2022 (UTC)

TOC subsection links fail accessibility
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)

TOC links don't work
Do the subsection links even work? I tried clicking on them but I'm not directed to the headings. Tenryuu (talk) 11:09, 28 April 2022 (UTC)
 * Perhaps it's a bug, @Tenryuu. Do you fail to get directed to the headings on all pages and all wikis where you use Vector 2022? SGrabarczuk (WMF) (talk) 12:21, 28 April 2022 (UTC)
 * @SGrabarczuk (WMF): The sidebar headings are blue, but nothing happens when I click on them. At the English Wikipedia help desk, the contents are collapsed by date (as the date headings use Heading 1), and I can click on the arrows inline to expand them, but clicking on them directly doesn't direct me to those sections. Tenryuu (talk) 13:24, 28 April 2022 (UTC)
 * @Tenryuu, please add ?safemode=1 to the url and try to click the headings in the TOC. ?safemode=1 temporarily turns all gadgets off. You should be directed to the headings down the page. If that doesn't work, share the details about your browser version. SGrabarczuk (WMF) (talk) 13:37, 28 April 2022 (UTC)
 * @SGrabarczuk (WMF): Tried safe mode on the aforementioned page and it still doesn't work. I'm using Google Chrome version 101.0.4951.41 (Official Build) (64-bit) on a Windows 10. All Javascript should be enabled on the domain, and my ad-blocker extensions shouldn't interfere with its function. Tenryuu (talk) 13:43, 28 April 2022 (UTC)
 * I'm experiencing the same problem reported by @Tenryuu 20:23, 28 April 2022 (UTC)
 * Same, Chrome 101.0.4951.41 Spiros71 (talk) 17:07, 30 April 2022 (UTC)

Regarding the unclickable table of contents links there seems to be a bug in Chrome 101 beta so if using that version please report it to Google and revert back to Chrome 100. Jdlrobson (talk) 00:51, 30 April 2022 (UTC)


 * Chrome 101 is not a Beta, but stable version. ValterVB (talk) 20:33, 30 April 2022 (UTC)
 * 101 went from beta on April 26, 2022, so yes my information was based on the week before. We are working on a fix and possibly upstream bug report. Jdlrobson (talk) 17:36, 2 May 2022 (UTC)
 * This appears to have been fixed for me (Chrome 102.0.5005.22 beta). Tol  (talk &#124; contribs) @ 18:32, 3 May 2022 (UTC)
 * Checking in to let devs know the contents sidebar is working for me now (on Chrome 101.0.4951.54 (Official Build) (64-bit)). Tenryuu (talk) 16:07, 5 May 2022 (UTC)

About Google Docs and Zoom
Thank you for the invitation I received for tomorrow's videcall since I was an interface admin and a developer! but sadly I cannot participate since I don't use Google Docs or Zoom for security reasons (partially related: ).

I don't know if it could be useful but maybe in the future you may consider to land the doc on the wiki itself, or using Etherpad when realtime is needed.

To drop Zoom, maybe I can propose Jitsi Meeting that is gratis and libre and supports streaming on social network to support large audience. (Also Wikimedia Meet deserves a try and some feedback). Valerio Bozzolan (talk) 15:38, 28 April 2022 (UTC)


 * Hello @Valerio Bozzolan. I understand your concerns and thank you for the language you use. I do appreciate that. As you may have realized, it isn't without a reason why we use these particular tools/platforms.
 * Google Docs are used by the Foundation as the default tool for making internal notes and docs. We might, for the purposes of the office hours, replace it with Etherpad. There's a problem with the translations, though. Asking translators to update just one word, and waiting until they've done that, could be troublesome. This is why I can only commit to replace this if we make more changes to the announcement. (By the way, the announcement is fully standardized and translated into 16 languages, some of which use declination or are not written in the Latin script.)
 * We need our office hours to be technically (platform-wise) predictable. Although Jitsi is open source and Zoom is not, the latter is more effective. It has been widely used for online meetings in the movement. It's been used by the WMF for office hours with the CEO, Maryana; it's been used by affiliates. There are hundreds of Wikimedians who at least once have participated in a Wikimedia meeting on Zoom. We know how to provide live translations there. Jitsi, on the other hand, is less popular, and we'd have to learn how to support live translations, including more trainings organized specifically for our meetings.
 * We may consider having office hours on IRC. Frankly, I have a feeling that since the migration from Freenode, IRC has been more and more marginalized, but we could give it a try.
 * I'm curious what other Wikimedians watching this page think. Add your comments! SGrabarczuk (WMF) (talk) 22:15, 5 May 2022 (UTC)
 * Just asking for an understanding that Google Form and Zoom are a bug, not a feature, to participate in a Wikimedia project. A bug that deserves a long-term fix. Valerio Bozzolan (talk) 15:57, 7 May 2022 (UTC)

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

Wide-column + Multi-column options for large screens
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)

Provide a link to this page?
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 T307113, and we hope to have it out next week.   OVasileva (WMF) (talk) 11:28, 4 May 2022 (UTC)
 * DavidBrooks (talk) 14:23, 4 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  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. 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 &#124; contribs) @ 00:12, 8 May 2022 (UTC)

Tool bars and tables
Hi, thanks for the update. A few observations: GeneraleAutunno (talk) 20:39, 8 May 2022 (UTC)
 * 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.