important to consider the length of the text labels in various languages:

In T328069#8631022, @Nux wrote:

Also not sure why are going with overlines. I think you will be opening another front of controversial changes. Headers are prominently underlined on Wikipedia from like... always. I think changing that is a mistake. Also note that the page is now very inconsistent.

• page title - underlined
• left actions - underlined
• right actions - underlined
• left sidebar title - underlined
• left sidebar header items - overlined
• right sidebar title - underlined?
• right sidebar header items - overlined

You have over and underlined headers right next to each other. For me it looks bad (and not only because I'm editing Wikipedia for 17 years).

But if you are going to force overlined headers please at least make those headers in the menu more distinct and make the font for items smaller. Which will also be beneficial because the page tools will have a smaller height.

Two thoughts:

In T314419#8669142, @Jdrewniak wrote:

@alexhollender_WMF I think 60px should be sufficient here, I don't think we should make this spacing too big.

right, sounds good. as a reminder: one thing we discussed last week was that we might need to make the spacing here match the spacing in T317661: [Table of contents] Increase threshold for when a section is active, so maybe they could both be 75px or something

In T330665#8650277, @AnneT wrote:

@alexhollender_WMF @Sarai-WMDE we could use your feedback on this change, if you have a moment!
...
Please let me know if you approve of this new behavior, disagree with it, or have any other comments about highlighting behavior! cc @bmartinezcalvo @Volker_E

In T314419#8658154, @Jdlrobson wrote:

When resizing the window our icon touch area adapts to 44x44 (it's 43.333 for some reason but ignoring that for now). I think the scrolling-padding-top should be slightly bigger to compensate for that. Ideally the margin between the top of the screen and the icon should match the margin between bottom of icon and heading. What do you think?

research summary is here: https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Limiting_content_width#Research

On larger screens this doesn't present an issue, however on smaller screens it means that the content gets squished more than it needs to, for example:

tools menu hidden (smaller screen)

In T259240#8625710, @Ckoerner wrote:

I'm curious if there is a way to make a gadget or userscript so folks (ok, really I just want this) could test the change to Vector 2022 before making any broad changes to the skin? While I think the demo pages are great, one would be able to use this while editing to see how it shakes out.

@Novem_Linguae thanks for raising this issue. We've been discussing this topic over at T259240: [Design] Discussion: differentiation/separation of interface elements/regions in Vector 2022. Could you add a comment over there, explaining why you think the tools menu should have a gray background? That would be helpful. Thanks : )

In T318169#8576945, @Sideswipe9th wrote:

I'm more than happy to @ovasileva !

something I've wondered about in the past, which seems worth bringing up again given some people's frustration with the personal tools menu, is showing a few more items from the menu (and potentially adding labels) at larger screen resolutions:

@Prototyperspective a lot of updates have been made to the table of contents since you filed this task. Most notably the table of contents is now wider, and soon will be able to to take up more vertical space (T319315: [Table of contents] Increase max-height of TOC). Several other table of contents tasks we will be working on soon:

• T318186: [sub task] Show table of contents for pages with less than 4 sections
• T317818: [L] [SPIKE] Add configurability options for table of contents
• T314419: Increase offset for headings when clicking TOC links
• T317661: [Table of contents] Increase threshold for when a section is active
• T325086: When navigating directly to a sub-section, the table of contents section should expand (if collapsed) and be bolded
• T316060: [anon prefs] TOC pinned / unpinned status should persist across page views for anonymous users

In T317710#8616686, @Jdlrobson wrote:

@alexhollender_WMF should this ticket be declined?

In T315932#8615194, @bwang wrote:

@alexhollender_WMF As I was working on this I realized I didnt ever check how this would look on large screens, so I wanted to check with you on how this looks:

@Sj I think it might make sense to wait another few weeks — once we've done T318186: [sub task] Show table of contents for pages with less than 4 sections and T316060: [anon prefs] TOC pinned / unpinned status should persist across page views for anonymous users — to re-assess questions/concerns of the layout shifting around. I think it will be happening much less frequently in general. Also I think it's reasonable that if someone collapses a sidebar the layout shifts, especially if our assumption turns out to be true that people aren't frequently expanding and collapsing the sidebars.

In T328574#8578931, @bmartinezcalvo wrote:

...Please, list all changes you publish in production in the list in this task description and ping us to let us know when should we update the Figma template.

@Sj apologies for the confusion, I forgot we hadn't implemented this yet: T316060: [anon prefs] TOC pinned / unpinned status should persist across page views for anonymous users. We will be working on that soon.

In T318169#8599760, @nray wrote:

@alexhollender_WMF This and T319315 are now on beta (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Dog) if you'd like to design review.

In T327732#8596036, @Sj wrote:

Thanks for the links Alex. Appreciated; I realize phab works best with compact issues and isn't a great place for umbrella topics.

In T317818#8596042, @Sj wrote:

Given the title: is this the right place to discuss NOTOC / FORCETOC magic words?

all set 👍

@Sj thank you so much for all of this feedback (and your continued feedback elsewhere).

Thanks @Ferret, @Theklan, @Pcoombe, @Izno, and @stjn for the continued feedback.

In T289212#8591944, @Jdlrobson wrote:

Alex I think https://phabricator.wikimedia.org/T289212#8571752 is the source of confusion here. Perhaps such conversations could be kept separate from sprint tickets in future (will add to retro)?

@Jdlrobson

@Jdlrobson sorry for not providing mockups earlier on.

I'm going to resolve this task now because the original work has been completed, and our team is doing some board cleanup. I will of course continue to work on improvements relating to all of the above feedback. Where possible please direct further comments to the more specific, open tasks that I've linked to. Or to create a new task if there isn't one that corresponds with a given topic.

thanks @TheDJ @Jonesey95 & @Sj for all of this feedback, and for your continued, deep engagement with this work. I'm glad to hear that everyone thinks things are moving in the right direction.

just discussed with @nray

cc @ovasileva @Jdlrobson

@Jdlrobson I defer to @ovasileva regarding the importance of this change, and how much work is worth putting into it.
In case it wasn't clear, my thinking was just that: optional preferences are off by default, and then turning one on should modify the default experience (like the preference right above, "Enable responsive mode"). But perhaps that's overthinking it...maybe it's fine for some preferences to be on by default.

hey @Ferret & others, @ovasileva and I were discussing this some more today, and are curious what you think of https://di-article-tools-2.web.app/Blue_whale ? I think adding gray backgrounds to the TOC and page tools does a good job of making them distinct from the article content, and makes the page structure/areas much more clear (see https://www.w3.org/WAI/WCAG2/supplemental/patterns/o2p03-page-structure/ which recommends using background colors). I prefer it to Zebra #9, where the article content is framed in a white box, and everything else on the page is in a gray background. I still feel that Zebra #9 de-emphasizes the table of contents too much, and also adds unnecessary visual heaviness to the whole page (though I recognize that's quite subjective).

In T324877#8558003, @TheDJ wrote:

I added the following css rules to my user profile:

yup, that definitely looks better. I was trying to have consistent styling between the TOC, main menu, page tools, and personal tools, since they are all similar in many ways. thinking at this point it's okay to special-case the TOC (because I think that's one case where we want more line-height between the elements). I will create a separate task for that change.

In T326887#8558308, @Edtadros wrote:

@alexhollender_WMF, for QA testing am i validating the behavior at 1400 or 1200?

In T327718#8551812, @Jonesey95 wrote:

Please don't add to the already excessive white space in these menus without first decreasing the excessive padding between list items and fixing the font size. See T327732 for some details.

In T318169#8553437, @Pbsouthwood wrote:

Agree with Jonesy95. This is not a feature if you have to scroll up to find it every time you want to use it.

looks good to me 👍

In T324877#8547447, @Edtadros wrote:

@alexhollender_WMF, I found the issue below. Let me know if this is expected. Also, let me know if you want me to do any QA on this or if you have already verified it with your much keener eyes. This happens anon and logged in. I did make sure the compact language list was selected in preferences.

In T324877#8540834, @TheDJ wrote:

Can we get just a tad more separation between the menu levels ?
I feel this is just still awfully close, even with the line in between.

In T326887#8540781, @TheDJ wrote:

I still think 1200 is the best cutoff, as that is where the margin increases and creates space for it.

on articles with a table of contents, assuming the table of contents is pinned (which is the default) the toggle wouldn't do anything at 1200px

In T259240#8540680, @Ferret wrote:

This really isn't the same thing as the feedback from the extensive Discord meeting, which spent some time on the Zebra prototypes.

In T326672#8535384, @Jdlrobson wrote:

@alexhollender_WMF @bwang I think this is a duplicate of another ticket. Do you remember which?

circling back to @VulpesVulpes825's idea of adding a slight box-shadow to the main (white) container, to make it more clear/intentional that the gray area is out of bounds:

In T293470#8524507, @Izno wrote:

In T293470#8523965, @alexhollender_WMF wrote:

@TheDJ @Izno any chance either of you would be able to help us add an h1 with the language switcher to the main page on English before the launch? Or could you suggest other community developers who might be able to help?

See my opinions in T293470#7432150 and T293470#7432242. That is a request that requires community consensus and I don't think you will get it (I obviously do not speak for them but I'd put the odds of acceptance somewhere between "not a snowball's chance in hell, thank you for asking" and "over our dead body" :).

Having something like Create language switcher templates for main page would go a way to starting a conversation about potentially raising the profile of these links, but I provide no guarantees and would probably rate effort spent on that, without discussion with affected communities, as being wasted.

Noting that we've heard a bunch of additional feedback from people:

• people are using the full-width toggle
• people would like the full-width toggle available at lower resolutions

@ovasileva looks like we still don't have tooltips on a few things, and this hasn't been fixed: