@RHo on my wide monitor, here is what the existing 75%/25% ratio between main and sidebar looks like with this layout change; it pushes the next module (mentorship) a bit farther down out of view.

If we change the ratio to 66% / 34% for main/sidebar it looks like this:

Do you have a preference between those?

Change 615487 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Output variant specific CSS classes for homepage modules

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

Change 615489 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Homepage: Provide shared layout for variant C and D users

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

Change 615490 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Homepage: Stretch suggested edits to 100% width for variants C/D

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

The suggested edits module changes (expanding to fill up the larger space) will be a separate task; this one is ready for code review.

Change 615487 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Output variant specific CSS classes for homepage modules

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

Change 615489 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Provide shared layout for variant C and D users

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

Change 615490 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Stretch suggested edits to 100% width for variants C/D

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

In T258005#6325980, @kostajh wrote:

@RHo on my wide monitor, here is what the existing 75%/25% ratio between main and sidebar looks like with this layout change; it pushes the next module (mentorship) a bit farther down out of view.

If we change the ratio to 66% / 34% for main/sidebar it looks like this:

Do you have a preference between those?

Actually, I would like to propose the following changes:

1. For @media (min-width: 800px) and (max-width:1280px) changing the width of .growthexperiments-homepage-group-main to width:64% (and therefore sidebar to 36%). This gives approximately the layout dimensions of the mock:

2. For @media (max-width: 800px), changing the layout so that both the "main" content and the sidebar below it are at width:100%`.
Additionally, could we make the Impact module take up 50% of one column, and the mentor and help flex to the other side, as illustrated in the mock below:

3. For @media (min-width: 1280px), could we make both the "main" content and the sidebar below it are at width:50%`, with again the Impact module taking up 50% as the left column of the sidebar container, as illustrated in the mock below:

Moving to Need more work per @RHo comments.

The screenshots just to illustrate the present layout:
variants C/D

variant A

Change 615690 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Homepage: Adjust layout width

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

2. For @media (max-width: 800px), changing the layout so that both the "main" content and the sidebar below it are at width:100%`.

Additionally, could we make the Impact module take up 50% of one column, and the mentor and help flex to the other side, as illustrated in the mock below:

We currently set the minimum width to 800px (done in 1ca13dff89812bd67f04c00cc1c6ffe190735d27), if we do this change, what would the new minimum width be? And would we fall back to single column mode at some point?

3. For @media (min-width: 1280px), could we make both the "main" content and the sidebar below it are at width:50%`, with again the Impact module taking up 50% as the left column of the sidebar container, as illustrated in the mock below:

I think so. I took a look at the initiated impact module in that narrower form and it seems OK:

In T258005#6329104, @kostajh wrote:

