cc @alexhollender - not sure I understand this bug as written but maybe you do?

In T258277#6324691, @Jdlrobson wrote:

cc @alexhollender - not sure I understand this bug as written but maybe you do?

Look at the screenshots? :P

Why is there a much much big border on the new one? Why is there no left hand line on the special tab?

New:

Old:

This is a screenshot from the bottom section of a basque Wikipedia article with the new skin.
Is the fact that it’s 1/4 empty intentional?

In T258277#6324709, @Reedy wrote:

In T258277#6324691, @Jdlrobson wrote:

cc @alexhollender - not sure I understand this bug as written but maybe you do?

Look at the screenshots? :P

Why is there a much much big border on the new one? Why is there no left hand line on the special tab?

@Reedy thanks for your attention to detail and feedback here. I would like to make sure I understand what you mean by the border being bigger. I've attached a side-by-side comparison of the tabs on legacy vector vs. latest vector. Are you referring to the height of the blue gradient borders? Or perhaps the width? I can't seem to find much of a difference between the two (maybe the gradient fades slightly earlier in legacy?).

Regarding your other point about the border to the left of the Special pages tab — this is something we're looking into. The reason, so to speak, why that happened is because we removed the blue gradient border from the sidebar, which is what used to provide the lefthand border on the first tab. At some point during this project we will restyle the tabs. Until then we want to make sure we're not over investing in small fixes.

Not sure if this helps illustrate it a bit more. The sidebar on the new one is slightly narrower it seems. The text then starts further to the right.

It's probably not a huge amount of difference in this example, and it's probably at least the lack (or the removal) of the blue line (ie a physical "border")... but it looks like a lot of space as a user. Even more so as there is a grey-er bit (it's not much, but it's noticeable) and a white bit.

If we look at the content alone, you can see it's wrapping earlier because everything is seemingly being shifted to the right. And there's less shown vertically too because things start further down the page. So as a user, suddenly the content is narrower, and everything is apparently moved down and to the right

Ah apologies for the misunderstanding @Reedy — I now understand what you're talking about. I hope my response will also address the question @Wittylama raised as well (T258277#6327805).

First some context to consider: once we've moved the language switcher to the article header the sidebar will be collapsed by default for logged-out users. This means we have to consider the following default experiences: sidebar open/small screen, sidebar open/large screen, sidebar closed/small screen, sidebar open/large screen. Speaking in general terms there will be some awkwardness in some of these cases which is a tradeoff for things being better in other cases.

Regarding the gap between the sidebar and the article text: this is intentional, however it is currently a little large so we will be reducing it. The reason why the gap is there is to allow your eye a moment of rest as it finishes one line and returns to the next (known as a "return sweep" in reading research jargon). This is the same reason why books and newspapers have margins around the text. If there was no margin, or other text, it would cause greater fatigue to your eyes over time. We wrote about this however your question makes me realize that I should address the gap specifically (link) — I will make sure to go back and do that.

Regarding the content being offset to the right, this has always been the case. It is just more noticeable now since we're not filling that space in with gray. We did consider making the sidebar sticky (see this 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.

I hope the two following images provide satisfactory visual examples of how the new layout differs from the old one:

I don't know if this is the best place for this (feel free to move this comment to another ticket) or not but the vertical space at bottom of pages seems weird too. Let me give an example:

(A small page in Basque Wikipedia in a wide screen):

As comparison, this is the new mailman in a large screen:

1- The footer is at the bottom of the page
2- The large blank area is just one color, not a combination of white and gray:

@Ladsgroup I went and made this a generic task so feel free to drop any feedback in here. We'll make new tasks and tweaking existing ones as a result of the input.

To build on my other task that was merged in: the space to the left of the vector tabs is not browser-specific and not because of gadgets.

Here is the login page for fawiki with uselang=en (I have highlighted the newly added space in yellow for you)

In comparison, enwiki which doesn't have Desktop Improvements (Vector 2022) enabled shows like this, with no space before the tabs:

Obviously, fawiki is in Persian (which is a right-to-left language) so the login page current looks like this (i.e. without uselang=en). and I've highlighted the extra space in yellow again:

