fm-rds-tx/docs/ui-flow-view-sollmodell.md

UI-Sollmodell – ferrite.fm Signal Flow View

Status: Entwurf / Arbeitsgrundlage
Zweck: Neuer zusätzlicher UI-View neben der bestehenden Control-Plane-Oberfläche
Arbeitsname: Flow View

---

1. Zielbild

Der neue View soll nicht die bestehende UI sofort ersetzen, sondern eine zweite, domänengerechtere Hauptansicht für professionelle Broadcast- und Signalpfad-Arbeit liefern.

Die Grundidee:

• Statt primär Formulare, Panels und technische Gruppierungen zu zeigen, visualisiert der View den realen Signalfluss der Applikation.
• Das UI wird damit näher an Broadcast-, Routing-, Audio- und DSP-Systemen.
• Der Nutzer soll auf einen Blick sehen:
  • wo sich das Signal gerade befindet,
  • welche Stufe gesund / degradiert / fehlerhaft / inaktiv ist,
  • welches Modul welchen Einfluss auf das On-Air-Signal hat,
  • wo eine Störung tatsächlich sitzt,
  • und wo man für Eingriffe klicken muss.

Kurzform: Weniger Settings-App, mehr Signal- und Sendeweg-Konsole.

---

2. Produktprinzipien

2.1 Operator-first

Der View muss innerhalb von 1–2 Sekunden lesbar sein. Keine dekorative Technikgrafik, kein animiertes Spielzeug, kein “Dashboard um des Dashboards willen”.

2.2 Systemmodell statt Menüstruktur

Die Oberfläche bildet nicht zuerst Menüpunkte ab, sondern die tatsächliche Kette: Input → Buffer/Ingest → Audio → Processing → Stereo/RDS/MPX → TX

2.3 Status ist primär, Settings sekundär

Die erste Funktion des Views ist Verstehen und Überwachen. Die zweite Funktion ist Eingreifen. Darum gilt:

• Farbe und Form zeigen Zustand.
• Hover erklärt.
• Click öffnet Steuerung.

2.4 Bestehende UI bleibt erhalten

Die aktuelle tab-basierte Oberfläche bleibt vorerst als:

• Detailansicht
• Fallback
• Vollkonfigurationsraum
• Diagnose-/Engineering-Oberfläche

Der neue Flow View ist also ein zusätzlicher View, kein sofortiger kompletter Ersatz.

---

3. Hauptnutzen des Views

Der View soll drei Dinge gleichzeitig leisten:

1. Observability
   Wo steht das System? Welche Stufe ist gesund? Was ist degradet? Wo liegt der Fehler?

2. Navigation
   Klick auf ein Modul führt direkt zur passenden Steuerung, statt Tabs/Panels suchen zu müssen.

3. Control
   Häufige und domänennah passende Eingriffe können direkt am jeweiligen Modul stattfinden.

---

4. Platz im Produkt

Top-Level-Position

Empfohlene Tabs / Hauptviews:

• Flow
• Control
• Diagnostics
• Activity

Dabei gilt:

• Flow = Hauptansicht für Operatoren und für systemisches Verständnis
• Control = Form-/Panel-basierte Bearbeitung und Vollkonfiguration
• Diagnostics = tiefe Runtime-/Health-/Audit-Ansicht
• Activity = Logs / Historie

Der neue View soll also idealerweise als erster oder linker Haupttab erscheinen.

---

5. Grundlayout des Flow Views

5.1 Grundstruktur

Der View besteht aus vier Zonen:

A. Top Status Bar

Persistente Betriebsleiste mit:

• Markenname ferrite.fm
• TX-Status (ON AIR, OFF AIR, DEGRADED, FAULT)
• Frequency (Applied / Target)
• Connection / Control-Plane-Status
• Last issue / active alarm
• Emergency Actions (Stop TX, Reset Fault)

B. Horizontale Signalfluss-Zeile

Die zentrale Fläche des Views. Hier liegen die Module als horizontale Pipeline mit Verbindungsstrecken dazwischen.

C. Detail / Popover-Ebene

Nicht dauerhaft offen. Öffnet sich:

• per Hover als kompakte Statusblase
• per Klick als interaktiver Popover / Inspector

D. Optionaler Bottom Strip / Runtime Summary

Schmale sekundäre Leiste für:

• aktive Warnings
• Queue Health
• Ingest state
• last change
• runtime age

---

6. Die Module im Signalfluss

Der Flow View soll echte, betrieblich relevante Knoten zeigen. Keine dekorativen Zwischenboxen.

