hyperframes/skills/hyperframes-animation/blueprints/concept-demo-decode-pan.md

---

id: concept-demo-decode-pan role: concept-demo duration_seconds: [6, 10] phases: 4 visual_arc: text-decode → scene-pan → cursor-track uses_rules: [hacker-flip-3d, camera-cursor-tracking, discrete-text-sequence] # discrete-text-sequence = smooth-slice variant element_roles: shot1_static: Context-setting text that fades in (tagline, slogan) shot1_accent: Accent word that decrypts via hacker-flip 3D (the hook) shot2_interactive: Interactive element (search bar, input field) with cursor-tracked typing when_to_use:

• Two visually distinct shots connected by a cinematic transition
• First shot reveals text dramatically (decode / decrypt)
• Second shot demonstrates product interaction (typing, search, input)
• "Reveal the concept → show it in action" flow when_not_to_use:
• Single scene, no transition — see brand-reveal-assemble-zoom or takeover-ticker-displace
• Shots should cross-fade rather than pan
• No text decode in the first shot
• Second shot is static (no dynamic tracking) triggers: [decode effect, decrypt, scene transition, search bar typing, horizontal pan, show then demonstrate]

---

Concept-Demo · Decode & Pan (HyperFrames)

This is a "tease → reveal → demonstrate" emotional arc: the viewer reads a static phrase, then the accent word decrypts in front of them like an old flap-display — the concept has just been declared. Before they can dwell, the camera pans sideways into a second shot where the product itself starts typing, answering "and here's what it does." Shot 1 is the hook; the pan is the bridge; Shot 2 is the proof.

Four phases on one paused GSAP timeline. The pan is the only place two unrelated rules' end-states have to align in screen space, and it's the failure-prone joint.

When to Use

• Promo has two narrative beats: concept reveal, then product demo
• First beat needs a dramatic text effect (decode / decrypt)
• Second beat shows interactive behavior (typing, searching, input)
• Need spatial continuity between beats (pan, not cut)

Orchestration

This scene combines three rules plus one inline phase, threaded together by a horizontal "shot strip" that the camera slides through.

