Talk:Reading/Web/Desktop Improvements/Archive3

Bug? Footer engulfes content

I've seen this from time to time. Examples (with activated new skin of course):

• b:de:Die_Rennmaus/_Haltung/_Käfigstandort#Der_Käfig_sollte_nicht
• b:de:Computerhardware:_RAM:_Geschwindigkeit

Regards (PS: Sorry if it's the wrong verb in the header, I wasn't sure how to describe the effect, feel free to change to sth appropriate) --HirnSpuk (talk) 23:23, 4 March 2021 (UTC)

You will need to use the ```{{clear}}``` template here. This user-content error was previously taken care of in the older skins, but in this new skin is the responsibility of the editor. Jdlrobson (talk) 20:09, 10 March 2021 (UTC)

@Jdlrobson: So you’re breaking something that worked for 15+ years just for the sake of breaking it? I don’t think there’s a single valid use case where content should get out of the content area. And it’s pretty easy to fix centrally instead of individually on hundreds of wikis, or, even worse, on probably tens or hundreds of thousands of pages as you advise. Simply

main::after {
	content: "";
	display: block;
	clear: both;
}

needs to be placed in whatever CSS/LESS file it belongs to. —Tacsipacsi (talk) 00:07, 11 March 2021 (UTC)

Where did I say I was breaking something " just for the sake of breaking it" ? My intention was to explain why it's happening.

Vector is essentially a new skin, so things can and will break, but the idea is that when they're fixed they are better defined and less fragile. New Vector has only been around approx 1 year and while it is based off of old Vector, and we're trying to keep it aligned with it, its not the same thing, so 15+ years comment here is a little misguided. It uses a completely different stylesheet.

" And it’s pretty easy to fix centrally instead of individually on hundreds of wikis" - I don't know, but you are probably right, but then that doesn't sound like a responsibility of Vector but of the skins code inside mediawiki core. The `mediawiki.skinning` module https://github.com/wikimedia/mediawiki/tree/master/resources/src/mediawiki.skinning was set up to define rules that are common to all skins and is where such styles should live and there is currently no such rule for clearing user generated content, so this issue likely impacts other skins (most likely ones not deployed on Wikimedia wikis. I've created phab:T277218 to document the problem. Jdlrobson (talk) 19:40, 11 March 2021 (UTC)

@Jdlrobson: The “you” was plural—silly English doesn’t differentiate between singular and plural here. :( Some developer broke it. I don’t care who was, but that person seemingly didn’t have any good reason to do so.

The 15+ years is relevant because editors have been designing pages for 15+ years with the assumption that content will remain within the content area. Breaking such assumptions needs very good reasons, which are not here.

I also don’t care what piece of software it’s fixed in, so if you think it’s better fixed in core rather than in Vector, feel free to do so, just fix it in software rather than forcing folks to fix it on-wiki. Anyways, thanks for opening the ticket! —Tacsipacsi (talk) 23:39, 11 March 2021 (UTC)

We are on the same page. I just want to make sure any assumptions are defined and clear to all stakeholders whether editor or mediawiki developer rather than implied :) Jdlrobson (talk) 03:05, 12 March 2021 (UTC)

Integrated Dark Mode color scheme

Dark themes are nowadays ubiquitous due to how easy on the eyes and optimized for displays they are. While there's also "hacky" ways (like browser extensions and scripts), they're community efforts at implementing this missing feature from outside, and it's hard to make them work perfectly fine and responsive for everyone. Please, consider implementing a native setting for it. --CapoFantasma97 (talk) 17:04, 5 March 2021 (UTC)

@CapoFantasma97, thank you for this suggestion. The concept of a native MediaWiki dark mode has got a long history now. Just take a look at the Community Wishlist Survey 2019 wish and 2017 wish. Our designers agree with you and would love to build the dark mode, but... ;)
(See the rest in my answer to the "Night mode clash" below.) SGrabarczuk (WMF) (talk) 23:55, 10 March 2021 (UTC)

Yep, at the very least prefers-color-scheme should definitely be incorporated, with a legible colour scheme to match. HughLilly (talk) 23:56, 12 April 2021 (UTC)

Night mode clash

Hi @SGrabarczuk (WMF):

The status update from the Community Tech team indicated that they'd started working on this but were not able to proceed because their work would clash with this team, and therefore a night mode would ultimately need to come from another WMF tech team, either this or another.

Could you clarify what prohibited that effort, or what prevents night mode being scoped in as part of this project - it is a rare change that is overwhelmingly requested by both the editing community and a constant avalanche of reader requests. I've no doubt that WMF employees would also like it, or at least think its a good option, so it's more finding "what are the sticking points preventing resources being allocated to it" and then "what can we do about those"? Nosebagbear (talk) 17:14, 7 March 2021 (UTC)

@Nosebagbear, great question! Both teams are well aware that the dark mode is desired by many. It was decided that Web would take care of that because it was going to work on related improvements anyway.

Why the dark mode is not in the scope of the current project? It's a mix of reasons. Some of them are of technical nature and I'm not familiar with that part. So my apologies, but it's not going to be a full answer :/

First and foremost, we're all interested in something better than a smart replacement. It appears that such a feature requires more investment than you or I suspect. More than a year ago, there was a decision to make: either the team would build most of the features currently being on the list, or it'd pick the dark mode and a few other improvements. We know what the decision was, but I don't know the factors involved.

Now, the dark mode is a strong candidate on top of a list of potential future tasks. SGrabarczuk (WMF) (talk) 23:45, 10 March 2021 (UTC)

Update and correction: the dark mode has been a candidate for a long time, BUT first, we would need to have more servers. Physically. Then we would be able to develop how we cache. At the end, we would be able to build things like the dark mode. If we did a dark mode now, users would have to turn it on each and every page they would visit individually. SGrabarczuk (WMF) (talk) 13:56, 11 March 2021 (UTC)

Opinion (that most likely will be ignored)

It is true that reading a text written along the entire Great Wall of China is hard. But is also true that it is hard to read a text written on a flea wing. Reading/Web/Desktop Improvements/Repository/First Prototype Feedback Report#1. Readability: The size of characters was took into consideration? And Wikimedia wikis also contain images, infoboxes, tables and other things that need space. And stop saying that I will can return to the original Vector; I want a good skin for editors and readers. --NGC 54 (talk | contribs) 10:51, 8 March 2021 (UTC)

@NGC 54, you know your opinion would not be ignored! :) Yes, the size of characters as well as the size of the screens were both taken into consideration. We have made one step in this direction and we're not saying we won't make next steps. Watch the updates from the team and keep your fingers crossed for our plans after the already planned improvements! ;) SGrabarczuk (WMF) (talk) 00:03, 11 March 2021 (UTC)

@SGrabarczuk (WMF): "you know your opinion would not be ignored!": How so? I repeat: the width is too small. --NGC 54 (talk | contribs) 11:36, 11 March 2021 (UTC)

@NGC 54, first, I do read each comment posted on this talk page. Secondly, I see that some volunteers from various wikis raise a fair point: on large screens, the width does feel small. I loyally pass this information to the Web team. The team does recognize this issue, and we will talk about this with due respect to all Wikimedians who ask us to adjust the limited width to their needs. SGrabarczuk (WMF) (talk) 12:11, 11 March 2021 (UTC)

Best design!

That's a very good argument I didn't even think about: Wikipedia contains images, infoboxed and tables, and it's gonna be a big mess if this doesn't get any space. Edit: I've ready about this in the FAQ and the argument is given that "people with smaller screens have had the issue before". The most common monitor screen size is between 21-24 inch, and screens are even getting bigger/wider. Maybe some research has to been done about that. It's impossible to give literally everyone the best experience, but it is about giving the best experience to as many people as possible, in this case that group is people with a larger screen size. Lots and lots of Wikipedia articles revolve around tables and images, if we take that away (or even position them on the side, and they are not in their right section), the reading experience gets worse for lots of people. Just like a few others, the design on the right is best for me personally: a collapsible side bar on the left is fine, but keep the content through the rest of the page including infoboxes, tables, images, etc. Coldbolt (talk) 19:39, 9 March 2021 (UTC)

@Coldbolt, you are absolutely right. People buy larger and larger monitors, there are panoramic monitors, etc. When we will be planning the next fiscal year (which will happen soon because the fiscal year begins in July and the plans have to be ready earlier than that) we will be considering how to improve the experience of users with large screens. SGrabarczuk (WMF) (talk) 00:45, 11 March 2021 (UTC)

How to localize logo when legacy vector turned off

Hello, I have recently started using the new Vector Skin in Assamese language Wikipedia. However, I see that the logo is not localized. Can you let me know how to do that? Does local interface admin will have to take care of that? --SlowPhoton (talk) 10:54, 10 March 2021 (UTC)

This is tracked in https://phabricator.wikimedia.org/T244486 and https://phabricator.wikimedia.org/T142426. In the latter you can help provide the wordmark if you want and are able to help. Jdlrobson (talk) 20:02, 10 March 2021 (UTC)

Generally speaking, the Web team will eventually provide the logos. Volunteers are welcome to help. Specific permissions (like local interface adminship) or local edits aren't required. SGrabarczuk (WMF) (talk) 22:19, 10 March 2021 (UTC)

Option to keep Legacy Vector as default

I don't accept a limit of content width. Users have the right to resize the window to achieve a proper width, and you shouldn't be opinionated.

Content width same limited, the new Vector looks full of disorder just compared with Skin:Timeless.

Hope my sites can keep Legacy Vector as default finally, otherwise we may have to add CSS rules to revert such "improvement". Lt2818 (talk) 07:00, 11 March 2021 (UTC)