Empfohlene Basiskette:

1. Source
2. Ingest / Buffer
3. Audio
4. Processing
5. Stereo
6. RDS
7. Composite / MPX
8. TX / RF

6.1 Source

Bedeutung: Ursprungsquelle des Programmsignals.

Mögliche Zustände:

• no source / idle
• connected
• reconnecting
• missing
• blocked

Beispiele für Daten:

• ingest.kind
• active origin / URL / stream name
• stream title (falls relevant)
• transport / codec
• connected / disconnected

Popover-Steuerung:

• Source kind
• Source URL / stream target
• Decoder mode
• grundlegende source-spezifische Optionen
• Link zur vollen Ingest-Konfiguration

6.2 Ingest / Buffer

Bedeutung: Annahme, Vorpufferung, Runtime-Stabilisierung.

Mögliche Zustände:

• healthy
• low buffer
• write blocked
• reconnecting
• stalled
• critical

Beispiele für Daten:

• prebuffer state
• buffered seconds
• reconnect count
• source state
• runtime state
• last chunk time

Popover-Steuerung:

• Prebuffer
• reconnect settings
• ggf. source-related runtime controls
• Link zu tiefer Diagnose

6.3 Audio

Bedeutung: Programmaudio-Grundparameter vor Stereo-/MPX-Pfaden.

Mögliche Zustände:

• active
• tone mode active
• muted / no input
• warning if gain/levels suspicious

Beispiele für Daten:

• input gain
• tone left / right / amplitude
• source activity summary

Popover-Steuerung:

• input gain
• tone controls
• ggf. source audio mode

6.4 Processing

Bedeutung: Eingriffe in Klangbearbeitung und Compliance-nahe Audio-/Processing-Stufen.

Mögliche Zustände:

• healthy
• limiter active
• compliance pending restart
• clipper active
• warning if inconsistent config/runtime impact exists

Beispiele für Daten:

• limiter enabled / ceiling
• pre-emphasis
• BS.412 enabled
• composite clipper enabled / iterations / knee / lookahead

Popover-Steuerung:

• limiter
• ceiling
• pre-emphasis
• compliance settings
• composite clipper settings

6.5 Stereo

Bedeutung: Stereo-Multiplex-Aufbereitung.

Mögliche Zustände:

• stereo on
• mono / stereo disabled
• pilot warning
• degraded if stereo mode or pilot abnormal

Beispiele für Daten:

• stereo enabled
• stereo mode
• pilot level

Popover-Steuerung:

• stereo on/off
• stereo mode
• pilot level

6.6 RDS

Bedeutung: Metadaten- und RDS-Subsystem.

Mögliche Zustände:

• active
• disabled
• active text relay
• degraded if metadata mismatch / relay issue / config inconsistency

Beispiele für Daten:

• RDS enabled
• PI / PTY
• PS / RadioText
• TP / TA
• active on-air text
• RDS2 summary if enabled

Popover-Steuerung:

• enable/disable
• PI / PTY
• PS / RT
• TP / TA
• RDS features shortcut

6.7 Composite / MPX

Bedeutung: Endstufe des zusammengesetzten Multiplexsignals vor TX.

Mögliche Zustände:

• healthy
• high injection
• compliance risk
• degraded if MPX gain / injection values suspicious

Beispiele für Daten:

• pilot level
• RDS injection
• MPX gain
• clipper state
• BS.412 state

Popover-Steuerung:

• pilot
• RDS injection
• MPX gain
• clipper toggle shortcut

6.8 TX / RF

Bedeutung: Ausgang / SDR / Sendezustand.

Mögliche Zustände:

• on air
• idle
• arming n- degraded
• muted
• faulted
• stopping

Beispiele für Daten:

• applied frequency
• desired frequency
• runtime state
• queue health
• underruns
• last fault
• backend / driver

Popover-Steuerung:

• start / stop TX
• reset fault
• frequency
• quick runtime summary

---

7. Statusmodell

Farben und Zustände müssen über alle Module konsistent sein.

7.1 Primäre Modulzustände

• Green → active / healthy / normal
• Amber → degraded / warning / pending / attention needed
• Red → fault / error / blocked / disconnected in fault-relevant stage
• Gray → disabled / bypassed / inactive / not configured
• Blue outline → selected / focused in UI

7.2 Zustandslogik

Nicht jedes Modul nutzt dieselben Regeln, aber dieselbe Farbe bedeutet denselben operativen Charakter.

