heygen-com--hyperframes/skills/hyperframes-animation/blueprints/device-surface-showcase.md

device-surface-showcase — Device / Surface Showcase

intent: A product surface — a device mockup or a floating browser/app window — is the hero held in frame while its screens cycle through a real flow, showcased by a camera move that ranges from a static hold to a continuous 3D push.

roles served

• KeyFeature (from key-feature-device-screen-tour, key-feature-floating-window-scroll, key-feature-3d-device-hand-demo): show a feature being _experienced inside its real interface — the surface houses the action and its screens advance through a flow, rather than enumerating tiles or chasing a cursor across a workflow. (Note: all three drafts are Key_Feature; this blueprint is role-narrow but mechanic-rich — variants differ by MECHANIC, not role.)
• Key_Feature (from demo-page-scroll-spotlight): the floating-window push-scroll variant carried to a spotlight climax — a real webpage rendered as a tilted 3D card coasts in (power2, like a phone held up — no spring), header keywords flare on a karaoke glow as the VO names them, the page rolls to the demoed section, and one element LIFTS off the surface (translateZ + scale) under a radial spotlight that dims the rest.

duration: 5–9.6s (page-scroll-spotlight 5–9s · floating-window 7.8s · 3d-hand 7.9s · device-tour 9.6s)

shot structure One product surface — a [device mockup] or a [floating browser/app window] — is the persistent hero on a [styled backdrop: gradient / radial / stylized 3D void]; its [screens/sections] cycle through a real [product flow] while a showcase camera (static-hold, push-in→zoom-out, or one continuous push) presents it. Each screen state holds ~1.0–1.5s.

• Scene 1 (0.0–~1.5s): The surface ESTABLISHES — it [slides in from an edge / drifts in from a tilt / dissolves from a full-frame title card] and settles, with a [accent shape or backdrop] resolving behind it; the first [screen] is visible. The showcase camera begins (see variants).

• Scene 2 (~1.5–~Xs): The surface is OPERATED on its own face — a [tap/select/scroll] triggers the first screen advance: old content [pushes out / scrolls up], new [screen/section] [pulls up / pushes in from the side]; concurrently a [label / header word / side headline] updates. The camera continues its move.

• Scene 3+ (~Xs–end, repeat for [2–4 screen beats]): The surface ADVANCES through successive [screens/sections], each a discrete swap or scroll synced to the surface's flow, while the secondary copy [swaps out-up / in-up] or stays marked to hold reading position. HOLDS on the final [screen] (or, for one variant, blooms out — see variant).

• Variant — static-tour (key-feature-device-screen-tour, 9.6s): a [device mockup] slides in from off-screen and settles (ease-out); an [accent-color shape] scales up behind it (spring overshoot). Camera STAYS STATIC the entire clip — all motion is element/UI-level: a tap COMPRESSES a button (95%→100%), the UI scrolls/transitions to the next view (old pushes out, new pulls up), and a [side headline] SWAPS beside the device (old slides up + fades, new slides up + in) per screen. Holds on the final screen. No camera move, no cursor.

• Variant — floating-window (key-feature-floating-window-scroll, 7.8s): OPENS on a full-frame [title card] (a small [icon] draws in at center, [feature name] below; holds ~2s), which DISSOLVES to a [macOS-style browser/app window] floating on a [vivid gradient] (traffic-lights + [URL pill] + tabs; left nav, central content, right [sidebar]). Camera PUSHES IN on a [target region/sidebar] (active item highlighted [accent], a cursor drifts down the list), then ZOOMS BACK OUT to re-frame the whole window while the content SCROLLS through [sections]; the [highlighted item] stays marked. One push-in→zoom-out arc, gated by the title-card opener.

• Variant — 3d-hand (key-feature-3d-device-hand-demo, 7.9s): FULLY 3D — a [3D device] drifts in a [stylized 3D void / bloom + particles], opening tilted and self-rotating to face the lens nearly flat as ONE CONTINUOUS forward camera push begins (no cuts). A glossy [3D hand] rises from the bottom-foreground and GESTURE-DRIVES the surface: it swipes to scroll a [picker/sidebar panel] of [option cards] and taps [option] (while a [header word] letter-flips in place); the selection APPLIES — a [new layout] grows from center to fill the device face, nav flips, a [marquee] scrolls horizontally; the hand swipes again to scroll the page upward through [sections], then drifts out. The camera never stops pushing; the bright device face keeps growing toward the lens until it BLOOMS into a [light] wash — a zoom-through "portal" exit that fills the frame.

motion vocabulary surface establish (edge slide-in + settle / tilt drift-in + self-rotate-to-camera / title-card dissolve); accent shape spring behind surface; element-level screen-cycling (scroll-swap, push-in-from-side, scale-swap); button tap-compress; staggered side-headline reveal + copy swap (out-up / in-up); in-place header-word letter-flip; floating browser-window-on-gradient idle float; full-frame title-card opener (icon draw-in + label); camera push-IN on a region; camera zoom-OUT re-frame; content scroll-through; one continuous 3D camera-follow push (no cuts); 3D device drift + self-rotate; stylized-environment bloom/particles; 3D-hand entrance + swipe-scroll + tap (gesture-driven); picker-panel slide-in; template-apply grow-from-center; horizontal marquee scroll; gesture-driven page scroll; zoom-through bloom/portal exit; static-hold (no camera) as the floor of the camera range.

