- Home
- Skills
- Sanky369
- Vibe Building Skills
- Loading States
loading-states_skill
16
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill sanky369/vibe-building-skills --skill loading-states- SKILL.md6.9 KB
Overview
This skill teaches how to design effective loading states, skeleton screens, spinners, progress bars, and empty states that preserve user confidence when content is delayed or missing. It focuses on choosing the right pattern by duration and context, accessible implementations, and practical rules to avoid common UX mistakes. Use it to make loading feel intentional, informative, and unobtrusive.
How this skill works
The skill inspects the expected content structure and operation duration to recommend an appropriate indicator: instant, subtle, skeleton, spinner, or progress bar. It provides simple CSS/HTML patterns for skeletons, spinners, progress bars, and empty/error states, plus accessibility snippets (aria-busy, reduced motion handling) and a checklist to validate implementations. It also flags cases where a skeleton or spinner is inappropriate and suggests actionable empty-state content.
When to use it
- When data or UI sections take 100ms–10s to render (skeletons for known layouts, spinners for unknown structures)
- For very short operations (100ms–1s) use subtle indicators or none
- For button or inline actions use small spinners or loading text
- For operations >10s use a progress bar with an estimated percentage or indeterminate animation
- When a user has no data, or a search/error returns nothing — provide helpful empty states and actions
Best practices
- Show a loading indicator immediately (within ~100ms) and match skeleton layout to real content
- Use skeletons for lists, cards, and predictable layouts; avoid skeletons for modals, toasts, dropdowns
- Prefer progress bars with estimates for long-running tasks and indeterminate bars when percent is unknown
- Respect motion preferences (prefers-reduced-motion) and ensure screen readers get loading announcements
- Include helpful CTAs in empty states (create, retry, clear filters) and avoid dead-end messaging
- Don’t overuse spinners for instant operations or animate aggressively
Example use cases
- E-commerce product grid: show card skeletons while images and prices load
- File uploader: show an upload progress bar with percent and cancel retry actions
- Dashboard with many widgets: display lightweight skeleton blocks per widget to reduce perceived latency
- Search page: show a "No results" empty state with suggestions and a clear filters button
- Form submit button: replace text with a small spinner while the request completes
FAQ
Use a skeleton when you know the layout of incoming content (lists, cards, tables). Use a spinner when structure is unknown or for very small components.
How long before I must show progress vs a spinner?
Show a spinner or skeleton for 1–10s. For operations over ~10s prefer a progress bar or estimated time to reduce uncertainty.
How do I make loading accessible?
Announce loading regions with aria-busy, respect prefers-reduced-motion, and avoid hiding essential content. Provide meaningful fallback text for screen readers.