Talk:Reading/Web/Desktop Improvements

I love the new width of the page
Please don't change it, or let others convince you to change it. The narrower width makes the reading much more comfortable, it looks more modern, and the eye can find the next line with ease. Blank space is not a problem, and who complains about it just needs to get used to it; the strangeness will go away eventually. If blank space were a problem, you should tell that to Facebook. Its feed also has lots of empty space around it. What's the problem?

The new Vector is the best skin in the history of Wikipedia. Congrats from a Portuguese Wikipedia editor. Bageense (talk) 18:38, 20 June 2021 (UTC)


 * Thank you @Bageense, this is very kind! All team members were really glad to hear that. While we can't promise we wouldn't listen to volunteers with various perspectives, we do hope that the limited width will be considered as an improvement. SGrabarczuk (WMF) (talk) 19:22, 1 July 2021 (UTC)
 * @SGrabarczuk (WMF), I'm also from the Portuguese Wikipedia. I think it would help if the white spaces got a bit grey, it looks worst in the all-white configuration. Moreover, it would be great if the desktop version looked like the mobile app version, with that awesome dark mode. Paz e concórdia (talk) 14:11, 3 August 2021 (UTC)
 * Hello @Paz e concórdia. Thanks for your opinion. Have you seen the task on Phabricator where we've begun discussing the background color? You may be interested in reading the comments. Regarding the dark mode - yes, that's an excellent idea, but we will not work on that. Basically, we can't deliver two separate @versions of the same page. I'll add a section to FAQ with an explanation why. SGrabarczuk (WMF) (talk) 17:15, 5 August 2021 (UTC)

I agree with Bageense. Its a huge improvement Shisma (talk) 07:20, 15 August 2021 (UTC)

I do not agree with Bageense. Usually when I read a Wikipedia article I do it from my laptop witch hasn't a wide screen. By squeezing the page together it looks like im reading the article from an iPad! On safari web browser, for example, I already have the read option to resize similarly the article (also with white spaces at the sides). An other point is that by zooming the old web page I could resize the text as I wanted (for example with cmd + or cmd -). With the improvement the size is fixed, the only thing that can happen is the white areas to enlarge or the text to ulteriorly shrink. Also, when a Wikipedia page has a propriety box (for example the chemical elements) it ulteriorly fills the text space, whereas the old version just placed it where now there is withe space. I think that it was better since the box containing technical information is less important than the article, it was logic to put it aside and not with the text. Finally, a tighter space means more scrolling witch on the older version, someone who doesn't want to always touch the mouse or keyboard, can just lean back on his chair and enjoy better the reading.

I wish the user will have the option to wide read a Wikipedia article in the future! PaDalton (talk) 15:04 21 August 2021 (UTC)

The reduced width is a single issue dealbreaker for me. The people that like the page narrow can... you know, just make their browser windows narrower? For me it is completely unusable, it gives up so much screen space, I need to scroll so much more, I have less information available in one view etc. --217.67.131.246 10:26, 10 September 2021 (UTC)

I strongly oppose this change, the current interface should be default and the one who make you scroll more, optional. Browsers already reduce vertical space, scrolling is frustrating, and increase visual fatigue because things moves. If you want easier readability, please implement a 2 columns layout like most paper encyclopaedias (this make even more sense on > 16:9 than on most book formats), scrolling should work with Page Down & Up keys & behave like 2 columns ePUB readers and physical books (bonus: incremental scrolling: bottom of 1st column overflows to the top of the 2nd one for those who wants it). See (CSS multicol) & a study on the use of multi columns and scrolling. Wasted space reduce usability. Hploter (talk) 10:42, 11 September 2021 (UTC)

I too would like to add my voice to the opposition. I always greatly admired Wikipedia as the last bastion of good UI. This abomination is merely a sign of mobile design's intrusion into the traditionally-desktop websites. I view it quite pessimistically - our voices will never be heard (because it's modern vs "outdated"), and it's only a matter of time until the last website on the Internet is turned into unreadable mess - with obnoxiously moving parts (the arrow signs), arcane and silly emojis ("hamburger sign"), wasted space (wide white bars to the sides), which requires more clicks than before (I hate the language tab already introduced which is always shrunk for logged out users). And what's the point? Mobile users already have mobile clients, afaik. Thus is mobile supremacism, pure and simple. Or do like Reddit did, and leave us alone on the old domain thingie.--Adûnâi (talk) 03:32, 19 September 2021 (UTC)

I also dislike the new default width, and is a dealbreaker for me with new Vector as a whole. When I took a look at the beta Vector, my first reaction was that I ended up on the mobile version of the site. Please do not change the default width for the desktop version of MediaWiki. I don't care about having a single design for both mobile and desktop versions, and would argue that a single design is detrimental to the user experience due to the very different nature of the platforms. The full-width website is something that has been around for over a decade, and I don't see the need to change it as the default. Mediawiki is not a tool for commercial purposes. Whitespace on the sides (which screams "banner ads") is not something needed as an informational platform. The platform exists to inform the reader and give them information, and having huge amounts of whitespace takes away what the reader can see on a single page and replaces it with nothingness. I would be perfectly fine with adding a setting that lets you switch to a mobile width for logged in users, but it should not be made the default for logged out users. This trend of creating a single design and thinning out the page width as a result is a step in the wrong direction, and is the reason why there exist situations like Reddit where a good portion of the userbase uses an older version. I am not against having a thin view option for the user, since if someone prefers that format they should be able to have it, but it should not be made to be the default experience. GalacticRuler456 (talk) 19:04, 8 October 2021 (UTC)

Impact of Language switching on the Main page (fr.wikipedia)
Hi, the Main page of the French Wikipedia shows the button of the Language switching at the end of the page. Some users don't find languages, some others say that this location is uncomfortable, some users answer to have languages on the top or at the left, like in others pages. See here, here, here and here. Thank you.--Patafisik (WMF) (talk) 08:25, 26 June 2021 (UTC)
 * See also a topic on Reddit, where some readers express their confusion about this change --Yodaspirine (talk) 13:15, 27 June 2021 (UTC)
 * This. The original version of Vector was clear, simple, legible, and mastered by all. I have yet to find one real world user that enjoys the new version. Absolutely nobody asked for any of the currently proposed changes on the French version. Since the first introduction of those changes I found myself switching to the english versions of the articles more often than not because the centered content makes the page needlessly long and way less legible. Now you're turning this action from easy and intuitive to something convoluted, on purpose? Please consult users/visitors before unilaterally changing a design that wasn't broken and introduce confusing and misleading modifications. That only serves to satisfy someone's need for change while making browsing unnecessarily more complex and confusing for millions (billions?) of people. --Eskaps (talk) 19:40, 27 June 2021 (UTC)


 * Hi, I understand that the reason why the language button were moved was to make sure they're always visible from the top of the page. While this is a legitimate concern the current solution is creating much more problem than it is fixing. Quickly changing the language of the article is probably the feature that I use the most on Wikipedia, in fact I use multiple time a day. And the people who responded to the reddit post linked previously shared the same experience. Perhaps this is not something than the current tools used to evaluate how the user navigate on Wikipedia was highlighting but this is clearly an overview and I really urge the developer to take into account these returns.--JllllllV (talk) 18:33, 27 June 2021 (UTC)
 * Bonjour, merci pour votre retour, je prends note de vos remarques. Je comprends que ce changement vous affecte beaucoup.
 * SGrabarczuk (WMF) a présenté la novelle fonctionnalité le 22 mai et a donné des réponses qui pourraient vous intéresser, notamment par rapport à la collecte des avis des utilisateurs avant le déploiement de la fonctionnalité et les tests A/B. Le 22 juin la fonctionnalité a été à nouveau annoncée au Bistro. J'ai cherché d'ajouter d'autres détails dans ma présentation au Bistro le 24 juin.
 * Vous pouvez toujours garder votre interface préférée et basculer vers l'ancien habillage : le lien est dans la barre à gauche, ou dans Préférences > Apparence > en cochant la case "Utiliser l'ancienne version de Vector".
 * Cordialement,--Patafisik (WMF) (talk) 09:22, 28 June 2021 (UTC)
 * , I'm not interested using the old layout, I find most of the change to be positive. As I said the habitability to quickly switch between languages is an integral part of the way I use Wikipedia everyday. And given the reaction a simple reddit post received in a few hours I am not the only one. As I already said, I read what motivated the changes and I understand why the dev team felt they needed to do something. But the solution is worse than the problem. There are already testimonies from people telling that using the new layout, when they arrive on an article available in multiple language they didn't even realize it was available in another language. And when they did, they did not know how to switch to the new language. And this is coming from people who are familiar with Wikipedia. What can be done to help the team do better on that topic? --JllllllV (talk) 11:26, 28 June 2021 (UTC)

and @alls: Thank you for writing. When you report problems and comment a new feature in this page, if you don't know, you are precisely helping us to understand if we are going in the right direction or not, if community like it or not, if the usability of the new feature is good or not, and it helps us to correct the direction if needed and fix bugs ! :) You can see the progress on Phabricator, the progress is due to your feedback.

Feedbacks from users and readers where already collected and analysed for create the prototype before the deployement on the pilots wikis (see here and here). I'm currently collecting all users' feedbacks and I have explained the topic to SGrabarczuk of the Web Team, they are discussing about the better way to act, considering all the variables. My goal is also to improve our ability as Web Team to collect feedbacks from / to give feedbacks to the French community, to communicate news but also understand to better way to communicate about the development process.

When a new feature is deployed, a period of transition is necessary: I understand the confusion of a lot of users and the impact of the Language switching mostly on experienced contributors. Some users like you are proposing solutions to make it easier for all to understand how and when new features are deployed, and I'm presenting your suggestions to the Web Team and staying tuned.

About the Language switching, tests A/B are presently in progress, this will be the case for two weeks : it means that we are collecting informations about the real use of the feature, what are the problems of users to find the button of languages or to understand what it is, if they prefer the old interface etc. At the same time, bugs are being fixed. Those data will be analysed and major decisions will be made based on your feedback. Transition takes time, and I'm sorry that the feature is not still perfect and that this period should be uncomfortable for experienced users like you and others*, but it is a temporary disease, we need to collect data and we are doing our best to reduce this disease. When you say « the solution is worse than the problem », I hope to have offered to you the reasons why for some of you this should be only a temporary unconfortable period, in the short term, and how we are really trying to prepare a better feature for the medium and long term.--Patafisik (WMF) (talk) 14:56, 28 June 2021 (UTC)

* But some users loves the changes.
 * About the impact of Language switching on the Main page: I have found this task T276140 on Phabricator which could explain why the Main page doesn't shows the link of language switching at the top.--Patafisik (WMF) (talk) 14:56, 28 June 2021 (UTC)


 * Bonjour. J’ai un compte wiki. Je voulais savoir comment je peux personnaliser l’affichage (sans trois cents lignes de code CSS/JS) pour mettre la boîte des choix des langues comme avant dans le menu du gauche. Et je pense que cette information sera très utile à beaucoup d’autres qui n’apprécient pas ce changement malvenu. Merci par avance. --Nbag (talk) 16:01, 21 July 2021 (UTC)

I can't clearly understand why only the language selection has been moved and not other objects. Intuitively if someone is reading an article the mouse is in the center of the page and for the hand on the desk it's much easier to move left-right. Accepting the new location, why then move the search bar away from anything? It could be so near the language switching button! With the new layout is seems I have to train for mouse acrobatics.

P.s. I totally agree with. PaDalton (talk) 15:25 21 August 2021 (UTC)

Bonjour, c'est déjà ssez pénible de chercher l'ancien menu avant de se rappeller qu'il a été déplacé de l'autre côté de l'écran, mais admettons, les choses changents et je ne veux pas finir vieux c**. Par contre ce qui me gène vraiment c'est d'avoir à derouler la liste pour savoir les langues disponibles. C'est un clic supplémentaire, qui en doublement perdu si ce que l'on cherche n'est pas au rendez-vous. Personne n'a besoin de ce genre de suspens


 * Bonjour, on est nombreux dans le même cas. Et non ce n'est pas être un vieux c que de vouloir garder ce qui servait à un grand nombre de gens. Merci--Jpve (talk) 05:41, 6 September 2021 (UTC)

Not sure if this is the right place to say it, but could we please keep the interwiki language links in the left-hand column, and NOT displace them as in the ongoing experiment on the French Wikipedia ? It makes them almost invisible, and not practical (they are not reachable in a single click as before). Baronnet 13:26, 9 September 2021 (UTC)

Impact on other languages in France of burying the interwiki link in the bottom
I have taken the overall visits of four languages spoken in France besides french:


 * Occitan
 * Breton
 * Corsican
 * Alsacian

I have downloaded visits during 2020 september and 2021 september using Siteviews tool. The result wouldn't be surprising to anyone who has thought on how hiding the interwiki link should affect smaller projects that can't be reached easily via Google search.

The combined views for this 4 projects during September 2020 was 1.358.349 pageviews (excluding special pages). For September 2021 is 1.192.619. Is a decrease of 12% (165.731 views less). I wonder how this aligns with the 2030 Strategy. -Theklan (talk) 10:40, 15 October 2021 (UTC)

Interwiki links
I've eventually found my way here. I don't know if this is the best place to post.

I am a WikiGnome. My speciality is fixing links to w:WP:DAB pages. I detest with a passion the so-called "improvement" which moves Interwiki links from the left-hand column into a clickable box. It makes my work slower and less efficient.

