@RHo do we already have a design or component for this? If not, could you please create one?

Moving to Ready for dev – but also pinging @Sgs in anticipation of discussion about what is actually feasible to have on load vs my assumptions in this initial design :)

In T321675#8358303, @RHo wrote:

Moving to Ready for dev – but also pinging @Sgs in anticipation of discussion about what is actually feasible to have on load vs my assumptions in this initial design :)

Thanks for this design!

There are two stages of loading:

1. The first stage of loading is on the server-side, where we output the markup for the module. If you disable JavaScript in your browser, you'll see how that looks:

What we probably want here instead is a box that is sized for some expected height (which is impossible to say precisely, because it can vary by languages, and by number of articles). The contents for it could be a spinner or it could be the bars used in the skeleton design for this task, but we can't easily render the different cards/components on the server-side, without duplicating a lot of work.

2. Once the JavaScript loads, there is then some period of time between the JS loading and the HTTP request to fetch the user impact data from the API. In "normal" scenarios where the data is already cached for the user, and with good network conditions, this should happen in let's say < 200ms. In this case, we can make use of the skeleton bars as provided in the design, until the data is loaded and rendered in the application.

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?

In T321675#8405696, @kostajh wrote:

In T321675#8358303, @RHo wrote:

Moving to Ready for dev – but also pinging @Sgs in anticipation of discussion about what is actually feasible to have on load vs my assumptions in this initial design :)

Thanks for this design!

There are two stages of loading:

1. The first stage of loading is on the server-side, where we output the markup for the module. If you disable JavaScript in your browser, you'll see how that looks:

What we probably want here instead is a box that is sized for some expected height (which is impossible to say precisely, because it can vary by languages, and by number of articles). The contents for it could be a spinner or it could be the bars used in the skeleton design for this task, but we can't easily render the different cards/components on the server-side, without duplicating a lot of work.

2. Once the JavaScript loads, there is then some period of time between the JS loading and the HTTP request to fetch the user impact data from the API. In "normal" scenarios where the data is already cached for the user, and with good network conditions, this should happen in let's say < 200ms. In this case, we can make use of the skeleton bars as provided in the design, until the data is loaded and rendered in the application.

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.

The prior impact module was rendered on the server whereas the new one is rendered on the client. That means users will have to wait for Javascript to load on their browsers before seeing any meaningful content ( until Codex has SSR support T321356). The proposed design it seems it assumes we can display Vue components (the scorecards) in the server which is sadly not the case. On the other side if we implement this issue 100% in the client it would only cover for the data fetching waiting time (orange), leaving all the user in front of an empty box (screenshot 1) while JS loads.

If we don't want to get in the business of generating HTML in the server again my suggestion is that we create a CSS-only loader with some animation to cover the Javascript loading time. Also the concerns about content height mentioned in T323572#8484270 are somehow related since the possible vertical bumps happen when the user moves from the Javascript loading step to the data fetching.

In T321675#8484424, @Sgs wrote:

The prior impact module was rendered on the server whereas the new one is rendered on the client. That means users will have to wait for Javascript to load on their browsers before seeing any meaningful content ( until Codex has SSR support T321356). The proposed design it seems it assumes we can display Vue components (the scorecards) in the server which is sadly not the case. On the other side if we implement this issue 100% in the client it would only cover for the data fetching waiting time (orange), leaving all the user in front of an empty box (screenshot 1) while JS loads.

If we don't want to get in the business of generating HTML in the server again my suggestion is that we create a CSS-only loader with some animation to cover the Javascript loading time. Also the concerns about content height mentioned in T323572#8484270 are somehow related since the possible vertical bumps happen when the user moves from the Javascript loading step to the data fetching.

👍

In T321675#8484424, @Sgs wrote:

The prior impact module was rendered on the server whereas the new one is rendered on the client. That means users will have to wait for Javascript to load on their browsers before seeing any meaningful content ( until Codex has SSR support T321356). The proposed design it seems it assumes we can display Vue components (the scorecards) in the server which is sadly not the case. On the other side if we implement this issue 100% in the client it would only cover for the data fetching waiting time (orange), leaving all the user in front of an empty box (screenshot 1) while JS loads.

If we don't want to get in the business of generating HTML in the server again my suggestion is that we create a CSS-only loader with some animation to cover the Javascript loading time. Also the concerns about content height mentioned in T323572#8484270 are somehow related since the possible vertical bumps happen when the user moves from the Javascript loading step to the data fetching.

hi @Sgs - in the proposed design, I was had assumed in the scorecard section the background could be easily replicated and icons loaded up from CSS (since the same icons are on OOUI which I assume is already separately loaded). Same goes for text being shown in there already (like it is in the Suggested edits module when loading).
However, if this is not so easy to achieve, can the following simplified version be done instead:

Change 879629 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] User impact: add skeleton markup while javascript loads

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

Change 881406 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] User impact: show skeleton while an api request is ongoing

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

Change 879629 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] User impact: add skeleton markup while JavaScript loads

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

Change 881406 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] User impact: show skeleton while an api request is ongoing

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

Based on https://phabricator.wikimedia.org/T321675#8504932 - the simplified version for the Impact module skeleton was checked on betalabs; no issues were found. See the animated gif below: