Change #1308678 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Expand toolbar to two lines when appearance menu pinned but toolbox not

https://gerrit.wikimedia.org/r/1308678

Change #1308678 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Expand toolbar to two lines when appearance menu pinned but toolbox not

https://gerrit.wikimedia.org/r/1308678

Change #1308697 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@wmf/1.47.0-wmf.10] Improve responsiveness of toolbelt

https://gerrit.wikimedia.org/r/1308697

Change #1308227 abandoned by Jdlrobson:

[mediawiki/skins/Vector@wmf/1.47.0-wmf.10] Improve responsiveness of toolbelt

Reason:

See https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1308697?usp=search

https://gerrit.wikimedia.org/r/1308227

Change #1308773 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Feature gate navigation update behind VectorNavigationUpdateTemporary

https://gerrit.wikimedia.org/r/1308773

Change #1308773 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Feature gate navigation update behind VectorNavigationUpdateTemporary

https://gerrit.wikimedia.org/r/1308773

Change #1308697 abandoned by Jdlrobson:

[mediawiki/skins/Vector@wmf/1.47.0-wmf.10] Improve responsiveness of toolbelt

Reason:

We decided to feature flag instead https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1308773?usp=search

https://gerrit.wikimedia.org/r/1308697

This is now feature flagged. You can see it at https://en.wikipedia.beta.wmcloud.org/w/index.php?title=Main_Page&vectornavigationupdate=1

Change #1314063 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/skins/Vector@master] [proof of concept] Break page toolbar based on available space

https://gerrit.wikimedia.org/r/1314063

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://23e476ed0e.catalyst.wmcloud.org/w/

@HFan-WMF, @Sneha, @bwang, @Jdlrobson-WMF

I've prototyped ideas from Hsuanwei (breaking to 2 lines based on available space) and Bernard (adding a border between the 2 lines) - check out the patchdemo. I'd recommend logging into the Patch Demo account, or creating an account then opting into the Saved Pages beta feature. You can go to a random page then change the language to one with longer words like German, e.g. https://23e476ed0e.catalyst.wmcloud.org/wiki/Regent's_Park?uselang=de. Bonus point for watching the page, since the translation for "unwatch" in German is especially long.

In English, especially if you're not watching a page, you will basically never see the breaking behavior. This should work with known gadgets like Twinkle and MoreMenu since they're contained within the right nav, which I'm checking as part of the calculation to decide whether to break or not.

It does require a small script. Curious to hear thoughts on that. The nojs behavior would just be the status quo on production right now.

Please test this out and let me know every way in which this won't work 😅

Test wiki created on Patch demo by JHuneidi (WMF) using patch(es) linked to this task:
https://046f311c9f.catalyst.wmcloud.org/w/

Test wiki on Patch demo by JHuneidi (WMF) using patch(es) linked to this task was deleted:

https://046f311c9f.catalyst.wmcloud.org/w/

Overall I like the design tweaks!

It does require a small script. Curious to hear thoughts on that. The nojs behavior would just be the status quo on production right now.

I think it's critical we avoid any on layout shifts on page load as this could have a knock on effect on Google Web Vitals and we know on slow connections JS can load very late leading to misclicks (we see this for example in banner campaigns where there is a high click through rate but lower 2nd action).

On page load, for example logged in with both menus at both sides pinned, at 1200px I see a layout shift and that's the viewport that everyone on a mobile device (e.g. iPad) will be hitting due to our viewport meta tag.

Is it possible to restrict the JS optimization to a resize event to avoid that occurring on page load?

Given most desktop users are seeing this view after a resize I think this would probably satisfy most users.

If we want to get a similar effect on page load perhaps we need to add a render blocking script to do this or explore adding a class/LESS variable that is dynamic based on the combined length of all labels?

In T429518#12147837, @Jdlrobson-WMF wrote:

I think it's critical we avoid any on layout shifts on page load as this could have a knock on effect on Google Web Vitals and we know on slow connections JS can load very late leading to misclicks (we see this for example in banner campaigns where there is a high click through rate but lower 2nd action).

Is it possible to restrict the JS optimization to a resize event to avoid that occurring on page load?

Given most desktop users are seeing this view after a resize I think this would probably satisfy most users.

Excellent point, and I can just remove the initial call to add the class. I agree that this tradeoff is worth avoiding layout shift or a render-blocking script (although I'd like to learn more about what goes into deciding when it's worth adding the latter).

Change #1314974 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/skins/Vector@master] Group watch/unwatch with edit links in 2-line page toolbar

https://gerrit.wikimedia.org/r/1314974

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://82db7c8d4b.catalyst.wmcloud.org/w/

@Sneha I've created a patchdemo (recommend logging into the Patch Demo account or creating an account then enabling the "saved pages" beta feature) where the watch/unwatch link is grouped with the edit links on the left like you suggested, let me know what you think!

