Talk:Reading/Web/Desktop Improvements/Archive2

Typo?

At Reading/Web/Desktop Improvements#Deployment plan and timeline the majority of wikis ... only editors can opt-in using Switch to old look in the sidebar (emphasis added) — should that be "opt in using switch to new look"? Pelagic (talk) 18:06, 20 July 2020 (UTC)

@Pelagic - good catch! Now fixed. To clarify, we're not adding a specific link when opting in but the preference is available in the appearance tab of user preferences OVasileva (WMF) (talk) 12:41, 22 July 2020 (UTC)

First impressions when deployed at euwiki

Hello! Today it was deployed at euwiki and I want to share some first impressions about what I have seen.

• The design is something in between nothing. No real change, only some minor "improvements", so everything looks broken.
• We have lot of pages using PAGEBANNER. You can see it at eu:Txikipedia:Ornodun or at eu:Laguntza:Sarrera. The feel is very bad, because it doesn't take all the wide BUT you know it should be wider because the top menu is wider.
• Many things are going out from the right. Look at eu:Txikipedia:Azala or eu:Txikipedia:Ornodun
• As the article reading box has disappeared, lot of things look "hanged-out" from nowhere. You can see it for example at eu:Ugaztun how the globalnotice, sitenotice and page-related icons (i.e. featured article) are taking a lot of space. If you read a very short article (eu:Fisiopatologia) this is further evident. The article content is less clear.
• The footer (including categories) should be sitewide. Is not part of the article, is part of the infrastructure.
• The sister projects links are now completely forgotten, making Wikimedia projects even less important. If you are trying to hide them from the sidebar they SHOULD be somewhere in the top of the page. THIS IS VITAL, is not something about esthetics, is something about WHO WE ARE and our Strategic Goals.
• Top tabs are too crowded. This can't be the solution. It is so small area that the history tab is merged with the "Other" tabs. Loot at eu:Ugaztun.
• Top tabs still have the "old look" and are now weird.
• In our case, Txikipedia has its own logo. It should appear in every page, instead of the Wikipedia logo. This was changed using css, so it must be reflected.
• There is more margin in the right that in the left. Not centering the content is something that will make people mad.
• Special pages are a mess. Full width, top tab not aligned...
• When editing a page with new code editor, things are not well aligned in the right side.

These is my first feedback. -Theklan (talk) 15:14, 22 July 2020 (UTC)

Some other improvements that could make this better:

• images and infoboxes can break the layout from the right, so there's more space for text and this items are presented in a more relevant way.
• when the sidebar is collapsed, image galleries may have full width, instead of being constrained to the fixed-width layout.
• Categories layout is really poor. The fixed width limits the columns to two, and it makes it worst for having a global picture.

-Theklan (talk) 16:02, 22 July 2020 (UTC)

Hey @Theklan, thank you for your detailed feedback. We appreciate you taking the time to investigate the changes and we hope you will continue to give feedback as the project progresses. As you may know this is the first of many deployments. I will do my best to reply to the concerns you've raised:

1. PAGEBANNER issues — in this case I think some clarification is needed. I looked at the pages you linked but am not understanding what the issue is. Can you please clarify?

   The problem here is that PAGEBANNER took all over the wide of the page (well, not the sidebar), and this is cool. Now it is constrained to a very fixed space. PAGEBANNER may be a good solution when the sticky top-menu is deployed to show below it, but with the current configuration it is not more "part of the page" but "part of the text". Consider thinking on making it sitewide, the result will be better.

2. Many things are going out from the right — ah yes, I see what you mean here. As far as I can tell this was already an issue for all users with screens smaller than ~1200px. If you look at those pages using Legacy Vector (eu:Txikipedia:Ornodun or eu:Txikipedia:Azala), and make your screen size smaller you will see the same issue. So I think in this case we should work on improving the flexibility of the content such that all users, regardless of their screen size or skin choice, can have a good experience.

   I have to work also on this kind of things, some of them can be worked (Txikipedia:Azala is one of them). Also, I think Main Pages shouldn't have the same "content" mood and they should be wider.

3. things look "hanged-out" from nowhere – if I understand this correctly you are commenting upon the lack of some sort've frame around the content. Later in the project we are planning to focus on visual design and part of that will include thinking about how to frame the content.

   Yes, the frame issue. Well, it can help now to have a small line.

4. the footer should be sitewide – we agree. As you can see in this prototype (link to prototype) that was the intended design. We are currently struggling with some DOM ordering issues that make this difficult to implement, but we will keep trying.
5. sister project links – there are two separate issues here. Firstly we made a mistake in our deployment: for logged-in users the sidebar should be open by default, so those links will remain right there. For logged-out users the sidebar will be collapsed by default. However the data shows us that those links get clicked very rarely (link to data). So it would seem that we need better design solutions to expose those projects to people if we want them to engage with them. The sidebar links aren't quite working.

   They are not working, and now they will work less, because they are hidden by default. The more I think about this, the more I see that they should go below the page title, but hiding them is just worst than not being pretty/evident.

6. Top tabs are too crowded – this will be resolved soon once we move the search bar into the site header (link to prototype) (see this page for more details - link)
7. tabs look weird/old – this will be addressed later on in the project with the visual design portion
8. Txikipedia logo – what a cool feature, I am sorry that we have temporarily broke it. Are you in touch with the developers who worked on that feature? I think it would be possible for them to chat with one of the developers on our team to figure out how to get that logo back.

   I was the developer. I will do it!

9. There is more margin in the right that in the left - if you collapse the sidebar the content is centered. If the sidebar is open the content is offset to the right, same as it currently is in Legacy Vector (it is just more noticeable now since we're not filling that space in with gray). We did consider making the sidebar sticky (link to prototype) to make better use of that space, but have decided to defer that until later. The good news is that with the new layout you can collapse the sidebar, thus gaining more space for content on smaller screens.
10. Special pages are a mess – yes, the situation is certainly not ideal at the moment. We wanted to allow Special Pages (in particular log-type pages) to be wider than regular pages, however we thought it would be best if the tabs stayed in place, making it easier to navigate between Article and History, for example. You can read more about our thinking regarding Special Pages here (link to page). If you have any ideas for how to improve this situation that would be great.

    Categories, special pages and code pages can be wider, because they are not intented to be read.

11. New code editor, things are not well aligned on the right – can you clarify what you mean here? Perhaps a screenshot would help.

    The "Publish changes..." button right-limit goes some pixels to the right of the search bar.

AHollender (WMF) (talk) 12:38, 24 July 2020 (UTC)

-Theklan (talk) 21:56, 27 July 2020 (UTC)

@Theklan - re: fixing the Txikipedia logo - not sure if this helpful but one of our developers put together some information on the logos and how to update them. OVasileva (WMF) (talk) 13:56, 29 July 2020 (UTC)

Irrelevant radiobox

Hi. There is a bug on global preferences, two radioboxes for legacy vector. IKhitron (talk) 01:22, 24 July 2020 (UTC)

@IKhitron - thank you for the feedback! We are aware of this bug and have been tracking this in phab:T258581. Hope to have a fix within the next couple of weeks. OVasileva (WMF) (talk) 11:04, 24 July 2020 (UTC)

Thank you for your answer, OVasileva. Here is another one: global preferences do not do anything in this case, you can change the legacy vector preference in local wiki only. IKhitron (talk) 11:43, 24 July 2020 (UTC)

Seems to be this one: phab:T258493. Stryn (talk) 07:39, 25 July 2020 (UTC)

Painful interwikis (dis)order

Tracked in Phabricator
Task T257625

I like the new look, but looking for the article in a different language is a pain. The interwikis on the left used to follow the alphabetical order, but now it is an absolute disorder, it takes me too much time to find the interwiki for a given language. --Xabier Armendaritz (talk) 10:28, 24 July 2020 (UTC)

@Xabier Armendaritz - thanks for reporting this! Do you have a screenshot of this issue by any chance? This sounds like a bug - the changes within the project so far did not include any interaction with the interwiki links, so the expectation is that the order of links should not have changed in any way. As a sidenote - we are currently planning on moving the interwiki links to a more convenient location at the top of the page as well - more info on that can be found on the features page: see language switching 1, and language switching 2. OVasileva (WMF) (talk) 14:38, 24 July 2020 (UTC)

@Xabier Armendaritz and OVasileva (WMF): This is a known bug, and is not related to Desktop Improvements (it’s broken in old Vector as well). It’s tracked in phab:T257625. —Tacsipacsi (talk) 15:05, 24 July 2020 (UTC)

Vector2

Can we please not retroactively rename Vector as "Vector Legacy"? There's years' worth of documentation and discussion that mentions Vector, and you want to say "from 2020 'Vector' now means something else". Just find a new name for the new thing, even if it's as straightforward as "Vector 2". Don't confuse things by usurping the old name. —Pelagic (talk) 16:15, 24 July 2020 (UTC)

+1. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:21, 27 July 2020 (UTC)

Hi @Pelagic, @Pigsonthewing. Thank you for the feedback! When we first began this project, we had a decision to make - build a new skin or improve our current one. For technical and maintenance reasons (for more details, see our FAQ), we settled on the latter. This means that rather than a new version of Vector (with a different name), what we are building is improved functionality for Vector itself. We’ll be building these features over the course of the next 1-1.5 years. Technically, this is similar to previous features or projects that were added to Vector such as page previews, with the only difference that, this time around, there will be more of them. We chose the language of “Legacy Vector” because it signifies Vector skin as it was prior to us beginning this project. Does that make sense? OVasileva (WMF) (talk) 12:14, 28 July 2020 (UTC)

It makes sense, in that I understand what you're saying. But I don't agree that its a good course of action; as Pelagic says, this will sow confusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 28 July 2020 (UTC)

Отзыв

Довольно интересная и долгожданная идея.

Замечание: как вы можете заметить здесь с 150% масштабом, при скрытии и раскрытии текст статьи скачет по горизонтали. Это нехорошо для людей, которым желательно использовать такой масштаб страниц из-за проблем со зрением.

Комментарий: при использовании очень полезных скриптов часть из них формирует новые табы рядом с табами править/править код/история. В результате их становится больше и они ломают верхний блок, налезая на название страницы. Наглядно, см. скрин скрин. Либо нужно переписывать все скрипты, либо как-то сохранить предыдущий размер верхней полосы, чтобы он не ломался от дополнительных 2-3 табов.

ПС: Кстати, при 150% масштабе вторая проблема исчезает) Ailbeve (talk) 11:41, 27 July 2020 (UTC)

Hello @Ailbeve, thank you for your feedback. Regarding the tabs above the article title: soon we will be moving the search bar to the header which will open up space for the tabs. This should fix the issue you described. Please see this page for mockups: link to page, or you can view a prototype of this feature here: link to prototype. AHollender (WMF) (talk) 15:03, 27 July 2020 (UTC)

Why limit width of content?

".skin-vector-max-width .mw-content-container { max-width: 960px; }": I have 2K screen and content takes less than half of my screen :( Most Main Pages use two column design, so they look epecially trashy. --AS (talk) 14:41, 27 July 2020 (UTC)

Hey @AS, thanks for your question. The reason for limiting the content width is to provide a more comfortable reading experience. We've written a bit about our research and thinking here: Introducing a max-width. AHollender (WMF) (talk) 15:03, 27 July 2020 (UTC)

I came here to ask the same thing. With this answer, I'll switch from Vector to Timeless. Ainali (talk) 15:20, 27 July 2020 (UTC)

Strewth. "mw-content-container {max-width: 960px;" That is horrible. Please reassure us that legacy Vector will continue to be available and Vector 2 will be an extra choice. — GhostInTheMachine ^{talk to me} 17:23, 27 July 2020 (UTC)

Why is this in px and not em? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:20, 27 July 2020 (UTC)

Thanks for the response above AHollender (WMF). Would the team perhaps consider adding an easy preference opt-out for the max-width? I can play around with CSS and pick it apart, but it'd be a whole lot easier to just have a preference for it, seeing as this seems likely to be a pain point for many users who are creating content rather than reading it. I've just tried the new Desktop Improvements on enwiki for the first time, and it was the first thing that immediately stood out to me as a "nope, don't like this" of the new theme. I like a lot of things about it - the new sidebar hiding and background look swanky! Naypta (talk) 18:49, 27 July 2020 (UTC)

Naypta thanks for checking it out and providing your thoughts here. I hope you will continue to follow the project and provide feedback. I agree that the limitation on the width of the content is going to be a pain point for many users, which makes it a difficult choice (and undoubtedly will be the reason why many editors will opt-out). I suspect that a full-width gadget or user script will emerge soon. One point however that I think is worth considering is this: there is extensive research showing that shorter line lengths provide a more comfortable reading experience and allow readers to comprehend and retain information better. It is the reason why so many major information websites follow a similar layout. While we still plan to conduct additional research, it seems like we can have relatively high confidence that this layout makes sense for the majority of users. Now if editors start using a layout with a different max-width (or no max-width at all), when editing articles they will not be seeing the same thing that readers will see when reading the articles. I don't know that this is inherently bad, but my inclination is that the closer the editing experience is to the reading experience, the better the articles will read. As you probably already know there are plenty of templates that break at small screen sizes, and I suspect part of the reason for this is because some editors have large monitors, and therefore these templates are not being tested at smaller screen sizes. So I guess in short: we fully support people being able to adjust the density/width of the content, but at the same time we wonder if there might be some tradeoffs to consider in terms of consistency between what is written and what is read. AHollender (WMF) (talk) 21:27, 27 July 2020 (UTC)

This really is sub-optimal for sites where you have to read a lot. Even sites with a lot of content that have a fixed max-width for the main element, have other elements that take up the space or simply, have less content. With Wikipedia pages, it's just empty, a white void with literally no use, surrounding tons of text. Someone on a 1800p display will have ~50% of their display just being empty! I am aware that fixed-width brings better readability but you're not really considering all the use-cases here, and the assumption that a consistent experience is equal to a better experience is false equivalence at best. --QEDK (talk 桜 enwiki) 21:51, 27 July 2020 (UTC)

I suddenly realize how long my (or some other users') paragraphs on discussion pages are. I'm not yet certain if that's a good thing. Nevertheless, it reduces the number of reasonably usable indentation levels, which might really be a problem on noticeboards. ToBeFree (talk) 00:55, 28 July 2020 (UTC)

Okay, it's not just discussion pages. I need a wide screen for en:WP:AIV, ideally one line per request, or it becomes hard to manage during busy times. ToBeFree (talk) 00:58, 28 July 2020 (UTC)

After some days of having this at euwiki, I must say that the reading experience is much better. Discussions, special pages and categories must be improved, but articles are now easier to read, especially in wide screens (you don't need to move the head). -Theklan (talk) 11:23, 28 July 2020 (UTC)

I also find the limiting width a bad move. I would understand if it was larger, but here it make the pages shrinkened for a even a normal sized screen, which mean way less content on a single page with large empty bands on either sides, and force to scroll more and more for the same content. Not to mention that in lots of pages the very small width forces left and right sided pictures way too close, making the amount of text on a single page even more diminished. I hope it will be changed for a larger one.--Aréat (talk) 16:31, 5 August 2020 (UTC)

The fixed format will ensure a more coherent design since every contributor will see how the images fit into the page. This decision was long overdue.--Codex (talk) 19:34, 5 August 2020 (UTC)

Preventing people, like this, from increasing the width of content, and deciding in their stead what is "a comfortable reading experience" is "paternalistic" : Paternalism is action that limits a person's or group's liberty or autonomy and is intended to promote their own good. Paternalism can also imply that the behavior is against or regardless of the will of a person, or also that the behavior expresses an attitude of superiority. This width limit results into the creation of big empty spaces on the right and left parts of the screen. These spaces being of white color, they are dazzling. I would not be surprised if further research reached the conclusion that this is tiring for the eyes, harmful for the eyes, harming visual attention, resulting into a not more but less comfortable reading experience. Being an encyclopedia, Wikipedia is a reference tool. At times it is something you may want to read like a book, at times you just browse it to look for a specific information, like a name, a date, a mathematical formula, etc. Typically, when you need to remind yourself something you used to know but later forgot. I am not convinced that wasting screen space is the best way to do so. Whenever, for some reason, I want to restrict text width, I do so either by resizing the window, or by using Firefox's reading tool which I can adjust with my own preferences ( https://support.mozilla.org/en-US/kb/firefox-reader-view-clutter-free-web-pages ). Theo F (talk) 05:52, 6 August 2020 (UTC)

There are already some pages using column layout, in particular the title pages of each language Wikis. The columns being squashed by the width limitation look especially surprising. The need of scrolling for reading distracts way more than even blank borders around, and definitely more than just long lines. Maybe Wikipedia should adopt a long-standing practice of scientific articles? For the ease of reading, A4-page there is divided into two columns, and you don't need to turn pages twice as often, nor do you question yourself why half of the space is blank. In any case I strongly suggest that maximum width are an adjustable setting with an option to use a browser client window width. Глюкавый (talk) 10:28, 6 August 2020 (UTC)

The sidebar and alignment problems

The hide-sidebar I think is a good idea, but for me the opened sidebar looks broken now. The border would make this look better (sharper).

The whole layout with new sidebar and logo looks broken because nothing seems to aligns there:

• The logo partially overlays top menu (if window is short or you have many tools there).
• There is weird white padding between sidebar and content. And that margin doesn't equal to the one n the right.
• Content is not aligned with top menu, nor with the logo.

For me the logo with text is just too long and this is causing problems. I think this just doesn't work with this layout. It just looks out of place. I've seen various non-standard layouts e.g. of Jen Simmons that just work together. Vector2 just don't seem to work together. Sorry.

One more thing. You could maybe make the new logo work if you move it out completely from the sidebar space to top (over top menu). Maybe also put the search bar on top as well. That would work much better for thin windows as you would see more article-actions (page history etc). Also the search-bar would be wider. I think the whole point of moving search bar from sidebar (old monobook) to the right (1st Vector) was to make the search bar wider. --Nux (talk) 22:26, 27 July 2020 (UTC)

PS: BTW. If you move the logo out of the sidebar you can make the hamburger a bit smaller. You can also put the "menu" word in there. There are studies that show that the hamburger icon is not universally recognized (probably even more of a case for the arrows). With menu word it would make more sense. --Nux (talk) 23:00, 27 July 2020 (UTC)

@Nux thank you for taking the time to look through the updated interface and provide detailed comments. I'm not sure if we've done a good job communicating this to people but this update is the first of many. As you've noted there are many different elements to consider on the page, and they all have a relationship to each other. As the project progresses things will fall into place more, and we will restore some of the harmony that we've temporarily lost. For example two of the next updates will be: moving the search bar into the header, and collapsing the user links into a menu. With these changes the top portion of the page will look more organized and clean. One of the biggest challenges for us is finding the right sequence to release the updates, because we know there is bound to be some weird states in between. I encourage you to take a look at our features page, as well as this page with some of our more bold ideas. I will also be working to try and communicate our future plans more clearly, such that people can more easily understand our plans.

@AHollender (WMF), thanks for the information. I've seen previous experiments and assumed this layout won. --Nux (talk) 19:27, 30 July 2020 (UTC)

I think I understand some of your ideas, and appreciate you taking the time to write them up. Would you be able to create some sort've sketch or mockup? I think it would be great to have that more as part of our culture when discussing interfaces. Cheers AHollender (WMF) (talk) 13:42, 30 July 2020 (UTC)

Below is a sketch of something I was thinking about. Unfortunately I don't have my mouse on vacation so this is a bit rough and one size only.

Layout with top logo (and search) for early Vector2

1st sketch

gradient (like tabs)

When collapsed the sidebar and the menu-toggle button could be shrank with some animation maybe. Or maybe just don't use border for the button... Not really happy with how that button turned out. I'm sure a graphic designer will be able to figure something nice for that 🙂. In terms of a role it's a button, but it does looks better without a border and with a blue text color (like for links).

Back to the alignment problem... Note that in terms of alignment I kept the personal bar aligned to right to make it feel out of the article space (as it is not related to the article obviously). I also purposefully kept it aligned vertically to the left menu button (as they are both more or less about a generic navigation). Oh and the search bar is not stretched to full width, but I guess you could stretch it a bit more.

BTW. I don't think that collapsing the personal bar is needed. By default that menu is quite short and clean by itself and power users tend to keep important links in there (I remember this was a quite popular place for enhancements). So at least for me collapsing p-personal would not be a desired feature.

Cheers, Nux (talk) 19:27, 30 July 2020 (UTC)

Added a gradient version that looks more like article tabs so should be more obvious. Also X (cross) for closing is more standard. The cross -> hamburger animations are quite popular from a few years I think e.g.: [1]. --Nux (talk) 18:52, 31 July 2020 (UTC) PS: I also changed the bell icon which seems not to conform to WCAG AA, but the human-user icon conforms to WCAG AAA.

Oh, also note that the content in my version is centred to the remaining space (excluding sidebar). Otherwise with sidebar opened content feels weirdly aligned to the left. I did a brief UX test on another user and the weird left alignment was the first thing she noticed and mentioned (without me saying anything about it and just asking which version she likes best). She also didn't have problems finding the search box (even though it was on top and on the left). --Nux (talk) 18:52, 31 July 2020 (UTC)

@Nux Sorry for being slow in following up here. I've also experimented with different options for the sidebar menu open/close button. I agree that having a hamburger menu in the header isn't necessarily the most clear, though I do think it's worth noting that many websites do it. And I don't think it's unclear enough to be problematic. Not a perfect solution by any means but probably good enough. Regarding your sketches, I think the challenge is where to put the Menu button when the sidebar is collapsed. I've attached an image below to show the previous solution I was considering. Also, regarding the sidebar always remaining fixed to the side of the screen, on wide screens this means there's a large gap between the sidebar and the content. AHollender (WMF) (talk) 19:43, 21 August 2020 (UTC)

floating menu tab

Sidebar is not hideable for thin windows

Seems like there is a z-index problem. The sidebar toggle button is in `.mw-header` which is `z-index:1`. And `#p-personal` is `z-index:100`. So this makes the toggle button unclickable. You must make the window thin enough (or have a lot of actions in `#p-personal` like me). --Nux (talk) 22:44, 27 July 2020 (UTC)

@Nux - thanks for letting us know! I think this is the same bug as phab:T258465, which we're hoping to fix soon. Let us know if not and we can open a new task. OVasileva (WMF) (talk) 12:17, 28 July 2020 (UTC)

@User:OVasileva (WMF), yeap, that looks to be exactly the same problem. Thanks. Top toolbar is wrapping to next line for me as well. --Nux (talk) 17:05, 28 July 2020 (UTC)

Vector 2.0 whitespace issues

At least on my screen (Firefox 78 for Mac, 1280x800 display, OS X Dock on the right side), there are some whitespace issues with Vector 2.0:

1. Compared to Vector, there is an extra centimeter of whitespace between the sidebar items on the left and the page body text. It looks like a weird void.
2. I see almost a centimeter of extra, unwanted whitespace on the right side of the body text.
3. I see about half a centimeter of new, unwanted whitespace between the links at the top right (talk, prefs, etc.) and the search box.
4. Hiding the sidebar with the back arrow that is not a back arrow does not make the content wider; it just shifts it to the left. Why would I hide it?

The combination of these things moves the body of the text, which is the thing I most want to see, down by two or three lines, off the bottom of my screen. Please fix. Jonesey95 (talk) 00:07, 28 July 2020 (UTC)

One more bug

A lot of people are complaining since today that the new design was turned on without any action from their side. IKhitron (talk) 14:06, 28 July 2020 (UTC)

@IKhitron - Do you know which wikis this is coming from? For a set of early adopter wikis, we are turning the design on by default as per community consultations and approval on those individual wikis. Currently, the changes should be available by default for euwiki, hewiki, fawiki, frwiktionary, and ptwikiversity. The changes can be turned off via a link in the left menu or by going to user preferences. OVasileva (WMF) (talk) 14:43, 28 July 2020 (UTC)

I see. Hewiki. Well, all of them do not like the new design, because of a lot of empty space. I've published a css code that removes this space, but they are right, noone should suffer without asking this. Maybe you needed to start a discusdion with community, weeks before the cgangd, explaining exzctly what changes will be done. For example, I still do not know the full list of changes, only what I can see. I'm affraid that this situation will lead to demand to remove the wiki from the list.

Errores y sugerencias

Sorry for write in Spanish, I didn't speak English good

He activado la opción en las preferencias de la wiki en español y gallego (no funciona como preferencia global, pero ya lo han dicho arriba) y he detectado varios errores:

• En las páginas especiales (incluido historial) no funciona el límite de ancho.
• El enlace "(revertir)" de los diffs no deja un resumen de edición predeterminado.
• El cuadro de búsqueda se mueve un poco a la izquierda en las páginas especiales.

Y dejo como sugerencias:

• Hay un triple salto de línea al final de la página. Además, la línea de separación es gris, lo que hace que el "footer" parezca parte de la página:

Fin de la página/End of the page.

---

This page was last edited on 22 December 2024, at 05:33.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.

Debería aparecer sin los saltos de línea y con la línea en azul para que se vea claramente que es el fin de la página:

Fin de la página/End of the page. ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── This page was last edited on 22 December 2024, at 05:33.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.

• El contenido de la página es muy estrecho y hay mucho margen. Eso hace que ciertos gráficos y tablas se salen de la pantalla. (ejemplo 1, ejemplo 2, entre otros) Debería cambiarse el ancho de 960px a 1075px (por lo menos a 1060 px). Yo lo he configurado así en mi common.css en español y gallego (que es donde tengo activada la opción) y se lee mejor. USI2020 (talk) 17:58, 28 July 2020 (UTC)

Hola @USI2020, gracias por tus comentarios!

Primero, disculpas porque mi Castellano tampoco es muy bueno :)

• • Unas respuestas y pensamientos:
    • En las páginas especiales (incluido historial) no funciona el límite de ancho:
      • Generalmente, las páginas especiales no se leen de arriba a abajo como el texto de un artículo - se miran más rápidamente, así que necesitamos un diseño que permita este uso.  Pensamos que es mejor tener el ancho completo y que eso facilitaría la lectura mas rápida de la información de este tipo (similar a un spreadsheet de Excel)
    • El enlace "(revertir)" de los diffs no deja un resumen de edición predeterminado.
      • Tienes una captura de pantalla aquí? Creo que esto no está relacionado con nuestros cambios, pero necesitaría más información para confirmar.

No tengo, pero para comprobarlo basta con ir a un diff al azar y presionar revertir sin guardar los cambios. El resumen de edición queda vacío. Si pruebas a hacerlo con esto desactivado deja el mensaje en Mediawiki:Revertpage: «Reverted edits by $2 (talk) to last version by $1» USI2020 (talk) 10:32, 29 July 2020 (UTC)

• • • El cuadro de búsqueda se mueve un poco a la izquierda en las páginas especiales.
      • Esto si que es nuestra culpa. Ahora estamos moviendo el cuadro de búsqueda un poco más arriba en la página y esto resolverá este problema. Puedes leer más sobre esto aquí: phab:T249363.  Este cambio debería estar listo en más o menos dos semanas.
    • Sobre el final de la pagina:
      • También estamos trabajando en esto: nuestro plan inicial era que la parte del final también fuera gris (como en el diseño anterior), pero eso era técnicamente un poco complicado. Actualmente estamos discutiendo nuestras opciones aquí. Este cambio podría necesitar un poco más de tiempo, tal vez un mes más o menos. OVasileva (WMF) (talk) 10:11, 29 July 2020 (UTC)

A Bug with the desktop improvements mode

Hai, I experienced a bug when enabled the new desktop improvements. I don't know whether it is a bug or my mistake. I am posting screenshots of this thing.The problem is the content is limited to a small with area. As you can see in the screenshot on the left side the contents box coming right side images are coming and the text in the article is shrinked to a small area of 350px wide. So the thing endup like in the screenshot at phabricator task.I am using Firefox 78 on Fedora 32 with KDE Plasma 5.19.3 I don't know how to fix this. If anybody know the solution plz help.Ranjithsiji (talk) 13:33, 29 July 2020 (UTC)

Main Page

Hi! A small suggestion, I think the Main Page should be full width as is the case with some namespaces.--Ghybu (talk) 16:41, 5 August 2020 (UTC)

Noted, we'll discuss this. Thank you, @Ghybu! SGrabarczuk (WMF) (talk) 16:54, 5 August 2020 (UTC)

Keep large pages when source editing

Hello, At first I was surprised by the new presentation. Now I admit that it makes wikipedia easier to read, just like a LateX file. However, would it be possible to keep the full screen when editing a page with the code editor? I think it's a shame to lose space in that mode.

Thanks. --Le Petit Chat (talk) 16:56, 5 August 2020 (UTC)

@Le Petit Chat, thank you for this idea. We will take a closer look. SGrabarczuk (WMF) (talk) 14:08, 11 August 2020 (UTC)

Logo no longer localized with legacy vector turned off

I went to el.wikipedia.org and turned off legacy vector in the user preferences. The logo in the upper left used to have the Greek name "Βικιπαίδεια" but now it has the English name "Wikipedia". This is very disconcerting, can it be set back somehow? I would like to keep the rest of the changes to see how I like them. Thanks! -- ArielGlenn (talk) 05:19, 6 August 2020 (UTC)

@ArielGlenn - Thanks for your feedback! This is temporary. We are currently working on getting all of the new logos ready across all wikis. We're hoping to add elwiki to phab:T258552, which means it should have the new logo localized within the next couple of weeks. OVasileva (WMF) (talk) 07:08, 6 August 2020 (UTC)

New text width slightly too narrow

Not a bad idea to have set a limit to page widths for large screens, however the current text width for the French Wikipedia looks too narrow, as even a 12.4" display with a 1366 x 768 resolution leaves 15% empty stripes on each side, and makes images and tables collide into each other on scientific pages. The standard width should not be narrower than most common laptop displays, otherwise too many pages will need significant rework, which might be done for TV shows or videogames, but will be very unlikely for molecular biology or nuclear physics. This change will hardly be applicable to the German Wikipedia anyway: look at the average size of German infoboxes!

In addition, the edition window should not be constrained: I support previous comment that we should be able to enjoy a large screen when we have one!

Thank you,
Bob Saint Clar (talk) 05:21, 6 August 2020 (UTC)

@Bob Saint Clar - thank you for your feedback! We just wrote a little bit more about our rationalization on choosing this particular width for text - please check our our FAQ as well as the limited content width page. That said, we do want to explore better ways of displaying non-text content such as larger tables and are hoping on iterating on this in the future. For editing, we are considering moving the source editor to full width. For visual editing, however, we think that having a standard size for readers and editors despite screen sizes is a benefit. It will allow editors to see the exact way people will read the content afterwards, which can lead to better formatting across all content. OVasileva (WMF) (talk) 11:31, 13 August 2020 (UTC)

Nouveau style (Wikipédia Fr)

Personnellement, je trouve que la récente mise à jour du style de Wikipédia n'est pas nécessaire, car elle ne présente aucune utilité indiscutable. Je reconnais l'effort envisagé pour pouvoir replier le menu, mais je ne trouvais pas celui-ci gênant. Cela n'a donc rien ajouté à l'aspect pratique de l'encyclopédie (ça a d'ailleurs plutôt enlevé des choses : par exemple, le nouveau CSS ne s'adapte pas aux dimensions de mon écran, ce qui fait que j'ai une marge inutile à droite quand je ne replie pas le menu). De plus, l'icône du site s'y trouve rétrécie, mais cela me dérange moins. Pour moi, cette modification est à revoir. --Hérisson grognon (talk) 09:20, 6 August 2020 (UTC)

Bonjour. Si l’idée de départ est intéressante (réduire la longueur des lignes pour améliorer la lisibilité), la mise en œuvre est décevante et ressemble à la version pour mobile. Sur un écran large 16/9 de 27 pouces, maintenant courant pour un pc de bureau, on se retrouve avec deux marges blanches et la largeur utile est réduite à 1050 pixels (sur 1920). Wikipédia devrait-il être optimisé pour lecture sur un écran de 15 pouces ? Dans le cas d’un écran large, on est conduit à réduire la largeur de la fenêtre pour visualiser Wikipédia. La réduction de la longueur des lignes aurait dû être accompagnée d’une réflexion sur la mise en page. Il serait possible d’employer utilement les marges pour y placer par exemple le sommaire, l’Infobox, les illustrations, les notes et références... En l’état la nouvelle mise en page n’est pas un progrès. Il serait intéressant de compter les utilisateurs qui, comme moi, ont immédiatement modifié leurs préférences pour retrouver l’ancienne mise en page. Cordialement.--Philippesalv (talk) 11:30, 6 August 2020 (UTC)

"Il serait intéressant de compter les utilisateurs qui, comme moi, ont immédiatement modifié leurs préférences pour retrouver l’ancienne mise en page." Yes, it could be interesting. Patriccck (talk) 11:42, 6 August 2020 (UTC)

Utiliser l'ancienne version de Vector (Use the old version of Vector) — DePlusJean (talk) 19:33, 6 August 2020 (UTC)

Bonjour. Cool, j'apprends que les utilisateurs enregistrés peuvent revenir à l'ancienne version. Et pour les millions d'autres qui, simples lecteurs, n'ont jamais à s'enregistrer, même pas un petit cookie pour stocker une préférence de cet ordre ? Ou alors ils n'ont qu'à dire amen aux modifications cosmétiques et la fermer (si c'est ça la philosophie Wikipédia, bien sûr) ? Cordialement, Xavier 90.6.243.101 12:07, 7 August 2020 (UTC)

Je préfère également l'ancienne présentation. L'actuelle ressemble à celle de la version pour mobiles. Je trouve la colonne de gauche (Accueil, Portails thématiques, Article au hasard, Contact, etc.) trop claire (insuffisamment grisée) ce qui rend la page éblouissante. Lorsque je clique afin de la masquer, la zone d'affichage du texte ne rélargit pas, la largeur de la marge de droite augmentant d'autant que celle de gauche se réduit. Cordialement, Olimparis (6 août 2020).

Je suis retourné sur "l'ancien" vector. Ahhhhh j'ai de nouveau une page commplete, et pas 2 bandes blanches immondes. Vivi-1 (talk) 08:24, 10 August 2020 (UTC)

Hello — please excuse my message in English. I understand that the amount of whitespace on the screen can feel frustrating or even make the page look broken at first. My request is that you give it a chance — maybe a few weeks even, before you come to a conclusion about whether or not it's a good idea. The content width was arrived at after reviewing multiple research studies on readability, and reviewing many popular content websites. We will, as some of you have suggested, be experimenting with using those margins for a fixed table of contents, article tools, or eventually content-related things like images and infoboxes. So in short, we are far from done. We have written up some additional details about content width and white space on our FAQ page (🔗 link).

We appreciate all of your feedback and suggestions and hope that you will continue to follow along as the project progresses. Thanks AHollender (WMF) (talk) 16:43, 13 August 2020 (UTC)

Comment retourner au VRAI design de wikipedia s'il vous plait ? Il m'a fallu des jours et des jours de recherche pour tomber sur cette page par hasard. I gave the new design a try, and the result are clear I've used les and less WikiFr in favor of WikiEn. How do I even get back to the real TRUE design of wikipedia, please? It took me days to find the page. Please help. 87.231.14.108 05:04, 19 September 2020 (UTC)

White spaces

Hi, I think there is (especially on the right) too much white space. It looks like space for advert (image). Why can't the text be stretched anymore? Editing in such a small window is not good for me. --Patriccck (talk) 11:34, 6 August 2020 (UTC)

By all means, nobody is even thinking about allowing adverts to appear on Wikimedia wikis! Our explanations on why can't the text be stretched anymore, see our FAQ. SGrabarczuk (WMF) (talk) 14:11, 11 August 2020 (UTC)

Reduce the "Limiting content width"/ Much larger content container

Hi, I'm from the French Wikipedia. And I see a lot of negative reaction on French Wikipedia after the implementation of the first serie of Desktop Improvements. The more controversial element is the "Limiting content width". For my opinion, you should try to be more consensual and less ambitious on this feature, because on others Wiki, there will be much more negative reactions, based on the history of the relation between WMF and the different wiki. I think it's the more important element, but there are a other reason : the "Limiting content width" need to be associe with lot of work by the community to ajust element which are not responsive, and it will need lot of time to the different community to do those things.

I'm advice, it's better to have a much larger content container for large screen and temporarily have a larger content container to give time to the community to adapt. Nouill (talk) 12:52, 6 August 2020 (UTC)

Going back to the old style for IPs

Hello,

I’m often using the French Wikipédia as an IP, mainly for just reading articles. I was very surprised today to find that the new interface had been enforced without any warning (at least to the average, not logged-in reader). No banner, and especially no way to go back to the old version where you can use the full width of your screen. Worst, it isn't effective on all pages, you can browse WP and then suddenly go back to the old interface (Joy and happiness in my heart!) and then another click, and there is the new interface again (Nooooo!). It's pretty disrepectful for users to implement that change without any warning, and worst, it lacks a "go to fullscreen version" button.

Could we please have a "go to fulscreen version" button ? Thanks 176.186.245.230 15:15, 6 August 2020 (UTC)

While I personnally chose to use the new version, I second this request. Accounts are for editing and discussing, not for reading; the common (i.e. unlogged) reader should have as much choices as the logged editor when it comes to reading comfort. For example Reddit has this under the url old.reddit.com. Thank you for your work! --GrandEscogriffe (talk) 19:18, 7 August 2020 (UTC)

Hi @176.186.245.230, @GrandEscogriffe... Thank you for your feedback! You raise a few good points - I’ll try to do my best to answer all of them.  First I’d like to note that the new version of Vector, and the maximum width in particular, is very helpful for readers, as studies have shown that shorter line width increases text retention and readability - feel free to check out the rationale on the feature page, which also includes a brief literature review of previous studies on this.  

That said, in general, I also completely agree that logged-out users should be able to modify their experience to their needs in a similar way to people who are logged in. We have future plans for a variety of logged-out preferences that would allow for us. Unfortunately, due to the way we currently cache our content, these changes are very difficult to implement and would require a complete rearchitecture of our caching system.   In short, while we have this included in our future plans, we don’t yet have the technical ability to make it happen.

Finally, I wanted to address the issue of switching back to the old version for some pages.  This is also due to content caching.  When we deploy a new change, it takes it a few days to propagate across all pages of the wiki.  After a maximum of 7 days, you should be seeing the new version of the pages only. OVasileva (WMF) (talk) 14:09, 10 August 2020 (UTC)

Comments on line length, content separation and readability

The idea that shorter line lengths are better does not agree with literature. Longer lines = longer read speed. Dan Luu commented on this: https://twitter.com/danluu/status/1115708058238251008 More over, if you want to increase readability, why not instead increase the font-size? The only way I can salvage the redesign over the old one is by increasing the zoom size to +150%. (But the fonts become too big). Please don't deploy as is. I'm barely on a 24" screen and the redesign is wasting around 50% of my screen real estate. Also, the side bar separation which was clearly visible before is now being faded. Where there used to be gray = sidebar, white=main article, there is now a background grey, a floating sidebar, a __barely visible___ vertical separator line, and another floating article. On the old version, when you scrolled enough to not see the sidebar text anymore, the separation between two was clear and it helped actually anchor the reading. Now the text is just floating in a sea of white, with some kind of small, fixed size side gutter to the left and right on the sides in very light grey. — Preceding unsigned comment added by 192.222.130.66 (talk • contribs) 16:32, 6 August 2020

The statement : "The idea that shorter line lengths are better does not agree with literature" is interesting. In fact why do people want to "improve" or to smoothen the learning process in the first place, when an increasing amount of literature points to the fact that learning is deeper when the student struggles with the content ? If the reading process is too smooth, too involuntary, it might well be that the memorization is less deep than when the student needs to voluntarily seek information, by taking decisions on where to focus his eyes on a larger screen, as is the case in the Where is Wally/Waldo? books. Theo F (talk) 11:40, 7 August 2020 (UTC)

Hi @Theo F - thank you for your feedback! There actually is some literature that concludes that shorter line width actually improves the retention of information as well. In particular, we looked at an eye tracking study from the IBM Center for Advanced Learning which found that participants reading paragraphs of narrower width had higher retention of content than participants reading wider paragraphs. Similar results were also seen in a more focused study on people with dyslexia. Please refer to the Readability section of the limited width feature description page for a list of some of the other literature used for our rationale for deciding on this particular line width and how it relates to the number of characters per page. OVasileva (WMF) (talk) 14:33, 10 August 2020 (UTC)

I think the Wikipedia article referred to in the #readability section you mention, could be wrong when it ( en:Line length ) says "Studies have shown that short lines are often preferred over long lines by study participants, likely because they feel more at ease with format, which contradicts research suggesting longer lines are best for quick reading". In fact this is not a contradiction, it is consistent. In order to deepen memory, one needs to feel uncomfortable. There is no such thing as a free lunch. If you want to be a good learner, this is going to be a hard, "uneasy" work. Theo F (talk) 07:37, 11 August 2020 (UTC)

Also, in the case of narrow paragraphs, shouldn't the brightness of the unused right and left parts of the screen be adjusted in order to be lower than, or to match the brightness of the middle of the screen, or otherwise isn't the eye going to be distracted by bright dazzling white spaces on the right and left ? Isn't the eye going to get tired, in an ophtalmologic sense ? The screenshots displayed at Reading/Web/Desktop Improvements/Features fail to show those white spaces. They do not reflect what happens on a wide screen. Theo F (talk) 09:01, 11 August 2020 (UTC)

Reading the paper Theo F linked on Wikipedia [2] one gets the impression that 30 years of research have generated enough studies to cherrypick support for any assertion about line length. Wouldn't it be then a better choice to let users who prefer shorter line length resize their browser window, instead of messing it up for the rest of the users? 93.136.184.51 19:05, 12 August 2020 (UTC)

Hey, I think there is an important clarification to make when discussing the Tweet from Dan Luu and the research paper referenced. That study, "The influence of font type and line length on visual search and information retrieval in web pages" (link), researched line lengths of 55, 70, 85 and 100 characters per line (cpl). Our current width limitation of 960px results in line lengths between 100 cpl (when next to an infobox) and 150 cpl (when uninterrupted by any inline elements). We are therefore at, and beyond, the upper range of what was studied. The study did find that task performance of finding a given link (what they call the "visual search task") was fastest with 85 and 100 cpl. And that for the reading task they found no significant difference among the lengths (however several other studies have found better speed and retention at the smaller end of that spectrum). Also worth noting that on the subjective preference question the majority of participants expressed a preference for 70 cpl. What can we make of this research? The conversation I think we should be having currently is about line lengths far outside of that range, and whether or not we think they provide a good experience. Unfortunately I have yet to find any research on line lengths of 300 or 400 cpl, which is an experience anyone with a wide monitor might easily get on Wikipedia. Perhaps we could assume that given all of the research is within the 35–100 cpl range, and that most major information sites are within that range, we could have some confidence that it's a good starting point. Of course it would be better if we could find research, or conduct our own, about what happens above that range. Regarding some of the other questions raised above: we have just written up several answers to these questions in our FAQ section. Please visit https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Frequently_asked_questions. Thanks AHollender (WMF) (talk) 22:31, 13 August 2020 (UTC)

Nouvelle présentation pas du tout adptée

La présentation en mode vertical n’est pas du tout adaptée aux écrans horizontaux des ordinateurs !!! 151.127.32.46 18:23, 6 August 2020 (UTC)

Je préfère l'ancienne présentation ... _ ( Paille-en-Queue (talk) 18:30, 6 August 2020 (UTC) ) ...

Moi aussi! --Jwh (talk) 19:51, 6 August 2020 (UTC)

Je préfère également l'ancienne présentation. L'actuelle ressemble à celle de la version pour mobiles. Je trouve la colonne de gauche (Accueil, Portails thématiques, Article au hasard, Contact, etc.) trop claire (insuffisamment grisée) ce qui rend la page éblouissante. Lorsque je clique afin de la masquer, la zone d'affichage du texte ne rélargit pas, la largeur de la marge de droite augmentant d'autant que celle de gauche se réduit. Cordialement, Olimparis (6 août 2020).