• Phase 1 — Shot 1 entry: no rule, inline fromTo on .shot1-content (opacity: 0 → 1, y: RISE_DIST → 0, power2.out). This is a context-setting fade-rise — too small a motion to deserve its own rule, and giving it back.out would compete with the decode's elasticity in Phase 2.
• Phase 2 — accent word decode: use hacker-flip-3d at the rule's default transform-origin: bottom (flap-display look). Reason for the default here: the accent word reads as a "verdict landing" — the bottom-hinge flap feels mechanical and authoritative, where a top hinge would feel like the text is falling away from the viewer just when we want it to arrive. The static phrase next to it stays still — only the accent word gets the 3D treatment, so visual hierarchy reads cleanly.
• Phase 3 — horizontal pan + parallax + Shot 2 entry: no rule, this is the blueprint's core glue. Three concurrent tweens at the same timeline position, all sharing PAN_DUR. See "Phase 3 Seam" below for the pan-ease constraint and the parallax math.
• Phase 4 — cursor-tracked typing: use camera-cursor-tracking in its continuous-typing-driver variation (the one called out in that rule's Variations section, not the default maxWidth form). Reason: the cursor's screen X has to feed the parent strip's x transform, not just the world container's, because the strip is already carrying the Shot 1→Shot 2 pan. Two cameras nested would be untenable. The typing driver itself is discrete-text-sequence in its smooth-slice variation (continuous typewriter, no typos). We don't want the human-typing chaos here — the demo is selling product confidence, not realism.

Phase Timing

Phase	Start ≥	Internal duration	Notes
1	0 (or end of previous scene)	ENTRY_DUR	Static text + accent placeholder both fade in together
2	ENTRY_START + ENTRY_DUR (no buffer)	FLIP_STAGGER × (N − 1) + FLIP_DUR	Decode starts the instant entry lands — no breath, builds urgency
3	FLIP_END + ~0.2s	PAN_DUR	Decode needs to visually settle before the camera tears away
4	PAN_START + PAN_DUR + ~0.15–0.2s	until TOTAL_DURATION − dwell	Eye needs a beat to find the bar before reading typing

Phase 1 → Phase 2 has no gap on purpose. The accent slot is already in its final layout position during Phase 1 (the flip rotates from 90° to 0° in place, no translation), so kicking the decode the instant the fade lands stacks the two beats into one continuous "here it comes — and there it is." Inserting a buffer here makes the decode feel detached from the phrase.

The 0.2s gap between Phase 2 and 3 is the most failure-prone one. back.out on the per-glyph flip overshoots and rebounds (see hacker-flip-3d's default ease); if you pan while the last glyph is still settling, the strip is sliding sideways while one character is still rotating, and the eye reads it as a glitch. The 0.2s is roughly the spring tail of the last character's back.out(FLIP_BOUNCE) — pad it more if you pick a larger FLIP_BOUNCE.

The 0.15–0.2s gap between Phase 3 and 4 is a reading buffer, not a spring buffer. The pan ends cleanly (power3.inOut has no overshoot), but the viewer's eye needs ~150ms to re-anchor on Shot 2's bar before typing starts. Cut this gap and the first few characters get missed.

Initial DOM Nesting (Horizontal Shot Strip)

The "shot strip" architecture is the spatial backbone — both Phase 3 (pan) and Phase 4 (cursor tracking) tween the same .strip element, so the order of layers below it must not bake any pan offset into Shot 2's internal world space.

.viewport            (overflow: hidden — clips off-screen shots)
  .strip             (flex row; Phase 3 + Phase 4 both tween its x)
    .shot.shot1
      .shot1-content (Phase 1 fade-rise target; Phase 3 parallax target)
        .shot1-row
          .shot1-static          (static phrase, no animation)
          .shot1-accent          (Phase 2 hacker-flip container)
            .flip-glyph × N      (one per char of accentWord)
    .shot.shot2
      .shot2-bar     (Phase 3 fade-scale target; cursor sits here in Phase 4)
        .search-text (Phase 4 typing target; smooth-slice variation)
        .search-cursor

Each .shot is exactly VIEWPORT_W wide with flex-shrink: 0; the strip width is therefore implicit (shots × VIEWPORT_W) and the pan distance equals one VIEWPORT_W. Letting flex compress the shots would silently shrink the pan distance and the camera would over-shoot in Shot 2.

.shot2-bar ships with opacity: 0 and transform-origin: left center so Phase 3's back.out scale lands the bar correctly when it arrives. The bar's width is pre-allocated from a font probe before the timeline registers — see Phase 4 Seam.

Phase 3 Seam: The Pan (Strip + Parallax + Shot 2 Entry)

Three tweens fire at the same timeline position, all sharing PAN_DUR:

1. .strip tweens x: 0 → -VIEWPORT_W with power3.inOut (the camera)
2. .shot1-content tweens x: 0 → -PARALLAX_DIST with power3.inOut (the near-plane, moves faster than the camera so depth reads)
3. .shot1-content also tweens opacity: 1 → 0 with power2.out, duration PAN_DUR × FADE_RATIO — the fade finishes before the pan does so the eye is on Shot 2 well before the strip stops
4. .shot2-bar tweens opacity: 0 → 1 and scale: ENTRY_SCALE_FROM → 1 with back.out(ENTRY_BOUNCE) over PAN_DUR (the landing)

The pan ease is the most common point of failure here. back.out on the strip reads as a UI bounce — the viewer's brain says "menu sliding in," not "camera moving." Use power3.inOut (slow start, slow finish — feels cinematic) or power2.out (quicker, snappier — feels like a UI swipe but still not a bounce). Reserve back.out for the .shot2-bar entry, where overshoot reads as the bar landing into place.

The parallax is additive: .shot1-content's x displacement is on top of the strip's x. When the strip has moved -VIEWPORT_W and .shot1-content has moved an extra -PARALLAX_DIST, the Shot 1 layer has effectively moved -(VIEWPORT_W + PARALLAX_DIST) in world space — so it leaves the frame faster than the camera passes it, which is what "near plane moves faster" means optically. PARALLAX_DIST in the 15–25% of viewport width range reads as strong depth without throwing Shot 1 away.

FADE_RATIO should land Shot 1's opacity at 0 around the 30–50% mark of the pan — fading later leaves stale content on screen during the climax, fading earlier kills the parallax (you can't perceive depth on an invisible layer).

Phase 4 Seam: Cursor-Tracked Typing Inside the Already-Panned Strip

This is the joint that the rule alone can't solve. camera-cursor-tracking describes a .world container that translates inside a .viewport. In this scene, the strip is the world — and it's already at x: -VIEWPORT_W from Phase 3. Phase 4's tracking offset has to add to that, not replace it.

The piecewise camera handoff:

// In an onUpdate driven by a typing-progress tween (smooth-slice form):
const charsTyped = Math.floor(progress * FULL_TEXT.length);
const typedWidth = measuredCharOffsets[charsTyped]; // pre-measured per-char left edges
const cursorWorldX = BAR_LEFT_MARGIN + PADDING_LEFT + typedWidth;
const targetScreenX = CURSOR_TARGET_FRACTION * VIEWPORT_W;
const trackingStripX = -VIEWPORT_W + (targetScreenX - cursorWorldX);
const finalStripX = Math.min(STRIP_BASE_X + INITIAL_OFFSET, trackingStripX);
gsap.set(".strip", { x: finalStripX });

Three things matter and the rule does not say them because they only make sense in this composite scene:

• STRIP_BASE_X = -VIEWPORT_W by construction (Phase 3 ended there). The Math.min baseline is that value plus INITIAL_OFFSET (typically 0), not 0.
• Per-character offsets are pre-measured once from the full target string, then stored as an array. Measuring getBoundingClientRect() on a growing text node per frame works but adds layout cost on every seek; the array form is O(1) per frame.
• Math.min (not an if branch). The handoff between "static" and "tracking" is mathematically continuous: while the cursor is left of the target screen X, trackingStripX is less negative than the baseline, so Math.min returns the baseline. The instant the cursor crosses, trackingStripX overtakes it and tracking begins — no jump. An if (charsTyped > threshold) branch will visibly snap on the boundary character.

The bar's pixel width must be pre-allocated from a real font measurement before the timeline registers, so the typing doesn't reflow the bar (which would invalidate measuredCharOffsets):

const probe = document.createElement("span");
probe.style.cssText =
  "position:absolute; left:-99999px; white-space:pre; " +
  `font: ${BAR_FONT_WEIGHT} ${BAR_FONT_SIZE}px ${BAR_FONT_STACK};`;
probe.textContent = FULL_TEXT;
document.body.appendChild(probe);
const fullTextWidth = probe.getBoundingClientRect().width;
probe.remove();
document.querySelector(".shot2-bar").style.width =
  PADDING_LEFT + fullTextWidth + CURSOR_VIS_W + PADDING_RIGHT + "px";

Build the timeline synchronously without a document.fonts.ready gate — that gate causes worker-race flicker on parallel-frame renders. See camera-cursor-tracking for the rationale; this is a hard constraint inherited from that rule. Fallback-font measurement error of a few percent is recoverable; missing timeline registration is not.

If the typing finishes before TOTAL_DURATION, extend the dwell with the rule's GSAP-driven finite-yoyo cursor blink so the GSAP timeline and the root composition's data-duration end together. CSS @keyframes blink infinite will flicker non-deterministically under HF's seek-by-frame.

Key Values to Choose (Not Already in the Rules)

Only values specific to this blueprint below; standard parameters (FLIP_DUR, FLIP_STAGGER, CURSOR_TARGET_FRACTION, BAR_FONT_SIZE, etc.) live in the referenced rules.

• VIEWPORT_W / VIEWPORT_H: must equal the scene root's data-width / data-height and are the per-shot width on the strip. Any mismatch makes the pan over- or under-shoot by exactly that delta.
• PARALLAX_DIST: extra pixels Shot 1 content travels beyond the strip. 15–25% of VIEWPORT_W reads as cinematic depth; over 30% feels like Shot 1 is being thrown away, under 10% reads as no parallax at all.
• FADE_RATIO: 0.3–0.5 of PAN_DUR. Shot 1's opacity reaches 0 at this fraction — fade later and stale content sits on the climax; fade earlier and the parallax has nothing visible to move.
• PAN_DUR: 0.5–1.0s. Under 0.4s reads as a whip-pan (disorienting between two distinct shots); over 1.2s drags the bridge.
• ENTRY_SCALE_FROM: 0.7–0.9 on the bar. Smaller exaggerates the landing; the back.out(ENTRY_BOUNCE) ease assumes some headroom, so don't go above 0.95 or the overshoot has nothing to do.
• STATIC_WEIGHT vs ACCENT_WEIGHT: discrete font weights, but with ACCENT_WEIGHT > STATIC_WEIGHT so the accent word reads as dominant even before it decodes. The decode then confirms a hierarchy the eye already saw — pleasant, not surprising.
• BAR_LEFT_MARGIN: 40–120 px from the left edge of Shot 2. This is where the empty bar sits before tracking starts; pick it visually, the Phase 4 math compensates for whatever you choose.
• INITIAL_OFFSET: usually 0 (bar sits where BAR_LEFT_MARGIN puts it). Non-zero values pre-shift the bar in screen space if the bar needs to feel "already mid-frame" at the start of typing.

Critical Constraints (ordered by failure frequency)

• Pan ease is power3.inOut or power2.out, never back.out — overshoot on the strip reads as a UI menu, not a camera. Reserve back.out for .shot2-bar entry inside Shot 2.
• Phase 4 uses Math.min, not an if branch — the static→tracking handoff must be mathematically continuous, or the camera snaps on the boundary character.
• Pre-allocate the bar's width from a real font probe before timeline registration — letting the bar grow with the typed text invalidates the per-character offset array and the cursor falls behind by ~1 character.
• Build the timeline synchronously, no document.fonts.ready gate — see camera-cursor-tracking constraints; worker-race flicker is unacceptable.
• STRIP_BASE_X = -VIEWPORT_W is the baseline for Phase 4, not 0 — Phase 3 ended the strip there. Forgetting this resets the camera to Shot 1 the instant typing starts.
• .shot { width: VIEWPORT_W; flex-shrink: 0 } — without flex-shrink: 0, flex compresses both shots into one viewport, pan distance becomes wrong, parallax silently breaks.
• Cursor blink via finite GSAP yoyo, not CSS @keyframes blink infinite — CSS animation clocks don't sync with HF's per-frame seek.
• Phase 1 → Phase 2: no gap; Phase 2 → Phase 3: ≥ 0.2s; Phase 3 → Phase 4: ≥ 0.15s — see Phase Timing for the per-gap rationale.
• Three concurrent tweens in Phase 3 must share PAN_DUR — pan, parallax, and Shot 2 entry are read as one cinematic event; differing durations decouple them visually.

Spring → Ease Selection

Four phases, four feels. The complete spring → ease mapping table lives in hyperframes-animation/SKILL.md; this blueprint's defaults:

• Phase 1 settle → power2.out
• Phase 2 character flip → back.out(FLIP_BOUNCE) (rule default)
• Phase 3 camera pan + parallax + Shot 1 fade → power3.inOut (pan/parallax), power2.out (fade)
• Phase 3 Shot 2 landing → back.out(ENTRY_BOUNCE) (mild overshoot)
• Phase 4 typing driver → "none" (linear); camera tracking driven by gsap.set in onUpdate, no ease

Golden Sample

• concept-demo-decode-pan.html — runnable composition with concrete values for every named constant above. Single paused GSAP timeline drives all four phases; the strip's x is shared between Phase 3's pan tween and Phase 4's gsap.set cursor tracking. Run it first, then change values — far faster than building from scratch.