I am one of the users that like the direction the new Vector is taking, and I disabled the Legacy mode on my side. A proper page layout greatly helps in readability, as the human eye can focus only on a small area, while peripheral vision is not useful to make out details, which is required for reading (otherwise we'd use smartphones only in landscape mode...). The website is still well responsive to window/screen size, it just has a maximum width. Filling a 16:9 screen side to side with text isn't "proper" width (nor is it on 21:9!) and makes it less comfortable to read.

Some people might not like space, but it's not a bad practice at all in typography; instead, it's a good thing when properly used. As such, it makes no sense to regard it as "wasted space" because it's not, it's helpful to format the page, and it could be used in the future for extra content like side panels; also, some modules and page sections could be moved there (imagine notes and references next to the paragraph they refer to!). --CapoFantasma97 (talk) 12:18, 11 March 2021 (UTC)

You can't find another website which has an empty right column. I see Winter put infoboxes and Timeless put related links there, both better than the new Vector. Also, other skins try to align elements to their best positions, but this one is a disaster.

Vertical writing systems are also ignored. The new Vector is obviously not going to support site-wide vertical writing of Classical Chinese. Don't say you can limit content height instead. Lt2818 (talk) 09:58, 17 March 2021 (UTC)

Max width fix for logged out users

I've released a new max-width fix. Apologies for waiting so long, I've been making time to write it as a CSS user style, but it seems to be outside my web design abilities, so I've written it as a JavaScript user script. This one shouldn't break on future updates to Vector 2.0.

You can download it from https://pastebin.com/3KY1QmzU and install it with any user script addon. The most commonly used are GreaseMonkey, TamperMonkey and VioletMonkey, and they are available for pretty all commonly used browsers (Firefox and forks, Chrome and forks, Edge, Safari, Opera...).

Please report any errors here or on my talk page. Happy browsing! Vectorman007 (talk) 11:28, 11 March 2021 (UTC)

Hello, maybe this is more or less the topic I would like to address. I very much dislike the fixed max width for the text in the new skin. That is the reason why I have opted out.

The problem: On my PC screen, I usually don't have the window/tab with Wikipedia on full screen. I find that too wide, there are too many words in a line. Also, usually I have other windows open, and I place them next to the window with Wikipedia.

So my Wikipedia window usually covers only half or two thirds of the screen. But then, with the new skin, a side bar appears, and I have to scroll the text horizontally in order to read it. Very annoying, of course.

That is the reason why I will opt out of every new skin with a fixed max width. Could the fixed max width become a separate feature instead? Ziko (talk) 15:04, 6 April 2021 (UTC)

Vector is just fine as it is

>It has been 10 years since the current default Wikimedia skin (Vector) was deployed
It has been 10 years of a damn fine interface is what it has been. It ain't broke, it works well, don't fix it, and for the sake of all that is holy, DON'T impose it on everyone. There is no logical reason, none whatsoever, under the sun, why you should remove the existing interface as an option. And there is no reason why PC users, who must surely make up the majority of editors, should have the use of half of their screen taking away by this thieving gang of cadres, eager to do something even when nothing needs to be done. Lord have mercy. Beaneater00 (talk) 01:51, 12 March 2021 (UTC)

I completely agree. If you are going to move on with this hideous project, at least let us who don't like it opt out. --PastelKos (talk) 22:38, 3 April 2021 (UTC)

@PastelKos, I encourage you to read the main page of the project as well as sub-pages dedicated for each feature. You will learn why and how the change is performed. SGrabarczuk (WMF) (talk) 11:14, 13 April 2021 (UTC)

New location of search bar now available on all wikis

Please could you add details of how this is enabled — GhostInTheMachine ^{talk to me} 00:07, 13 March 2021 (UTC)

@GhostInTheMachine, go to your preferences, second tab. Find "Skin preferences". Uncheck "Use Legacy Vector" (= don't use Legacy Vector), go to any other page, and the new location should be displaying. Does that answer your question? You can also set a global preference to see the new Vector on all wikis. SGrabarczuk (WMF) (talk) 13:20, 15 March 2021 (UTC)

Sadly, that does answer my question. Having the search bar moved in Vector would have been somewhat better. Perhaps the main page could also make this clearer? — GhostInTheMachine ^{talk to me} 14:31, 15 March 2021 (UTC)

@GhostInTheMachine, my apologies, I don't know what is your expectation. Are you asking about the code or Vue.js, things documented on Phabricator and Gerrit, that is, how have our engineers moved the search widget? Maybe you've got ideas how the design of the widget could be improved? SGrabarczuk (WMF) (talk) 16:43, 15 March 2021 (UTC)

Too much wasted space in desktop (sorry for bad english)

When connected from desktop with a resolution of 1920 × 1080, there are 1000 pixels of wasted space left and right. This is too hard to read and inefficient. --소언예 (talk) 22:54, 13 March 2021 (UTC)

Thank you @소언예! Have you read our documentation: the FAQ and/or Limiting content width? What do you think about the arguments mentioned there? SGrabarczuk (WMF) (talk) 14:02, 15 March 2021 (UTC)

If what I understood is correct, did you intentionally narrow it down for readability? --소언예 (talk) 13:14, 16 March 2021 (UTC)

@소언예, yes, this is correct. SGrabarczuk (WMF) (talk) 13:09, 19 March 2021 (UTC)

Maybe my complaint is just because it's unfamiliar. Thank you! --소언예 (talk) 17:59, 19 March 2021 (UTC)

About how the sidebar moves

Hello, I'm Kyosu-tanni.

I have some ideas about how the sidebar moves:

• the button which shows/hides the sidebar is presently shown at the top of the page, but it seems better to shown in the area the user is seeing - sometimes want to let the hidden sidebar be shown even if the page is scrolled down.
• The scrolling of the sidebar and that of the main content is better to be independent of each other - the reason being same as above, often want to see the content of the sidebar even if the page is scrolled down.

Thank you! Kyosu-tanni (talk) 11:45, 16 March 2021 (UTC)

I have an  additional idea: to make the sidebar customizable.

How about:

• moving the button to show/hide the sidebar, to the left side
• change the icon of the button to one that signifies sidebar as a pictogram
• allow users to add some kinds of sidebar - e.g. one that shows watchlist as one of sidebars even in a non-watchlist page
  • sidebar-type TOC may be also good.

It is difficult to explain this by text... At the point of view of copyright, is it allowed to upload videos that is made by exporting on Microsoft PowerPoint?

Thank you! Kyosu-tanni (talk) 11:44, 19 March 2021 (UTC)

The original language list will no longer appear on the sidebar

@SGrabarczuk (WMF): Some questions

1. In Reading/Web/Desktop Improvements/Features/Language switching page you are writing that the original language list will no longer appear on the sidebar. However, it doesn't say if users could still select the the old list from preferences like they can full language list now from preferences (Special:Preferences#mw-prefsection-rendering and m:Special:GlobalPreferences#mw-prefsection-rendering)?
2. If the old list with full languagelinks cannot be selected via preferences then will it be possible to enable it using user javascripts or gadgets? (ie. how the We will have a non-JavaScript fallback which will display the full list of all languages for users that do not have JS access. will be implemented?)

Br, --Zache (talk) 12:21, 16 March 2021 (UTC)

Captured in phab:T277517 Jdlrobson (talk) 00:18, 18 March 2021 (UTC)

Thanks, I am not sure that we are talking on same thing though. However I was able to browse through phab tickets to Betawiki and found and example article for the (prototype?) of a new language selector which give a look and feel of it. --Zache (talk) 10:31, 18 March 2021 (UTC)

Max-width_gadget

Talk:Reading/Web/Desktop_Improvements/Archive2#Max-width_gadget or the anything based on skin-vector-max-width CSS class doesnt seem to work anymore. What is proper way to remove the width limit using gadget/javascript/css currently?

Also link to the documentation for the used CSS-classes would be nice if you have it somewhere. --Zache (talk) 03:11, 17 March 2021 (UTC)

I was able to solve this. My version of the full-screen gadget is in w:fi:mediawiki:Gadget-FullWidthVector.css and w:fi:mediawiki:Gadget-FullWidthVector.js. --Zache (talk) 07:05, 17 March 2021 (UTC)

Just some thoughs. The ability to limit the width of the page is awesome and useful. However making it as mandatory is not and it would be a good idea to make it as an toggleable feature like the side bar is. This can be done using gadgets, but there is couple problems with this approach. One is that if the feature relies to javascript to initialize it then the gadget or user javascript will be loaded after page is loaded and page will render itself first using the narrow page width and then re-renders it to full width. This will be visible to user. Another approach would do it using purely using CSS which will be loaded before page is rendered but you actually overwrite CSS values set by Vector skin and not just to add new CSS-rules which you can toggle on/off.

It would be a lot better if the option would be directly supported in the skin itself. Ie, mediawiki would read the wanted state from user settings and then set the css class which would define if the content is in full-width or narrow mode. In this way the re-rendering could be skipped and you could also collect data on if users are using narrow/widescreen settings --Zache (talk) 07:30, 17 March 2021 (UTC)

Changing language on the main page

Old version can change language on the main page, but new version can't. The process of searching through another language wikis is too long. Are there any plans to make it? --소언예 (talk) 18:38, 19 March 2021 (UTC)

Thanks! This looks like a bug, not a feature. I've submitted a task on Phabricator. SGrabarczuk (WMF) (talk) 12:07, 22 March 2021 (UTC)

How to pre-opt for an entire community (fr. wikiquote) ?

I asked on the "Salon" of the French Wikiquote wether people would be interested in pre-opting, as a community, for these desktop improvements, and people are interested (only three answers, but French Wikiquote currently has a very small regular, active community). So, how can we pre-opt ? The "Participage" page says "contact us", but who are "us" and how do we contact them ? (That should be added on the page for clarity's sake, in my opinion.)--Eunostos (talk) 12:30, 20 March 2021 (UTC)

@Eunostos, thank you! Just as this page explains, you can contact me. And you have, so we'll have you on our radar. SGrabarczuk (WMF) (talk) 11:56, 22 March 2021 (UTC)

Wide tables benefit from using the full width of the screen

Certain Wikipedia articles contain really wide tables. The reasoning for a narrower page doesn't apply to those, you would never want padding when viewing an Excel spreadsheet. For example, not having the rightmost column on w:List of ISO 639-1 codes go to the edge of the screen only makes the table harder to read.

Another issue: w:List of Nvidia graphics processing units has tables that go past the width of the page, but the background abruptly changes from white to gray on the right. Akeosnhaoe (talk) 04:01, 26 March 2021 (UTC)

This is tracked in https://phabricator.wikimedia.org/T267161. Thanks for reporting! Jdlrobson (talk) 14:48, 26 March 2021 (UTC)

For me, the ISO table looks way better when limited to 960px. Some comments in the rightmost column get wrapped into two, sometimes three lines, and it is totally fine. And, since you brought up Excel, it has an option to wrap text in column, not have it in one endless line to the right of your table, for a reason. Cheers! SSneg (talk) 14:47, 5 April 2021 (UTC)

The new search field is too narrow

When I start typing in the new search field, a Search button appears in addition to the magnifier icon. It takes up too much space; with a 1024px wide viewport the useful part of the search field is only 192px wide on the French Wikipedia, as opposed to legacy Vector’s 231px on the Hungarian Wikipedia (17% width loss). Even on my larger screen, although it’s actually a few pixels wider, it still feels narrower (probably because its vicinity is too crowded). You should also take into account that not all languages have such short words as Search; French is Rechercher (10 letters instead of 6), while the Bavarian translation is Suach Boarisch oda Deutsch (okay, that literally means “Search in Bavarian or in German”, but it’s still what would be shown with Bavarian interface). —Tacsipacsi (talk) 00:39, 28 March 2021 (UTC)

The logo should be reworked completely for the small resolution

While we in the Russian Wikipedia were preparing a 1 April logo (our annual tradition), we happened to notice that the new Vector has a critical flaw which, I think, many have overlooked before. The problem is that, in the new Vector, you can't see individual letters on the Wikipedia's logo, given that it's made very small. That kind of defeats the purpose of the logo.

Generally, in design, when you create a logo for small resolutions, you remove details or make them larger. This hasn't been done in this case. The puzzle pieces have not been made larger, they have the same size as in the big resolution variant. Jack who built the house (talk) 22:12, 31 March 2021 (UTC)

Long ago I saw an redesign proposal that featured a simpler version of the logo, namely Wikipedia affiliative mark.png. I always thought it was a beautiful idea and would solve the issue you're pointing out. However I bet many will complain that it removes the multilingual aspect of the current logo, and in any case changing the logo would be a massive enterprise on itself. Sophivorus (talk) 12:22, 3 April 2021 (UTC)

Totally agree. The logo needs a redesign to improve legibility of the the smaller variant. Whether it should be radically changed from a globe to a piece of puzzle, I'm not sure. SSneg (talk) 14:50, 5 April 2021 (UTC)

I also agree that this redesign requires a smaller logo, and think Wikipedia affiliative mark.png is perfect. This is what it would look like at 70px; I don't even know if it needs File:Wikipedia-wordmark-en.svg and File:Wikipedia-tagline-en.svg next to it. Edit: Per a previous discussion, I also think the tagine ought to go, even if the wordmark stays. HughLilly (talk) 23:48, 12 April 2021 (UTC)

This is an interesting discussion, and I encourage you to continue. However, the Web team has neither the intention nor mandate to make any changes to the brand, and are not the addressee of these ideas. Meanwhile, I'll inform my colleagues in the Communications department who are more familiar with the brand aspect than we are. SGrabarczuk (WMF) (talk) 13:07, 13 April 2021 (UTC)

Smaller logos for larger screens? It is a desktop change, not a mobile one. The mobile interface is independent from the desktop one... And a single piece of puzzle instead of a puzzle-globe? Why? Wikipedia is more incomplete than before? --NGC 54 (talk | contribs) 13:19, 13 April 2021 (UTC)

Well, my thoughts are just a suggestion. The current logo is an incomplete puzzle of a globe, and is 50px square (at least on my computer). A single puzzle piece, on which the "W" is more legible, could imply—on an article page at least—that the user is viewing just one 'piece of the puzzle,' so to speak.HughLilly (talk) 01:29, 14 April 2021 (UTC)

Is there any reason(s) why Wikipedia is not presenting texts with right justification by default ?

(when languages read from left to right)
I think that's this would improve presentation, and participate to easier reading.
--Hc balestrieri (talk) 20:25, 2 April 2021 (UTC)

@Hc balestrieri, thank you, this is a good question. Sadly, justification is more complex than it could appear. Ideally, such changes should be made independently on each individual wiki.

There are various counterarguments to a justification turned on across the wikis. Two random examples:

1. Justification works if hyphenation is turned on. Otherwise, the spaces are too large, and a distracting river effect appears. However, not all browsers support the hyphenation.
2. Various languages and scripts have different hyphenation rules. It'd be difficult to ensure proper behavior across the language versions of Wikimedia projects.

SGrabarczuk (WMF) (talk) 13:34, 13 April 2021 (UTC)

I truly dislike the limited content width on Serbian Wikipedia (this is an under-statement)

The limited content width that recently appeared on Serbian Wikipedia really bothers me to that extent that I always end up going to read Wikipedia in another language. The amount of text that you can read on the screen is terribly limited, and this is particularly true for Wikipedias written in Cyrillic script where the letters are wider.
The other thing of huge concern is that anonymous readers are not given the ability to choose their display. Remember that Wikipedia exists for billions of anonymous readers around the world. And also, that they do not have the right to vote or express their opinion.
I truly hope that an option for every reader to choose their display will be allowed. Thank you. - Emilijaknezevic (talk) 02:47, 6 April 2021 (UTC)

No moving/changing elements on page

Hello, in general I appreciate the efforts to improve our wiki skin. I would like to ask you, though, not to put changing elements on a wiki page. On the page I see now elements change constantly for the A/B illustration. It is very annoying for me when something is moving on a page, because I cannot concentrate then on the text. It would be better for me if I had to click on a button in order to start/pause a changing element. Kind regards Ziko (talk) 15:10, 6 April 2021 (UTC)

@Ziko, would you be able to specify which elements are changing? Thank you! SGrabarczuk (WMF) (talk) 13:36, 13 April 2021 (UTC)

New Search Widget Complaint.

I was enjoying the vector improvements very much until the most recent changes to the search widget. Currently images for similar searchs are visable alongside their articles, although this initially seems helpful, it makes it near impossible to avoid viewing sexual or violent images, for example upon entering the two letters "an" you are immediately greeted with a graphic depiction of anal sex.

I am aware wikipedia is not censored but surely there should be a skin option to turn off images in the widget so such imagery is not effectively mandatory to view for users even if their respective pages are not read the by the user.

I think this especially important, as this the default skin and introduction the majority of readers get to wikipedia, And as a large amount of the world have obections to such content, it is not an excellent introduction to potential wikipedians.

Several other skins also have this issue, and it would be nice to at least have the option to disable unavoidable images in the searchbar especially as the page on "options to hide images" does not resolve the problem. — Preceding unsigned comment added by Transcendent Presence (talk • contribs) 05:24, 11 April 2021‎ (UTC)

It is possible to turn off the images in the search results by editing common.css and adding a rule to not display background images for spans of the class .wvui-typeahead-suggestion__thumbnail . Something like

span.wvui-typeahead-suggestion__thumbnail {
	background-image:none !important;
}

Vexations (talk) 21:35, 13 April 2021 (UTC)

Thank you very very much! incredibly helpful.

Are the Main page sections meant to be numbered?

I'm seeing the secitons on the Main page 'numbered'. Is this by design on this new version of Vector? HughLilly (talk) 01:38, 14 April 2021 (UTC)

@HughLilly: Heading numbering is a feature that can be enabled and disabled from your preferences in the Appearance section and has always been a feature. —TheDJ (Not WMF) (talk • contribs) 10:47, 14 April 2021 (UTC)

Hi @HughLilly, TheDJ is right, this feature is independent from the skin choice. We don't have any plan or even intention to make it a part of the new Vector. SGrabarczuk (WMF) (talk) 12:40, 14 April 2021 (UTC)

Oh, thanks; I must've turned it on without realising. Thank you. HughLilly (talk) 23:07, 14 April 2021 (UTC)

image collage problems with limited content width and voting question

As we can see in (https://di-collapsible-sidebar-2.firebaseapp.com/Lute) there's a big problem with image collages etc. in the limited content width version of this project. How is this going the be solved? And is there going to be some sort of voting from the community whether changes get implemented? Just "opting out" from a combination of different features and getting that number below 40% is not the way this is supposed to be handled in my opinion. I would like to know when changes get final. And when are we going to see solutions/discussions about my first question and solutions for people with large monitors? Because I'm truly afraid of this content width change. Coldbolt (talk) 22:41, 18 April 2021 (UTC)

Hi @Coldbolt! I understand the width issue is important for you, and I remember you've got a large screen. Unfortunately, we haven't formed an answer to your first question posted earlier on this page yet. I assure you, this isn't because we don't consider the point you're raising as important. We just need to conclude other topics first to get to that point. When we have and answer about the large screen support, we'll definitely let you know.

What you've found is a collapsible sidebar prototype. Templates, CSS classes and styles etc. are not related to the collapsible sidebar, and may not work properly in the prototype. When you check how that article looks with our changes, you will notice that there is no problem with image collages.

Now, we are working just with the communities who have volunteered (or accepted our offer) to get our features first. We've got, if I recall correctly, something like 8-10% opt-out rate in average across those wikis. So it's clearly way below 40%.

Before the changes get final (this should happen by the end of the calendar year) we will begin communicating why we are introducing the changes, how these are working, where our data come from, where to share feedback, etc. A post on the Foundation blog will appear soon. This will be a series of blog posts, really. Last but not least, Olga (the manager) and I will personally put a lot of effort to make this collaborative, and the current state is far from the final look. SGrabarczuk (WMF) (talk) 11:09, 19 April 2021 (UTC)

This really was the answer I was looking for, thanks! Thanks for listening, doing so much research, and being so clear on what to expect. I'm looking forward to the blog posts, results and more. Coldbolt (talk) 11:22, 19 April 2021 (UTC)

No content above the fold in narrow view

In web design, it’s a basic thing how much content appears “above the fold”, i.e. without scrolling. Well, if the viewport width is at most 720px, it’s zero. The page title appears around 1420px below the top of the page in my 665×705px slightly portrayish browser window on MediaWiki, i.e. it’s not even that no content appears above the fold, but I scrolled a full viewport height, and there’s still no content, only interwiki links and namespace tabs! I know that the sidebar is collapsed by default for logged-out readers, but this is not okay at all for logged-in editors either. I don’t know how to solve this, but something should definitely be done about it. —Tacsipacsi (talk) 19:56, 19 April 2021 (UTC)

indentation lists with Microsoft Edge

Hello, I wanted to inform you that the indentation of bulleted and numbered lists on Microsoft Edge in vec.wiki are without indentation, while on Chrome the indentation is correct. is it my problem or has the problem already been found? --ꜰɪᴇʀᴏᴅᴇʟᴠᴇɴᴇᴛᴏ (Talk)-(Contributions) 11:39, 4 May 2021 (UTC)

Hello @Fierodelveneto. Would you be able to share some screenshots? I've checked Edge and Firefox, and haven't noticed any difference between vec and any other wiki. I'm afraid this might be due to your personal settings. Thank you! SGrabarczuk (WMF) (talk) 22:23, 6 May 2021 (UTC)

Мне кажется, что новый список языков — плохая идея

Плюсы — появился поиск в списке языков, но это очень маленький плюс. Но лично по моему опыту список языков используется в основном так:

• Есть два-три «любимых» языка (обычно те, которые сам немножечко знаешь), которые нужны чаще всего;
• Нужно узнать, есть ли статья на одном из языков, чаще всего — из списка «любимых», либо имеющем отношение к теме статьи;
• Нужно прощёлкать все языки подряд, например, например, в надежде найти авторитетные источники на другом языке.

Теперь приходится делать дополнительные прицельные клики там, где раньше можно было обойтись прокруткой или даже она не требовалась. Плюс выпадающее окошко имеет свою полосу прокрутки. В некоторых трудноуловимых случаях браузер вместо того, чтобы прокручивать текст в окошке, начинает прокручивать всю страницу. Это, конечно, проблема браузера, но это тоже раздражает и усложняет взаимодействие со списком языков. Плюс группировка языков только мешает, когда нужно пройтись по всем языкам: уже просмотренные никак не выделяются, а в список они попадают несколько раз.

В общем, если ваши инженеры по UI/UX считают, что новый список языков — это хорошо, то пусть они хотя бы сделают возможность переключиться на старый вид.--Tucvbif (talk) 08:45, 6 May 2021 (UTC)

@Tucvbif, спасибо за ваши наблюдения. Я думаю, что некоторые из них нуждаются в пояснении. Скорее всего, мы добавим дополнительные кнопки к наиболее часто используемым языкам. Кроме того, вы можете искать по списку. Вам не нужно прокручивать. В этом году языковая группа внесет улучшения в сам список языков. Если по какой-то причине вас все еще не устраивает, вы сможете переключиться на «Устаревший» вектор. Мы предусмотрели эту возможность в самом начале наших изменений. (Thank you for your observations. I think some of these need clarification. Most probably, we will put additional buttons to the most used languages. Apart from that, you are able to search the list. You don't have to scroll. This year, the Language team will deploy improvements to the language list itself. If for some reason you are still not satisfied, you'll be able to switch to the "Legacy" Vector. We provided this option at the very beginning of our changes.) SGrabarczuk (WMF) (talk) 20:38, 1 July 2021 (UTC)

@SGrabarczuk (WMF) но мне не нужна тема «Устаревший Вектор», я как раз хочу пользоваться актуальной темой, и при этом иметь удобный список языков. По кнопкам «наиболее часто используемых языков» — они будут настраиваться один раз для всех языков, или мне нужно будет в каждом языковом разделе настраивать любимые языки отдельно? Кроме того, очень неудобным остаётся случай 3 (прощёлкать все языки подряд): нужно открывать список языков и искать среди них те, в которых ещё не побывал. Поиск тут не поможет, без прокрутки тут не обойтись, что делает список неудобным. Сначала нужно прицельно ткнуть в список языков, чтобы открыть его, потом перевести курсор на список, чтобы прокручивался он, а не вся страница, затем прокрутить, чтобы найти очередной непосещённый язык, и только после этого ткнуть в нужный язык. В старой версии достаточно было двух последних действий. --Tucvbif (talk) 12:14, 14 July 2021 (UTC)

И ещё вопрос: как будут добавляться интервики? Сейчас это неочевидно. --Tucvbif (talk) 12:27, 14 July 2021 (UTC)

Hey @Tucvbif.

1. Я думаю, что у нас будет более удобный список языков, когда языковая команда закончит свою работу.
2. «Oни будут настраиваться один раз для всех языков, или мне нужно будет в каждом языковом разделе настраивать любимые языки отдельно» — У каждой вики будут свои настройки. В дополнение к этому, кнопки будут настраиваться пользователем на основе индивидуального выбора.
3. «Поиск тут не поможет, без прокрутки тут не обойтись, что делает список неудобным» — Что ты имеешь в виду? Когда поиск не работает?
4. «Как будут добавляться интервики? Сейчас это неочевидно» — Команда обсуждает временное восстановление ссылки на Викиданные. Когда языковая команда сделает свое дело, ссылки на Викиданные будут добавлены по-новому.

English:

1. I think we will have a more convenient list of languages when the Language team finishes their job.
2. "Will they be configured once for all languages, or will I need to configure my favorite languages ​​separately in each language section?"—Each wiki will have its own setting. In addition to that, the buttons will be configurable by user based on individual choices.
3. "Searching will not help here, you cannot do without scrolling here, which makes the list inconvenient."—What do you mean? When doesn't the search work?
4. "How will interwiki be added? It is not obvious now"—The team is discussing to restore the link to Wikidata temporarily. When the Language team does their part, Wikidata links will be added in a new way.

SGrabarczuk (WMF) (talk) 19:11, 19 July 2021 (UTC)

Adding Interwikis / Wikidata element and hover of quality badges

I just realised that with having the language links moved to the top spot, also the old link for adding the Wikidata connection / other language versions to an article has apparently vanished. How is that supposed to work in the future? Another thing I noticed in that context is that the star icons for good/featured articles next to the language links do not show good/featured on hover anymore, which makes them less helpful. Regards --XanonymusX (talk) 20:15, 7 May 2021 (UTC)

Removing the link for adding the Wikidata connection / other language versions to an article seems like a bad idea. Related to this you can't start the translation tool through-out a speciic article anymore. (When using the drop down link near "contributions" you must specify the article you want to translate.) –—2003:E5:1F28:59F6:946F:EBCE:2900:60D3 09:53, 10 May 2021 (UTC)

@XanonymusX - Thanks for the feedback. Could you give some more info on what you're seeing on the on-hover behavior? I'm currently seeing the tooltips as before when hovering: "This is a featured article. Click here for more information". In terms of the links for adding Wikidata items and other language versions - these will be available again later on within a new version of the Universal Language Selector (the selector that appears once you click the button) that the Language team is currently working on. OVasileva (WMF) (talk) 14:03, 10 May 2021 (UTC)

IMO, it's en.m with the bottom headers re-added and a hamburger menu that doesn't actually save much space. And just like en.m, the Categories bar is still missing. If I wanted en.m, I'd use en.m. --Dogcow (talk) 22:45, 10 May 2021 (UTC)

@OVasileva (WMF): Sure! I just did the direct comparison. In the language menu of Vector Legacy, every li.interlanguage-link.badge-goodarticle has lesenswerter Artikel (good article) added as its title, which then appears as tooltip when hovering over the marker containing the badge. In the new Vector, the title attribute contains the name of the language instead (which is unnecessary, since the language link has its own title attribute with language and article name), so there is no way to find out what the star/badge is supposed to mean on hover. The title attribute should be used the same way as in the old language menu.--XanonymusX (talk) 12:22, 11 May 2021 (UTC)

The new language selector ignores my preferences

The new language selector ignores my language preferences, instead of showing the language versions I prefer first I need to search for them. The language selector also gives me quick access to my language preferences which makes it even odder that it ignores them. I can imagine this is a known issue but I had to revert to old Vector which is sad as your improvements are great. Abbe98 (talk) 11:52, 9 May 2021 (UTC)

@Abbe98 - thank you for the feedback and apologies for this issue. We are aware of the bug and are currently tracking this in phabricator (Suggested language list not available for ULS version in new language button). We hope to have a fix ready this week or next week. OVasileva (WMF) (talk) 14:05, 10 May 2021 (UTC)

Thank you! I subscribed to the ticket so that I can turn this on once it has been deployed. Abbe98 (talk) 15:09, 10 May 2021 (UTC)

Minor optimisation on readability

Some friends and I thought Vector has become too white that reduces readability, so I did some minor CSS tweaks just for experiments.

• Bright grey background colour for the outer space
• Slightly larger font size
• Borderlines and box shadows for the body and sidebar

The values are largely influenced by Skin:Timeless since the author (Isarra et al.) did make an effort on readability.

My CSS files (on English & Chinese Wikipedias) also fix some minor bugs regarding to undefined More button (not available for some people), the language menu at the bottom of the main page, and the colour of search bar.

They are simply my experiments for my personal taste so they may not satisfy every one. Feel free to comment or try it yourself by adding the following to your custom Vector CSS file:

@import url(https://en.wikipedia.org/w/load.php?lang=en&modules=user.styles&only=styles&skin=vector&user=Meow);

 🐱💬 03:59, 19 May 2021 (UTC)

Thanks @Meow! Just for clarification, you have you modified the version after our changes (the "modern" Vector), haven't you? Also @AHollender (WMF), you may find that interesting. SGrabarczuk (WMF) (talk) 20:15, 1 July 2021 (UTC)

Sure it’s based on the modern Vector skin, not the legacy one. 🐱💬 02:46, 2 July 2021 (UTC)

Die Monitorbreite

… sollte bitte weiterhin ausgenutzt werden. Die Inhalte zusammenquetschen entspricht möglicherweise den Wünschen der nur-Schmiertelefon-Nutzern, doch für alle, die einen echten Rechner benutzen, ist ein zusammengequetschtes Layout mit weißen Streifen rechts und links nicht nur nervig, es behindert auch das Einbinden von Bildern.

In diesem Zusammenhang wäre auch eine globale und geräteübergreifende Abschaltmöglichkeit der Mobilansicht wünschenswert. Schmiertelefone lassen sich im Querformat benutzen und bei Tablets ist die Mobilansicht ebenfalls verzichtbar. –Falk2 (talk) 16:14, 25 May 2021 (UTC)

Danke @Falk2. Hast du unsere FAQ gelesen? Auf dieser Seite erklären wir diese Änderung. Außerdem wissen wir, dass diejenigen, die große Monitore haben, andere Lösungen bevorzugen. (Thank you. Have you read our FAQ? On that page, we are explaining this change. Also, we know that those who have large monitors prefer different solutions.) SGrabarczuk (WMF) (talk) 20:03, 1 July 2021 (UTC)

Language Selector misunderstandable

Hello everyone,

I'd like to raise an issue on the language Selector: As it's presented now, it might let you think: "Well I'm going to see THIS TEXT in another language!" aka reading in mother-tongue. We all know, this is not the case. Even worse, the pages and content can differ significantly. This is not only true for project pages, but also for content pages. As an example see wikidata:Q788553.

I think this is a big problem, because the Wikimedia-Projects do not work like that. I do see the idea behind placing the option more prominently. But I think that the underlying mechanism should be "really" clear! The Problem probably is: keeping the "Option" short ("languages") collides with a more identifiable explanation. Maybe the best Option is a short explanation when opening the language selector? Something like: "Visit the same page of another language project"? idk...

Best regards --HirnSpuk (talk) 16:03, 26 May 2021 (UTC)

Thanks @HirnSpuk, that's an interesting perspective. Actually, this is worth discussing across the Wikimedia Foundation teams. Our team is only moving the language link list to the new button, while the Language team is working on improving the language list itself. SGrabarczuk (WMF) (talk) 19:59, 1 July 2021 (UTC)

Hey @HirnSpuk, can you clarify why you think that the new location of the language switcher would lead to this assumption? I can understand the general concern that people might not understand what's happening when they switch languages, but I'm not sure I understand why moving the language switcher would affect that. AHollender (WMF) (talk) 22:22, 29 August 2022 (UTC)

@AHollender (WMF), sure: people are used to multilanguage webpages (or at least I think they are, because, I am), where a button like this, usually located at the same spot (somewhat top right corner), usually meaning: there is a version in another language with a content-Team at least aware of the different languages and cross checking. So far so good, same here: there is a version in another language, but: the "content-Team" here is entirely different between languages. And there is no "source" language. Here it's merely switching between the different language-projects. This is probably not that big of a deal for users that are familiar with the wikimedia-structure, but some users, like say my mom and dad, would probably assume, that the content between languages is (at least somewhat) similar. There are examples with quite some difficulties in this regard. Like above said as an example compare e. g. d:Talk:Q788553; another Example is w:Eponym (comparing the german and english article-version).

One can easily try this by oneself: Click on random article, see if there's a language available you understand, and check the other page.

I did this just five times to find: w:drive theory which differs significantly between english and german. The first three random articles didn't have a german version (some english institutions), and the fourth were close enough (some sport event). I can give you another example: w:List of Star Trek games which doesn't even list the two german w:de:Star-Trek-Spiele and w:de:Liste der Star-Trek-Videospiele. Another fun example, I just found: w:de:Liste der Staatsoberhäupter 79 v. Chr. switches to w:List of state leaders in the 1st century BC, but you can't switch back (sure, because of the redirect, but readers will probably not understand, what's happening here).

The whole functionality does not seem to work so consistently as it should for being so prominently placed for readers.

Additionally the new language switcher is placed so close to the actual content, that it seems pretty likely it switches "just the language of the text". Which it doesn't, it switches the project to another language, hence changing sometimes the whole meaning and/or intention of the article, or the book if I'm thinking about wikibooks. Sometimes even different rules apply.

In the old version "in other languages" and "in other projects" were placed close together, not resembling the function of other webpages (not saying it was clear, what will happen, until really understood).

As a side note, fun fact, if there are no other languages the button says: "Add language", if I click it, nothing happens. The Option in the side menu doesn't seem to show consistently (had examples where it showed and some where it didn't).

Hope these explantations and examples help. Regards HirnSpuk (talk) 16:27, 31 August 2022 (UTC)

Hey @HirnSpuk, thank you for taking the time to further explain your thoughts.

Regarding: "the new language switcher is placed so close to the actual content, that it seems pretty likely it switches "just the language of the text"." — this is an interesting assumption. I think we could test: do people have a different understanding of what language switching does if the language switcher is placed in the article header, versus having a list of language links in the main menu? If there is no affect, we don't necessarily have a problem (though maybe some room for improvement still). If there is an affect, then we must consider these conflicting priorities:

• Make language switching as easy as possible (we've already tested this, and know it's easier with the new location)
• Make it clear what language switching does (we have not tested this)

I think that the first priority is more important than the second. So even if moving the language switcher to the article header negatively impacted people's understanding of what it does, it might still be worth it. However we might not have to make this tradeoff. There might be ways to make it very clear what switching languages does, even with the language switcher in the article header. For example we could temporarily show a modal that says "You are now switching to the [German] version of Wikipedia", or something like that.

Side note: we considered placing the new language switcher in the site header (like it is on Wikidata and Commons), but thought it would be more noticeable in the article header. AHollender (WMF) (talk) 18:22, 2 September 2022 (UTC)

@AHollender (WMF), you're welcome. I agree with everything you said. Do you have an idea, how this might be "testable"? Wouldn't this require "active" feedback from a user-group not likely to be reached in a test? I'm concerned about the mixing of "system" and "content" (short: works in wikipedia, doesn't necessarily in other projects like wikibooks), but one will probably get used to the new style. Best regards HirnSpuk (talk) 20:46, 2 September 2022 (UTC)

I can start by running a simple test on usertesting.com. I will show one group Legacy Vector, with the language links in the sidebar, and the other group Vector 2022, with the language links in the article header. And I will ask each participant: what do you think will happen if you click on one of these links?. Then I can ask them to click on a language link, and then afterwards ask: Describe what you are seeing now and what you think happened. AHollender (WMF) (talk) 16:25, 6 September 2022 (UTC)

@HirnSpuk following up here with the results of the simple test I ran on usertesting.com.

• There were 10 participants in each group
  • Group A saw Legacy Vector
  • Group B saw Vector 2022
• Participants were asked to locate the language links, and then asked "what do you think will happen if you click on one of these links?"

Results

• Group A (Legacy Vector)
  • 6 participants used the word "translate" in their response (e.g. "the page will be translated into that language")
  • 1 participant: "it will convert the article into that language"
  • 1 participant: "content will change into language"
  • 1 participant: "it will take you to the language you selected"
  • 1 participant was familiar with the concept of different language versions of Wikipedia, and knew that it would take them to a different article about the same topic, in the chosen language
• Group B (Vector 2022)
  • 3 participants used the word "translate" in their response (though one added, "or maybe the article will be rewritten in that language, not a translation")
  • 4 participants used the term "change" or "switch" in their response (e.g. "the article will change into the language you select")
  • 2 participants were familiar with the concept of different language versions of Wikipedia
  • 1 participant: "I will be able to read the article in that language, but it won’t be the same necessarily"

These results are not conclusive, as the test was limited and quite simple. However they seem to suggest that the position of the language links (in the sidebar, vs. in a menu at the top of the article) might not be a determining factor in how people are understanding language switching. What do you think?

If we wanted to continue to investigate this, I think a better test would be to get participants who are not at all familiar with Wikipedia, and then ask them explicitly: "do you think this will translate the page you are currently viewing, or do you think this will send you to a page in another language about the same topic (but is not necessarily the same exact text)." AHollender (WMF) (talk) 19:23, 14 September 2022 (UTC)

@AHollender (WMF), thanks for letting me know. Your test was limited, yes, but it seems to clearly show, that in any case it's misunderstandable and the notion it "translates" the content seems to be quite prevalent (80% in both cases give or take, let's say +-20%, than it's still more than half in any case). Thinking about the function doesn't do this (can we agree that the degree to which it does is to small?), I see two possibilities

1. explanatory intro with a link to a help page (that could be done in any case) or
2. how about rethinking completely?

For me MediaWiki has a history of organically confusing system and content. That's by design, it's a wiki, but somehow I have the impression Vector22 makes it worse. I think my perception of the language-switcher is just one of the manifestations of this impression.

Examples (sorted in order of bothering me):

1. The TOC is not customizable anymore. Every page that relies on magic words breaks (more or less).
2. The header and the sticky header are different.
3. The heading of the article comes before the "system-links" like "edit".
4. The language-switcher is misunderstandable (as discussed).
5. The language-switcher even links to preferences for "system-language" instead of "just content-language".

Thank you very much for your effort. I didn't expect such a clear outcome. If you want to continue investigation, your plan sounds well. But I would expect the question to be more open, for example something like: "What do you think the language link on <example page> will do? a) translate the content via some automated system; b) show a redacted translation of the text I was reading; c) switch to another project in another language with another text about the topic; d) none of the above, please elaborate..." Don't know is this more open? I'm not sure.

Is there any data on language-link-usage? Like how often language-links are used in comparison to other links on the site? That could be an indicator if further investigation is useful.

Best regards HirnSpuk (talk) 02:12, 16 September 2022 (UTC)

@HirnSpuk thanks for your reply. Here are responses to your points above:

• Regarding: The TOC is not customizable anymore — we've just opened a task for this, https://phabricator.wikimedia.org/T317818
• Regarding: The header and the sticky header are different — this is by design and based on community feedback. The sticky header is a combination of the site header, the article titlebar, and the article toolbar/tab-bar. What we heard from the community is that certain tools, such as Watch, Talk, History, etc. are important to have in the sticky header, as well as items from the site header like Search and Personal tools.
• Regarding: The heading of the article comes before the "system-links" like "edit" — this is by design and based on community feedback. We asked the community about it during our fourth prototype testing (link to questions & prototype, link to responses). We had 33 community members saying they prefer the toolbar below the titlebar, and 5 community members saying they did not, which seemed like a clear enough preference to us. Also, from a logical standpoint, if someone is viewing the topic "Water", we think it makes sense for the information architecture of the page to say "Water" first, then say Article, Talk, History, etc., because from the perspective of someone using the page those are effectively sub-pages of this overall topic: "Water". We understand that from a technical perspective it might be different, and we are okay with that.
• Regarding: The language-switcher is misunderstandable — based on the limited test this doesn't seem to be any worse with Vector 2022.

What do you think about the above responses? Overall, based on the data we've collected and the user research we've done, Vector 2022 seems to be more usable and welcoming/friendly than Legacy Vector. I realize it can be difficult to trust the research and user/community feedback when it contradicts your personal experience, and that change in general can be very difficult : / I do really appreciate you taking the time to continue to give feedback.

Regarding making language switching more clear, I think it's a great idea. I've shared your feedback with the language team. If they decide to make improvements here it seems they would need to make them to both Legacy Vector and Vector 2022, as the issue seems to be the same with both skins. AHollender (WMF) (talk) 13:54, 16 September 2022 (UTC)

@AHollender (WMF), as you asked for a reply I'd be happy to talk further. Thanks for taking my thoughts into account, that feels really welcoming. Regarding your points it's a little difficult, because I can't adress them in the given order. And, if I'm trying to adress them, I will probably loose focus of the "language switcher" topic.

I'll try anyways:

• I know a redesign is always difficult and the voices of "you ****, what have you done..." are always louder than the mass, that's simply "getting used to it".
• I've been a part of the development for a while now (switched to Vector22 really early) and I'm more or less fine with everything, except where it makes my life harder in the wikimedia-universe.
• I know about the community testing from Szymon and I was part of it and gave feedback, but I would have liked a proper presentation of these findings with explanation of the methodology and goals etc. prior to the changes. But on the other hand, I might just have missed the spot, where it's presented.
• I know that most of the change is made with community-feedback. And this is a good thing. You are all doing a wonderful job.

That said, how would I sum up my problems and where is "my life made harder"?

• I'm afraid, without a clear "structure" to the duality of page-system, work for regular editors will get harder (keeping an eye on the difference between content and structure was already pretty hard to handle and to explain!). And future redesigns might become "greater" breaks.
• I'm active in the wikiverse about 6 years now, and I remember clearly which problems I had getting used to the "system" and the historically grown "it's always been this way"... (and I consider myself somehow fluent in modern technology; something totally different, when I think about my parents (>70) or other relatives (visually impaired))
• Help- and community-pages must be rewritten and redesigned (where is the menu, how does it work, what means language-switching, ...). This is especially tedious, because it seems, that there will be more work on the design in the future, so it will probably not be: "it changed, now it's like this", but a regular checking for updates and rewriting. I'm afraid some of the redesign work will probably lead to a "template-workaround" for a self-made-TOC which needs to be kept coherent in the future. Your phab-link doesn't seem to adress my problem, because I would like floating-ability.
• Sometimes even content-Pages could be redesigned. Compare the book b:de:Julius Döpfner und das Zweite Vatikanische Konzil -> old design: TOC directly accessible and there in the printout (not saying it looks nice), new design: TOC hidden under the side-menu and not in the printout.
• To your third point, the logical standpoint: right! For Wikipedia! Probably for wikivoyage and wiktionary, too. Odd at wikibooks and wikiversity. Maybe odd at wikisource? Odd also on community-pages. Compare the above mentioned book again or b:Cognitive_Psychology_and_Cognitive_Neuroscience/Problem_Solving_from_an_Evolutionary_Perspective or look at an example community-page: b:Shelf:Computer_networking

Last: I'm not criticizing the work, I actually think I'll get used to it (though the redesign-issue is really unsettling me). I'm trying to think of it as about six years ago: I might have been more confused. Hope this makes somehow some kind of sense and helps in some way. Best regards HirnSpuk (talk) 16:55, 16 September 2022 (UTC)

Hey @HirnSpuk, thank you very much for your supportive and encouraging words, and for continuing our dialogue. It is certainly helpful. I appreciate the opportunity to discuss the interface and the various decisions that have gone into it.

• I would appreciate some help understanding this point from your latest comment: without a clear "structure" to the duality of page-system, work for regular editors will get harder (keeping an eye on the difference between content and structure was already pretty hard to handle and to explain!) — what do you mean by this? And can you help me connect it back to Vector 2022?
• Regarding: Help- and community-pages must be rewritten...This is especially tedious, because it seems, that there will be more work on the design in the future. I recognize that any changes to the interface create additional work regarding any documentation about the interface. This seems almost like a necessary evil in ways. I would be happy to help updating such documentation pages. I'm not sure if I understand the connection between this and the table of contents, particularly "because I would like floating-ability". Can you help me understand that?
• Regarding: right! For Wikipedia! Probably for wikivoyage and wiktionary, too. Odd at wikibooks and wikiversity. Maybe odd at wikisource?. I think one of the most difficult parts of interface design is that it has to prioritize certain use cases above others. Over time configurability and customizations can be built in, however with each additional configuration you then run into the two problems of (1) maintenance (in terms of the code, QA/testing, documentation, etc. — all of the work multiplies with each additional configuration), and (2) consistency, because now the layout is different here than it is there. We have a particularly large challenge here because we use one interface for so many different projects (and languages), each with their own needs. Hopefully we can find a reasonable balance, where the interface works well for the majority of people using it, and at least works for all of the others. We have chosen to anchor on Wikipedia, as it is the most used project within the movement.

Our conversation has developed a bit beyond the original topic heading ("Language Selector misunderstandable"), which is of course fine (and only natural). I'm just noting that because it might make sense for you to start new, separate discussions with some of these points on the main project talk page (for others to find). Totally up to you.

Cheers, AHollender (WMF) (talk) 21:02, 19 September 2022 (UTC)

Ping @AHollender (WMF), I did move the two points regarding structure and redesign/writing there. Feel free to restructure and comment to your linking. Regarding your third point: Yes! To everything you said! Best regards HirnSpuk (talk) 18:15, 21 September 2022 (UTC)

Content display width

Hello! I just tried this new skin a few minutes ago. I am wondering about one thing. Please compare Preferences and an article. Doesn't the vector-menu-content-list look wrong? In Preferences, the content is protruding to the left of the tabs. This problem occurs in jawikivoyage, dewikivoyage, frwikipedia... but not in enwikivoyage. --Tmv (talk) 09:32, 2 June 2021 (UTC)

Hello @Tmv, apologies for the late reply. Could you write more about the thing looking wrong? I didn't understand what you mean by the "vector-menu-content-list". SGrabarczuk (WMF) (talk) 17:39, 19 July 2021 (UTC)

@SGrabarczuk (WMF) The problem is happening on the special page. Using Preferences page as an example, a tab above the title "Preferences" is in the wrong place (in using English). The tab is where it says "Special page". Tmv (talk) 09:34, 20 July 2021 (UTC)

@Tmv, do you mean you are confused because the Preferences page is wider than article pages? This is because of the setting of the limited width. On special pages, history pages, etc., the width is different because these pages have different type of content. But indeed, on English Wikivoyage, the Preferences page has a width of an article page. I'll investigate that. SGrabarczuk (WMF) (talk) 16:01, 20 July 2021 (UTC)

Idea: “persist_skin” URL parameter to retain skin preference in browser cookie, inspired by YouTube

I would like to share an idea from YouTube's website, which has both a desktop and a mobile front end. For temporarily recalling either version, one uses the app= URL parameter, with app=desktop or app=m respectively. But that is just for one page load.

But YouTube also has allows retaining the skin preference in a browser cookie using the persist_app=1 URL parameter; persist_app=true also works. As a side note, YouTube also stores the light/dark theme preference in a browser cookie.

Until 2020, there was also a disable_polymer= URL parameter, where one could recall the pre-2017 YouTube theme, which is HTML-based instead of AJAX-based, which was, as far as I can remember, retained in the URL to keep using the non-polymer version. I am generally against AJAX-loaded pages, as it demolishes accessibility and increases loading times for the sake of looking more like a mobile app.

Sure, one could just create an account for choosing a preferred skin, but many MediaWiki-based wikis on the Internet are read-only, lacking the support for account creation. Also, when accessing from a public computer, logging in for this purpose is inconvenient.

Furthermore, the ability to retain the desktop or mobile front end setting without login already exists, so it should also exist for skins themselves.

As soon as the new Vector skin becomes default, I suggest renaming its legacy version to "vector2010", "vector10", or similar, so that those who prefer it can keep using it by appending ?useskin=vector2010&persist_skin=1, which applies the skin preference to a browser cookie. One could also use monobook with ?useskin=monobook&persist_skin=1.

I hope this improvement will be considered.

There's an option to add ?useskinversion=1 or ?useskinversion=2 already. The first forces the Legacy Vector and may be useful on wikis with the modern as default, the latter works inversely. But those only work for each individual loading of a page. In order to have the same non-standard skin loaded each time, one needs to be logged-in and set their preferences. SGrabarczuk (WMF) (talk) 20:44, 1 July 2021 (UTC)

Article tools prototype

I came across this prototype, and just wanted to say that I like it quite a bit! Collapsing the tools is needed to make the sidebar more accessible, and the more menu is a great place to put it. I'm not sure how eager the rest of the community will be about it, though; see w:Wikipedia:Requests for comment/2020 left sidebar update#Autocollapsing for an important precedent. Sdkb (talk) 17:05, 12 June 2021 (UTC)

Hey, thanks for your opinion and the link to the RfC! Our plan is to integrate article tools and put these aside from site-wide tools. Now, some article tools are on top (such as Move) some are in the sidebar (Wikidata item) where site-wide tools are as well (Recent changes, etc.) We will be working on this later this year. Just as usual, we'll measure the communities' reception. After each deployment, we run an A/B test on all early adopter wikis and check if the change is actually an improvement. SGrabarczuk (WMF) (talk) 19:35, 1 July 2021 (UTC)

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)

A year ago, I was dissatisfied with how narrow and overly compressed content looks with the current max-width on 1920x1080 display. Well, now I have a 2560x1600 display and it looks even worse to me, as only one third of my screen is filled with useful content. It feels like I'm using a mobile version of the website on mz laptop and it doesn't help that I don't really like a sidebar and would prefer it hidden, so that nothing distracts me from the article. I would really love to have several max-width options to choose from (e.g., leave as is, fill the entire workspace container or even fill the entire page container). Too bad it's still only possible with user scripts and styles... At the moment, it is also a single most important reason for me to stick to the old vector theme. 2-column layout, as suggested above, also might be a viable approach, though it might break a lot of stuff. Adamant.pwn (talk) 16:32, 4 December 2021 (UTC)

Is the new fixed width made for people too stupid, or too lazy, to resize their window? 2A01:CB15:338:E200:FB14:192D:A0F3:C30C 22:41, 8 December 2021 (UTC)

My thoughts exactly. (And wait till you see what they are now messing with…) Of course, if one uses Monobook instead of Vector all this silliness goes away, but having “power users” experiencing the site in a way that is more and more distant from that of an entry-level or unlogged user is not a good trend. Besides the fear that one day suddenly they will pull the plug on Monobook fills my daily Wikipedia editing experience with dread and bitterness.

I feel transported to the bad old days of the early 1990s when really bad ideas about user interface (anyone remembers those multimedia CDs?) florished and wilted, to eventually give way to clean functional designs such as early Wikipedia. To rehash all that nonsese again is even worse, as the accumulated experience is not being taken into account and every interface designer wants to do it from scratch and reinvent the wheel (like seemingly every .swf designer did in the 2000s…), compounded by the fact that, unlike back then, in the 2020s user interfaces on a screen are not exactly newfangled — yet bad ideas and attempts at bogus “paradigm shift” keep plagueing us.

One imagines that something like Wikimedia would be exempt from the constant changes that affect major commercial websites, but that what we get when we voluntarily put our necks on the stump and give away the keys of the realm to higher-ups who post more tweets and instas in a day than Wikimedia site edits in a month (not hyperbole here, and you all know it), No wonder said luminaries, accostumed to social media and mobile UIs, will be shocked to see a functional design meant for comfortable encyclopedia reading and editing: «Ew, is that “my” website?!, let’s change everything about it!» And here we are.

Tuvalkin (talk) 23:00, 21 December 2021 (UTC)

I strongly dislike the fixed width for same reasons as stated above. The new UI does seem to make using Wikipedia only harder and frustrating experience. Authors of this change seem to be bit of out of touch what most existing contributors preference. --4shadoww (talk) 17:24, 10 December 2021 (UTC)

I often use widescreen monitors. Would it be possible to select only the new width and not the other new design stuff? Jiiimbooh (talk) 21:40, 22 December 2021 (UTC)

I can understand that there is value in consistent width in terms of article presentation, however there's significant wasted screen space that's a deal breaker for me. Why is this not just an optional toggle, I'm even okay with fixed width being the default, so long as I have the ability to expand it. Supertrinko (talk) 01:05, 25 January 2022 (UTC)

I agree on the new width. The desktop page seems to provide a much better reading experience now. Thanks! -- Kaartic ^[talk] 08:35, 26 January 2022 (UTC)

Impact of Language switching on the "Download as PDF"

Tracked in Phabricator
Task T282304

Hi, on French Wikipedia someone notice that the Language switching has a negative impact when you download an article with a lot of language versions (for exemple, try with Grenoble): PDF begins with the list of languages (2 pages for my exemple), but those pages are not desired by the user.--Patafisik (WMF) (talk) 15:54, 24 June 2021 (UTC)

Salut Patafisik, it will probably be fixed this week. --Thibaut120094 (talk) 16:34, 24 June 2021 (UTC)

Thank you!--Patafisik (WMF) (talk) 17:19, 24 June 2021 (UTC)

Bug : absence de basculement des liens interlangues

Bonjour,

Bug déjà signalé sur WP-fr, mais je le signale ici.

Problème : les liens interlangues s'affichent toujours à leur ancien emplacement (menu latéral gauche), le nouveau bouton n'apparaît pas.

Circonstances :

• Comptes enregistrés sur lequel le bug est reproduit : Jules* (Firefox) et Bot de pluie (Google Chrome) ;
• Comptes avec la nouvelle version de Vector activée (case des préférences pour revenir à l'ancienne version désactivée) ;
• Cache purgé ;
• Bug persiste sur le compte Jules* avec les pages .css et .js vides (0 script) ;
• Bug persiste sur le compte Bot de pluie avec les pages .css et .js vides (0 script) et tous les gadgets désactivés dans les préférences ;
• Sous IP (Firefox et Chrome), RAS, pas de bug.

Cdlt, Jules* (talk) 10:02, 25 June 2021 (UTC)

Bonjour, même problème pour moi, les liens apparaissent au nouvel emplacement sous IP (Firefox et Edge). nouvelle version de Vector activée, Cache purgé. Pas testé de désactiver les gadgets et vider les pages .css et .js. Bon courage. - AvatarFR (talk) 11:11, 25 June 2021 (UTC)

C'est mon cas : interlangues à l'emplacement habituel quand je suis connecté, au nouvel emplacement quand déconnecté. Je n'ai pas de CSS ou JS personnalisé. Jean-Christophe BENOIST (discuter) 25 juin 2021 à 13:39 (CEST)

en béta : Nouveau lecteur vidéo, Différences visuelles, Outils de discussion, Traduction de contenu. En gadget : ArchiveLinks, LastContrib, Réduction d'URL, EditZeroth, OngletPurge, PublierBrouillon, ResumeDeluxe, WikiEd, ProveIt, MonobookToolbarStandard , ContribsRange, WatchlistNotice, RevertDiff, Wdsearch, OptimizedShort, CarRename. Jean-Christophe BENOIST (discuter) 25 juin 2021 à 13:54 (CEST) (original message on fr.wiki --Patafisik (WMF) (talk) 12:11, 25 June 2021 (UTC))

link to other languages

Hi, the french wikipedia is experimenting the improvement for languages: the links to other languages are now hidden behind a button (in the main page the button is at the bottom-> very hard to see). It s annoying , my feedback: better before. Anonymous — Preceding unsigned comment added by 145.242.20.121 (talk • contribs) , 25 June 2021

Impact of Language switching on the Main page (fr.wikipedia)

Tracked in Phabricator
Task T276140

Tracked in Phabricator
Task T293470

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 [1]--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 @Eskaps and JllllllV: , 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)

@Patafisik: , 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)

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

Language switching : Geographic coordinates under the line of the title of an article

Tracked in Phabricator
Task T282027

(original message on fr.wiki by @Daehan: ) e.g. in the article Musée de Rimini: with the new Language switching button, the geographic coordinates are under the line of the title of the article. Between the line and the beginnig of the article there is now a lot of space.--Patafisik (WMF) (talk) 10:24, 26 June 2021 (UTC)

Nouveau menu des langue sur Wikipédia/Wikitionnaire français

Bonjour, le nouveau menu pour choisir la langue est pratique et permet de se rapprocher de l'application smartphone. En revanche il y a un point embêtant, c'est que l'ancien menu a disparu partout, même sur la page d'accueil où il n'y a pas ce nouveau menu. Hors je me servais souvent de ce menu pour aller sur une autre version de Wikipédia/Wikitionnaire, à partir de la page d'accueil. Ainsi j'avais juste à cliquer sur mon favoris pour Wikipédia Français, et ensuite cliquer sur la langue. Là je suis soit obligé de chercher la langue sur Google, soit d'aller sur l'article français (s'il existe), puis sur la langue.

Si vous pouviez le remettre sur la page d'accueil, ça serait super :)

Merci d'avance. — Preceding unsigned comment added by 28 juin 2021 à 07:35‎ Quarante-quatre (talk • contribs)

