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) (talk) 16:36, 27 April 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)

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

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)

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

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)

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)

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)

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)

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)

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

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)

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)

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)