I use non-English WPs to solve problems in several ways. (1) By clicking on the link in the left hand column. (2) By loading the Main Page, and selecting a language from there. (3) By using a non-WP search engine, and selecting a non-enwiki result it might turn up. I do not need a non-alphabetic scrolling list of languages by popularity or geographical location. If I want to consult a page in Hangul, I want to find it somewhere between Galego and Hrvatski, not in some apparently random list; and if I want to find the correspoding enwiki page, ditto. How on earth am I supposed to find the page I want from a list of languages I can't read?

I was the last moderator (#45, I think) to be appointed to a very well-known website. Management knew better than the mods and other power users, and implemented top-down "improvements" which we told them were bad ideas. Us mods who had striven to keep the site clean of porn, commercial spam, and underagers, all packed it in, within a few weeks. That site, which in 2009 reported 200 million users worldwide and 15 million daily users, first fell off the Quantcast ratings as too insignificant to record, and was closed down in 2021.

Don't give me focus group crap! Consider yourself warned. I don't expect you to listen (that site didn't). Don't give me "yes, but" responses - I've heard them all before, and they were management-speak bullshit.

At the very least, make the "old-fashioned" easy-to-use alphabetical list version and the "modern" badly-sorted version a selectable user option. Narky Blert (talk) 17:28, 31 July 2021 (UTC)


 * I’m not among the people who decided on this project (and I also strongly disagree with several changes), so it’s not a “yes, but” response, I just want to mention some options that already exist:
 * You can search in the new list. You can search by language code (if you expect Hangul somewhere between Galician and Croatian, you probably know its language code), or you can search by language name—with a quick test it looks like in virtually any language, so if you want to jump from German Wikipedia to Croatian, you can search for Croatian, you don’t need to know either its German name kroatisch or its native name hrvatski. Depending on the number of interlanguage links and your computer usage customs, it can be much faster to search than to scan the list with your eyes (but it can be much slower as well).
 * As long as you’re logged in, you can opt out from this change in an all-or-none manner in your preferences. If you want to opt out once for all wikis, you can use global preferences.
 * —Tacsipacsi (talk) 19:43, 31 July 2021 (UTC)
 * I have looked at your links, and have not the foggiest idea as to how to get rid of this abomination. Please advise. Narky Blert (talk) 20:38, 31 July 2021 (UTC)
 * You have to turn on  (it’s on by default on wikis like mediawiki.org that don’t have the changes yet, but you’ll find it off by default on wikis like French Wikipedia that do already have the changes). —Tacsipacsi (talk) 21:44, 31 July 2021 (UTC)
 * You don't need to turn on legacy Vector. The language button feature can be turned into a list by unselecting the box "Use a compact language list, with languages relevant to you." in your Special:Preferences. This will give you an alphabetical dropdown. Jdlrobson (talk) 16:16, 5 August 2021 (UTC)
 * That option is unselected, and never has been selected, in my preferences. Do I have to search for the equivalent and unselect it in every language WP I might consult (161 and counting, including only those where I've found something relevant)? Narky Blert (talk) 19:26, 9 August 2021 (UTC)
 * No. You onlu need to use Special:GlobalPreferences as suggested above to change it once across all your 161+ wikis.
 * Screenshot of Compact languages button dropdown with JS disabled.png
 * That said, if the option is not selected as you say, I'm not sure how you are seeing the languages separated by alphabetical/geographical regions, as that is not possible from the code.
 * If that preference box is unselected like you say, you should be seeing is the screenshot on the right, and that list is no different than the original alphabetical list that you claim was more efficient.
 * If you aren't seeing that, is it possible you have any gadgets/beta features enabled that may be interfering? Jdlrobson (talk) 02:40, 11 August 2021 (UTC)
 * I've now selected Global preferences/Use Legacy Vector, and see my preferred left-hand language column in all the WPs I've checked. My, but that hasn't been easy to find - open a page which I didn't know existed, on a site I've hardly visited, and choose between unintelligible options.
 * I assert the left-hand column version is more efficient because I can see 34 entries at a time and get the next lot by using PgDn. In the screenshot, I can only see 13 - a reduction of 62%. If scrolling is required, it will be more cumbersome still. I speak from experience; Yahoo! did something similar in 2015-16. Narky Blert (talk) 08:14, 11 August 2021 (UTC)
 * Not sure if this is the right place to say it, but could we please keep the interwiki language links in the left-hand column, and NOT displace them as in the ongoing experiment on the French Wikipedia ? It makes them almost invisible, and not practical (they are not reachable in a single click as before). Baronnet 13:25, 9 September 2021 (UTC)

Will the current design still be available alongside the new one
Will the current design still be available even when the new one is rolled out, since I like the current version of Vector better than the new one. Blubabluba9990 (talk) 17:47, 9 August 2021 (UTC)


 * Hey @Blubabluba9990! Yes, the Legacy Vector will remain available for anyone to choose. You can opt in and out at any point. I hope that you will like the new version when more changes are ready :) SGrabarczuk (WMF) (talk) 01:05, 11 August 2021 (UTC)


 * @SGrabarczuk (WMF) Do you mean that the old UI will only be available for logged in users with accounts? Because I rarely log in to Wikipedia, as I browse in private browser windows, and constantly typing in the password would be ridiculous. Are you going to have a way to opt out of the redesign for logged out users the way Reddit did it with its old. domain thingie?--Adûnâi (talk) 18:34, 19 September 2021 (UTC)
 * Hi @Adûnâi. Unfortunately, the Foundation is not able to provide any personalization to logged-out users. This is due to the limitations of our infrastructure (capacity of our servers). This is the reason why there's no dark mode for logged-out yet. I'm really sorry we aren't compatible with the way you browse. This is beyond our sphere of choice or influence. I'll ask my colleagues if there is any other way we could solve this problem. SGrabarczuk (WMF) (talk) 12:13, 20 September 2021 (UTC)

Вклад и список наблюдения в один клик
В прошлый раз интервики спрятали под выпадающее меню, теперь ещё список наблюдения и вклад участника? На список наблюдения нужно переходить гораздо чаще, чем на новые сообщения. Да и в целом, на десктопной версии нет необходимости что-то прятать, если есть возможность сделать переход в один клик, особенно если по этой ссылке нужно переходить часто — лучше оставить переход в один клик. --Tucvbif (talk) 05:43, 11 August 2021 (UTC)


 * Hi @Tucvbif! You're right, this requires additional consideration. Generally, we are working on the sticky header. When it's ready, there will be no way to display all these links. We are also trying to determine if the watchlist should be directly available. See T289619 and T289574 for more details. SGrabarczuk (WMF) (talk) 19:19, 2 September 2021 (UTC)

Trend towards hiding links and more clicks
I have tried the new skin for some time. I like some features, such as the maximum column width in articles, which make them much more readable and provide a more consistent experience for users with different screen sizes. However, I am noticing a trend towards increasing number of clicks needed to do anything. First it was language links. They used to be accessible directly, while now we need to open a dynamic menu which slows down the process. I think that for people like me that often use multiple languages it is quite annoying. More recently, the links to watchlist, preferences, sandbox etc. have also been moved to another drop down menu. I don't understand the rationale for this. There is plenty of space to fit all the links, so why hide them in a dynamic menu? Now I have a lot of blank unused space and need to click double the time to get anywhere. How is this an improvement? Unfortunately after this I am forced to go back to the old skin for better usability, although I really liked some of the changes. --Ita140188 (talk) 02:50, 12 August 2021 (UTC)
 * I also miss the direct links to the languages and to the user-related pages (watchlist, preferences, etc.). Or if only the user could choose the links that would go in the new blank space (e.g., what he uses the most often)... — Vincent Lefèvre (talk) 21:17, 12 August 2021 (UTC)
 * En:Wikipedia:Keyboard shortcuts may be helpful for avoiding two clicks to commonly used pages. Jdlrobson (talk) 23:46, 12 August 2021 (UTC)
 * It works only when english layout activated. It doesn't work with non-latin-based languages.— Tucvbif (talk) 06:40, 13 August 2021 (UTC)
 * This is the opposite for me: access keys work on fr.wikipedia.org, but not on en.wikipedia.org (actually, they sometimes work, but not always). — Vincent Lefèvre (talk) 09:58, 13 August 2021 (UTC)
 * agree. It's really annoying to have more clicks.--Afaz (talk) 04:16, 13 August 2021 (UTC)


 * I think it makes sense to hide the language links, as those aren't used super frequently (at least in my admittedly limited experience), but for active editors, the talk, watchlist, sandbox, and contribution links are used all the time. I'm finding it annoying to have to make an extra click to get to them. &#123;{u&#124; Sdkb  }&#125;  talk 22:50, 13 August 2021 (UTC)
 * An extra click is also required to access the "More" menu and the Twinkle menu ("TW") because they don't drop down automatically when hovering like they do in the old version. This and the display issues I talk about below make the new version inconvenient to use and look broken in appearance. I won't be using it until these issues are addressed. Diannaa (talk) 13:28, 18 August 2021 (UTC)


 * Just wanted to note my agreement with the OP above. As a logged in editor of Wikipedia, I access my user page very rarely.  But it's one click away, and now the easiest page to reach in the entirety of Wikipedia.  Other links, such as my talk page, watch list and contributions, which I use all the time, are now two clicks away.  Where is the sense in this? --Escape Orbit (talk) 15:10, 20 August 2021 (UTC)


 * For whoever is interested, I am using the old version of the skin and reintroduced the nice feature of max column width by adding this code to the global CSS preferences (meta.wikimedia.org/wiki/User:Username/global.css):

.mw-body { max-width:860px; }	max-width:860px; }
 * 1) content {
 * so I can avoid using the new skin while keeping the nice column width. --Ita140188 (talk) 08:25, 8 September 2021 (UTC)


 * Perhaps the simple explanation is that these designers speak only one language and they hate all multilingual people and want to make our experience miserable. We write articles and they design and format because they don't command language. So they feel envy and a need to command us. --92.35.13.45 00:21, 6 October 2021 (UTC)

Tagging wide tables for exception?
Firstly, great work on this! I've been using it for a while now. Secondly, I wonder whether it'd be worth either automatically identifying wide tables, or allowing them to be manually tagged as. The formatting for those tables could therefore either be:


 * Wide tables default to full width (extended to the right, or both left and right)
 * Wide tables still default narrow but get a button appear on the right to extend the width to full width.

It's low priority, but could be worth considering. T.Shafee(Evo&#65120;Evo)talk 06:17, 16 August 2021 (UTC)


 * Thank you @Evolution and evolvability for your support. I'll share your idea with the team. SGrabarczuk (WMF) (talk) 18:53, 2 September 2021 (UTC)


 * Definitely include classes like this that can be added to any div.
 * More generally, I have a wide screen and want to be able to use it, so there should be an easy pref in the default skin for either wide-screen single column or multi-column. Flowing multi-column within each section, w/ the number of sections scaling with width, may be the best experience -- we do it already for citations.  There's also a way to have flowing multi-col that scrolls up across all columns as you move.  Sj (talk) 22:59, 27 October 2021 (UTC)

Test and observations
Hello, thank you for your efforts. I am currently experimenting with improvements to persuade the largest segment of the Arab community to adopt it, but I have a first note, which is when there is no article in preferred language, a link appears in the old version (in gray) carrying the Content translation tool, but it is now absent. the secode, is the space in right (Arabic) when the Browser is 100%, but 0 space above 120%

Greetings Nehaoua (talk) 18:35, 19 August 2021 (UTC)


 * First of all, huge thank you for talking to the Arab community, @Nehaoua!
 * Could you write more? Where does the link appear exactly?
 * Perhaps the resolution of your screen is the reason why the space to the right disappears above 120%. Is inconvenient for you? What would you prefer instead?
 * SGrabarczuk (WMF) (talk) 18:45, 2 September 2021 (UTC)

A new icon
Hello. Is there a way to provide an icon for gadget or user script defined link in the new user menu? Thank you. IKhitron (talk) 14:47, 22 August 2021 (UTC)


 * Hi @IKhitron. We believe it's a good nice-to-have. I personally totally support this. We may make this possible. The software will be checking in the gadget's code if an icon has been defined, and if yes, this icon will be displayed. Also, some requirements will be set. Probably, icons for custom links should be different from the existing ones so users wouldn't confuse the links. Now, we're focusing on the sticky header, and nice-to-haves will be added later. SGrabarczuk (WMF) (talk) 16:16, 2 September 2021 (UTC)

Bringing search functionality to RefToolbar
One of my favorite parts of New Vector has been the improved search functionality. I was wondering if it would be possible to take the core of this and expand it to other areas. For instance, at w:Wikipedia:RefToolbar/2.0, it would be very helpful if fields like work, publication, and author-link returned search results. Would this be possible? &#123;{u&#124; Sdkb  }&#125;  talk 22:37, 27 August 2021 (UTC)


 * VisualEditor has had a such search functionality for ages. mw.widgets.TitleInputWidget is OOUI, not WVUI, but it provides the same functionality, and Vue is not (yet?) available for gadgets anyway. Or is there anything that’s missing from the OOUI widget (apart from the dynamic loading, which would be more annoying than useful in an editing interface IMO, and the link at the bottom to Special:Search, which makes absolutely no sense if you want to put the value in the input field instead of going to the said page)? —Tacsipacsi (talk) 11:57, 28 August 2021 (UTC)
 * I just checked VisualEditor, and it does have the functionality I'm seeking for the author-link parameter (since it's set to the "page name" type in the TemplateData. I'm not sure how to bring it to the work and publisher fields, as we'd want it to wikilink when someone selects a page but not when they just type in something custom (as will sometimes be the case, as not every newspaper/etc. we cite has an article). And I don't know how to bring it to RefToolbar, either, which is how most experienced editors edit and therefore what ends up getting used for most of the citations added. &#123;{u&#124; Sdkb  }&#125;  talk 17:46, 28 August 2021 (UTC)
 * I don’t know how to do conditional linking, either, but I also don’t think this is the right venue to ask for help from other people. The most appropriate non-enwiki place is Tech, although en:WP:VPT or en:Wikipedia:Interface administrators' noticeboard may also be helpful.
 * Now I tried out RefToolbar, and realized that it still uses jQuery UI; this widget uses OOUI. While it’s possible to mix the two, the result (what the user sees) would look quite awful, so I don’t recommend it. On the other hand, jQuery UI is more flexible: its windows can be moved on the screen by grabbing the title bar, and they can be modal or non-modal, while OOUI only offers non-movable, modal windows, so probably many users wouldn’t like OOUI (especially as one can’t select text behind the window for copy-paste). I don’t really know what the right solution is, but again, tgis page is not the right venue for lengthy discussions on this matter. (Feel free to ping me if you want to hear my opinion in a discussion you start elsewhere.) —Tacsipacsi (talk) 18:41, 29 August 2021 (UTC)

Левая панель наползает на тело статьи
При некоторых размерах окна левая панель стала наползать на текст статьи. https://imgur.com/a/SOMtjKr --Tucvbif (talk) 08:35, 30 August 2021 (UTC)


 * Hey @Tucvbif. Could you add ?safemode=1 to the URL and check again? I suspect you might experience this because of a gadget that you use. If this happens with ?safemode=1 in the URL, please write what operating system and browser do you use, and which versions, and we'll try to use the same. SGrabarczuk (WMF) (talk) 18:51, 2 September 2021 (UTC)
 * I guess that trouble not in gadgets but in default font size. I set bigger default font size because default FS is too small. Can you check media query for mw-content-container class for different font sizes? Or, maybe, make proper mechanism for change font size in user settings?--Tucvbif (talk) 08:31, 3 September 2021 (UTC)

Two Three thoughts on collapsed user menu
Hi! Two quick observations on the collapsed user menu: Cheers, &#123;{u&#124; Sdkb  }&#125;  talk 23:51, 1 September 2021 (UTC)
 * 1) I'm not sure why "Beta" is one of the links. It's really just one of the preferences pages, and there's already a link to preferences. Shouldn't it be removed?
 * 2) I've run into the issue a few times where the notification thingy you get when you e.g. add a page to your watchlist conflicts with the user menu (which is hidden behind it). A frequent workflow is for me to finish up something on a page, add that page to my watchlist, and then go to my watchlist to see what's next. Having to wait for a few seconds for the watchlist message to go away or click on it to get it out of the way is a minor nuisance. Could you make it so that the user menu displays on top or pushes the watchlist confirmation notification down?


 * Hey @Sdkb! Good points!
 * If I recall correctly, we haven't thought or planned to touch anything in the menu itself. We only have changed a line of links into a drop-down. Should we improve the selection of the links? That's an interesting point. We'll think about that.
 * I've created T290270. If you feel comfortable, you're welcome to report bugs on Phabricator yourself.
 * SGrabarczuk (WMF) (talk) 17:14, 2 September 2021 (UTC)
 * I don’t think new Vector should show different links than other skins. So if the beta link is removed, it should be removed everywhere, for everyone. —Tacsipacsi (talk) 23:31, 2 September 2021 (UTC)
 * Hmm, any idea where one would propose removing it? &#123;{u&#124; Sdkb  }&#125;  talk 01:25, 4 September 2021 (UTC)
 * I don’t think it’s a very big deal, so I’d start at Phabricator. —Tacsipacsi (talk) 11:19, 4 September 2021 (UTC)
 * Done; see T290463. &#123;{u&#124; Sdkb  }&#125;  talk 05:28, 7 September 2021 (UTC)


 * Oh, and a third thought: Would it be possible to make it so that the user menu expanded whenever you hover your cursor over the menu icon, rather than having to click on it? It'd save a fraction of a second, but I think it might go a ways toward helping editors accept it. &#123;{u&#124; Sdkb  }&#125;  talk 05:28, 7 September 2021 (UTC)
 * I'd like to join here. You plan to let the users decide themeselves, which language they want outside the dropdown menu. Is it possible to do that here, too? Because i would really like to have my contribution page and watchlist back in the line instead of having it in the dropdown menu. --FrühlingsSonnenBad (talk) 20:58, 13 September 2021 (UTC)
 * Hello @FrühlingsSonnenBad! Yes, this will be customizable. We are figuring out how to make this possible. Perhaps we will make it a user preference. Alternatively, we could build API and encourage local communities to decide how they would like to use the customizable part. The second option would make it possible to make gadgets. The current plan is to ask the communities we are working most closely with, and see what they say. SGrabarczuk (WMF) (talk) 17:38, 17 September 2021 (UTC)
 * Any thoughts on my hovering rather than clicking suggestion just above? &#123;{u&#124; Sdkb  }&#125;  talk 20:25, 11 October 2021 (UTC)