En fait, la largeur limitée n'a pas été développée spécifiquement pour les écrans verticaux. Pourquoi nous avons déployé cela - consultez notre FAQ et une page plus détaillée décrivant uniquement cette fonctionnalité. Aussi, @Olimparis, merci pour votre avis sur l'arrière-plan de la barre latérale! SGrabarczuk (WMF) (talk) 14:18, 11 August 2020 (UTC)

Some first impressions

Hey there, aren't you guys rushing things a little bit? This is not a finished work. Do not present an unfinished work to the readers (and the editors) if you want them happy with it. First there is a clear issue with symetry. You have to collapse the toolbar to get a symetrical page with empty columns on both sides, but nobody wants his toolbar collapsed and certainly not an editor. I know once you start scrolling down the toolbar disappears but as they say, the first impression matters doesn't it ? There are other issues including for example bits of text squished into a tiny fraction of the screen between an illustration and an infobox, which you just can't describe as "comfortable to read" in any way, and large tables with plenty of content that clearly need more than 60% of the width of a screen to be comfortable to read, and become quite unreadable when they are further squished by an image or an infobox. You guys, I'm afraid, have to solve this kind of tiny issues BEFORE you deliver a new page layout. It might not look like a big deal, but it is worrying that some editors (including myself) are already turning back to the old style. If some editors start feeling that making it easier for the reader comes with making it trickier for them, it would be a huge failure on your behalf. Please put more time in experimenting with your work before you make it the standard for all wikipedia users. Thanks for your work anyway, Toghebon (talk) 19:01, 6 August 2020 (UTC)

@Toghebon, thank you for this comment! SGrabarczuk (WMF) (talk) 15:52, 11 August 2020 (UTC)

IT'S HORRIBLE !!!

Hi.

I've discovered this new appearence. It's horrible and no easily usable. Please restore the previous appearence. --ComputerHotline (talk) 19:14, 6 August 2020 (UTC)

@ComputerHotline, thanks! Could you elaborate more: how this change affects the way you interact with a wiki? Why isn't this usable for you? SGrabarczuk (WMF) (talk) 15:55, 11 August 2020 (UTC)

First impressions

The new appearance leaves an empty space, a few centimetres wide on the right side of every single article. Is there any way to fix this ? Yoyo360 (talk) 19:34, 6 August 2020 (UTC)

Hi @Yoyo360 - thank you for your feedback! Are you referring to the space between the menu and the article text? If so, we are planning on fixing this in the next couple of weeks - you can track our progress on phabricator. Otherwise, the space on the right and left side of the text is expected - we have limited the width of the text to provide readability of the content. You can learn more about our rationale on the feature page.

Tracked in Phabricator
Task T259761

OVasileva (WMF) (talk) 14:34, 11 August 2020 (UTC)

Hi @OVasileva (WMF) ! I was referring to the space on the right side of the screen. From what I understand it is actually meant to be there, but I think it is really weird to have a space completely unused. If the central space is used for the main content and left space for the menu, you should put something on the right as well, as on Twitter for example. 109.209.19.70 17:18, 11 August 2020 (UTC)

Trop étroit

La réduction de la largeur n'est vraiment pas une bonne idée, je trouve. On se retrouve avec des écrans d'ordinateur dont à peine la moitié de la largeur est occupé par du texte, ce qui oblige à jouer sans cesse de la molette pour lire alors que l'ancien affichage offrait davantage de contenu sur une même page. Les infobox et les images de part et d'autre du texte entre davantage en collision, réduisant davantage encore la quantité de texte affiché sur une même page, ce qui est particulièrement frustrant quand on voit de large bandes vides à gauche comme à droite. C'est d'autant plus dommage que la seule justification avancée est qu'avoir un même affichage sur ordinateur et sur tablette serait nécessairement une bonne chose. Non. En quoi est ce bien ? Avoir un rendu un peu différent en fonction du matériel utilisé est normal, et c'est absurde de priver les utilisateurs de l'un (la grande largeur d'un écran) sous prétexte que les ceux de l'autre n'en bénéficie pas autant. C'est du nivelage par le bas. Les tablettes et mobiles ont des avantages comme par exemple les gyroscopes intégrés, que n'ont pas les ordinateurs. Ce n'est pas pour autant que les applications en enlève l'utilisation sous prétexte que les ordinateurs ne l'ont pas. Ça n'a pas de sens de forcer à ce point une utilisation commune pour du matériel aussi différent au détriment des utilisateurs. J'espère vraiment que vous tiendrez compte des retours présents sur cette page. Cordialement.--Aréat (talk) 19:42, 6 August 2020 (UTC)

Do agree, nivelage par le bas! --Jwh (talk) 19:53, 6 August 2020 (UTC)

Same for me. Definitely not an improvement..--Damned (talk) 19:56, 6 August 2020 (UTC)

Je trouve la colonne de gauche (Accueil, Portails thématiques, Article au hasard, Contact, etc.) trop claire (insuffisamment grisée) ce qui rend la page éblouissante. Lorsque je clique afin de la masquer, la zone d'affichage du texte ne rélargit pas, la largeur de la marge de droite augmentant d'autant que celle de gauche se réduit. Cordialement, Olimparis (6 août 2020).

Exactement le même avis qu'Aréat. --89.156.216.137 20:18, 6 August 2020 (UTC)

Même avis également. — Vincent Lefèvre (talk) 21:49, 6 August 2020 (UTC)

Si encore le système permettait de basculer d'un mode lecture réduite à écran cinéma, ce serait toujours mieux que rien. En l'état je ne vois pas l'intérêt. Jpgibert (talk) 11:41, 7 August 2020 (UTC)

Something I do not understand is: why don’t you let users who find it hard to read wide paragraphs reduce the size of their window, use the zoom function of their browser, or use the reader view? Before this change, it was possible to reduce the wideness of the paragraphs using one of these methods; now, it is impossible to revert it and enlarge them — unless you are logged in, of course. There something strange in reducing the wideness of paragraphs now that many people use 1920px-wide screens… Thanks --Rükükü Stash Stash (talk) 07:28, 7 August 2020 (UTC)

Idem, la barre blanche d'espace inutilisé à droite me perturbe beaucoup trop, c'est désagréable, inesthétique, un gâchis monstre d'espace et pas du tout pratique puisque ça limite le contenu à lire sur la page. Et mon ordinateur portable n'a pourtant qu'un écran de 17 pouces. Je suis repassée à l'ancienne version à cause de ça, tout les autres changements ne me posent pas problèmes, j'aurais même pu en apprécié certains, mais cette limitation de la largeur de la page ? Une erreur. Pas du tout intuitif, tout le contraire. --Zeynel (talk) 10:14, 8 August 2020 (UTC)

Je suis un simple lecteur de Wikipedia, j'ai retrouvé ce très vieux compte pour pouvoir donner du feedback sur cette nouvelle interface, et pour dire que la grande barre blanche à droite est un gâchis d'espace, pas même utilisé pour y mettre les images. Je n'ai pas réalisé d'étude académique sur le nombre optimal de mots par ligne, mais rendre les pages plus étroites n'améliore rien du tout, resserrer tout rend les choses plus confuses au contraire. Je n'ai pas d'avis sur les autres modifications, mais si les retours des simples lecteurs sont appréciés, alors revenez en arrière sur le Wikipedia francophone, et n'implémentez pas ça sur les autres langues non plus. Merci d'avance. Xerbias (talk) 20:55, 8 August 2020 (UTC)

Hello — please excuse my message in English and my delayed reply to this thread. The motivation behind limiting the content width is to improve the reading experience, particularly for people with wide screens. The research we have reviewed recommends line lengths around 45–75 characters per line. The upper limit we have seen from research, or found on other popular information websites, is around 120 characters per line. Research shows that above this limit there are detrimental effects to speed, comprehension, and retention of information. If you take a look at some of the popular websites you use I expect you will find a similar width limitation. So we believe that is the correct default experience, even if it results in white space on the sides of the screen. Further along in the project we will be experimenting with putting a table of contents and/or article tools in that white space. I encourage all of you to take some time — maybe a few weeks — and give the new layout a chance. We have already heard from some editors that after a week or two of adjustment they are liking the new layout and find it easier to read. Of course if you have a strong preference for full-width content that is your right. A team member has made a userscript that adds a button to toggle the width of the content: https://en.wikipedia.org/wiki/User:Jdlrobson/vector-max-width-toggle.js. Lastly, we appreciate your feedback and hope you continue to share your observations and opinions. I also ask that you review the notes we've collected here so that you have the full context of our thinking: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Frequently_asked_questions#Why_is_the_width_of_the_content_limited?_Why_is_there_so_much_white_space?. Thank you AHollender (WMF) (talk) 16:58, 13 August 2020 (UTC)

Thanks for the answer. I'm always logged out when reading Wikipedia, so I care how it looks for the default user. On popular websites, there is stuff in columns around the text. If this has to go on, I strongly suggest you put everything that is not the article's text on the empty side, because it can reduce the size of the line way too much, which is not what you're looking for. An example : https://fr.wikipedia.org/wiki/R%C3%A9publique_d%C3%A9mocratique_finlandaise The infobox and the picture should be on the side, then, and length of the line would be alright. This is the priority to fix before implementing it further I think. Xerbias (talk) 18:02, 14 August 2020 (UTC)

I think this answer misses a few points. It may be good to scroll faster thanks to a larger page width. So adjusting only for reading may hinder other uses of the page, such as navigating through it. I often move downwards quickly in order to go where I want. This is now made slower. It also misses the point that people made a conscious choice to have a large screen and that they can reduce the size of their window when they want to. I do that all the time. I disagree with the notion that I should be restricted because some people don't know how to resize a window. Using the white space for other things in the future makes little sense as it would be too small on small screens to hold anything useful in the first place. Please just let people decide the width of their screen. Furthermore, I recently had to edit many pages (French wikipedia, towns -communes- pages with neighboring communes being half-hidden) because the layout got cluttered due to an image on the right "eating" the text or tables on the left, which has to be changed from left to centered in order to be readable at all. I believe this is due to the limitation in width.

Please stop!

Please stop inventing concepts that are useless. You get to dislike basic Wikipedians, those who work on the core of wikipedia: content. Let us work! If you want to make changes, let them be approved by a qualified majority and not by a small group disconnected from reality. --Archaeodontosaurus (talk) 20:04, 6 August 2020 (UTC)

This is currently where I'm at. The majority of editors seem to strongly dislike the proposed changes, especially max-width. Why does WMF think they should force changes that the community are against? There are so many reasons not to do this.

• Vector is the brand of wikipedia. It is how people recognize wikipedia and known around the world.
• People do not come to "read articles" as AHollender keeps repeating. They come to scan for information.
• Wikipedia is not a stream of information, like every example in Desktop_Improvements/Frequently_asked_questions. It is a sea. We are not a journal, a news site, or medium.com and we shouldn't try to be. We are an encyclopedia.
• I can't help but notice all the defenders of these changes are being paid to make them. All the opponents are unpaid volunteers that have no need to justify their continued contribution to the project. Maybe the paid staff should stop defending themselves and work on something the community supports. I don't know how to phrase that in a kinder way.

-- Trysten (talk) 23:05, 19 December 2020 (UTC)

Suggestions about font-size and infobox position

Hello!

Firstly, thank you for these welcome interface improvements.

To further improve readability, it may be worthwhile to slightly increase the text size and line spacing.

On the other hand, it is true that the presence of large white margins is a bit disturbing, especially with large screens. This space could be used to insert some of the templates that are common in most wikis. For example, infoboxes could be positioned in the right column at the beginning of the article.

Regards, Géodigital (talk) from French Wikipedia, 09:12, 7 August 2020 (UTC).

This space could also be used for the references: they would be better contextualized and the reader would not need to go down to the reflist section and then go up to where he was reading. --Daehan (talk) 10:02, 7 August 2020 (UTC)

Hey, thank you for your observations and suggestions. I apologize for my delayed reply. I fully agree on all points:

• we should experiment with font size and line spacing. We're assuming that those changes would be more controversial than line-length, but maybe that's not the case.
• we should experiment more with page layout, particularly regarding the table of contents, infoboxes, and references in the margins. There have been some great mockups submitted by contributors on this topic: https://commons.wikimedia.org/wiki/File:Annotation_2020-07-30_0xc80607.png and https://imgur.com/FVN98xx

I hope you all will continue to follow along as the project progresses and continue providing your helpful observations and opinions. Thanks! AHollender (WMF) (talk) 17:31, 13 August 2020 (UTC)

Freeze top pan

Hello,

Thank you for the new interface.

A direct consequence is that long articles are longer to scroll down, and consequently to scroll up. It is especially anoying to have to scroll up to the search bar, both for user and reader.

So, would it be possible to freeze the top pan that includes (or will include) logo, search bar, personal links (user, talk, preferences, beta, watchlist, contributions, log out)?

Or provide a button aside the section titles, that allows the user to go back on top.

Thank you very much, --Daehan (talk) 09:58, 7 August 2020 (UTC)

+1. It would be nice, especially if the new top bar is smaller than before as you planned :). Jules* (talk) 12:14, 7 August 2020 (UTC)

Hi @Jules*, @Daehan - thank you for the feedback! Adding a persistent header is actually one of the features we are planning on implementing next in the project (will probably begin building within the next 2-3 months). Some mocks on our initial ideas are available on our features page. In terms of functionality we plan on including the list of features you referred to earlier: logo, search bar, personal links (user, talk, preferences, beta, watchlist, contributions, log out). We are also considering adding persistent links to edit, talk, and history as well. Let us know if you have any more thoughts around this. We're hoping to finalize our ideas and put up a prototype to gather thoughts and feedback within the next month or so as well. OVasileva (WMF) (talk) 14:41, 11 August 2020 (UTC)

@OVasileva (WMF): great! I think that with those further developments and a bit of polish, new design will be more consistent, and more liked by editors. Kind regards, Jules* (talk) 23:19, 11 August 2020 (UTC)

Hello @OVasileva (WMF): , these are great news! Can't wait for it to happen :) --Daehan (talk) 20:53, 15 August 2020 (UTC)

new header is ugly and creates more empty space!

the new header is ugly! it's smaller, it breaks the harmony of lines, it causes more empty space in the top part of the screen and it's completely unneeded!--Orange-kun (talk) 14:27, 7 August 2020 (UTC)

Hey @Orange-kun. The header as is now is just one step towards the look we intend. Later, we will make it sticky (just as requested above), will put more options there, and make aesthetic adjustments. For more details, look at Olga's reply directly above this section. SGrabarczuk (WMF) (talk) 16:02, 11 August 2020 (UTC)

@SGrabarczuk (WMF), I've made some remarks on current design and uploaded a screenshot here: [3] please note it! --Orange-kun (talk) 07:28, 12 August 2020 (UTC)

The interface is not practical.

Hello, first of all I would like to thank the developers for the work they have done on this new interface. I contribute and read Wikipedia from a laptop. The screen is not very big. Now that there are the huge borders there is really less room for the content. Maybe the borders are ergonomic on big screens, but on my small screen it's a disaster. I think we should work from Timeless, which is a very ergonomic, beautiful skin, and which adapts very well on small screens (smartphones for example). 3(MG)² (talk) 16:51, 7 August 2020 (UTC)

@3(MG)², thank you. In the FAQ, we've explained the reasoning behind the limited content length. What is, according to you, the key advantage of Timeless compared to our change? SGrabarczuk (WMF) (talk) 16:13, 11 August 2020 (UTC)

Improvements

Hi,

I did a tweet with the chapter account to help the people on Twitter

https://twitter.com/Wikimedia_Fr/status/1291679508651704321

I'm personnaly happy of the maximum width. I'm not a huge reader of Wikipedia, but I find articles difficult to read, specially when whe compare Wikipedia to Medium. Since 2014, I'm using a CSS done by Magnus (fr:Utilisateur:Pyb/vector.css). It's basically a 3-column website with the table of content on the left, text in the middle, infobox on the right, and files on the left and right columns. Unfortunately a lot of wikipedians like alterning pictures on the right, on the left... With Vector, you obtain very few words per line!

Thank you for the work, modifying the skin is not an easy task. Pyb (talk) 18:53, 7 August 2020 (UTC)

Hey @Pyb thank you so much for spreading information about the project on Twitter, and for your encouraging feedback. It's great to hear that you find the site better to use :) We hope that you will continue following along and giving feedback. Thanks again AHollender (WMF) (talk) 22:38, 13 August 2020 (UTC)

Good intentions, poor execution.

Ok, studies say it's better to have not too large text.

But maybe don't just reduce text width without thinking about the layout at all ?

It looks ok on one of my monitors, but absolutely awful on my laptop. Maybe it would be ok if we still had 4:3 screens ? Well that's not the case.

We already had skins with different width (Timeless, Minerva), they showed perfectly how you could reduce main text and still use space efficiently. Why not take ideas from these ? We know these skins work, they can be a great inspiration for the new version... no need to reinvent the wheel (especially if it's to make it square).

I mean, when the mobile skin looks better than the desktop skin, on desktop, there is an issue — Preceding unsigned comment added by 2a01:e34:ed1e:8360:2575:8c8c:7e6c:54da (talk • contribs) 21:20, 7 August 2020

No, studies actually say the opposite: it is better to have a large text width. See the comment from User:176.186.245.230 above at #Comments on line length, content separation and readability quoting Dan Luu. Theo F (talk) 16:35, 8 August 2020 (UTC)

Hey the question of that specific Tweet and the study it references is being discussed in another thread. Please see https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Comments_on_line_length,_content_separation_and_readability. Regarding the questions around how we might make use of that space, Timeless/Minerva, etc. — we are planning to experiment with similar features. Please see this section for more details: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Frequently_asked_questions#But_what_about_all_of_the_white_space!?. Also, if the anonymous contributor who left the initial comment sees this: can you please clarify what you mean when you say "It looks ok on one of my monitors, but absolutely awful on my laptop"? What about it looks aweful?

A way to let users anonymous users maximize the reading window -- a button?

Some users (I am among them) prefer to be able to choose the reading width. As a technical solution, I would like to suggest that an additional button for example with a double arrow ⇔ labelled as “maximize width“, which would toggle modes, the same way that there is a button to collapse/expand the lateral bar.

My use case:

I read wikipedia unlogged on private and public computers. My preferred width appears to be around 1200px, but sometimes different values to fit several windows on the screen. I loved the dynamic width. I could set the old vector style in the preferences, but that is only accessible when logged in. In my case, it means:

1. the annoyance of physically typing in a password every time I want to read a Wikipedia article;
2. the possibility that I occasionally forget to log off from a public computer;
3. possibility that I mistakenly edit a page under a logged account while I intended to edit as IP to avoid linking some of my interests to my main account;
4. the question of principle that Wikimedia Foundation can now easily track which pages I read (not the same thing as the pages I edit). Maybe the WMF already could infer that using other technical solutions, but now it becomes trivial.

Creating a secondary account for reading does not eliminate the annoyances above (in particular typing a password and losing 30 seconds everytime). Cæruleum (talk) 23:06, 7 August 2020 (UTC)

I followed a tutorial to do a quick hack on CSS with greasemonkey/tampermonkey.

This is a first time for me with CSS/js, please someone experienced help improve it. At the moment the problem is that above a certain threshold in width, it starts teh text below the left bar, which should then be switched to collapsed mode. or it should be the opposite: collapse the lateral bar for small width, expand it above a threshold. Either way, I am not competent.

Plus:

• works at my place with Firefox 79.0 and Palemoon 28.12
• a short term solution that requires fewer clicks (just one click to collapse the lateral bar when using at large widths).

Downside

• needs to be installed on each and every public computer when one reads Wikipedia, including installing an extension
• on Firefox, requires javascript activated (on Palemoon, Greasemonkey bypasses that somehow).

The commented line about "imeselector" is for when javascript is required. It removes the moving keyboard icon that appears on top right corner of the edition window everytime one types a new line. It moves after 5 seconds of typing something, this is very distracting when javascript is activated. There are probably better ways to have it not move, but I am not competent.

// ==UserScript==
// @name        Change_vector_maxwidth
// @namespace   example@example.com
// @description Changes the width on fr.wikipedia
// @include     https://fr.wikipedia.org/*
// @version     1
// @grant       none
// ==/UserScript==

function addGlobalStyle(css) {
    var head, style;
    head = document.getElementsByTagName('head')[0];
    if (!head) { return; }
    style = document.createElement('style');
    style.type = 'text/css';
    style.innerHTML = css;
    head.appendChild(style);
}

addGlobalStyle('.mw-content-container { max-width: none !important; }');
addGlobalStyle('.mw-workspace-container { max-width: none !important; }');
// addGlobalStyle('.imeselector { display: none !important; }');

The following should press the button so the left bar starts collapsed, which solves the problem where the the text starts below the bar, for large widths. But I cannot make it work. Please someone help.

// https://stackoverflow.com/questions/6337197/greasemonkey-button-click
// https://wiki.greasespot.net/Generate_Click_Events
var evt = document.createEvent('HTMLEvents');
evt.initEvent('click', true, true);
document.getElementById('mw-sidebar-button').dispatchEvent(evt);

Cæruleum (talk) 14:30, 8 August 2020 (UTC)

@Cæruleum, we’re working towards the best use case. We are also aware that individual users adjust the layout to their personal needs. Luckily, Wikimedia wikis are massively customizable. There are user gadgets/scripts which change the width already. For instance, see Max-width gadget section. SGrabarczuk (WMF) (talk) 20:08, 11 August 2020 (UTC)

As I understand, this solution only work when logged, which was never a problem because several skins are already available. The need I express is for users who read wikipedia unlogged (because of using shared computers, or because the login does not survive closing the browser; see also my discussion above).

I am not questioning your new choices, I am instead asking for a help from you competent developers to improve a proposed script that I published above, so that it can be used by me and others who read or edit Wikipedia unlogged, without affecting any of the new defaults.

Let me know if a paid bounty would be appropriate, and how I can place such request preferably within the WMF. Cæruleum (talk) 23:03, 11 August 2020 (UTC)

Diff views are extremely narrow

Hi Readers Web team, are there plans around relaxing the width constraints when viewing page diffs? Diffs show side-by-side (i.e. 2-column layout) comparisons of two revisions of a page. The content shown for each revision is the wikitext, and is therefore more verbose than the corresponding content that would be rendered (despite only having about half the horizontal space available). When viewed on a 15-inch screen, the new design reduces the width used for each column in the diff from almost half the screen width to about a quarter of the screen width (see screenshot), making it more difficult to scan (particularly for longer lines that have to wrap) and increases the length of the page (for longer diffs). I don't find that ideal, so I hope we can improve that experience there. Hazard-SJ (talk) 03:49, 8 August 2020 (UTC)

Thanks for flagging. I've setup phab:T260091 to document the pages where fixed width is problematic. Please feel free to comment there if you find any other pages. Jdlrobson (talk) 22:19, 10 August 2020 (UTC)

Any forthcoming actions following early comments?

People have started to express their feelings about the new layout of the French Wikipedia, but got not much feedback for now. The banner iniviting people to leave their comments here has been quickly removed from articles, while patronizing answers on the French Village Pump explain that problems are mostly with people's mindsets and that the new layout is pretty much okay. Does it mean that basically nothing will be done to improve the situation? — Bob Saint Clar (talk) 07:30, 8 August 2020 (UTC)

@Bob Saint Clar, we are collecting data (via API as well) and will make decisions in the near future. It's our intention not to make major decisions directly after the development, based only on the first reactions. SGrabarczuk (WMF) (talk) 16:15, 11 August 2020 (UTC)

@SGrabarczuk (WMF): thanks for your answer.

I totally understand that you wish to capture a comprehensive feedback from all stakeholders prior to making any kind of decisions: that make sense. In the meantime, is there any page, on Mediawiki or elsewhere, where suggestions and proposals for discussion are logged and investigated, so that we can have an idea of what is being considered exactly, and when any kind of outcome should be expected? — scope, roadmap, timeline, that sort of thing.

Bob Saint Clar (talk) 17:00, 11 August 2020 (UTC)

You are right, this is exactly our approach.

Regarding your question, this very page is the central place for proposals and discussion with the wide editing communities. There's also a Phabricator board with a part of the more technical discussions. If you go through the main navigation tabs and read these pages, you will learn all the crucial information that needs and is possible to be shared now, incl. the scope and sequence of functionalities built and deployed. SGrabarczuk (WMF) (talk) 12:00, 12 August 2020 (UTC)

A mini-minute remark

Of the 3 july changes that affect, as far as I am concerned, the fr.WP (WP = wikipedia) and fr.wikt (wikt = wiktionary) interfaces (and with my less degree of participation, to eo.WP), much nothing to say, apart "good job ! I appreciate". 1°) I can't say I am much appreciating the collapsible sidebar, since I have been using this functionality with the LeftPaneSwitch gadget for many (?) years, so that I miss it on en.WP. While rereading these words, I notice that this gadget was only present on fr.WP, and not on eo.WP or fr.wikt. So now, the functionality is all there, and on fr.WP, I e havleft the gadget apart. In conclusion : for me; no new functionality, but its presence at more palces ; and more confidence in it, since it's now part of the "system". 2°) The width question : on desktop computer, who is still having a 9 in. wide LCD ?… It's nowadays so easy to zoom the content inside a specific window or to adapt the size of the fonts to the specific use at the peculiar moment… Since I am badly equipped in matter of eyes, it's a thing I permanently do, changing globally the size of the fonts inside a window, an operation which can be done, on my casual OS at home (5 years old since the last major update) as well as with the much newer one at work, with very simple shortcut key commands… So, I am wondering where the problem is, guys ? Those in need just have to learn two new shortcuts and that's fine, most probably. 3°) The logo size and shape… Oh yes, this is a very vital subject… :-))) which I don't care. But I do have a truely definitive real mini-minute remark : I have noticed the disappearance of one crucial functionality : clicking the WP sphere logo was « sending the browser » to the home page of the current project, Wikipedia or Wiktionary. Now, the logo is unresponsive, deaf, insensitive, shamely careless... How-e-ver, since this functionality is the first one in the left column, this means that : if the column is deployed, it's also one click ; but when the column is collapsed, it's now 2, two, TWO ! clics, one to open it, and the second… as usual. Well, I personaly think I can however cope with this newly required tremendous effort of partly doubling the clicks... :-) Conclusion : therefore, thanks to all people who participated to the elaboration then development for these three first modifications. I'll be waiting for the next 10 with no anxiety. Best friendly regards to all readers of this, and to others too. (And I plea guilty for typos, miss-expressions and bad wordings…) --Eric.LEWIN (talk) 07:53, 8 August 2020 (UTC).

