Vad är ett rörelsesystem? En praktisk guide för UI-team
Ett rörelsesystem är de delade regler, tokens och komponenter som bestämmer hur en produkt rör sig. Vad hör hemma i en, hur man hanterar den och var ExodeUI passar.
Core Takeaway
Ett rörelsesystem är den delade uppsättningen regler, tokens, komponenter och kod som bestämmer hur en produkt rör sig. Det täcker varaktigheter, lättnader, fjädrar, koreografi och interaktionstillstånd så att team återanvänder godkänd rörelse istället för att bygga om den skärm för skärm. Ett rörelsesystem är ett ledningsproblem lika mycket som ett designproblem: det behöver en ägare, en källa till sanning och en väg till produktion.
Vad är ett rörelsesystem?
Ett rörelsesystem är den del av ett designsystem som beskriver rörelse. Det svarar på frågor som ett statiskt komponentbibliotek inte kan: hur snabbt en meny öppnas, hur en knapp reagerar när den trycks ned, vad händer när en användare avbryter en övergång och vilka fjädervärden som hör till vilken yta. Utdata är inte en stilguidesida. Resultatet är en liten uppsättning återanvändbara beslut som designers och utvecklare kan tillämpa utan att uppfinna en ny animation varje gång.
Vad hör hemma i ett rörelsesystem
Ett användbart rörelsesystem har fem delar. Hoppa över en och systemet blir en mapp med filer som ingen använder.
Principles
Korta regler som förklarar produktens personlighet. Till exempel: rörelse bekräftar inmatning på den första bilden, eller stora ytor rör sig mindre än små.
Polletter
Namngivna värden för varaktighet, easing och fjädrar, som motion.enter.fast eller motion.spring.snappy. Tokens gör rörelse granskningsbar och håller värdena konsekventa.
Mönster
Återanvändbara beteenden för vanliga jobb: gå in, avsluta, expandera, ordna om, dra, avvisa, lyckas och fel.
Komponenter
De levande byggstenarna som redan använder mönstren, så ett team kan släppa in en istället för att läsa ett dokument och bygga om det.
Styrning
Vem kan ändra systemet, hur ändringar granskas och hur utfasad rörelse tas bort.
Rörelsesystem vs designsystem vs rörelsetokens
Ett designsystem omfattar färg, typ, avstånd, komponenter och användningsregler. Ett rörelsesystem är rörelseskiktet inuti det, och det har ofta sin egen ägare eftersom rörelsen förändras av andra anledningar än vad färgen gör. Rörelsetokens är den minsta enheten i det lagret: namngivna värden för timing och fysik. Ett tokenbibliotek är nödvändigt men inte tillräckligt. Utan mönster och levande komponenter blir tokens en lista med siffror som designers tolkar olika på varje skärm.
Varför rörelsesystem misslyckas
De flesta rörelsesystem misslyckas av operativa skäl, inte estetiska. Polletterna bor i ett dokument som är bortkopplat från komponenterna. Den godkända motionen finns bara i en prototyp som utvecklare inte kan köra. Ett team antar systemet och ett annat fortsätter att skicka hårdkodade varaktigheter. Systemet har ingen ägare, så det driver. Att fixa det innebär att placera systemet någonstans, arbetet sker redan: i designfilen, i komponentbiblioteket och i kodgranskning.
Hur man hanterar ett rörelsesystem
Börja med en liten, ägd yta och gör systemet till den enkla vägen.
- Välj en sanningskälla för tokens och länka till den från designfilen och kodbasen
- Namnge tokens efter avsikt, inte efter värde: motion.exit.fast är mer användbart än motion.200ms
- Skicka en liten uppsättning mönster innan du lägger till fler polletter
- Granska rörelseändringar som kodändringar, med en före-och-efter-inspelning
- Spåra återanvändning: hur många nya komponenter använder godkända mönster istället för anpassad timing
- Ta bort gamla värden enligt ett schema så att systemet inte ackumulerar dubbletter
Där ExodeUI passar
ExodeUI håller rörelse i en öppen .exode-fil snarare än i en separat specifikation. Layout, tillstånd, tidslinjer, fjäderfysik, logik och ingångar lever tillsammans, och runtime-paket spelar upp filen i React, Vue, Svelte, Angular, Solid, React Native, SwiftUI och Flutter. Det ger ett rörelsesystem en fungerande referens: en designer kan öppna den godkända komponenten, en utvecklare kan inspektera samma fil och ett AI-kodningsverktyg kan redigera den via MCP-servern. Filen är inte en ersättning för styrning. Det ger bara styrningen något konkret att peka på.
Hur man startar ett rörelsesystem i en sprint
Granska tio av dina mest använda komponenter och lista varje varaktighet, kurva och fjäder i dem. Gruppera de värden som gör samma jobb och namnge grupperna. Välj fem mönster som täcker de flesta interaktioner. Bygg en referenskomponent per mönster, dokumentera när den ska användas och lägg till tokens i dina design- och kodbibliotek. Kör sedan en enskild funktion genom det nya systemet och mät hur många anpassade värden som fortfarande behövs. Den siffran är din baslinje för nästa sprint.
Produktionsimplementeringsutdrag
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()}
/>
);
}Nyckel Principles att komma ihåg
- Ett rörelsesystem är rörelseskiktet i ett designsystem, inte en mapp med prototypvideor
- Det behöver principer, tokens, mönster, levande komponenter och styrning
- Tokens utan användningsregler blir siffror som varje lag tolkar olika
- Rörelseändringar bör granskas som kodändringar
- ExodeUI håller rörelse, tillstånd och logik i en öppen fil som körtider kan spela