Skeleton Loading Design Paradigm
This paradigm is introduced with https://gitlab.com/gitlab-org/gitlab-ce/issues/29666#note_36569171
This is a new design paradigm imo and should therefore need some set of rules to which all skeleton loading elements should comply to. To what degree will we show elements/placeholders? atoms, organisms? .. or in this case, just the cards? I think simplicity is key here to keep this maintainable.
If we look how facebook does it, they keep a nice ratio between details and whitespace, representing organisms:
Therefore I could see rules like the following work out for this:
- Skeleton should represent organism in a recognisable way
- Atoms may be represented in max 3 repetitions, if applicable
- Skeletons should adhere as much as possible to final UI CSS (think of shadows, borders, visual hierarchy)
- Skeletons should however only be presented in grayscale with internal atom representations following HEX colors:
#f9f9f9
or#ffffff
I think we need to document this at the same time as doing issue https://gitlab.com/gitlab-org/gitlab-ce/issues/29666
Proposal
- Skeleton should represent organism in a recognisable way
- Atoms may be represented in max 3 repetitions, if applicable
- Skeletons should adhere as much as possible to final UI CSS (think of shadows, borders, visual hierarchy)
- Skeletons should however only be presented in grayscale with internal atom representations following HEX colors:
#fafafa
or#ffffff
- Animate the grey atoms to show motion, as if "loading". So it's growing, not just static, similar to fb. It should pulse transition colors horizontally from left to right, with
#f2f2f2
to#fafafa
. - Pulse animation should have
X
navigation curve and timing - example: loading
Edited by Dimitrie Hoekstra