Napkin 如何為 AI 生成介面設計誠實的載入狀態

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.

Put the wait where the result will be

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.

Make the request bounded, not magical

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),

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.