Bonjour @Quarante-quatre: merci pour ce retour constructif. La remarque sur la page d'accueil de fr.wiki a été faite par plusieurs utilisateurs et je l'ai signalé ci-dessus, les langues se trouvent actuellement tout au fond de la page d'accueil sur la droite. Cordialement,--Patafisik (WMF) (talk) 09:04, 28 June 2021 (UTC)

Language switching (Desktop Improvements): mouse hover pop-up ?

(original on fr.wiki) Actually, you need to click on the button of language to see others versions of an article. Some users don't understand what is the funcion of the button. In this case, the suggestion of @Warp3: could be useful: to have a pop-up when the pointer moves on the button with written "see this article in others languages".--Patafisik (WMF) (talk) 08:17, 29 June 2021 (UTC)

Bonjour. En plus de ma suggestion, je trouve qu'il serait bien d'ajouter le code de la langue avec chaque nom de langue affiché (par exemple : recherche de “Code pays” donnerait entre autres : → Ländercode - allemand - de ).

English:

Hello. In addition to my suggestion, I think it would be nice to add the “language code” with each language item (eg: search for "Country code" would give among others : → Ländercode - German - de ).

--Warp3 (talk) 05:29, 1 July 2021 (UTC).

Language switching (Desktop Improvements): search field of language

