Warten mit Stil: Ehrliche Ladezustaende fuer KI-generierte Oberflaechen
Wenn ein Modell fuer die Generierung eines UI-Entwurfs fast zwei Minuten braucht, wirkt ein eingefrorener Editor schnell wie ein Absturz. Im Tool Napkin bleibt daher der bestehende Entwurf geschuetzt, waehrend Nutzer per Textbeschreibung oder Skizze neue HTML-Entwuerfe anfordern.
Wenn ein Modell länger braucht, ist das ein Backend-Problem. Dass der gesamte Editor während des Wartens eingefroren wirkt, ist jedoch auch ein Produktproblem.
In Napkin beschreiben Nutzer eine UI-Idee oder laden eine Skizze hoch und bitten die Anwendung, einen responsiven HTML-Entwurf zu generieren. Wenn Gemini nahezu zwei Minuten brauchte, blieb der vorhandene Entwurf zwar erhalten, doch das Feedback bestand lediglich aus einem generischen Spinner über dem Editor. Dieser verdeckte den Arbeitsbereich, ohne zu zeigen, wo das Ergebnis erscheinen würde.
Bei der ersten Generierung verwandelt sich die leere Vorschau-Fläche nun in ein kleines animiertes Mockup: Ein Header, eine Feature-Karte und Textblöcke zeichnen sich auf, während eine dezente Bewegung über das Frame läuft. Die Animation befindet sich innerhalb der Fläche mit dem Hinweis „Your idea goes here“, nicht über dem gesamten Editor. Ein kurzes Statuslabel erklärt, was gerade passiert, und der vorhandene Entwurf bleibt während der Neugenerierung sichtbar.
Die zentrale Idee ist kontextbezogenes Feedback: Der Ladezustand soll dem Ergebnis ähneln, statt das Produkt mit einem inhaltlich unverbundenen Spinner zu überdecken. Die Animation basiert auf CSS, und die Anwendung deaktiviert Animationen bereits für Nutzer, die reduzierte Bewegung bevorzugen.
Zusätzlich habe ich den Gemini-Prompt verschärft, die Ausgabe auf 8.192 Tokens begrenzt und den Request-Timeout auf 45 Sekunden verkürzt. Diese Änderungen begrenzen den Arbeitsaufwand und sorgen dafür, dass eine hängende Anfrage früher fehlschlägt; sie garantieren jedoch nicht, dass das Modell innerhalb dieser Zeit antwortet. Der Client ersetzt den aktuellen Entwurf erst nach einer vollständigen erfolgreichen Antwort, sodass ein Timeout keine Arbeit vernichtet. Dieser Pfad wartet weiterhin auf die vollständige Antwort, anstatt partielles HTML zu streamen.
Die relevanten Request-Einstellungen sind bewusst klein gehalten:
generationConfig: { temperature: 0.25, maxOutputTokens: 8192, }, signal: AbortSignal. timeout ( 45 _000 ), Enter fullscreen mode Exit fullscreen mode Ein guter Ladezustand verbessert die Wartezeit, aber er kann einen langsamen Provider nicht schnell machen. Halte die Timeout-Meldung ehrlich, bewahre wiederherstellbare Arbeit auf und messe die tatsächliche Provider-Latenz getrennt von der wahrgenommenen Reaktionsfähigkeit.
Napkin ist Open Source: nonydev27/napkin.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
A model taking a while is a backend problem. Making the whole editor look frozen while it waits is a product problem too.
In Napkin, users describe a UI idea or upload a sketch and ask the app to generate a responsive HTML draft. When Gemini took close to two minutes, the existing draft stayed safe—but the feedback was a generic spinner over the editor. It obscured the workspace without showing where the result would appear.
For the first generation, the empty preview canvas now changes into a small animated mockup: a header, a feature card, and text blocks draw in while a subtle sweep passes over the frame. The animation lives inside the “Your idea goes here” canvas, not across the editor. A brief status label explains what is happening, and the existing draft remains visible during regeneration.
The key idea is contextual feedback: make the loading state resemble the outcome, rather than covering the product with an unrelated spinner. The motion is CSS-based and the app already disables animation for users who prefer reduced motion.
I also tightened the Gemini prompt, capped output at 8,192 tokens, and shortened the request timeout to 45 seconds. These changes constrain work and make a stalled request fail sooner; they do not guarantee the model will return within that time. The client only replaces the current draft after a complete successful response, so a timeout does not erase work. This route still waits for the full response rather than streaming partial HTML.
The relevant request settings are intentionally small:
generationConfig: { temperature: 0.25, maxOutputTokens: 8192, }, signal: AbortSignal. timeout ( 45 _000 ), Enter fullscreen mode Exit fullscreen mode A good loading state improves the wait, but it cannot make a slow provider fast. Keep the timeout message honest, preserve recoverable work, and measure actual provider latency separately from perceived responsiveness.
Napkin is open source: nonydev27/napkin.