Thanks @AnneT this is looking pretty good. I wonder if the users have some gadgets enabled (as documented in T430221) everything will be folded into the options menu sooner as there would be no space?

I also noticed that when the tools menu is hidden the responsive changes don't not jump around as much i.e. goes form one line, to two line, to everything in options menu. Whereas when the tools menu is pinned to side it goes from one line, to two lines, back to one line (as we fold the tools menu), then back to two lines, and then eventually everything is in options menu. Which might be okay since we don't want to hide any options as long as there is space available.

@Ponor @Izno @Hakimi97 (and anyone else who's interested) - pinging you all because you've talked to the Reader Experience team in the past about our updates to the page toolbar

We've been working on improving the page toolbar layout, especially in longer languages, where the toolbar is becoming cramped due to the addition of the watch button label. I've been experimenting with breaking the toolbar onto 2 lines when there's not enough horizontal space for everything. If you're interested, would you check out this patchdemo and let me know what you think? I'd recommend:

• Setting the language to German or another language with relatively long words
• Logging in (you can log into the Patch Demo account, or create a throwaway account)
• Turning on the "saved pages" beta feature so you get the bookmark button
• Watching a page (since the "unwatch" label is longer)
• Testing that page at various viewport widths

You can also test in English, where you should see little to no line breaking (if you had a few gadgets in the toolbar, you might start to see the line breaking at certain viewport sizes).

Well, you definitely need to check what you've programmed when "saved pages" feature is disabled, because the entire edit "row" just disappears at a small resolution, without being sucked into the menu. (Making turning the beta feature on a requirement for experimentation.)

Moving on from that slight issue :):

I have no large issue with a second row. I would be thinking about whether it's necessary to suck into the menu if you do present a second row instead. You could get rid of what appears to be a nowrap at the group level so the items can fall into arbitrary count of rows.

(NB there was a gadget or POC someone had come up with in the past week or two that I saw that made the top bar a real permanent feature so you can reach the edit button at any time. So this might be a consideration in the opposite direction.)

Not sure that I like that the menu goes to the second row with the edit group. Might be a technical limitation to its positioning though so, weigh accordingly.

In general I support more responsiveness (which reminds me that I need to file a task about the watchlist sometime).

Hi @AnneT , thanks for pinging me.

The demo version now displays a line between left-navigation (containing p-associated-pages and vector-variants-dropdown) and right-navigation (containing p-views and vector-page-tools-landmark) when they are becoming two separate lines for whatever reason, perhaps this is an intended feature. And the line between them might be is related to the CSS code that I observed:

@media screen and (min-width: calc(639px)) and (max-width: calc(1679px)) {
    .vector-page-toolbar-container--expand #left-navigation {
        box-shadow: 0 1px var(--border-color-subtle, #c8ccd1);
    }
}

But then, I noticed an issue whereby the line somehow protrudes before the position of the words "Seite" and "Bearbeiten":

which might be caused by:

#right-navigation, #left-navigation {
    margin: 0 -8px;
}

Is there anything that could be done to tidy up this minor issue perhaps?

In T429518#12173103, @Izno wrote:

Well, you definitely need to check what you've programmed when "saved pages" feature is disabled, because the entire edit "row" just disappears at a small resolution, without being sucked into the menu. (Making turning the beta feature on a requirement for experimentation.)

Thanks for pointing this out; I've opened T433691 to cover this bug.

I have no large issue with a second row. I would be thinking about whether it's necessary to suck into the menu if you do present a second row instead. You could get rid of what appears to be a nowrap at the group level so the items can fall into arbitrary count of rows.

I did play around with just applying flex-wrap: wrap by default and it worked well in terms of line-breaking, but I couldn't think of a CSS-only way to push the bookmark button (if applicable) and the tools menu to the end of the toolbar only when it's in the 2-line state. Open to suggestions though; a no-JS solution would be great if possible and I'll mention this to our designer in case she can think of an acceptable design change that would allow us to do this with just CSS

(NB there was a gadget or POC someone had come up with in the past week or two that I saw that made the top bar a real permanent feature so you can reach the edit button at any time. So this might be a consideration in the opposite direction.)

Do you mean not collapsing the edit link into the menu on very small screens? Or something else? Just want to make sure I understand this fully.

Not sure that I like that the menu goes to the second row with the edit group. Might be a technical limitation to its positioning though so, weigh accordingly.

We could do this, but it would mean double-rendering the menu and hiding one of them with CSS depending on the state of the toolbar. I'd like to reduce the complexity as much as we can, so would recommend we keep the menu where it is at least for now. But I'll take this feedback back to our designer too and we could do this in a future iteration if necessary.

Test wiki created on Patch demo by ATomasevich (WMF) using patch(es) linked to this task:
https://f8ca352c09.catalyst.wmcloud.org/w/

In T429518#12176851, @Hakimi97 wrote:

But then, I noticed an issue whereby the line somehow protrudes before the position of the words "Seite" and "Bearbeiten":
Is there anything that could be done to tidy up this minor issue perhaps?

Thanks for catching this! I've updated the CSS and created a new patchdemo where the issue should be resolved.

Change #1314974 abandoned by Anne Tomasevich:

[mediawiki/skins/Vector@master] [PoC] Group watch/unwatch with edit links in 2-line page toolbar

Reason:

Folded into the parent patch for easier reverting

https://gerrit.wikimedia.org/r/1314974

Change #1314063 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Break page toolbar based on available space

https://gerrit.wikimedia.org/r/1314063

I tried this on beta and noticed that the "read" tab is disappearing when the items go to the second line.

Thanks for testing, @Sneha! Based on feedback in the thread above, we intentionally removed the "read" link when the menu breaks to a second line to save space, because the link is somewhat redundant unless you're editing the page (we've kept the "read" link in that case). Let me know if you disagree with that decision

Yeah the presence of read tab feel redundant and I believe the only reason we have not removed it entirely is because currently there is no obvious way of going back to reading from edit mode or other tabs. But it makes sense if it still persist in those situations. All good from my side. Sorry missed that discussion above.

I've tested the changes using https://de.wikipedia.beta.wmcloud.org/wiki/DC-37?vectornavigationupdate=1&uselang=de

The reading list icon disappears and the "unwatch" button gets cut-off when zooming in:

Perhaps this overcomplicates things (or might be confusing to users?), but I'm wondering if it would be possible to only remove the "read" menu item if there's not enough space? "Read" / "Lesen" would easily fit in some cases:

Noticed this when zooming out a couple in Greek (width set to "Standard" in the Wikipedia appearance menu; using Safari on an 13-inch screen)

Another minor issue I noticed: When changing the language (without zooming in/out!) the line break sometimes doesn't occur, even though it should. Zooming out 1x and zooming in again to the previous size suddenly shows the line break as intended:

@Johannnes89 I notice "Pending changes" is duplicated in the UI - as a tab and as an indicator in the top right. Is that standard for German Wikipedia and something we should reconsider to free up some space at lower resolutions?

@HFan-WMF moving this to sign-off - when you do so could you also review the above issues reported by @Johannnes89 (thank you so much for testing!) and let us know which of them we should prioritize next?

In T429518#12213903, @Jdlrobson-WMF wrote:

@Johannnes89 I notice "Pending changes" is duplicated in the UI - as a tab and as an indicator in the top right. Is that standard for German Wikipedia and something we should reconsider to free up some space at lower resolutions?

I believe it's standard for all wikis using FlaggedRevisions or PendingChanges, e.g. German and English Wikipedia both use the indicator (some wikis like ruwiki opted for different design options T372694). The indicator got implemented as part of T191156 (see T191156#10055466 for the previous version).

Logged-in users always see the "pending changes" tab per default (with the UI icon serving as a reminder that this isn't reviewed yet and offering a review button on hover if the user has the necessary permissions).

Readers (logged-out users) will see the "Read" tab per default on German and English Wikipedia (which also shows an indicator if there are unreviewed edits). Most other wikis show the "pending changes" tab per default even to logged-out users.

Selecting the "review" button will open the pending changes tab and also show the diff + review options

TLDR: Indicator and pending changes tab serve different purposes and I don't think one could easily free up space by removing either of these, both logged-in users and readers should be able to easily switch between reading the reviewed and unreviewed version of the article.

This is what it looks like after merging the https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1314063 on Test Wikipedia:

I noticed that although the left-side protruding line mentioned previously has been solved, I am not sure as to why the line on the right side looks shorter and indented to the left. I am fine with it since it looks special and nice to me, but if this is not intended then something might need to be done here.

Change #1326888 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Remove unused feature flag

https://gerrit.wikimedia.org/r/1326888

The feature flag was made redundant by this change so moving back to code review to get this cleaned up.

Another bug that I noticed, let say I add a new portlet on Test Wikipedia ( https://test.wikipedia.org/wiki/User:Hakimi97/common.js ), if I open https://test.wikipedia.org/wiki/Rounding?uselang=de then the page view looks like this:

Only when I right click and select "Inspect" then it becomes like this (I believe this should be the ideal configuration of the namespace tabs):

Change #1326888 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Remove unused feature flag for navigation

https://gerrit.wikimedia.org/r/1326888

Only when I right click and select "Inspect" then it becomes like this (I believe this should be the ideal configuration of the namespace tabs):

Yes currently the layout only adjusts on a resize. Gadgets use a different event - so we'd need to subscribe to that event to like so:
https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1327638
@HFan-WMF worth a follow up task?

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://23e476ed0e.catalyst.wmcloud.org/w/

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://82db7c8d4b.catalyst.wmcloud.org/w/

Test wiki on Patch demo by ATomasevich (WMF) using patch(es) linked to this task was deleted:

https://f8ca352c09.catalyst.wmcloud.org/w/