07 · Images, motion, and HTML video

OpenDesign makes more than static pages. Image generation, code-driven motion, and video are all in there, by different routes.

Image generation

There's an Image entry point, and you can also generate imagery inside a deck or page build as needed.

The supported models track the release; GPT Image, Seedream, and Nano Banana are the usual ones. Managed tiers open image models by plan; the free tier runs on your own key.

Sketch input

An easy capability to miss: it accepts hand-drawn input.

Draw something rough — a dragon, a screen — save the file, then reference it and ask for a real image or a real screen. It asks about orientation and background, generates, and drops the result back into your design files.

For people who can't draw, that's the point: you need an idea, not a skill. The sketch carries structure and layout intent, not craft.

The same trick works for prototypes — a crooked wireframe becomes a mature-looking mobile screen. See Playbooks / Sketch to app prototype.

Keeping the style consistent

The failure mode of batch generation is drift. Fix one image first:

All images use one style: [describe it].

Generate one first. Once I confirm it, reuse the same style
description for every subsequent image. Don't improvise per image.

Code-driven motion

There's a built-in motion skill producing pure SVG + CSS animation — every visual element is code.

That's considerably more useful than generating a GIF:

• Drops into a deck or a page
• Resolution-independent, sharp on a projector
• Editable — change text, change colours, edit the code
• Small

One community example is an animation of two anthropomorphic phones meeting and talking, done entirely in SVG and CSS.

Use it when a deck needs a moving diagram, a page needs an explanatory animation, or you're describing a process or a state change.

HTML video

The video line works with the hyperframes project: code-driven product prototype demos and data-visualisation animation.

Compared with conventional editing:

	HTML video	Conventional edit
Source	Code	A timeline project file
Changing data	Change an array	Rebuild that section
Version control	git diff	Binary file
Rendering	Run it again	Export again
Suits	Product demos, data stories, launch shorts	Live footage, complex editing

The fit is clear in both directions. It's right for feature demos, launch shorts, data stories, and changelog videos. It's wrong for anything involving filmed material.

See Playbooks / HTML video and motion shorts.

The desktop pet

Nothing to do with output, but worth a line: you can raise a desktop pet, including community-contributed characters. Save it and it lives on your desktop and interacts.

It says something about a project that cares how a tool feels, not only what it emits. Use it or don't.

Which one when

You want	Use
A poster, cover, or icon	Image generation
An explanatory animation	Code motion (SVG + CSS)
A paced product short	HTML video (hyperframes)
Entrances and transitions in a deck	CSS animation, not 3D
A background with depth	Three.js, in one or two places only

The priority order: CSS before 3D, code before generated images, real assets before generated ones. Each step down costs you control and editability.

Where it goes wrong

Trap	How it shows	Fix
Style drift across a batch	Every image looks differently sourced	Approve one, then batch
Text inside generated images	Garbled lettering	Require no text in images
Motion as a GIF	Blurry, heavy, uneditable	Use code motion
Too much in one video	The viewer can't follow	One idea per shot
3D in a presentation deck	Dropped frames in the room	Use CSS animation

Related

• Deck workshop / Step 6 — deciding which images earn a slide
• Deck workshop / Step 8 — motion, sparingly
• Playbooks / Posters
• Playbooks / HTML video