Talk:Reading/Web/Desktop Improvements

Discussions: Desktop Improvements • Accessibility for reading.

---

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

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

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

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

Thank you!

(Translate this page)

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.

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

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 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 8 November 2024, at 17:41.

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 8 November 2024, at 17:41.

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)

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)

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)

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

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)

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)

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.

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

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)

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)

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)

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 utilisateur 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)

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)

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)

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

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)