Page MenuHomePhabricator

[leftovers] Newcomer tasks: show skeleton of filter and article card UI elements *on load*
Closed, ResolvedPublic

Description

This task is leftover from T238231. The main part that is not implemented is that the 'skeleton' of the filter bar, number of suggestions counter, and the article card should already be inside the SE module *onload*.

Proposed design:

image.png (840×1 px, 67 KB)

https://app.zeplin.io/project/5bd0b069495b5d0a002e7eb6/screen/5dceca39ec737944ea2120d6
zpl://screen?pid=5bd0b069495b5d0a002e7eb6&sid=5dceca39ec737944ea2120d6

... with CSS animation:
https://codepen.io/reets/pen/wvBwGKE

And as animated gif

expected-skeleton-screen.mov.gif (1×848 px, 677 KB)
open full screen to see animation

Notable aspects:
  1. For both mobile and desktop, the filter and article card should not shift positions at any point.
  2. For desktop, the height of the module should not change at any point.
  3. Pager text will show as 1 of ... suggestions whilst the total number of tasks is being fetched
  4. All elements of the article card will load as a 'skeleton' placeholder grey boxes - including the article title *(this was not leftover from T238231)
  5. 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)
  6. 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.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

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

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

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

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.

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:

image.png (512×784 px, 43 KB)

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:

image.png (512×784 px, 43 KB)

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

With updated patch:

image.png (407×484 px, 18 KB)

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:

image.png (512×784 px, 43 KB)

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

With updated patch:

image.png (407×484 px, 18 KB)

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

Etonkovidova added a subscriber: Etonkovidova.

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)

article_title_displayed3.gif (945×1 px, 282 KB)

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.

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)

article_title_displayed3.gif (945×1 px, 282 KB)

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)

Tgr added a subscriber: Tgr.

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.

SE_initiation_jump1.gif (678×542 px, 156 KB)

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.