@Eric.LEWIN, thank you for these kind words! SGrabarczuk (WMF) (talk) 11:46, 12 August 2020 (UTC)

new interface : the main problem is when there is an infobox

Without infobox, the lengths of a line on my screen is ~115 character, and i think that it is good. But when there is an infobox (like at the begining of most article), it is reduce to ~77 and is too short.

But this would be very easy to solve, by putting the infobox in the big empty space at left :

this is the old version : https://i.imgur.com/hGpwlHY.png

this is the new version : https://i.imgur.com/uwDFaof.png

this is my suggestion : https://i.imgur.com/FVN98xx.png

(the dark-mode is the result of 2 addon (dark reader + adjust screen brightness). But it would be easy to make it the dark theme of wikipedia : the brightness of the images is reduce of 20%, the background is 14-14-15 (in RGB) ; the main text is 157-153-147 ; the bleu link is 77-130-180 ; and the title is 177-170-147 .)

--2A01:CB08:AB5:E300:9044:65C:233E:DD66 05:33, 9 August 2020 (UTC)

Hey, apologies for the delay in responding. Thank you for taking the time to provide constructive feedback. And we really appreciate you showing your ideas visually, it helps facilitate communication and understanding. I think it's a great point you make — moving infoboxes and/or image templates into the right margin seems like an improvement worth experimenting with, especially given the updated layout. I am not yet sure how this would be possible from a technical perspective but I've added to our list of future considerations. AHollender (WMF) (talk) 13:44, 20 August 2020 (UTC)

I find the images outside the text to be a very bad idea. If I reduce the size of my window to just see the text, I'll miss the images.

Images mixed with text feel also more pleasant to the eye imo.

The beginning of the line in the page (mainly for wiktionary)

In the old version, there is an bleu line at the left of the article, but not in the new ; and in the new, the text start far from the left limite of the screen. It is mainly a problem for Wiktionary, because there is lot of list, and for the list, we always go the the left, but there is no indicator for where the line start.

We could use this bleu line at the left of the article :

old : https://i.imgur.com/DBp9D1b.png

new : https://i.imgur.com/zeIafni.png

my suggestion : https://i.imgur.com/fMCqj2Y.png

--2A01:CB08:AB5:E300:9044:65C:233E:DD66 06:37, 9 August 2020 (UTC)

Hey, thanks for your suggestion. In an attempt to consolidate conversations I'm going to point you to a Phabricator task, on which a similar discussing is happening: https://phabricator.wikimedia.org/T259240. In short I understand the need to have some kind of element that frames the content so it doesn't feel like it's floating. However since there are several other features that we want to work on in that space, we think it makes sense to wait for those features before making any additional changes to the background/border situation. AHollender (WMF) (talk) 18:27, 24 August 2020 (UTC)

What's the plan for Legacy Vector?

What is the the long term plan for "Legacy Vector"? Will it continue to be available as a separate skin, like Monobook is, after the new Vector is deployed as the default skin? /JohanahoJ (talk) 07:59, 9 August 2020 (UTC)

Hi @JohanahoJ - that's correct, the Legacy Vector skin version will continue to be available after the switch. OVasileva (WMF) (talk) 14:50, 11 August 2020 (UTC)

Ok, thanks! /JohanahoJ (talk) 14:58, 11 August 2020 (UTC)

The width is the same for everyone, but non-Latin wikis look different

There is also a difference in fonts. In firefox settings win10 (font by default) the font size is 16, in the wiki it is already 14 - see where the line ends in the wiki. I put 14-15 in the browser or 13px for the text - a few more words fit into the line. Or I do serif (times new roman) - in another font the text is denser. I take an article in enWP - 150 characters fit in a line, in ruWP - 130. In enWP (and in ruWP with a smaller font size), browsing and reading the text is a little more convenient. In ruWP, the text looks "inflated" and the developers, when forming the length, could only look at sites in English. Non-Latin languages ​​are now less comfortable to read. It is possible that different wikis need different widths or font adjustments for the same number of characters per line. --Sunpriat (talk) 12:50, 9 August 2020 (UTC)

@Sunpriat, this is an excellent point. We will definitely look into these settings. SGrabarczuk (WMF) (talk) 16:29, 12 August 2020 (UTC)

The maximum width restriction is a disaster for wide tables and wastes screen space.

I know criticism is not much appreciated, but I am afraid this needs to be said:

The maximum width restriction which is planned for Vector 2.0 defeats one of the greatest benefits of the Vector skin and is a disaster for big tables. Not just on Wikipedia, but on countless MediaWiki instances on the Internet.

Here are two screen shots of this table in comparison. And here is the Vector 2.0 demo site. The difference is dazzling.

Users who actually want a restricted content width already have that option: A “Mobile view” button at the bottom of the page or the browser's so-called reading mode, which all major browsers are equipped with by 2020 and is customizable by the user.

I am utterly disappointed about that width restriction. One of the things I appreciated most about Vector will now be destroyed.

Also, the change actually does the opposite of improving readability: It forces the user to seek the beginning of lines more often. For this very reason, I read long texts horizontally if I read on a mobile phone.

Suggestions

• If this change will actually be made on Wikipedia, please do not make this change a default on MediaWiki, because many MediaWiki instances on the Internet do not allow a user to create an account which would be required to choose MonoBook, which I presume will not be squished like Vector 2.0.
• Please allow non-account users to choose a skin via a setting that is stored as a browser cookie. The useskin URL parameter is discarded upon navigation to the next page.

I sincerely hope that my suggestions will be considered. ---46.114.106.231 12:54, 9 August 2020 (UTC)

I totally agree with you. Lematth88 (talk) 16:12, 9 August 2020 (UTC)

wide tables are a disaster on mobile and should be avoid. Pyb (talk) 21:52, 9 August 2020 (UTC)

Actually, tables can easily be side-scrolled on mobile phones. Also, us desktop readers do not wish to lose wide tables that look good on a desktop monitor. --79.241.207.77 23:28, 9 August 2020 (UTC)

Agreed. Mobile view should be optimized for mobile and desktop view should be optimized for desktop. Otherwise what's the point of keeping them separate. 93.136.89.139 05:26, 14 August 2020 (UTC)

Thanks for bringing this up. One of the worst designs I once saw in a web application was a big table (wide & long) squeezed in a narrow column with a horizontal scrollbar at the very bottom, i.e., you need to scroll to the bottom of the table to then scroll to the right, which makes reading a line from left to right totally impossible. It specifically pains when at the same time the monitor would be big enough to never require horizontal scrolling. So that must be avoided IMHO. Switching the overall layout isn't optimal either, because restricting the width of text still has its value. From this seems to follow, that wide tables (and other wide material, like images?) should be allowed to to "flow" over the text margin. One could discuss a UI where tables can be folded (in/out). Perhaps by default(?) tables are cut off at the text margin, but can be expanded to the full physically available horizontal space by one or more simple gestures. That way the initial view of a page is clearly focused on the text column, but wide material can be made to show in an optimized way. 94.223.0.72 13:06, 8 October 2020 (UTC)

Max-width gadget

Here is a gadget that might be helpful to users who dislike the max width but do not want to opt into the legacy mode. It should give you the best of both worlds and hopefully allow you to see the benefits over time. en:User:Jdlrobson/vector-max-width-toggle.js Jdlrobson (talk) 00:36, 10 August 2020 (UTC)

One can also do it similarly with a custom CSS browsing add-on. --79.241.207.77 01:12, 10 August 2020 (UTC)

Great! Thank you on behalf of the entire Multiverse, @Jdlrobson :) SGrabarczuk (WMF) (talk) 23:08, 13 August 2020 (UTC)

Any plans to roll it out for us 99% of Wikipedia readers who don't have an account? I suggest a link next to the mobile switch. 93.136.89.139 05:25, 14 August 2020 (UTC)

Preferences like this are generally only made available to logged-in users. If you are using a desktop or laptop, you might want to look into installing a userscript manager. Once you've installed it, click the "new userscript" button and copy the code on the .js page linked above. — pythoncoder  (talk | contribs) 13:38, 24 September 2020 (UTC)

Malfunction

There seems to be a malfunction, the site renders like this: https://wtf.roflcopter.fr/pics/Ekh6WpbZ/bLniiEly.png

Notice the random, non-aligned white and grey areas left and right of the page and overall lack of alignment. M!dgard (talk) 20:32, 10 August 2020 (UTC)

Okay, apparently it's intentional. I don't want to just scream "baaad!", and I think a lot about design of websites and web applications these days, creating some myself, so here's a quick critique.

A quick critique by M!dgard

M!dgard (talk) 21:03, 10 August 2020 (UTC)

Here's a quick mockup that I think fixes a lot of issues.

A quick mockup by M!dgard

I haven't touched on the max-width, if that's something you want to keep. M!dgard (talk) 21:40, 10 August 2020 (UTC)

SGrabarczuk (WMF), please look carefully at these comments and the proposed fixes that M!dgard so generously provided. They should all be considered before rolling out these changes to sites like en.WP, where there are many editors who are just as critical but not nearly as helpful. Jonesey95 (talk) 17:20, 13 August 2020 (UTC)

@Jonesey95, sure we are! We are watching this page and looking carefully at all comments. As we've outlined on the main page of the project, we are implementing the changes gradually, and adjusting and improving the layout. Our decisions aren't based on talk page feedback only, but also on statistics. Our software is and will be well tested :) SGrabarczuk (WMF) (talk) 22:25, 13 August 2020 (UTC)

max-width CSS rules harm usability

A max-width CSS rule is not relevant for the content of a webpage, because it is possible for users to resize the browser window. On top of this, many browsers offer a "reading mode" that shrinks the text to a small column. Please retract any max-width CSS rules on the content. Calimeroteknik (talk) 20:40, 10 August 2020 (UTC)

Yeah. The most used browsers also allow the use of ctrl+plus or ctrl+mouse scroll to zoom in, which gives you fewer characters per line. We who want to read the page in normal width have been forced to resort to unreliable CSS hacks. 93.136.89.139 05:34, 14 August 2020 (UTC)

The new maximum-width rule is making reading experience worst

While I understand the rational behind the maximum line length rule, I found the way it has been implemented (setting up a max-width on the whole article) is making reading experience actually worst than it was before. Some of the issues I noticed / suggestions of improvement:

• Not properly implemented on large screen with grey areas on the borders => no grey areas
• Menu of the article (Read, Edit, Search, etc.) has also been reduced causing a strange disruption with the menu in the header => align with header menu on the right
• Infobox further reduce width of the paragraphs making them very small => Move infobox outside of the max-width limit to the right.
• Large tables are very difficult to read => allow for large table to extend max-width limitation

pzwsk (talk) 11:25, 11 August 2020 (UTC)

@Pzwsk, thaks for these suggestions! As for the lack of grey background, we've tried this. If there was no such area, the header (which, in a few months, will be not scrollable and always visible at the top of the screen) would inevitably look... "lost", misplaced on this vast white background. Grey area gives a sense of framing. Regarding infoboxes, we are enthusiastic about using the newly blanked areas. We would like to make more steps in this direction. Bullet points #2 and #4 - these issues are on the radars of our designers. SGrabarczuk (WMF) (talk) 19:04, 26 August 2020 (UTC)

Rollback request

The "content width limit" is very controversial and I believe you have received enough negative feedback already to confirm that it is currently broken.
So, please revert this change on the test wikis for the time being. Xhamon (talk) 01:04, 12 August 2020 (UTC)

Peu d'intérêt...

Je suis un utilisateur qui consulte généralement wikipédia sans être connecté (parce que je bouge pas mal, change de PC, ou utilise la navigation privée). Bien qu'ayant remis l'ancienne mise en page en vigueur sur mon compte, je ne comprends vraiment pas l'intérêt de la nouvelle. J'utilise en général des écrans larges où la largeur de texte se trouve maintenant limitée, quand je pouvais auparavant afficher bien plus sans avoir à scroller. Au début, j'ai même pensé que mon navigateur ou mon PC avait planté tellement la qualité de lecture avait baissé.

Pourquoi changer cette interface qui fonctionnait très bien ? Et pourquoi imposer d'autorité ce changement ?

--Sombresprit (talk) 10:09, 12 August 2020 (UTC)

D'autant qu'il a toujours été possible de réduire la fenêtre du navigateur pour choisir une largeur de lecture inférieure. Et ça prend beaucoup moins de temps que de se connecter à un compte !! -- Calimeroteknik (talk) 19:02, 18 August 2020 (UTC)

Text width

Please make the text width maximum again. I have a non-magnified 1080p screen and I can only fit seven paragraphs on it.

What the heck is all the white space for anyway? Are you going to run ads? Does somebody think WP will become more relevant if it looks more like Facebook and Twitter? Is WP's readership now intimidated by long, formal texts? Or has Jimbo been bought off by the mouse scroll wheel manufacturers? 93.136.184.51 18:53, 12 August 2020 (UTC)

This. The huge columns of whitespace look hideous, such a waste of screen space - almost half the screen is wasted requiring extra vertical scrolling at standard screen resolution. Xaosflux (talk) 04:06, 13 August 2020 (UTC)

Ditto. Wide-screen support is still relevant for many readers and editors, including this one. For those looking for workarounds, en:wp:Village_pump_(technical)/Archive_183#New_look? has some suggestions. 24.151.56.107 17:35, 13 August 2020 (UTC)

• If this is what it's gonna look like, then it's not a "desktop improvement". My feedback is: don't do this.--Piramidion (talk) 17:40, 18 August 2020 (UTC)

Thank you all for your feedback. We have written up some responses to common questions about the width: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Frequently_asked_questions#Why_is_the_width_of_the_content_limited?_Why_is_there_so_much_white_space?. Please understand that we are at the very beginning of this project. There are features coming later on that will make use of the white space on the sides of the screen. AHollender (WMF) (talk) 13:49, 20 August 2020 (UTC)

The aloof tone of the answers makes me "wonder" if our feedback "might have been" dismissed out of hand... 93.136.37.250 21:19, 20 August 2020 (UTC)

Maybe check your own tone first? —TheDJ (Not WMF) (talk • contribs) 15:58, 24 August 2020 (UTC)

@AHollender (WMF) having to scroll more when there is blank space is not mentioned in that page https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Frequently_asked_questions#Why_is_the_width_of_the_content_limited?_Why_is_there_so_much_white_space It is easy to see that blank space mechanically pushes content down the page. I believe it is arguable that this is one thing that is wrong with white space. -- Calimeroteknik (talk) 02:33, 22 August 2020 (UTC)

@Calimeroteknik right, one result of limiting the width of the content is that the page gets taller and therefore you have to scroll more. However I would be cautious to list this as a negative result because I think it's quite difficult to accurately determine the effect of having to scroll more. I'm not trying to suggest that it's a benefit, but more so that we don't really know if it's bad, or even if we do think it's bad it's difficult to describe how bad it is. It could very well be a very slight drawback that doesn't warrant being mentioned, but once we do mention it then people might start latching onto that and saying "look it's not worth it because it makes the page taller". It would be great if we could find some research on this matter. AHollender (WMF) (talk) 14:05, 31 August 2020 (UTC)

It is always possible to downplay an inconvenient argument, and ask for more studies. However, we already know that it is possible to reduce text line length without limiting content width, by introducing text columns. This is not a cornelian choice between two evils. Calimeroteknik (talk) 11:46, 11 September 2020 (UTC)

Pourquoi changer ce qui fonctionne.

Cette nouvelle interface n'est pas du tout adaptée à la consultation de contenu sur ordinateur. La moitié de l'écran ne sert à rien, on est bien plus obligés de défiler, et donc de casser sa lecture pour voir la suite du contenu. Les écrans deviennent de plus en plus grand, mais le contenu affiché le devient aussi. La quantité de défilement nécessaire pour naviguer dans les pages les plus longues, avec l'ancienne interface était déjà bien grande, non pas qu'elle gênais, mais on pouvais avoir une bonne vision de la taille des paragraphes, d'un coup d'oeil, on pouvais rapidement voir quelles étaient les sections les plus fournies, avec cette nouvelle interface, la mon index va se fatiguer au vu des défilement à faire, surtout pour les utilisateurs qui n'utilisent pas les ancres dans le sommaire. Si je voulais consulter wikipédia mobile, j'irai sur m.wikipedia.fr, pas sur le site pour ordinateur. je me suis créé un compte uniquement pour revenir à la nouvelle interface, et je pense que je ne suis pas le seul.

Exactly, I made this account precisely because I could not stand using the new version of wikipedia. It's so narrow, I hope they will reconsider or to at least give the option to opt out of this new update. --Civicader (talk) 14:42, 15 August 2020 (UTC)

On a privacy/anonymity note, staying logged into your account makes it easy for Wikipedia to collect the history of pages you visit. This is indisputable fact. -- Calimeroteknik (talk) 19:00, 18 August 2020 (UTC)

Nouveau style wiki français horrible

Bonjour, le nouveau style du wiki français est vraiment très mauvais. Lorsque l'on lit un article du wiki sur l'écran du PC on a une énormes bande blanche de chaque côté de l'article. Sans déconner on perd pratiquement la moitié de l'espace d'affichage. Le changement est horrible, j'ai l'impression de consulté une version mobile sur un PC. On scroll down beaucoup plus qu'avant aussi, c'est assez pénible. Voilà mon premier problème.

Le deuxième problème c'est que j'ai passé environ 30 minutes à chercher la cause de cette nouvelle mise en page, je pensais que c'était un problème venant de mon PC. A aucun moment, personne n'a pensé a peut être mettre un bandeau d'information qui explique ce qui se passe? La manière de procéder me fait penser qu'on doit accepter le changement et se taire.

