GitHub user xuang7 created a discussion: Proposal: Automated operator-demo video generator
### Motivation Texera has around 160 operators, and most of them do not have a demo. The current operator descriptions are often limited, so users may still be unsure how to configure or use an operator in practice. Recording a video for every operator manually does not scale. This proposal introduces a Playwright-based tool that automatically generates a short sample video for each operator, so operators can include an up-to-date example of how they are used. These videos are not intended to be detailed tutorials. Instead, each video provides a concise example showing: - what users are expected to enter in the operator form, - how the operator is added to a workflow, - and what result users can expect after running it. As a side benefit, generating the videos exercises the full operator workflow end to end: logging in, creating a workflow, dragging an operator onto the canvas, filling in its properties, running the workflow, and viewing the result. This can also provide end-to-end coverage for common operator interactions. ### Generation Pipeline A developer can ask an agent to recommend sample field values for an operator based on a given dataset. The recommended values are then reviewed and stored as configuration data. The remaining generation is deterministic. Each operator group has a defined script template that encodes how operators in that group are demoed: which sample workflow to load, where to drag the operator and how to connect it, and whether a dataset needs to be selected. OperatorScriptGenerator picks the template by the operator's group, fills in the operator's name/type and its field values from operator-field-values.json, and emits the per-operator script. <img width="732" height="610" alt="architecture-docs" src="https://github.com/user-attachments/assets/f4e06d19-c175-405b-8104-3bf0e1b5da2c"; /> Sample video: [line-chart_demo.webm](https://github.com/user-attachments/assets/4e184a50-0f68-4beb-a5bb-25f63e7b7681) ### Rollout plan Horizontal split by code layer into ~10 small, independently-compiling PRs, ordered along the demo flow (frontend testids, flow setup, login/navigation, drag, fill, run, dataset, config framework, demo data, generator+entry). Each PR compiles on its own; only the last wires the entry point so the tool runs. ### Maintenance Principle A key goal is to keep this process lightweight and avoid turning operator demo generation into an additional maintenance burden. Operator authors should only need to provide or update the sample field values required for their operators. They should not be expected to maintain Playwright scripts or video-generation infrastructure directly. Shared controllers and generation logic should be maintained centrally. When UI changes affect multiple operator demos, the corresponding updates should be made once in the shared controller layer rather than separately for every operator. Video regeneration should also be an occasional release task rather than a required step for every operator change or pull request. #### Maintenance Model | Role | Responsibility | |---|---| | **Operator authors** | Provide and validate the recommended sample values for their operators. | | **Tool maintainers** | Maintain the shared Playwright controllers, script generator, and generation infrastructure. | | **Regeneration** | A maintainer, possibly the release manager, runs a full regeneration before major releases. | | **Hosting** | The generated videos are published publicly on YouTube. | ### Limitations Requires a full running stack: Generating or regenerating videos requires a live Texera deployment, including the backend, frontend, seeded sample datasets, Playwright, and Chromium. This is not a lightweight process and cannot run in a minimal CI environment. Playwright flows are timing-sensitive: End-to-end browser flows may occasionally fail because of timing issues rather than actual regressions. A retry or tolerance strategy may therefore be needed if these flows are used in automated checks. UI coupling is reduced but not eliminated: The controllers rely on stable data-testid attributes where possible. However, some interactions still depend on ng-zorro component classes or canvas geometry. Certain elements rendered by the component library, such as dropdown popups, cannot easily be assigned test IDs. As a result, frontend or component-library changes may still break the generation flow and require updates to the shared controllers. ### Open Questions 1. Should operator authors only maintain sample values and validate the generated result? 2. Who should own the shared controllers when UI changes affect the generation flow? 3. Should generation remain a best-effort maintenance task and therefore not block a release? 4. How much should video quality matter? The current default datasets and workflows are intentionally kept simple, but this may produce outputs whose colors, scales, or visual appearance are not always intuitive. Should we invest additional effort in improving the sample data and visualization settings for presentation quality? Please feel free to share any thoughts, concerns, or suggestions. Thank you. GitHub link: https://github.com/apache/texera/discussions/6871 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