Suggestion for Watchlist
(original message posted on fr.wikipedia)

suggests to allow to change the duration of the watchlist without removing the star.

Translation of the original message: «When I put a page in the watch list, it suggests a watch duration: very good. But from time to time (don't understand why), I'm not satisfied with the duration I had set, and I want to change it. And that's where I find it frustrating that I have to remove the star and then redo. I would expect to be able to edit directly from the star and have the drop down menu from [No Tracking to Indefinitely].» --Patafisik (WMF) (talk) 08:07, 7 September 2021 (UTC)


 * To add, I would also like to see a watchlist button and not 'watch changes of my list' button. --Greatder (talk) 09:29, 13 September 2021 (UTC)

Interwiki links SHOULDN'T be buried in the bottom of the page at euwiki
Hello. I'm trying to open a bug at Phabricator, but they continue to close it arguing that an obvious but (having the interwiki links below the categories at the main page of euwiki) is not a bug but a feature. I doubt that someone designed it even as a prototype, so this is obviously a bug created from a bad decission making process. I don't know how to solve it: but it should be. Thanks. -Theklan (talk) 18:24, 7 September 2021 (UTC)

High-contrast themes
I am using Windows 11 with a contrast theme and the latest Firefox. If I use the system dark contrast themes, then the buttons for minimizing the sidebar, notifications and the user menu are not visible (the sidebar and user menu buttons are visible if I enable the dark reader extension). If I use a light contrast theme, the sidebar and user menu buttons are visible, but the notification buttons are not visible (Firefox). In the Microsoft Edge browser (clean, without extensions), when the system dark contrast themes are enabled, the symbols "P..." are visible in place of the sidebar collapse buttons and the user menu; in the light contrast Desert theme, notification buttons are visible, but under the user's menu button, "P..." and the bullet list symbol are now visible (there is the text Personal tools in h3 id="p-personal-label"). In Ubuntu, the notification buttons are not visible in the contrast theme (light), the sidebar and the user menu buttons are not visible if I enable the dark reader extension. Sunpriat 13:46, 9 September 2021 (UTC)

About the user links -- Sausage links
I know it may get a bit overwhelming in the settings with too many options. But, I think having the new vector look but with sausage links feels a lot better to me. --Greatder (talk) 08:53, 13 September 2021 (UTC)

2 colones sont mieux qu'une étroite
(Original topic by . --Patafisik (WMF) (talk) 07:50, 14 September 2021 (UTC))

Etude sur le sujet

I strongly oppose this change, the current interface should be default and the one who make you scroll more, optional. Browsers already reduce vertical space, scrolling is frustrating, and increase visual fatigue because things moves. If you want easier readability, please implement a 2 columns layout which should work with Page Down & Up keys (CSS multicol) like most paper encyclopaedias (this make even more sense on > 16:9 than on most book formats) ; wasted space reduce usability. Hploter, 11 septembre 2021 à 10:26

Don't ruin Wiktionary with ugly distracting emojis
Please, leave Wiktionary alone, and abandon the idea of burying the entire page under an avalanche of disgusting and cringe-inducing emojis. I was horrified when I discovered this example on French Wiktionary. Squiggly blue arrows, clocks, eye symbols, Chinese characters and even a horrifying ghost face? How can anyone defend this preposterous uglification? This is a bad joke. 1. They make entry sections seem less distinct, my brain filters out these abominable emojis and I cannot focus. 2. My brain reads words, the emojis that my eyes catch confuse me, as I cannot read these weird unfamiliar symbols the way I can read words. 3. The narrower page width makes it look claustrophobic and jumbled: for example, the "English Wikipedia has an article on:" box sits neatly far to the right in the original, but in the new version, it's immediately close to the text to which it is otherwise unrelated.--Adûnâi (talk) 18:25, 19 September 2021 (UTC)


 * The icons in section titles are French Wiktionary’s own thing. They used to exist even back in the Monobook days, and won’t be forced to other Wiktionary communities. —Tacsipacsi (talk) 22:25, 19 September 2021 (UTC)
 * Anyway, thank you @Adûnâi for knowing whom to ask about desktop design-related issues, even if it's not our work or even idea. You've put visible effort in explaining why you don't like the icons, and I think you can re-use them when talking to the Francophone Wiktionary community :) SGrabarczuk (WMF) (talk) 16:47, 21 September 2021 (UTC)

Language section in sidebar on special pages
I just noticed that apparently, special pages (as the watchlist) still show the p-lang section in the sidebar, while on all other pages the section has "moved up" to the language switching dropdown. Has this been forgotten? As I understand it, it should disappear from all pages in all namespaces (especially if it is completely empty). Regards, XanonymusX (talk) 16:25, 22 September 2021 (UTC)


 * Good point, @XanonymusX. Thanks! I'm pretty sure my team is aware of this, but to double check, I've filed T291632. SGrabarczuk (WMF) (talk) 12:58, 23 September 2021 (UTC)

There are not only readers, but also editors and powerusers
New vector might be good for someone who reads articles and maybe sometimes corrects typo or add one sentence. But there are also users who make many edits and use special pages, watchlists, discussion, sandbox - and these linjks are more hidden. And also sysops. I stay for long years on monobook, and one of reasons is that in vector are tools like [move] or [delete] hidden under some menu and needs more clicking (Timeless skin have this tools in whitespace on the right, so I love it more than vector, but some tools don't work here). And new vector hides more and more tools which are used by many editors and powerusers.

For my work I need large display or two and the new skin looks very tiny, and specially pages with tables needs many scrolling. I forgot to add signature, because I use easy reply feature on my wikis... JAn Dudík (talk) 18:22, 11 October 2021 (UTC)


 * In comment to the above unsigned section, I think the idea of "special-skins" tailored to usability not to looks or fashion would be an interesting idea! --HirnSpuk (talk) 17:03, 5 October 2021 (UTC)


 * There's an early idea that this team might make the interface modular. Then, it could be different for different groups of users. But there are various good ideas competing for our time, plus we're focused on the Desktop Improvements. There are no decisions about future projects. SGrabarczuk (WMF) (talk) 02:13, 6 October 2021 (UTC)


 * @SGrabarczuk (WMF), sure! I just wanted to "put the idea" out in public. --HirnSpuk (talk) 06:16, 6 October 2021 (UTC)


 * For the record, none of the skins are properly usable for high-level editing. I had to fuss at several people until they were able to design modifications to my Vector such that it looks (mostly) like Classic. Timeless is a good try but still inadequate. This is an issue of workflow and visual acuity. DragonflySixtyseven (talk) 20:26, 10 November 2021 (UTC)

Zu bunt, finde ich
Muss es so viele Farben geben? Ich meine, weniger ist mehr. Ich finde es gut, wenn z. B. die Sprachen-Wikis eine andere Farbe haben,aber den Artikel selber würde ich gerne so lassen, wie gehabt. Zabia (talk) 08:48, 5 October 2021 (UTC)
 * Annotated_Wikipedia_Vector_interface_(logged-out).png was für Farben wird denn da gesprochen? Das neue Design hat keine anderen Farben als das alte. Zumindest keine, die ich sehe. Oder ist das Bild rechts gemeint? Wenn ich es richtig sehe, ist das lediglich ein Symbolbild, welches die Seitenbereiche farbig unterlegt. Viele Grüße --HirnSpuk (talk) 15:33, 5 October 2021 (UTC)
 * @HirnSpuk Ja, ich habe das Symbolbild gemeint, ein anderes kenn ich nicht. Und dieses finde ich zu bunt, sollte Wikipedia künftig so aussehen.
 * Wikipedia will not look like that. I only use it as a replacement for a logo of the Desktop Improvements project. SGrabarczuk (WMF) (talk) 21:02, 6 October 2021 (UTC)

Streaming the Zoom-Meeting
It would be nice to stream the zoom-meeting somehow? I'd like to watch, if I find the time, but I won't install zoom. I'm pretty happy with the new look until now (with the exception for the language-links, compare Special:PermanentLink/4790869) and have high hopes for better mobil usability. Regards --HirnSpuk (talk) 15:33, 5 October 2021 (UTC)


 * Thanks @HirnSpuk, we'll talk about it. We didn't want to stream the entire meeting due to privacy reasons. Simply, we don't want to intimidate people. There are good editors who want to talk to us but don't want their voices to be available for everyone. But then recording the presentation part might be an option - this or the next time. We'll definitely talk about it! SGrabarczuk (WMF) (talk) 02:08, 6 October 2021 (UTC)


 * @SGrabarczuk (WMF), reasonable concern, I didn't think about that. In that case I'm refraining from this wish, cause I'm usually on the side of "there couldn't be enough privacy". My initial thought was based on the wish of transparency and Public Relations.
 * As an Idea: Maybe events like this can be splitted in multiple parts. One, where general information is streamed (with everybody participating in it being fine with it, I think at least the team developing the new stuff should be at least okay with it?), let's say a "Status-qou-presentation", then some kind of request for comments (which is, of course a high maintenance-task and might not be possible in real-time) and private talks after that (from which information should be made public of course, but with the proper measures in respect to privacy)? --HirnSpuk (talk) 06:08, 6 October 2021 (UTC)

Not logged in
Why am I not logged in? What happened to Single User Login? Fix errors before introducing new changes. --193.11.200.152 16:20, 5 October 2021 (UTC)


 * I'm sorry to hear that. This issue is probably not related to the Desktop Improvements. But I'm glad you came and are aware of this project. SGrabarczuk (WMF) (talk) 02:15, 6 October 2021 (UTC)


 * As far as I know, this is usually a cookie- or privacy-setting problem of the used browser. Maybe this helps. Regards --HirnSpuk (talk) 06:09, 6 October 2021 (UTC)

Translation
Hi. Why the changes are not translated? IKhitron (talk) 17:51, 5 October 2021 (UTC)


 * What changes specifically, @IKhitron? SGrabarczuk (WMF) (talk) 02:02, 6 October 2021 (UTC)
 * Too late, @SGrabarczuk (WMF), it was already delivered. All rtl wikis get wrong Zoom ID, so they will miss the meeting. IKhitron (talk) 02:04, 6 October 2021 (UTC)
 * Good catch. I've noticed that, will fix it. Actually, the link in the sentence is correct, and the one on the list is not. I think that's easily fixable. SGrabarczuk (WMF) (talk) 02:17, 6 October 2021 (UTC)

regarding page width (again. I'm sorry!)
First: No problem with me. But I've read multiple times, that users are not happy with the new width ("snowy void", "too much blank", "why", "But I need the space!"). It's obviously such a big deal, that there is even a big FAQ-Section about it, even the first one. Though there is explained, why preferences are not the way to go, I'm afraid, "you can use a local user script or gadget to do so." might be too intimidating especially for the content creator (which can not be expected to be a "techie"). So I'm proposing to think again about implementing a preference like

Width:
 * full
 * improved reading (default).

If it's so "easy" (script/gadget) wouldn't it be reasonable to have it in preferences in the first place?

--HirnSpuk (talk) 06:36, 6 October 2021 (UTC)


 * PS: An interesting issue was raised in german wikipedia: What about inclusion? Do the mobile impaired also like it better the narrow way, though it needs more scrolling hence more movement? --HirnSpuk (talk) 08:13, 6 October 2021 (UTC)
 * Before I answer anything directly, I'll give a tip, so to speak.
 * The Community Tech (the team working on the Community Wishlist Survey) is preparing Real Time Preview for Wikitext. They intend to make it default for all editors. This clearly needs to be synchronized with the limited width. No decision has been made yet. SGrabarczuk (WMF) (talk) 18:37, 6 October 2021 (UTC)


 * Seconding HirnSpuk. I'm also appreciative of Real Time Preview being added as default -- that's great.  I think that a default goal for reading should include a target for two-column layouts of article text, when the screen is sufficiently wide.  Then we can add a style guideline that each section should be no more than one page-length for a two-column wide layout -- provide good readability in both vertical sections [section headers span both columns] and horizontal line-length [each column has a max width, but usable page space does not].  At an abstract level, this could match the overall 2-col experience of the live preview. Sj (talk) 23:05, 27 October 2021 (UTC)

Add extra button to the WVUI search
On the Hungarian Wikipedia, there’s a gadget that adds an extra “open in new tab” button to the search widget. (You can try it by turning on the gadget Search in new tab / Keresés új fülön in your gadget preferences, or by loading the ResourceLoader module directly with .) It works fine on legacy Vector, but on new Vector it disappears when the full (WVUI) search widget loads. How can I inject my button in the WVUI widget? —Tacsipacsi (talk) 13:57, 9 October 2021 (UTC)

Sticky Header in legacy skin?
I saw the announcement of Sticky Headers. This looks like a really useful feature. It's unclear what skins it works with. Will this work with legacy vector, or does it only work with the new vector? RoySmith (talk) 15:50, 11 October 2021 (UTC)


 * Hello @RoySmith. It will only work with the new Vector. The Legacy Vector is a version with absolutely no change related to the Desktop Improvements. SGrabarczuk (WMF) (talk) 06:47, 12 October 2021 (UTC)


 * That's quite unfortunate. This looks like a really nice feature, but new Vector is fixed page width, which makes it a non-starter for me.  I've made a couple attempts to switch to it, but keep coming back to that same problem.  In a nutshell, for pages with wide tabular material, I want to be able to expand my window wide enough so the lines don't fold.  For reading normal text, I want to make the window narrow enough that the lines are a reasonable length.  A fixed-width skin like new vector makes that impossible.  RoySmith (talk) 14:31, 12 October 2021 (UTC)
 * @RoySmith - thanks for your feedback. Could you give a few examples of the pages you are referring to?  Something we've discussed in the past is extending the width for tables specifically while keeping the text at the fixed width.  In terms of turning off the limited width, there have been some gadgets created that would be able to turn off the limited width.   OVasileva (WMF) (talk) 16:16, 13 October 2021 (UTC)
 * Here's 4 screenshots from en:Wikipedia:Sockpuppet investigations. The first two are the index page in new and legacy.  The other two are a case page, again in new and legacy.  Note that if you look at the case page yourself, the lines probably won't have the "created 2020-3-28, last edit 2020-7-14, probably stale" stuff at the ends; that's added by a user script most SPI users install.  Having the index pages wrap lines isn't so bad, but the line wrapping makes the individual case pages very difficult to read.  If there was a way to make tables go wide while keeping the body text at some fixed width, that would be a good compromise.  RoySmith (talk) 18:09, 13 October 2021 (UTC)
 * You might like to try the custom CSS I've been working on, for max-width override. You can either (1) Install it via a browser-extension (as I do) and thus benefit from any updates I make in the future (and easily toggle it on/off). Details at this github page, or (2) put lines 31-51 from this revision into your local common.css or meta global.css.
 * And +1 to your suggestions about making tables go wide, as a good compromise for all users (readers and editors). Cheers, –Quiddity (talk) 00:51, 19 October 2021 (UTC)

Vector dauerhaft behalten
Die »Modernisierungsmaßnahmen« halte ich für eine Totgeburt. Es gibt schon eine Mobilansicht, die ich abschalte, wo immer sie mir unterkommt. Die Anpassung der auch noch Desktopansicht an Schmiertelefone im Hochformat muss deswegen nicht sein. Hamburgermenüs sind bei Monitoren mit HD-Auflösung und besser einfach unnötig. Bleibt die bisherige Ansicht ohne weiße Balken rechts und links auf Dauer nutzbar? –Falk2 (talk) 19:26, 11 October 2021 (UTC)


 * @Falk2, regarding the birth, you are almost correct. The changes are still in the making. We only ask some communities to agree to use them early. Communities such as English or German are only informed about the project, are welcome to give feedback, are sometimes asked for feedback, but aren't asked to have the changes as default. The current default on German-language Wikipedia will remain available. SGrabarczuk (WMF) (talk) 07:52, 12 October 2021 (UTC)
 * …except that Totgeburt is quite not the same as Geburt. —Tacsipacsi (talk) 17:57, 12 October 2021 (UTC)

Confirmation step for log-out
I just tested, and in the new desktop it appears that there is still no confirmation step when a user clicks the log out button, despite this discussion and the supposedly resolved phabricator ticket that came out of it. Could you please make sure that this is resolved before you launch the final version? Apologies, but this is the sort of thing that is incredibly frustrating. Adding a simple "Are you sure you want to log out?" pop-up should be trivially simple for anyone at the WMF who has the right tools, but instead, the community has had to spend an unreasonable amount of effort pushing for this to be addressed. &#123;{u&#124; Sdkb  }&#125;  talk 20:22, 11 October 2021 (UTC)


 * Hi @Sdkb - thank you for raising this. Just to clarify - are you referring to the log out button on desktop or on mobile?  We are currently considering making a smaller change on mobile that would make it clearer that the button is clearly marked with the intention for logging out, based on the task you opened for mobile.  That said, we can also look into adding a confirmation step on desktop as well.  Thanks!  OVasileva (WMF) (talk) 16:13, 13 October 2021 (UTC)
 * In this thread I'm talking about desktop, so different than the phab ticket (although same issue). &#123;{u&#124; Sdkb  }&#125;  talk 16:32, 13 October 2021 (UTC)

About double-click to log in with the new user menu
(from fr.wiki 1, 2)

Hi, when users choose Private Browsing their browsing information is not saved. So, they have to log-in every time. With the new user menu for logged out users this means a double-click to connect. This is unconfortable for users in the opinion of a French editor. For not having to double-click to log in, he suggest to make a link "Créer un compte - se connecter" ("create account - log in") instead of the simple "create account", outside of the menu button. This solution has also been discussed in phab:T273502 and phab:T289212.--Patafisik (WMF) (talk) 08:47, 16 October 2021 (UTC)

I think the main page should be wider
Because of the fact that it contains an actual layout, the smaller width that fits well for documents with mostly text (most pages) doesn’t work as well for the main page. I think it should be moved quite a bit farther to the right:


 * Or just drop the whole width limit, at least on main pages. They usually already contain a massive amount of CSS, their maintainers should take care of making them work on different screen sizes. —Tacsipacsi (talk) 00:27, 24 October 2021 (UTC)


 * There definitely needs to be a way to turn off maxwidth for a multi-column page, or section, or table/image. [what will happen in the current design if you include an image and set an image width of 1600 px?] Sj (talk)!

New media viewer feedback
Two things that puts me off the new "Media Viewer" is that certain objects bounce or move around a little like at the bar at the bottom "more details" on page load and the arrows (I think it might be an animation) which I find that very annoying so I end up going to back to the previous viewer and when selecting next picture it has this effect where it "fades" and blurs and I find that very uncomfortable to look at like there is something wrong with my vision. Sliding wouldn't be bad too bad without anything effects that cause the picture to flash.

The good things I see: I don't see any dimming or gradients on the thumbnails or pictures yet that obscures the top or bottom as with the growing recent trend where it goes beyond the text and covers up large parts of the picture but I'd rather not see gradients at all covering anything up.

No spammy fixed header of widgets constantly there in the way yet.

Some functions at the right hand side, to download, share and not to distracting oh and no silly gradients for that

An option to revert back to the previous viewer which has more details.
 * Hey @MrMobodies. By the new "Media Viewer" do you mean the 2014 Media Viewer, or some newer feature? Anyway, I'm afraid this isn't one of this team's projects.
 * If you mean the 2014 Media Viewer, according to this table, its code stewards is the Structured Data team. This tool has no developers/maintainers. This means the Structured Data team checks if the Media Viewer's code is written correctly, in line with some code standards for developers, but doesn't work to improve the tool. Anyway, I'll inform my colleagues in Structured Data - that's what I can do. SGrabarczuk (WMF) (talk) 15:00, 28 October 2021 (UTC)

Barre de recherche : pas de suggestion avec le préfixe Special:
Bonjour, sur l'ancienne barre de recherche de Vector, lorsqu'on tapait, on commençait à avoir des suggestions par exemple Special:AbuseFilter. Cela facilitait la vie des contributeurs faisant de la maintenance ou de la vérification, si on ne connait pas le nom exact. A noter que l'éditeur visuel peut aussi suggérer ce type de page. Mais avec la nouvelle barre de, il n'est plus possible d'avoir des suggestions de recherche. Est-il prévu d'y remédier ? Merci à vous pour le travail déjà entamé, --  Nemo  Discuter 16:37, 2 November 2021 (UTC)
 * Merci, this is the dedicated task on Phabricator: T277363. SGrabarczuk (WMF) (talk) 18:18, 4 November 2021 (UTC)

Search box size and location
Hi. I have 3 initial thoughts about the sticky header. I hope those details help! –Quiddity (talk) 02:36, 10 November 2021 (UTC)
 * 1) I really like the easy access to the page-tools, without having to scroll up or remember the key-combinations! I've been wanting this for years.
 * 2) I'm still hoping for easy 1-click access to my watchlist, which I access multiple times each day (and the Watchlists system is good for newcomers to become familiar with, which they won't if it's buried in a menu, and even below the "Preferences" item which most people rarely access.)
 * 3) Vector-sticky-header-version1-search-size.png (Main point) I'm feeling very frustrated when I try to use the Search in its new location, partially because the click-target is so small, and partially because it is in an inconsistent location.
 * 4) The box I need to click on is very small. Previously, I was loving the increased size of the search box in New Vector. This new design is vastly smaller than the previous iteration, and quite a bit smaller than the classic design. Search is one of the most core activities readers/editors/users engage with, and deserves as much target area as feasible.  [See screenshot, for emphasis/clarification.]
 * 5) * (cf. Fitts's law for more details about link target size - TLDR/IIUC, it's all about how many micro-adjustments we need to make, after the first initial "rough" movement in the general direction of the target.) [Edit: I believe this is also a significant part of the reason for why many users advocate for "text instead of icons" in some circumstances - we/they like the inherently bigger click-targets.]
 * 6) The magnifying-glass icon is in the same "area" within a browser window as the "hamburger menu" - This is confusing for muscle-memory, and should probably be consistent instead, so that I can reliably tap or click in the same area of the screen, to start a search, regardless of whether I've scrolled down.
 * 7) * I can appreciate the idea of showing the "Page name" and perhaps "Section name" at the top, but I think the Search-box needs a very large click target, so that we can throw out mouse-cursors/fingers in the general direction and be likely to end up in the exact correct spot. -- My only idea for how to resolve these 2 goals, is to show the page-name within the search box. I'm not sure if that would work.
 * 8) * I also appreciate that having it in the corner, might be beneficial for some Mobile users, because that places the click-target nearest to the thumb. But it is very frustrating for me as a mouse user.