Talk:Reading/Web/Desktop Improvements

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

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


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

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

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

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

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

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

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

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

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

A question
Do you have any plan to make vector skin mobile responsive? I use this code to do this-  Yahya (talk) 09:07, 11 November 2021 (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)

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)

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)

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)
 * 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 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. &#123;{u&#124; Sdkb  }&#125;  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)

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

Sticky Header
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)

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)



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) next to languages, for several reasons: Also, I would be in favor of including Wikidata links to this tab, which are placed separately on many projects.
 * above all, it would allow easier and more comfortable access;
 * it would also allow consistency with the languages tab, since it was moved;
 * compared to Wikipedia, sister projects are often not highlighted enough and this new spot would also make it possible to better recommend them to readers;
 * many projects have tried to better highlight the other projects with “frame” templates at the bottom of the page (example: ), which create duplicates, are visually heavy-looking, and often shift the layout. Thus, such a new tab in the sticky header would allow to remove a certain number of these templates and improve the global rendering.

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