Animation Duration
UI motion (hover, focus, expand, collapse, page transition) MUST resolve in 100–300ms. Below 100ms the motion reads as a glitch; above 300ms it feels sluggish; above 500ms users perceive the UI as broken. Cap is 500ms.
$ aoe install @community/rule-animation-durationProjection
Always in _index.xml · the agent never has to ask for this.
AnimationDuration [rule] v1.0.0
UI motion (hover, focus, expand, collapse, page transition) MUST resolve in 100–300ms. Below 100ms the motion reads as a glitch; above 300ms it feels sluggish; above 500ms users perceive the UI as broken. Cap is 500ms.
Loaded when retrieval picks the atom as adjacent / supporting.
AnimationDuration [rule] v1.0.0
UI motion (hover, focus, expand, collapse, page transition) MUST resolve in 100–300ms. Below 100ms the motion reads as a glitch; above 300ms it feels sluggish; above 500ms users perceive the UI as broken. Cap is 500ms.
Checks
- @community/check-animation-duration
Applies To
@community/type-html-artifact
Meta
- License: Apache-2.0
- License Provenance: package-authorship-claim
Severity
medium
Severity Combination
animation > 500ms → BLOCK
animation 300–500ms → WARN
animation 100–300ms → PASS
animation < 100ms → WARN (likely missed by user)
Failure Mode
Slow motion makes the UI feel broken or laggy; users click again, double-fire, or abandon. Fast motion (<100ms) is invisible — the cognitive 'where did the menu go?' moment cancels the value of the animation.
Remediation
- Standardize on tokens:
--motion-fast: 150ms,--motion-base: 200ms,--motion-slow: 300ms— consume them in CSS and JS. - Reserve 400–500ms only for full-page route transitions; never for hover / focus.
- If your animation truly needs > 500ms (e.g. a hero reveal), break it into stages with the user able to interact during.
- Pair with @community/rule-reduced-motion-required to handle accessibility.
Exceptions
- Case: Decorative ambient animation
- Allowed When: A background gradient or hero loop runs continuously and is not tied to interaction; duration is not perceived as 'response time'.
- Case: Loading skeleton
- Allowed When: A pulse / shimmer cycles every 1500ms — this is feedback, not response.
Loaded when retrieval picks the atom as a focal / direct hit.
AnimationDuration [rule] v1.0.0
UI motion (hover, focus, expand, collapse, page transition) MUST resolve in 100–300ms. Below 100ms the motion reads as a glitch; above 300ms it feels sluggish; above 500ms users perceive the UI as broken. Cap is 500ms.
Checks
- @community/check-animation-duration
Applies To
@community/type-html-artifact
Meta
- License: Apache-2.0
- License Provenance: package-authorship-claim
Severity
medium
Severity Combination
animation > 500ms → BLOCK
animation 300–500ms → WARN
animation 100–300ms → PASS
animation < 100ms → WARN (likely missed by user)
Failure Mode
Slow motion makes the UI feel broken or laggy; users click again, double-fire, or abandon. Fast motion (<100ms) is invisible — the cognitive 'where did the menu go?' moment cancels the value of the animation.
Remediation
- Standardize on tokens:
--motion-fast: 150ms,--motion-base: 200ms,--motion-slow: 300ms— consume them in CSS and JS. - Reserve 400–500ms only for full-page route transitions; never for hover / focus.
- If your animation truly needs > 500ms (e.g. a hero reveal), break it into stages with the user able to interact during.
- Pair with @community/rule-reduced-motion-required to handle accessibility.
Exceptions
- Case: Decorative ambient animation
- Allowed When: A background gradient or hero loop runs continuously and is not tied to interaction; duration is not perceived as 'response time'.
- Case: Loading skeleton
- Allowed When: A pulse / shimmer cycles every 1500ms — this is feedback, not response.
Relations
related: [@community/rule-reduced-motion-required, @community/anti-pattern-decorative-spinning, @community/anti-pattern-no-bounce-everything, @community/example-linear-card-hover, @community/example-framer-page-transition, @community/rule-hover-focus-animation-parity] see-also: [@community/check-animation-duration]
Applies To
@community/type-html-artifact
Meta
- License: Apache-2.0
- License Provenance: package-authorship-claim
Severity
medium
Validates With
Severity Combination
animation > 500ms → BLOCK
animation 300–500ms → WARN
animation 100–300ms → PASS
animation < 100ms → WARN (likely missed by user)
Failure Mode
Slow motion makes the UI feel broken or laggy; users click again, double-fire, or abandon. Fast motion (<100ms) is invisible — the cognitive 'where did the menu go?' moment cancels the value of the animation.
Remediation
- Standardize on tokens:
--motion-fast: 150ms,--motion-base: 200ms,--motion-slow: 300ms— consume them in CSS and JS. - Reserve 400–500ms only for full-page route transitions; never for hover / focus.
- If your animation truly needs > 500ms (e.g. a hero reveal), break it into stages with the user able to interact during.
- Pair with @community/rule-reduced-motion-required to handle accessibility.
Exceptions
- Case: Decorative ambient animation
- Allowed When: A background gradient or hero loop runs continuously and is not tied to interaction; duration is not perceived as 'response time'.
- Case: Loading skeleton
- Allowed When: A pulse / shimmer cycles every 1500ms — this is feedback, not response.
See Also
- @community/check-animation-duration
Source
aoe-engine/examples/frontend-design/primes/compiled/@community/rule-animation-duration/atom.yaml