Show a product on screen

The product's own screens provide evidence of what it does. First question: what must the viewer understand or inspect, and what evidence is available? Use screenshots, recordings or the running app (guide-pull-product-highlights) according to that need. Prominence affects capture resolution and legibility; it does not make motion compulsory.

Routes

Presentation and pace

Any route may use a full frame, device frame, card or picture-in-picture. Choose the layout for the evidence and its surrounding message. A presenter can occupy a bubble when helpful (guide-present-with-an-avatar); leave room for what the viewer must read.

Choose movement from tone and reading load: hn4a-compositor-fast-ad-camera for rhythmic emphasis, hn4a-compositor-calm-explainer-camera for measured reveals, or a held frame for inspection. A launch or ad may be calm; an explainer may open with an energetic beat. A camera move is useful when it makes the next point easier to find.

Choosing

• Never animate a UI with a video model: image-to-video warps a screenshot's text. The product's screens go on as layers; a generated shot around them is fine.
• Generated screens never: the text comes out wrong. When the product has no clean screen to show, make one from its real parts (rebuild it), never from a prompt.
• Capture at 2× for a screen the camera pushes into: a 1600 px screenshot shown 1600 px wide and pushed to 1.6× is upscaled and goes soft. A recording is scaled to 2560×1440 under a 1080p frame, so framings up to 1.33× lose nothing and 1.6× stays readable.
• Read every box off a gridded full-size frame (python-contact-sheet, --grid 50): boxes estimated from a contact sheet landed a whole row high.
• For a staged reveal, move the parts that carry the point; keep navigation and other stable context readable. Follow the actual action when showing a recording.
• A presenter over the screens sits in a bubble clear of what the camera frames (guide-present-with-an-avatar, Layouts).

Framing and cueing

• Device frame: an empty frame from the brand's own assets (a repo's screenshot tooling often has one). Place it at width PW, k = PW / frame_width, and the screenshot at the frame's measured screen inset times k, with radius the screen's corner radius times k. Measure the inset by scanning out from the frame's centre for the transparent or white pixels of the opening (a 3939×8022 phone frame: inset x 201, y 177, 3537×7668). Keep one device on screen and swap the screenshot on each step with a 0.3 s fade.
• Card over footage: the real screen as a rounded card on the line that names it, popped on the word. A card that replaces something in the picture (a dashboard on a wall screen) cuts on and off on that shot's own cut frames (ffmpeg-scene-cuts), with cut as its in and out.
• A screen recording under a camera: the screen track in a camera() group, each framing cued on a phrase, never a typed second, so a re-cut keeps it on its words. Highlights are parented to the camera: a transparent fill 10 px larger than the element, radius 14, a 5 px ring in the brand's accent plus a soft glow, popping in 0.1 s before its phrase and out at the next phrase or 0.15 s before its shot ends, never on a timer (one timed "+3 s" outlived its shot).

Avoid

• Motion that competes with reading, or an invented UI state presented as a real product capability.
• Zooming a recording past 1.6×: at 2.1× text was cut off; frame the whole thing being talked about (the full card, the header with the price), not its middle.
• An animated crop on a compositor video layer: the picture didn't fill its box; render footage zooms in ffmpeg.

Related

• guide-make-a-video-from-a-website: the piece the screens go into, from a URL.
• guide-add-titles-and-motion-graphics: everything else on screen.