Formforvandling gjennom brukergrensesnitttilstander

Spør meg om: 8 til 12 brukergrensesnitttilstander jeg ønsker at formen skal være (f.eks. knapp, laster, spiller, glidebryter, veksleknapp, faner, diagram, kommandopalett, toast), ren svart-hvitt eller én aksentfarge, og en royaltyfri sang rundt 120 BPM (f.eks. Mixkit, gratis for kommersiell bruk).

Dribbble-nivå UI-bevegelse. Én form, aldri kutt: hver tilstand er det samme elementet som forandrer størrelse, radius og farge, mens innholdet bytter med en kort uskarphet. En markør styrer hver endring med ekte klikk og draing. Lys varmgrått lerret, svart-hvitt-komponenter, én ren UI-font (Geist). Fjærer overalt, en liten overskygging på det meste. Kameraet zoomer slik at hver tilstand fyller bildet. Det siste bildet er det første bildet, så det looper.
Utestengt: hoppende lettelser, partikkelutbrudd, glød, gradienter i UI-krom, ikonstrøk som ikke samsvarer, dødtid, alt som ser ut som en mal.

120 BPM, 7 takter, noe skjer på hvert slag.
Knapp → laster → sjekk → dynamisk øy → musikkspiller med en spill av/pause-morf → skru fremdriftslinjen → den blir en volumglidebryter som strekker seg når den dras forbi maks → en vekslebryter vippes på takten → knappen blir en flytende tabulatorindikator → fanene åpnes i et diagram som tegner seg selv, med et verktøytips når du holder musepekeren over den → den skjules til ⌘K → skriv for å filtrere → enter → toast → tilbake til knappen.

1. Én HTML fil, kvadratisk 1440x1440. Hver stil beregnes ut fra tiden i seek(t): ingen CSS overganger, ingen tidtakere, ingen tilstand mellom rammer.
2. Fjærer er lukkede trinnresponser. En verdi som endrer mål mange ganger er summen av én fjær per endring, så den forblir en ren funksjon av tid.
3. De to kantene på faneindikatoren er avhengige av forskjellige fjærer, slik at den fremre kanten strekker seg foran den bakre. Samme triks for vippeknappen.
4. Draging er direkte manipulasjon: mens markøren holdes, beregnes verdien fra dens posisjon. Når den slippes, spretter den tilbake fra der den var.
5. Analyser sangen med numpy for taktnettet og start på et nedadgående taktslag. Plasser hver UI-lyd ved den målte toppen.
6. Rendering med Playwright: 4 underbilder per bilde, blandet med ffmpeg tmix for bevegelsesuskarphet ved 60 fps.
7. Rendre én ramme per taktslag før full rendring. Fiks alt utenfor rutenettet, trangt eller vanskelig å lese.

Bruk aldri will-change på noe som kameraet skalerer eller teksten gjør uskarpt. Tekst som bytter inne i en morphing-container trenger sin egen inngangs- og utgangstiming, ellers overlapper den. Gjør den siste rammen identisk med den første, inkludert markørposisjon og hastighet, ellers hakker løkken.

Spør meg om inndataene, og vis meg deretter tilstandslisten på taktrutenettet før du skriver 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ørsmål hentet fra stolpe @twoclipping.