Loading skeleton

Problem Context

• Content loads asynchronously and has a predictable final shape such as cards, rows, profile blocks, charts, or media tiles.
• A blank screen or centered spinner would not show where content will appear or would allow avoidable layout shift.
• The system can distinguish loading from loaded, empty, failed, and timed-out states.

Selection Rules

• Choose skeletons when the final content layout is known enough to reserve stable space.
• Use skeletons for dynamic content regions rather than standalone buttons, inputs, or controls.
• Keep skeletons neutral and abstract so they do not look like real text, fake data, or tappable controls.
• Mark the loading region busy or provide a concise status so assistive technology does not treat placeholders as content.
• Transition to loaded content, empty state, error state, or cancelled state on a bounded timeline.
• Respect reduced-motion preferences when using shimmer or pulse animation.
• Use progress bars, inline loading, or explicit job status instead when progress is measurable or the task blocks action.

Required States

• Initial skeleton placeholder state with region marked busy.
• Loaded state where real content replaces placeholders without layout jump.
• Resolved empty state after successful loading returns no content.
• Failure or timeout state after loading cannot complete.
• Reduced-motion state for animated skeletons.
• Refresh or partial-loading state where existing content remains trustworthy while only new areas are busy.

Interaction Contract

• Skeleton placeholders are not focusable, clickable, selectable, or announced as real content.
• The placeholder geometry approximates the loaded content closely enough to reduce layout shift.
• The loading region communicates pending status without announcing every placeholder row.
• Loading cannot continue indefinitely without switching to error, timeout, or support messaging.
• Existing user focus remains stable while new content loads unless focus movement is required after completion.
• When loaded content arrives, busy state is removed and real controls become available.

Implementation Checklist

• Reserve stable dimensions for every skeleton region.
• Match skeleton row, card, media, and text proportions to the final content density.
• Avoid fake readable text and fake interactive controls.
• Use aria-busy or equivalent status for the affected region.
• Remove busy state when content, empty, or error state resolves.
• Add timeout or failure handling so skeletons do not run forever.
• Honor prefers-reduced-motion when animating shimmer or pulse.
• Do not combine skeletons with competing spinners unless each indicator applies to a clearly different region.

Common Generated-UI Mistakes

• Showing skeletons forever.
• Using skeletons for unknown layout shapes.
• Making placeholders look like tappable content.
• Showing skeleton after a no-results or empty response is already known.
• Leaving shimmer animation on for reduced-motion users.
• Loading into a layout that has little relationship to the placeholder.

Critique Questions

• Does this placeholder communicate pending structure without pretending content exists?
• What exact state replaces the skeleton if loading succeeds, returns empty, fails, or times out?
• Can keyboard and screen reader users avoid interacting with placeholder-only content?