Hva er et bevegelsessystem? En praktisk veiledning for brukergrensesnittteam
Et bevegelsessystem er de delte reglene, tokens og komponentene som bestemmer hvordan et produkt beveger seg. Hva hører hjemme i en, hvordan du administrerer den, og hvor ExodeUI passer.
Kjerne takeaway
Et bevegelsessystem er det delte settet med regler, tokens, komponenter og kode som bestemmer hvordan et produkt beveger seg. Den dekker varighet, lettelser, fjærer, koreografi og interaksjonstilstander, slik at team gjenbruker godkjent bevegelse i stedet for å gjenoppbygge den skjerm for skjerm. Et bevegelsessystem er et ledelsesproblem like mye som et designproblem: det trenger en eier, en kilde til sannhet og en vei til produksjon.
Hva er et bevegelsessystem?
Et bevegelsessystem er den delen av et designsystem som beskriver bevegelse. Den svarer på spørsmål et statisk komponentbibliotek ikke kan: hvor raskt en meny åpnes, hvordan en knapp reagerer når den trykkes, hva skjer når en bruker avbryter en overgang, og hvilke fjærverdier som tilhører hvilken overflate. Utgangen er ikke en stilguideside. Utdataene er et lite sett med gjenbrukbare beslutninger som designere og utviklere kan bruke uten å finne opp en ny animasjon hver gang.
Hva hører hjemme i et bevegelsessystem
Et nyttig bevegelsessystem har fem deler. Hopp over en og systemet blir en mappe med filer som ingen bruker.
Principles
Korte regler som forklarer produktets personlighet. For eksempel: bevegelse bekrefter input på den første rammen, eller store flater beveger seg mindre enn små.
Tokens
Navngitte verdier for varighet, lettelser og fjærer, for eksempel motion.enter.fast eller motion.spring.snappy. Tokens gjør bevegelser gjennomgåbare og holder verdiene konsistente.
Mønstre
Gjenbrukbar atferd for vanlige jobber: gå inn, avslutte, utvide, omorganisere, dra, avvise, suksess og feil.
Komponenter
De levende byggeklossene som allerede bruker mønstrene, slik at et team kan slippe en i stedet for å lese et dokument og bygge det på nytt.
Styring
Hvem kan endre systemet, hvordan endringer vurderes og hvordan avviklet bevegelse trekkes tilbake.
Motion system vs design system vs motion tokens
Et designsystem dekker farge, type, avstand, komponenter og bruksregler. Et bevegelsessystem er bevegelseslaget inne i det, og det har ofte sin egen eier fordi bevegelse endres av andre årsaker enn farge gjør. Bevegelsestokens er den minste enheten i det laget: navngitte verdier for timing og fysikk. Et token-bibliotek er nødvendig, men ikke tilstrekkelig. Uten mønstre og aktive komponenter blir tokens en liste over tall som designere tolker forskjellig på hver skjerm.
Hvorfor bevegelsessystemer mislykkes
De fleste bevegelsessystemer svikter av operasjonelle årsaker, ikke estetiske. Tokenene bor i et dokument som er koblet fra komponentene. Den godkjente bevegelsen eksisterer bare i en prototype som utviklere ikke kan kjøre. Ett team tar i bruk systemet og et annet fortsetter å sende hardkodede varigheter. Systemet har ingen eier, så det driver. Å fikse det betyr å plassere systemet et sted arbeidet allerede skjer: i designfilen, i komponentbiblioteket og i kodegjennomgang.
Hvordan administrere et bevegelsessystem
Start med en liten, eid overflate og gjør systemet til den enkle veien.
- Velg én sannhetskilde for tokens og lenk til den fra designfilen og kodebasen
- Navngi tokens etter hensikt, ikke etter verdi: motion.exit.fast er mer nyttig enn motion.200ms
- Send et lite sett med mønstre før du legger til flere tokens
- Se gjennom bevegelsesendringer som kodeendringer, med et før-og-etter-opptak
- Spor gjenbruk: hvor mange nye komponenter bruker godkjente mønstre i stedet for tilpasset timing
- Trekk tilbake gamle verdier på en tidsplan slik at systemet ikke akkumulerer duplikater
Hvor ExodeUI passer
ExodeUI holder bevegelse inne i en åpen .exode-fil i stedet for i en separat spesifikasjon. Layout, tilstander, tidslinjer, vårfysikk, logikk og innganger lever sammen, og kjøretidspakker spiller av filen i React, Vue, Svelte, Angular, Solid, React Native, SwiftUI og Flutter. Det gir et bevegelsessystem en fungerende referanse: en designer kan åpne den godkjente komponenten, en utvikler kan inspisere den samme filen, og et AI-kodingsverktøy kan redigere den gjennom MCP-serveren. Filen er ikke en erstatning for styring. Det gir bare styresett noe konkret å peke på.
Hvordan starte et bevegelsessystem i en sprint
Kontroller ti av de mest brukte komponentene dine, og skriv opp hver varighet, kurve og fjær i dem. Grupper verdiene som gjør den samme jobben og navngi gruppene. Velg fem mønstre som dekker de fleste interaksjoner. Bygg én referansekomponent per mønster, dokumenter når du skal bruke den, og legg til tokens i design- og kodebibliotekene dine. Kjør deretter en enkelt funksjon gjennom det nye systemet og mål hvor mange egendefinerte verdier den fortsatt trenger. Det tallet er din grunnlinje for neste sprint.
Snippet for produksjonsimplementering
import { ExodeUICanvas } from 'exodeui';
// The motion system lives in the .exode file. Your app supplies inputs
// and listens for events; it does not restate spring values in code.
export function SystemButton({ pressed, onConfirm }) {
return (
<ExodeUICanvas
src="/system_button.exode"
inputs={{ pressed }}
onTrigger={(name) => name === 'confirm' && onConfirm()}
/>
);
}Tast Principles å huske
- Et bevegelsessystem er bevegelseslaget til et designsystem, ikke en mappe med prototypevideoer
- Den trenger prinsipper, tokens, mønstre, levende komponenter og styring
- Tokens uten bruksregler blir tall som hvert lag tolker forskjellig
- Bevegelsesendringer bør gjennomgås som kodeendringer
- ExodeUI holder bevegelse, tilstander og logikk i én åpen fil som kjøretider kan spille av