A pattern for adding a self-narrating (typed out) guided walkthrough to any HTML/web application. Use this skill whenever the user wants to add a guided demo, auto-narration, self-running presentation, or step-by-step tour to an HTML page, web app, prototype, HTML slide deck, dashboard, or data story.
A pattern for adding a self-narrating (typed out) guided walkthrough to any HTML/web application. Use this skill whenever the user wants to add a guided demo, auto-narration, self-running presentation, or step-by-step tour to an HTML page, web app, prototype, HTML slide deck, dashboard, or data story.
Guided Demo Pattern
Add a self-narrating walkthrough to any HTML/web application. A declarative step array drives a setTimeout loop that toggles CSS classes on DOM elements and writes text character-by-character into a fixed panel. The engine overlays the existing page without modifying its code. When the demo stops, all state resets.
About 100 lines of JS and 30 lines of CSS for the core. Interstitials, speed controls, keyboard shortcuts, and progress bar are optional layering.
Before implementing
Ask the user these questions (skip any already answered in conversation):
What are the sections? Tabs, routes, scroll positions, slide indices? Determines how section switching works.
Framework? Vanilla HTML works directly. React/Vue/Svelte need the engine as a conditional overlay component, and querySelector must run after render.
Presenter talking over it, or self-narrating? Talking over: shorter text, longer pauses. Self-narrating: detailed text, moderate pauses.
Interactive elements to trigger? Map to step actions. Confirm CSS selectors are stable (not framework-generated hashes).
Offline requirement? Keep everything in one file if so. No CDN dependencies without fallbacks.
How many steps? Under 15 for a pitch, 20-30 for a detailed walkthrough. Over 40 loses attention.
Touch device support needed? Most guided demos target desktop/laptop presentation contexts. The narrator panel has on-screen prev/play/next buttons that work on touch, but swipe gestures or mobile-specific layout are rarely needed.
Implementation
Read references/implementation.md for all code snippets (vanilla JS / static HTML). If the target application uses React with React Router, also read references/react-integration.md for React-specific patterns covering stale closures, route navigation timing, and component architecture. For other SPA frameworks (Vue, Svelte, etc.), the same concepts apply (poll for elements after route change, store timer-relevant state outside the reactivity system) but the implementation details differ.
The four required pieces are:
Narrator panel - fixed-position bar with text container and progress bar
Highlight class - outline (not border) with animated glow, no layout shift
Typewriter function - recursive setTimeout, narration text set via textContent (never set user-authored narration via innerHTML), blinking cursor via CSS. The innerHTML = '' clearing before each tick is intentional and safe (no user content involved)
Playback loop - playStep(idx) that switches sections, runs actions, highlights, types, and auto-advances
Step array
The single source of truth. Each step is a plain object:
Properties: section (which view), target (CSS selector or null), text (narrator copy), transition (show interstitial), action/actionTarget (trigger UI change), delay (optional per-step pause override in ms, defaults to PAUSE_MS).
Timing defaults
Constant
Default
When to adjust
TYPE_SPEED
5ms/char
3ms for long text, 15ms for dramatic short statements
PAUSE_MS
3000ms
4-5s if audience reads rather than listens
Speed range
0.5x-2x
Both constants divided by multiplier
Writing narrator copy
The typewriter effect means each word lands individually, so writing style matters:
Short declarative sentences. Each step should make exactly one point.
Conversational tone, present tense. Address the audience directly.
Describe what the element means, not what the UI shows: "This column quantifies the cost impact" not "The cost is shown in this column".
No jargon the audience wouldn't know. Match terminology to the domain, not the implementation.
Under 30 words per step for presenter-led demos, up to 50 for self-narrating.
Keyboard controls
Gate all keyboard capture behind an isActive flag so it does not interfere with normal page interaction. Space = play/pause, arrows = step, M = toggle TTS narration, Escape = exit and reset.
Text-to-speech narration
Browser-native TTS via the speechSynthesis Web Speech API reads each step's narration aloud alongside the typewriter. Include it in every demo but keep it off by default - never speak without explicit user action. The user toggles it with a speaker icon in the control bar and the M key. See references/implementation.md (Text-to-speech narration) for voice selection, the single call site, and cancellation.
Step countdown indicator
A thin bar below the step progress bar fills during the pause after the typewriter finishes, showing time until auto-advance. Include it in every demo. See references/implementation.md (Step countdown indicator) for the CSS-animation approach, placement, and reset via clearAllTimers().
Optional: transition interstitials
Full-screen overlay with cycling status messages between sections. Simulates processing time. Define messages per section in a 2D array. Fade each message, then dismiss overlay via callback.
Optional: step actions
String-matched in executeStep(). Actions run before highlighting because elements inside collapsed panels can't be found by querySelector until the panel is open. Adding a new action is one if block. Keep it simple. Common patterns beyond expand/collapse: expandOne (open one panel, close all siblings - accordion style), call (trigger a named function like requestBriefing()), addClass/removeClass (toggle a CSS class on document.body for global state changes).
Gotchas
These are the failure points that come up repeatedly:
Layout shift: Use outline not border for highlighting. Outline does not affect box model.
Hidden elements: If target is inside a collapsed container, the action must open it first. This is why actions execute before highlighting.
Dynamic selectors: Framework-generated class names (.css-1a2b3c) break between builds. Use data-* attributes or IDs.
Scroll conflicts: scrollIntoView({ block: 'center' }) conflicts with fixed headers/panels. Set scroll-padding-bottom on the scroll container to account for the narrator panel height.
Z-index: Narrator panel at 500+, interstitials at 490, highlighted elements at 2+. Check for conflicts with existing modals or dropdowns.
Cleanup on exit: Reset every piece of state the demo touched: close opened panels, remove highlights, clear timers. Missing cleanup leaves confusing UI state.
Form inputs: If the page has text inputs, textareas, or selects, the keyboard handler must skip them. Otherwise pressing Space in a text field triggers play/pause instead of typing. Check e.target.tagName and bail out for INPUT, TEXTAREA, SELECT.
ES modules: If using <script type="module">, all demo functions called from onclick must be on window.*.
Print: Hide demo panel and interstitial in @media print.
Accessibility: Narrator panel should have role="status" and aria-live="polite". Highlight outlines must meet contrast requirements.
Applicability
Works for: prototypes, PoCs, HTML slide decks, data storytelling dashboards, product demos, workshop facilitation, investor pitches, onboarding walkthroughs.
Does not replace: user testing tools, screen recorders, production onboarding tours (use a tour library with persistence and analytics for those).
For framework apps, mount the demo engine as a conditional overlay component and pass the script array as a prop. For single-file demos, inline everything for offline/USB-stick distribution.
