Talk:Reading/Web/Desktop Improvements

Overview

Features

Repository

FAQ

Discussions: Desktop Improvements • Accessibility for reading. If you would like to follow our technical work closely, this is what we're doing now.

---

You can comment in any language. We are especially interested in:

• Feedback on the functionalities we have already deployed. (Please see Reading/Web/Accessibility for reading/Known issues before reporting bugs.)

• Expanding the list of existing gadgets and user scripts that are related to providing a better desktop experience.

We are discussing with many volunteers and communities at the same time. It may take some time for us to reply here. We apologize for that.

Thank you!

(Translate this page)

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)

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)

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)

Too narrow (again)

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

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)

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)

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

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)

Unecessary "deadspace" on the sides of the site

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

Please see Talk:Reading/Web/Desktop Improvements/Reading/Web/Desktop_Improvements/Features/Limiting_content_width. Jdlrobson (talk) 23:57, 5 January 2022 (UTC)

Example of "deadspace" on sides of article

Move other projects to the sticky header

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

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

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

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

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

Sticky Header won't switch between language versions

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

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

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

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

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

How to disable sticky headers?

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

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

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

@Bombenleger, @Akeosnhaoe, you need to add

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

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

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

Sticky header zero language switcher

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

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

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

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

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

Tracked in Phabricator
Task T298705

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

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

A problem of cache or someone else?

(from fr.wiki 1 and 2)

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

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

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

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

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

Sticky header: language switch button wraps on narrow screens

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

Tracked in Phabricator
Task T298887

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

Talk page and page history

Tracked in Phabricator
Task T299115

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

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

Hey @Nux!

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

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

Keyboard shortcut does not focus search field in sticky header

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

Scrolling by pages + sticky header scrolls too far

Steps to reproduce:

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

Expected results:

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

Actual results:

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

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

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

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

Page-title and Search

In a nutshell, I believe

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

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

Drop down menus

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

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

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

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

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

Nice to have: personalized background

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

Claims about the current interface

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

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

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

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

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

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

This is not an improvement

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

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

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

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

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

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

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

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

Thanks for the bug report.

Tracked in Phabricator
Task T300182

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

Feedback regarding the new language switcher

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

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

I hope this feature is not shipped to other languages, and France gets the sidebar back. If you want to make this feature more discoverable, maybe you could add a shortcut but keep the sidebar. Or display a tooltip once in a while to educate newcomers. But please, keep "heavy users" of language switching in consideration. Thanks — Preceding unsigned comment added by 77.148.113.166 (talk • contribs) 19:54, 25 January 2022‎

Some Feedback on Improved Desktop View

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

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

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

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

Bug: Sticky Header is printed

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

THanks for the report!

Tracked in Phabricator
Task T300178

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

Not at all suitable for Wikisource users

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

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

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

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

Tracked in Phabricator
Task T300563

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Live preview broken on 2010 wikitext editor

Tracked in Phabricator
Task T300814

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

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

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

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

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

Enable sticky header

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

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

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

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

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

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

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

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

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

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

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

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

Broken gadgets

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

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

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

Example at w:Georgetown University

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

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

Tracked in Phabricator
Task T281974

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

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

Language switching - speed, suggesion

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

Thank you @Greatder for this comment.

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

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

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

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

Hello Greatder,

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

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

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

Feedback on ToC functionality

Hello,

I’m not sure how far you are in the development of the new table of content functionality, but I was looking at this prototype and noticed a potential problem. Here the ToC is on the side and that’s a good thing, but the ToC in the text have also been deleted and that’s not much a good thing. When there is a big infobox, the in-text ToC compensate partly or totally for it, hence the page arrangement take it into consideration for the position of the images. Now if you delete it, all the text will go up, along with the images, but the images can’t always follow, because the infobox, so the right-aligned images are going to pile under it, while the left-aligned will reduce the text to a very small column between them and the infobox. On fr:wp, infoboxes are very widely used, so deleting the in-text ToC is going to break the page layout of most articles (and rather probably upset the community). So I’d suggest that, whatever you do with the ToC, to not delete the in-text ToC until there is also a functionality to move the infobox outside the text too (that would be great by the way, as infoboxes always cause difficulties with page layout). --Runi Gerardsen (talk) 09:30, 7 February 2022 (UTC)

Feedback on new language switcher in French

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

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

1- switching seamlessly from one language to another is precisely the one advantage Wikipedia has over any other encyclopedia and

2- my 32" monitor has plenty of space to display these links in the left column.

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

Hello @Herisson26. Thank you for asking here.

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

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

Hello @SGrabarczuk (WMF),

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

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

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

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

Tracked in Phabricator
Task T302031

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

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

Patsagorn Y. (Talk)

07:51, 8 February 2022 (UTC)

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

TOC Feedback

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

Default image thumb size?

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

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

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

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

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

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

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

La nueva interfaz es muy incomoda de usar.

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

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

How do I go back to full width?

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

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

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

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

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

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

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

Copied from Topic:Wqeyb0m05zkmeemb

Well, I have a few questions:

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

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

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

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

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

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

Inter-language links

Tracked in Phabricator
Task T289840

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

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

The empty TOC box

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

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

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

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

Sticky header in the namespace Project

(original discussion in French)

Hi,

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

Unable to switch back to Vector Legacy skin

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

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

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

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

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

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

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

Left margin menu pushes down content

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

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

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

–LPfi (talk) 20:07, 17 March 2022 (UTC)

Let's talk about our latest prototype and next steps

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

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

Agenda

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

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

Questions I shouldn't need to ask

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

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

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

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

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

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

How is the progress of 2 phabricator tasks?

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

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

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

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

@SGrabarczuk (WMF) First ok.

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

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

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

(From French Wiktionary)

Tracked in Phabricator
Task T293395

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

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

Keep the sidebar collapsed as default

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

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

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

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

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

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

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

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

More visibility for Wikimedia and Wikidata

Based on (BTW, nie job, congrats!)

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

I strongly suggest

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

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

Finally, I suggest

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

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

Thx for your work and your attention

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

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

Thank you @AnBuKu for your appreciation.

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

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

Search box shortcut key

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

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

Unsurprisingly

This feels like one more attack on “power users”, from all fronts. The newspeak and weasel words noted. Makes it increasingly easy to dispise and abhorr all of you and your makework. Tuvalkin (talk) 12:12, 7 April 2022 (UTC)