Page MenuHomePhabricator

[leftovers] Newcomer tasks: show skeleton of filter and article card UI elements *on load*
Open, Needs TriagePublic

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:


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

open full screen to see animation

Notable aspects:

#For both mobile and desktop, the filter and article card should not shift positions at any point.

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

RHo created this task.Sep 16 2020, 4:50 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 16 2020, 4:50 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
RHo updated the task description. (Show Details)Sep 16 2020, 5:24 PM

@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 added a comment.Tue, Sep 29, 11:57 AM

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

RHo added a comment.Tue, Sep 29, 12:05 PM

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