Direct AI-driven product demos for Phoenix apps, right from your Tidewave Web tab.

DemoDirector gives an AI agent (or, eventually, a saved script) the seams to drive a Phoenix LiveView application as a guided tour: subtitled explanations appear in an overlay, the next element to interact with is highlighted, typing is slowed enough to read, and selectors stay stable via the data-demo-id convention.

Concept

The package is intentionally small. It does not run demos itself — it produces JavaScript strings that an agent passes to Tidewave's browser_eval (or any equivalent in-browser evaluator), plus HEEx components and JS/CSS that render the demo overlay in the page.

Two layers:

1. Top-level helpers in this module (subtitle/1, highlight/1, fill/2, fill_typed/3, click/1, wait/1) return JS source strings. The agent drives the demo by emitting them in sequence.
2. Overlay components in DemoDirector.Components render the subtitle bar and highlight ring. Apps mount these once on a layout.

Quick start

# In your layout (Phoenix.Component or LiveView):
import DemoDirector.Components

~H"""
<.demo_director_overlay />
"""

# In your HEEx templates, mark interactive elements:
import DemoDirector.HEEx

~H"""
<button {demo_id("save-prescription")}>Save</button>
"""

# Then the agent emits, in sequence, things like:
DemoDirector.subtitle("First we'll add a diagnosis.")
DemoDirector.highlight("save-prescription")
DemoDirector.fill_typed("notes", "Patient stable.")
DemoDirector.click("save-prescription")

Each return value is a JS string. The agent passes it to browser.eval(...) (Tidewave) or any evaluator with a JavaScript execution context for the page.

Selectors

All helpers default to data-demo-id lookups. To target an element the LiveView source doesn't yet expose, the agent should ask before inventing a CSS selector — fragile selectors (:nth-child, deep descendant chains) are exactly what data-demo-id exists to avoid.