Change 860566 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] NewImpact: Add minimum height for mobile overlay summary

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

Change 860571 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] NewImpact: Add minimum height for unactivated desktop

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

Change 860578 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] NewImpact: Set minimum height for activated desktop module

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

Change 860566 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] NewImpact: Set minimum height for mobile overlay summary

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

Change 860578 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] NewImpact: Set minimum height for activated desktop module

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

Change 860571 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] NewImpact: Set minimum height for unactivated desktop

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

After seeing the problems in T325339: [wmf.14-minor] arwiki - Impact module: ext-growthExperiments-NoEditsDisplay__footer is not placed at the bottom I wonder if using the min-height approach is the best to sort the minimal sorting state. I think the min-height approach is fair when the content size is predictable but here there are some cases where the content length can vary. @kostajh did you use this approach with good results in other places?

I think vertical bumps are not critical on desktop for this particular module since the Suggested edits module is already giving more height to the homepage area. In mobile vertical bumps can be annoying, maybe we could just set a fixed height ( max bound ) instead of min-height in the overlay summary which is the most sensitive view to vertical bumps.

Note aside, my perception is that the most relevant thing to cover in an initial loading state is the time while Javascript is loading. Having an empty box, even if with a some height doesn't seem to indicate something is gonna load there. The screenshot above shows what user on a slow connection may get with the current status:

I would suggest adding any kind of loading animation (css only) that can give the user some expectation something is gonna show in the box.

In T323572#8484270, @Sgs wrote:

After seeing the problems in T325339: [wmf.14-minor] arwiki - Impact module: ext-growthExperiments-NoEditsDisplay__footer is not placed at the bottom I wonder if using the min-height approach is the best to sort the minimal sorting state. I think the min-height approach is fair when the content size is predictable but here there are some cases where the content length can vary. @kostajh did you use this approach with good results in other places?

We did something similar for suggested edits when it was client-side only, but that is much more predictable in its size.

I think vertical bumps are not critical on desktop for this particular module since the Suggested edits module is already giving more height to the homepage area. In mobile vertical bumps can be annoying, maybe we could just set a fixed height ( max bound ) instead of min-height in the overlay summary which is the most sensitive view to vertical bumps.

As long as there is some kind of placeholder there, that is close enough to the final size, that is good enough for me (I am not a designer!). The dramatic "nothing -> full module render" should be avoided, IMO.

Note aside, my perception is that the most relevant thing to cover in an initial loading state is the time while Javascript is loading. Having an empty box, even if with a some height doesn't seem to indicate something is gonna load there. The screenshot above shows what user on a slow connection may get with the current status:

I would suggest adding any kind of loading animation (css only) that can give the user some expectation something is gonna show in the box.

Yes, I agree with that. I believe we are waiting on something like T300538: Design, agree, and provide a general loading indicator for large-scale UX components in Codex / T311874: [New component] Skeleton: Add Skeleton loader component to Codex in a CSS-only release of Codex.

In T323572#8529942, @Etonkovidova wrote:

The minimal height is in place.
When checking in betalabs, the grey background was not present, e.g.

The issue with loading state will be addressed in Codex components (see the comment above).

In T323572#8530458, @RHo wrote:

Hi @Sgs - can we add in a Base80 leaving background colour in this minimal loading state before resolving? My concern is that this oils believe without some indicator, and we have no form timeframe for when Codex will be implemented.

I think both of these are addressed by the latest two patches just +2'ed in T321675: NewImpact: Create skeleton loading state. Could we close this and track any follow-ups in T321675 or a new task?

In T323572#8537987, @kostajh wrote:

In T323572#8529942, @Etonkovidova wrote:

The minimal height is in place.
When checking in betalabs, the grey background was not present, e.g.

The issue with loading state will be addressed in Codex components (see the comment above).

In T323572#8530458, @RHo wrote:

Hi @Sgs - can we add in a Base80 leaving background colour in this minimal loading state before resolving? My concern is that this oils believe without some indicator, and we have no form timeframe for when Codex will be implemented.

I think both of these are addressed by the latest two patches just +2'ed in T321675: NewImpact: Create skeleton loading state. Could we close this and track any follow-ups in T321675 or a new task?

I checked T321675: NewImpact: Create skeleton loading state - the loading state for Impact module is betalabs, scheduled for wmf.20 (the next deployment):
The simplified version per the comment this @RHo comment's is in place:

In T323572#8538810, @Etonkovidova wrote:

In T323572#8537987, @kostajh wrote:

In T323572#8529942, @Etonkovidova wrote:

The minimal height is in place.
When checking in betalabs, the grey background was not present, e.g.

The issue with loading state will be addressed in Codex components (see the comment above).

In T323572#8530458, @RHo wrote:

Hi @Sgs - can we add in a Base80 leaving background colour in this minimal loading state before resolving? My concern is that this oils believe without some indicator, and we have no form timeframe for when Codex will be implemented.

I think both of these are addressed by the latest two patches just +2'ed in T321675: NewImpact: Create skeleton loading state. Could we close this and track any follow-ups in T321675 or a new task?

I checked T321675: NewImpact: Create skeleton loading state - the loading state for Impact module is betalabs, scheduled for wmf.20 (the next deployment):
The simplified version per the comment this @RHo comment's is in place:

@RHo - anything else needs to be done on this task?

Looks good to me, thank you!