Hvad er et bevægelsessystem? En praktisk vejledning til UI-teams
Et bevægelsessystem er de delte regler, tokens og komponenter, der bestemmer, hvordan et produkt bevæger sig. Hvad hører der til i én, hvordan man administrerer det, og hvor ExodeUI passer.
Core Takeaway
Et bevægelsessystem er det fælles sæt regler, tokens, komponenter og kode, der bestemmer, hvordan et produkt bevæger sig. Det dækker varigheder, lempelser, fjedre, koreografi og interaktionstilstande, så hold genbruger godkendt bevægelse i stedet for at genopbygge den skærm for skærm. Et bevægelsessystem er lige så meget et ledelsesproblem som et designproblem: det har brug for en ejer, en kilde til sandhed og en vej til produktion.
Hvad er et bevægelsessystem?
Et bevægelsessystem er den del af et designsystem, der beskriver bevægelse. Det besvarer spørgsmål, som et statisk komponentbibliotek ikke kan: hvor hurtigt en menu åbner, hvordan en knap reagerer, når den trykkes på, hvad sker der, når en bruger afbryder en overgang, og hvilke fjederværdier hører til hvilken overflade. Outputtet er ikke en stilguideside. Outputtet er et lille sæt genanvendelige beslutninger, som designere og udviklere kan anvende uden at opfinde en ny animation hver gang.
Hvad hører hjemme i et bevægelsessystem
Et nyttigt bevægelsessystem har fem dele. Spring en over, og systemet bliver en mappe med filer, som ingen bruger.
Principles
Korte regler, der forklarer produktets personlighed. For eksempel: bevægelse bekræfter input på det første billede, eller store overflader bevæger sig mindre end små.
Poletter
Navngivne værdier for varighed, lempelse og fjedre, såsom motion.enter.fast eller motion.spring.snappy. Tokens gør, at bevægelse kan gennemgås og holder værdierne konsistente.
Mønstre
Genanvendelig adfærd til almindelige job: indtast, afslut, udvid, omarranger, træk, afvis, succes og fejl.
Komponenter
De levende byggeklodser, der allerede bruger mønstrene, så et team kan droppe en i stedet for at læse et dokument og genopbygge det.
Governance
Hvem kan ændre systemet, hvordan ændringer gennemgås, og hvordan forældet bevægelse trækkes tilbage.
Bevægelsessystem vs designsystem vs bevægelsestokens
Et designsystem dækker over farve, type, afstand, komponenter og brugsregler. Et bevægelsessystem er bevægelseslaget inde i det, og det har ofte sin egen ejer, fordi bevægelse ændrer sig af andre årsager, end farve gør. Bevægelsestokens er den mindste enhed i dette lag: navngivne værdier for timing og fysik. Et token-bibliotek er nødvendigt, men ikke tilstrækkeligt. Uden mønstre og levende komponenter bliver tokens en liste over tal, som designere fortolker forskelligt på hver skærm.
Hvorfor bevægelsessystemer fejler
De fleste bevægelsessystemer fejler af operationelle årsager, ikke af æstetiske. Tokenerne lever i et dokument, der er afbrudt fra komponenterne. Den godkendte bevægelse findes kun i en prototype, som udviklere ikke kan køre. Et team adopterer systemet, og et andet fortsætter med at sende hårdkodede varigheder. Systemet har ingen ejer, så det driver. At rette det betyder at placere systemet et sted, hvor arbejdet allerede sker: i designfilen, i komponentbiblioteket og i kodegennemgang.
Sådan styres et bevægelsessystem
Start med en lille, ejet overflade og gør systemet til den nemme vej.
- Vælg en kilde til sandhed for tokens og link til den fra designfilen og kodebasen
- Navngiv tokens efter hensigt, ikke efter værdi: motion.exit.fast er mere nyttigt end motion.200ms
- Send et lille sæt mønstre, før du tilføjer flere tokens
- Gennemgå bevægelsesændringer som kodeændringer med en før-og-efter-optagelse
- Spor genbrug: Hvor mange nye komponenter bruger godkendte mønstre i stedet for tilpasset timing
- Træk gamle værdier tilbage efter en tidsplan, så systemet ikke akkumulerer dubletter
Hvor ExodeUI passer
ExodeUI holder bevægelse inde i en åben .exode-fil i stedet for i en separat specifikation. Layout, tilstande, tidslinjer, fjederfysik, logik og input lever sammen, og runtime-pakker afspiller filen i React, Vue, Svelte, Angular, Solid, React Native, SwiftUI og Flutter. Det giver et bevægelsessystem en fungerende reference: en designer kan åbne den godkendte komponent, en udvikler kan inspicere den samme fil, og et AI-kodningsværktøj kan redigere den gennem MCP-serveren. Filen er ikke en erstatning for governance. Det giver bare styring noget konkret at pege på.
Sådan starter du et bevægelsessystem i én sprint
Gennemgå ti af dine mest brugte komponenter og angiv hver varighed, kurve og fjeder i dem. Gruppér de værdier, der udfører det samme arbejde, og navngiv grupperne. Vælg fem mønstre, der dækker de fleste interaktioner. Byg én referencekomponent pr. mønster, dokumenter, hvornår den skal bruges, og føj tokens til dine design- og kodebiblioteker. Kør derefter en enkelt funktion gennem det nye system og mål, hvor mange brugerdefinerede værdier, den stadig har brug for. Det tal er din baseline for næste sprint.
Snippet til produktionsimplementering
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 for at huske
- Et bevægelsessystem er bevægelseslaget i et designsystem, ikke en mappe med prototypevideoer
- Det har brug for principper, tokens, mønstre, levende komponenter og styring
- Poletter uden brugsregler bliver tal, som hvert hold fortolker forskelligt
- Bevægelsesændringer bør gennemgås ligesom kodeændringer
- ExodeUI holder bevægelse, tilstande og logik i én åben fil, som runtimes kan afspille