rule mapping (per motion verb → backing rule, or flagged special)

• screen-cycling — UI scrolls/sections scroll inside the surface (device-tour, floating-window scroll, 3d-hand page scroll) → 3d-page-scroll (webpage/app as a tilted card whose content translateY-scrolls to sections; primary mechanic for the surface's screen flow)
• floating-window establish + the surface presented as a tilted/floating UI card → 3d-page-scroll (the tilt/perspective framing) + css-3d-transforms (perspective/translateZ depth)
• screen / side-copy state swaps (discrete screen states; side headline content swapping per beat) → discrete-text-sequence
• side-headline reveal (staggered fade + slide-up) → discrete-text-sequence
• in-place header-word letter-flip (3d-hand) → hacker-flip-3d
• screen swap as a coordinated shrink-out / pop-in between two screen states → scale-swap-transition
• template-apply "new layout grows from center to fill the face" (3d-hand) → center-outward-expansion (clustered-at-center → expand to fill)
• the surface morphing between states / title-card→window dissolve as the eye-anchor transition → card-morph-anchor
• button tap-compress (95%→100% press feedback) → press-release-spring (or physics-press-reaction for a heavier press)
• floating-window cursor click on the highlighted list item → cursor-click-ripple
• accent-highlight pop on the active sidebar/list item → asr-keyword-glow (accent glow on the focused item)
• drifting cursor down the sidebar list (floating-window) → camera-cursor-tracking (flat-cursor drift; pairs with the push-in)
• floating browser-window idle float / 3D device drift-breathe → sine-wave-loop
• 3D device drift + self-rotate-to-camera + perspective depth (3d-hand) → css-3d-transforms (CSS-3D) or 3d.md technique (true Three.js/R3F device); see camera modifier
• horizontal [marquee] scroll (3d-hand) → viewport-change (PAN mode on the marquee strip) — thin fit; a literal CSS-marquee/translateX loop is closer to a gsap-effects/CSS recipe than a named motion rule
• 3D-hand entrance + swipe + tap as the interaction DRIVER (gesture input that scrolls/selects) → flagged special — needs a heavier capability beyond the rule library (R3F/Three.js + WebGL), NOT a motion-shape rule. The 3D hand model + WebGL bloom have a technique backing (3d.md — R3F, useGLTF HandModel, --gl=swiftshader for the shader/bloom), but no motion-shape rule models a 3D hand as the swipe-to-scroll / tap-to-select gesture protocol. context-sensitive-cursor / camera-cursor-tracking only model a flat typing/pointer cursor, not a 3D gesturing hand.
• zoom-through bloom / portal exit (3d-hand) → flagged special — needs a heavier capability beyond the rule library (WebGL), NOT a named transition rule. Capability is techniques.md → WebGL shader (via 3d.md headless WebGL: --gl=swiftshader --concurrency=1), but no named transition rule covers a bloom/portal fly-through.

camera modifier: The showcase camera spans a RANGE keyed by variant, all on a single content-wrapping virtual camera (viewport-change):

• static-tour → NO camera move (viewport-change held at scale 1, or omitted); all motion is element-level. This is the floor of the range and what distinguishes the device-tour from the rest.
• floating-window → a two-phase push-in → zoom-out arc → multi-phase-camera (e.g. dramatic-reveal 1.1→1.0→0.95 feel): push IN on the [sidebar/region] via coordinate-target-zoom (off-center target = scale + counter-translate), then multi-phase-camera zooms back OUT to re-frame the whole window while content scrolls.
• 3d-hand → ONE continuous forward push (no cuts) → multi-phase-camera in steady-push mode (1.0→1.03→1.06… plus its sine micro-drift) layered over css-3d-transforms/3d.md so the device self-rotates-to-lens during the push; the push runs unbroken into the bloom/portal exit (exit itself is the WebGL-shader flagged special above). Across all three: viewport-change is the base virtual-camera primitive; multi-phase-camera sequences the push/zoom phases (and supplies the always-on micro-drift that keeps even the "static" tour from feeling dead); coordinate-target-zoom aims the push at off-center screen detail.

Overflow (pan/scroll surfaces — required for a clean inspect): a panned or scrolled surface deliberately moves content PAST the edges of its framing card. Clip it at the card (overflow: hidden on the card/window) AND mark the moving inner layer (the .world / surface wrapper holding the screenshot + any markers/labels) with data-layout-allow-overflow — otherwise inspect reports text_box_overflow / container_overflow ERRORS for the parts that scroll off (e.g. a marker label panned off the left edge). The card clips them visually; the attribute tells inspect it's intentional, not a layout bug.