Troisième problème, je crois avoir compris que les personnes enregistrés pouvaient modifier l’apparence et revenir à l'ancien format, c'est très bien mais quid de la grande majorité, qui comme moi ne sont pas enregistré, on ne peut pas avoir cette possibilité? Doit-on accepter cette modification et se taire? j'ai juste le sentiment qu'on veut nous forcer à accepter quelque chose et franchement je ne pensais pas que c'était la mentalité de Wikipedia de procéder ainsi.

Pour moi ce changement de largeur rend la lecture des articles vraiment désagréable, pour être vraiment honnête je préfère aller lire les articles en anglais à cause du nouveau design plutôt que des les lires dans ma langue natale.

Mon dernier point, quand est-ce prévu d'avoir au moins une option pour avoir les pages aussi large qu'avant? Merci

voilà my two cents sur ce sujet.

Text columns instead of max-width

Given these clear and blocking regressions of max-width rules, I suggest to instead keep the width, but introduce columns within the text of the articles, like newspapers do. (using media queries)

This would reduce the number of characters per line, but not at the cost of:

• breaking large tables
• wasting a lot of screen space
• forcing people to scroll more

To conclude, the max-width limit brings nothing more than what was possible by resizing the browser window, which takes a split second.

-- Calimeroteknik (talk) 13:33, 20 August 2020 (UTC)

@Calimeroteknik thanks for taking the time to write up your idea. We're currently planning to experiment with adding a table of contents and/or page tools within the margins of the article, so that space is most likely going to be used for something. If none of those ideas end up working perhaps we can consider something like you suggest. We have also started discussing some reading accessibility features that would allow people to choose the width of the content. Please do stick around and continue adding valuable ideas like this one! AHollender (WMF) (talk) 13:56, 20 August 2020 (UTC)

I wish to make an explicit note here that I believe that any hostility to the changes in this discussion page to come from the regressions, and not from change in itself, or resistance to it, as people pushing that change will feel (consciously or not). From what I see in the workplace, working as an UX designer gets one to develop a specific bias, where any change seems more welcome than keeping the existing, for the sole reason that it is new. By suggesting something entirely new (text columns), I leverage that bias to steer the UX designer's effort towards net improvement of the interface, i.e. without accompanying it with regressions. I believe that the current proposed layout with max-width is a result of yielding to the temptation to break a few things just to fix one downside whose importance got overestimated (especially as it is fixed by a window resize). I mention this out of honesty, and also because I have (possibly unreasonable) hope it could be well-received, and useful. -- Calimeroteknik (talk) 14:37, 20 August 2020 (UTC)

User page of Antandrus

en:User:Antandrus user page looks best on 1024px 1280px width or more? I think our Wikipianist ain‘t going to be happy about the 960px max-width

—2003:E5:BF17:7000:E4CD:CE57:753D:EF8F 14:16, 20 August 2020 (UTC)

The max width only applies to the content area. The sidebar is 160px width. Last time I checked 1024px is less than 960+160. What am I missing? 157.131.76.233 22:24, 20 August 2020 (UTC)

Looking at said user page, I guess (s)he meant 1280px. I corrected it. --46.114.105.71 15:27, 21 August 2020 (UTC)

New content width limit wastes space on a large monitor

For a few days or weeks now, French Wikipedia has started using the new skin. My first reaction to this new theme is that the new content width limit is way too small, and this is especially shocking when using a large screen (I'm using a 27" screen with a resolution of 2560*1440). A rough measure with GIMP shows that the content is now only using 37% of the width of my screen, which looks like a waste of space. (See this comparison: https://twitter.com/s3phyca/status/1296903251753926657 )

I understand while reading Reading/Web/Desktop Improvements/Features/Limiting content width that there's a logic behind this modification. I'm wondering if the data used to come to the conclusion that a width limit is sensible may be old data, predating screens with very wide resolutions? I believe most desktop users have adapted to wider screens that may have seemed way too large at first, but now provide some good usable space to have data on screen.

If a content limit has to be imposed, may I suggest that it be a percentage of the width of the screen and not a fixed value in pixels?

This is only going to get worse with 4K or 8K monitors (although using Hi-DPI might/will mitigate some of this I guess)

Putting aside the number of characters per line (which seems to have some pretty strong sources suggesting a limit for easier readability), I think the real problem here is how much a page looks "empty" by using only a small percentage of the width of a screen. This really feels like a waste of space. I do not have a solution on how to improve that if putting a limitation of characters per line is so important. Maybe using a "columned" view (like newspapers) on very wide screens? Using that "wasted" space for non-text article content? (images, graphs, etc.)

If the character limit per line has to be imposed, then there is a need to find a use for all that space that is going to be freed up. FF7Sephiroth (talk) 21:28, 21 August 2020 (UTC)

I thought about this some more and one more thing is bugging me. This modification takes control away from the user. With the previous, full window width content, the user could choose to have it displayed in a narrower window if they feel that shorter lines is easier for them to read. The width limit now imposes that choice on them.

After thinking about it some more I understand how fewer characters per line makes lines easier to understand, however, most of the times I'm just skimming through articles, or searching through them with Ctrl-F. For that use I do not need the narrower lines, on the contrary I appreciate having more content displayed on one screen for skimming/searching. FF7Sephiroth (talk) 03:41, 23 August 2020 (UTC)

Keep other languages accessible (e.g. like in the mobile skin or in the mobile app)

Hi, I am really excited about this (see my tweet)! One suggestion: We should keep the links to other languages accessible, maybe in the way it's done in the mobile skin or in the mobile app. --Gnom (talk) 14:25, 23 August 2020 (UTC)

Have you tried it on a desktop screen yet? 93.136.146.80 07:25, 25 August 2020 (UTC)

@Gnom, thanks for your support. Regarding the languages, you will find the answer on the page that contains the descriptions of our future changes. The plan is to move these links to the article bar, and later, enable one-click access to a few preferred languages. SGrabarczuk (WMF) (talk) 23:15, 25 August 2020 (UTC)

What's the workspace area?

Hi. I've read your docs and for now I don't see any purpose for the "workspace" area except to limit line length. Do you plan to add stuff there, like the timeless skin has?--Strainu (talk) 08:21, 24 August 2020 (UTC)

@Strainu - good question! Yes, we are actually quite excited about the idea of using this space for other functionality. In the short term, we're currently exploring a few options we mention in the FAQ, such as a sticky sidebar, and the table of contents. OVasileva (WMF) (talk) 14:05, 26 August 2020 (UTC)

Logo

Please tell me how to include the Chechen logo in the new interface? Screenshot. --Takhirgeran Umar (talk) 11:08, 24 August 2020 (UTC)

Hi @Takhirgeran Umar. You can find the answer to that question above: this is temporary, and we are working on this. However, since the number of wikis is significant, it will take a couple of weeks at least. SGrabarczuk (WMF) (talk) 23:25, 25 August 2020 (UTC)

Hi, now I get it! Thank.--Takhirgeran Umar (talk) 00:31, 26 August 2020 (UTC)

Gnome 3

The new changes are from the same people that brought you gnome 3. Your donation money in action. 82.39.171.152 13:19, 25 August 2020 (UTC)

Is it actually the same people? Or are you just pointing a general trend among visible UX designers these days (since circa 2011)? -- Calimeroteknik (talk) 17:11, 25 August 2020 (UTC)

Maximum width

How Vector 2.0 looks on wide screens.

Hello, I am coming from the French Wikipedia to support the above messages from other users stating that the set maximum limit to the width of articles is a nonsense:

• Dynamic websites are supposed to be able to adapt to any screen, whether they be computer, tablet or smartphone screens. There is now a lot of white space left and right, without any purpose, and more scrolling to reach the content in the lower parts of articles.
• Giving registered users the option to revert back to the previous display is not an adequate solution for most readers, as they are not registered. Additionally, I guess that this option to use the "old" vector will be removed at some point.

I encourage you to revert back this width limitation, or at least increase the current limit. --LeJC (talk) 16:48, 25 August 2020 (UTC)

If the designers decide against this, I would encourage keeping an easily accessible version of the original vector like https://en.old.wikipedia.org like Reddit does with https://old.reddit.com . New Reddit style was also width limited and enough people complained that they have kept the old style as a subdomain. I wouldn't depend on cookie-based and account-based switching since it's a big pain in private browsing and such and generally a dark pattern. 93.136.146.80 20:20, 25 August 2020 (UTC)

Hi @LeJC, thank you for the feedback! We've outlined some of our rationale on why we chose this particular width in our FAQ. The short version is that we're trying to optimize a line width that can provide the best reading experience in terms of speed and comprehension based on a variety of studies done on this topic. I also want to add that, while there is nothing inherently wrong with white space, we are considering using this space for a variety of other functionality in the future such as holding the table of contents for example. This change allows us to begin exploring these opportunities. In terms of accessing the previous version while logged-out, we have not yet discussed creating a separate subdomain, but the site can be accessed on a per-page basis by appending the url parameter "?useskinversion=1", as in https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal?useskinversion=1 OVasileva (WMF) (talk) 13:59, 26 August 2020 (UTC)

Brilliant. The URL parameter useskinversion=1 is a step in the right direction. But, as suggested by others above, a skin setting stored as browser cookie would be even more useful, because the URL parameters useskinversion and useskin get discarded upon navigation on the next page. Not just for Wikipedia, but on other MediaWiki-powered websites too, in case the content column is planned to be squished on MediaWiki's default installation. Most MediaWiki sites I have seen use the default skin, i.e. Vector. --19:47, 28 August 2020 (UTC)

A subdomain would be even better than the cookie since it would be supported when browsing with cookies off such as in Firefox Focus. "Useskinversion" is a good idea but it's impossible to memorize and the reverting to old version when changing pages needs to be fixed ASAP 93.142.82.119 02:19, 30 August 2020 (UTC)

Hi @OVasileva (WMF), first, you are not really addressing the many messages of concern on this page, on the English Wikipedia Village Pump and its French counterpart (Le Bistro) and merely copy-pasting similar answers without really listening to the complaints. Second, for non-registered users, changing the URL is clearly not a viable solution. --LeJC (talk) 13:30, 2 September 2020 (UTC)

@93.142.82.119: The mutilated Vector 2.0 redesign will not just be a problem on Wikipedia, but also on MediaWiki-powered wikis from the rest of the Internet. And not every webmaster will bother creating an old. subdomain.

Web designers these days seem to forget that there is also a group of people who own wide displays. And 960px (!) is so 2003.

The redesign looks like vertical video on these wide screens. --10:11, 4 September 2020 (UTC)

Design suggestions for large tables

Pages with large tables (such as monument lists: ro:Lista_monumentelor_istorice_din_București,_sector_1) don't look nice with your changes. What are your design suggestions for such pages?--Strainu (talk) 20:38, 25 August 2020 (UTC)

@Strainu I believe this would be an issue for anyone with a screen that is more narrow than the table. Therefore I think it would be a good idea to introduce some kind of minimal markup/template style/something that limits the width of the table, adds a horizontal scrollbar, and gives some indication that there is more content. I've attempted a simple demo of this here: https://en.wikipedia.org/wiki/User:AHollender_(WMF)/sandbox/wide_tables AHollender (WMF) (talk) 19:26, 15 September 2020 (UTC)

Wow, it looks absolutely amazing, thank you! Indeed, the tables are a problem for mobile users as well.--Strainu (talk) 19:44, 15 September 2020 (UTC)

Talk Pages

Talk pages with long comments are already unwieldy on a wide display, how are they going to work when limited to 960px? Will talk pages be reworked in the future to help this?

Yes, talk pages are currently being worked on and we are collaborating with that team to ensure that we improve readability. Please see https://www.mediawiki.org/wiki/Talk_pages_project for more information. AHollender (WMF) (talk) 14:28, 31 August 2020 (UTC)

Add a dark themed Vector

While I appreciate the effort that the MediaWiki community is doing to improve Vector "for once in a decade", it would be great to at least provide all of these improvements in a separate variant of Vector that features a light-on-dark appearance (as in "a dark theme/mode"), just like what the mobile version of Wikipedia provides as of now. I would also accept that it be provided as an option not just for logged-in accounts but also for everyone, as light-on-dark designs are widely present almost on every device and it would be useful for readers that prefer to explore Wikipedia (or other Wikimedia projects for that manner) more comfortably with them toggled on. - AlejHerrBar2003 20:55, 28 August 2020 (Central America)

Hello AlejHerrBar2003. Dark theme (including dark theme for all) has been a topic for quite a long time. Unfortunately, it's not on the list of changes we're able to make in the close and foreseeable future. But oh boy, do we keep it in mind! SGrabarczuk (WMF) (talk) 11:51, 31 August 2020 (UTC)

@SGrabarczuk (WMF) I understand that a proper dark theme needs a lot of work because it would probably mess up other elements and their colors. However, would it be possible to change the vector skin to have a background of light grey instead of the blinding white color. Hako9 (talk) 00:51, 1 September 2020 (UTC)

That's an interesting idea, @Hako9, and sounds like one of the planned General aesthetic refinements. SGrabarczuk (WMF) (talk) 12:19, 1 September 2020 (UTC)

@Hako9 and @SGrabarczuk (WMF), I accept the idea of replacing Vector’s background with a light gray color, but what I suppose you didn’t understand was that a dark theme could be theorically achieved by creating another version of Vector, separate from the original version, that could be enabled by the user if desired on "Special:Preferences > Appearance", not having to modify Vector as a whole and only making it light-on-dark. Is there any limitation on MediaWiki as used by Wikimedia’s projects to theming beyond the 5 standard skins (which are all dark text on light backgrounds) that prevents a dark theme from even being possible? If not, I think it would be great decision to begin working on what I would codename "Darktor". ;) AlejHerrBar2003 09:21, 1 September 2020 (Central America)

It would be good to have this and white-on-black as options on the side, possibly as radio buttons in the sidebar. Perhaps that's how we could implement the max-width toggle as well. I'd oppose having it like black-on-#cccccc or white-on-black as default, as to cite another assumption in this thread few serious websites have this layout (since it makes reading tiresome in a bright environment). 93.136.73.58 20:07, 1 September 2020 (UTC)

w:White-on-black should have been the default on the internet all along. White backgrounds sttain the eyes and waste battery charge on mobile phones with AMOLED display, while dark backgrounds only makes the parts of AMOLED screens consume power that acutally show information. --10:04, 4 September 2020 (UTC)

A dark theme is not all that difficult to do with css but the problem for the WMF is that it could place too much of a burden on Wikipedia's caching system. Small wikis can use Extension:Theme (example). I like the idea of a Darktor skin too as it would eliminate the complexity and performance penalty of using the theme extension but there might be other reasons to keep the basic skin the same and just overlay dark css on top of it. Flounder ceo (talk) 02:15, 22 October 2020 (UTC)

Maximum width research, A/B testing

Like many people, I have an instinctual aversion to the maximum width, and am not yet convinced by the research/justification that's been given. The research listed in these pages is mainly at below 100 cpl which is out of the range being proposed; it's a big assumption that the conclusions from that research scale to our proposal. Furthermore, I'm not too convinced by the research that's been given, because en:Line length#Electronic text suggests that there's research supporting both smaller and larger line lengths, and the third paragraph to me implies that it should be a user preference (which is the status quo today).

Has any A/B testing been conducted, or is there a plan to? We need evidence proving that this proposal is an improvement before users will buy in to the change. The current conclusions are based on a lot of assumptions which need to be cleared up before going live. Thanks, M.nelson (talk) 11:05, 29 August 2020 (UTC)

@M.nelson I agree that more research should be done and/or found. We are indeed making some assumptions however I think it is worth being specific about the assumptions we're making. The first assumption is that if longer line lengths were beneficial to reading we would see them out in the world more often. I am hard-pressed to find a popular website, or any printed material, that exceeds the suggested line length range. I am not saying that everyone else is automatically right about line-length, but I would expect to at least find some examples of line lengths in the 200+ cpl range if that was indeed better for reading (if you can find some please post them here). The second assumption is that the extensive amount of research on this topic has intentionally been focused on the optimal range. Without speaking to the folks who conducted the research (and I have started to reach out to them) there is no way of knowing why they didn't study longer line-lengths, but I do feel like this is a relatively safe assumption again considering how many studies are conducted within the same range. Lastly I think it would be valuable for you (and others) to further investigate your own personal aversion to the max-width. We have had some great conversations with those willing to dive a bit deeper on this topic and a few folks have found that there are other factors (mainly frustration about blank space) that are informing their opinions, rather than an actual dissatisfaction with shorter line-lengths in and of themselves. AHollender (WMF) (talk) 14:26, 31 August 2020 (UTC)

Is it reasonable to ask critics for evidence for their assumptions when you consider your own assumptions to be above the need for evidence? 93.136.73.58 20:02, 1 September 2020 (UTC)

I'm not sure I understand your question. Would you be willing to re-phrase it? In this case we (the web team) and M.nelson are both making assumptions about line length. I was attempting to clarify and explain the assumptions we (the web team) are making. AHollender (WMF) (talk) 14:10, 3 September 2020 (UTC)

Agreed. I just fail to understand how having to seek the beginning of the next line more often is supposed to improve readability. It does not.

Also, web browsers these days have a reading mode, and there is already a way to have limited content width: The minerva shortcut at the bottom of the page, also known as Mobile view. --79.249.151.110 09:57, 4 September 2020 (UTC)

The new interface is worse

• Yellow: Useless button.
• Green: The Wikipedia logo is modified; this is not necessary.
• Red: Useless blank spaces. ("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." But the desktop interface must be independent and the mobile interface must be independent).

The current skin is fine. --NGC 54 (talk | contribs) 15:04, 30 August 2020 (UTC)

Hello, @NGC 54. The button is used by readers who would like to focus on reading Wikipedia (read more). The modified logo allows us to make the header persistent at the top of the screen (read more). In future, blank spaces could be filled with... something. We aren't ready to make decisions about that yet, but volunteers rightly whisper that infoboxes or categories could potentially fit. We will examine that in 2021 at earliest. SGrabarczuk (WMF) (talk) 11:58, 31 August 2020 (UTC)

@User:SGrabarczuk (WMF) At this moment there isn't a way (from user preferences) to remove this blank spaces? And force the page full wide when you close the menu? --Yacine Boussoufa (talk) 15:55, 31 August 2020 (UTC)

@Yacine Boussoufa, see the Max-width gadget section! SGrabarczuk (WMF) (talk) 20:26, 31 August 2020 (UTC)

I hope that "something" doesn't means "adds". --NGC 54 (talk | contribs) 10:02, 1 September 2020 (UTC)

That would be quite a revolution, wouldn't it? No, rest assured, nobody is even dreaming of putting ads there. SGrabarczuk (WMF) (talk) 12:27, 1 September 2020 (UTC)

While I'm sure Wiki isn't going to run ads, I can't think of anything that could fill that space on a 1080p or 1440p monitor (including infoboxes, which are barely 250px wide). Shouldn't we delay implementing the whitespace until we figure out what to put there? 93.136.73.58 20:11, 1 September 2020 (UTC)

Yes, I agree. Patriccck (talk) 11:40, 2 September 2020 (UTC)

"In future, blank spaces could be filled with... something." This is quite telling: we are discussion the implementation a major change to the reading interface (the way articles are displayed), and no one even thought about half of the implications. Apologies for being blunt, but this is a half-baked update. --LeJC (talk) 13:30, 2 September 2020 (UTC)

Agreed. On the mutilated redesign, the content just appears “in the middle of nowhere”. It is not stamina in place like legacy Vector / MonoBook. --10:00, 4 September 2020 (UTC)

The blank space on the both sides looks bad, especially on wide screens. There is no reason to leave these areas empty. Draceane (talk) 18:56, 4 September 2020 (UTC)

I don't agree that red is "useless blank spaces." Most of the content served under the Vector skin are text articles, and for text articles there is an optimal w:line length, too narrow or too wide will negatively affect the reading speed. For example if too wide people will have trouble seeking the next line. IMO the "current" width is too wide. --Emphrase (talk) 11:40, 25 September 2020 (UTC)

J'accuse!

Fr:Cette libération d’espace écran, de la nouvelle interface, est incompressible ; sauf si cet espace est utile à autre chose. Vous êtes entrain de mettre en place les futures espaces publicitaires. Prouvez votre bonne foi en abandonnant ce projet nauséabond.

En:This freeing up of screen space from the new interface is incompressible; unless this space is useful for something else. You are in the process of setting up future advertising spaces. Prove your good faith by abandoning this nauseating project.

It:Questo liberare spazio sullo schermo dalla nuova interfaccia è incomprimibile; a meno che questo spazio non sia utile per qualcos'altro. Sei in procinto di allestire futuri spazi pubblicitari. Dimostra la tua buona fede abbandonando questo progetto nauseante.

De:Diese Freigabe des Bildschirmplatzes von der neuen Benutzeroberfläche ist inkompressibel. es sei denn, dieser Raum ist für etwas anderes nützlich. Sie sind dabei, zukünftige Werbeflächen einzurichten. Beweisen Sie Ihren guten Glauben, indem Sie dieses widerliche Projekt aufgeben.

--Archaeodontosaurus (talk) 05:43, 2 September 2020 (UTC)

Suggestion for a new text layout

Hello. Since changes are being to Vector like text appearance, I would like to recommend implementing or making beta feature of this layout. When I use this, I find it more compact and easier to read articles. Plus, with ToC on the left side, infobox on right, images not interfering with the text, the layout looks great, so much I had to recommend it. Maybe you can do something with this, and who knows, make it better. Hopefully you'll agree. 1989 (talk) 11:56, 4 September 2020 (UTC)

French Wikipedia looks so 2005.

With its fixed-width layout, French Wikipédia looks like a site designed years ago. With the top header overflowing in the right margin, it even looks broken. And the functionality behind the top left button is actually broken: it removes the menu, but forgets to maximize the content! If the idea was to provide a read-mode, then it should additionaly minimize the huge footer and the announcements. I expect much more from the read mode of Wikipedia. A button to switch into a multi-columns layout could be cool. At least, it would provide a new functionality instead of removing the fluid-layout functionality. And it would show to the world a new kind of layout instead of mimicking websites from 15 years ago. Marc Mongenet (talk) 23:57, 4 September 2020 (UTC)