Another separate issue: I have modified my Vector.css to hide some of the links at the top of the page (like the sandbox link, etc.) and it used to work just fine. But now it results in those links having unequal spacing. Here is how it looks like in English:

And in Persian:

Pertinent piece of CSS code that I use which doesn't seem to work anymore:

#pt-sandbox, #pt-betafeatures, #pt-mycourses {
	visibility: hidden;
	display: none;
}

The CSS rule that makes them reappear is this (not sure which file it resides in):

#p-personal li {
	display: inline-block;
}

Why is this a bug? Because wherever the latter CSS rule lives is being executed after my own Vector.css which is wrong. My personal CSS should be the last one rendered. Somewhere, we are getting the order of things wrong.

Another unrelated issue: the search box should be aligned to the left (in RTL), but now it has a big margin to its left. Screenshot:

And in English (notice the huge margin to the right of the search box:

Is there a querystring parameter one could use to temporarily turn off Desktop Improvements (Vector 2022) ? We have useskin= but when I tried useskin=oldvector it didn't work. Can we make it possible, at least for this beta-testing period?

UPDATE

I figured it out. useskinversion=1 will take you back to the legacy vector.

TODO: I think we should document it at mw:Reading/Web/Desktop Improvements

Why is this a bug? Because wherever the latter CSS rule lives is being executed after my own Vector.css which is wrong. My personal CSS should be the last one rendered. Somewhere, we are getting the order of things wrong.

The loading order of Vector.less has not changed, what has changed is the layout - so the scripts/styles you have built on top of have changed, so as a result the gadgets will need to change. There are likely to be further changes to this widget, so I'd suggest updating such scripts to be scoped to .skin-vector-legacy in the mean time.

Longer term it will look like this: https://www.mediawiki.org/wiki/File:Consolidated_user_tools_prototype_for_Desktop_improvements_project.gif

And in English (notice the huge margin to the right of the search box:

Will be fixed in the next feature in the sequence T249363 which is currently in flight.

Another unrelated issue: if you have enough tabs (using gadgets), your page will be rendered in an awkward way. I have both Twinkle and MoreMenu enabled and here is how the tabs look like for me:

Why is this a bug? Because Vector should realize there are too many tabs and should push more items into the "More" menu (which in Persian is called "بیشتر") but it fails to do so.

Search looks misaligned:

An idea from the discussion in fawiki: Use the free space on the left (in fawiki, right in LTR wikis) for TOC. Similar to Britannica. The app also something similar as well.

I knew that white space generated by narrowing the reading pane would be claimed for a new use very soon, but I was thinking it would be for gadgets and similar tools. The TOC idea is also great. But a higher level discussion is: do we want to promote reuse of that freed-up space on the side of the page, or do we want to promote keeping it empty?

Happy to see all the feedback here. @Jdlrobson We should transform that into a parent-child task. This could lead to a lot of confusion what has been addressed/decided/marked as invalid. Not convinced about a drop-in task for collecting all feedback here.

@Ladsgroup has been making some changes to fawiki gadgets to address some of the above. Vector tabs look much better to me now.

Why is this a bug? Because what he is doing for fawiki may need to be done for other wikis too but I don't think he has started documenting his actions yet.

PS: I hope you found the second line's opening humorous :)

In T258277#6335584, @Ladsgroup wrote:

I don't know if this is the best place for this (feel free to move this comment to another ticket) or not but the vertical space at bottom of pages seems weird too. Let me give an example:

(A small page in Basque Wikipedia in a wide screen):

To illustrate my point, I mark all of the gray area as red:

As comparison, this is the new mailman in a large screen:

1- The footer is at the bottom of the page
2- The large blank area is just one color, not a combination of white and gray:

The additional white space is caused by this line: https://gerrit.wikimedia.org/g/mediawiki/skins/Vector/+/eeb6182a9112026e3cb9ad270f0548d16bf74981/resources/skins.vector.styles/layout-max-width.less#150

Fifty pixels is a lot of padding!

Currently, the new Vector skin uses max-width 960px for mw-content-container based on the decision in T246420. However, this brings some issues.

1. This is sometimes too small for a widescreen display.
2. When a user changes the Thumbnail size in Setting-Appearance bigger than 220px, 960px max-width is sometimes fell too small, as bigger the infobox with image, the less space for words.
3. Setting different background color for .skin-vector-max-width gives users the impression that something is wrong (It is hard to say, but for me, I feel that the website is intentionally cropped and shift my focus to the different background color rather than the content itself)

In Old Vector Skin

In Current Vector Skin

Removing background color of .skin-vector-max-width

In short

It may be best if the background color of .skin-vector-max-width is removed. Also, the max-width of mw-content-container should be dynamically increased based on the thumbnail size user chosen in the setting.

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.

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.

I think I found another case where the order in which CSS files are loaded is wrong. The order in which CSS is loaded must be as follows: MW Core > Skins (e.g. Vector, including Desktop Improvements) > Extensions > Gadgets > User CSS (global CSS first, local CSS last)

How do I know this bug exists? We have some gadgets on fawiki (example) that define an embded font and assign it to certain elements, including the #firstHeading element (i.e. page title). Ever since Desktop Improvements (Vector 2022) was enabled on fawiki, this does not work any more, that is, the first heading is now shown using .Arabic UI Display which is the wiki's default.

@Huji I tried out that gadget and it applies the new font to the body element no problem however the selector div#content h1, div#content h2, div#content #firstHeading, div#content .mw-editsection, .mw-body .mw-editsection-like, div#content #toc h2, div#content .toc h2 doesn't match anything because of the use of the div#content This was reported in the April tech news https://meta.wikimedia.org/wiki/Tech/News/2020/17 - those need to be updated to not use div#content (T248137). Without change this will also break in the old Vector in the distant future.

@Jdlrobson nice catch! I will update all said gadgets. My last comment is not entirely valid anymore.

Do see, however, my previous comment that also was about the order in which CSS is loaded (specifically, user CSS seems not to be the last thing loaded anymore): T258277#6341331

@Huji I believe that one is tracked in T259190

Hi,

i wanted to share a screenshot how an office wiki page looks for me:

It seems like ~50% of screen estate is just white space. There are really large empty areas on the right and left. When i hide the menu that also just stays white and is not being used for content.

Could we use more of that area for the content?

This sounds like a good idea:

A few more "this doesn't look quite right"...

The Wikisource proofreading view is very narrow, with its two side-by-side panels for editing:

In T258277#6371809, @Samwilson wrote:

The Wikisource proofreading view is very narrow, with its two side-by-side panels for editing:

Thanks Sam! Knowing particular pages where this design breaks down (aside from the general case where people don't like it which is to be expected) is really useful. I've created T260091 to start to collate these.

All: some folks on fawiki have shown interest in reading more about the research that is the basis of "narrower reading pane" change. Which paper/book/website would you suggest?

In T258277#6413490, @Huji wrote:

All: some folks on fawiki have shown interest in reading more about the research that is the basis of "narrower reading pane" change. Which paper/book/website would you suggest?

I find this study to be the most straightforward to begin with: https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf
There is a longer version of it as well: https://link.springer.com/content/pdf/10.1007/11555261_59.pdf
Another study here: http://www.makinggood.ac.nz/media/1266/ling_2006_fonts.pdf
This is a literature review of existing research: https://s3-us-west-2.amazonaws.com/visiblelanguage/pdf/V39N2_2005_E.pdf
The Wikipedia page on line-length: https://en.wikipedia.org/wiki/Line_length

One important note: we have not yet found research that studies line lengths beyond 125 characters per line. With the current layout on Wikipedia someone on a wide screen could easily get 200, 300, or 400 characters per line. Unfortunately that length doesn't seem to have been studied much, so part of our thinking is based on a) inferences we can draw from the range that has been studied, b) looking at other websites. We've written up some thinking here and here.

This is great, thanks!

I see that some of the screenshots above may be the result of the issue raised in T263950

[For future reference, please directly link folks to a central on-wiki feedback talk page and don't create one Phab task as a non-actionable catch-all - thanks a lot :) ]