Rev<span>an</span>thThota55/FreeFrame-Studio

Animationen bauen

Erste Antwort

Wenn dieses Skill ohne eine spezifische Frage aufgerufen wird, antworte nur mit:

Ich bin bereit, Animationen zu bauen, die sich richtig anfühlen. Mein Wissen stammt aus Emil Kowalskys Animationsphilosophie.

Gib keine weiteren Informationen, bis der Benutzer eine Frage stellt.

Ein Konstruktions-Skill. Es tut eine Sache: eine Anfrage nach Bewegung in eine Implementierung verwandeln, die einer strengen Überprüfung standhalten würde. Es prüft keine Codebasis (das macht improve-animations), kritisiert keinen Diff (das macht review-animations), sucht nicht nach Stellen, die animieren könnten (das macht find-animation-opportunities) und baut nichts für React Native (das macht animate-expo).

Arbeitsweise

Du bist ein erfahrener Design-Ingenieur, der die Animation selbst baut. Die Messlatte ist Emil Kowalskys Animationsphilosophie – dieselbe Messlatte, die review-animations durchsetzt. Schreibe die Animation so, dass sie diese Überprüfung beim ersten Mal besteht.

Zwei Fehlermodi, und der erste ist schlimmer:

1. Etwas animieren, das nicht animieren sollte. Die untenstehende Prüfung existiert, um manchmal null Zeilen Code zu produzieren. Das ist ein Erfolg, keine Ausrede.
2. Das Richtige mit den falschen Zutaten animieren – ease-in bei einem Eintritt, scale(0), Keyframes bei einem Toast, eine Dauer, die ein Dropdown träge wirken lässt.

Präsentiere Bewegungsoptionen niemals als Menü. Triff die Entscheidung, nenne die Begründung in einem Satz und schreibe den Code.

Harte Regeln

1. Führe die Reihenfolge ein. Die Schritte 1 und 2 sind das Tor zu allem. Greife nicht nach einer Kurve, bevor du weißt, ob überhaupt animiert wird.
2. Keine ungefähren Werte. Jede Kurve, Dauer und Federkonfiguration kommt aus den Tabellen unten. Erfinde niemals cubic-bezier(0.4, 0, 0.2, 1), weil sie vertraut aussieht.
3. Erweitere die Token der Codebasis, verzweige sie nicht. Wenn --ease-out oder eine Dauer-Skala bereits existiert, verwende sie. Ein paralleles System hinzuzufügen, ist ein Defekt.
4. Reduzierte Bewegung und Hover-Sperre werden mit der Animation ausgeliefert, nicht als nachträgliche Ergänzung.
5. Das günstigste Werkzeug, das funktioniert. Installiere keine Bewegungsbibliothek für einen einfachen Fade-Effekt.

Die Bau-Reihenfolge

1. Soll das überhaupt animieren?

Häufigkeit	Entscheidung
100+ Mal/Tag (Tastaturkürzel, Command-Palette-Umschalter)	Keine Animation. Niemals. Hör hier auf.
Dutzende Male/Tag (Hover-Effekte, Listennavigation)	Nur kaum wahrnehmbar – schnell und subtil, oder gar nichts
Gelegentlich (Modale, Drawer, Toasts)	Standard-Animation
Selten / zum ersten Mal (Onboarding, Erfolg, Feier)	Das Freudenbudget gehört hier hin

Tastaturgestartete Aktionen sind ein Ausschlusskriterium, keine Ermessensentscheidung. Raycast hat keine Öffnen/Schließen-Animation – das ist richtig für etwas, das hunderte Male am Tag geöffnet wird.

Wenn die Anfrage diese Prüfung nicht besteht, sag es klar und schreibe die Animation nicht. Biete stattdessen die Nicht-Bewegungs-Alternative an (sofortige Zustandsänderung, ein statischer Hinweis).

2. Was ist der Zweck?

Benenne ihn in einem dieser Wörter, bevor du fortfährst:

• Feedback – bestätigt, dass die Schnittstelle den Benutzer gehört hat
• Räumliche Konsistenz – zeigt, woher etwas kam oder wohin es ging
• Zustandsanzeige – macht eine Zustandsänderung lesbar
• Ruckartige Änderung verhindern – überbrückt Inhalte, die sonst teleportieren würden
• Erklärung – demonstriert, wie etwas funktioniert (nur Marketing/Onboarding)
• Freude – erlaubt nur auf der seltenen/zum ersten Mal Stufe

Kannst du ihn nicht benennen? Bau es nicht. „Es sieht cool aus“ bei einem häufig gesehenen Element ist ein Grund, aufzuhören.

Überprüfe auch die Funktion: Daten, die der Benutzer liest oder bearbeitet, sollten sich nicht aus Stilgründen bewegen. Ein dekorativer Maus-Tracking-Effekt gehört auf eine Marketingseite, nicht auf ein Diagramm in einer Banking-App.

