Page MenuHomePhabricator

Newcomer tasks: show skeleton screen while loading
Open, Needs TriagePublic

Description

Our team will work to make the suggested edits module and cards load as quickly as possible. Because there may still be some delay, we should also have a skeleton screen to show during the millisecond of loading.

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:
  1. Pager text will show as 1 of ... suggestions whilst the total number of tasks is being fetched
  2. All elements of the article card will load as a 'skeleton' placeholder grey boxes
  3. 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)
  4. 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.

Details

Related Gerrit Patches:
mediawiki/extensions/GrowthExperiments : masterSuggested Edits: Adjust task impression log invocation
mediawiki/extensions/GrowthExperiments : masterSuggested Edits: Show skeleton animation while loading

Event Timeline

The first step here is for @RHo to design the skeleton screen.

RHo added a comment.Nov 15 2019, 3:55 PM

@MMiller_WMF - I noticed that in V1.0 at the moment when refreshing on mobile there is about a 500ms delay where the screen looks like this:

RHo updated the task description. (Show Details)Nov 15 2019, 3:56 PM
RHo moved this task from 📗Backlog (Current sprint) to 💪In Progress on the Growth Design board.

An alternative to consider is T236738.

MMiller_WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.Nov 26 2019, 1:55 AM

@RHo -- after discussing this with @Catrope and @Tgr, we have decided that we want to prioritize adding loading placeholders over trying to speed up the loading. We think we need an additional placeholder for card navigation. When the user clicks the navigation arrows quickly, what we have is the article titles, task types, and page views -- not the image or the text extract. Can you design something for that? Should it just be what you already posted to the description, but with the things filled in that we know (the article titles and task types)? Or should it be something different? Should the loading state for an image be the gray box (even if it ends up having no image)? Or should it be the placeholder "mountain" image (which may then load into a real image)?

Tgr added a comment.Nov 26 2019, 3:37 AM

We don't have the page views either (the fix to T238178: Newcomer tasks: pageview count not appearing or inconsistent was to load it per card). We might have images but it's probably better to only rely on the title + task type, we are guaranteed to always have those while other things might come and go as we try to optimize the API.

Per team meeting today, @RHo will specify how this skeleton screen will animate.

RHo updated the task description. (Show Details)Nov 29 2019, 8:56 PM
RHo removed a project: Growth Design.

@RHo has now included all the assets in the description, and so this is fully ready for development.