Beispiele:

• Source disconnected = rot, wenn ingest erwartet wird
• RDS disabled = grau, nicht rot
• TX idle = grau oder neutral, nicht rot
• queue critical = rot
• restart required = amber indicator, aber nicht automatisch roter Modulstatus

7.3 Zusätzliche Marker

Neben der Grundfarbe kann ein Modul kleine sekundäre Marker tragen:

• pending indicator
• restart required
• reload required
• draft exists

Diese Marker sollen aber klein und sekundär bleiben.

---

8. Hover-Verhalten

Hover soll eine kompakte Statusblase öffnen.

Prinzipien

• Schnell erfassbar
• Kein Formular
• Kein Scrollmonster
• Max. 5–7 Zeilen
• Klare Typografie

Inhalt pro Hover-Blase

1. Modulname
2. Zustand in Klartext
3. 2–5 wichtigste Metriken / Werte
4. optional letzter Hinweis / letzter Fehler
5. evtl. Zeitbezug (updated 4s ago)

Beispiel RDS Hover

• RDS
• Status: Active
• PI: BEEF
• PS: FERRITE
• RT: Now playing ...
• TP/TA: off / off
• updated 2s ago

Beispiel TX Hover

• TX / RF
• State: Running
• Applied: 99.5 MHz
• Target: 99.5 MHz
• Queue: normal (67%)
• Underruns: 0
• Runtime age: 18m

---

9. Click-Verhalten / Popover

Ein Klick auf ein Modul öffnet einen Popover / Inspector, nicht sofort ein Fullscreen-Modal.

9.1 Ziel

• Schnell editierbare Kernparameter
• Kontext bleibt sichtbar
• Fokus bleibt auf dem Signalfluss

9.2 Struktur des Popovers

• Modulname + Statuskopf
• kleine Summary
• relevante Einstellfelder
• Apply-/Action-Bereich
• Link / Button zu “Open full controls”

9.3 Regeln

• Nur die wichtigsten Bedienelemente inline
• Tiefe Spezialkonfiguration weiter in der bestehenden Control-View
• Kritische Aktionen klar trennen

Beispiele

TX Popover

• Start TX / Stop TX
• Reset Fault
• Frequency field
• Applied / target summary

RDS Popover

• Enable RDS
• PI
• PTY
• PS
• RT
• TP/TA

Processing Popover

• Limiter on/off
• Ceiling
• Pre-emphasis
• BS.412 on/off
• Composite clipper toggle

---

10. Navigations- und Wechselmodell

Der Flow View soll sich nicht isoliert anfühlen. Jedes Modul kann zusätzlich einen Übergang in die bestehende UI bieten:

• Open full controls
• Open diagnostics
• Open ingest panel
• direkter Link zum entsprechenden Tab bzw. Panel der bestehenden Detail-UI

So wird der Flow View zur Primärnavigation, ohne alles selbst lösen zu müssen.

Festlegung

Popover bleiben Quick Control und sollen bewusst flach bleiben. Für tiefere Arbeit gibt es immer einen direkten Sprung in die bestehende Detail-UI an die passende Stelle.

---

11. Visual Language

11.1 Stilprinzipien

• nüchtern
• präzise
• professionell
• ruhig
• hohe Informationsdichte ohne Chaos

11.2 Look & Feel

• heller bis neutraler Hintergrund bleibt möglich
• weniger Card-Sammlung, mehr zusammenhängende technische Arbeitsfläche
• Module als klar definierte Knoten mit Verbindungslinien
• Verbindungslinien dezent, aber lesbar
• Symbole sachlich und funktional, nicht verspielt

11.3 Symbolik

Jedes Modul erhält ein einfaches, wiedererkennbares Icon, z. B.:

• Source → Stecker / Input / Antenne / Link
• Buffer → Stack / Queue / Reservoir
• Audio → Waveform / Fader
• Processing → Filter / dynamics / knob cluster
• Stereo → linked channels / L-R icon
• RDS → text / metadata / broadcast tag
• Composite → multiplex / spectrum-like icon
• TX → antenna / RF output

Wichtig: Icons unterstützen, ersetzen aber nie die Lesbarkeit.

---

12. Responsive Verhalten

Der View ist primär Desktop-/Operator-first. Mobile ist sekundär, aber nicht ignoriert.

Desktop

• horizontale Kette in einer Zeile
• Popover seitlich / unterhalb des aktiven Moduls

Tablet / kleinere Fenster

• Kette darf umbrechen in 2 Zeilen, aber logisch lesbar bleiben
• Verbindungslogik optisch erhalten

Mobile

• keine ambitionierte Vollsimulation der Horizontalkonsole
• stattdessen vereinfachte vertikale Step-Ansicht
• Hover-Konzept wird zu Tap-Details

---

13. Technische Datenquellen

Der View soll möglichst aus bereits vorhandenen Daten gespeist werden.

Bereits vorhanden / nutzbar

• /status
• /runtime
• /config
• bestehende Draft-/Apply-Logik in ui.html

Erwartete Zuordnung

• Source / Ingest / Buffer ← runtime.ingest, config.ingest
• Audio / Processing / Stereo / RDS / MPX ← config, runtime.engine, teilweise status
• TX / RF ← runtime.engine, runtime.driver, status

Wichtige Designregel

Der View darf zunächst read-mostly + selectively writable sein. Nicht alles muss in Version 1 voll editierbar sein.

---

14. MVP-Scope

Für eine erste brauchbare Version reichen:

Muss enthalten

• neuer Flow-Tab
• horizontale Modulkette
• Statusfarben pro Modul
• Hover-Details pro Modul
• Click öffnet kompakten Popover
• pro Modul 1–3 relevante Kernaktionen
• klare Verbindung zur bestehenden Control-Ansicht

Darf zunächst fehlen

• hochkomplexe Inline-Editoren
• Drag & Drop
• Mini-Sparklines in jedem Modul
• Animationen entlang des Flows
• komplette Mobile-Perfektion

---

15. Anti-Ziele

Der Flow View soll nicht werden:

• eine dekorative Netzwerkgraph-Spielerei
• eine überanimierte “wow”-Fläche
• ein unlesbares Technikposter
• ein Vollersatz für jede Detailkonfiguration in Version 1
• eine Oberfläche, bei der Farbe das einzige Statussignal ist

---

16. Nächste Umsetzungsstufe

Stufe 1 — UX-Skelett

• neuen Tab Flow anlegen
• statische Modulkette rendern
• Icons + Titel + Statusfarben
• ausgewählte Runtime-/Config-Werte anbinden

Stufe 2 — Interaktion

• Hover-Bubbles
• Click-Popover
• Quick actions für TX / RDS / Frequency / Source

Stufe 3 — Integration

• Draft-/Apply-Mechanik für Kernmodule
• Übergänge zu bestehender Detail-UI
• sauberer Pending-/Restart-/Reload-Status

Stufe 4 — Broadcast-Polish

• strengere visuelle Hierarchie
• Alarm-Layer
• optional Operator-/Engineering-Abstufung

---

17. Getroffene Designentscheidungen

17.1 Stereo und RDS

Entscheidung: Stereo und RDS werden als getrennte Knoten dargestellt.

Begründung:

• fachlich klarer
• RDS bleibt als eigenes Broadcast-Subsystem sichtbar
• Fehlerursachen werden präziser lesbar
• passt besser zu einer professionellen Broadcast-/Signalpfad-Sicht

17.2 Composite / MPX

Entscheidung: Composite / MPX wird als eigener Knoten dargestellt.

Begründung:

• Broadcast-technisch zentrale Stufe
• trennt Audio-/Processing-Welt sauber von der Multiplex-/Deviation-Ebene
• macht Pilot, RDS-Injection, MPX Gain und Composite-Verhalten sichtbar an der richtigen Stelle

17.3 Popover-Tiefe

Entscheidung: Popover bleiben Quick Control.

Regel:

• wenige Kernaktionen / Kernfelder direkt im Popover
• keine Vollkonfiguration im Flow View
• tiefe Bearbeitung erfolgt über direkten Link in den passenden Tab bzw. das passende Panel der bestehenden Detail-UI

17.4 Globaler Alarm-Banner

Entscheidung: Ein globaler Alarm-Banner oberhalb des Flows ist sinnvoll, aber nur kontextuell sichtbar.

Regel:

• sichtbar bei aktiven Faults / relevanten Degraded-Zuständen / betrieblich relevanten Warnings
• nicht als permanentes Alarmband
• kompakt, klar, operator-first

17.5 Stil

Entscheidung: Der View wird technisch-klar mit leichter visueller Abstraktion umgesetzt.

Regel:

• echte Modulnamen
• echte Signalpfad-Logik
• präzise Zustände
• nüchterne, moderne technische Konsole statt Spielerei oder retro-technischer Härte

---

18. Festgelegte Architektur für die erste Realisierung

Empfehlung für die erste Realisierung:

• eigener Flow-Tab
• acht klare Knoten
• strikte Statusfarben
• Hover für Status
• Click für kleine Popover
• Popover als Quick Control
• direkter Link in passende Detail-Tabs/Panels
• globaler Alarm-Banner nur bei Relevanz
• bestehende UI bleibt Vollkonfigurations-/Fallback-Ebene

Festgelegte Modulkette

• Source
• Ingest / Buffer
• Audio
• Processing
• Stereo
• RDS
• Composite / MPX
• TX / RF

Das ist der pragmatischste Weg zu einer professionelleren Broadcast-Oberfläche, ohne die vorhandene UI sofort wegzuwerfen.

---

19. Konkretes Modul- und Wireframe-Schema

Dieser Abschnitt definiert den ersten baubaren MVP des Flow Views.

19.1 Gesamt-Wireframe

Obere Leiste

Von links nach rechts:

1. ferrite.fm Wortmarke / Produktname
2. globaler TX-Zustand
3. Applied / Target Frequency
4. Source Summary
5. Active Alarm / Warning Banner (nur wenn relevant)
6. Emergency Actions (Stop TX, Reset Fault)

Flow-Zeile

Eine horizontale Kette mit 8 Modulknoten. Jeder Knoten besitzt:

• Icon
• Namen
• Statusfarbe
• 1 kurze Sekundärzeile
• Hover-Bubble
• Click-Popover

Verbindungssegmente

Zwischen den Knoten liegen simple horizontale Linien / Segmente. Optional können Segmente dieselbe Statusfarbe wie der nachfolgende Knoten aufnehmen oder neutral bleiben. Für MVP besser neutral und ruhig halten.

Untere Sekundärzone

Schmale Zeile für:

• queue health
• ingest state
• runtime age
• last update

Keine große zweite Dashboard-Wand. Nur kompakte Betriebszusammenfassung.

---

19.2 Knoten-Spezifikation

A. Source

Icon

• Input / link / connector symbol

Primärlabel

• Source

Sekundärzeile

• aktiver Typ, z. B. icecast, srt, aes67, stdin, http-raw, none

Primärstatuslogik

• green → connected / active source
• amber → reconnecting / degraded
• red → source expected but disconnected / failed
• gray → no source / none configured

Hover-Inhalt

• Source kind
• Origin / endpoint / stream name
• Transport / codec (falls verfügbar)
• Connection state
• Reconnect count / last error (falls vorhanden)

Quick-Control-Popover

• source kind (read-only oder einfacher selector nur wenn sinnvoll)
• URL / endpoint (wenn einfache Bearbeitung vertretbar)
• decoder mode (bei icecast)
• reconnect enabled
• Button: Open Input details

Linkziel im Detail-UI

• Tab: Ingest
• Fokus: Ingest Config

---

B. Ingest / Buffer

Icon

• queue / buffer / stacked blocks

Primärlabel

• Ingest / Buffer

Sekundärzeile

• z. B. 1.5s buffered, prebuffering, write blocked, healthy

Primärstatuslogik

• green → healthy ingest runtime
• amber → low buffer / reconnecting / prebuffering / delayed
• red → critical / stalled / write blocked with active fault relevance
• gray → ingest inactive

Hover-Inhalt

• Runtime state
• Buffered seconds
• Prebuffer state
• Last chunk age
• Reconnect count
• Write blocked yes/no

Quick-Control-Popover

• prebuffer ms
• reconnect enabled
• initial/max backoff
• Button: Open Ingest config
• Button: Open Diagnostics

Linkziel im Detail-UI

• Tab: Ingest
• Fokus: Ingest Config

---

C. Audio

Icon

• waveform / fader

Primärlabel

• Audio

Sekundärzeile

• z. B. gain 1.00, tones off, tones active

Primärstatuslogik

• green → active / healthy
• amber → unusual tone mode / suspicious gain / weak signal condition
• red → no usable audio in relevant runtime state
• gray → inactive / no source

Hover-Inhalt

• input gain
• tone left/right
• tone amplitude
• audio activity summary

Quick-Control-Popover

• input gain
• tone left
• tone right
• tone amplitude
• Button: Open Audio controls

Linkziel im Detail-UI

• Tab: TX Control
• Fokus: Audio & Drive

---

D. Processing

Icon

• filter / dynamics / processor block

Primärlabel

• Processing

Sekundärzeile

• z. B. limiter on, pre-emphasis 50µs, BS.412 off

Primärstatuslogik

• green → healthy / nominal
• amber → restart required / compliance attention / unusual setting combination
• red → critical processing/compliance state (nur falls wirklich fault-relevant)
• gray → inactive / bypassed if such mode exists

Hover-Inhalt

• limiter on/off + ceiling
• pre-emphasis
• BS.412 enabled + threshold
• clipper enabled summary

Quick-Control-Popover

• limiter enabled
• limiter ceiling
• pre-emphasis
• BS.412 enabled
• Button: Open Processing controls

Linkziel im Detail-UI

• Tab: TX Control
• Fokus: Audio & Drive oder MPX Compliance

---

E. Stereo

Icon

• linked L/R or stereo channels icon

Primärlabel

• Stereo

Sekundärzeile

• z. B. DSB, stereo on, mono

Primärstatuslogik

• green → stereo enabled and healthy
• amber → non-default mode / pilot attention / pending state
• gray → stereo disabled / mono
• red → only if runtime actually indicates a fault-worthy stereo stage problem

Hover-Inhalt

• stereo enabled
• stereo mode
• pilot level

Quick-Control-Popover

• stereo enabled
• stereo mode
• pilot level
• Button: Open Stereo controls

Linkziel im Detail-UI

• Tab: TX Control
• Fokus: Switches

---

F. RDS

Icon

• metadata / text / radio-data symbol

Primärlabel

• RDS

Sekundärzeile

• z. B. PS FERRITE, RT active, disabled

Primärstatuslogik

• green → enabled and active
• amber → enabled but metadata stale / pending / mixed runtime impact / relay mismatch
• gray → disabled
• red → only if a real operational RDS fault state is surfaced

Hover-Inhalt

• enabled / disabled
• PI
• PTY
• PS
• active RT
• TP / TA
• RDS2 summary if applicable

Quick-Control-Popover

• enable RDS
• PI
• PTY
• PS
• RT
• TP / TA
• Button: Open RDS details

Linkziel im Detail-UI

• Tab: RDS
• Fokus: Station Identity or On-Air Text

---

G. Composite / MPX

Icon

• multiplex / layered-spectrum symbol

Primärlabel

• Composite / MPX

Sekundärzeile

• z. B. pilot 9%, RDS 4%, mpx 1.00

Primärstatuslogik

• green → nominal multiplex state
• amber → high injection / compliance attention / restart pending / unusual MPX values
• red → critical compliance or composite issue if surfaced
• gray → inactive when TX chain inactive

Hover-Inhalt

• pilot level
• RDS injection
• MPX gain
• composite clipper state
• BS.412 state

Quick-Control-Popover

• pilot level
• RDS injection
• MPX gain
• clipper enabled shortcut
• Button: Open MPX controls

Linkziel im Detail-UI

• Tab: TX Control or RDS
• Fokus: MPX Compliance or Injection Levels

---

H. TX / RF

Icon

• antenna / RF output / transmitter symbol

Primärlabel

• TX / RF

Sekundärzeile

• z. B. 99.5 MHz, ON AIR, idle, faulted

Primärstatuslogik

• green → running / on air
• amber → arming / degraded / muted / stopping
• red → faulted
• gray → idle / off air

Hover-Inhalt

• runtime state
• applied frequency
• target frequency
• queue health
• underruns
• backend / driver
• last fault summary

Quick-Control-Popover

• start TX / stop TX
• reset fault
• frequency
• refresh runtime
• Button: Open TX control

Linkziel im Detail-UI

• Tab: Overview or TX Control
• Fokus: Frequency / Hero area

---

19.3 Globale Interaktion

Hover

• Öffnet kompakte Bubble
• bubble schließt automatisch beim Verlassen
• kein interaktives Formular im Hover

Click

• öffnet Popover am Knoten
• nur ein Popover gleichzeitig offen
• Klick außerhalb schließt Popover
• ESC schließt Popover

Statusbanner

• erscheint oberhalb des Flows nur bei Relevanz
• enthält Severity + Kurztext + optionalen Deep-Link

---

19.4 MVP-Bauplan

Phase MVP-1

• statischer Flow-Tab
• acht Knoten
• Statusfarben
• Sekundärzeilen
• read-only Hover-Bubbles

Phase MVP-2

• interaktive Popover
• erste Quick Controls für TX, RDS, Source, Processing
• Deep-Links in bestehende Tabs/Panels

Phase MVP-3

• Draft-/Apply-Anbindung
• konsistente Pending-/Restart-/Reload-Marker
• Alarm-Banner