audi-app/DESIGN_AUDIT_2026-08-13.md

Design Audit — 2026-08-13 (Grossbildschirm-Layout)

Auslöser: zwei konkrete User-Reports ("Einstellungen-Knopf sitzt am Bildschirmrand, obwohl die App-Spalte schon vorher endet" und "die Ringe als Einstellungen-Knopf sind zu klein"). Beide sind bestätigt, behoben und live im audi_ha_test-Container verifiziert (Desktop 1920px + Mobil 375px, Chrome-Konsole fehlerfrei bis auf die vorbestehenden, unbezogenen Service-Worker-/Platzhalterbild-404-Meldungen). Im Zuge der Fehlersuche wurde ein dritter, verwandter Fehler im selben Muster gefunden und mitbehoben.

Geprüft wurden Übersicht, Mein Audi, Fahrten, Statistik, Tanken und Einstellungen (inkl. Setup-Popup) bei 375px und 1920px. Die drei unten dokumentierten Befunde sind die einzigen gefundenen Abweichungen; der Rest folgt konsistent den bestehenden Tokens (--r-tile, Farbrollen aus dem iOS-Overlay, .aktion/.switch-Semantik).

Befund 1 — Zahnrad/Kopfzeile sass bei breiten Fenstern am Fensterrand statt am Inhaltsrand

Root Cause: .topbar (enthält den Einstellungen-Knopf .profilbtn) liegt im Grossbildschirm-Raster (@container (min-width:860px) in audi-dashboard-ios.css) in Spalte 2 (grid-column:2), derselben Spalte wie main#view. main#view hat dort ein max-width:860px, .topbar hatte keins - die Spalte selbst ist aber minmax(0,1fr), füllt also die volle restliche Fensterbreite. .head{flex:1} in der Kopfzeile hat den Rest der Zeile aufgefüllt und .profilbtn bis an den rechten Rand der vollen Spalte geschoben, weit hinter das Ende des sichtbaren Inhalts.

Beleg (1920px Fenster): main#view endete bei x=1380, .topbar ging bis x=1920, .profilbtn sass bei x=1832-1876 - eine Lücke von über 450px zwischen Inhaltsende und Knopf.

Fix: .topbar, .phone:has(.back.on) .topbar und .ptr bekommen im 860px-Container-Query dasselbe max-width:860px wie main#view. Nach dem Fix enden .topbar und main#view an derselben Kante (x=1380), der Knopf sitzt bei x=1292-1336, sichtbar über dem Inhalt.

Datei: homeassistant/www/audi-dashboard-ios.css

Befund 2 — Audi-Ringe als einziger Einstellungen-Zugang in Telefonbreite zu klein

Root Cause: In Telefonbreite blendet die iOS-Auflage das Zahnrad-Icon (.profilbtn) aus

