Mad7droid/ux-motion

UX-Bewegung

Wenden Sie diese Regeln beim Entwerfen und Schreiben der Interaktion an. Überprüfen Sie zuerst die Bewegungs-Token des Projekts: Die Dateien AGENTS.md, CLAUDE.md, Token-Dateien und Designdokumente eines Repositorys überschreiben die unten stehenden Hauswerte.

Immer aktiver Kern

• Hausentscheidung: Funktionale UI liegt normalerweise im Bereich 120–180 ms. Projekt-Token haben Vorrang.
• Animieren Sie für räumliche Kontinuität, Zustandsänderung, Eingabe-Feedback oder um einen ruckartigen Sprung zu vermeiden.
• Bevorzugen Sie benannte transform- und opacity-Übergänge. Verwenden Sie niemals transition: all.
• Eintretende Oberflächen sollten verlangsamen; austretende Oberflächen sollten beschleunigen. Austritte können kürzer sein.
• Starten Sie skalierte Oberflächen nahe scale(0.96), niemals von scale(0).
• Halten Sie Bewegung unter prefers-reduced-motion: reduce ersetzbar; bewahren Sie Verständlichkeit und Tastaturzugriff.
• Erfassen Sie den Zeiger für Ziehbewegungen, schützen Sie sekundäre Berührungen und testen Sie Gesten auf echter Hardware.
• Bevor Sie Bewegung schreiben oder ein gemeinsames Overlay berühren, lesen Sie diese Datei vollständig. Verwenden Sie REFERENCE.md nur für Clip-Pfade, 3D, WAAPI oder tiefgehende Leistungsanalysen.

1. Entscheiden, ob es Bewegung verdient

Verwenden Sie die Häufigkeit der Exposition als Einschränkung: Ständig wiederholte Aktionen sollten sofort oder nahezu sofort sein; gelegentliche Oberflächen können räumliche Kontinuität herstellen; seltene, erklärende Momente können mehr Persönlichkeit tragen. Bewegung muss eine Änderung verdeutlichen, eine Eingabe bestätigen, die Position bewahren oder ein ruckartiges Erscheinen verhindern. Wenn sie nichts davon tut, entfernen Sie sie. Lassen Sie eine Tastenkombination nicht auf dekorative Bewegung warten.

2. Eine Dauer wählen

Der Bereich 120–180 ms ist eine Hausentscheidung: Er ist bewusst enger als Material 3's veröffentlichte short3 (150 ms), short4 (200 ms) und Standard-Übergangsbereich (250–400 ms). Er drückt eine Präferenz gegen langsame funktionale UI aus, keine veröffentlichten Barrierefreiheits- oder Plattformanforderungen.

Oberfläche	Startpunkt
Drück-Feedback	100–140 ms
Tooltip oder winziges Popover	120–160 ms
Menü oder Dropdown	140–180 ms
Modal	180 ms
Blatt	180 ms; bis zu 250 ms bei Bewegung über den größten Teil des Viewports

Verwenden Sie das kürzere Ende für Austritte. Dies sind Standardwerte, keine Überschreibungen für Produkt-Token.

3. Eine Beschleunigung wählen

Eine eintretende Oberfläche sollte mit Betonung ankommen, die sich setzt (verlangsamen); ein Austritt sollte schnell verschwinden (beschleunigen). Material 3 benennt diese Richtungen explizit:

:root {
  --ease-standard: cubic-bezier(0.2, 0, 0, 1);
  --ease-enter: cubic-bezier(0.05, 0.7, 0.1, 1); /* emphasized-decelerate */
  --ease-exit: cubic-bezier(0.3, 0, 0.8, 0.15); /* emphasized-accelerate */
}

Verwenden Sie linear nur für zeitähnlichen Fortschritt. Verwenden Sie eine ease-in-out-Kurve für einen Zustand, der durch einen bewussten Mittelpunkt reist. Vermeiden Sie es, eine Kurve nur nach Namen auszuwählen: Überprüfen Sie die gezeichnete Form und die Bewegungsrichtung.

4. Günstig rendern lassen

Bevorzugen Sie transform und opacity, die auf dem Compositor bleiben können. Benennen Sie die Eigenschaften und halten Sie Layout aus der Animation heraus. Vermeiden Sie die Animation von top, left, width, height, margin oder padding, es sei denn, die Layoutänderung ist der Punkt und die Kosten werden akzeptiert. Für intrinsische Höhe kann ein Wrapper grid-template-rows: 0fr auf 1fr übergehen, mit einem min-height: 0 inneren Wrapper, der durch overflow: hidden beschnitten wird. Dies führt immer noch Layout durch; profilieren Sie es, anstatt es als Compositor-only-Abkürzung zu behandeln. Verwenden Sie will-change spät, kurz und nur, nachdem Profiling gezeigt hat, dass es hilft; Ebenen verbrauchen Ressourcen.

5. Zustände korrekt machen

