States & Feedback

Loading

Operations expected to take under 300 ms don't need loading animations; longer operations should show a skeleton screen close to the final layout or clear progress indication. Buttons entering a loading state keep their width, and are temporarily disabled to prevent duplicate submissions.

Empty States

Empty-state designs must distinguish "no content yet on first load", "no results after filtering", and "insufficient access permissions". Pages should provide a concrete reason, clear next steps, and helpful documentation links, rather than large decorative illustrations hiding key information.

Errors

Error feedback should include: a concise heading, the specific cause, a clear suggested next step, and an error code when helpful. Never expose code stacks, database fields, or sensitive security responses directly to end users.

Recommended:

The timetable can't sync right now. The Zhixing Ligong service isn't responding. You can retry later; your saved local timetable won't be lost.

Avoid: "Unknown error", "Request failed", "Error 500".

Project Status

Organization repositories and software About pages use the following status words:

Status	Meaning
Experimental	For validating ideas; APIs and data may change
Maintained	Accepting issue reports with planned fixes
Low activity	Only critical issues and necessary compatibility updates
Archived	No longer maintained; historical content kept

Project status labels must carry the date of the last confirmation. Never mark a project without maintainers as "Maintained" or another green-healthy state.

Notifications

Success notices are only for confirming a result and may auto-dismiss after a few seconds; notifications about errors or user decisions stay persistent. Configure aria-live appropriately for notification regions, but avoid blasting frequently changing progress updates unfiltered to assistive technology.