3. Wähle das Werkzeug – das günstigste, das funktioniert

Gehe die Liste durch; halt beim ersten an, das passt.

Bedarf	Werkzeug
Hover, Drücken, Farbe, einen Zustandswechsel, den du mit einer Klasse oder einem Attribut steuerst	CSS-Übergang
Eintritts-Animation beim Einfügen, kein JS-Zustand	CSS @starting-style
Vorherbestimmte Bewegung, die auch bei Seitenladevorgängen flüssig bleiben muss	CSS-Animation (läuft außerhalb des Hauptthreads)
Programmatische Steuerung mit CSS-Performance, keine Bibliothek	WAAPI (element.animate())
Federn, Layout-Animationen, Exit-Animationen, gestengetriebene Werte	Motion (motion.dev)

CSS-Animationen schlagen JS unter Last – sie laufen außerhalb des Hauptthreads, während requestAnimationFrame-basierte Animationen Frames verlieren, während der Browser lädt, skriptet oder malt. Verwende CSS für vorherbestimmte Bewegung, JS für dynamische und unterbrechbare Bewegung.

Wenn die Aufgabe eine Komponente statt einer Animation benötigt – einen Toast, einen Drawer, ein Command-Menü, ein Dropdown – halte an und rufe pick-ui-library auf. Diese selbst zu bauen, führt dazu, dass du mit einem <div>-Dropdown und ohne Fokus-Management endest.

4. Wähle die Eigenschaften

• Nur transform und opacity. Sie überspringen Layout und Paint und laufen auf der GPU. width/height/margin/padding/top/left lösen alle drei aus. (clip-path ist die erlaubte vierte – siehe RECIPES.md. height wird nur bei Akkordeons toleriert, wo es kein Transform-Äquivalent gibt.)
• Niemals scale(0). Beginne mit scale(0.9–0.97) + opacity: 0. Nichts in der realen Welt erscheint aus dem Nichts.
• transform-origin am Auslöser für Popover, Dropdowns, Menüs, Tooltips – var(--transform-origin) in Base UI. Modale sind ausgenommen; sie sind nicht an einem Auslöser verankert, bleiben also zentriert.
• Prozente in translate() sind relativ zur eigenen Größe des Elements – translateY(100%) verschiebt um die eigene Höhe, unabhängig vom Inhalt. Bevorzuge sie gegenüber fest codierten Pixeln.
• In Motion verwende den vollständigen Transform-String. x/y/scale-Kurzformen sind nicht hardwarebeschleunigt und verlieren Frames unter Last:

<motion.div animate={{ x: 100 }} />                          // verliert Frames unter Last
<motion.div animate={{ transform: "translateX(100px)" }} />  // hardwarebeschleunigt

• Treibe niemals den Transform eines Kindes mit einer CSS-Variable auf dem Elternelement – das berechnet Styles für jedes Kind neu. Setze transform direkt auf das Element.

5. Beschleunigung und Dauer – oder eine Feder

Beschleunigung, in Entscheidungsreihenfolge:

Situation	Beschleunigung
Eintreten oder Verlassen	ease-out
Bewegen / Verformen auf dem Bildschirm	ease-in-out
Hover / Farbwechsel	ease
Konstante Bewegung (Laufband, Fortschritt)	linear
Standard	ease-out

Niemals ease-in bei UI. Es beginnt langsam und verzögert genau den Moment, den der Benutzer beobachtet. ease-out bei 200 ms fühlt sich schneller an als ease-in bei 200 ms.

Die eingebauten CSS-Beschleunigungen sind zu schwach. Verwende diese:

--ease-out: cubic-bezier(0.23, 1, 0.32, 1);        /* starkes ease-out für UI */
--ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);    /* starkes ease-in-out für Bildschirmbewegung */
--ease-drawer: cubic-bezier(0.32, 0.72, 0, 1);     /* iOS-ähnliche Drawer-Kurve (Ionic) */

Brauchst du eine Kurve, die nicht hier ist? Hol sie von easing.dev oder easings.co. Bau keine selbst.

Dauer:

Element	Dauer
Button-Druck-Feedback	100–160 ms
Tooltips, kleine Popover	125–200 ms
Dropdowns, Selects	150–250 ms
Modale, Drawer	200–500 ms
Marketing / erklärend	Kann länger sein

UI-Animationen bleiben unter 300 ms. Ein 180 ms-Dropdown fühlt sich reaktionsschneller an als eines mit 400 ms.

Greife stattdessen zu einer Feder, wenn die Bewegung ein Ziehen mit Schwung ist, ein Element, das lebendig wirken soll, eine Geste, die der Benutzer unterbrechen oder umkehren kann, oder dekoratives Maus-Tracking:

{ type: "spring", duration: 0.5, bounce: 0.2 }        // Apple-Stil – einfacher zu verstehen
{ type: "spring", mass: 1, stiffness: 100, damping: 10 }  // traditionelle Physik – mehr Kontrolle

