Formforvandling gennem brugergrænsefladetilstande

Spørg mig om: 8 til 12 brugergrænsefladetilstande, jeg ønsker, at formen skal være (f.eks. knap, indlæser, afspiller, slider, skifte, faner, diagram, kommandopalet, toast), ren sort og hvid eller én accentfarve, og en royaltyfri sang omkring 120 BPM (f.eks. Mixkit, gratis til kommerciel brug).

Bevægelse i brugergrænsefladen på Dribbble-niveau. Én form, aldrig beskæring: hver tilstand er det samme element, der ændrer størrelse, radius og farve, mens indholdet skifter med en kort sløring. En markør styrer hver ændring med rigtige klik og træk. Lys varmgråt lærred, sort-hvide komponenter, én ren brugergrænseflade-skrifttype (Geist). Fjedre overalt, højst en lille smule overskridelse. Kameraet zoomer, så hver tilstand fylder hele billedet. Det sidste billede er det første billede, så det looper.
Udelukket: hoppende lettelse, partikeludbrud, glød, gradienter i UI Chrome, uoverensstemmelser i ikonstrøg, dødtid, alt der ligner en skabelon.

120 BPM, 7 takter, der sker noget på hvert slag.
Knap → indlæser → tjek → dynamisk ø → musikafspiller med en afspil/pause-morph → skrub statuslinjen → den bliver en lydstyrkeskyder, der strækker sig, når den trækkes forbi max → en skifteknap vippes på takten → knappen bliver en flydende tabulatorindikator → fanerne åbner i et diagram, der tegner sig selv, med et værktøjstip, når du holder musen over den → den skjules til ⌘K → skriv for at filtrere → enter → toast → tilbage til knappen.

1. Én HTML fil, kvadratisk 1440x1440. Hver stil beregnes ud fra tiden i seek(t): ingen CSS overgange, ingen timere, ingen tilstand mellem frames.
2. Fjedre er lukkede trinvise reaktioner. En værdi, der ændrer sig mange gange, er summen af én fjeder pr. ændring, så den forbliver en ren funktion af tid.
3. Tappindikatorens to kanter er påvirket af forskellige fjedre, så den forreste kant strækker sig foran den bageste. Samme trick gælder for vippeknappen.
4. Træk er direkte manipulation: mens markøren holdes nede, beregnes værdien ud fra dens position. Når den slippes, springer den tilbage fra, hvor den var.
5. Analysér sangen med numpy for beatgitteret og start på et downbeat. Placer hver UI-lyd ved dens målte peak.
6. Render med Playwright: 4 underbilleder pr. billede, blandet med ffmpeg tmix for bevægelsessløring ved 60fps.
7. Render én frame pr. taktslag før den fulde rendering. Ret alt, der er uden for gitteret, trangt eller svært at læse.

Brug aldrig will-change på noget, som kameraet skalerer eller teksten slører. Tekst, der skifter i en morphing-container, skal have sin egen ind- og udgangstiming, ellers overlapper det. Sørg for, at den sidste frame er identisk med den første, inklusive markørposition og -hastighed, ellers hakker løkken.

Spørg mig om inputtene, og vis mig derefter tilstandslisten på taktgitteret, før du skriver nogen kode.

Ask me for: 8 to 12 UI states I want the shape to become (e.g. button, loader, player, slider, toggle, tabs, chart, command palette, toast), pure black and white or one accent color, and a royalty-free song around 120 BPM (e.g. Mixkit, free for commercial use).

Dribbble-level UI motion. One shape, never cut: every state is the same element morphing its size, radius and color while its content swaps with a short blur. A cursor drives every change with real clicks and drags. Light warm-gray canvas, black and white components, one clean UI font (Geist). Springs everywhere, a tiny overshoot at most. The camera zooms so each state fills the frame. The last frame is the first frame, so it loops.
Banned: bouncy easing, particle bursts, glows, gradients on UI chrome, mismatched icon strokes, dead time, anything that looks like a template.

120 BPM, 7 bars, something happens on every beat.
Button → loader → check → dynamic island → music player with a play/pause morph → scrub the progress bar → it becomes a volume slider that stretches when dragged past max → a toggle flips on the beat → the knob becomes a liquid tab indicator → the tabs open into a chart that draws itself, with a tooltip on hover → it collapses into ⌘K → type to filter → enter → toast → back to the button.

1. One HTML file, square 1440x1440. Every style is computed from time inside seek(t): no CSS transitions, no timers, no state carried between frames.
2. Springs are closed-form step responses. A value that changes target many times is the sum of one spring per change, so it stays a pure function of time.
3. The tab indicator's two edges ride different springs, so the leading edge stretches ahead of the trailing one. Same trick for the toggle knob.
4. Drags are direct manipulation: while the cursor is held, the value is computed from its position. On release it springs back from wherever it was.
5. Analyze the song with numpy for the beat grid and start on a downbeat. Place every UI sound by its measured peak.
6. Render with Playwright: 4 subframes per frame, blended with ffmpeg tmix for motion blur at 60fps.
7. Render one frame per beat before the full render. Fix anything off the grid, cramped or hard to read.

Never put will-change on anything the camera scales or the text renders blurry. Text that swaps inside a morphing container needs its own enter and exit timing or it overlaps. Make the last frame identical to the first, cursor position and speed included, or the loop stutters.

Ask me for the inputs, then show me the state list on the beat grid before you write any code.

Spørgsmål taget fra stolpe @twoclipping.