mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2c8d16b27f
meldestelle/docs/04_Agents/Roadmaps/UIUX_Roadmap.md

8.7 KiB
Raw Blame History

🖌️ [UI/UX Designer] — Schritt-für-Schritt Roadmap

Stand: 2. April 2026 Rolle: High-Density Design, Wireframes, Usability, Compose Desktop UX

🔴 Sprint A — Sofort (diese Woche)

  • A-1 | Design-Inventur: Bestehende V2-Screens analysieren
    • Alle vorhandenen V2-Screens katalogisieren (Screenshots in docs/ScreenShots/ bzw. docs/06_Frontend/Screenshots/)
    • Inkonsistenzen in Spacing, Typografie und Farbgebung identifizieren
    • Offene UX-Probleme und fehlende Empty States dokumentieren
    • Ergebnis als kurze Issue-Liste für Sprint B vorbereiten

Ergebnis A-1 — Design-Inventur V2 (Stand V3 abgeglichen)

Quellen:

  • V3 Navigation: docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
  • Archiv/Referenz V2: docs/_archive/06_Frontend/Navigation_V2_Screen-Baum_und_Back-Stack.md
  • Screenshots: docs/06_Frontend/Screenshots/ und docs/ScreenShots/archive/
  1. Katalog der relevanten V2-Screens (gemappt auf V3-Begriffe)
  • Veranstaltungen (Liste) — V3: „Veranstaltungen (Tab‑Root)“
  • Veranstaltung.Detail — V3 gleichlautend
  • Turnier.Detail — V3 gleichlautend
    • Belege: docs/06_Frontend/Screenshots/Turnier-Stammdaten_01_entwurf-01.png, .../Turnier-Stammdaten_02_entwurf01.png
  • Bewerb.Detail — V3 gleichlautend
  • Abteilung.Detail — V3 gleichlautend
    • Startliste innerhalb Abteilung — V3: „Startliste(divisionId)“
  • Kassa für Turnier — V3: „Kassa.Turnier(tournamentId)“
  • Kassa für Veranstaltung — V3: „Kassa.Veranstaltung(eventId)“
  • Status‑Anzeige/Listenkarte — Beleg: docs/06_Frontend/Screenshots/Veranstaltungen-Status-Anzeige_entwurf-01.png
  • Tab‑Root Platzhalter: Reiter, Pferde, Funktionaere, Meisterschaften, Cups (V3 vorhanden, in V2 teils rudimentär)
  1. Gefundene Inkonsistenzen (V2 UI vs. V3 Vorgabe/Figma Vision_03)
  • Spacing
    • Uneinheitliche Außenabstände (8/12/16/20 px gemischt). Vorschlag: 8‑pt Grid; Außen 16, Innen 8/12 je Dichte.
    • Vertikaler Rhythmus bei Karten uneinheitlich (Header ↔ Body ↔ Footer). Vereinheitlichen: 12/8/12.
  • Typografie
    • Unterschiedliche Größen/Weights für vergleichbare Überschriftenebenen (z. B. Screen‑Title vs. Section‑Title).
    • Fehlende definierte Caption/Overline‑Stile für Badges/Status.
  • Farben
    • Primärfarbe variiert zwischen Blau‑Tönen; Sekundär/Info vs. Accent unscharf. MaterialTheme Tokens konsolidieren (V3 C‑Palette).
    • Statusfarben (OK/Warn/Error) ohne konsistente Kontraststufen und ohne Dark‑Mode‑Fallbacks.
  • Komponenten
    • Heterogene Kartenrahmen (Elevation vs. Border). Einheitliche „MeldestelleCard“ definieren.
    • Uneinheitliche „SectionHeader“ (Icon/Spacing/Divider). Standard‑Composable nötig.
  1. Fehlende/ungenügende Empty States (Beispiele, nicht abschließend)
  • Veranstaltungen (keine Veranstaltungen) — Call‑to‑Action „Neue Veranstaltung anlegen“ + kurzer Hilfetext.
  • Turnierliste einer Veranstaltung (0 Turniere) — CTA „Turnier anlegen“ + Link zu Import.
  • Bewerbe eines Turniers (0 Bewerbe) — CTA „Bewerb anlegen“ + Hinweis auf Abteilungslogik.
  • Abteilungen eines Bewerbs (0 Abteilungen) — CTA „Abteilungen generieren/teilen“.
  • Kassa (keine offenen Posten) — freundlicher Hinweis + Link zur Teilnehmerliste.
  1. Optimierungen in Bezug auf V3 Navigation/Regeln
  • Breadcrumb in TopBar konsistent anzeigen (Eltern klickbar; keine Logout‑Aktion im MVP).
  • Kassa‑Screens als Push über Detail beibehalten (Back kehrt korrekt zurück; kein eigener Tab).
  • Dialoge/Sheets nicht im Back‑Stack verewigen; Schließen führt zum Ursprungs‑Screen.
  1. Abgeleitete Issue‑Liste für Sprint B (konkret, klein schneidbar)
  • B-0: Design‑Tokens konsolidieren
    • Farben: Primär/Secondary/Info/Warning/Error gemäß V3 Palette in Theme.kt vereinheitlichen.
    • Typo: Headline/Title/Body/Label/Caption Skala festlegen und dokumentieren.
    • Spacing: 8‑pt Grid als Standard definieren (Außen 16, Innen 8/12).
  • B-1a: „MeldestelleCard“ Standard‑Composable erstellen (Padding, Border/Elevation, Title‑Slot, Actions‑Slot).
  • B-1b: „SectionHeader“ Standard‑Composable (Icon optional, Title, Subline, Divider‑Option, Standard‑Spacings).
  • B-4a: Empty‑State Vorlage erstellen (Icon/Illustration + Title + Body + Primary‑CTA + Secondary‑Link) und für 5 Listen anwenden.
  • B-2a: Wireframe „Bewerb anlegen“ inkl. Abteilungs‑Vorschlag (CSN‑C‑NEU Pflicht‑Teilung klar visualisieren).
  • B-3a: Wireframe „Kassa Turnier/Veranstaltung“ inkl. Zahlungsaufteilung und Rechnungsvorschau (Tabs oder Side‑by‑Side) verfeinern.
  • B-1c: Entscheidungsrichtlinie Dialog vs. Fullscreen‑Edit als kurze Guideline in docs/06_Frontend/ publizieren.

