gliff.ai AUDIT – a user-friendly browser interface for exploring a fully documented audit trail of dataset development from the gliff.ai platform for machine learning regulation
There is certain areas of our platform which users have to wait while content is loaded. We currently use spinners however these do not feedback to the user about what is going on (reason for loading, loading progress, or what content is being loaded). Users need to be more engaged with the loading process.
Solution
Skeleton Screens are a common UX feature used in other platforms like LinkedIn, Youtube etc. These screens give the user feedback on what content is loading (used on for front-end loading, not back-end e.g. image upload) where rough grey shapes are replaced by the loaded data (text or images). These do not offer a reason for loading or the loading progress but do inform the user what is being loaded.
The Skeleton Screens for AUDIT handle text on a white background.
Text is generally represented by a box, in this case use a thin, rectangle with rounded edges which uses the colours #F2F2F2 (light grey, background colour of platform) and #D8D8D8 (grey) for the animation. Ideally, the skeleton screens should demonstrate the actually amount of content but has no interaction functionality (ie. clicking to open).
AUDIT: Overview
during loading >
after loading >
AUDIT: Details
during loading >
after loading >
Considered Alternatives
I considered both the pulsate and wave skeleton screen animations. They are both widely used and have a very similar perception to loading speed. Visually, pulsate is less distracting?
As skeleton screens do not offer a reason for loading or loading progress, this could be introduced via a snackbar message after a certain amount of time has lapsed. This is all dependent on loading context.
Additional Context (delete if not applicable)
MaterialUI supports skeleton screens, check out their documentation. To support some of my reading around UX and skeleton screens, we want a slower motion for the skeleton screen animation. The MaterialUI documentation doesn't seem to cover speed, but this stackoverflow thread does.
Problem
There is certain areas of our platform which users have to wait while content is loaded. We currently use
spinners
however these do not feedback to the user about what is going on (reason for loading, loading progress, or what content is being loaded). Users need to be more engaged with the loading process.Solution
Skeleton Screens
are a common UX feature used in other platforms like LinkedIn, Youtube etc. These screens give the user feedback on what content is loading (used on for front-end loading, not back-end e.g. image upload) where rough grey shapes are replaced by the loaded data (text or images). These do not offer a reason for loading or the loading progress but do inform the user what is being loaded.The
Skeleton Screens
for AUDIT handle text on a white background. Text is generally represented by a box, in this case use a thin, rectangle with rounded edges which uses the colours#F2F2F2
(light grey, background colour of platform) and#D8D8D8
(grey) for the animation. Ideally, theskeleton screens
should demonstrate the actually amount of content but has no interaction functionality (ie. clicking to open).AUDIT: Overview
during loading >
after loading >
AUDIT: Details
during loading >
after loading >
Considered Alternatives
I considered both the
pulsate
andwave
skeleton screen animations. They are both widely used and have a very similar perception to loading speed. Visually,pulsate
is less distracting?As
skeleton screens
do not offer a reason for loading or loading progress, this could be introduced via asnackbar message
after a certain amount of time has lapsed. This is all dependent on loading context.Additional Context (delete if not applicable)
MaterialUI supports skeleton screens, check out their documentation. To support some of my reading around UX and skeleton screens, we want a slower motion for the skeleton screen animation. The MaterialUI documentation doesn't seem to cover speed, but this stackoverflow thread does.