Tracked in Phabricator
Task T286419

(original messagge on fr.wiki) Hi, when you search "fr" in the Language switching search field of fr.wiki, some articles (but not all) who exist in fr.wiki shows "This article doesn't exist in the language you are searching for" (Cette page n'est pas disponible dans la langue que vous recherchez). It is a search of the article we are reading. Instead, it should be displayed something like "You are already reading this article in this language."

• 
• 
• 

--Patafisik (WMF) (talk) 10:12, 29 June 2021 (UTC)

Thanks for flagging this. I was to create a task on Phabricator, but I think this might actually be up to the Language team as part of their improved Universal Language Selector. SGrabarczuk (WMF) (talk) 19:17, 1 July 2021 (UTC)

New discussion here.--Patafisik (WMF) (talk) 11:03, 11 July 2021 (UTC)

Opt-out of new design for logged-out users?

Why is the option to opt-out of the new design not made available to logged-out users?

I am a frequent reader of Wikipedia in its many languages, and I am almost always logged out due to proxy and security reasons. After being frustrated for many months at the amount that I had to scroll when looking through articles in the French and Korean wikis (due to the max-width change), and now recently having had the language links seemingly disappear in these wikis, I finally decided to look up what was going on, and I've just found out yesterday that the deployment of these desktop improvements was the cause. I've now logged in for the sole purpose of being able to opt-out of these changes (and secondarily to ask this question here).

As a related question, how are the perspectives of logged-out users (which, I presume, are the vast majority of readers of Wikipedia) taken into account when rolling out these features? I sometimes encounter a survey-type question that asks whether a page loaded quickly enough for me, which I can answer in a few seconds. Could a similar feature be used to collect quick, large-scale feedback from all users, including those not logged-in, on the new layout changes (for example, a prompt which asks "Is this page too long/wide/narrow?", which could perhaps be followed up by an option to switch layouts and give feedback on the other layout if the user answers yes)?

--Protocactus (talk) 22:42, 30 June 2021 (UTC)

I agree with this request. Regards, --Warp3 (talk) 05:40, 1 July 2021 (UTC).

Hello @Protocactus. Both of your questions are related to our technical limitations. We are not able to offer our readers (logged-out users) the opportunity to change the layout. This is because of the limited capability of our servers. We know these functionalities would be useful, though. SGrabarczuk (WMF) (talk) 18:28, 1 July 2021 (UTC)

Certain things can be done with browser extensions if you care for them, with no or negligible impact on server resources. For example, content can be made wider with a simple extension (I don’t have accounts on Mozilla Add-Ons, Chrome Web Store or the like, so you need to build it yourself, or get someone who publishes it); it would be even better if the content action tabs were on the far right, not the same place as in the width-constrained version, and if it was actually full width, not just 1256px instead of 960px (both of these fixes should happen in Vector code to ensure it doesn’t break suddenly with other changes). Others, like the position of the language list, are not that easy to do in an extension, and even if done, almost certainly lead to flash of unstyled content. —Tacsipacsi (talk) 23:08, 1 July 2021 (UTC)

Laguage switching not available in editing mode

Tracked in Phabricator
Task T285973

(original messages here, here and here)

Desktop Improvement for editors: on French Wikipedia, when you are in editing mode (logged-in or logged-out), the button of laguage switching doesn't appear. Editors ask for languages switching availables when they edit.--Patafisik (WMF) (talk) 16:00, 1 July 2021 (UTC)

Language switching no longer available on wikidata and mediawiki

Tracked in Phabricator
Task T286574

On wikidata, it was possible to change the language by clicking on the left of the displayed language. This is no longer possible: this just adds a "#" to the URL. One now needs to change the language in the preferences, which takes more time. I don't understand why such a useful feature has been removed. And the mediawiki pages seem to be affected too. — Vincent Lefèvre (talk) 23:50, 2 July 2021 (UTC)

@Vincent Lefèvre: The language selector in the top right toolbar (next to my user name) works for me on this very page (with both the new and the old version of the Vector skin). If you have any JavaScript error messages, they’ll certainly help developers investigate the issue. —Tacsipacsi (talk) 01:46, 4 July 2021 (UTC)

@Tacsipacsi: It is on the left of my user name, but it does nothing except adding a "#" to the URL. This does not trigger any JavaScript error. — Vincent Lefèvre (talk) 11:16, 4 July 2021 (UTC)

@Vincent Lefèvre: Sorry for the late reply. Please also see point 5 on the linked page—without knowing what you use, it’s nearly impossible to reproduce the issue, and without reproducing or having error messages, it’s nearly impossible to fix it. —Tacsipacsi (talk) 12:56, 11 July 2021 (UTC)

@Tacsipacsi: Skin: Vector (this is the default). Browser: Firefox 88.0.1 under Linux (Debian/unstable). I've also tested with a new profile: still the same issue, and still no errors in the console. — Vincent Lefèvre (talk) 00:04, 12 July 2021 (UTC)

And same issue with Opera 77.0.4054.203 on the same machine. — Vincent Lefèvre (talk) 00:08, 12 July 2021 (UTC)

I think this is a bug, but please check "Use a compact language list, with languages relevant to you." on Special:Preferences#mw-prefsection-rendering to restore it in the mean time. Jdlrobson (talk) 03:43, 12 July 2021 (UTC)

@Jdlrobson: I've just seen that this has now apparently been fixed. — Vincent Lefèvre (talk) 15:35, 24 July 2021 (UTC)

Language switching button on French Wikipedia : text bold vs. normal and text black vs. blue

(original message on fr.wiki by @LPLT: , published here by --Patafisik (WMF) (talk) 09:52, 4 July 2021 (UTC))

Pour ce qui est de la charte graphique, deux éléments à mon avis ne sont pas optimaux : 1/ l'usage du gras pour l'affichage (le gras est déconseillé sur WP) 2/ la police en noir, alors qu'instinctivement et pratiquement, tous les liens hypertexte sont en bleu. L'appel en noir est contre productif visuellement pour le clicage. LPLT [discu] 3 juillet 2021 à 20:21 (CEST)

New Vector theme does not span entire border

This is what I see

--Tyw7 (🗣️ Talk) — If (reply) then (ping me on en Wikipedia) 00:34, 6 July 2021 (UTC)

Impact of Language switching on fr.wiki : badges are no longer shown next to interwiki links

Tracked in Phabricator
Task T286612

(original message on fr.wiki)

• 
  1. Anonymous or not connected users (New Vector)
• 
  2. Connected users - part of the A/B test groupe without the new feature available (Vector Legacy)
• 
  3. Connected users (New Vector)

Hi, star icons for good/featured articles are not shown next to interwiki links for connected users on fr.wiki (and there is no hover message to advise on articles or good/featured ones). Is there any possibility to fix it? Thanks.--Patafisik (WMF) (talk) 09:09, 11 July 2021 (UTC)

@Patafisik (WMF): It doesn’t depend on whether the user is logged in, but on whether the language switcher uses JavaScript. Normally it should for both logged-in and logged-out users, but it could fail for various reasons (JS explicitly disabled in the browser, too old browser, conflicting other gadgets or user scripts etc.). If it fails, the one-column list shown on the third screenshot appears.

Even though this one-column list technically also contains the badges, they’re cut off. However, since everything is there in the HTML source code, they can be restored with a simple CSS snippet (it should ideally go to Vector’s source code, but as a hotfix, you can put it in a user stylesheet (e.g. fr:Special:MyPage/vector.css) or in a sitewide stylesheet (e.g. fr:MediaWiki:Vector.css) or gadget):

#p-lang-btn ul {
	margin-left: 1.6em;
}

(Please note that when put in user or sitewide stylesheets/gadgets, this may not work in right-to-left languages like Hebrew. When put in the Vector source code, however, it should automatically be rewritten appropriately to accommodate to RTL.) —Tacsipacsi (talk) 12:50, 11 July 2021 (UTC)

Also, I didn’t test this much, so there may be edge cases where this doesn’t work, or kicks in even though it shouldn’t. —Tacsipacsi (talk) 12:53, 11 July 2021 (UTC)

@Tacsipacsi: Thanks for explanations. @HB: j'espère que cela te permettra de résoudre le problème, s'il te faut une traduction du message je peux la faire, notifie-moi dans ce cas. :)--Patafisik (WMF) (talk) 13:08, 11 July 2021 (UTC)

4. Logged-in, with Vector.css

Compact language links preference

@HB: Usefull information to all: I've tried to find the gadget or beta feature responsable of the problem but I've not found it. No scripts, JS available in the browser, last version of all browsers. So I'm using the suggested vector.css, this is the result (screenshot n. 4). It's fine for the badges. But the list is still different from the list of screenshot n. 1 (2 columns, suggested languages, "Paramètres d’affichage" and "Paramètres de saisie" in the box of the button, etc.). To fix it: Allez dans Préférences → Apparence et descendez dans la page jusqu'à la section Langues. Vous trouverez une case à cocher, avec le texte « Utiliser une liste compacte de langues, avec seules celles qui vous conviennent. ». (voir Liens de langues compacts)

Best regards, --Patafisik (talk) 14:32, 11 July 2021 (UTC) Modified --Patafisik (talk) 14:58, 11 July 2021 (UTC)

Still testing the feature, I've discovered that with the Compact Language Links activated the vector.css is not necessary, badges are presents.--Patafisik (talk) 15:07, 11 July 2021 (UTC)

I didn’t know about this side effect of turning off compact language links (I’d consider it a bug, by the way, since at the new location, the list is neither longer nor shorter with either option). However, my point about the JavaScript-less experience still stands: users without JS get the one-column version even if they have compact language links enabled. —Tacsipacsi (talk) 16:02, 11 July 2021 (UTC)

Thanks for all the informations!--Patafisik (WMF) (talk) 08:06, 12 July 2021 (UTC)

"However, my point about the JavaScript-less experience still stands: users without JS get the one-column version" - this is a very small subset of our users. Right now our main focus in the majority of users who do have JS enabled.

This style could be shipped in a common CSS or site CSS for those users to rectify that in the interim:

.client-nojs #p-lang-btn ul    { column-count: 3; } Jdlrobson (talk) 16:34, 13 July 2021 (UTC)

@Jdlrobson: The question here is not whether users without JS see one or three columns, but whether they see the badges for featured articles/good articles/etc., or don’t see them. Compatibility#Basic (Grade C) promises that in Grade C browsers (the most notable browsers without JS) content is presented in a readable manner. Badges cut off breaks this promise, since quality assessment is an important part of the content, and something that’s not visible isn’t readable either. And it takes literally three lines of CSS to fix it. —Tacsipacsi (talk) 18:35, 13 July 2021 (UTC)

I did a bit of digging and the badges are provided by the WikimediaBadges extension which is making some assumptions that are no longer true in modern Vector.

I've created T286612 and added a temporary workaround (feel free to revise/remove): https://fr.wikipedia.org/w/index.php?title=MediaWiki%3AVector.css&type=revision&diff=184622499&oldid=183232069 Jdlrobson (talk) 20:48, 13 July 2021 (UTC)

Language switching (Desktop Improvements): not available (gadget conflict ?)

Tracked in Phabricator
Task T286459

Though my fr.Wikipedia account is with standard vector, I do NOT benefit the new language menu in this fr.WP. Instead, I still have a (reduced) list of languages in the left column. I remind having, some years ago, "installed"… a, I guess: gadget (what else ; I have a slightly modified "Common.js", but not related to languages), so, gadget which permits to show only a tenth of languages, among which the ones I switch to the most (in my case : english, esperanto and picard are most frequently present there if the article is available). On the contrary, when in eo.Wikipedia, which did install the language menu, I do have it ; and by the way, I did very little if not none, specific customisations in my eo.WP preferences. Question : do you have a suggestion how I could track the "faulty gadget" ? (I use a bunch of these, and am not very happy about testing each one individually) Thanks in advance. -- Eric.LEWIN (talk) 12:49, 12 July 2021 (UTC)

