Talk:Reading/Web/Desktop Improvements

You can comment in any language. When giving feedback, please consider the Goals and Constraints of the project.

We are especially interested in feedback on:


 * Feedback on the ideas and mockups we have collected so far - How could they be further improved? What important considerations are not currently documented?
 * Identifying other focus areas for the project we have not yet discovered
 * Expanding the list of existing gadgets and user scripts that are related to providing a better desktop experience. If you can think of some of these from your wiki, please let us know

Typo?
At Reading/Web/Desktop Improvements 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.


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


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


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


 * 1) 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)
 * 2) tabs look weird/old – this will be addressed later on in the project with the visual design portion
 * 3) 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!


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


 * 1) 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 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: T258493. Stryn (talk) 07:39, 25 July 2020 (UTC)

Painful interwikis (dis)order
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)
 * This is a known bug, and is not related to Desktop Improvements (it’s broken in old Vector as well). It’s tracked in 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. 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)

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

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 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: 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)
 * 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 does not make the content wider; it just shifts it to the left. Why would I hide it?

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 adopte r 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: Fin de la página/End of the page.
 * 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:

This page was last edited on 27 August 2024, at :.

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 27 August 2024, at :.

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: «» 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í: 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 |the 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)