loading-states_skill

This skill helps you design effective loading and empty states that maintain user confidence during delays and empty data scenarios.

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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational