dragon-iso/PRODUCT.md

PRODUCT.md — TeamsISO

Register

Product. This is a tool, not a destination. The design serves the operator running a live broadcast. The UI is judged by how invisible it gets once the show is rolling.

Product purpose

TeamsISO is a per-participant NDI ISO controller for Microsoft Teams. It sits between Teams' raw NDI broadcast output and a live-production switcher (vMix, OBS, Resolve, Ross, hardware capture), and does three things:

1. Routes each guest as a clean, individually-addressable, normalized NDI source (consistent framerate, resolution, aspect, audio routing — regardless of what each participant's webcam is doing).
2. Records every active ISO to disk simultaneously — raw BGRA + manifest
   • ffmpeg convert script — so post-production gets a per-guest archive ready to cut from.
3. Orchestrates Teams itself — launch/hide Teams windows, drive in-call controls (mute, camera, share, leave, raise hand, quick-join) via UIAutomation, so the operator never has to alt-tab away from the routing table while the show is live.

External control surface (REST + WebSocket + OSC on localhost) lets a Companion / Stream Deck / TouchOSC controller drive routing remotely.

Users — the primary persona

Solo operator. One person, one Windows laptop or desk machine, often running the show alone from a hotel room, conference green room, or home studio. Picture them at 1:50am, twenty minutes before a live international broadcast, ambient room lights down, the Teams call already started, four guests joining staggered over the next ten minutes. They need to:

• See which participants are present, online, and producing NDI signal.
• Toggle each one's ISO on as they join.
• Confirm at a glance that recording is live, the disk has room, and the control surface is reachable.
• Drop a marker if the host says something quotable.
• Mute themselves without alt-tabbing.

If the UI demands more than a glance for any of those, the show suffers.

Secondary personas (informed, not designed-for)

• TD at a broadcast desk — multi-monitor, may use the OSC bridge to a hardware control surface. Can tolerate a denser layout because their eyes aren't the only thing on the surface.
• Producer monitoring — glances occasionally, mostly hands-off. Will see this app over someone's shoulder; first read matters.
• IT/AV admin — installs it once, tunes config, walks away. Needs settings to be findable, not present-at-all-times.

The design optimizes for the solo operator. Everyone else is downstream.

Brand

Wild Dragon LLC. Reference: wilddragon.net.

Palette anchors:

• Canvas: near-black (#0A0A0A)
• Primary accent: cyan (#97EDF0)
• Secondary blue: (#9AE0FD)
• Coral (error / destructive): (#FB819C)
• Earth (warning): (#423825)

Typography:

• Sans: Inter (variable, bundled as a resource — not assumed installed).
• Mono: JetBrains Mono (also bundled).

The brand carries the surface but doesn't shout. Wild Dragon's authority is in the restraint, not the saturation.

Voice and tone

Operator-first, terse, broadcaster-native. The UI talks like a confident peer, not a Slack bot.

• "Stop all" not "Are you sure you want to stop all ISOs?"
• "Disk low — 8.3 GB" not "Heads up! Your disk space is running low."
• "Joined call · 4 guests" not "You have successfully joined a Teams meeting!"
• Numbers carry their unit, no sentence wraps them.
• Never apologetic. Never bubbly. Never "Let's get started!"

When something goes wrong, name it: "NDI receiver dropped — restarting" beats "Something went wrong, please try again."

Strategic principles

These are the design's load-bearing commitments. Any choice that contradicts one of these is wrong, even if it would otherwise be pretty.

1. One operator, one screen, one show.

The design is for someone running a live broadcast alone. Their attention budget for chrome is roughly zero. Anything that's not the participants table should fade until it's needed.

2. The participants table IS the product.

Everything else is support staff. Routing toggles, ISO state, and per-guest signal health get the real estate, the contrast, and the typographic hierarchy.

3. Progressive disclosure, not progressive density.

The current GUI's failure mode is "every feature gets its own visible button." The redesign's failure mode would be the opposite — burying important things in menus. The discipline: surface the half-dozen actions an operator needs mid-show; hide setup, presets, control-surface config, and exotic options behind purposeful entry points.

4. At-a-glance status is sacred.

Recording state, disk health, control-surface reachability, session timer, NDI signal-per-participant — these are the operator's situational awareness. They must be readable in peripheral vision, in one place, without scanning.

5. Confident neutrality over decorative warmth.

This is a broadcast tool. It looks like one. No empty-state mascots, no illustrated onboarding cards, no celebratory toasts. Restraint is the brand.

Anti-references — what this is NOT

The "vibe-coded GUI" failure mode is the enemy. The redesign should never read as AI-generated. Concretely, this means none of:

• Generic SaaS dashboard. No "hero metric + supporting stats + gradient accent" cards. No "icon + heading + body text" card grids.
• Cards-in-a-grid template. Same-sized cards repeated endlessly is the defining LLM-design tell. If a layout would benefit from cards-in-a-grid, it benefits more from a table.
• Card-with-icon-and-text rows. The in-call control bar's current "icon + label" buttons (Mute / Camera / Share / Marker / Notes / Leave) read AI-generated. The redesign uses iconography differently.
• Zoom pastel. Soft purples, friendly mint greens, rounded everything, Inter-at-low-weight.
• Skeuomorphic broadcast hardware. No woodgrain, no chrome bezels, no fake LCD readouts, no metallic gradients. Wild Dragon's confidence is in flat surfaces with real typography.
• Tour-everything onboarding. No "Let's get started!" wizards with cute copy. The OnboardingWindow exists for first-launch config, not pageantry.
• Modal-as-first-thought. Settings, presets, help all currently live in modals; some should be drawers or inline-progressive. Modal is a last resort.

Technical constraints (informing design)

• Windows-only (Teams' NDI is Windows-only anyway).
• WinUI 3 / Windows App SDK is the new frontend target.
• Engine layer (.NET 8) is preserved verbatim — view-model surface is the swap boundary.
• Bundled fonts via WinUI 3's FontFamily packaging (the WPF pack://...#Inter resource URI doesn't translate; needs migration).
• MSIX-signed installer is on the v1.0 path; the new shell needs to package cleanly through that pipeline.
• The external control surface (REST/WebSocket on :9755, OSC on :9000) must not regress — its HTML control panel at /ui is a separate design surface but shares brand tokens.

What "done" looks like

The redesign is finished when:

1. A first-time operator can launch TeamsISO, join a Teams meeting, and route their first ISO without reading documentation.
2. A returning operator at 1:50am can find the four things they need (participant signal · ISO toggle · recording state · disk free) in under half a second of glance.
3. Nothing on the surface reads as AI-generated. Show this to a working broadcast engineer and they say "someone who knows the job built this."
4. The design system is documented in DESIGN.md tightly enough that a future contributor can add a new view that looks like it belongs.