Was macht Web-Demo-Video?
Wandle eine funktionierende Web-App in ein 20–60 Sekunden langes MP4 um. Der Bildschirm zeigt stets die echte App; Untertitel, Cursor und Effekte werden als Overlays darüber gelegt. Verwende ausschließlich erfundene Daten.
Toolkit: starter/ neben dieser Datei. Kopiere es in das Projekt des Benutzers (z. B. video/), führe dort npm install aus und schreibe Szenenskripte dagegen. Ein funktionierendes Beispiel gibt es im Repository unter examples/sample-tasks/.
1. Wähle zuerst den Stil
| Das Video ist … | Stil | Warum |
|---|---|---|
| Wie man eine Funktion nutzt (Anleitungen, Onboarding, Support-Antworten) | Walkthrough: Zeichne die echte UI beim Klicken auf | Zuschauer kopieren die Schritte, daher müssen sie den echten, ungeschnittenen Ablauf in lesbarem Tempo sehen |
| Warum das Produkt lohnenswert ist (Launch, Homepage, Anzeigen, Übersicht) | Motion Promo: Animation über Screenshots | Zuschauer folgen nicht aktiv mit; das Video muss Aktionen mit Ergebnissen verbinden und die Aufmerksamkeit halten |
Mische die Stile nicht in einem Video. Ein How-to mit fliegenden Objekten ist schwer zu verfolgen; ein Promo aus purer Aufnahme wirkt lang.
Details: Walkthrough in references/walkthrough.md, Motion Promo in references/motion.md.
2. Vor dem Rendern abstimmen
Rendern ist der teure Schritt. Bevor Szenencode geschrieben wird, erstelle ein Storyboard (references/storyboard.md) und hole die Zustimmung des Benutzers zu:
- Stil (Walkthrough oder Promo) und Zielgruppe
- Länge und Anzahl der Szenen
- Ausgabegröße (Standard 2560x1440 bei 30 fps; 1080x1920 für Hochformat)
- Marke: Farben, Schriftart, Logo, Produktname und Wörter, die nicht vorkommen dürfen
- Daten: Welche erfundenen Namen und Zahlen auf dem Bildschirm erscheinen (niemals echte Kunden)
- Voice-Over oder stumm
- Wohin die Datei nach Fertigstellung gehen soll
Ein Storyboard hat eine Motion-Spalte sowie Bildschirm- und Untertitelspalten (Promo), damit jede Szene bewusst eine andere Bewegungsart verwendet.
3. Bauen
Walkthrough
- Überprüfe zuerst den Ablauf: Ein Skript, das ohne Aufzeichnung durchklickt, um Selektoren und Wartezeiten zu korrigieren
- Nimm in Teilen auf (eine Seite oder ein Schritt pro Teil) mit
lib/recorder.mjs, dann füge sie mitconcatPartszusammen - Schreibe Untertitel mit references/copy.md
Motion Promo
- Erfasse jeden UI-Zustand mit
lib/capture.mjs(Screenshots mit 3840 Breite + Elementpositionen) - Komponiere Szenen in Remotion mit
motion/parts.tsx(Kamera, Cursor, Untertitel, Chips, Zahlen-Count-ups) - Überprüfe Standbilder an Schlüsselframes (
remotion still ... --frame=N --scale=0.25) vor einem vollständigen Render
Voice-Over: Kein Tool ist enthalten. Falls der Benutzer eines wünscht, empfehle Gemini 3.1 Flash TTS (gemini-3.1-flash-tts-preview) mit der Charon-Stimme.
4. Vor der Übergabe prüfen
Führe node lib/qa.mjs out/video.mp4 --sheet 16 --end aus und betrachte beide Bilder. Details: references/qa.md.
- Größe, fps und Dauer stimmen mit dem Storyboard überein
- Kein Untertitel abgeschnitten oder die angeklickte Schaltfläche verdeckt
- Kein halb geöffneter Dialog, leeres Bild oder spät ladendes Logo (überprüfe die letzte Sekunde separat)
- Jede animierte Zahl endet auf dem Wert, den der reale Bildschirm anzeigt
- Gib bei der Übergabe an, welche Teile inszenierte Effekte sind (ein fliegendes Dokument, ein Count-up) und welche die tatsächliche Funktionsweise des Produkts zeigen
5. Harte Regeln
- Echte UI, erfundene Daten. Keine echten Kunden-, Personen- oder Firmennamen, IDs, E-Mails oder Zahlen auf dem Bildschirm, in Untertiteln, in Dateinamen oder in der Beschreibung
- Nicht veröffentlichen (YouTube, Social Media, Website) ohne die ausdrückliche Zustimmung des Benutzers für diesen Upload
- Nicht behaupten, was das Produkt nicht tut. Wenn ein Schritt für die Aufnahme vorgetäuscht wird (eine Serverantwort, ein Upload), darf der Untertitel nicht so tun, als sei es automatische Magie
- Behalte die Render-Quellen (Skripte, Storyboard) im Repository; halte MP4s und Screenshots aus Git heraus