Hinweise zur Ablage

  • Wireframes und UI‑Guidelines bitte unter docs/06_Frontend/ versionieren; Screenshots ergänzen unter docs/06_Frontend/Screenshots/.
  • V2‑Verweise in Docs auf V3 aktualisieren; V2 bleibt nur im Archiv referenziert.

🟠 Sprint B — Kurzfristig (nächste Woche)

  • B-1 | Wireframes: Editier-Formulare (AlertDialog vs. dedizierter Screen)

    • Entscheidungsgrundlage erarbeiten: Wann AlertDialog, wann Fullscreen-Edit, wann Sliding-Panel?
    • Kriterien definieren: Anzahl der Felder, Komplexität, Kontext-Erhalt
    • Wireframes für beide Varianten erstellen (am Beispiel Reiter-Edit und Pferd-Edit)
    • Entscheidung final treffen und als Design-Richtlinie dokumentieren (Review durch 🎨 Frontend)
    • Ergebnis in docs/06_Frontend/ ablegen → docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md

  • B-2 | Wireframes: Bewerb anlegen mit Abteilungs-Logik

    • Dialog-Flow: Bewerb-Grunddaten → Abteilungs-Vorschlag → Bestätigung
    • CSN-C-NEU Pflicht-Teilung: Visuelle Darstellung der automatischen Vorschläge
    • Abteilungs-Typ-Auswahl: SEPARATE_SIEGEREHRUNG vs. ORGANISATORISCH verständlich gestalten
    • Ergebnis in docs/06_Frontend/ ablegen → docs/06_Frontend/Wireframes/Bewerb_anlegen_Abteilungs-Logik_v1.md

  • B-3 | Wireframes: Veranstaltungs-Kassa

    • Gesamt-Saldo-Ansicht: Teilnehmer mit offenen Beträgen aus mehreren Turnieren
    • Zahlvorgang-Dialog: Eine Zahlung, Aufteilung auf Turniere sichtbar
    • Rechnungsvorschau: Zwei separate Rechnungen je Turnier nebeneinander oder als Tab
    • Ergebnis in docs/06_Frontend/ ablegen → docs/06_Frontend/Wireframes/Kassa_Veranstaltung_v1.md

  • B-4 | Empty States für alle Listenansichten

    • Liste aller Screens mit möglichen leeren Zuständen erstellen
    • Illustrations-Konzept oder Icon + Text für Empty States definieren
    • Konsistente Vorlage für alle Empty States umsetzen

🟡 Sprint C — Mittelfristig (in 2 Wochen)

  • C-1 | Wireframes aus Sprint B implementieren

    • Editier-Dialog / Fullscreen-Edit gemäß Entscheidung aus B-1 in Compose umsetzen
    • Bewerb-Anlegen-Dialog mit Abteilungs-Logik gemäß B-2 umsetzen
    • Kassa-Screen gemäß B-3 umsetzen

  • C-2 | Design-System konsolidieren

    • Farb-Palette in MaterialTheme / Theme.kt vereinheitlichen
    • Typografie-Skala definieren (Überschriften, Body, Labels, Captions)
    • Wiederverwendbare Komponenten identifizieren und als Composables extrahieren (z.B. MeldestelleCard, SectionHeader, StatusBadge)

  • C-3 | Abteilungs-Ansicht: Startliste und Ergebnisliste

    • Wireframe: Startliste einer Abteilung (Startnummer, Reiter, Pferd, Verein)
    • Wireframe: Ergebnisliste einer Abteilung (Platz, Reiter, Pferd, Ergebnis)
    • Wireframe: Gesamtrangliste Bewerb (organisatorische Abteilungen zusammengeführt)
    • Wireframe: Separate Siegerehrungsliste (CSN-C-NEU, getrennt nach Lizenzklasse)

⏸️ Zurückgestellt

⏸️ Web-App Präsentation (Veranstaltungs-Seite, Turnier-Seite) — Separate Besprechung zu einem späteren Zeitpunkt ⏸️ Nenn-Formular (Web) — Separate Besprechung zu einem späteren Zeitpunkt ⏸️ Live-Ergebnis-Seite (Web) — Separate Besprechung zu einem späteren Zeitpunkt

📌 Abhängigkeiten

Warte auf Von wem
Domänen-Modell final (Abteilung, Kassa) 🏗️ Architect
ViewModel-Struktur (welche States gibt es?) 🎨 Frontend
Meine Aufgabe Ermöglicht wem
Wireframes Editier-Formulare (B-1) 🎨 Frontend: Implementierung der Edit-Dialoge
Wireframes Kassa (B-3) 🎨 Frontend: Kassa-Screen-Implementierung
Design-System (C-2) Alle: konsistentes UI ohne Nacharbeit