Hi @Marc Mongenet, thanks for your ideas! As you can learn by reading the Features page, the changes you can see on French Wikipedia are just first of a series. More will come, and the layout will eventually be more different from the Legacy Vector. We would also love to make further changes beyond what's described on the Featured page, but this is not under any debate now. SGrabarczuk (WMF) (talk) 13:14, 7 September 2020 (UTC)

Blank space on both sides

Hey all, I'm sure it was mentioned here before, but...to add my point of view, I'll re-add it anyway. I hate the blank space added by the new Vector. It literally feels to me like something (ads? Template:Smile) failed to load, in another words, my brain tells me "there should be something". The behavior with the special pages (all width) is much better IMO. --Martin Urbanec (talk) 18:18, 6 September 2020 (UTC)

White space

I want to also express my opposition to the white space on both sides of the text. I much prefer having longer lines of text as opposed to shorter, and find it frustrating to have to keep scrolling and changing lines while reading. I would much prefer to keep the current style as the default, and allow users to shrink the width if they would like, not the other way around. Kaiser matias (talk) 20:50, 9 September 2020 (UTC)

I very much agree. Let's keep what we have now. Why do we have wide screen monitors? To see a white space? Not everybody is reading wiki on a mobile phone. KPX8 (talk) 17:46, 24 September 2020 (UTC)

Neato!

To balance out the criticism here, I just wanted to say good job on the redesign so far! Vector in general is really outdated, so I'm glad to see it finally get a facelift.

Limiting content width and hiding the side bar are already really nice. A lot of the people here commenting about the added width limit seem to forget Vector was designed and tested for 4:3 monitors (yes, it's really that old!). Maybe this'll finally get editors on Wikipedia to stop using tables so much (or at least reduce the columns; they look no bueno on phones). I can't really think of any other site that still uses tables as much as Wikipedia does.

Anyway, mini rant over. :P Nice job again, I especially like the upcoming, cleaner user menu. Hope you guys don't have to compromise too much for power-editors in sacrifice of the average reader's needs. I don't know what it's like on Wikimedia, but FANDOM (a.k.a. Wikia) said earlier this year that 99.95% of their readers never make an edit. Stafyfan53 (talk) 19:56, 10 September 2020 (UTC)

Thank you! SGrabarczuk (WMF) (talk) 13:05, 14 September 2020 (UTC)

This update it is not for readers. If it would have been for readers, the content area would not become smaller. --NGC 54 (talk | contribs) 09:27, 18 September 2020 (UTC)

I think we should learn from politics about what happens when we start speculating about what the silent majority wants. Take it from me, a reader half of whose involvement with Wikipedia this year is probably on this freaking page, I like the new foldable menu but I defo don't like the narrow text, no ty. 93.138.95.25 22:29, 19 September 2020 (UTC)

Overlaps on wikimedia

As seen on https://fr.wikipedia.org/wiki/Fichier:AniarasKelpoKalle.jpg there are overlaps with some buttons and the title in the experimental layout, which are not present in the normal version https://en.wikipedia.org/wiki/File:AniarasKelpoKalle.jpg

I would like to stress that I do not believe the French wikipedia is the right place to test experimental designs that have not been thought through.

To further clarify, I posit that it is possible to predict problems such as overlaps in a layout, by thinking of boundary conditions as an integral part of its design. For this, it is also necessary to not yield to the temptation of using a layout that works only in certain cases, but not all. "Ironing out the bugs later" is a scarily frequent trend in the industry, which doesn't make it any more desirable. Calimeroteknik (talk) 11:37, 11 September 2020 (UTC)

@Calimeroteknik, would it be possible for you to add a screenshot? Without knowing the details such as the size of your screen (in pixels at least) it's difficult to find out what problem you're referring to. This might also be related to the language of your interface, or other personal settings. Thanks in advance. SGrabarczuk (WMF) (talk) 13:04, 14 September 2020 (UTC)

@SGrabarczuk (WMF): This sounds a lot like phab:T261279--Strainu (talk) 19:48, 15 September 2020 (UTC)

Yes, same as illustrated there indeed. It was blatant, and did not depend on screen size, due to the max-width rule, otherwise I would have provided more details. Seems to have been "ironed out". On this topic, I don't think that "ironing out" the bugs after the fact is anywhere near a valid method for software development. Flexible user interfaces need to be thought from the ground up with a logic of geometrical constraints to be sure they'll always display fine. Calimeroteknik (talk) 13:27, 10 November 2020 (UTC)

I think this is referring to the image with width 800px not being constrained to the page. That is an easily fixed bug. Jdlrobson (talk) 06:16, 18 September 2020 (UTC)

Colour changes

Is there any way I can find a list of all the colour changes they've made to MediaWiki since 2016? Since I've noticed a number of colour changes. #efefef is now #f8f9fa. #aaaaaa is now #a2a9b1. #606060 is now #54595d. And #888888 is now #72777d.

I don't have an issue with the colour changes on most sites that use newer versions of MediaWiki. But for those sites that I want to preserve the legacy colours on, it would be great if I had a full list so that I can revert all the colour changes on those specific sites where I want to preserve the legacy colours. Currently there are only two sites where I want to preserve the legacy colours, so it isn't that I hate the newer colours. ― C.Syde (talk | contribs 10:13, 20 September 2020 (UTC)

I believe this is a question to @Volker. SGrabarczuk (WMF) (talk) 10:22, 21 September 2020 (UTC)

@C.Syde There has been no color consistency at large in MediaWiki core and products before Design Team under my direction and implementation work has come to a unified color palette, that is now universally applied in all Wikimedia Foundation interfaces. For the actual changes we've went as careful as possible and made changes as subtle as possible and at the same time improved readability and accessibility where needed. This task should provide you an overview about before and after colors changes. --Volker E. (WMF) (talk) 12:12, 23 September 2020 (UTC)

Just what I needed. Thanks! :D ― C.Syde (talk | contribs) 00:41, 24 September 2020 (UTC)

Remove margins on wide-screen sizes

Is it possible to easily remove the margins when the view is past a certain point? If it wasn't for this I'd switch from legacy in a heartbeat Thepenguin9 (talk) 01:25, 22 September 2020 (UTC)

@Thepenguin9, correct me if I'm wrong - your idea would be to have the text covering 100% of the screen width? SGrabarczuk (WMF) (talk) 19:35, 23 September 2020 (UTC)

@SGrabarczuk (WMF) yes, utilise 100% of the width if the user wishes so the extra screen space is not "wasted" Thepenguin9 (talk) 23:59, 23 September 2020 (UTC)

@Thepenguin9 - User:Jdlrobson has made a gadget that allows you to toggle between full and limited width: Talk:Reading/Web/Desktop Improvements#Max-width gadget. OVasileva (WMF) (talk) 09:11, 24 September 2020 (UTC)

Fixing max-width

I've written a CSS user style for the max-width issue. It doesn't require being logged in on Wikipedia. You can download it from https://pastebin.com/5jA70LHR, install instructions are provided. It is open-source, no scripting or compilation. Currently it works with Waterfox, Pale Moon and probably Firefox. Vectorman007 (talk) 22:35, 22 September 2020 (UTC)

Mostly good designs but a couple bad choices

The sticky header is a waste of vertical space. It's never been a problem to scroll back up and just type my next search there if I want. Or sometimes I'll just type it into my browser bar and end up at Wikipedia again.

The collapsible sidebar doesn't solve any actual problem. If you're already moving some of its contents to new spots, then there's no reason to further diminish the sidebar. I find it very hard to believe that people can't ignore the small column (tools) and focus on the big column (article).

These two changes in particular just seem like hanging on to fad UX. I believe Wikipedia can improve, but at the same time it's been a success as it is. I'm usually refreshed when I land on Wikipedia and don't see modals and sticky divs and such. The design is simple and straightforward already. — Preceding unsigned comment added by 2600:1700:7261:6ad0:7cdd:7d59:1bc7:9aff (talk • contribs) 112:48, 23 September, 2020‎ (UTC)

Auto adjust font size

I like the line length limitation. I am older and my eyesight getting worse. I would like to be able to scale up the font to fill the window's width rather than add blank panels on the sides which is useless space for me. Robert.Harker (talk) 21:40, 23 September 2020 (UTC)

Tabs and the left whitespace

One of the things that irked me when I tried the new desktop interface is that, with the addition of the whitespace on the left, the top left tab (normally "Page") just cuts off into white. It doesn't even have a thin blue border line, which it almost surely should, given that such border lines exist for the other tabs. Could this be addressed? Sdkb (talk) 22:09, 23 September 2020 (UTC)

Min-width (forced horizontal scroll bars in non-maximized browser windows)

I have a problem with the min-width, rather than the max-width.

See, already I do not (usually) browse with my browser maximized. Not only does maximizing make the lines too long (as you've correctly observed), it also prevents me from looking at two things at the same time (to e.g. cross-reference articles).

Instead, I typically split the difference, with two windows each taking up half the screen. (You will note that such side-by-side arrangement is a built-in feature of both Windows and many Linux distros, and there are apps like ShiftIt for macOS to do the same.)

On a 1920x1080 screen, that means 960 pixels for each window, which I'm sure you'll agree is an entirely reasonable width. However, in your design, the text itself (main#content.mw-body) appears to have a minimum width of 930px, and with padding and margins on top of that, that means I'm now forced to look at a horizontal scrollbar on every page.

TL;DR: Please make sure to support "screen sizes" down to 960px wide, because not everybody wants to maximize their browser window.

– Kwi (talk) 12:06, 24 September 2020 (UTC)

The min width is temporary while we shuffle around certain pieces of the UI as at lower resolutions the existing UI hits problems with certain gadgets due to the tabs. We are currently in the process of moving the search out of this area to make more space available. Once that's done, this should be relaxed or possibly removed. I just want to make clear that this was a developer decision rather than a product decision to make this transition easier and does not reflect the final product. Jdlrobson (talk) 15:31, 24 September 2020 (UTC)

Glad to hear it. Good luck with the redesign, then; I am looking forward to the end result. :-) – Kwi (talk) 18:56, 1 October 2020 (UTC)

I actually like the redesign

Didn't expect this to happen, but I actually like a lot of the new features. The redesign will make desktop Wikipedia more reader-friendly (e.g. with max width), plus it adds a sticky header, which is something I've wanted on wikis for a long time. It also puts Tools in a much more sensible place so that it's more consistent with gadgets like MoreMenu. — pythoncoder  (talk | contribs) 13:45, 24 September 2020 (UTC)

Sticky header? The timeless skin had this since many years, and it has a max-width too, which is 1261 pixels according to this section. --84.147.33.92 16:07, 26 September 2020 (UTC)

Limiting content width is not a Desktop Improvement

Until now , the wikipedia layout is one of the few websites in a mobile only infested world i could read without my blood pressure going up because over 50% of my screen is just whitespace. I made a quick dive into the french wikipedia with the new design and there it is even worse - the principal content , the main text column - is less than 25% of the available space ! (on a 4k 27inch screen. I measured it...)

Desktop nowadays is not the 600-1024 px range given in the rationale of the improvement but several screens of minumum 1920px or full 4k resolution. And i want information on this screen estate and not an oversimplified peephole.

Of course the current result of long lines is far from optimal , but the solution of just making the browser window smaller ist only a mouse move away. (Whereas getting rid of whitespace forced upon me ist not so easy..) As long as a true desktop improvement with an upward responsive web design (multiple columns,....) ist not available, just do not touch the existing width for questionable gains but evident disadvantages. — Preceding unsigned comment added by 2001:16b8:304f:800:39d2:2429:b3d4:b650 (talk • contribs) 13:45, 24 September, 2020‎ (UTC)

Horizontal overflow issue

Thanks for addressing the line-width issue in the new design, though I noticed a somewhat subtle issue.

The new design seems to be assuming a fixed screen width. If you resize or zoom in on a wikipedia page, for example Wikipédia, under the new design, a horizontal scroll bar will appear due to overflow. This makes the new design less responsive, which can cause some issues on vertical monitors and when using the zoom feature in web browsers. Compare the old layout and the new layout at 200% zoom level on a 16:9 monitor.

Old layout.

New layout. Notice the page is clipped horizontally, especially the navigation bar at the top.

You could also notice this issue using the responsive design view in Firefox. The overflow occurs at 1005px for the new layout, which is around 200px higher than the original 799px.

The new design changes the line width without changing the font size, so it is still often necessary to zoom in to see the text clearly, while the overflow issue mentioned above negatively affect the experience when using Wikipedia zoomed in.

This might also be the reason some people complain about the narrower layout. The problem is less about the line-width, but the fact that it breaks the zoom-in feature in web browsers.

I hope this issue gets fixed in the final version.

p.s. I made a much smaller typographical rehash of wikipedia called wikipedia.rehash a while ago. It address the same issue without breaking the zoom feature. I hope its source code and design could be helpful in the final version of this new design. --Krasjet (talk) 23:22, 24 September 2020 (UTC)

@Krasjet Thanks for your comment. We will be removing the minimum width soon, which will resolve this issue. See Jdlrobson's response here for slightly more context. Regarding wikipedia.rehash — wow, that is such an awesome modification. I was wondering if you've got any useful information regarding line-length research that studies the longer line-lengths that your project solves? I seem to have hit a dead-end of sorts, which I've described here: https://phabricator.wikimedia.org/T261174. Cheers 69.5.116.23 15:43, 28 September 2020 (UTC)

Max width on widescreen monitors

Even though there have been quite a few comments about this topic already I want to leave my own personal impression on this here.

I simply do not understand the reasoning behind making the content a fixed PIXEL VALUE in 2020!
Seriously.

Desktop monitors nowadays are not 1024 pixels wide anymore. Full HD (1920 PX) is pretty much the current standard for most people and more and more people use 2k or even 4k monitors now.
With these monitors the new Vector design is a total waste of space and articles look completely ugly since 75% of the page is just blank white space.
And even though some of the editors here are for some reason trying to argue that "White space is not a bad thing": Yes it is.
It is malpractice in webdesign and if you would do that as a professional webdesigner at an agency you would probably lose your job.

Now to the more positive things:
Having a fixed width to limit the line length is (imho) not an entirely bad thing. If it is done right!
Limiting it to a fixed pixel value is definitely not the right way how to do it.
Instead it would be more reasonable to limit it to a percentage of the readers screen width. This is easily doable with current CSS.

For example having the content at 75% of the overall screen width still gives more than enough room on the sides for the planned features like content tables or other sidebars while not making half the screen an empty void.
Here is an example of how the page looks on a 2k monitor (2560 px width) with the 960px content width vs. 75% content width: https://imgur.com/a/eCCM9U1
The 75% width keeps the lines shorter to a more readeable length while still maintaining a reasonable page width even on widescreen monitors.

For the edge case of ultrawidescreen or super small monitors CSS media queries could be used to limit the page width to some fixed value so that the page does not get too wide or too narrow.

But fixed 960 pixels? In 2020? With all the options and possibilities of responsive webdesign? Come on. It's not 2005 anymore...— Preceding unsigned comment added by Vastrox (talk • contribs) 03:28, 25 September, 2020‎ (UTC)

Not only that, but pixel widths do not scale when you zoom from the browser (pixels are pixels), but em widths do. 98.207.79.51 05:51, 2 October 2020 (UTC)

Can't stand the new forced narrow look with a ton of white space. Longer lines with less need to reposition one's eye as much is way better. I don't want to have to look down to the next line every few words. It is a shame, I would often come to wikipedia to read, only on desktop (I don't own a phone, couldn't personally care less about phone users and how their demands override everything - very inconsiderate), but I will never use wikipedia again. I refuse to even look at pages that seem so inefficient, new and "improved" (for no reason mind you - don't fix it if it ain't broke!) and ugly. I would rather let my question go unanswered, or walk all the way to the library to find out. Very VERY bad change. Not sure who in their right mind would think this was good.

But then again, not sure why wiki is even asking for comments and feedback, considering no matter how many people rage against it and utterly hate it, they will stick with it... pointless pretend consideration of their users while they plow ahead anyhow. Very disingenuous. — Preceding unsigned comment added by 70.75.81.228 (talk • contribs) 03:20, 4 November 2020 (UTC)

Max width fix for logged out users

Since it doesn't seem like logged out users can easily disable max width, I've written a CSS user style for those who want to do that. You can download it from https://pastebin.com/5jA70LHR https://pastebin.com/JypKbXqV, install instructions are provided. It is open-source, no scripting or compilation. Currently it works with Waterfox, Pale Moon and probably Firefox. Vectorman007 (talk) 00:55, 26 September 2020 (UTC)

Thanks for writing this up. Can confirm it (mostly) works for Firefox 80.0.1. I've never edited .css file before so here's a walk through for anyone coming after:

• Enable .css in Firefox: by typing about:config in your address bar, hit "accept risk and continue". search for "toolkit.legacyUserProfileCustomizations.stylesheets" and click the arrows to toggle to true.
• Find the right place for the file: in firefox, hit the menu bar in the upper right hand corner, select "help" and then select "Troubleshooting Information". On that page will be a list of items, and within that list "name, version, build id,.." will be "profile directory", click the button next to this labeled "open directory". Within this folder, make a folder named "chrome" (if it doesn't already exist)
• Inside that chrome folder, create a text document, copy Vectorman007's script inside, and then save the result as "userContent.css"
• Restart Firefox. The full text width should be back.

A bug to be worked out: the sidebar overlaps with the article text. Forbes72 (talk) 20:59, 28 September 2020 (UTC)

Thanks for the extra instructions and happy that it works on Firefox. The sidebar problem exists now in Pale Moon too. The new Vector source code was changed after I wrote the fix. I've added a new link with an updated version. Known problems: horizontal scrollbar (because the page is somehow 15px too wide), some extra lines and empty space under the page footer. Vectorman007 (talk) 03:39, 2 October 2020 (UTC)

So far the script is only set to work on fr.wikipedia.org. If anyone has a list of websites with new Vector updates, I'd appreciate a message :-) Vectorman007 (talk) 03:41, 2 October 2020 (UTC)

Found the list of websites, script implemented with varying degrees of success, will fix later. Also fixed a bug in page history view on French and Basque Wikipedia. Same link. Vectorman007 (talk) 21:49, 2 October 2020 (UTC)

A few suggestions

TL;DR ==>

I think the development of a new user interface can use the results of the many researches done on how to make a webpage more focused on reading, more clean, considering that Wikipedia is effectively an online reference book. With focusing on how to make the whole webpages more clean and with more focus on reading, the UI design of the webpage and also what font face to use. Also it would be probably good to think about ease of access features for people with disabilities.

The long version ==>

Historically speaking, no other book of reference has been this massive, most recent and updated, and as this detailed and coverage as Wikipedia and this is the result of many human hours and works.

It is very amazing that the community has decided to revamp the user interface. And I thought maybe share a few ideas and thank you for the opportunity.

One thing that is super nice about Wikipedia’s current interface is that it works even without JavaScript and we probably might want to take that under consideration during the process of making a new interface, to keep this body of knowledge as accessible as possible.

With that in mind, there have been many researches done on how to make a webpage more engaging and easier to focus on with changing the UI. Using or at least considering these researches in the design would ultimately result in more spread of knowledge, because the readers would focus much better on the text and actually ‘remember’ and ‘learn’ the material, which this spread of knowledge was and still is the original goal of Wikipedia.

Some articles:

• https://www.uxmatters.com/mt/archives/2010/04/designing-with-the-mind-in-mind.php
• https://arxiv.org/ftp/arxiv/papers/1401/1401.6365.pdf
• https://iopscience.iop.org/article/10.1088/1742-6596/1533/2/022040/meta
• https://ieeexplore.ieee.org/abstract/document/5451619/
• http://www.few.vu.nl/~hans/publications/y2002/SIGDOC2002.pdf
• https://academic.oup.com/iwc/article-abstract/15/4/539/663119
• https://dl.eusset.eu/bitstream/20.500.12015/2405/1/00204.pdf

Of course much more research can be found by either looking the references of the articles above or what articles are referencing these, or by just looking for new material.

Also the font face of the web page plays a major role in readability and how effectively readable and mentally engaging it would be for the end user:

• https://files.eric.ed.gov/fulltext/EJ1067757.pdf
• https://prism.ucalgary.ca/bitstream/handle/1880/26040/31338Connolly.pdf?sequence=1
• https://files.eric.ed.gov/fulltext/EJ1105535.pdf
• https://cognitiontoday.com/2018/05/font-psychology-research-and-application/
• https://www.researchgate.net/profile/Michael_Gasser/publication/237229931_The_Influence_of_Font_Type_on_Information_Recall/links/0046352ffbb8566bd4000000/The-Influence-of-Font-Type-on-Information-Recall.pdf
• https://journals.sagepub.com/doi/abs/10.2466/pms.106.1.35-42
• https://www.superarladislexia.org/pdf/2016-Luz%20Rello-Fonts-taccess.pdf

Apparently using the right font face can increase information recall.

Also it might be a cool idea to embed in a few ‘ease of access’ features for people with disabilities built right in. Like reading aloud using online open source TTS services.

Aside from that I personally think If almost all the options, probably aside from the search bar, are moved into a collapsible sidebar to make the articles less crowded it might be a cool idea.

Thank you. — Preceding unsigned comment added by Ironnail (talk • contribs) 20:16, 25 September 2020‎

@Ironnail, I would like to at least explain some of the quirks of how text appears in Wikipedia.

TL: Wikipedia uses the browser's defined sans serif and monospace fonts to display the text on its articles. These defined fonts can be changed, meaning that if you want to use a specific font, you can perfectly do so through the browser's settings. I also hope that accessibility tools be ready for use on Wikipedia anytime soon. That is all.

Further info: Wikipedia uses the "sans-serif" font-family string to input the text you see when you read an article on the font set as the sans-serif font by the browser, depending on your OS this font can be Arial (Windows), Helvetica (Mac), DejaVu Sans (most Linux browsers), or anything else that the user chooses on the browser's settings (but remember that if a font doesn't have as much international or literary characters it will have some glyphs replaced by the "standard" browser-defined font [that would be Times New Roman or Liberation or DejaVu Serif or even anything else too]). For the titles, at least on the Vector theme, Wikipedia uses Liberation Serif (common on Linux) first, then Georgia (common on Windows and Mac, doesn’t have a lot of literary or international glyphs), then Times (in case Georgia were removed), and then if none of these fonts is detected, it resorts to the "serif" user-defined font. In MonoBook the titles use the same font as "sans-serif". For monospaced strings (that is programming code or similar present in technology articles), it uses the "monospace" browser-defined font, for example Consolas (Chromium in Windows), Courier [New] (Internet Explorer), Liberation or DejaVu Mono, and for the eleventh time it can even be another user-specified font. In the context of glyphs for alphabets beyond Latin, browsers have separate font options depending on the language (no font can have the same glyphs for everything), so they can't be user-modified unless you use an advanced add-on (for example Advanced Font Settings for Chromium). Since the only place where Wikipedia has set fonts is on the titles, letting people have a reading font ready from the get-go and use it anywhere in Wikimedia's projects helps people who need to use a special font to read text, especially in case of reading issues. So no sir, Wikipedia's font face is not on their end, it's on your browser's font settings. If you want to use any font you consider appropiate, go ahead, find font settings in your favorite browser, set your favorite font in the "sans-serif" font menu, and be thankful that Wikipedia allows everyone to use their font. Honestly, I do consider your idea of including ease of access utilities ready from start is a pretty good idea, and I hope you do get replied about it.

This was --AlejHerrBar2003 (talk) 14:43, 12 November 2020 (UTC)

@AlejHerrBar2003 Thank you so much for letting me know about the fact that Wikipedia actually allows the users to pick the fonts on their ends. I have actually been using Times (to be honest something that looks very similar to times but is not Times) my self for years by setting the settings that you mentioned. So yes I am aware that the users get to pick the font by altering their browser settings. However I mean that considering many open font projects or projects like Google fonts, it may be possible to run a public study with volunteers from Wikipedia, I know I would volunteer, to take part in a "font readability and how much a specific font enhances information retrieval" study to pick the best font for Wikipedia to spread knowledge and make people remember it as much as possible. Again I know the users have the freedom to pick their own fonts, but Wikipedia using by the default the "best font for learning" is probably a cool feature.

I am mostly suggesting to design an interface which is best geared towards learning and enhancing people's engagement with information and enhancing their learning, when they are using Wikipedia. A very crowded, colorful and scientifically unproven interface will probably ruin the ultimate and original objectives and purposes of Wikimedia foundations, the prime of which was to spread knowledge to every corner of the world and free access to Information. that is all I am trying to say :) — Preceding unsigned comment added by Ironnail (talk • contribs) 20:16, 25 September 2020‎

Whoops! I thought you said "I hope that Wikipedia implements this font for this or that", but I now understand your concerns over the UX of Wikipedia. Honestly, my only nuisance when it comes to the layout of Vector is yes, the left bar containing commands; however it can be killed in the new Vector with the '<<' button above, although the Wikipedia logo, the search bar and user commands (User: page, Preferences, Contributions...) still appear. If only there were a way for these to disappear, that would be great. Colorful? Yes, those commands are in blue, and links to other articles are blue too, because ever since Internet Explorer blue and purple are the standard colors for hyperlinks. Crowded? It’s an encyclopedia, articles shall therefore contain lots of words to talk about their subject, however if you talk about the left bar, yes, that’s too much options for one single bar. I would place some of these commands (Linking here, page info, cite page, info in other projects and languages...) in a button next to the Watch star (unless of course you also insist on killing the Read and Edit and Watch buttons and leave only and exclusively the article itself). I can only say this: I am not the people who are updating Vector "for once in a decade", so I can’t help out with making Vector the way Ironnail asks for. cya imma sleep --AlejHerrBar2003 (talk) 03:00, 13 November 2020 (UTC)

Infoboxes

A big area that needs overhaul is the infoboxes. In 2013 it seems there was a proposal for improvement, with WMF making mocks for a redesign, at Streamlined Infoboxes (Pginer-WMF, Vibhabamba). I think infoboxes are pretty representative of the design in general, so a change to them would be both helpful and noticeable. Would it be possible to consider revisiting Streamlined Infoboxes in these desktop improvements, or is it too far out of scope? ProcrastinatingReader (talk) 12:57, 29 September 2020 (UTC)

This is definitely beyond the scope of this project and these very desktop improvements. However, we're positive we would very much like to revisit more existing/previously proposed features... when this project is finished. SGrabarczuk (WMF) (talk) 21:51, 30 September 2020 (UTC)

The fact is we need help to develop and translate 100 % Wikidata infoboxes able to work on various Wikipedias, especially small Wikipedias where we have a lack ok users but quality users. Jérémy-Günther-Heinz Jähnick (talk) 15:56, 2 October 2020 (UTC)

icons instead of text only

So far, moving the making search bar, and making the sidebar collapsible was a reason for me to look into Vector again after using Minerva Neue for the desktop for some time. Still, Vector is cluttered with UI text — especially in the sidebar —, that you have to actively scan instead of using easily visually comprehensible markers — icons. Will there be a move towards more icons or icons+text as part of this redesign? --CamelCaseNick (talk) 02:23, 2 October 2020 (UTC)

Skin:MinervaNeue appears somewhat more functional when viewed from desktop than mobile, but still not as much as other skins. Minerva also uses Special:MobileDiff without including the page title inside the URLm

Maybe Skin:Timeless could adapt icons for the side bar, like they did with the edit/history/etc. buttons. --79.249.152.18 02:17, 4 October 2020 (UTC)

User's panel

I don't like the fact that part of the user bar goes down. Maybe it would be better from top to bottom?.--Takhirgeran Umar (talk) 13:52, 10 October 2020 (UTC)

@Takhirgeran Umar, this is a step towards making the header fixed at the top of the screen. The space on both sides will stay blank for some time, until, after the end of this project, it's established what could be displayed there. Surely, it won't be the user menu, because this one will become a drop-down. SGrabarczuk (WMF) (talk) 11:07, 14 October 2020 (UTC)

A note of encouragement

Since disabling the legacy vector option in my e.wp preferences, I've very much enjoyed watching the changes slowly implemented. Updating the UI is a tough problem, so well done so far. I like that we're getting closer to the main useful interface features of web readers like wikiwand.com. T.Shafee(Evo﹠Evo)^talk 01:36, 14 October 2020 (UTC)

@Evolution and evolvability, thank you! If you're interested, you can check our new search prototype. This change is coming soon! SGrabarczuk (WMF) (talk) 11:15, 14 October 2020 (UTC)

Cannot open alert notification

When using Desktop Improvements , I no longer can open the alert. Clicking this bell icon and the right side of my user name will open the notice instead. But sometimes it works by making my browser window smaller. William Surya Permana (talk) 07:26, 14 October 2020 (UTC)

Hello! This bug has been fixed and next week, everything will work properly. SGrabarczuk (WMF) (talk) 11:35, 14 October 2020 (UTC)

Table of contents, Images, Fonts

Hi, I like new redesign features. However, overall a page still looks kind of old-style. I think we can learn a lot from Wikiwand project. Compare https://di-search-3.web.app/Greenland and http://www.wikiwand.com/en/Greenland . Wikiwand feels much better from a user perspective:

• table of contents is always available on the right side (no need to click at the top button to show a dropdown)
• images have no stupid borders and frames!!! - slightly another color, font size and margin is enough
• fonts, infoboxes, info messages just look better. --176.36.227.144 23:46, 19 October 2020 (UTC)

Thank you. We will redesign the table of contents - this is a part of our plan. Regarding the bullet points #2 and #3, it's currently out of scope of our improvements, and we would be delighted to work on that in future. SGrabarczuk (WMF) (talk) 15:54, 21 October 2020 (UTC)

Article beginning and "Go to content" link with lynx

Hi,

I'm blind and using lynx.
So, first of all, I would like to thank mediawiki developers for the great level of accessibility of wikimedia.
Then you may place yourself in the context of non-visual rendering and no fast track to browse the screen with the eyes but search line by line for the relevant content.

With the old skin, in this context, the content used to start on the first screen, not right at the beginning nor at the end of it, so it required some research to find the exact place, but it was always on the first screen.

With the new skin, it starts further, often on the fifth screen, which means I have to pres 4 times on PageDown to go on the screen where the article begins and then browse line by line with my braille device to find the exact place.
Pressing 4 times PageDown isn't a problem in itself, although it's less friendly than before, but the article doesn't always begin in the 5th screen. For example, on the French Wikipedia, if I open the page "Jimi Hendrix", it starts on the 12th screen, so it starts to make it painful to find the beginning of the article, because we never exactly know.

I probably could change this behaviour in my preferences, but, will it work if I'm not logged in? and I think it could be solved another way.

Indeed, I wanted to use the "Aller au contenu" ("Go to content") link, which points to
https://fr.wikipedia.org/wiki/Jimi_Hendrix#content
but it just brings me to the very beginning of the page.
If there is a way to make this link work, with lynx, it would be, for me at least, for others I hope, an even more convenient way than with the old skin.

Another note of encouragement

I hate change as much as anyone but I agree that the new Vector is better in some ways. It looks pretty good on my laptop. I'm still getting used to the fixed width but first impression is that the walls of text are easier to read. Flounder ceo (talk) 02:41, 22 October 2020 (UTC)

Thank you! SGrabarczuk (WMF) (talk) 13:45, 26 October 2020 (UTC)

Give users more preference settings to modify Vector 2020

If users enjoy the newer Vector skin, why not give them user preferences settings to adjust content width, display which logo they like, select whichever background they prefer, and other things? I read negative reactions about changes toward content width and background color. George Ho (talk) 07:48, 29 October 2020 (UTC)

Hello @George Ho! These are truly valid questions. We agree that MediaWiki could be more customizable, and that would definitely be an improvement from users' perspective. This issue has been, by the way, raised repeatedly in relation to a number of MediaWiki development projects.

Engineers agree that customization correlates with high costs. These costs seem to be too high at this moment. Among the arguments against a wide customization, there are:

1. every option adds new branches to the execution flow, and mental complexity increases,
2. it's more difficult to obtain a reliable test coverage (at the level of initial research, Quality Assurance, etc.),
3. both of the abovementioned result with even more requirements, limits and challenges for maintenance and future development, for WMF, WMDE, volunteer developers, and everyone else involved in our software development.

In short: it's too difficult. At least, for the current capacities. SGrabarczuk (WMF) (talk) 02:50, 5 November 2020 (UTC)

Hey, Mr. Grabarczuk. Why not request only various background colors and text colors instead? I see their plans to change the background color (phab:T259240). However, would such requests rehash the abandoned desktop Dark Mode project? George Ho (talk) 20:39, 13 November 2020 (UTC)

Remove the "the free encyclopedia"

It doesn't look modern. It looks heavy, polluted. By now everyone knows what Wikipedia is. Just leave the name in the logo and perhaps add the motto somewhere else, like in the main page.Bageense (talk) 22:23, 6 November 2020 (UTC)

@Bageense, I apologize for such a late reply. Yes, we're considering this step. The top of the articles (wiki pages in general) is in some cases cluttered and "the free encyclopedia" line does seem redundant. We aren't sure what we do with it eventually. Possibly, this line will be removed. SGrabarczuk (WMF) (talk) 06:21, 3 December 2020 (UTC)

It is already on the main page alongside links to portals in many versions of Wikipedia ("the free encyclopedia that anyone can edit"), so the motto could have always been dropped altogether. Same should go to all Wikimedia projects because Wikipedia isn’t the only one that explicitly displays their "slogan" all the time. AlejHerrBar2003 08:02, 12 November 2020 (C. America)

Feedback from 2020-02-07 (by Adûnâi)

The following is my feedback from 2020-02-07 (link).

1. Take a minute to look around. What are some of your initial impressions? Do you find anything confusing? Convenient? Particularly interesting?

   The first different thing I see is the ugly mobile logo - along with the abominable 3-bars sign. Please, do not implement any of those! Wikipedia was a shiny beacon amidst the abhorrent mobile Material design.

2. Imagine you wanted to switch the article to another language. Can you figure out how to do so? What do you think of this experience?

   Totally oppose the change! The small window, if implemented, will exemplify everything wrong with modern website UI! I already find it disgraceful that in the current client, a logged-out user has such trouble navigating that excuse for a language selection "menu". Please, do not spread it to logged-in users, too.

3. Imagine you wanted to collapse the main sidebar menu. Can you figure out how to do so? What do you think of this experience?

   I say NO to any collapsible windows. They come from mobile. They make it hard for me to click on things because everything is moving around!

4. The logged-out experience is slightly different. Please click the “Log out” link in the top corner. What do you notice that’s different from the logged-in experience? What do you think?

   The page moves awkwardly to the left of the screen. Now there is a huge white bar to the right! The whole text becomes unpleasant to read as there are now two white bars (in the original, there is only one to the left and thus the text has a "foundation" from the right, a neat basis).

5. Imagine your main objective is reading an article. What do you think of page layout and the reading experience? How does it compare with the current experience on Wikipedia?

   The page becomes annoying to read because a logged-out user sees two white bars to the sides of the text instead of one - it makes the text seem "hung" awkwardly in the middle, without a neat basis on the right as was the case with the original.

6. Please add any final thoughts, ideas, or questions.

   All these changes make Wikipedia ugly and hard to read. I am grateful that I have a place to voice my thoughts against this constantly-moving and objectively worse (in arbitrarily-chosen places, it seems) mobile abomination trying to get on my desktop/laptop. Collapsible menus? And an objectively cumbersome language selection menu? No, do not do any of these. And if I may add my subjective view now, I like the long list of languages not only because I find it easy to select them as they are neatly ordered alphabetically (instead of typing), and not just because I can easily remember the place of German or Russian in the list for all future cases (instead of scrolling in an ugly tiny window), but also because I can determine at a glance the relevance of the article internationally, and appreciate the diversity (I normally despise the word) of Wikipedia's contributors. There, I said it - the new ugly tiny language selection window hinders diversity! (Maybe this will work, considering the general political Weltanschauung of Wikimedia organizers...)--Adûnâi (talk) 00:45, 13 November 2020 (UTC)

"Citation bloc" beaucoup trop compacte avec la nouvelle interface

Je partage l'ensemble des critiques qui ont émises ici concernant la nouvelle interface sur écran PC, notamment le fait qu'elle est excessivement et inutilement compacte. Par ailleurs, cette nouvelle interface entraine de véritables dysfonctionnements. Le modèle Template:Citation bloc ne permet plus d'aligner ne serait-ce que deux mots et les place en colonne de façon ridicule et quasi illisible, ce qui casse complètement l'attractivité des citations. Par pitié, revenons à la version qui a fait ses preuves sur la durée. Celle-ci n'a aucun intérêt, bien au contraire, et elle relève d'un pur effet de mode. --Nadjiwill (discuter) 14 novembre 2020 à 19:47 (CET)

I translate into English for non-French speakers :

I share all the criticisms that have been voiced here regarding the new PC screen interface, especially the fact that it is excessively and unnecessarily compact. In addition, this new interface causes real dysfunctions. The Template:Citation bloc template no longer allows even two words to be aligned and places them in a column in a ridiculous and almost illegible way, which completely breaks the attractiveness of the quotes. Please let’s go back to the version that has proven itself over time. This has no interest, quite the contrary, and it is a pure fashion effect.

Best regards,

Florian COLLIN (talk) 11:16, 15 November 2020 (UTC)

No Horizontal scroll bar for wide table with new Vector skin

I hope this is the right place to write this report.

With the new vector skin there is no horizontal scroll bar for this page: https://en.wikipedia.org/wiki/Comparison_of_Google_Pixel_smartphones

That can make it less obvious of additional content, or maybe how to view it. Also depending on where cursor is (in textbox, or unfocused) may not be able to scroll with arrow keys.

In this application it might make sense to have a horizontally collapsible table to fit within the limited width.

Louipc (talk) 20:39, 15 November 2020 (UTC)

Bug: two scrollbars?

I just tested the new design in german wikibooks and found occasionally two vertical scrollbars. My best guess is, it happens, when the sidemenu is longer than the actual content? Example: de:b:Handbuch_Open_Science/_Open_Data (needed to be viewed with new design enabled in preferences of course). Regards --HirnSpuk (talk) 12:34, 17 November 2020 (UTC)

I came here to say the same thing. Consensus to apply this Vector skin for all users is being made on Kowiki but the same problem appeared as dominant. Please regard. Sincerely, 사도바울 (talk) 13:23, 28 November 2020 (UTC)

@HirnSpuk, @사도바울, this might be caused by the minimal width setting, which was introduced, but not for long. We've been working on this and we'll fix (remove) it. Thank you for your vigilance :) SGrabarczuk (WMF) (talk) 06:30, 3 December 2020 (UTC)

In kowiki, the code that might solve this problem was introduced. Please check this discussion and the code introduced by ted. I think the minimal width setting is really gorgeous idea. Please do not remove.사도바울 (talk) 11:28, 3 December 2020 (UTC)

@사도바울, to be exact, there's a difference between the minimum width and the fixed (limited) width. The latter means that on wide screens, only a part of the width is used, and is intended. The first, on the other hand, means that if you have a narrow window on your screen, a horizontal scroll bar may show up. Browsers themselves force a limited width (which is around 600px and is OK), but our limited width has been noticeably larger (around 1000px) and that may fairly be raised as a bug, and not a feature. SGrabarczuk (WMF) (talk) 13:37, 3 December 2020 (UTC)

Thank you for your kind reply! Have a good day :)사도바울 (talk) 13:40, 3 December 2020 (UTC)

Thanks @사도바울, and take care :) SGrabarczuk (WMF) (talk) 18:16, 3 December 2020 (UTC)

About fixed headers and widgets

I just read above a comment about making the headers fixed. I absolute hate this sort of thing (with no way to hide it when unwanted) as I find anything stuck there over the contents distracting and annoying as well as getting in the way and taking up room. For me I don't need it stuck all the time as I hardly every need it. When I do it is only for a couple of seconds and I hit the home button to get there.

I have to use an extension called "Sticky Header Hider aka Fixed Header Fixer" to hide these sort of persistent things but sometimes or on certain websites it doesn't always reshow the fixed elements/widgets when scrolling back up to the positions they appear when the page jumps, shrinks or increases in size.

I think it was mentioned about a sliding side menu so I suggest an option like that to toggle it on and off maybe by a fixed symbol lets say on the top right side.

Look at an older copy of a website of archive.org and there is a close button on their fixed nav/toolbar when I don't need it but then you can't get it back without refreshing the page.

A little pin at let say the right side, so when I scroll I can hide/show the search/navigation bar and get it back if I am down the page if I ever need it but the pin remains visible but small enough not to get in the way and be distracting. I can read articles in peace and for very long articles that is where getting it up will be of assistance.

That will be a lot better and a big improvement than sticking things in yer face constantly that maybe totally unwanted and and turns into a nuisance/distraction where it goes past helpful.

Also an option would be good that will be remembered by cookies or signin.

With the way it is looking at the moment I am perfectly happy and no complaints.

It is clear, lots of detail, I don't have scroll too much to read stuff or zoom out where the text becomes unreadable or anything in the way.

I have seen some other beta pages which also look different but okay, some seem a bit slow to scroll but haven't come across any fixed elements yet.

Edit: I have just seen it: Header 2: Sticky site and article headers

Reminds me a little but of Google Reader and I would definately want that thing out of the way when I am trying to concentrate and read an article.

In the ninth preview "Table of contents": the fixed element featuring the text "Toni Morrison" stuck over the contents. Reminding me in large letters what I am reading. Now I am bound to notice that all the time like anything stuck there where that becomes an annoyance. The only useful thing I find is the "table of contents", on it's own with some small white background, without the white fixed bar it is on displaying text like "Toni Morrison" spanning all the way across as that would free up reading space and "table of contents" is small enough to not be distracting. — Preceding unsigned comment added by MrMobodies (talk • contribs)

Hi MrMobodies! Thank you for this comment. We are considering various options. For instance, it's possible that the fixed header will disappear while scrolling up. Also, before the deployment of the fixed header, there will be a prototype published for volunteers to test and share their detailed feedback. This should happen in the next 1-2 months. Keep your eyes peeled for the banners! One of them will announce the prototype testing. SGrabarczuk (WMF) (talk) 22:59, 11 January 2021 (UTC)

Website UI preloaders/spinners/dimming overlay animation stuff

