Page MenuHomePhabricator

Define and add guidelines for adding skeleton/placeholder UI to the DSG
Closed, DuplicatePublic

Assigned To
None
Authored By
RHo
Apr 21 2021, 7:36 PM
Referenced Files
F35685981: image.png
Nov 2 2022, 1:17 PM
File Not Attached
F34409746: image.png
Apr 21 2021, 7:36 PM
F34409748: image.png
Apr 21 2021, 7:36 PM
F34409740: image.png
Apr 21 2021, 7:36 PM

Description

Define and add guidelines for 'skeleton' or placeholder UI to the DSG, potentially as a part of the progress indicator task T266028

Acceptance criteria

  • Collect current implementations across products
  • Define general rules on appearance and interactivity
  • Add to DSG

Some examples in use right now:

  • Growth newcomer homepage:
  • Image thumbnails on articles
    image.png (1×2 px, 897 KB)
  • Image thumbnails on search (Minerva)
    image.png (2×1 px, 456 KB)

Event Timeline

@Prtksxna has shared in recent design review on IP Info Tool similar plan for using a skeleton loading state.

On a personal note, I have never understood the advantages of animated skeleton loading state, besides possibly helping preventing layout reflows. Find it really distracting, specifically on text-heavy information pages, where one could start reading while loading, both on mobile and low-bandwidth environments.

On a personal note, I have never understood the advantages of animated skeleton loading state, besides possibly helping preventing layout reflows. Find it really distracting, specifically on text-heavy information pages, where one could start reading while loading, both on mobile and low-bandwidth environments.

Ahh I kind of like them! Besides the value in helping prevent reflow, imo it also offers a stronger signal to have some animation that more content is coming than a static grey box and something is happening rather than it being 'stalled' or blank. In the case of @Prtksxna's example where there is a skeleton on each field, not having the animation may lead some users to think it's the styling for a blank text-field. But agree that it should not be too ostentatious but a subtle shimmer.

helping preventing layout reflows. Find it really distracting…

Agree with both these. Being able to read stuff that is already loaded in the UI without having to worry about its position shifting is great. And yep, the attention does go to the animation before the content, something to be careful about.

In the case of @Prtksxna's example where there is a skeleton on each field, not having the animation may lead some users to think it's the styling for a blank text-field. But agree that it should not be too ostentatious but a subtle shimmer.

Agreed, it can look like a disabled field. This was the reference we had made for the shimmer, it works but I guess could be more subtle?
https://codepen.io/prtksxna/pen/OJLmVXZ

NOTE: The loading state of that UI might need to change because of some technical considerations.

On a personal note, I have never understood the advantages of animated skeleton loading state, besides possibly helping preventing layout reflows. Find it really distracting, specifically on text-heavy information pages, where one could start reading while loading, both on mobile and low-bandwidth environments.

Note though that three of the four listed use cases aren't text-heavy. IMO it would make sense to have different loading indicators for content pages (where there isn't much loading happening anyway; see also T120032: Make image thumbnails interlaced whenever possible about a different approach) and for other kinds of UIs.