What Is a FoxChat Walkthrough?

A walkthrough is the smallest unit of guided experience FoxChat produces. Two or more steps, each step a region on a page plus a sentence of narration, replayed as an overlay on the live page itself.

If you've ever recorded a screen-capture video to show someone how to use a feature, you already understand the problem a walkthrough solves — just with a different output. A walkthrough is what you wish a screen recording could be: searchable, translatable, edge-resilient, and never out of date.

The shape of a walkthrough

A FoxChat walkthrough has three parts:

• Steps. Each step is a region on the page (a button, a form field, a section, an entire dashboard tile). The recorder captures seven stable identifiers per step — CSS selector, ARIA label, ARIA role, data attributes, XPath, surrounding text, and a relative position hint — so the runtime can find that region again later even if the host site changes.
• Narration. Each step has a short text description that visitors see during playback. Optionally, that narration can be voiced — the recorder can capture spoken audio per step, or a speech synthesis voice can read the text on the fly.
• Order. Steps play in sequence, with prev/next/replay/restart controls. Visitors can jump around. The walkthrough doesn't force a linear path.

Walkthrough versus screen recording

The temptation is to compare walkthroughs to Loom, Veed, or any of the screen-capture tools. They look similar in the demo, but they are structurally different. The differences matter for production use:

• A screen recording is pixels. A walkthrough is structured data. When your UI ships a redesign, the screen recording is now wrong — the buttons are in different places. The walkthrough finds the new locations because it captured selectors, not pixel coordinates.
• A screen recording is opaque. A walkthrough is searchable: visitors can scrub through the narration text to jump to the part they want. Search engines can index the text, too.
• A screen recording is in one language. A walkthrough's narration is text, so it can be translated. The runtime swaps the captions at playback time based on the visitor's preferred language.
• A screen recording is heavy. A walkthrough is a JSON document plus a small runtime — it loads in tens of kilobytes, not megabytes.

Walkthrough versus tooltip tour

The other natural comparison is to product-tour libraries like Shepherd, Intro.js, or in-product tools that ship "click here next" tooltips. These are closer to walkthroughs in shape, but they have a different lifecycle:

• Tooltip tours are authored in code. A developer writes JavaScript to define each step's selector and copy. When the marketing team wants to update the copy, they file a ticket. With FoxChat, the person who recorded the walkthrough can update the copy by editing the step in the dashboard — no deploy.
• Tooltip tours break silently. When the host site renames a class, the tooltip silently points to the wrong element or to nothing. FoxChat's seven-identifier fallback chain explicitly tries alternatives and reports when a step's element cannot be found at all.
• Tooltip tours are linear. They march through their steps and end. Walkthroughs are scrubbable; visitors can jump back, replay a step, or restart from the beginning.

Where walkthroughs live

Once recorded, a walkthrough has three publishable surfaces:

• The standalone embed page at app.getfoxchat.com/embed/<walkthrough_id> — full-fidelity player with optional background music and lead-modal end screen.
• An iframe embed on your own site — pasted into a help article, a blog post, or a product page.
• A bookmarklet replay on the original site — the visitor clicks a bookmarklet on your live site and the walkthrough overlays the real product. See playing back walkthroughs.

See sharing and embedding for the full URL and embed-code options.

How walkthroughs get recorded

Two paths:

• The Chrome extension — smoothest path on Chromium browsers, supports multi-page recording across navigations, supports screenshot capture. See recording from the extension.
• The bookmarklet — works on any browser with a bookmarks bar, no install required. Single-page only. See recording from the bookmarklet.

What walkthroughs are good for

A few production patterns we see:

• First-time setup tours. A new user lands in your dashboard. The proactive trigger fires a walkthrough showing them the three things they need to set up before the product is useful. Visitors finish the tour with the right configuration in place; you skip the support ticket.
• Feature announcements. You ship a new section. Instead of writing a blog post no one reads, record a 60-second walkthrough that highlights the new section in context. Embed it on the changelog page; share the URL in your release-note email.
• Async product reviews. A teammate asks "how do I send a campaign in our tool?" You record a walkthrough on your live account, share the bookmarklet, they replay it on their account. Same UI, real data, no screen-share scheduled.
• Bug repros. Customer reports a bug. Customer-success records a walkthrough of the repro path. Engineering replays it on their staging environment and sees exactly which steps trigger the bug.
• Sales demos. Pre-record the standard demo path as a walkthrough. Send the share URL to a prospect who couldn't make the live call. They get the same explanation, on their own schedule, with searchable narration.

What walkthroughs are not good for

Walkthroughs are step-by-step. They are not great for:

• Continuous animation or video content. If the thing you want to explain is "watch this animation play," record a screen capture instead.
• Multi-screen coordinated demos. Walkthroughs handle multi-page recording (with the extension), but switching between desktop and mobile views in the same walkthrough is awkward. Use a video for cross-device demos.
• One-off explanations of a single screen. A walkthrough needs at least two steps. For a single thing to point at, a tooltip in your chat widget is faster to set up.