Page MenuHomePhabricator

Variant C/D: homepage layout changes
Closed, ResolvedPublic

Description

For the variant tests in T246533: Variant tests: "initiation part 2" test (C vs. D), there are some layout changes to the homepage on desktop that variant C and D have in common.

  • Move the impact module to the (right-hand side) sidebar, at the top (above the mentorship module)
  • Widen the suggested edits module to take up the space where the impact module was

See this mockup.

This should only apply to variants C and D, and not variant A.

Layout specs

There are 2 breakpoints in variants C & D, which result in 3 possible layouts.

Standard
image.png (1×1 px, 251 KB)
Narrow
image.png (1×1 px, 232 KB)
Wide
image.png (1×2 px, 269 KB)

Details on the following codepen: https://codepen.io/reets/pen/dyGaxQO?editors=1100

1. "Standard" layout

  • The .growthexperiments-homepage-container changes max and min widths:
    • { min-width: 600px; /*RH changed from 800px*/ }
    • { max-width: 1440px; /*RH changed from 1600px*/ }
  • The .growthexperiments-homepage-group-main has a width:64% (previously 75%)
  • The .growthexperiments-homepage-group-sidebar has a width:36% (previously 25%)
  • The Impact module is moved to the sidebar, on top of the help and mentor items
  • The .growthexperiments-homepage-module has reduced margins: 8px (previously 12px)

2. Narrow layout

  • This involves modifying the existing from @media (max-width: 1024px) to @media (max-width: 800px)
  • The Impact module takes up width:calc(50% - 8px); of the sidebar, the help and mentor modules are in a second column with the same width.

3. Wide layout

  • This involves adding a new breakpoint for @media (min-width:1280px)
  • Both the main and sidebar containers have width:50%
  • Within the sidebar, the Impact module takes up width:calc(50% - 8px); of the sidebar, the help and mentor modules are in a second column with the same width.

Suggested edits module changes are broken out into T258704

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

image.png (1×3 px, 389 KB)

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

image.png (1×3 px, 387 KB)

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

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

image.png (1×3 px, 389 KB)

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

image.png (1×3 px, 387 KB)

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:

image.png (930×1 px, 319 KB)

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:

image.png (1×800 px, 294 KB)

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:

image.png (800×1 px, 297 KB)

Etonkovidova subscribed.

Moving to Need more work per @RHo comments.

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

Screen Shot 2020-07-22 at 6.04.56 PM.png (641×1 px, 238 KB)

variant A

Screen Shot 2020-07-22 at 6.03.15 PM.png (680×1 px, 214 KB)

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

  1. 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?

  1. 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:

image.png (1×1 px, 377 KB)

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

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:

masterwith the patch
T258005-old.png (1×1 px, 227 KB)
T258005-new.png (1×1 px, 232 KB)

Not sure if that's intentional.

The last patch makes the variant A sidebar narrower:

masterwith the patch
T258005-old.png (1×1 px, 227 KB)
T258005-new.png (1×1 px, 232 KB)

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)
Screenshot from 2020-08-10 20-02-39.png (941×1 px, 237 KB)
Variant C/D @ 1279px (standard)
Screenshot from 2020-08-10 20-17-02.png (976×1 px, 142 KB)
Screenshot from 2020-08-10 20-17-39.png (465×1 px, 37 KB)
Variant C/D @ 1975px (wide)
Screenshot from 2020-08-10 20-15-04.png (909×1 px, 159 KB)
Variant C/D @ 801px (standard)
Screenshot from 2020-08-10 20-18-44.png (975×632 px, 140 KB)
Screenshot from 2020-08-10 20-19-20.png (461×638 px, 29 KB)
Variant C/D @ 1281px (wide)
Screenshot from 2020-08-10 20-16-13.png (966×1 px, 162 KB)
Variant C/D @ 799px (narrow)
Screenshot from 2020-08-10 20-20-33.png (955×636 px, 83 KB)
Screenshot from 2020-08-10 20-20-48.png (822×647 px, 78 KB)

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

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:

image.png (831×1 px, 186 KB)

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

image.png (121×784 px, 10 KB)

  • Is there supposed to be a white box around the message at the bottom of the suggested edits module? (@RHo?)
    image.png (121×784 px, 10 KB)

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

variant CvariantD
Screen Shot 2020-10-01 at 5.26.34 PM.png (256×715 px, 31 KB)
Screen Shot 2020-10-01 at 5.27.55 PM.png (217×717 px, 27 KB)

Chrome displays it correctly for all variants:

Screen Shot 2020-10-01 at 5.32.02 PM.png (414×543 px, 97 KB)

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

Chrome displays it correctly for all variants:

Screen Shot 2020-10-01 at 5.32.02 PM.png (414×543 px, 97 KB)

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.

  • Is there supposed to be a white box around the message at the bottom of the suggested edits module? (@RHo?)
    image.png (121×784 px, 10 KB)

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

variant CvariantD
Screen Shot 2020-10-01 at 5.26.34 PM.png (256×715 px, 31 KB)
Screen Shot 2020-10-01 at 5.27.55 PM.png (217×717 px, 27 KB)

Chrome displays it correctly for all variants:

Screen Shot 2020-10-01 at 5.32.02 PM.png (414×543 px, 97 KB)

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?

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.

@Etonkovidova -- can you reproduce the autoscrolling issue?

Nope, I cannot reproduce it either

NOTE: moving for Design review to see whether something else here needs to be adjusted. I'll be testing (1) other browers (2) new Vector skin

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 screensmall screen (before breaking point)
Screen Shot 2020-10-08 at 10.19.24 AM.png (876×1 px, 291 KB)
1440x908
Screen Shot 2020-10-08 at 10.25.00 AM.png (680×744 px, 205 KB)
800x908

The gif for the small screen - variant A

variantA_Legacy Vector_small screen.gif (797×729 px, 1 MB)


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 screensmall screen(before breaking point)
Screen Shot 2020-10-08 at 11.11.07 AM.png (771×1 px, 170 KB)
Screen Shot 2020-10-08 at 11.05.08 AM.png (779×642 px, 118 KB)

The gif for the small screen - variant D

variantD_Legacy Vector_small screen.gif (632×600 px, 940 KB)

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

image.png (926×1 px, 233 KB)

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.

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

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

image.png (926×1 px, 233 KB)

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.

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

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

image.png (926×1 px, 233 KB)

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.

image.png (608×967 px, 201 KB)

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.

image.png (608×967 px, 201 KB)

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.

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.

image.png (608×967 px, 201 KB)

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?

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.

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.

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