Files
audi-app/DESIGN_AUDIT_2026-08-13.md
tobias 440ff22bda EU-Data-Act-Reste bereinigt, Slider-Bug behoben, zwei Design-Audit-Runden umgesetzt
Entfernt die letzten Verweise auf die abgeloeste TommiG1/HA_VAG-EU-Data-Act-
Integration (Versionstile, Testumgebungs-Fixture) und ersetzt sie durch die
FMM003-Werte. Behebt eine CSS-Spezifitaetskollision, durch die alle iOS-
Toggle-Switches viel zu breit gerendert wurden. Dokumentiert und behebt sieben
Layout-Befunde aus zwei Design-Audit-Runden (Zahnrad-Ueberlauf auf breiten
Bildschirmen, zu kleine Ringe als mobiler Einstellungen-Zugang, zu breite
Popups, Kopfzeilen-Versatz, ueberlappende Kachel-Pfeile, fehlender
Editierbarkeits-Hinweis bei Auswahlfeldern, Haekchen-artige Auf/Zu-Pfeile) -
siehe DESIGN_AUDIT_2026-08-13.md fuer Root-Cause und Beleg je Befund.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-13 20:52:07 +02:00

192 lines
11 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.