UI-Sollmodell – Control Plane

Zielbild

Operator-first: Das UI muss schnell erfassbar sein, ohne verschwenderischen Glanz. Klar strukturierte Oberflächen mit nordisch-kühlen Tönen, typografischer Klarheit und ausreichend Weißraum ermöglichen fokussiertes Arbeiten ohne Ablenkung.
Helles Farbschema: Weiß- und Graustufen dominieren, Akzente bleiben zurückhaltend (tiefe Blau- oder Grünwerte für Aktionen/Status). Kein Neon, kein Cyber-Punk-Glanz, keine animierten Nebel.
Vertrauensein: Live-Status & Kontrolle auf einen Blick: Wichtigste Telemetrie und Schalter werden ohne Scrollen sichtbar. Historien und Auditdaten leben in eigenen, abrufbaren Tabs.

Statt des current long-scroll Layouts treten klar abgegrenzte Top-Level-Tabs. Jeder Tab bekommt eine eindeutige Verantwortung.

Zweck: Schnellcheck, ob Sender/Control Plane gesund ist. Live-Hero, Status-Zustand, Aktivitäts-Metriken. Inhalte:

Alles bleibt hier; nichts anderes.

Zweck: Alle live-änderbaren Controls bündeln, damit ein Operator schnell Eingriffe macht. Inhalte:

TX Buttons (Start/Stop/Refresh) + große Hinweisfläche („Danger“-Status nur hier sichtbar, mit klarer Trennung)
Frequency Panel (Slider, Eingabe, Presets, Apply/Reset)
RDS Text Panel (PS/RT, Char-Counter, Presets)
Switches (Stereo, RDS, Limiter)
Optional: Danger Zone (Reset Fault / Hard Refresh) als separater Sub-Panel innerhalb des Tabs

Zweck: Tiefere Einblicke, wenn etwas nicht stimmt. Inhalte:

Health-Dashboard (HTTP/Runtime/Queue/Buffer, Zeit seit Update) als strukturierte Key-Value-Liste
Meter + Trend-Sparklines (High Watermark, Queue Fill)
Control Audit (Reject Counts)
Transition History + Fault History (pflege kurzer Listen)

Diese Inhalte verschwinden vom Overview, sitzen gebündelt im Diagnostics-Tab.

Zweck: Chronologische Einblicke und Auditierung. Inhalte:

Tabs als saturated horizontal/vertical nav mit Indikatoren (keine unwichtigen Animationen).
Mobile: Tab-Inhalte untereinander, Tab-Bar sticky oben, Panels innerhalb Tabs collapsible.

Diagnosen, Logs, Toggels und History wandern in eigene Tabs.

Palette: Hintergrund #f7f8fb, Flächen #ffffff, #eef0f3, #d7dcdf; Text #111724/#3b3f45; Akzente #1f4d9d, #0d944a für positive Aktionen, #b03030 für Fehler.
Typografie: Sans-Serif (z. B. Inter oder Libre Franklin), Gewichtung durch Größe statt Glow. Monospaced nur für Messwerte/Logs.
Container: Schatten weich (z. B. 0 8px 24px rgba(15,23,42,0.08)), Ecken leicht gerundet (8px).
Tabs/Navigation: Prägnante Tab-Bar mit Underline/Border-Highlight. Klarer Fokuszustand, deutliche Hover/Active, keine Glüh-Effekte.
Buttons: Volume-sichere Farbflächen (z. B. #0d944a) auf weißem Hintergrund, sekundäre Buttons Outlines, Danger red minimal.
Status-Indikatoren: Nicht mehr „glow“; statische Icons oder leichte Capsules, ggf. Label (LIVE/IDLE) in Kapitälchen.
Spacing: Gitter (max-width 1200px) mit konsistentem 24px-Gutter, 14px Zwischenräume.

Tab-Start: Wrapper für Tabs + Content-Sektionen in internal/control/ui.html. Beginn mit statischem Tab-Layout (z. B. nav + sections) und Platzhalter für Inhalte.
Palette-Refactoring: CSS-Variablen neu definieren (heller Hintergrund, neue Akzentfarben) und Grundflächen anpassen.
Menu-State: Simplify hero/medicine to new layout, move quick-grid + signal cards into Review Overview tab.
Logik: Tab-Switching via minimal JS (klassische data-tab), keine komplette re-rendering.

Welche Panels bleiben collapsible in den Tabs (z. B. Danger Zone vs separate CTA)?
Soll es ein persistentes „Status banner“ (z. B. oben) über allen Tabs geben?
Wie viel Redundanz darf es zwischen Overview und Control geben (z. B. TX-Buttons)?