Skeleton loading screen

A few gray rectangles are the promise of the future content.

Published: 2017-10-11

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.

Facebook

The most recognizable on Facebook is loading new posts on the main wall.

Facebook before and after loading

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.

Facebook compare skeleton with rendered content

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

LinkedIn skeleton contains the same parts as Facebook has, but the gray parts seem bigger.

LinkedIn before and after loading

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:

LinkedIn compare skeleton with rendered content

Jira

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.

Jira before and after loading

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.

Jira compare skeleton with rendered content

Slack

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.

Slack before and after loading

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.

Slack compare skeleton with rendered content

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.