@Eric.LEWIN: The position of the language links doesn’t depend on any gadgets or other preferences. There’s currently an A/B test, so it’s decided at random whether you get the language links in the header, and apparently this random setting varies by wiki. You can force the new version on individual pages by appending ?languageinheader=1 to the article title (e.g. https://fr.wikipedia.org/wiki/Test_A/B?languageinheader=1), but that’s just for testing as manually appending it to all URLs is quite inconvenient. The only thing you can do is waiting until it becomes the default (or at least a preference; I don’t know whether making it a preference is planned). By the way, this reduced language list you mention is Compact Language Links, but it has nothing to do with whether you get the language links in the header (except for turning it off breaks the links if you get them in the header, see the previous section). —Tacsipacsi (talk) 21:59, 12 July 2021 (UTC)

Many thanks, @Tacsipacsi: , for your clear explanations. I saw the expression "Test A/B", but did not know, and catch, its meaning, and in fact did not bother :-(. Effectively, your forcing recipe did work well. I'll let the test going on, hoping for a quick setting, whatever the choice, default or preference. And thanks for the ULS/CLL reminding. Minden köszönetemmel és üdvözletemmel a Francia Alpoktól (Google Translator). Best regards, cordialement. -- Eric.LEWIN (talk) 23:33, 12 July 2021 (UTC)

Hello @Eric.LEWIN. After the deployment of almost each feature, we run the A/B test. Tacsipacsi is correct. This does vary by wiki, and depends on your user ID (all who have even numbers can see one version, and those with odd numbers can see the other version). Usually, the A/B tests take two weeks. However, we may set up these again if something goes wrong. For instance, one time, we learned that the test wasn't set up precisely enough, and we didn't receive answers for questions we wanted to ask. Anyway, I expect the results to show up this week. SGrabarczuk (WMF) (talk) 16:59, 19 July 2021 (UTC)

Thanks for these infos. I was mainly offline since the 14th ; when I connected back this morning, it appears to me that I was now benefiting the language menu, whatever the reason or cause. And I still have taken advantage of it. Really a great feature, a major improvement from my point of view. I keep being attentive to it, and eventually I'll report in case I meet an ISA ("Incident, Surprise or Anomaly"). Best regards. -- Eric.LEWIN (talk) 18:28, 20 July 2021 (UTC)

Please move it up, again

I just would like to say that I like the new language selector, but I disapprove of it being placed at the bottom of the main page of a wiki. I am used to switching between language versions and I am sorry to say this, but it is a nuisance when you have to scroll to the very bottom of the main page in order to find the selector. You wonder, is there any selector at all? So, could you please move it up again to the top of the main page? Thanks! Aschmidt (talk) 19:48, 28 July 2021 (UTC)

Concrete suggestions for improvement

Hi, a year ago I submitted a critique and mockup for improvements. You could not fully take them into account because the links for some of the image files had expired. Because most of them are still relevant, I have uploaded them to Commons.

M!dgard (talk) 11:27, 22 July 2021 (UTC)

Thank you @M!dgard for the screenshots. I appreciate the effort. We take your opinion into account.

You are right about some elements, and these will be fixed. When will we do that, and why these imperfections exist? It's because our changes are gradual, and we'll be fixing these gradually.

1. The lack of alignment between the content and the user menu will be not relevant when we deploy the user menu.
2. The symetry of article tabs will be not relevant when we deploy the sticky header.
3. The selection and sequence of links in the sidebar are, for the most part, decided by the local communities. The Tools section will be put to the header as part of the article tools improvement.
4. The grey area on both sides of the screen will be a subject of discussion closer to the general aesthetic refinements phase (see the related Phabricator account).

I'm not able to answer to some of your points yet, sorry! Some are strictly related to the design and technical limitations (e.g. the "return" button by the sidebar, or the "page weight".) I'll discuss this with other members of our team. SGrabarczuk (WMF) (talk) 17:35, 27 July 2021 (UTC)

Purging issue: swapping old and new look without switching

Sometimes when I go to any page, like a page using a non-main namespace, I saw an old look. However, I refreshed the page by clicking the refresh icon and pressing Ctrl + F5 keys, so the page automatically switches back to the newer look. Is there a purging issue or something like that? George Ho (talk) 23:04, 25 July 2021 (UTC)

Hi George, this is usually a sign that the page hasn't been visited recently and that a new feature was recently rolled out (usually within the 1 week). It's a known issue that corrects itself as you've pointed out, but we accept it as it reduces a lot of risk to our operations team who keep the site running. Jdlrobson (talk) 02:43, 11 August 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 w: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 w: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)

@Narky Blert: 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)

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

@Narky Blert: You have to turn on Use Legacy Vector (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)

@Jdlrobson: 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.

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)

New vector language switching selector : title icons are no longer on the title line

Tracked in Phabricator
Task T282027

Hello. On french wikipédia, icons created using the template {{Icône de titre}} are no longer on the same line than the title but inside the page, and they occupy a full line. It is the case for example for the page protection indicator (example on article fr:Jules Verne). It is also the case for the numerous title icons used on user pages, where the rendering is no more what the user expected, although there is no language selector on user pages.

• At least on user pages, or more generally on pages without language selector, title icons should always stay on the title line
• On pages with language selector, it is maybe questionable where the icons should be, but they should not use a full line just for the icons.

It concerns a huge number of pages. Best regards Csar62 (talk) 17:20, 29 July 2021 (UTC)

Ping Patafisik (WMF) . Jules* (talk) 10:40, 30 July 2021 (UTC)

@Csar62 and Jules*: Hello, two tasks are opened about this subject (and the coordinates display): phab:T282027 and phab:T281974. See also the answer below. --Patafisik (WMF) (talk) 16:53, 5 August 2021 (UTC)

Assessment icons and the upper right corner in the new display

Tracked in Phabricator
Task T281974

Notice in the top right corner how the coordinates overlap with the infobox.

I just came across the language switching feature that you have in development. Overall, I like it—collapsing makes sense, it's nice to see the total language count, and the positioning may make it easier for people to find. However, I anticipate an area of concern for the community (at least at en-WP) will be that this area is already currently used for other icons, particularly protection icons and good article/featured icons. When testing, these icons are currently pushed down below the bar underscoring the title, which in turn pushes anything normally right below the bar (namely coordinates) down another line. As you can see in the screenshot, this can cause overlap with the article content, and looks awkward even when it doesn't.

Moving the assessment icons somewhere else will be essential if we want to clear up that space. This brings me to a proposal we considered a few months ago to move the good/featured icons next to the article title, which I think you may find it very useful to read. The proposed placement is something that the Danish Wikipedia does and that has the potential to make the icons a lot more noticeable (something crucial for media-literate readers). However, the discussion reached a no consensus result, in large part because of uncertainty about how aware readers are of the GA/FA icons in their current placement. Other recent discussion about redesigning the icons' appearance has touched on similar themes. It would be extremely helpful if you could look into how the GA/FA icons are handled as part of your work, perhaps do some user research to determine if there are indeed issues with awareness (as I suspect), and incorporate the results into your improvements package. Would this be possible? {{u|Sdkb}} ^talk 17:35, 3 August 2021 (UTC)

While moving assessment icons to a more discoverable position may be a good idea, doing so with all indicators (category pages’ help links, user pages’ random icons, and so on) isn’t. Using the current infrastructure, it’s possible to do so in Vector.js (for example that’s done on huwiki, although we put the icon before the title, not after, as dawiki). If you want to get it done without JS, the categorization system I proposed in phab:T75299#6951825 may help to do it on server side. And not only in case of the GA/FA icons, but also for positioning the coordinates. —Tacsipacsi (talk) 00:41, 4 August 2021 (UTC)

@Tacsipacsi: Yeah, I wouldn't want to see all icons currently in the upper right moved to directly after the title. The protection icons in particular are quite common. The designers will have to figure out what to do with those if they want to put the language list where they are currently. {{u|Sdkb}} ^talk 17:53, 5 August 2021 (UTC)

@Sdkb: They have figured it out: what currently happens, i.e. indicators below the language link dropdown, and coordinates broken as long as the community doesn’t fix them. —Tacsipacsi (talk) 23:31, 5 August 2021 (UTC)

Renommage de la page "Brouillon" ?

copied from Topic:Wdygruogtnv10t42

(Pas sûr qu'ici soit le meilleur endroit pour cette discussion ; si vous voyez mieux, notamment plus visible mais tout autant approprié, merci de déplacer cette discussion, ou d'y mettre un mot et un lien).

Je trouve que le terme "brouillon" n'est pas le meilleur choix pour désigner cette page et sa fonction. J'utilise plus volontiers dans les discussions avec les nouveaux, les expressions de « zone d'ébauche », « page d'ébauchage », bref « ébauche », non pas que le sens soit fortement différent, mais parce qu'il est plus gratifiant quand on débute. C'est donc plus un choix psychologique, ou pédagogique, que sémantique. Qu'en pensez-vous ? -- Eric.LEWIN (talk) 19:50, 3 August 2021 (UTC)

Bonjour ! Chaque communauté peut choisir le meilleur mot pour décrire cela. C'est une question de décision locale. La Fondation ne change pas le libellé. SGrabarczuk (WMF) (talk) 01:22, 11 August 2021 (UTC)

New sidebar design

I think the sidebar is not user-friendly (i.e.: font too small, words too crowded, help link is not enough noticeable). Could you propose some ideas about it? --Daniele Pugliesi (talk) 17:29, 4 August 2021 (UTC)

Hello @Daniele Pugliesi! Thank you for asking. You are correct, the sidebar could be improved. We might at some point increase the font. (That increase would apply to everything, not just sidebar.) About the specific words though, we don't change those because this part is completely on the community's side. SGrabarczuk (WMF) (talk) 12:17, 5 August 2021 (UTC)

In my opinion words are fine, but what is more important for new and/old users could to be more evident and intuitive, for example adding some icon, coloured boxes, etc. In other words, a different and more complex layout/graphics, better if with some possibility to customize it, for example in order to have a basic sidebar for readers and new users (with more emphasis on links to rules pages and support pages) and another version for experienced users (with more emphasis on links to editing tools and patrolling tools). --Daniele Pugliesi (talk) 12:58, 5 August 2021 (UTC)

Icons and stuff - that sounds interesting. In the early days of the project, when the team was just imagining what could be done, a sketch with a sidebar with icons was created. Maybe we will think about that again when we will be closer to the "general aesthetic refinements". And yes, we have thought about making the interface tailored for specific groups, so one version for readers, and a different one for power users. Sadly, we are not able to do that now because of the limitations of the infrastructure. SGrabarczuk (WMF) (talk) 15:36, 5 August 2021 (UTC)

The width limitation of the wikitext source editor

The source editor uses monospace font which is wider than the default one. This means that every line of text in the source edit view consists of smaller number of words than on the article page. While I'm generally for the width limitation, I feel like the editor is too narrow. Msz2001 (talk) 06:00, 7 August 2021 (UTC)

Hi @Msz2001, fair request. We'll create a Phabricator task and examine how exactly how that could be done. SGrabarczuk (WMF) (talk) 01:12, 11 August 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)

Ok. Blubabluba9990 (talk) 17:43, 24 November 2021 (UTC)

Deskop/mobile key

Premise: I don't speak English well so excuse me for error. Considering the fact that you are changing the interface, I ask that the "desktop/mobile" and "mobile/desktop" button be repositioned in a more visible way and above all higher, because especially with small touchscreen displays as smartphone, sometimes the "warning" or "privacy" button is often pressed. My idea is to put it in the sidebar near wiki language link or at the top near the "edit" and "history" buttons--5.11.114.150 10:29, 10 August 2021 (UTC)

Thank you! That's an interesting thought. This will be possible closer to the end of the year when we will be working on the "general refinements," and then we will possibly change the footer. SGrabarczuk (WMF) (talk) 01:03, 11 August 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. {{u|Sdkb}} ^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;
}
#content {
	max-width:860px;
}

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)

Mauvais liens de page d'aide sur le nouveau menu utilisateur

Bonjour, en allant sur Wikipédia en français, en étant déconnecté, nous avons, avec la nouvelle interface, un nouveau bouton Créer un compte puis les trois points menant au sous-menu où apparaît ceci :

« Pages pour les éditeurs déconnectés (en savoir plus) », ce qui mène à un mauvais lien, c'est dû à une mauvaise "traduction" de la page d'aide de WP anglophone Help:Introduction. Cette dernière a en effet w:fr:aide:premiers pas comme équivalent, cf Wikidata.

En résumé, serait ce possible de modifier le lien de Aide:Introduction vers Aide:Premiers pas ? Merci d'avance et bonne continuation pour le dévelopement du projet! -- Nemo ^Discuter 20:51, 14 August 2021 (UTC)

Solution technique temporaire trouvée sur WP en français (changement de redirection, Aide:Introduction menait auparavant à w:fr:Wikipédia:Résumé introductif). À mon avis, il faut que le lien (en savoir plus) mène à la page correspondante de Help:Introduction pour chaque wiki, indiquée sur l'item wikidata et ce peut importe les futurs évolution de l'interface, un mauvais lien aussi visible n'est pas tolérable. Bonne continuation, -- Nemo ^Discuter 09:46, 15 August 2021 (UTC)

Similar issue: phab:T288293.--Patafisik (talk) 19:09, 19 August 2021 (UTC)

Ability to link to other language articles missing in new version of language selector

Tracked in Phabricator
Task T265996

Tracked in Phabricator
Task T287206

Previously before the rollout of the new language selector (the one that move it onto the header bar), I was able to link English Wikipedia articles to other languages Wikipedia articles by clicking the "edit links" link under the languages panel on the sidebar. However with the new version, this link is nowhere to be found, even in Edit mode. Would like to have this function added back else it will become very tedious process of linking to other languages Wikipedia articles, I would need to go to wikidata, find the correct item, and add the newly created article onto the language list. Another alternative I can/have done before, is switching back to legacy mode, add it onto the list, and then switch back, which sounds ridiculous as this isn't improvement. Both methods are very inefficient when compared to former design of ease of access and usage.

Sorry about the rant, if the feature is already there, please advise where to find it else would like to request this feature to be added back. Paper9oll 10:46, 15 August 2021 (UTC)

@Paper9oll: There’s an Edit/Add interlanguage links in the left-hand sidebar’s toolbox (a bit higher up than where the language links were). The plan is to have it next to the language links again, but that needs quite some work (phab:T265996); the toolbox is a temporary solution (phab:T287206). The popup to link the articles without ever going to Wikidata doesn’t work reliably in new Vector yet, but hopefully next week it will. —Tacsipacsi (talk) 13:01, 15 August 2021 (UTC)

@Tacsipacsi Oh great, thanks for the reply. Will make do with the "Edit/Add interlanguage links" for the time being. Glad to see the function being worked on. Paper9oll 13:12, 15 August 2021 (UTC)

Ordre des boutons dans le nouveau menu utilisateur

Tracked in Phabricator
Task T288913

Tracked in Phabricator
Task T291011

Bonjour, je pense que l'ordre des boutons dans le nouveau menu utilisateur devrait être changé. L'actuel est inspiré des anciens liens utilisateur du vieux Vector (Discussion - Brouillon - Préférences - Bêta-Liste de suivi - Contributions - Se déconnecter), qui se trouvaient horizontalement. Mais verticalement, Liste de suivi et Contirbutions sont plus difficile à atteindre alors que ce sont deux liens plus utilisés que Bêta et Préférence. Je propose donc un nouvel ordre dans le menu vertical :

• Discussion
• Brouillon
• Liste de suivi
• Contributions
• Préférences
• Bêta

-- Nemo ^Discuter 12:58, 15 August 2021 (UTC)

Hi,

I agree with a list where "Préférences (Preferences)" and "Bêta (Beta)" came after "Liste de suivi (Watchlist)" and "Contributions (Contributions)". The list in the user menu that I can see is actually this one:

• Discussion (Talk)
• Brouillon (Sandbox)
• Préférences (Preferences)
• Bêta (Beta)
• Liste de suivi (Watchlist)
• Contributions (Contributions)
• Traductions (Translations)
• Fichiers téléversés (Uploaded media)
• Log-out

@Nemo Le Poisson: can you add in your suggested list to order the links also "Uploaded media" and "Translations" ?--37.103.9.224 10:26, 18 August 2021 (UTC)

Effectivement, certains wiki ont d'autres boutons ! Pour moi, Preference et Gadget devraient systématiquement se trouver à la fin de tous les autres boutons. Cela donnerait ici :

Discussion (Talk)

Brouillon (Sandbox)

Liste de suivi (Watchlist)

Contributions (Contributions)

Traductions (Translations)

Fichiers téléversés (Uploaded media)

Préférences (Preferences)

Bêta (Beta)

Log-out -- Nemo ^Discuter 21:08, 19 August 2021 (UTC)

I agree.--37.103.9.224 13:38, 26 August 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 class="wikitable sortable wide" . 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﹠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)

Suggestion to redesign the Language button

Hi, with how the Language button is designed and placed onto the article right now, it also moves the articles' symbols (such as stars, locks, GA...) to a new place. I think the new place of these symbols is not visually reasonable because it feels quite out of place. So the Vietnamese community has a suggestion to redesign and replace the button like this, where we will drop the word "Languages" (as in XX languages) and then combine the articles' symbols and the Language symbol onto one single place. Can you guys consider it?

Also, the moving articles' symbols to a new place means that we have to move coordination to a new place, and consequently make the coordination overlaps with Xtool (See this Phab task I just created.) Thanks! Bluetpp (WMF) (talk) 14:14, 16 August 2021 (UTC)

Clock

The clock is very helpful and I use it constantly. I don't like having to use a pulldown menu to look at the UTC time on the new Vector skin. Thanks, Diannaa (talk) 01:22, 18 August 2021 (UTC)

Hey @Diannaa, thank you for your opinion. Any links added via gadgets to the user menu are displayed in the new dropdown. The clock is added via such a gadget. Since these lie within the realm of community/volunteer editing, our engineers provide help for the gadget maintainers, but don't edit gadgets if possible. You may find another thread on this issue on the gadget's talk page. SGrabarczuk (WMF) (talk) 16:31, 19 August 2021 (UTC)

Overlapping content when coordinates template is present

Here is a screen shot of what I am seeing with the new Vector version on the article Calgary. The output of the Coord template is overlapping with other content on the page. Same on other articles such as en:Division of Batman but not on en:Edmonton, where the Good Article icon apparently pushes it downward to a nice location. I am using an Acer Chromebook, but I tested it also on an Acer desktop running Windows and got the same mess. Thanks, Diannaa (talk) 01:19, 18 August 2021 (UTC)