@RHo @MMiller_WMF this design works for displaying while the user clicks previous/next (side note: it seems instantaneous to me in production, and even when clicking quickly it doesn't seem bothersome. Is the time between next/previous a problem that we need to solve?)

But as noted in T238231#5666995 the biggest lag is when the page loads, but before the JavaScript has finished loading. For that, I think we need to take a different approach to what the design proposes.

The other modules have server-side rendered content so they appear well before the Suggested Edits module which is all client-side. On initial page load, we can't use the design here because it assumes we know the initial task title and its task type. It also requires us to render the task filters, previous next buttons, and task explanation on the server-side.

If we modified the design such that the placeholder has no title nor task type it's a little simpler because we just render a totally generic placeholder on the server-side. But we would still then need to render the filters + arrows + explanation widget on the server-side. If we updated the design to remove those from the initial page load placeholder, then that simplifies things more.

If we do want to keep task title + task type + filters + arrows + explanation widget as part of the initial page load experience, then we are 90% of the way towards {T236738: Newcomer tasks: server-side rendered version of suggested edits module} which will be a better user experience anyway.

Tgr added a comment.Dec 11 2019, 10:10 PM

IMO whether rendering happens on the server side or not does not make that much difference. The fundamental problem is that task search is slow; moving it to the server side will make the whole page load slower, which is probably worse. If we cache it or speed it up in some other way, a fast API will be almost as good from a performance POV as server-side rendering. (The task module rendering would have to wait for the ResourceLoader modules to load, and then for the API request, so there would still be a perceivable delay compared to server-side rendering, but nowhere near what we have now.)

IMO whether rendering happens on the server side or not does not make that much difference. The fundamental problem is that task search is slow; moving it to the server side will make the whole page load slower, which is probably worse. If we cache it or speed it up in some other way, a fast API will be almost as good from a performance POV as server-side rendering.

I'm not sure I agree with that, because the API can't be used until we have the JS loaded and executing, at which point it's already too late to make a difference to user perception.

When I load cs.wikipedia.org/wiki/Special:Homepage, the response HTML comes back in 407 ms. The CSS is loaded by the time we reach one second.

The request to load the homepage module JS starts at 1.72 seconds, and it takes 471 ms to come back. Then the API query for fetching tasks starts at 2.78 seconds and takes 691 ms. Let's say we somehow got that API query down to 50ms or 100ms, we would still be looking at ~1.5-2 seconds where the user is looking at the styled and interactive homepage but does not see a card in the suggested edits module.

Looking at the API query on testwiki (modified to use ggtlimit: 1), where we use local config + search, the response time is ~350-500ms. From the profile of the API request a big chunk of that time is API module overhead. The relevant search calls seem to take about ~100ms. So, if in SuggestedEdits.php we execute a query in search to load a single task and render that server-side, I think we'd be adding 100-200ms to the page load time. While that's not nothing, IMHO it will be a better user experience to have an actual task when the page is loaded and styled than to look at a placeholder for ~2 seconds.

All this said... if we accept that it's OK to cache one of the 200 items for some period of time (1 week?), which means that there might be cases where a task has already been completed (maintenance tags removed) but still shows up in the task feed, then we could do the server-side rendered version without adding any noticeable cost to the current server-side rendering time.

RHo added a comment.Dec 12 2019, 7:36 PM

@RHo @MMiller_WMF this design works for displaying while the user clicks previous/next (side note: it seems instantaneous to me in production, and even when clicking quickly it doesn't seem bothersome. Is the time between next/previous a problem that we need to solve?)

I thought this was the priority based on the subsequent comment T238231#5691846....

But as noted in T238231#5666995 the biggest lag is when the page loads, but before the JavaScript has finished loading. For that, I think we need to take a different approach to what the design proposes.

> The other modules have server-side rendered content so they appear well before the Suggested Edits module which is all client-side. On initial page load, we can't use the design here because it assumes we know the initial task title and its task type. It also requires us to render the task filters, previous next buttons, and task explanation on the server-side.

If we modified the design such that the placeholder has no title nor task type it's a little simpler because we just render a totally generic placeholder on the server-side. But we would still then need to render the filters + arrows + explanation widget on the server-side. If we updated the design to remove those from the initial page load placeholder, then that simplifies things more.

We can also do this for the initial load if we can get the skeleton to look like the following:


Skeleton with no server-side rendered elements (except background color)
CSS animated version: https://codepen.io/reets/pen/bGNeMdL

If we do want to keep task title + task type + filters + arrows + explanation widget as part of the initial page load experience, then we are 90% of the way towards {T236738: Newcomer tasks: server-side rendered version of suggested edits module} which will be a better user experience anyway.

Agree this would be my pref.

kostajh removed RHo as the assignee of this task.Dec 16 2019, 6:35 PM

Change 558550 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] (wip) Suggested Edits: Show skeleton animation while loading

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

Change 558550 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Show skeleton animation while loading

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

Tested on cs.wikipedia.beta.wmflabs.org/ (the issues that I noticed might be specific only to betalabs environment).

(1) My testing is in agreement with what @kostajh wrote in his comments

  • on production the navigation between the articles via arrows feels instantaneous
  • the biggest delay is on the initial load of the Suggested edits module when an empty card is display - the animated gif below shows that when Homepage is reload it takes about 5 sec to see the image on the article card. There is no visual indications that the loading process is still in progress.

(2) It seems that the specs have been implemented as per CSS animated skeleton screen. There are two twists (they might be betalabs-specific twists, pinging @kostajh )

  • the page views are visible for a moment in the skeleton
  • if the page text extracts are impossible to fetch, the skeleton lines are changed to a blank card. In betalabs, there are two types of cards - the cards that instantaneously will display the text extracts and those who unable to fetch the text extracts and thus they become blank after displaying the skeleton. Below is an animated gif (click to view):

The screenshot of barely visible pageview info

I have added this to be discussed in a team meeting on Jan 6.

the page views are visible for a moment in the skeleton

This is unintentional (and I thought I had checked for it to not occur), I can look at it.

if the page text extracts are impossible to fetch, the skeleton lines are changed to a blank card. In betalabs, there are two types of cards - the cards that instantaneously will display the text extracts and those who unable to fetch the text extracts and thus they become blank after displaying the skeleton. Below is an animated gif (click to view):

That is expected behavior, as far as I understood the requirements. What would you prefer to have happen if the text extracts can't be fetched? Also, in production this scenario should be encountered rarely if at all.

Change 561877 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Adjust task impression log invocation

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

Change 561877 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Suggested Edits: Adjust task impression log invocation

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

the page views are visible for a moment in the skeleton

This is unintentional (and I thought I had checked for it to not occur), I can look at it.

if the page text extracts are impossible to fetch, the skeleton lines are changed to a blank card. In betalabs, there are two types of cards - the cards that instantaneously will display the text extracts and those who unable to fetch the text extracts and thus they become blank after displaying the skeleton. Below is an animated gif (click to view):

That is expected behavior, as far as I understood the requirements. What would you prefer to have happen if the text extracts can't be fetched? Also, in production this scenario should be encountered rarely if at all.

Checked in wmf.14 testwiki - the issue with briefly displaying "undefined visits" message is still present - to reproduce it switch to Network Slow 3G":

To answer the second question - the issue of not fetching article extracts - it does not seem to me as a real issue; I didn't find any way to see it in production.

Relevant stills of the current loading behaviour:


Video from which the above frames were captured: https://youtu.be/-te4Qxj2uwk

There are still a fair few unexpected issues with how items are shown during and after loading.

  1. There should not be a grey box shown at the bottom of the loading screen at any point
  2. There should not be white background on the loading screen before the pale blue.
  3. The Suggested edits white footer section should not start higher in the screen before shifting into position at the bottom of the screen
  4. Suggested edits header text shifts slightly to the right when the the article card loads. It’s expected to be in place as soon as the text loads.
  5. Pale grey background ‘skeleton’ box for pageviews text should not be longer than the article extract text ‘skeleton’.
  6. It is not expected that the image icon that appears when there is no article image to be shown at all if there is an actual article image.

Based on the current way these issues are appearing, here is a suggestion of how to amend the order and way items load to reduce the jumpiness.

@kostajh - can we take 5-10min to review together how much of this could be adjusted?

kostajh added a comment.EditedFri, Feb 14, 2:39 PM

Based on the current way these issues are appearing, here is a suggestion of how to amend the order and way items load to reduce the jumpiness.

Could I suggest that item 1 be changed to look like item 2, but with loading placeholders for the pager (1 of 345), the task name (egg tart) and and the task type (copyedit)? Then there would be much less visual distraction as the content is loaded into place, because based on current speeds, the transition from the blank blue (in frame 1) to frame 2 is always going to take the longest. See also T238171#5871512

@kostajh - can we take 5-10min to review together how much of this could be adjusted?

Yes, let's find time on Monday!

RHo added a comment.Mon, Feb 17, 4:58 PM

Changes to this task and skeleton behaviour after discussion with @kostajh :

  1. Pager text will show as 1 of ... suggestions whilst the total number of tasks is being fetched
  2. The article title is also loaded as a 'skeleton' placeholder box along with the rest of the article card content
  3. The task type, info icon, difficulty level tag, and task type short description text will be shown after the initial skeleton card is loaded
  4. 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.
RHo added a comment.Mon, Feb 17, 4:59 PM
This comment was removed by RHo.
RHo updated the task description. (Show Details)Mon, Feb 17, 6:47 PM
kostajh removed kostajh as the assignee of this task.Tue, Feb 18, 1:00 PM

Untagging myself for now.