Demo videos for Chrome extension projects, built from your code

Why Chrome extension teams make product videos

A code folder can give a product video context for extension popups, settings and browser workflows. DemoVexa is not a framework-specific parser or a Chrome extension plugin. It reads the code and workspace information to help an AI draft a story and recreate UI scenes; you check the result against the running product.

From project folder to video

• Point Workspace settings → App & docs to the project folder on this computer. Clone a repository first if it only exists online.
• Add a how-to guide, choose a video type and describe the audience and workflow.
• Review and edit the brief and script; select AI narration, your own recording or captions with music.
• Review the planned scenes, approve the build, then check the preview and render formats included in your plan.

What to provide for this project

Include the extension manifest and the popup, options or side-panel code for the task. Explain the browser context and permission prompts viewers should expect. DemoVexa reads code as it exists locally and does not change it. The accuracy of recreated screens depends on the code, guides and product context available; no framework-specific route or component extraction is promised.

Before building, confirm the selected folder represents the product users interact with. Remove credentials and customer data, then compare the preview with the running product before export.

• How DemoVexa uses app code and docs

Prepare a reviewable Chrome extension example

Before selecting the folder, trace the user-facing path from its entry point to the screen where the task finishes. In a multi-package repository, write down which app owns those screens and whether shared UI lives elsewhere; select the product app and provide the relevant guide so the task is clear. A repository with only a library, API or build configuration may need a website or user guide as additional context.

Give the reviewer a short checklist with the expected starting state, any role or plan prerequisite, and the visible result. Compare the preview with the running product at the same code revision. If a screen is missing or simplified, correct the story or scene before export instead of implying the recreation is an exact capture. Keep the branch or version identifier with the approved video so a later reviewer can tell which interface it represents.

Worked story: a user saving the current page to a reading list

Use a fictional product and sample data. Open on the browser page and extension popup, then show the viewer adding a tag and saving the item. Close on a confirmation in the popup or list. This is a planning example, not a customer story or a claim that DemoVexa can inspect a live production account.

Keep each scene tied to a real UI state and a sentence in the narration. If the task branches, show the route most users follow and link to written help for exceptions instead of cramming every path into one clip.

• Turn a cloned repository into a video
• Prepare app code and documentation

Review questions for this stack

• Show the browser context and explain any permissions the extension requests; use a page safe to share.
• Can a viewer identify the starting state without seeing an internal loading screen or developer-only panel?
• Do the sample names, permissions, dates and outcomes match the current product behavior?
• Does each aspect ratio keep the important controls readable? Preview each composition separately.

Choose a useful first video

Start with a workflow that demonstrates one capability in extension popups, settings and browser workflows, rather than trying to explain the architecture of the whole project. The best first example has a recognizable starting screen, one decision or action, and a result a viewer can verify. For a developer-facing product, include the prerequisite and a safe sample value; for a customer workflow, make the sample account and permission level explicit.

If the chosen task depends on an external service, device permission or environment setting, decide whether the video should show that setup or begin after it. State the boundary in narration and supporting copy. This keeps the demo useful to the intended viewer without suggesting that DemoVexa executes the app, validates integrations or captures a live session.