• die Audi-Ringe (#marke/.rings) sind dort laut eigenem Code-Kommentar "der einzige Zugang zu den Einstellungen" und seit einer früheren Session bewusst ein echter, tastaturbedienbarer Knopf. Die Knopfgrösse war mit 42×24px aber deutlich kleiner als jeder andere Symbol-Knopf in derselben Kopfzeile (.themebtn/.profilbtn/.back sind alle 44×44px) und lag unter der üblichen 44px-Mindestgrösse für Tippflächen.

Fix: .rings von 42×24px auf 58×32px vergrössert (Seitenverhältnis beibehalten, .rings svg{width:58px}). Funktion (Klick navigiert zu Einstellungen) unverändert getestet.

Datei: homeassistant/www/audi-dashboard.css

Befund 3 — Popups/Sheets auf breiten Bildschirmen fast bildschirmbreit (gleiches Muster wie Befund 1)

Beim Nachprüfen von Befund 1 fiel derselbe Fehler bei vier weiteren Elementen auf: sie sind position:absolute mit left/right relativ zu .phone (der vollen Rasterbreite, Seitenspalte inklusive) statt zur schmaleren Inhaltsspalte, ohne eigenes max-width für grosse Bildschirme:

• .setup-popup (Sensor-Zuordnung) - bestätigt live: 1644px breit bei 1920px Fenster (nur 10px Rand auf jeder Seite), praktisch bildschirmfüllend statt eines ruhigen Dialogs.
• .sdpopup (SmartDeal-Aktivierung)
• .sheet (Action-Sheet, ersetzt confirm()/alert() beim Löschen)
• .standortmenu (Standort-Bottom-Sheet auf der Kartenansicht)

Fix: Im selben 860px-Container-Query max-width:560px (Popups/Sheet) bzw. max-width: 640px (Standortmenü, mehr Inhalt) plus margin-left/right:auto ergänzt - zentriert die Elemente innerhalb ihres bestehenden left/right-Abstands, ohne die Transform-basierte Einblend-Animation dieser Elemente anzufassen (eine transform:translateX(-50%)-Zentrierung hätte mit der sheet-rein-Keyframe-Animation kollidiert, die am Ende selbst transform:none setzt). border-radius bleibt jeweils unverändert (.standortmenu behält oben abgerundete/unten eckige Kanten, passend zur weiterhin am unteren Fensterrand andockenden Bauweise).

Beleg nach Fix (Setup-Popup, 1920px Fenster): 560px breit, zentriert bei x=808-1368.

Datei: homeassistant/www/audi-dashboard-ios.css

Nicht verändert (bewusst ausserhalb dieses Audits)

• .bildmenu (Kontextmenü bei Fahrzeugbildern) ist bereits min-width:160px und wächst nicht mit der Fensterbreite - kein Fehler.
• Zentrierung der Popups erfolgt relativ zur vollen .phone-Breite (Seitenspalte inklusive), nicht exakt zur Mitte der 860px-Inhaltsspalte - bei 1920px ein Versatz von ca. 138px nach rechts gegenüber echter Inhaltsmitte. Sichtbar besser als der vorige Zustand (praktisch volle Fensterbreite), aber für pixelgenaue Zentrierung müssten die Popups im Markup in die Grid-Spalte 2 verschoben werden statt als Geschwister von main#view direkt in .phone zu liegen - eine grössere strukturelle Änderung, hier bewusst zurückgestellt.

Runde 2 — sechs weitere User-Findings

Vier bestätigt, ursächlich geklärt und behoben; zwei trotz gezielter Suche (Computed-Style- Vergleich, 2.5x-Zoom per temporärem transform:scale() auf das Live-DOM, Tag- und Nacht-Theme) nicht reproduzierbar - siehe unten.

Befund 4 — Kopfzeile (Übersicht/Fahrten/...) auf breiten Bildschirmen 30px zu weit rechts

Root Cause: .back (Zurück-Pfeil) ist auch inaktiv (opacity:0, kein .on) weiterhin ein 44px breites Flex-Element in .topbar plus gap. Auf Wurzelseiten ohne Zurück-Pfeil (Übersicht, Fahrten, ...) schiebt dieser unsichtbare Platzhalter .head/.title sichtbar weiter nach rechts als main#view darunter beginnt.

Beleg: .title links bei x=594, die erste Kachel in main#view links bei x=564 - 30px Versatz.

Fix: .back:not(.on){width:0;min-width:0;margin:0;overflow:hidden} im 860px-Container-Query. Nur für Wurzelseiten relevant; auf Detailseiten (.back.on, z. B. Einzelfahrt) bleibt der Knopf unverändert 44px breit und funktionsfähig - live getestet (Klick navigiert zurück zur Liste).

Beleg nach Fix: Versatz auf 4px reduziert (der verbleibende gap zum nächsten Flex-Element, nicht mehr wahrnehmbar).

Datei: homeassistant/www/audi-dashboard-ios.css

Befund 5 — Graue Pfeile auf "Mein Audi" (Fahrzeug/Service/Versicherung/Reifen) überlappen Text

Root Cause: .tilebtn .go{top:50%;margin-top:-5px} zentriert den Kachel-Chevron vertikal auf die gesamte Kachelhöhe. Diese fünf Kacheln sind aber keine Einzeiler, sondern <span class="label">Titel</span> + Chevron + eine ganze dl.rows-Liste darunter - die 50%-Mitte der gesamten Kachel liegt damit mitten in der Zeilenliste statt neben dem Titel, und überlappt besonders bei mehrzeilig umgebrochenen Werten (z. B. "2.9 TFSI quattro · 331 kW · 450 PS") sichtbar den Text.

Fix: top:50%;margin-top:-5px aus der iOS-Auflage entfernt - fällt zurück auf top:var(--sp-5) aus der Basis, die den Chevron wieder neben den Titel oben in der Kachel setzt (dafür existiert dort bereits extra Padding: .tile:has(> .go) > .label:first-child {padding-right:44px}).

Betroffen: alle 5 .go-Kacheln (Fahrzeug, Service, Versicherung/Steuer, Reifen, Schutzbrief Mobilität) - identisches Markup-Muster überall.

Datei: homeassistant/www/audi-dashboard-ios.css

Befund 6 — "10.000 km" / "1 Jahr" (Ölwechsel-Intervall) sehen nicht editierbar aus

Root Cause: Beide Werte sind echte <select>-Dropdowns, aber die iOS-Auflage entfernt Rahmen und Fläche komplett (background:transparent;border:0) und färbt den Wert in --fg2 - demselben gedämpften Grau wie jeder andere Fliesstext. Kombiniert mit appearance:none (entfernt zusätzlich den nativen Auswahlpfeil des Browsers, base-CSS) gibt es keinerlei visuellen Hinweis, dass hier eine Auswahl möglich ist.

Fix: .feld select{color:var(--ios-tint)} ergänzt - der Wert erscheint jetzt in der Marken-Akzentfarbe (Rot), dem iOS-üblichen Signal "hier gibt es eine Auswahl" bei Picker-artigen Feldern (anders als bei freien Texteingaben, die bewusst unverändert bleiben).

Datei: homeassistant/www/audi-dashboard-ios.css

Befund 7 — Auf/Zu-Pfeile bei Gruppenkopfzeilen (z. B. "2026", "August" in Fahrten) sehen wie Häkchen aus

Root Cause: .mark baut den Chevron aus der klassischen "zwei Kanten + 45°-Drehung"- CSS-Technik (border-right+border-bottom, transform:rotate(-45deg/45deg)). Diese Technik braucht zwingend ein Quadrat für eine saubere Pfeilform - .mark war aber 6×10px (für die SVG-Chevrons .chev/.go gedacht, die eine eigene, absichtlich nicht-quadratische Pfad-Form nutzen). Die ungleich langen Kantenabschnitte (10px vs. 6px) ergeben verdreht eine Form, die eher wie ein Häkchen als ein Pfeil aussieht - besonders im per Default aufgeklappten Zustand (rotate(45deg)), in dem "2026"/"August" standardmässig starten.

Fix: .mark auf 8×8px quadratisch gesetzt.

Datei: homeassistant/www/audi-dashboard.css

Nicht reproduziert — Befund A: "Alle Menü-Icons haben eine graue Box"

Programmatisch geprüft (.tab, .tabpille, .tab svg: background, border, box-shadow, outline für alle 5 Tabs sowohl im Seitenmenü (Desktop) als auch in der Tableiste unten (375px)): nur der aktive Tab hat eine (sehr dezente, 7% Deckkraft) graue Füllung - .tab.on .tabpille{background:var(--tile-2)}/.tab.on{background: var(--ios-fill)}, exakt wie beabsichtigt. Die vier inaktiven Tabs sind computed rgba(0,0,0,0) (vollständig transparent) auf allen geprüften Ebenen. Falls auf dem tatsächlichen Gerät etwas anderes zu sehen ist (z. B. alle 5 Icons mit sichtbarer Box), bräuchte es einen Screenshot vom echten Gerät/Browser, um die Abweichung von diesem Testcontainer einzugrenzen.

Nicht reproduziert — Befund B: "Roter Teilrahmen rechts an jeder Zeile" (Fahrten/Tanken)

Geprüft: .swipe-content{background:var(--tile-deckend)} (deckend, #171B21 Nacht / #FFFFFF Tag) deckt den dahinterliegenden roten Löschen-Button (.swipe-delete, rgb(255,69,58)) vollständig ab - beide Boxen exakt deckungsgleich (x/width/right identisch bis auf Subpixel), kein CSS-seitiger Spalt gefunden. Bei 2.5x-Zoom (temporärer transform:scale() auf das Live-DOM, nicht deploybar, nur zur Inspektion) war am rechten Rand in Tag- und Nacht-Theme kein Rot sichtbar. Möglich, dass dies nur unter bestimmten Bedingungen auftritt (Swipe-Geste mitten in der Transition, ein bestimmter Zoom-/DPI-Stand auf dem echten Gerät) - ein Screenshot oder eine genauere Beschreibung, wann genau es auftritt (beim Laden, nach einer Wischgeste, permanent?), würde helfen.

Deployment

Alle sieben Fixes deployed und verifiziert im audi_ha_test-Docker-Container (audi-dashboard-version.json → 1786744000), nach homeassistant/installationspaket/ synchronisiert. Konsole fehlerfrei bis auf die vorbestehenden, unbezogenen Service-Worker-/Platzhalterbild-404-Meldungen.