@RHo could we do the first iteration of this using a div with skeleton styling for the filter buttons, both on desktop and mobile? We would then focus on:

1. article title, task type and additional info rendered on the server-side
2. correct height for the module on server-side render

Then we could follow up later with the server-side rendering of the filters.

In T263040#6501668, @kostajh wrote:

@RHo could we do the first iteration of this using a div with skeleton styling for the filter buttons, both on desktop and mobile? We would then focus on:

1. article title, task type and additional info rendered on the server-side
2. correct height for the module on server-side render

Then we could follow up later with the server-side rendering of the filters.

Sure, if that is doable as part of var C and D that would be great. I do think that the footer loading at the top and shifting position comes across as an error though, so wonder if we can fix it to the module bottom or have it appear last as part of this first iteration fix?

In T263040#6501673, @RHo wrote:

In T263040#6501668, @kostajh wrote:

@RHo could we do the first iteration of this using a div with skeleton styling for the filter buttons, both on desktop and mobile? We would then focus on:

1. article title, task type and additional info rendered on the server-side
2. correct height for the module on server-side render

Then we could follow up later with the server-side rendering of the filters.

Sure, if that is doable as part of var C and D that would be great. I do think that the footer loading at the top and shifting position comes across as an error though, so wonder if we can fix it to the module bottom or have it appear last as part of this first iteration fix?

Yeah we are basically already doing this with small task card used in mobile variant C/D, so I don't think it's a huge leap to apply the same techniques to desktop.

I do think that the footer loading at the top and shifting position comes across as an error though, so wonder if we can fix it to the module bottom or have it appear last as part of this first iteration fix?

If we do the card rendering on the server-side (per this task), then we wouldn't have to make any changes to the footer CSS, and we wouldn't have the problem with the footer shifting down (since all the components would already be placed in the right position). So, I'd favor going the extra distance to render the card on the server-side with skeleton components where needed (filters, task queue pager) and fix the footer fly-out problem in the process.

In T263040#6501681, @kostajh wrote:

I do think that the footer loading at the top and shifting position comes across as an error though, so wonder if we can fix it to the module bottom or have it appear last as part of this first iteration fix?

If we do the card rendering on the server-side (per this task), then we wouldn't have to make any changes to the footer CSS, and we wouldn't have the problem with the footer shifting down (since all the components would already be placed in the right position). So, I'd favor going the extra distance to render the card on the server-side with skeleton components where needed (filters, task queue pager) and fix the footer fly-out problem in the process.

OK cool, that sounds sensible.

Change 631987 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Homepage: Render filter buttons on server-side

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

Change 631987 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: Render filter buttons on server-side

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

Change 635818 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP]: Server-side rendered card wrapper

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

What is implemented in the patch for this task is a little bit different than what the description says, because in the meantime we've done T236738: Newcomer tasks: server-side rendered version of suggested edits module. So, we can render all components of the suggested edits module on the server-side, but we add the skeleton styling for:

• Article wikidata description
• Article image
• Pageview info

Given the above, maybe it makes sense to close this task in favor of T236738: Newcomer tasks: server-side rendered version of suggested edits module.

In T263040#6571591, @kostajh wrote:

What is implemented in the patch for this task is a little bit different than what the description says, because in the meantime we've done T236738: Newcomer tasks: server-side rendered version of suggested edits module. So, we can render all components of the suggested edits module on the server-side, but we add the skeleton styling for:

• Article wikidata description
• Article image
• Pageview info

Given the above, maybe it makes sense to close this task in favor of T236738: Newcomer tasks: server-side rendered version of suggested edits module.

Agree that the new loading is much better when testing the patchdemo from T236738#6571595 here: https://imgur.com/a/lkYAxu5, most importantly that all elements in the task module are in place so there is no jarring shifting position.
However, one minor visual note is that the page views skeleton should be amended to the same length as the article description placeholder:

In T263040#6571617, @RHo wrote:

In T263040#6571591, @kostajh wrote:

What is implemented in the patch for this task is a little bit different than what the description says, because in the meantime we've done T236738: Newcomer tasks: server-side rendered version of suggested edits module. So, we can render all components of the suggested edits module on the server-side, but we add the skeleton styling for:

• Article wikidata description
• Article image
• Pageview info

Given the above, maybe it makes sense to close this task in favor of T236738: Newcomer tasks: server-side rendered version of suggested edits module.

Agree that the new loading is much better when testing the patchdemo from T236738#6571595 here: https://imgur.com/a/lkYAxu5, most importantly that all elements in the task module are in place so there is no jarring shifting position.
However, one minor visual note is that the page views skeleton should be amended to the same length as the article description placeholder:

Ah, I think we forgot to update the width after the article card was adjusted in another task.

With updated patch:

In T263040#6571858, @kostajh wrote:

In T263040#6571617, @RHo wrote:

In T263040#6571591, @kostajh wrote:

What is implemented in the patch for this task is a little bit different than what the description says, because in the meantime we've done T236738: Newcomer tasks: server-side rendered version of suggested edits module. So, we can render all components of the suggested edits module on the server-side, but we add the skeleton styling for:

• Article wikidata description
• Article image
• Pageview info

Given the above, maybe it makes sense to close this task in favor of T236738: Newcomer tasks: server-side rendered version of suggested edits module.

Agree that the new loading is much better when testing the patchdemo from T236738#6571595 here: https://imgur.com/a/lkYAxu5, most importantly that all elements in the task module are in place so there is no jarring shifting position.
However, one minor visual note is that the page views skeleton should be amended to the same length as the article description placeholder:

Ah, I think we forgot to update the width after the article card was adjusted in another task.

With updated patch:

Great, thanks!

Change 635818 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Server-side rendered card wrapper

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

For Design review - I marked with green exclamation points the specs that I think I did not see implemented (see my notes on those specs below).
The animated gif illustrates what happens immediately after clicking the submit button on the last intro overlay.
My notes:

• rendering happens really fast
• the only actual issue - there is kind of pre-initial title load when an article title will appear (and it will be changed to another article title when the card load is completed).
• the card does shift a little bit

(click on the animated gif)

The task type, info icon, difficulty level tag, and task type short description text will be shown (fade in) after the initial skeleton article card is loaded (along with filter bar and pager text)

I guess that all that is in this comment was, in fact implemented.
i.e.

Article wikidata description
Article image
Pageview info

The suggested edits white footer section animates in (moving upwards into position) after all other content is loaded - this removes the joltiness with how this section shifts down currently when it is shown first.

As soon as a page is visible to a user - the footer ( also, the difficulty level elements) are displayed.

In T263040#6586468, @Etonkovidova wrote:

For Design review - I marked with green exclamation points the specs that I think I did not see implemented (see my notes on those specs below).
The animated gif illustrates what happens immediately after clicking the submit button on the last intro overlay.
My notes:

• rendering happens really fast
• the only actual issue - there is kind of pre-initial title load when an article title will appear (and it will be changed to another article title when the card load is completed).
• the card does shift a little bit

(click on the animated gif)

Thanks @Etonkovidova, for capturing this and I can see the slight "pre-initial" is causing the shift because the card, task pager, and task explanation skeleton is still not being shown on load. @kostajh can the space occupied by the pager, card and task explanation be incorporated into the pre-loaded state of the module so this jolt doesn't occur at all? Parts 5 and 6 of this task can also be considered ameliorated if the module can just be loaded without any shifting positions.

The task type, info icon, difficulty level tag, and task type short description text will be shown (fade in) after the initial skeleton article card is loaded (along with filter bar and pager text)

I guess that all that is in this comment was, in fact implemented.
i.e.

Article wikidata description
Article image
Pageview info

The suggested edits white footer section animates in (moving upwards into position) after all other content is loaded - this removes the joltiness with how this section shifts down currently when it is shown first.

As soon as a page is visible to a user - the footer ( also, the difficulty level elements) are displayed.

Change 637688 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested edits: Export task count from start editing dialog

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

@kostajh @Catrope -- now that there is a patch here, should this be in Code Review?

Change 637688 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested edits: Export task count from start editing dialog

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

Change 639501 had a related patch set uploaded (by Gergő Tisza; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.36.0-wmf.16] Suggested edits: Export task count from start editing dialog

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

Change 639501 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.36.0-wmf.16] Suggested edits: Export task count from start editing dialog

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

Mentioned in SAL (#wikimedia-operations) [2020-11-05T19:44:38Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.16/extensions/GrowthExperiments/modules/homepage/: 81cb1c7b141d49d7fc931fdc13ffd1b48b3a25ab: Suggested edits: Export task count from start editing dialog (T266868; T263040) (duration: 01m 07s)

The last patch fixed the early jumping of the card due to the pager not being shown. With that I think all needed work was done.

Hm, I can still see jumping if I click through the initiation dialog real quick. I think it happens when the call to update the task count in the initiation dialog finishes when the task card is already shown...

The task pager is set now on the initial load (click on the animated gif below), so the load is smooth now.

In T263040#6607349, @Tgr wrote:

Hm, I can still see jumping if I click through the initiation dialog real quick. I think it happens when the call to update the task count in the initiation dialog finishes when the task card is already shown...

I filed T267448: Fetching SE on slow connection throws Uncaught TypeError: Cannot read property 'tasktype' of undefined (seems as an extreme case to me though). I do not observe the "jumpiness" - maybe I define it differently :)

@RHo - I've updated the marking on the task - only two exclamation points (although they are green) left. Please review whether any follow-ups on this tasks are needed.

Thanks all! Now that there is no more 'jumpiness' with the skeleton in place this looks good to me.