87 lines
4.7 KiB
Markdown
87 lines
4.7 KiB
Markdown
|
|
> **Additional context needed**: performance constraints.
|
|||
|
|
|
|||
|
|
Use motion to explain state, relationship, and hierarchy, or to create one authored moment the surface has earned. Decoration without purpose is animation debt.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Visitor mode
|
|||
|
|
|
|||
|
|
- **Persuade + Experience:** motion may carry the voice. Prefer one rehearsed focal sequence to repeated section reveals.
|
|||
|
|
- **Operate + Read:** motion serves feedback, state, and continuity. Keep routine transitions fast and do not make users wait through page-load choreography.
|
|||
|
|
- **Native (`ios` / `android` / `adaptive`):** follow the Motion section of [ios.md](ios.md) or [android.md](android.md), including the platform's Reduce Motion behavior. Do not apply the web tooling below.
|
|||
|
|
|
|||
|
|
## Find the job
|
|||
|
|
|
|||
|
|
Inspect the existing motion language, interaction states, target devices, and performance budget. Find only the places where motion would:
|
|||
|
|
|
|||
|
|
- acknowledge an action;
|
|||
|
|
- make a state change or spatial relationship legible;
|
|||
|
|
- preserve continuity through navigation or layout change;
|
|||
|
|
- direct attention at a meaningful moment;
|
|||
|
|
- embody the selected visual world.
|
|||
|
|
|
|||
|
|
Ask only when a material constraint cannot be inferred. Do not animate a static area merely because it exists.
|
|||
|
|
|
|||
|
|
## Set the motion thesis
|
|||
|
|
|
|||
|
|
Write a short plan before implementation:
|
|||
|
|
|
|||
|
|
- **Focal moment:** the one sequence or interaction that deserves authorship, if any.
|
|||
|
|
- **Continuity:** the state, layout, or navigation changes that need explanation.
|
|||
|
|
- **Feedback:** the controls and outcomes that need acknowledgment.
|
|||
|
|
- **Budget:** which effects may be expensive and how often they run.
|
|||
|
|
|
|||
|
|
The focal moment must come from this product and surface concept. A generic fade-and-rise, hover lift, parallax layer, or scroll reveal is not a thesis.
|
|||
|
|
|
|||
|
|
## Choose material by meaning
|
|||
|
|
|
|||
|
|
Transform and opacity are reliable foundations, not the entire palette. Choose properties for what the transition communicates:
|
|||
|
|
|
|||
|
|
- **Continuity and relationship:** shared-element motion, FLIP-style transforms, view transitions, or deliberate spatial movement.
|
|||
|
|
- **Focus and depth:** bounded blur, filter, backdrop, light, or shadow changes.
|
|||
|
|
- **Reveal and composition:** masks, clip paths, cropping, or controlled occlusion.
|
|||
|
|
- **Material and energy:** color, gradient position, texture, distortion, or shader effects when the world and runtime support them.
|
|||
|
|
- **State and feedback:** the smallest change that makes cause and result unmistakable.
|
|||
|
|
|
|||
|
|
Do not stack techniques for spectacle. One strong material idea, carried through the focal sequence and quiet supporting states, is usually enough.
|
|||
|
|
|
|||
|
|
Sibling stagger is appropriate when a list appears as a list. Cap the total delay, and never reinterpret every scrolled section as a staggered list.
|
|||
|
|
|
|||
|
|
## Timing and easing
|
|||
|
|
|
|||
|
|
Timing should express distance and consequence:
|
|||
|
|
|
|||
|
|
| Duration | Typical use |
|
|||
|
|
|---|---|
|
|||
|
|
| 100–150 ms | immediate feedback |
|
|||
|
|
| 150–300 ms | routine state change |
|
|||
|
|
| 300–500 ms | layout, overlay, or view transition |
|
|||
|
|
| 500–800 ms | a deliberately authored focal entrance |
|
|||
|
|
|
|||
|
|
Exit faster than entrance. Use natural deceleration such as `cubic-bezier(0.16, 1, 0.3, 1)` for confident arrivals; do not use bounce or elastic curves by reflex. Long feedback feels like latency.
|
|||
|
|
|
|||
|
|
## Implement to the runtime
|
|||
|
|
|
|||
|
|
- Use CSS transitions and keyframes for declarative state and bounded sequences.
|
|||
|
|
- Use Web Animations API or the project's existing motion library for interruption, sequencing, and dynamic values.
|
|||
|
|
- Use View Transitions or shared-element techniques when continuity across states is the point.
|
|||
|
|
- Use scroll-driven motion only when the scroll relationship itself carries meaning, with a robust fallback.
|
|||
|
|
- Do not add a dependency for an effect the existing stack can express cleanly.
|
|||
|
|
|
|||
|
|
Keep content visible in the default state so failed scripts do not hide the page. Avoid casually animating layout-driving properties such as `width`, `height`, `top`, `left`, and margins; use FLIP, transforms, or grid techniques when appropriate. Bound blur, filter, shadow, canvas, and shader work to isolated regions. Apply `will-change` only during known animation. Measure on target viewports and devices rather than assuming transform means fast.
|
|||
|
|
|
|||
|
|
## Accessibility and control
|
|||
|
|
|
|||
|
|
Respect autoplay and sound preferences. Any nonessential loop must stop when offscreen or hidden.
|
|||
|
|
|
|||
|
|
## Verify
|
|||
|
|
|
|||
|
|
- The focal motion is specific to the selected world and surface.
|
|||
|
|
- Every supporting animation explains feedback, state, or relationship.
|
|||
|
|
- Interruption and repeated use behave correctly.
|
|||
|
|
- Desktop, mobile, and keyboard paths remain usable.
|
|||
|
|
- Expensive effects stay smooth on the target device.
|
|||
|
|
- Removing an animation would lose meaning or authored character, not merely decoration.
|
|||
|
|
|
|||
|
|
When motion earns its place, hand off to `/impeccable polish` for the final pass.
|