| • alexhollender_WMF | |
| Jan 27 2022, 3:09 PM |
| F34933029: image.png | |
| Jan 27 2022, 3:09 PM |
| F34933027: image.png | |
| Jan 27 2022, 3:09 PM |
| F34931891: Screen Shot 2022-01-26 at 1.33.47 PM.png | |
| Jan 27 2022, 3:09 PM |
With T223844 we're now reserving space for related articles before they've loaded. A side-effect of this is that before they load the page appears to have a sort of random gap:
Introduce some kind of loading indicator that communicates to people that something will soon be appearing in that space, for example:
| loading | loaded |
|---|---|
 |  |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T284951 [EPIC] Simplify the RelatedArticles extension | |||
| Resolved | ovasileva | T223844 Reserve space for the "Related articles" container | |||
| Stalled | None | T300258 Add loading indicator for related articles | |||
| Open | None | T310633 Card: Add loading (Skeleton) state | |||
| Open | None | T311874 Skeleton: Add Skeleton loader component to Codex |
cc @bmartinezcalvo @Volker_E @KieranMcCann another example of a needed loading indicator
Note in an ideal world (based on server side rendering being available in Codex ) our hope is to server-side render RelatedArticles in which case there would be no API call and no loading state.
@alexhollender_WMF +1 with using the skeleton state to communicate to the user that something is going to happen. I think skeletons are the best way to communicate it when the content in the page is not already loaded, in this way the user waits for something to happen and doesn't leave the page.
I totally agree with adding this skeleton state. My only concern is if we could do it for technical reasons, since the other day talking about a similar use case Volker commented me that skeletons weren't technically available, right @Volker_E ?
If technical reasons let us do it, I will go with skeleton states.