Page MenuHomePhabricator

NewImpact: Minimal loading state
Closed, ResolvedPublic

Description

Based on T321675#8411188,

So I guess the question is if we should try to accommodate what is happening in phase 1, before the JS loads, or just do something ultra minimal like setting a minimum height on the impact module box?

My inclination is your suggested minimal approach and setting a min height based on height of the contents when using default english copy, which seems to be ~786px.

In this task, we want a minimal loading state, with a minimum height while the JS is loading.

Event Timeline

kostajh triaged this task as Medium priority.Nov 22 2022, 1:23 PM
kostajh created this task.

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:

Screenshot 2022-12-21 at 12.27.06.png (2×3 px, 409 KB)

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.

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:

Screenshot 2022-12-21 at 12.27.06.png (2×3 px, 409 KB)

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: Skeleton: Add Skeleton loader component to Codex in a CSS-only release of Codex.

Etonkovidova subscribed.

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

Screen Shot 2023-01-16 at 7.46.03 PM.png (1×830 px, 33 KB)

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

RHo reopened this task as In Progress.Jan 17 2023, 10:33 AM

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.

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

Screen Shot 2023-01-16 at 7.46.03 PM.png (1×830 px, 33 KB)

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

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?

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

Screen Shot 2023-01-16 at 7.46.03 PM.png (1×830 px, 33 KB)

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

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:

Screen Shot 2023-01-18 at 3.19.23 PM.png (1×904 px, 55 KB)

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

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

Screen Shot 2023-01-16 at 7.46.03 PM.png (1×830 px, 33 KB)

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

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:

Screen Shot 2023-01-18 at 3.19.23 PM.png (1×904 px, 55 KB)

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

Looks good to me, thank you!

Thnaks, @RHo - closing as Resolved; the simplified loading version (T321675: NewImpact: Create skeleton loading state) will be deployed in wmf.20).