2. For @media (max-width: 800px), changing the layout so that both the "main" content and the sidebar below it are at width:100%`.

Additionally, could we make the Impact module take up 50% of one column, and the mentor and help flex to the other side, as illustrated in the mock below:

We currently set the minimum width to 800px (done in 1ca13dff89812bd67f04c00cc1c6ffe190735d27), if we do this change, what would the new minimum width be? And would we fall back to single column mode at some point?

Hi @kostajh - I'd propose this be reduced to 600px. Please see the updated task description where I've tried to take a bit more time to illustrate the layout changes with details in this codepen: https://codepen.io/reets/pen/dyGaxQO.

Change 615690 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Adjust layout width

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

In T258005#6331652, @gerritbot wrote:

Change 615690 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Adjust layout width

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

This patch only did the 64/36 change (#1 from T258005#6328261). #2 and #3 remain.

Change 616745 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Homepage: Variation C/D layout changes

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

The last patch makes the variant A sidebar narrower:

master	with the patch

Not sure if that's intentional.

In T258005#6361603, @Tgr wrote:

The last patch makes the variant A sidebar narrower:

master	with the patch

Not sure if that's intentional.

That's not what I see.

With the last patch (which I made some changes to today), it now looks like this:

Variant A (wide)		Variant C/D @ 1279px (standard)
Variant C/D @ 1975px (wide)		Variant C/D @ 801px (standard)
Variant C/D @ 1281px (wide)		Variant C/D @ 799px (narrow)

You need to change the mentor message to something shorter to reproduce.

In T258005#6403399, @Tgr wrote:

You need to change the mentor message to something shorter to reproduce.

Thanks, that exposed the issue. You were right about the cause too. Fixed in the latest patchset.

Change 616745 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Variant C/D layout changes

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

To QA, you can opt-in to variation A/C/D with:

new mw.Api().saveOption(
	'growthexperiments-homepage-variant',
	'D' // or replace with 'A' or 'C'
);

in your browser console, press "enter", then reload the page.

For Design review - thanks @Catrope for the screenshots in this comment, I don't need to provide any additional screenshots here.

I checked on

• different browsers- no issues were found.
• wrapping for article titles/general text in the Impact module

and no issues were found.

Thanks all! I agree the Impact module text overflow looks not great at certain widths and layouts.
However, I'd consider the main layout task as done and have created a leftover task with a proposed change to resolve this at T262168. @MMiller_WMF perhaps this can be reviewed along with the other variant c/d leftovers tasks we've the past week to see if any should be given higher prio?

Change 629375 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Homepage layout and wide format SE module

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

Change 629375 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage layout and wide format SE module

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

Per conversation with @MMiller_WMF - an easy improvement is to increase the breakpoint for the wide layout as mentioned in T258704#6501473. This makes sense as well given we have also increased the min-width of the narrow layout.

@Catrope @kostajh -- I just finished testing both Variants C and D on desktop in beta, and I have these issues:

• When I first visit the homepage in Variant D, I am autoscrolled down the page to this view. This happened to me for all three accounts I created:

• Is there supposed to be a white box around the message at the bottom of the suggested edits module? (@RHo?)

In T258005#6510923, @MMiller_WMF wrote:

• Is there supposed to be a white box around the message at the bottom of the suggested edits module? (@RHo?)
  

It happens for variant D in FF (variant C displays it differently).

variant C	variantD

Chrome displays it correctly for all variants:

In T258005#6510923, @MMiller_WMF wrote:

@Catrope @kostajh -- I just finished testing both Variants C and D on desktop in beta, and I have these issues:

• When I first visit the homepage in Variant D, I am autoscrolled down the page to this view. This happened to me for all three accounts I created:

I could not reproduce this issue, neither in Firefox nor in Chrome.

In T258005#6511031, @Etonkovidova wrote:

Chrome displays it correctly for all variants:

That's not what I'm seeing, it's broken for me in Chrome too. It looks the same (broken) way in variant C and D in both Firefox and Chrome, but it looks right in variant A. It looks like that's just a coincidence: in both cases, the white area is only as wide as it needs to be. But in variant A, the card is narrower, and the text is so long that the white area has to be full width for the text to fit (and even then it wraps), but in C/D the card is wider, and the white area doesn't have to be full width for the text to fit.

Change 631564 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Fix footer display

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

Moving to Code Review because I couldn't reproduce the autoscrolling issue; please move back to Needs More Work if someone other than Marshall can reproduce it.

In T258005#6511031, @Etonkovidova wrote:

In T258005#6510923, @MMiller_WMF wrote:

• Is there supposed to be a white box around the message at the bottom of the suggested edits module? (@RHo?)
  

It happens for variant D in FF (variant C displays it differently).

variant C	variantD

Chrome displays it correctly for all variants:

I believe this is item E on T258704 (footer should be flush to bottom and sides of SE module).

@Etonkovidova -- can you reproduce the autoscrolling issue?

In T258005#6512685, @RHo wrote:

I believe this is item E on T258704 (footer should be flush to bottom and sides of SE module).

You're right. I've tagged my patch with both that task and this task.

Change 631564 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] SuggestedEdits: Fix footer display

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

I can't reproduce the autoscroll issue either. @MMiller_WMF it happens consistently for you?

The footer issue should be fixed.

In T258005#6513546, @MMiller_WMF wrote:

@Etonkovidova -- can you reproduce the autoscrolling issue?

Nope, I cannot reproduce it either

The screenshots (and gifs) for the specs in the task description:

• Legacy Vector skin
• Chrome
• variants A/C/D

body.mw-special-Homepage.growthexperiments-homepage-desktop .growthexperiments-homepage-container-user-variant-A {
    min-width: 800px;
    max-width: 1600px;

body.mw-special-Homepage.growthexperiments-homepage-desktop .growthexperiments-homepage-container-user-variant-C, body.mw-special-Homepage.growthexperiments-homepage-desktop .growthexperiments-homepage-container-user-variant-D {
    min-width: 520px;
    max-width: 1650px;

body.mw-special-Homepage.growthexperiments-homepage-desktop .growthexperiments-homepage-container-user-variant-C, body.mw-special-Homepage.growthexperiments-homepage-desktop .growthexperiments-homepage-container-user-variant-D {
    min-width: 520px;
    max-width: 1650px;

variant A
the issues:

• the position of a blue dot
• the Impact module has lot of empty space
• the arrows go beyond the module boundaries when the screen get resizing

wide screen	small screen (before breaking point)
1440x908	800x908

The gif for the small screen - variant A

variant D and C
the issues:

• the position of the blue dot
• (don't pay attention to the partially displayed info icon - it's displayed like this because of scaling the screen).

wide screen	small screen(before breaking point)

The gif for the small screen - variant D

Thanks @Etonkovidova - I filed a bug task for the blue dot (T265262). As for the other issues, I believe they are resolved by variant A being switched off, and by the layout leftovers task T264462

The current implementation of the page in the new vector looks rather strange.

• Stretched columns
• The help module is not visible at all
• Compressed text on the right side
• Page tab has lost border on the left

And if we are already talking in this topic, then it seems to me that the 'help block' should be put above 'your impact'.

@Iniquity -- thanks for your feedback on the design. I'm pinging our team's designer, @RHo, who can explain why we've arranged it the way we have.

In T258005#6764130, @MMiller_WMF wrote:

@Iniquity -- thanks for your feedback on the design. I'm pinging our team's designer, @RHo, who can explain why we've arranged it the way we have.

In T258005#6750524, @Iniquity wrote:

The current implementation of the page in the new vector looks rather strange.

• Stretched columns
• The help module is not visible at all
• Compressed text on the right side
• Page tab has lost border on the left

Hi @Iniquity - thanks for taking a close look at the page. Regarding the visual design changes on the newcomer homepage layout, these are part of the revised Variant C & D design intended to make the Suggested edits tasks a more prominent focus (more details are on T246533). It was a conscious decision to make the Suggested edits module larger, and the other modules narrower and invariably longer in this new layout. Similarly, the impact module placement is to promote the value of editing. We should be sharing results of how these revised layout variants did in the coming weeks on our team's updates page so please watch that space for an update.

Regarding the lack of left border on the first tab in your screenshot, it's due changes from the Desktop improvements project, where all Special pages on wider screens do not have the LHS border for the first tab. The Reading Web team is accepting feedback on the design on Phab in this task T258277: A friendly place to share your initial reactions to the first release of desktop improvements., where there are already a few comments about this in case you'd like to add your input too.

In T258005#6765342, @RHo wrote:

In T258005#6764130, @MMiller_WMF wrote:

@Iniquity -- thanks for your feedback on the design. I'm pinging our team's designer, @RHo, who can explain why we've arranged it the way we have.

In T258005#6750524, @Iniquity wrote:

The current implementation of the page in the new vector looks rather strange.

• Stretched columns
• The help module is not visible at all
• Compressed text on the right side
• Page tab has lost border on the left

Hi @Iniquity - thanks for taking a close look at the page. Regarding the visual design changes on the newcomer homepage layout, these are part of the revised Variant C & D design intended to make the Suggested edits tasks a more prominent focus (more details are on T246533). It was a conscious decision to make the Suggested edits module larger, and the other modules narrower and invariably longer in this new layout. Similarly, the impact module placement is to promote the value of editing. We should be sharing results of how these revised layout variants did in the coming weeks on our team's updates page so please watch that space for an update.

Regarding the lack of left border on the first tab in your screenshot, it's due changes from the Desktop improvements project, where all Special pages on wider screens do not have the LHS border for the first tab. The Reading Web team is accepting feedback on the design on Phab in this task T258277: A friendly place to share your initial reactions to the first release of desktop improvements., where there are already a few comments about this in case you'd like to add your input too.

Thanks for the detailed answer! I hope the analysis will show that the page will need to be redesigned :) And even if it doesn't, we will deal with this issue.

I would like to know why do we always show the user's email address? Is this done on purpose? I just couldn't find a discussion.

In T258005#6826208, @Iniquity wrote:

I would like to know why do we always show the user's email address? Is this done on purpose? I just couldn't find a discussion.

Hi @Iniquity - there is already a task T237312 to anonymize the user's email address but has been on the backlog for a while. I've just moved it into the Current sprint board in case we can work on it sooner along with the related task T260780.

In T258005#6826475, @RHo wrote:

In T258005#6826208, @Iniquity wrote:

I would like to know why do we always show the user's email address? Is this done on purpose? I just couldn't find a discussion.

Hi @Iniquity - there is already a task T237312 to anonymize the user's email address but has been on the backlog for a while. I've just moved it into the Current sprint board in case we can work on it sooner along with the related task T260780.

Thanks for the tasks! :) But this block confuses me in general, is it really necessary?
UPD: Why do we show to user his email, and without the ability to remove the block?

In T258005#6826521, @Iniquity wrote:

Thanks for the tasks! :) But this block confuses me in general, is it really necessary?

Ah is your question why we even show this at all? It's to encourage newcomers to add a confirmed email address, so that we have the option to reach them offwiki to re-engage them in participating via an email notification. There's a whole series of tasks related to increasing "emailability" with a longer explanation under this epic T215626, even though you will notice we have not yet determined it necessary to do more messaging to newcomers this way, based on a healthy influx of usage to date.

In T258005#6826539, @RHo wrote:

In T258005#6826521, @Iniquity wrote:

Thanks for the tasks! :) But this block confuses me in general, is it really necessary?

Ah is your question why we even show this at all? It's to encourage newcomers to add a confirmed email address, so that we have the option to reach them offwiki to re-engage them in participating via an email notification. There's a whole series of tasks related to increasing "emailability" with a longer explanation under this epic T215626, even though you will notice we have not yet determined it necessary to do more messaging to newcomers this way, based on a healthy influx of usage to date.

Ah, I got the main point. But maybe after confirming the email, this block should be removed altogether? It's just that at the moment it does not carry any payload, especially for participants who have been in the project for a month, or who have already indicated their email. And given that it is located in one of the most overlooked areas, it draws attention to itself.

In T258005#6826548, @Iniquity wrote:

In T258005#6826539, @RHo wrote:

In T258005#6826521, @Iniquity wrote:

Thanks for the tasks! :) But this block confuses me in general, is it really necessary?

Ah is your question why we even show this at all? It's to encourage newcomers to add a confirmed email address, so that we have the option to reach them offwiki to re-engage them in participating via an email notification. There's a whole series of tasks related to increasing "emailability" with a longer explanation under this epic T215626, even though you will notice we have not yet determined it necessary to do more messaging to newcomers this way, based on a healthy influx of usage to date.

Ah, I got the main point. But maybe after confirming the email, this block should be removed altogether? It's just that at the moment it does not carry any payload, especially for participants who have been in the project for a month, or who have already indicated their email. And given that it is located in one of the most overlooked areas, it draws attention to itself.

Very good point @Iniquity! Which is why I took a bit of time to respond as I had to make a task and mocks to let people remove it here T275155: Homepage: allow users to remove the startemail module from the homepage once their email is confirmed