The second screen shot shows the box "Skip to TOC - Skip to bottom" unhelpfully overlapping with other text on the en.wiki page Wikipedia:Contributor copyright investigations. Thanks,Diannaa (talk) 01:33, 18 August 2021 (UTC)

@Diannaa: For the coords at least, it's a known issue; see above. Cheers, {{u|Sdkb}} ^talk 18:45, 18 August 2021 (UTC)

Login button is under a ··· icon

Hello! When logged out, there are two options [Create account] and [···]. The login button should be visible at all time, and should also have an icon. -Theklan (talk) 17:11, 19 August 2021 (UTC)

Hello, others users agree with this proposal, e.g. @Schlosser67: asked the same here. In my opinion, if the team want to conserve the login button under the icon, the icon more appropriate should be the account icon (the same of logged-in editors), instead of three points button which is not "self explanatory" of a user link to login inside. Logged in or logged out, the user icon is easy to understand and universal for "the person visiting this website". The ··· icon is not so clear : it means "see also" and not "see the link to log-in".--37.103.9.224 13:36, 26 August 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%

small

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

First of all, huge thank you for talking to the Arab community, @Nehaoua!

1. Could you write more? Where does the link appear exactly?
2. 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

Tracked in Phabricator
Task T289163

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

Example of behavior from VE citation tool

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? {{u|Sdkb}} ^talk 22:37, 27 August 2021 (UTC)

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

@Tacsipacsi: 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. {{u|Sdkb}} ^talk 17:46, 28 August 2021 (UTC)

@Sdkb: 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 m: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:

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?

Cheers, {{u|Sdkb}} ^talk 23:51, 1 September 2021 (UTC)

Hey @Sdkb! Good points!

1. 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.
2. 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)

@Tacsipacsi: Hmm, any idea where one would propose removing it? {{u|Sdkb}} ^talk 01:25, 4 September 2021 (UTC)

@Sdkb: 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 phab:T290463. {{u|Sdkb}} ^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. {{u|Sdkb}} ^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)

@SGrabarczuk (WMF): Any thoughts on my hovering rather than clicking suggestion just above? {{u|Sdkb}} ^talk 20:25, 11 October 2021 (UTC)

Suggestion for Watchlist

(original message posted on fr.wikipedia)

@Curios7ty: 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

Tracked in Phabricator
Task T290480

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)

2 colones sont mieux qu'une étroite

(Original topic by @Hploter: . --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

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[2] feels a lot better to me. --Greatder (talk) 08:53, 13 September 2021 (UTC)

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)

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)

Von 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#Language_Selector_misunderstandable) 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 mw.loader.load('ext.gadget.keresesUjFulon').) 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)

Hello @Tacsipacsi, I'm sorry you've been waiting that long. As you've correctly identified, this gadget doesn't work with the new Vector because the new Vector uses Vue. In this context, Vue is more predictable and easy to maintain at the cost of lesser modifiability. At this point, we are not convinced if we should make an exception here and make it possible for everyone to modify the feature. It'd need a twofold (design and engineering) analysis.

So why would you like to see an interface button? And why I'm asking - interactions such as “open in new tab” are also available via the context menu of the browser; some mouses have dedicated buttons/scroll wheels. From what I know, based on my Community Wishlist Survey experience, there's a lot of gray area between what we support and what we let the browsers do. For the sake of the mentioned analysis, we need to understand your need better. SGrabarczuk (WMF) (talk) 15:18, 16 March 2022 (UTC)

@SGrabarczuk (WMF), thanks for getting back to me! The issue this gadget tries to work around is that “open in new tab” is not available in modern browsers’ context menus for form buttons (<button> and <input type="button|submit|reset">), only for links (<a> elements), and the Search button is a <button> (as it should be). Chromium seems to support Ctrl+clicking on the form button (but not middle click), but Firefox supports neither.

There are some cases where no links provided by the search widget point to the page where submitting the form would go: for example, if you search for Special:PrefixIndex/Foo, legacy Vector’s search widget provides four links (Special:PrefixIndex/Foo type A, Special:PrefixIndex/Foo type B, Special:PrefixIndex/Footer and https://www.mediawiki.org/w/index.php?search=Special:PrefixIndex/Foo&title=Special:Search&fulltext=1), while submitting the form goes to Special:PrefixIndex/Foo. (I used legacy Vector because new Vector’s search widget doesn’t provide any suggestions due to phab:T277363.) Or if you search for MediaWiki:searchbutton, submitting the form brings you to the locally not overridden MediaWiki:Searchbutton, but it’s not shown as a search suggestion (not even in legacy Vector). If you’d provide a workaround for this issue yourselves rather than a customization point, that’s also okay for me. —Tacsipacsi (talk) 22:42, 16 March 2022 (UTC)

The WVUI search has a row at the bottom that allows searching within pages. I use Firefox and I can open that in a new tab without any problems. For each suggestion, I can also open those in a new tab. I can understand a need to work around phab:T277363 since for that query no suggestions show, but if that's resolved I'm not really sure what problem the tab link solves. I think there is a use case for navigating to a new tab for the purpose of new page creation. That might be achieved by a change in the software itself that adds a row at the bottom saying "Create article with name <text>" that can also be opened in a new tab.

That aside, if you want to replicate the existing behaviour, Vue maintains a virtual DOM, so inserting a new button inside it that persists across changes will be tricky. Instead I'd suggest you create a button in the parent container and use CSS to absolutely position it. The click handler would need to query the DOM to work out the highlighted node and where it should go. I'd note seeing this for the first time, I found the use of the external link icon a little problematic here. I expected this to run a Google search when I first tried it out since I associate that icon with "follow a link to an external site". Jdlrobson (talk) 23:53, 16 March 2022 (UTC)

@Jdlrobson: I don’t follow you. I brought two examples where neither new nor legacy Vector works without extra page loads. The purpose of this gadget is not to work around T277363 (it’s older than even legacy Vector), but to work around a behavior of browsers that I probably wouldn’t call a bug (but rather a design failure), and certainly not a bug in our code. (I also don’t even plan to work around T277363 with this—while I hope that this gadget’s functionality will become available on new Vector before it becomes default on huwiki, I also hope that T277363 will be fixed much sooner than that; fixing a bug that affects all users of all sites is much more urgent than fixing a gadget that’s available on only a few wikis, and even there it’s opt-in.)

For the technical part, I’m open to all solutions that work reliably across screen sizes and zoom levels and provides a better-than-horrible UI (i.e. it should be visually part of the search input field, not somewhere outside of it); including, but not limited to, you adding a such button (you can hide it by default and let me unhide it if you don’t want to clutter the default interface), adding a declarative way to add the button (the button part of the gadget doesn’t even need any callback, it just adds an <input value="Megnyitás új fülön" title="Megnyitás új fülön" id="keresesUjFulonGomb" type="submit" formtarget="_blank"> to the appropriate place, styled with the appropriate CSS), or adding a hook to update the DOM after any Vue changes (this is maybe the easiest, but definitely by far the least performant solution). Unfortunately I couldn’t get the absolute positioning work reliably, as the search field may have different size, spacing etc. depending on the screen size, not to mention that the Search button’s size depends on the UI language.

For the icon, there’s a (Hungarian-only) tooltip that explains what this button does (and also it’s an opt-in gadget, so the user should have read the description on Special:Preferences before), so Hungarian users are hopefully less confused about it, but if you have a better idea, I’m open to applying it on legacy Vector as well. —Tacsipacsi (talk) 17:08, 17 March 2022 (UTC)

Sticky Header in legacy skin?

legacy index

new index

legacy page

new page

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)

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

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)

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)

@SGrabarczuk (WMF): …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. {{u|Sdkb}} ^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)

@OVasileva: In this thread I'm talking about desktop, so different than the phab ticket (although same issue). {{u|Sdkb}} ^talk 16:32, 13 October 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)

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:

Suggested right boundaries

— Preceding unsigned comment added by Theanswertolifetheuniverseandeverything (talk • contribs) 19:42, 21 October 2021 (UTC)

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. — Preceding unsigned comment added by MrMobodies (talk • contribs) 23:29, 26 October 2021 (UTC)

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:

Tracked in Phabricator
Task T277363

Bonjour, sur l'ancienne barre de recherche de Vector, lorsqu'on tapait Special:, 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, @Nemo Le Poisson: this is the dedicated task on Phabricator: phab: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.

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. [Edit: Fixed! Hooray!] 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. 

   Screenshot of three pages, showing (1) sticky header, (2) current desktop improvements, (3) classic vector, with the search-click-targets highlighted in red

   (Main point) When I'm scrolled-down on a page, 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.
   1. 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.]
      • (cf. w: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.]
   2. 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.
   • 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.
   • 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.

I hope those details help! –Quiddity (talk) 02:36, 10 November 2021 (UTC)

I don't see an issue with the search box being moved... except for why? It's exceptionally common around wikis everywhere that the search box is in the upper right. So what is the justification for changing from this norm? We shouldn't do change for change sake, but if there's a good reason, that's fine. Supertrinko (talk) 01:09, 25 January 2022 (UTC)

Why is the search box semi transparent, though? I see some faded grey title in the background right next to the text I've typed and this is quite confusing/distracting when you look at what you're searching for. I think it would be way better if the white box was really opaque instead of showing for instance a faded grey title right next to what you typed, slightly off because of scrolling, as if you were searching something plus the ghost of something else. LDiCesare 16 February 2022

A question

Do you have any plan to make vector skin mobile responsive? I use this code to do this- if ( mw.config.get("skin") === "vector"){ document.head.innerHTML += '<meta name="viewport" content="width=device-width, initial-scale=0.77, maximum-scale=1.0, user-scalable=0">'; } Yahya (talk) 09:07, 11 November 2021 (UTC)

We've been working towards that goal, but it's not an official goal of the project. For third party wikis you'll be able to do this via the configuration flag wgResponsiveVector and that script is exactly what I was going to recommend for Wikimedia wikis :) Jdlrobson (talk) 00:01, 6 January 2022 (UTC)

Temporary logo customization

In legacy vector, the accepted way to temporary change the logo (for anniversaries and milestones of wikis) was through css. In the improved vector, the logo items seem to be hardcoded in the html. Any tips? Geraki (talk) 19:30, 15 November 2021 (UTC)

The instructions you're looking for are mentioned on /Features/Header, and it's /Features/Breaking changes + T245190. SGrabarczuk (WMF) (talk) 14:20, 16 November 2021 (UTC)

عدم سازگاری و تداخل در نسحه جدید و قدیم. Incompatibility and interference in new and old versions

سلام من از پوسته جدید وکتور بسیار راضی هستم. متاسفانه در نسخه 1.36.2 و 1.38 که تست کردم، مشگل تداخل نسخه قدیم و جدید را می‌دهد. در 1.36.2 با تنظیمات پیش فرض وکتور و استفاده از کامند 2،برای کسانی که وکتور وارد سیستم نشده‌اند، وکتور قدیم را نشان می‌دهد و در نسخه 1.38 برعکس است در صورتی که تنظیمات من همانند دایکرومنت پوسته وکتور است. این موضوع کلافه ام کرده است. آیا ب ای حل این مشگل راهکاری دارید؟ با تشکر

hello I am very satisfied with the new vector shell. Unfortunately, in versions 1.36.2 and 1.38 that I tested, the problem of interfering with the old and new version gives. In 1.36.2 with the default vector settings and the use of comand 2, for those who are not logged in, the old vector shows and It's the opposite in version 1.38 If my settings are the same as the docker theme. This has overwhelmed me. Do you have a solution to this problem? Sincerely Sokote zaman (talk) 22:54, 22 November 2021 (UTC)

Hello @Sokote zaman. Just to be sure, you experience this on a third-party wiki, not a Wikimedia wiki like Wikipedia in Farsi?

سلام @Sokote zaman. فقط برای اطمینان، شما این را در ویکی شخص ثالث تجربه می کنید، نه ویکی ویکی مدیا مانند ویکی پدیا به فارسی؟

SGrabarczuk (WMF) (talk) 13:39, 24 November 2021 (UTC)

سلام بر شما

@SGrabarczuk (WMF)

من میدونم شما بحث پشتیبانی از ویکی های شخص ثالث را انجام نمیدهید. قبلا این مشگل را هم در انجمن و هم در گزارش اشکال مدیاویکی مطرح کردم ولی هیچ جواب درستی نگرفتم. اگر رضایت کاربران ویکی ثالث برای شما مهم است و باعث می‌شود اشکالات اسکریپت را پیدا و ارائه دهند خدمتتان عرض میکنم این یک مشگل هست و حتی اگر یک ویکی با حالت نصب اولیه بدون کانفیگ شخصی هم اگر نصب و تست کنید متوجه این مشگل خواهید شد.

من این مشگل را در ویکی پدیا فارسی ندیدم و تست هم کردم جواب داده است. خب لااقل بگوید از چه دستوری استفاده کرده‌اید و توضیحات مربوطه را بروز کنید. من ویکی را ب یا خودم نصب میکنم و به جایی وابسته نیست.

با احترام و تشکر فراوان از همه شما را بابت این اسکریپت بسیار خوب Sokote zaman (talk) 14:52, 24 November 2021 (UTC)

Narrow width issue

This new width is a nonsense to me. If so, it means current layout of existing pages will have to be redone, more specifically pictures positioning. Large tables will take two lines instead of one !!! I guess I won't contribute anymore, if it goes this direction.--GGir (talk) 09:10, 12 December 2021 (UTC)

Of course, it's a mess, and it will proceed regardless. The entirety of the Internet is being turned into an unreadable mobile downgrade. Wikipedia used to be the site one could be sure would not feature annoying pop ups, moving parts, large fonts. But as it looks, the time will come when they implement an unskippable menu at the top that remains on the screen no matter how much one scrolls. Or a login button that only appears when one scrolls down, like in the WordPress rework. Merely brainstorming more annoying ideas, feel free to use them, my dear.--Adûnâi (talk) 11:37, 12 December 2021 (UTC)

"It is not possible for them to intuitively switch languages, search for content, or adjust reading": adjust reading, but WMF provides a limited non-adjustable width with the New Vector. They want to adapt the desktop skin after the incomplete mobile skin. The logo is also destroyed, being smaller, only because on mobile it cannot be large. --NGC 54 (talk | contribs) 12:29, 12 December 2021 (UTC)

¿Qué tal sí hacemos que ese enorme espacio en blanco sea gris?

Digo, ese es mi único pero con la nueva piel. Sin embargo, este problema de "hay demasiado blanco" ya está resuelto en la piel Timeless. En esta piel el texto negro contrastado con blanco de fondo está flanqueado por unos sutiles espacios grisáceos. Me es bastante cómodo esto, es lo mismo que ocurre en Word por defecto.

Espero que esta simple sugerencia apacigüe las inquietudes de algunos uwu. --Christian Alexis Arroyo Ortiz (talk) 09:59, 18 December 2021 (UTC)

Gracias @Christian Alexis Arroyo Ortiz. Esta es una traducción del Traductor de Google (no se español): trabajaremos en esto como parte del Refinamientos estéticos generales. Puedes leer más en T259240. SGrabarczuk (WMF) (talk) 00:07, 21 December 2021 (UTC)

@SGrabarczuk (WMF) I find the new design eye-straining, because I have a big monitor and now I see a lot of empty white space, that makes the overall space very bright. One of the differences with "old" Vector is that Vector had the sidebar with a grey background, while the new Vector has completely white background. Also, there are no borders on the page to delimit where the content ends, which makes me a bit uncomfortable when reading. I'd suggest returning the grey background and the borders, the same that were on the old Vecctor. You can test with this CSS (that I've put to my personal CSS):

body {
	background: #f6f6f6;
}
.mw-page-container, #mw-panel {
	background: transparent;
}
#content {
	background: #ffffff;
	border: 1px solid #a7d7f9;
}
#p-namespaces {
	background-image: linear-gradient(to bottom,rgba(167,215,249,0) 0,#a7d7f9 100%);
	padding-left: 1px;
}

I know that T259240 has some talk about borders, but the border that are suggested there are fundamentally different: they're not close to the text delimitation, which makes them distracting. Ciencia Al Poder (talk) 14:18, 11 February 2022 (UTC)

Hi @Ciencia Al Poder. I understand. I also have quite a large monitor, 27", and sometimes I work on a huge 4K, 32" or so. There is a lot of bright space. We will think how not to solve this. I've tested your settings. Even if it won't make it to the final version, it will be possible to use these settings as a gadget. SGrabarczuk (WMF) (talk) 21:54, 17 February 2022 (UTC)

So far so good

Copied from Topic:Wmjydo5ya7z8zz3g

Really liking that the table of contents now moves as you scroll down. I can see where I am at, what's next, and can easily warp to where I want to go. A2Bros (talk) 05:13, 20 December 2021 (UTC)

Contra the "sticky header" clutter and interwiki language selection

The dreaded "unskippable menu" was a joke on my part above, but it's apparently a reality (the "sticky header")... What an abomination - why would I ever want my screen space to be stolen by an ever-present menu? Are you expecting me to forget what page I am reading, so that I would need the page title at the top constantly? This is an objectively infuriating change that apparently crawled to desktop from mobile phones. I vehemently oppose such a direction - especially for the logged-out users! I actually routinely press F11 to read full-screen without the distraction of my browser UI, let alone would I wish for more clutter, unavoidable at that.

Sticky header will allow users to access important functionality (logging in/out, edit, talk pages, etc.) without requiring people to scroll to the top of the page.

These are not "important functionality". And even if they were, I would not permanently trade my screen space for a thing I can access in a millisecond by pressing the Home button! Do people not employ keyboards in 2022?

And the interwiki language button is getting downgraded even more? The previous change at least showed a few important languages at the ready, one click away (based on my IP address or something). Now it will actually force me to click more times. What a joke. Every single change is counter-productive, it's impressive.--Adûnâi (talk) 23:16, 20 December 2021 (UTC)

Thank you for your comment, @Adûnâi. Please be reminded that here on MediaWiki.org, the Code of Conduct is in force. I understand you're dissatisfied with our assumptions and choices. We can talk about this - how to disable it individually, etc. Please stop using offensive and derogatory words, though. For instance, let's leave "abominations" in the Dungeons and Dragons world. Thank you. SGrabarczuk (WMF) (talk) 00:50, 21 December 2021 (UTC)

@Adûnâi Home button makes you loose your scrolling position. So that is not a solution. Having a sticky header allows you to e.g. open a talk page in a new tab. Or open a specific language version in a second window for a side-by side view.

It is quite easy to remove the header if you do not find is useful. You can do that with e.g. Stylish or by using commons.css. Just add a line like this to your css:

#vector-sticky-header{display:none!important}

Nux (talk) 22:21, 11 January 2022 (UTC)

@Nux, I fail to see how such fringe cases justify ruining the experience for 99% of the time. Even in your example, a far simpler and more efficient solution can be found - such as copying a part of the text and then CTRL+Fing it to find it immediately again (apparently, it is a downgrade aimed at the mobile users unable to do it, just like with the redundant and annoying arrow buttons on this very page when my keyboard already has the Home and End buttons). Regarding your suggestion to disable the sticky, unscrollable header - 1) I have no idea about coding that stuff; 2) does it even work when logged out? If not, it will be utterly useless to me, as I rarely log in.--Adûnâi (talk) 00:47, 12 January 2022 (UTC)

Yes, Stylus works when you are logged out. You seem to be versatile in using your keyboard so you should be able to handle CTRL+C and CTRL+V 😉. Nux (talk) 01:10, 12 January 2022 (UTC)

I hate it, but others...

Copied from Topic:Wmjryh74k5zswirt SGrabarczuk (WMF) (talk) 00:15, 21 December 2021 (UTC)

Hello, as it is with many proposals to improve the look and feel of the Wikipedia interface, some people like it, others don't care and then again others absolutely hate it. What to do? Wouldn't it be better in general to give the readers and collaborators more options for customization? Ziko (talk) 15:17, 20 December 2021 (UTC)

I suppose I've no objections as long as it's easy to opt out. However, I'm concerned that such developments divert the WMF's limited IT resources from the many stalled Phabricator tickets which represent fixes and minor enhancements that the communities actually want and have asked for. Certes (talk) 16:20, 20 December 2021 (UTC)

Hi @Ziko, apologies for the late response. "Wouldn't it be better in general to give the readers and collaborators more options for customization?" - of course it would. The only issue is that it'd be massively difficult to maintain and deal with when building something next upon all these options.

Soon, we'll update our FAQ where we'll publish something along these lines:

"Each preference is like a crossroad where users can choose between options. Many choices indicate many combinations. Preferences would make us responsible for all the combinations. We would have to maintain them, and also, in the case of building new features, check if the features are compatible with each of the combinations. We can't afford that.

Instead, we give the communities the option to create gadgets, user scripts, and individual settings. As always, we provide the space for bottom-up creativity, and help technical users to maintain their code.

For more information, read the Just make it a user preference essay by Quiddity (WMF)." SGrabarczuk (WMF) (talk) 03:22, 24 February 2022 (UTC)

I love it, but...

...there is a reason that a couple of issues keep cropping up in this discussion: they represent a gut reaction of a lot of users to the changes based on massive amount of cumulative web experience. In short, the wisdom of the crowd. Please don't ignore them.

The first issue is the massive amount of wasted white space on 16:9 monitors. Readers, even those who don't log in or edit, don't necessarily want or expect an encyclopedia to look like Twitter. If logged out users can have four configuration choices for the table of contents, surely at least a wider option could be offered. Or at least compromise by using a percentage rather than a pixel number to limit the content width. The nearly rote response that pops up in most similar comments above of "some people who are much smarter than you say that you'll like this better" is not comforting.

The second is less important to many, but the downgrading and re-"organization" of the interwiki links makes linking to other language articles incredibly tedious. Even if the interwikis have to be hidden, ditch the geographic-based lists and just alphabetize them. This presents difficulties for me when I'm on an interwiki where I don't know the language well, and I scroll through a list a regions names that I don't understand. I guess the upside is that I've learned some new foreign-language terms lately.

I'm not sure where the clamor for a new interface came from, but I generally like the look of the new interface except of the blank spaces that make Wikipedia look like a social media site. I accept the gradual dumbing down of the look of most websites (e.g. greater use of emojis), but appreciate a stronger emphasis on the graphic "feel" of the new interface. AjaxSmack (talk) 03:12, 21 December 2021 (UTC)

Sidebar vs table of contents

Copied from Topic:Wmlday2rza1i9wa7

When I open the sidebar via the "<<" on the upper-left corner, the table of contents disappears. When I close the sidebar, the TOC reappears. Is this intentional? If not, then can this be fixed? George Ho (talk) 08:27, 21 December 2021 (UTC)

Humble request (toggle for width + header)

It's awesome, great work, and a much-needed refresh. I imagine there will be bellyaching about the new text width and the sticky header. I imagine most people who complain about the one will complain about the other, so I recommend a toggle (near the "mobile view" link on desktop) to simultaneously make the text full-width and remove the sticky header. It'll set a cookie. No need for a preference or anything advanced like that. I make this suggestion because there will be absolute metric tons of complaining if not, from my experience of how introducing those two design elements usually goes. Thanks again for working on this. Enterprisey (talk) 08:35, 21 December 2021 (UTC)

Hello @Enterprisey. Thank you for your support. There is a gadget disabling the limited width already. I think it will be also possible (I haven't tested that myself yet) to hide the header via CSS. Would that work as a solution? What do you think? SGrabarczuk (WMF) (talk) 13:44, 21 December 2021 (UTC)

@SGrabarczuk (WMF): No, for several reasons:

• Gadgets are per-wiki. As long as there are no global gadgets, most small wikis will almost certainly miss out anything that’s gadget-based, because simply there’s nobody installing the gadget, let alone localizing it (e.g. translating the description and any human-readable strings it produces).
• Gadgets are logged-in-only. Logged-out users cannot enable gadgets (or only using complicated ways like bookmarklets or browser extensions that explicitly load the required ResourceLoader modules, but that’s not for average users). In contrast, purely cookie-based solutions like the mobile view toggle or the table of contents collapsing work for both logged-in and logged-out users.
• Gadgets are not very visible. If one specifically looks for gadgets, they can find them in the preferences, but people won’t discover it by chance, while they may discover a link in the page footer.

The first two issues can be resolved by using a browser extension (although it introduces another drawback, browser-dependency, and thus it may not even work for many browsers, especially for smartphone and tablet ones), but the third one, visibility, can be resolved only within the skin.

A solution that consists of pure CSS except for the small amount of JS toggling the class is a good direction to avoid HTTP caching issues—but this CSS and JS should live within the skin, not in some gadget. —Tacsipacsi (talk) 16:24, 21 December 2021 (UTC)

@SGrabarczuk (WMF), thank you for the response! I anticipate the majority of the complaining coming from readers without accounts, and it would be surprising to require an account for a minor display change. I think this should be treated exactly like the table-of-contents toggle (thanks Tacsipacsi for that example). I feel that this would serve a large number of readers for a relatively small amount of work. (This might finally get me into MediaWiki dev :) that is if WMF product is okay with this change.) Enterprisey (talk) 23:03, 21 December 2021 (UTC)

@SGrabarczuk (WMF): Where could I find this gadget? I like the 2022 vector skin, but the limited width is the only reason why I haven't enabled it yet. Thanks in advance, Tol (talk | contribs) @ 05:10, 15 April 2022 (UTC)

@Tol, here it is. Enjoy! SGrabarczuk (WMF) (talk) 14:39, 23 April 2022 (UTC)

Thank you! Tol (talk | contribs) @ 18:23, 23 April 2022 (UTC)

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)

What is our objective? > Currently the interface doesn't highlight the community side & list item 4

List item 4 under https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements#Currently,_the_interface%E2%80%A6, (connects with "...doesn't highlight the community side"):

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

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

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

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

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

Hey @AltoStev, I'm sorry for not answering earlier! It took me a while to talk to the team about this, and then I was occupied with urgent tasks. I'm really sorry.

• "But does that help the user?" - the assumption is that yes, it helps to understand that what you see in your mobile app, mobile browser, and on desktop, is the same website.
• "This new design hides many community links behind a menu" - according to our quantitative data pulled via API, readers don't click links presented to them that much. Quite the contrary, they ignore these, and ignoring the links in the sidebar is a perfect example. By de-clustering the interface, we are making the really most important links and "community entry points" (like "Edit" or "Log in") more intuitive to find, understand, and use. Perhaps at the last stage of the project, we'll highlight some links in blue, or something... we haven't started thinking about the details yet.
• Alerts and notifications are (unfortunately or fortunately) out of the scope of this project. We aren't going to touch them... for now.

SGrabarczuk (WMF) (talk) 16:36, 27 April 2022 (UTC)

@SGrabarczuk (WMF) Thanks for your reply - very insightful that readers don't click these links. That completely changes my view. I'm pretty sure I fell for multiple different biases there.

Misaligned tabs in page history

This is a separate issue, but is the positioning of the tabs in the page history a bug or a feature? (see image right) AltoStev (talk) 00:17, 6 May 2022 (UTC)

@AltoStev, currently, the tabs should be displayed in the same place both in full width and in limited width. This will be changed, because people consider it more as a bug than a feature. Later, the design will be changed. See our newest prototype and the task on Phabricator: "Visual design & layout refinements". SGrabarczuk (WMF) (talk) 00:38, 6 May 2022 (UTC)

Concern with using logged in vs. logged out to determine sticky header design

Based on the most recent update on the sticky header feature, it seems that you plan to use whether a user is logged in or not as a proxy for whether they are a reader or an editor and which interface they should therefore be given. I understand the temptation to do this, but I think it's a fundamentally bad idea.

There is a large group of users who are logged in but do not identify as editors. This is good, since it allows them to customize their preferences, and it means that if they ever do decide to fix a typo or otherwise wade into editing, their edits will be associated with their identity, making it much easier to communicate with them and improving their newcomer experience (courtesy ping MMiller (WMF) for the Growth team). However, these users presumably do not want a ton of buttons for editing features, and if their first experience after creating an account is that they now suddenly have a ton of new buttons that clutter their interface and look like junk, that'll push them to just log back out.

I've long felt that we need to be much more deliberate about how we invite readers to become editors. In an ideal world, there would be a master user preference that could be toggled between "display no editing features", "display basic editing features" (e.g. the edit button; default for IPs), and "display advanced editing features" (e.g. the en-WP left sidebar tools section). As a more practical matter here, it's important that at minimum there be a preference option for users who don't want their user links to persist in the upper right as they scroll and that this be the default for non-autoconfirmed users.

There are so many ways in which the ideal experience for readers vs. editors differs, and the longer we keep using logged in vs. logged out as a cheap proxy rather than building a better system, the more debt will accrue and the more non-editing logged in users will be harmed. {{u|Sdkb}} ^talk 20:52, 22 December 2021 (UTC)

Hi @Sdkb -- thanks for the ping. I definitely see why newcomers came to mind as you were looking at the sticky header work. I'm following along closely with the progress, and I know that the Web team has newcomers in mind as they work on the desktop improvements project -- part of the objective is around helping readers intuitively understand how Wikipedia comes together so that some of them are driven be curious and learn more, and maybe participate themselves. I think that's part of a difficult balance you're touching on -- we know that the vast majority of readers will never edit, but we do want to make opportunities visible enough for those who might edit to try them out.

With respect to the actual sticky header work and their thinking about the different needs of readers and editors, @OVasileva (WMF) will be able to give you more details on the thinking and plans likely at the beginning of January once work ramps up again. MMiller (WMF) (talk) 21:04, 22 December 2021 (UTC)

Hi @Sdkb - thanks for your comment and questions. I too agree that we should move towards a more modular approach for individual features and needs, preferably by showing the user the interface options they are most likely to need. I see the sticky header as the beginning of this type of process - it collects many editing features in a way that is easier to understand and more accessible to newcomers. Another approach, as you pointed out, would be to create individual configurations for the sticky header and it's functionality. This is difficult technically as it requires the team to maintain many different versions of the page that we have to then test against when building out any new functionality. It also places a lot of pressure on the user to be able to identify where each setting lives and what its purpose is. However, we are currently discussing other potential options for configuration - for example, allowing individual users or entire wikis to be able to configure smaller portions of the sticky header via gadgets or a user preference (such as adding or removing links to functionality and features that are relevant to them). I'd love to hear your thoughts on this. Our hope is that it would be a more sustainable way to approach the question of configuration. OVasileva (WMF) (talk) 12:32, 4 January 2022 (UTC)

@OVasileva (WMF), thanks for the comment! I think that when left to the community, there's nearly always a significant bias for editor needs over reader needs. Logged in but non-editing users are a pretty much invisible group. That's part of why I think it's important to have something like the no/basic/advanced editing features toggle in the settings, since then when the community makes interface changes to benefit editors, we'd be doing so for ourselves, rather than for ourselves and also this other invisible group that might want something different. {{u|Sdkb}} ^talk 22:50, 4 January 2022 (UTC)

Unecessary "deadspace" on the sides of the site

Tracked in Phabricator
Task T306660

Example of "deadspace" on sides of article

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)

Could consider moving "Contents" from low on the left side to top of the right side to fill the empty space there. Or put "Contents" at the top on the left and move the other section to the right side. SabreWolfy (talk) 11:43, 15 May 2022 (UTC)

Yes @SabreWolfy, we will fill that empty space. We'll do that by separating links related to the entire wiki (like Recent changes) from the ones related to single pages (like Related changes), and move the latter menu to the right. If you're interested in the details, read the page about the Page tools feature. SGrabarczuk (WMF) (talk) 15:51, 16 May 2022 (UTC)

Sticky Header

How can I use this new feature in a third party wiki?

Reading/Web/Desktop Improvements/Features/Sticky Header --89.35.180.240 22:58, 24 December 2021 (UTC)

We'll have better third party support soon for the new Vector. We will be creating a new skin. Please track phab:T291098 to follow progress. Jdlrobson (talk) 23:58, 5 January 2022 (UTC)

TOC links don't work

Tracked in Phabricator
Task T307271

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 — Preceding unsigned comment added by Caarl 95 (talk • contribs) 20:23, 28 April 2022 (UTC)

Same, Chrome 101.0.4951.41 Spiros71 (talk) 17:07, 30 April 2022 (UTC)

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

Chrome 101 is not a Beta, but stable version. ValterVB (talk) 20:33, 30 April 2022 (UTC)

101 went from beta on April 26, 2022, so yes my information was based on the week before. We are working on a fix and possibly upstream bug report. Jdlrobson (talk) 17:36, 2 May 2022 (UTC)

This appears to have been fixed for me (Chrome 102.0.5005.22 beta). Tol (talk | contribs) @ 18:32, 3 May 2022 (UTC)

Checking in to let devs know the contents sidebar is working for me now (on Chrome 101.0.4951.54 (Official Build) (64-bit)). Tenryuu (talk) 16:07, 5 May 2022 (UTC)