In your redesign please refrain from usng dimming overlays (that dim the rest of the page on dialogues and hurts my eyes), distracting loading spinners some which cover up contents with an overlay for quick loading things that take seconds (unless it a real loading spinner linked to the real loading progress of something very slow where it is spins once and doesn't cover up any content.)

I have noticed this practice increasing early this year during the Covid lockdown with these loading spinners (in the form of animated GIF images) repetitively for short loading stuff that takes seconds.

Example go on Ebay and do a search, overlay appears and a spinner. That can visually annoy me in two ways, one if it is slow, the animated GIF goes around and around and round, if quick it flashes after every page search which is the case.

For dimming overlays, when a white dialogue appears, the rest of the page dims and some sites do this repetitively like on typing in the search box and that hurts my eyes where most of the page flips from light to dark to light.

I try to hide the elements of these things but the problem is that some of them are the parent element so kill that and the dialogue or content under it disappears.

Most of the dialogues (like cookies) are good enough without the dimming overlays as many are in the middle, some animate if clicked past.

I noticed that some of this UI stuff can slow down the page load, like the skeleton placeholders on Youtube (the page where the video plays) and the new recent Paypal checkout but loads much quicker when they're hidden.

Edit: The blue animation in "Search: widget move and other improvements"

Firefox has one of those where and I find that pretty annoying where they also removed the option to stop it so had to edit the UserChrome.CSS file to rid off it.

The only thing i like the is that sliding side menu and I think it should also be applied to that sticky fixed header and the other fixed things that follow down the page so I am not forced to see it all the time where I have to rely on extensions to manage it.

Please have consideration, do one thing and provide a choice, not all users may want fixed things stuck over what they're trying to read and the animations where they can get in the way and interfere with the viewing of the page.

Some improvements

The concept looks good and well, still a beta, so it's kinda quirky to use the skin as the default. The sticky header and collapsible sidebar are true necessities to make Vector a modern skin because, well... the skin looks quite outdated now.

Anyway, as a webdesigner, my suggestion is:

• I know this is on "Desktop Improvements", but would be great if Vector was more mobile-friendly so we can ditch MinervaNeue. Minerva is such a horrible skin that breaks so many things on wikis... you have also to switch between versions, which is something so 10-year old now, most professional websites adapt their content based on the window size. So, the first thing, modify the <meta> already to match each device's width!
• Don't use fixed-width elements and make .mw-page-container have padding: 0 10px instead of 0 30px.
• While it's great to have the TOC fixed as a dropdown on a sub-navbar, I would prioritize having the "Page", "Discussion", "Edit", etc. buttons fixed on the sub-navbar instead.
• Remove these gradients on the top tabs, make it just solid and with at least .25rem border-radius or a blue border at the bottom of the selected tab.
• Avoid using background-image as icons, borders and gradients. Use the defined CSS tools instead + SVGs or unicode font.

For now, it's just this, but I want to see how far this can go. :) — Lakelimbo (talk) 18:24, 30 November 2020 (UTC)

Printed version

I really like this new style, thank you for all your work. There is an issue on Wikipedia Fr when the user want to print the page. In the lagacy theme, the navigation menu (Home, random page, etc.) wasnt printed. In the new style it's now included in the printed version. For me it is not the expected behavior.

Another idea would be to allow the user to hide the TOC from the printed version, I don't know if it's possible.

--MrEpicKiwi (talk) 10:45, 3 December 2020 (UTC)

Hi @MrEpicKiwi - thanks for reporting this! We are aware of this issue and are tracking in this task on phabricator. We hope to have this fixed in the next couple of weeks. OVasileva (WMF) (talk) 17:03, 3 December 2020 (UTC)

Bug? Annoying side-menu-flipping

I don't know how this happens exactly, but if I'm not working in fullscreen the Menu is overlaying the content. It happens when the browserwindow (Firefox 83) is around 1000 px (a guess, I didn't measure). It's fine, when it's wider, it's fine when the window get's "smaller" than the actual content (doesn't know how to describe this). This is pretty annoying, because, either I have to change my window, or I have to hide the menu. This is an unnecessary task while just using the website I would think. Regards --HirnSpuk (talk) 20:18, 4 December 2020 (UTC)

@HirnSpuk, hello! Yes, this may be a bug. I'll share this with the team. However, I also use Firefox 83, and I don't notice the problem when I set the window to be around 1000px wide. So in the meantime, would you be able to check if this isn't caused by a gadget you use? SGrabarczuk (WMF) (talk) 12:01, 10 December 2020 (UTC)

Hello SGrabarczuk (WMF), easy enough, I don't use any gadgets... At least, that's what I thougt :-). There where some markers in the gadget-section which I turned all off: Same behaviour. When making the window smaller, the content stays in fixed width (seem to be centered). When it touches the side-menu it slides "under" the sidemenu until the "content" reaches the other side of the browser-window (at least this is what I'm guessing) and suddenly flip to correct layout. This behaviour is the same, either resizing Firefox-window from the left or right. The problem arises when I'm doing other Internetstuff, resizing the Firefox-window to my liking, than go to wikibooks and need to resize the window to see all content (checked on de&en on wikibooks&pedia as well as here, right now). Hope this helps. Regards --HirnSpuk (talk) 20:00, 10 December 2020 (UTC)

@HirnSpuk - thanks for the report! I'm also having some trouble reproducing, but I opened this task in phabricator so we can track the bug and our QA engineer can take a look. If possible, could you post some screenshots on the task? Thanks! OVasileva (WMF) (talk) 13:52, 14 December 2020 (UTC)

Done. Regards --HirnSpuk (talk) 19:35, 14 December 2020 (UTC)

@HirnSpuk - sorry this took us a while, but I'm happy to say this is now fixed. Thanks again for raising the issue and helping us reproduce! OVasileva (WMF) (talk) 11:00, 19 February 2021 (UTC)

OVasileva (WMF), thanks. No problem. I didn't expect a fast solution, because I supposed, there would be more urgent needs. But a solved problem is a good problem ;-)... regards, --HirnSpuk (talk) 17:39, 19 February 2021 (UTC)

What about those who don't want to see sticky fixed headers and navbars?

What about those who don't want to see fixed headers and navbars?

Lakelimbo: " The sticky header and collapsible sidebar are true necessities to make Vector a modern skin because, well... the skin looks quite outdated now.

Anyway, as a webdesigner, my suggestion is:"

Necessities? Not all of us want fixed headers or things stuck there constantly all the time and some of us find that incredibly annoying (including me) as it gets in the way and can be distracting and denies us a choice we once had over our screen area in the absolute positioning.

Will there be a choice or a setting?

That's the best you can do. It will be very helpful and a neccessity for those who don't absolutely hate them stuck there constantly where the negatives outweight the advantages for them when they are trying to concentrate reading an article.

Normally I don't care how it looks but I do start caring when things are placed over the contents that I don't want there and can't be closed.

I see it as spam and have to put time into finding the elements to add to my blocklist, so therefore it is not always helpful to everybody.

I see many websites still out there that look modern and change over the years and and don't feel the need to spam their viewers with persistant things that maybe unwanted.

Look at an older copy of of a website on Archive.org, it has a fixed header that has a close button and that is really good. That is considerate in that I have a choice like before. Once I find what I am looking for and it has outlived it's purpose and I don't want it stuck there I have control over my viewing area of the article. They also remind me of about 20 years when some I noticed a few websites (not many) using Iframes in a similar way with the headers and I found them just as distracting and in the way. So in that similar form where it can't be closed I see that as not an improvement.

Ebay did this some months ago to their main home page and made it sticky so it follows you down the page. I complained and eventually it seems they reverted but changed the design a little, so there must have been others complaining for them to do that. — Preceding unsigned comment added by MrMobodies (talk • contribs) 05:40, 7 Dec 2020‎ (UTC)

Hello MrMobodies! Thank you for your opinion. We don't believe a constantly sticky header is an absolute must. We are still working on the details. For example, the header could only be sticky when scrolling up (and not down). How does that sound to you? SGrabarczuk (WMF) (talk) 11:41, 10 December 2020 (UTC)

Special pages tab

Since the "Special" tab in the toolbar of special pages floats and is not directly at the left edge, would it be possible to add the blue edge lines to the left side of the button. Similar to the "right-navigation" side. So that the tab is better defined instead of having an open side. Terasail (talk) 14:51, 10 December 2020 (UTC)

Terrible changes

Now it's like all websites are trying to became uglier and worse, only because it's more "modern". Vector looks great right now, you are only tryng to destroy it and make Wikipédia looking like a blog. 131.255.74.175 22:21, 11 December 2020 (UTC)

The funny part is last year Wikia/Fandom removed Monobook, and it caused a lot of rage. But now is Wikipedia that's trying to became like Wikia/Fandom. 131.255.74.175 00:19, 12 December 2020 (UTC)

Bug? Transclusion of Special:PrefixIndex falls back to legacy vector

When transcluding Special:PrefixIndex as described here: Help:Subpages#Displaying_subpages the layout changes back to legacy-vector. It could be observed even in preview. Regards --HirnSpuk (talk) 19:54, 14 December 2020 (UTC)

@HirnSpuk, thank you! I've submitted a task on Phabricator. SGrabarczuk (WMF) (talk) 00:58, 24 December 2020 (UTC)

Bug? Menu and Contentoverlays in Printing

Firefox 84 in Linux: When trying to print, the menu is printed. And there are some weird overlay thingis happening, reason unknown (I tried to find another example than given below, but I couldn't manage; maybe I'll try to investigate further in a few days). Example: https://de.wikibooks.org/w/index.php?oldid=940581 (remember to use new vector skin) → browser's print preview →

• first page(s) have the menu
• last page: the last comment is "overlayed" by other information

Regards --HirnSpuk (talk) 23:00, 17 December 2020 (UTC)

Confirmed with Firefox 78.6 ESR on Linux; the menu is there but no overlapping occurs in Chromium 73 on Linux. Direct link for all those who don’t want to play with their preferences: https://de.wikibooks.org/w/index.php?oldid=940581&useskin=vector&useskinversion=2. —Tacsipacsi (talk) 06:50, 18 December 2020 (UTC)

Logo?

I have a logo in my site using Vector theme. But there's no logo on new one. Only wordmark — Preceding unsigned comment added by Achia70 (talk • contribs) 12:45, 22 Dec, 2020 (UTC)

Hello Achia70. I believe we have published an advice on how to proceed. Please check how it's working on your site and write back if our documentation was helpful :) SGrabarczuk (WMF) (talk) 00:12, 24 December 2020 (UTC)

Dropdown Widget overflow

When there is a OO.ui.DropdownWidget with a lot of items, on the legacy vector it would create a scrollable box if they could not all fit on the screen. However it will now just extend past what you can see on screen. Making it slightly annoying if the option is not visible and meaning a user has scroll the page to find the item to select. Terasail^[✉] 23:56, 25 December 2020 (UTC)

Improvements?

The new desktop is hard to navigate. I don't understand why a fixed width. Also the scrollable boxes for references it's very annoying. --Scann (talk) 22:20, 26 December 2020 (UTC)

@Scann, first of all, thank you for using "I don't understand" instead of "I dislike that, please remove that". Have you read a page dedicated for the limited width? Secondly, what do you mean by "the scrollable boxes for references"? SGrabarczuk (WMF) (talk) 13:52, 11 January 2021 (UTC)

SGrabarczuk (WMF) I'd assume they're referring to this, which I'm inclined to agree isn't a perfect solution. AngryHarpy (talk) 13:25, 14 January 2021 (UTC)

@AngryHarpy, thanks for clarification! So, @Scann, using parameters such as useskinversion=1 or useskin=monobook, we can check that there are scrollable boxes for references in the Legacy Vector and even in Monobook. Therefore this change was not made by us. In fact, it was in the Common.css before we released anything on French Wikipedia. :) SGrabarczuk (WMF) (talk) 16:15, 14 January 2021 (UTC)

Bouton pour déplier le menu de gauche

Bonjour à toute l'équipe des développeurs,

J’apprécie ces débuts de nouvelle interface, en particulier le bouton de recherche en haut qui est bien plus visible. Je constate que lorsqu'on veut replier le menu de gauche, le bouton reste entouré de bleu. Ça n'est pas très esthétique et ça reste tout le long de la lecture de notre article tant qu'on clique sur rien d'autre. Ce rectangle bleu pourrait t-il être supprimé ou disparaître de lui même ? Par ailleurs, je pense qu'on peux maintenant retirer du menu le lien en gras « Basculer vers l’ancien habillage » du menu. Je le trouve assez dérangeant.

Cordialement, -- Nemo ^Discuter 18:13, 2 January 2021 (UTC)

@Nemo Le Poisson, I'd like to ensure you (and everyone else reading this) we've noticed your suggestions and have already started discussing the next steps. Regarding the blue frame, it's going to be more difficult than one may think (because of all standard buttons' imperfections and limitations). SGrabarczuk (WMF) (talk) 16:09, 9 February 2021 (UTC)

Displaying of some Wikidata qualifiers and of references

Hi, I noticed a thing since a few months in Wikidata specially in taxa items, I guess this has maybe something to do with "Limiting content width", but I'm not a specialist.
I have a screen with 1920*1200 resolution, and I often work with two windows open at the same time and each taking half of the screen. The screenshot below (of Sternaspis sendalli (Q40696606)) show my issue, when i am in Wikidata with a window half the size of my screen and that the sidebar is open then some qualifiers en some references are displayed in one vertical line which is the width of a letter while it seems there is still some room. It's particularly annoying when the reference is a scholarly article with a long title. If I collapse sidebar then the reference resumes a normal aspect, as well as if I re-enlarge the window to the full size of the screen.

• 

Christian Ferrer (talk) 12:49, 12 January 2021 (UTC)

Wikisource

Bonjour à tous. Je ne sais pas si quelque chose est prévu pour Wikisource, mais avec la nouvelle version de Vector le formulaire d'édition devient peu commode, à cause de sa largeur trop étroite. N'oublions pas que sur Wikisource ledit formulaire est divisé en deux sur sa largeur par l'extension ProofreadPage. Une idée simple pour remédier à ce problème serait de proposer un agrandissement plein écran (fullscreen) du formulaire à partir d'un bouton situé dans la barre d'outils. Ça me semble facilement réalisable, non ? Reptilien.19831209BE1 (talk) 08:09, 21 January 2021 (UTC)

@Reptilien.19831209BE1, merci pour cette question. C'est vrai! Quand nous déployerons la nouvelle version de Vector à Wikisource, nous (je pense!) créerons une exception pour des espaces de noms choisis. Espaces choisis, parce que la limitation de la largeur du contenu peut paraître bien dans (par exemple) l'espace de noms principal. SGrabarczuk (WMF) (talk) 13:06, 21 January 2021 (UTC)

55% of my screen is empty space

I think the design should use the full width of the viewport. At my zoom level Chrome says my monitor is 1700 px wide and articles use 944 pixels of the width, and the rest is just empty space. I don't get the crusade against using the user's entire screen. I paid for my full monitor, I want to use all of it. I like seeing more of the page so that I can estimate how much more I have to read, so that I can skim to other sections and because I don't need to fiddle with the scroll wheel as much, which can be distracting or at least it's not reading, which is what I want to be doing. I don't mind having to move my eyes left and right, the less lines I have to read, the less often I'll start reading the wrong line.

For this reason I am re-enabling "legacy" Vector. Akeosnhaoe (talk) 09:59, 24 January 2021 (UTC)

@Akeosnhaoe, would you consider using the max-width gadget allowing you to keep the rest of improvements? SGrabarczuk (WMF) (talk) 15:48, 9 February 2021 (UTC)

@SGrabarczuk (WMF): I’d give it a try. But the user script stopped working more than three months ago. —Tacsipacsi (talk) 21:27, 9 February 2021 (UTC)

It's because of collapsible sidebar it doesn't help anything.Baratiiman (talk) 18:08, 25 January 2021 (UTC)

„Language switcher“

Hi, the upcoming change of the interwiki link position raise some concerns of mine. You call the interwiki link area „language switcher“ and justify the position change to the upper right corner with the common behaviour of other multilingual sites. The latter might be true, but is Wikipedia really a multilingual site in the understanding of most of the other sites as the same content is simply translated into other languages?

I see big differences in many articles with the same topic regarding structure, style, content emphasis and text volume between the single Wikipedia language projects. It's not a simple switching of language, you switch to a completely different article in a different project with it's own community and regulations. It's more of a project switcher. I think the new position known as the 'switch to translated version' position could be confusing to readers that expect a translated page and don't get it.

Many of the recent documentaries about Wikipedia's 20th birthday spoke of 'the Wikipedia' missing the fact that there is not one Wikipedia but standalone Wikipedias in many languages. I think the new position could increase this misunderstanding because of the reasons mentioned above. Maybe this is worth a reflection. Regards, -- hgzh 15:40, 24 January 2021 (UTC)

@Hgzh: Could you link to some examples of the new interwiki link position? --Iketsi (talk) 07:40, 25 January 2021 (UTC)

Hi @Iketsi: , i refer to the changes proposed in Reading/Web/Desktop Improvements/Features/Language switching. -- hgzh 11:00, 25 January 2021 (UTC)

@Hgzh: I also very much prefer keeping the interwiki links in the sidebar, mainly because it allows me to see the whole list of available languages at a glance, without having to click or scroll. Obviously, the average user will have different priorities, so it may make sense for most people, but I hope to be able to opt out of this improvement to stick with the legacy layout. –Iketsi (talk) 17:19, 27 January 2021 (UTC)

@Hgzh, when it comes to "there's no 'one Wikipedia' ", you are right. However, the main issue the team intends to resolve is that there's an unfair "traffic dissemination" - the largest projects are much more likely to be read. The issue of translations vs. independent projects is also important. It seems it'd require solutions of a different kind (how the switcher should look like instead of where it should be). @Iketsi, thank you for your opinion. I'll share your point of view with the team. SGrabarczuk (WMF) (talk) 15:46, 9 February 2021 (UTC)

Articles now fill the entire width of the page

What happened? I really, really, hope this won't stay in the final version of the new Vector skin. The narrower articles were way more comfortable to read. They were the big advantage of the new skin. Please, don't even think about making them even wider than before!

You have 24 hours to undo that change.

I use the beta version of the skin in the Portuguese Wikipedia, btw. Bageense (talk) 18:54, 29 January 2021 (UTC)

Oh, only the diffs are shown in full width. I don't remember now whether for a few hours the articles were also in full width. Sorry. In any case, I also don't like the diffs in full width. Bageense (talk) 19:09, 29 January 2021 (UTC)

Wikimedia Foundation's Website

WMF's Website is pretty fancy, couldn't you use it as model in order to create a new design? --ValeJappo (talk) 11:50, 5 February 2021 (UTC)

@ValeJappo, interesting thought :) Overall, that page is based on Wordpress and it's read-only, which makes its design much different from MediaWiki. What functionalities would you like to see? SGrabarczuk (WMF) (talk) 15:35, 9 February 2021 (UTC)

@SGrabarczuk (WMF): Hi, tank you for getting interested. I created a visual example that you can find in phab:F34098637.

• I belive "Donate" button would be very useful.
• In that same style of that button, you could create a language switch and an edit button. An edit button could also be added next to "more"
• The search function on the wmf's website is very well done
• Related articles, as happens on the mobile version
• The wikidata's item description next to the title, as happen on mobile
• An easy way to access other projects (from wikidata)
• Images on the right blank space
• Table of content on the left blank space; also images could be added there, if the're is enough space
• This footer could be better than the current one ValeJappo (talk) 16:51, 9 February 2021 (UTC)

@ValeJappo, thanks! We will definitely take your suggestions into consideration. It's possible for us to make some improvements you've mentioned. SGrabarczuk (WMF) (talk) 12:50, 2 March 2021 (UTC)

Merci pour ce formidable nouveau design !

My dream for Wikipédia !

Bonjour,

Je tiens vous écrire ce message pour vous dire que j'aime votre projet de nouveau design pour Wikipédia. L'encyclopédie en a vraiment besoin et je pense qu'on est même en retard sur le sujet. J'espère que vous pourrez accélérer la mise à jour de l'interface pour l'avoir plus rapidement.

Je tenais juste à vous adresser une petite recommandation :

• Pouvez vous mettre quelques couleurs dans la nouvelle interface, un peu comme Timeless ? Cela permettrait de rendre l'interface plus agréable et moins grise et triste.

J'ai aussi deux questions pour vous :

• Est-ce que le nouveau skin Vector remplacera le skin Minerva par défaut sur mobile ? Ce serait bien s'il remplaçait Minerva car ce skin n'est pas pratique sur mobile
• Est-ce que vous changerez le design des infobox, des tableaux, des cadres images ? Il commence à vieillir il faut les changer.

Merci encore. Bonne chance et bon courage ! Je vous soutiens ! Menthe 555 (talk) 12:52, 5 February 2021 (UTC)

Translate :

Hello,

I want to write you this message to tell you that I love your new design project for Wikipedia. The encyclopedia really needs it, and I think we’re even behind on the subject. I hope you can speed up the update of the interface to get it faster.

I just wanted to make one small recommendation:

• Can you put some colors in the new interface, a bit like Timeless? This would make the interface more pleasant and less gray and sad.

I also have two questions for you:

• Will the new Vector skin replace the default Minerva skin on mobile? It would be nice if it replaced Minerva because this skin is not practical on mobile
• Will you change the design of infoboxes, tables, picture frames? It starts to age you have to change them.

Thank you again. Good luck and good luck! I support you! Menthe 555 (talk) 12:52, 5 February 2021 (UTC)

Hello @Menthe 555! Thank you! It's important for us and we are really glad to see that there are volunteers who support us.

Regarding your small recommendation/questions:

1. Colors are troublesome, unfortunately. There are various groups of people with different abilities to recognize colors (in other words, there are differences in the interaction with... light). According to best Web accessibility practices, we shouldn't add colors because these seem pleasant to some of us. That said, I believe it would be possible for volunteer designers to build themes based on the new Vector.
2. We don't have plans to use the desktop interface on mobile. Some features could potentially be re-used, but a simple replacement would not be possible.
3. Actually, it's the volunteers who add and edit most of these elements (templates in general, table formatting, as well as some icons). This is why we will not change these elements. On the other hand, things like "wikitable" (the standard look for tables) or picture frames could be changed by WMF, but it's not certain if we could do this as part of this very project.

SGrabarczuk (WMF) (talk) 12:46, 2 March 2021 (UTC)

Why mess with the ancient early-2010s skin.....

....when Skin:Timeless was created years ago as a modern replacement for Vector? Why can’t we just use that as the new default skin for MediaWiki? 2001:569:BD7D:6E00:D173:89E6:1427:48DB 17:44, 7 February 2021 (UTC)

Looking good

Love the new look..Full page view is really helping with all the sandwiched text..that said we have a few people that say the sidebar is by default collapsed. If only our tutorial at English Wikipedia had a simple design like this...new generation like compilated coding.--Moxy (talk) 03:58, 17 February 2021 (UTC)

Narrow reading/black space

If this gets implemented by default I'm going to stop editing. Nobody will probably care because I'm not that active but for me with a 4K resolution screen the narrow reading is as bad as it can be. UNCOMFORTABLE. Many people are against this and this is gonna get so much hate in the media once this gets implemented. Because we are living in 2021 with lots of widescreen monitors and such. Websites should be responsive in all ways possible. Coldbolt (talk) 10:48, 18 February 2021 (UTC)

Hello @Coldbolt, thank you for your comment. We agree that we could add some improvements for high resolutions and widescreens. No decisions have been made, though. If you are interested in details on why we have built this feature, I encourage you to read a related section in our FAQ and the dedicated sub-page. Also, I'd like to highlight that it is (and will be) possible to opt-out (and use the Legacy Vector) or use a max-width gadget. SGrabarczuk (WMF) (talk) 12:00, 2 March 2021 (UTC)