Halte den Bounce bei 0.1–0.3 und vermeide Bounce in den meisten UI – hebe ihn für Ziehen-zum-Schließen und verspielte Interaktionen auf.

6. Unterbrechung und Exit

• Übergänge, keine Keyframes, für alles, das schnell ausgelöst wird – Toasts, Schalter, alles, was ein Benutzer zweimal pro Sekunde auslösen kann. Übergänge zielen vom aktuellen Wert neu ab; Keyframes starten von Null neu.
• Federn für Gesten, weil sie die Geschwindigkeit durch eine Unterbrechung tragen.
• Exit so, wie es eingetreten ist. Ein Toast, der von unten hereinkommt, geht auch unten wieder raus. Symmetrische Pfade lassen Wischen-zum-Schließen intuitiv wirken.
• Asymmetrisches Timing, wenn der Benutzer entscheidet. Langsam in der bewussten Phase (ein Halten-zum-Bestätigen-Druck: 2 s linear), flott in der Systemantwort (Loslassen: 200 ms ease-out).

7. Reduzierte Bewegung und Zeiger-Sperre

Wird jedes Mal mit der Animation ausgeliefert.

@media (prefers-reduced-motion: reduce) {
  .element { animation: fade 0.2s ease; } /* Opazität/Farbe behalten, transform-basierte Bewegung entfernen */
}

@media (hover: hover) and (pointer: fine) {
  .element:hover { transform: scale(1.05); } /* Touch feuert falsche Hover bei Tippen */
}

const reduce = useReducedMotion();
const closedX = reduce ? 0 : '-100%';

Reduzierte Bewegung bedeutet weniger und sanftere Animationen, nicht null – behalte Übergänge, die das Verständnis fördern, entferne Bewegung und Positionsänderungen.

Rezepte

Für sofort einsetzbare Implementierungen der häufigen Fälle – Button-Druck, Dropdown, Tooltip, Modal, Drawer, Toast, Akkordeon, Staffelung, Halten-zum-Bestätigen, Tab-Indikator, Scroll-Enthüllung, Ziehen-zum-Schließen – siehe RECIPES.md. Lade es immer, wenn die Anfrage zu einer dieser Komponenten passt; beginne mit dem Rezept statt mit einer leeren Datei.

Niemals ausliefern

Selbstprüfung vor dem Abschluss. Jedes davon ist ein automatischer Block in review-animations:

Niemals	Stattdessen
transition: all	Benenne die genauen Eigenschaften
transform: scale(0)-Eintritt	scale(0.95) + opacity: 0
ease-in bei einem UI-Element	ease-out oder eine starke benutzerdefinierte Kurve
Eingebautes ease-out in einer bewussten Animation	cubic-bezier(0.23, 1, 0.32, 1)
Animation bei einem Tastaturkürzel oder 100+/Tag-Aktion	Keine Animation
UI-Dauer über 300 ms ohne Grund	150–250 ms
transform-origin: center bei einem auslöserverankerten Popover	var(--transform-origin) (Modale ausgenommen)
Keyframes bei Toasts, Schaltern, schnell ausgelösten Elementen	CSS-Übergänge
width/height/margin/padding/top/left animieren	transform / opacity
Motion x/y/scale-Props unter Last	Vollständiger transform-String
Ungeschützte :hover-Bewegung	@media (hover: hover) and (pointer: fine)
Fehlendes prefers-reduced-motion	Sanftere Variante, nicht Null
Alles tritt gleichzeitig ein	30–80 ms Staffelung

Ausgabe

Schreibe den Code. Dann, in höchstens ein paar Zeilen:

• Das Prüfergebnis – Häufigkeitsstufe und der benannte Zweck. Wenn etwas in der Anfrage abgelehnt wurde, sag, was und warum.
• Die Zutaten – Werkzeug, Eigenschaften, Kurve, Dauer oder Federkonfiguration, jeweils in einer Zeile.
• Was auf Gefühl zu prüfen ist – wenn das Ergebnis von einem Gefühl abhängt, das du nicht anhand des Codes beurteilen kannst (eine Überblendung, der Bounce einer Feder, das Opazitäts-/Höhen-Verhältnis in einer eintretenden Liste), sag es und weise auf die Prüfung hin: spiele es bei 2–5× Dauer oder im DevTools-Animationsinspektor ab, gehe es Frame für Frame durch, teste Gesten auf einem echten Gerät und schau es am nächsten Tag mit frischen Augen an.

Mache daraus keinen Bericht. Der Code ist die Leistung.

Ton

Meinungsstark und knapp. Wenn die ehrliche Antwort „das sollte nicht animieren“ ist, gib sie – diese Antwort ist der Grund, warum dieses Skill existiert. Wenn das Gefühl wirklich nicht anhand des Codes geklärt werden kann, sag es, anstatt einen Wert zu schätzen.