- Home
- Skills
- Raphaelsalaja
- Userinterface Wiki
- To Spring Or Not To Spring
to-spring-or-not-to-spring_skill
- TypeScript
253
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 raphaelsalaja/userinterface-wiki --skill to-spring-or-not-to-spring- SKILL.md7.3 KB
Overview
This skill audits animation code to ensure the correct timing function is used for each interaction. It flags cases where springs, easing, linear timing, or no animation would be more appropriate and reports findings in file:line format. Use it to improve perceived responsiveness and preserve interaction intent.
How this skill works
The tool scans specified TypeScript and CSS files (or patterns you provide) and checks each animation against a decision framework: user-driven motions, system-driven changes, time representations, and high-frequency interactions. It applies rule categories (spring, easing, duration, none) and emits file:line findings with rule IDs and concise descriptions. It also produces a summary table of rule counts and severity for quick triage.
When to use it
- Review motion implementations during code review
- Debug animations that feel wrong (too bouncy, sluggish, or mechanical)
- Decide between spring vs easing for a new interaction
- Check durations and timing functions for accessibility and UX consistency
- Audit keyboard, typing, and high-frequency interactions for unnecessary animation
Best practices
- Use springs for gestures and any interruptible motion to preserve velocity and natural feel
- Use easing curves for system-initiated state changes; prefer ease-out for entrances and ease-in for exits
- Use linear timing only where time maps directly to progress (progress bars, loaders)
- Avoid animation for high-frequency or keyboard-driven interactions — instant feedback feels faster
- Keep user-initiated animations under 300ms and follow recommended ranges (press/hover 120–180ms, small state 180–260ms)
Example use cases
- Find drag handlers using easing transitions and recommend spring transitions with balanced stiffness/damping
- Detect toast or modal entrances using springs and suggest ease-out with a short duration
- Locate progress bar transitions that are non-linear and recommend linear timing for honesty of time representation
- Flag animations triggered on every keystroke or keyboard navigation and recommend removing them or using instant states
- Identify long user-initiated durations (>300ms) and suggest shortening before changing curves
FAQ
Findings are emitted as file:line - [rule-id] description, plus a summary table listing rule counts and severity.
How does it decide between spring and easing?
It asks whether the motion is user-driven (gestures, interruptible) or system-driven (state changes, announcements). User-driven → spring; system-driven → easing; progress → linear; high-frequency → none.