Skeleton loading screens are with us for a while. You can read about core concepts and benefits of them in a lot of places. I’m not going to convince you why they are better than traditional loading spinner, but rather than I’m examining the most popular sites.
Let’s find out how those skeletons fit rendered content after loading.
The most recognizable on Facebook is loading new posts on the main wall.
The top part of circle image, title, and date are permanently part of the post so skeleton of them is a good choice - every facebook user recognizes this iconic part of the portal. Next 3 lines indicate that there will be some text, this is not always true, the post can contain video/picture/etc. so there can be some mismatch. If we overlay skeleton on a post with text content we will get surprising perfect fit.
Certainly, gray lines (red in a comparison) are the size of x-height of
the font. This is a good choice
since solid rectangle block of this height appear as the same “weight”
as final text. If solid rectangles will be the size of font body height
or cap height they will appear way thicker than final text even they
better cover text size.
Folks at facebook did a great job there.
LinkedIn skeleton contains the same parts as Facebook has, but the gray parts seem bigger.
It looks like the skeleton is not trying to mimic perfectly rendered final layout. Aesthetics and clarity of standalone skeleton are more important than “fit factor” in a LinkedIn example. But the cost of this is some kind of FOUC - you can fill mismatch:
In Jira example is hard to predict what will rendered version look like since this card can be highly modifiable. But at the first glance only by looking on a skeleton you can see that there will be: some icon next to id (Lorem-1000), title, probably text content, comment with the picture, some kind of aside widgets. It’s quite a lot only by looking at the gray rectangles. Reusing id in this card is a great idea, it can be displayed before loading data (since it is probably used to load this data) and you can check if you open proper card before any data arrive.
When we overlay skeleton on the rendered version you can see a good alignment of text and position of title and first widget in aside. Rest of elements as we suspect are not adjusted. It’s funny that icons are represented on the skeleton by squares and on the final version they are circles.
Slack uses some kind of hybrid version of skeleton loading screen and preloader. Skeleton is used for UI, but posts are represented by traditional preloader, this prevents overload of gray rectangles and keeps nice minimalism. Also, it’s worth mention that they are not exactly “gray rectangles”, the roundness of corners is related with branding style (look for example on slack logo) and can be introduced to the user quickly.
Vertical rhythms of first 2 lines are preserved in the skeleton. Icons are represented by gray bars. Couldn’t icons be used from the beginning? They could, but they will be probably inactive and also make a look of skeleton more patchy. Gray bars preserves color thone of final font color - it breaks the monotony (like in the Jira example). The vertical rhythm of channels and friends is smaller than actual rendered content, a skeleton is using only one vertical spacing in groups - all this to make skeleton cleaner.
All presented examples have one in common: they strongly use minimalistic art principles. It’s funny how we can in a couple of simple rectangles reflect the promise of future content.