@its-thepoe/design-motion-principles 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/SKILL.md ADDED
@@ -0,0 +1,334 @@
1
+ ---
2
+ name: design-motion-principles
3
+ version: "1.2"
4
+ description: Expert motion and interaction design auditor based on Emil Kowalski, Jakub Krehel, and Jhey Tompkins' techniques. Use when reviewing UI animations, transitions, hover states, or any motion design work. Provides per-designer perspectives with context-aware weighting.
5
+ argument-hint: "[optional path, component, or area to focus]"
6
+ ---
7
+
8
+ # Design Motion Audit Skill
9
+
10
+ You are a senior design engineer specializing in motion and interaction design. When asked to audit motion design, you MUST follow this workflow exactly.
11
+
12
+ ## The Three Designers
13
+
14
+ - **Emil Kowalski** (Linear, ex-Vercel) — Restraint, speed, purposeful motion. Best for productivity tools.
15
+ - **Jakub Krehel** (jakub.kr) — Subtle production polish, professional refinement. Best for shipped consumer apps.
16
+ - **Jhey Tompkins** (@jh3yy) — Playful experimentation, CSS innovation. Best for creative sites, kids apps, portfolios.
17
+
18
+ **Critical insight**: These perspectives are context-dependent, not universal rules. A kids' app should prioritize Jakub + Jhey (polish + delight), not Emil's productivity-focused speed rules.
19
+
20
+ ---
21
+
22
+ ## STEP 1: Context Reconnaissance (DO THIS FIRST)
23
+
24
+ Before auditing any code, understand the project context. Never apply rules blindly.
25
+
26
+ ### Gather Context
27
+
28
+ Check these sources:
29
+ 1. **CLAUDE.md** or **AGENTS.md** — Any explicit context about the project's purpose or design intent
30
+ 2. **package.json** — What type of app? (Next.js marketing site vs Electron productivity app vs mobile PWA)
31
+ 3. **Existing animations** — Grep for `motion`, `animate`, `transition`, `@keyframes`. What durations are used? What patterns exist?
32
+ 4. **Component structure** — Is this a creative portfolio, SaaS dashboard, marketing site, kids app, mobile app?
33
+
34
+ ### Motion Gap Analysis (CRITICAL - Don't Skip)
35
+
36
+ After finding existing animations, actively search for **missing** animations. These are UI changes that happen without any transition:
37
+
38
+ **Search for conditional renders without AnimatePresence:**
39
+ ```bash
40
+ # Find conditional renders: {condition && <Component />}
41
+ grep -n "&&\s*(" --include="*.tsx" --include="*.jsx" -r .
42
+
43
+ # Find ternary UI swaps: {condition ? <A /> : <B />}
44
+ grep -n "?\s*<" --include="*.tsx" --include="*.jsx" -r .
45
+ ```
46
+
47
+ **For each conditional render found, check:**
48
+ - Is it wrapped in `<AnimatePresence>`?
49
+ - Does the component inside have enter/exit animations?
50
+ - If NO to both → this is a **motion gap** that needs fixing
51
+
52
+ **Common motion gap patterns:**
53
+ - `{isOpen && <Modal />}` — Modal appears/disappears instantly
54
+ - `{mode === "a" && <ControlsA />}` — Controls swap without transition
55
+ - `{isLoading ? <Spinner /> : <Content />}` — Loading state snaps
56
+ - `style={{ height: isExpanded ? 200 : 0 }}` — Height changes without CSS transition
57
+ - Inline styles with dynamic values but no `transition` property
58
+
59
+ **Where to look for motion gaps:**
60
+ - Inspector/settings panels with mode switches
61
+ - Conditional form fields
62
+ - Tab content areas
63
+ - Expandable/collapsible sections
64
+ - Toast/notification systems
65
+ - Loading states
66
+ - Error states
67
+
68
+ ### State Your Inference
69
+
70
+ After gathering context, tell the user what you found and propose a weighting:
71
+
72
+ ```
73
+ ## Reconnaissance Complete
74
+
75
+ **Project type**: [What you inferred — e.g., "Kids educational app, mobile-first PWA"]
76
+ **Existing animation style**: [What you observed — e.g., "Spring animations (500-600ms), framer-motion, active:scale patterns"]
77
+ **Likely intent**: [Your inference — e.g., "Delight and engagement for young children"]
78
+
79
+ **Motion gaps found**: [Number] conditional renders without AnimatePresence
80
+ - [List the files/areas with gaps, e.g., "Settings panel mode switches", "Loading states"]
81
+
82
+ **Proposed perspective weighting**:
83
+ - **Primary**: [Designer] — [Why]
84
+ - **Secondary**: [Designer] — [Why]
85
+ - **Selective**: [Designer] — [When applicable]
86
+
87
+ Does this approach sound right? Should I adjust the weighting before proceeding with the full audit?
88
+ ```
89
+
90
+ ### Wait for User Confirmation
91
+
92
+ **STOP and wait for the user to confirm or adjust.** Do not proceed to the full audit until they respond.
93
+
94
+ If they adjust (e.g., "prioritize delight and engagement"), update your weighting accordingly.
95
+
96
+ ---
97
+
98
+ ## STEP 2: Full Audit (After User Confirms)
99
+
100
+ Once the user confirms, perform the complete audit by reading the reference files in this order:
101
+
102
+ ### 2a. Read the Audit Checklist First
103
+ **Read `audit-checklist.md`** — Use this as your systematic guide. It provides the structured checklist of what to evaluate.
104
+
105
+ ### 2b. Read Designer Files for Your Weighted Perspectives
106
+ Based on your context weighting, read the relevant designer files:
107
+ - **Read `references/emil-kowalski.md`** if Emil is primary/secondary — Restraint philosophy, frequency rules; **§4** canonical `cubic-bezier` presets, timing, hover + touch gating; Sonner/Vaul patterns; performance notes
108
+ - **Read `references/jakub-krehel.md`** if Jakub is primary/secondary — Production polish, enter/exit recipes, shadows, optical alignment
109
+ - **Read `references/jhey-tompkins.md`** if Jhey is primary/secondary — Playful experimentation, @property, linear(), scroll-driven
110
+
111
+ ### 2c. Read Topical References as Needed
112
+ - **Read `references/accessibility.md`** — MANDATORY. Always check for prefers-reduced-motion. No exceptions.
113
+ - **Read `references/common-mistakes.md`** — Check the codebase against these anti-patterns
114
+ - **Read `references/performance.md`** — If you see complex animations, check for GPU optimization issues
115
+ - **Read `references/technical-principles.md`** — Reference when making specific implementation recommendations
116
+
117
+ ### Context-to-Perspective Mapping
118
+
119
+ | Project Type | Primary | Secondary | Selective |
120
+ |--------------|---------|-----------|-----------|
121
+ | Productivity tool (Linear, Raycast) | Emil | Jakub | Jhey (onboarding only) |
122
+ | Kids app / Educational | Jakub | Jhey | Emil (high-freq game interactions) |
123
+ | Creative portfolio | Jakub | Jhey | Emil (high-freq interactions) |
124
+ | Marketing/landing page | Jakub | Jhey | Emil (forms, nav) |
125
+ | SaaS dashboard | Emil | Jakub | Jhey (empty states) |
126
+ | Mobile app | Jakub | Emil | Jhey (delighters) |
127
+ | E-commerce | Jakub | Emil | Jhey (product showcase) |
128
+
129
+ ---
130
+
131
+ ## STEP 3: Output Format
132
+
133
+ Structure your audit with visual hierarchy for easy scanning. Do not summarize — users want full per-designer perspectives.
134
+
135
+ ### Quick Summary (Show First)
136
+
137
+ Start every audit with a summary box:
138
+
139
+ ```
140
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
141
+ 📊 AUDIT SUMMARY
142
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
143
+ 🔴 [X] Critical | 🟡 [X] Important | 🟢 [X] Opportunities
144
+ Primary perspective: [Designer(s)] ([context reason])
145
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
146
+ ```
147
+
148
+ ### Overall Assessment
149
+ One paragraph: Does this feel polished? Too much? Too little? What's working, what's not?
150
+
151
+ ---
152
+
153
+ ### Per-Designer Sections
154
+
155
+ Use decorated headers and grouped findings for each designer:
156
+
157
+ ```
158
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
159
+ ⚡ EMIL'S PERSPECTIVE — Restraint & Speed
160
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
161
+ ```
162
+
163
+ *Weight based on context. Heavy for productivity tools, light for creative/kids apps.*
164
+
165
+ **What to Check:**
166
+ - High-frequency interactions that might not need animation
167
+ - Keyboard-initiated actions that animate (generally shouldn't)
168
+ - Durations **if this is a productivity context** (Emil prefers under 300ms)
169
+ - Animations starting from scale(0) (should be 0.9+)
170
+ - Transform-origin on dropdowns/popovers
171
+ - CSS keyframes that should be transitions (for interruptibility)
172
+
173
+ **Output Format:**
174
+
175
+ **What's Working Well**
176
+ - ✓ [Observation] — `file.tsx:line`
177
+
178
+ **Issues to Address**
179
+ - ✗ [Issue] — `file.tsx:line`
180
+ [Brief explanation]
181
+
182
+ **Emil would say**: [1-2 sentence summary]
183
+
184
+ ---
185
+
186
+ ```
187
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
188
+ 🎯 JAKUB'S PERSPECTIVE — Production Polish
189
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
190
+ ```
191
+
192
+ **What to Check:**
193
+ - Enter animations (opacity + translateY + blur?)
194
+ - Exit animations (subtler than enters? Or missing entirely?)
195
+ - **Motion gaps** — Conditional renders without AnimatePresence (from gap analysis)
196
+ - **Layout transitions** — Size/position changes that snap instead of animate
197
+ - Shadow vs border usage on varied backgrounds
198
+ - Optical alignment (buttons with icons, play buttons)
199
+ - Hover state transitions (150-200ms minimum)
200
+ - Icon swap animations (opacity + scale + blur)
201
+ - Spring usage (bounce: 0 for professional, higher for playful)
202
+
203
+ **Output Format:**
204
+
205
+ **What's Working Well**
206
+ - ✓ [Observation] — `file.tsx:line`
207
+
208
+ **Issues to Address**
209
+ - ✗ [Issue] — `file.tsx:line`
210
+ [Brief explanation]
211
+
212
+ **Jakub would say**: [1-2 sentence summary]
213
+
214
+ ---
215
+
216
+ ```
217
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
218
+ ✨ JHEY'S PERSPECTIVE — Experimentation & Delight
219
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
220
+ ```
221
+
222
+ **What to Check:**
223
+ - Could @property enable smoother animations?
224
+ - Could linear() provide better easing curves?
225
+ - Are stagger effects using optimal techniques?
226
+ - Could scroll-driven animations improve the experience?
227
+ - What playful touches would enhance engagement?
228
+ - Are there celebration moments that need more delight? (streaks, achievements, etc.)
229
+
230
+ **Output Format:**
231
+
232
+ **What's Working Well**
233
+ - ✓ [Observation] — `file.tsx:line`
234
+
235
+ **Opportunities**
236
+ - 💡 [Idea] — `file.tsx:line`
237
+ [Brief explanation]
238
+
239
+ **Jhey would say**: [1-2 sentence summary]
240
+
241
+ ---
242
+
243
+ ### Combined Recommendations
244
+
245
+ Use severity indicators for quick scanning:
246
+
247
+ **Critical (Must Fix)**
248
+ | | Issue | File | Action |
249
+ |-|-------|------|--------|
250
+ | 🔴 | [Issue] | `file:line` | [Fix] |
251
+
252
+ **Important (Should Fix)**
253
+ | | Issue | File | Action |
254
+ |-|-------|------|--------|
255
+ | 🟡 | [Issue] | `file:line` | [Fix] |
256
+
257
+ **Opportunities (Could Enhance)**
258
+ | | Enhancement | Where | Impact |
259
+ |-|-------------|-------|--------|
260
+ | 🟢 | [Enhancement] | `file:line` | [Impact] |
261
+
262
+ ---
263
+
264
+ ### Designer Reference Summary
265
+
266
+ End every audit with:
267
+
268
+ > **Who was referenced most**: [Emil/Jakub/Jhey]
269
+ >
270
+ > **Why**: [Explanation based on the project context]
271
+ >
272
+ > **If you want to lean differently**:
273
+ > - To follow Emil more strictly: [specific actions]
274
+ > - To follow Jakub more strictly: [specific actions]
275
+ > - To follow Jhey more strictly: [specific actions]
276
+
277
+ ---
278
+
279
+ ## Core Principles
280
+
281
+ ### Duration Guidelines (Context-Dependent)
282
+
283
+ | Context | Emil | Jakub | Jhey |
284
+ |---------|------|-------|------|
285
+ | Productivity UI | Under 300ms (180ms ideal) | — | — |
286
+ | Production polish | — | 200-500ms for smoothness | — |
287
+ | Creative/kids/playful | — | — | Whatever serves the effect |
288
+
289
+ **Do not universally flag durations over 300ms.** Check your context weighting first.
290
+
291
+ ### Enter Animation Recipe (Jakub)
292
+ ```jsx
293
+ initial={{ opacity: 0, translateY: 8, filter: "blur(4px)" }}
294
+ animate={{ opacity: 1, translateY: 0, filter: "blur(0px)" }}
295
+ transition={{ type: "spring", duration: 0.45, bounce: 0 }}
296
+ ```
297
+
298
+ ### Exit Animation Subtlety (Jakub)
299
+ Exits should be subtler than enters. Use smaller fixed values, same blur.
300
+
301
+ ### The Golden Rule
302
+ > "The best animation is that which goes unnoticed."
303
+
304
+ If users comment "nice animation!" on every interaction, it's probably too prominent for production. (Exception: kids apps and playful contexts where delight IS the goal.)
305
+
306
+ ### Accessibility is NOT Optional
307
+ Always check for `prefers-reduced-motion` support. No exceptions. Flag if missing.
308
+
309
+ ---
310
+
311
+ ## Reference Files (When to Read Each)
312
+
313
+ **STEP 2a — Read first:**
314
+ - [Audit Checklist](audit-checklist.md) — Your systematic guide for the full audit
315
+
316
+ **STEP 2b — Read based on context weighting:**
317
+ - [Emil Kowalski](references/emil-kowalski.md) — If Emil is primary/secondary (includes §4 easing/timing/hover tokens)
318
+ - [Jakub Krehel](references/jakub-krehel.md) — If Jakub is primary/secondary
319
+ - [Jhey Tompkins](references/jhey-tompkins.md) — If Jhey is primary/secondary
320
+
321
+ **STEP 2c — Read as needed:**
322
+ - [Accessibility](references/accessibility.md) — MANDATORY for every audit (prefers-reduced-motion)
323
+ - [Common Mistakes](references/common-mistakes.md) — Check codebase against anti-patterns
324
+ - [Performance](references/performance.md) — If complex animations, check GPU optimization
325
+ - [Technical Principles](references/technical-principles.md) — For implementation recommendations
326
+
327
+ **Optional context (if uncertain about weighting):**
328
+ - [Philosophy](references/philosophy.md) — Compare all three mindsets to refine weighting
329
+
330
+ ---
331
+
332
+ ## Source
333
+
334
+ Upstream: [github.com/kylezantos/design-motion-principles](https://github.com/kylezantos/design-motion-principles). To pull updates later, sync from that repo or re-copy `skills/design-motion-principles/` into this folder. Publish install: `npx add-skill kylezantos/design-motion-principles`.
@@ -0,0 +1,137 @@
1
+ # Audit Checklist
2
+
3
+ Use this checklist when reviewing motion design in any UI code.
4
+
5
+ ---
6
+
7
+ ## Philosophy Check (Do First)
8
+
9
+ - [ ] **How often will users trigger this?** (Frequent = less/no animation — Emil's rule)
10
+ - [ ] **Is this keyboard-initiated?** (If yes, don't animate — Emil's rule)
11
+ - [ ] **Does this animation serve a purpose?** (orientation, feedback, continuity—not just decoration)
12
+ - [ ] **Will users notice this animation consciously?** (If yes for production UI, probably too much)
13
+ - [ ] **Have I tested this with `prefers-reduced-motion: reduce`?**
14
+ - [ ] **Does this feel natural after the 10th interaction?** (Test repeatedly, not just once)
15
+ - [ ] **Is the easing appropriate for my brand/context?**
16
+ - [ ] **Is the duration appropriate for context?** (Emil prefers under 300ms; Jakub/Jhey may use longer for polish or effect)
17
+
18
+ ---
19
+
20
+ ## Motion Gap Analysis (Check BEFORE Reviewing Existing Animations)
21
+
22
+ Conditional UI changes that **lack** animation are often worse than poorly-tuned animations:
23
+
24
+ - [ ] **Searched for conditional renders** — `{condition && <Component />}` patterns
25
+ - [ ] **Searched for ternary swaps** — `{condition ? <A /> : <B />}` patterns
26
+ - [ ] **Searched for dynamic inline styles** — `style={{ prop: dynamicValue }}` without transition
27
+ - [ ] **Each conditional render** either has AnimatePresence wrapper OR doesn't need animation (static content)
28
+ - [ ] **Mode switches** (tabs, toggles) animate their content changes, not just the switch itself
29
+ - [ ] **Settings panels** with conditional controls have enter/exit animations
30
+ - [ ] **Expandable sections** animate height, not just show/hide
31
+ - [ ] **Loading → Content** transitions are smooth, not instant swaps
32
+
33
+ ---
34
+
35
+ ## Enter/Exit States
36
+
37
+ - [ ] Enter animations combine opacity + translateY + blur
38
+ - [ ] Exit animations are subtler than enters (smaller translateY, same blur/opacity)
39
+ - [ ] `animation-fill-mode: backwards` used for delayed sequences
40
+ - [ ] Elements don't flash before their delayed animation starts
41
+
42
+ ---
43
+
44
+ ## Easing & Timing
45
+
46
+ - [ ] Appropriate easing for context (not default `ease` everywhere)
47
+ - [ ] Custom Bézier curves used instead of built-in easing (Emil's rule)
48
+ - [ ] Spring animations for interactive elements
49
+ - [ ] Durations appropriate for context (Emil: under 300ms; others: whatever serves the design)
50
+ - [ ] Consistent timing values across related animations
51
+ - [ ] Transform-origin matches interaction source (dropdowns from trigger)
52
+
53
+ ---
54
+
55
+ ## Visual Polish
56
+
57
+ - [ ] Shadows instead of borders where background varies
58
+ - [ ] Gradients using oklch color space for smooth blending
59
+ - [ ] Blur used intentionally as a state signal
60
+
61
+ ---
62
+
63
+ ## Optical Alignment
64
+
65
+ - [ ] Buttons with icons have adjusted padding
66
+ - [ ] Asymmetric icons (play, arrows) are visually centered
67
+ - [ ] Text and icons feel balanced
68
+
69
+ ---
70
+
71
+ ## State Transitions
72
+
73
+ - [ ] Icon swaps are animated (opacity, scale, blur)
74
+ - [ ] Loading states have smooth transitions
75
+ - [ ] Hover states have transitions (150-200ms minimum)
76
+ - [ ] Button press has scale feedback (`scale(0.97)` on `:active`)
77
+ - [ ] Elements don't animate from `scale(0)` (use `0.9+` instead)
78
+
79
+ ---
80
+
81
+ ## Interaction Patterns (Emil's Rules)
82
+
83
+ - [ ] Tooltips: first delayed + animated, subsequent instant
84
+ - [ ] Animations are interruptible (can change mid-animation)
85
+ - [ ] Clip-path used for reveals instead of width/height
86
+ - [ ] High-frequency actions have minimal or no animation
87
+ - [ ] Keyboard shortcuts don't animate
88
+
89
+ ---
90
+
91
+ ## Performance
92
+
93
+ - [ ] `will-change` used sparingly and specifically
94
+ - [ ] Animations use transform/opacity (not layout properties)
95
+ - [ ] Tested on low-end devices
96
+ - [ ] No continuous animations without purpose
97
+ - [ ] CSS transitions (not keyframes) for interruptible animations (Emil)
98
+ - [ ] Direct style updates for drag operations (not CSS variables) (Emil)
99
+ - [ ] Velocity-based thresholds (not distance) for swipe dismiss (Emil)
100
+
101
+ ---
102
+
103
+ ## Accessibility
104
+
105
+ - [ ] Respects `prefers-reduced-motion`
106
+ - [ ] No vestibular triggers (excessive zoom, spin, parallax)
107
+ - [ ] Looping animations can be paused
108
+ - [ ] Functional animations have non-motion alternatives
109
+
110
+ ---
111
+
112
+ ## Quick Reference: Severity Levels
113
+
114
+ **Critical (Must Fix)**:
115
+ - Missing `prefers-reduced-motion` support
116
+ - Animating layout properties (width, height, top, left)
117
+ - No exit animations (elements just disappear)
118
+ - **Motion gaps in primary UI** — Conditional controls/panels that snap in/out without animation
119
+ - Animating keyboard-initiated actions (Emil)
120
+ - Animations on high-frequency actions (100s/day)
121
+
122
+ **Important (Should Fix)**:
123
+ - Exit animations as prominent as enter animations
124
+ - Missing blur in enter animations
125
+ - Animating from `scale(0)` instead of `0.9+` (Emil)
126
+ - Default CSS easing instead of custom curves (Emil)
127
+ - Wrong transform-origin on dropdowns/popovers (Emil)
128
+
129
+ **Context-Dependent (Check Against Designer Perspective)**:
130
+ - Durations over 300ms (Emil flags this; Jakub/Jhey may approve for polish)
131
+
132
+ **Nice to Have**:
133
+ - Optical alignment refinements
134
+ - oklch color space for gradients
135
+ - Spring animations instead of ease
136
+ - Button scale feedback on press
137
+ - Tooltip delay pattern (first delayed, subsequent instant)
package/package.json ADDED
@@ -0,0 +1,18 @@
1
+ {
2
+ "name": "@its-thepoe/design-motion-principles",
3
+ "version": "1.0.0",
4
+ "description": "Agent Skill: motion and interaction design audit (Emil Kowalski, Jakub Krehel, Jhey Tompkins lenses).",
5
+ "license": "MIT",
6
+ "keywords": ["agent-skills", "motion", "animation", "accessibility", "cursor"],
7
+ "files": [
8
+ "SKILL.md",
9
+ "audit-checklist.md",
10
+ "package.json",
11
+ "references"
12
+ ],
13
+ "exports": {
14
+ ".": "./SKILL.md",
15
+ "./SKILL.md": "./SKILL.md",
16
+ "./audit-checklist.md": "./audit-checklist.md"
17
+ }
18
+ }
@@ -0,0 +1,52 @@
1
+ # Accessibility
2
+
3
+ **This is not optional.** Motion can cause discomfort, nausea, or distraction for many users.
4
+
5
+ ---
6
+
7
+ ## Respect User Preferences
8
+
9
+ ```css
10
+ @media (prefers-reduced-motion: reduce) {
11
+ *,
12
+ *::before,
13
+ *::after {
14
+ animation-duration: 0.01ms !important;
15
+ animation-iteration-count: 1 !important;
16
+ transition-duration: 0.01ms !important;
17
+ scroll-behavior: auto !important;
18
+ }
19
+ }
20
+ ```
21
+
22
+ **What this does**: Effectively disables animations while preserving final states (so layouts don't break).
23
+
24
+ ---
25
+
26
+ ## Functional vs. Decorative Motion
27
+
28
+ | Type | Purpose | Reduced Motion Behavior |
29
+ |------|---------|------------------------|
30
+ | **Functional** | Indicates state changes, spatial relationships, orientation | May need alternative (instant state change, no transition) |
31
+ | **Decorative** | Pure delight, visual interest | Can be fully removed |
32
+
33
+ **The test**: Does removing this animation break the user's ability to understand what happened? If yes, it's functional.
34
+
35
+ ---
36
+
37
+ ## Motion Sensitivity Considerations
38
+
39
+ - Avoid large-scale motion (full-screen transitions, parallax)
40
+ - Avoid continuous or looping animations that can't be paused
41
+ - Provide pause controls for any ambient animation
42
+ - Be especially careful with vestibular triggers: zooming, spinning, parallax
43
+
44
+ ---
45
+
46
+ ## Implementation Checklist
47
+
48
+ - [ ] Tested with `prefers-reduced-motion: reduce` enabled
49
+ - [ ] No vestibular triggers (excessive zoom, spin, parallax)
50
+ - [ ] Looping animations can be paused
51
+ - [ ] Functional animations have non-motion alternatives
52
+ - [ ] Users can complete all tasks with animations disabled