• Geben Sie drückbaren Bedienelementen sichtbares Feedback; verwenden Sie einen vorhandenen Farb-, Rahmen- oder Schattenzustand oder eine kleine scale(0.98), wenn es passt. Überschreiben Sie keine Positionierungstransformation.
• Bewahren Sie sichtbaren Fokus, Tastaturaktivierung und deaktiviertes Verhalten. Animation darf die Fokusplatzierung, die Escape-Behandlung oder semantische Zustandsaktualisierungen nicht verzögern.
• Popovers, Menüs und Tooltips wachsen von einem Anker über transform-origin; zentrierte Modals wachsen von der Mitte. Halten Sie den Ursprung stabil, während sich der Zustand ändert.
• Bevorzugen Sie Übergänge für erneut auslösbare Zustände. Verwenden Sie Keyframes für ein eigenständiges Ereignis.
• Beschränken Sie Hover-only-Funktionen auf @media (hover: hover) and (pointer: fine).
• Verwenden Sie für ein eintretendes Element @starting-style, wo unterstützt, oder einen eingehängten Zustand, der den anfänglichen Stil vor dem Übergang beobachtbar macht.

6. Reduzierte Bewegung bedeutet einen Ersatz

Die Einstellung prefers-reduced-motion deckt das Entfernen, Reduzieren oder Ersetzen von Bewegung ab; großflächiges Schwenken und Zoomen können vestibuläre Auslöser sein. Ersetzen Sie Reise und Skalierung durch Deckkraft- und Farbänderungen, wo diese den Zustand noch erklären. Halten Sie Fokus, Lade- und Sichtbarkeitsänderungen verständlich. Lassen Sie ein Element nicht einfach verschwinden, nur weil der Benutzer weniger Bewegung angefordert hat. Beachten Sie diese Präferenz sowohl in JavaScript-gesteuerten Animationen als auch in CSS, einschließlich Präferenzänderungen während die Seite geöffnet ist. Verlassen Sie sich nicht auf ein transitionend-Ereignis, um eine wesentliche Zustandsänderung abzuschließen: Der Übergang kann deaktiviert oder abgebrochen werden. Begrenzen Sie Überschreibungen auf die betroffene Komponente, anstatt global jede Animation auf eine winzige Dauer zu zwingen.

7. Gesten

Rufen Sie setPointerCapture() auf, wenn ein Ziehen beginnt: Nachfolgende Zeigerereignisse zielen dann weiterhin auf das erfassende Element bis zur Freigabe. Schließen Sie mit einer abgestimmten Geschwindigkeits- oder Entfernungsregel; es gibt keine universelle Flick-Konstante, also kalibrieren Sie sie auf dem tatsächlichen Gerät. Halten Sie die Bewegung mit Dämpfung anstelle einer harten Kante begrenzt. Ignorieren Sie zusätzliche Berührungspunkte, sobald eine Geste den Zeiger besitzt. Lassen Sie den Benutzer eine laufende Geste umkehren. Behandeln Sie pointercancel und lostpointercapture, indem Sie den Ziehstatus löschen. Wählen Sie touch-action für die Gestenachse, ohne das Seiten-Scrolling unnötig zu blockieren; stellen Sie eine Taste oder ein Tastaturäquivalent bereit.

8. Unterbrechung und Federn behandeln

Schnelles Öffnen/Schließen/Wiederöffnen sollte sich im zuletzt angeforderten Zustand einpendeln. Zielen Sie vom aktuellen visuellen Zustand aus neu, anstatt von Anfang an wiederzugeben. Brechen Sie veraltete Callbacks, Listener und Animationen bei Ersatz oder Trennung ab; ein alter Austritt darf eine neu geöffnete Oberfläche nicht entfernen. Halten Sie versteckten oder austretenden Inhalt aus der Tastaturnavigation gemäß dem Fokuslebenszyklus der Komponente heraus.

Verwenden Sie eine Feder, wenn direkte Manipulation oder Kontinuität davon profitiert, unter Beachtung der Projektbibliothek. Federparameter variieren zwischen Engines: Kopieren Sie nicht blind Steifigkeit und Dämpfungswerte. Stimmen Sie die Einschwingzeit und das Überschwingen auf der tatsächlichen Komponente ab; vermeiden Sie Hüpfen auf textlastigen Oberflächen und deaktivieren Sie Reisen bei reduzierter Bewegung.

9. Vor dem Fertigstellen überprüfen

Spielen Sie mit 4-facher Geschwindigkeit ab und prüfen Sie, ob Eigenschaften gemeinsam enden und vom richtigen Ort stammen. Schalten Sie schnell um, um Ruckeln aufzudecken. Emulieren Sie reduzierte Bewegung in DevTools. Führen Sie einen Zug über seine Kante hinaus, brechen Sie ihn ab, fügen Sie eine zweite Berührung hinzu und testen Sie auf einem physischen Gerät. Für zur Laufzeit berechnete Animationswerte konsultieren Sie REFERENCE.md. Geben Sie an, welche Prüfungen tatsächlich durchgeführt wurden und welche einen Browser oder ein physisches Gerät erfordern; Code-Review allein kann keine gefühlte Glätte feststellen.

Ausgabe überprüfen

Wenn Sie Code prüfen, melden Sie eine kompakte Tabelle, zuerst die schwerwiegendsten:

Datei:Zeile	Jetzt	Ändern zu	Warum
Menu.tsx:18	transition: all 300ms	benannte Eigenschaften und Projekt-Token	vermeidet versehentliche Layout-Animation

Melden Sie nur Befunde, die im Code sichtbar sind. Wenn der Diff sauber ist, sagen Sie dies, anstatt Befunde zu erfinden.

Kuratiert von mad7droid.