docs: restructure and streamline sprint execution order
- Consolidated and removed redundant steps in `SPRINT_EXECUTION_ORDER.md`. - Simplified descriptions and roadmap formatting for improved clarity. - Updated progress and dependencies to align with Phase 8 objectives. - Adjusted role-specific roadmaps to reflect the latest sprint updates. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -1,148 +1,93 @@
|
||||
# 🖌️ [UI/UX Designer] — Schritt-für-Schritt Roadmap
|
||||
# 🖌️ [UI/UX Designer] — Zwischenstand & Roadmap
|
||||
|
||||
> **Stand:** 2. April 2026
|
||||
> **Rolle:** High-Density Design, Wireframes, Usability, Compose Desktop UX
|
||||
> **Stand:** 3. April 2026
|
||||
> **Rolle:** High-Density Design, Wireframes, Usability, Design-System, Empty States
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint A — Sofort (diese Woche)
|
||||
## ✅ Erledigte Sprints
|
||||
|
||||
- [x] **A-1** | Design-Inventur: Bestehende V2-Screens analysieren
|
||||
- [x] Alle vorhandenen V2-Screens katalogisieren (Screenshots in `docs/ScreenShots/` bzw. `docs/06_Frontend/Screenshots/`)
|
||||
- [x] Inkonsistenzen in Spacing, Typografie und Farbgebung identifizieren
|
||||
- [x] Offene UX-Probleme und fehlende Empty States dokumentieren
|
||||
- [x] Ergebnis als kurze Issue-Liste für Sprint B vorbereiten
|
||||
### Sprint A — Abgeschlossen
|
||||
|
||||
### Ergebnis A-1 — Design-Inventur V2 (Stand V3 abgeglichen)
|
||||
- [x] **A-1** | Design-Inventur: Bestehende V3-Screens analysiert
|
||||
- [x] Alle vorhandenen V3-Screens katalogisiert (Screenshots in `docs/06_Frontend/Screenshots/`)
|
||||
- [x] Inkonsistenzen in Spacing, Typografie und Farbgebung identifiziert
|
||||
- [x] Offene UX-Probleme und fehlende Empty States dokumentiert
|
||||
- [x] Issue-Liste für Sprint B vorbereitet
|
||||
|
||||
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/`
|
||||
### Sprint B (Teilweise) — Wireframes erstellt
|
||||
|
||||
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)
|
||||
- [x] **B-1 Wireframes** | Editier-Formulare (AlertDialog vs. dedizierter Screen)
|
||||
- [x] Entscheidungsgrundlage erarbeitet: Wann AlertDialog, wann Fullscreen-Edit?
|
||||
- [x] Wireframes für beide Varianten erstellt (Reiter-Edit, Pferd-Edit als Beispiele)
|
||||
- [x] Ergebnis: `docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md`
|
||||
- [ ] **Finale Entscheidung dokumentieren und als Design-Richtlinie festschreiben** (Review durch 🎨 Frontend
|
||||
ausstehend)
|
||||
|
||||
2) 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.
|
||||
|
||||
3) 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.
|
||||
|
||||
4) 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.
|
||||
|
||||
5) 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)
|
||||
- [x] Entscheidungsgrundlage erarbeiten: Wann AlertDialog, wann Fullscreen-Edit, wann Sliding-Panel?
|
||||
- [x] Kriterien definieren: Anzahl der Felder, Komplexität, Kontext-Erhalt
|
||||
- [x] Wireframes für beide Varianten erstellen (am Beispiel Reiter-Edit und Pferd-Edit)
|
||||
- [ ] Entscheidung final treffen und als Design-Richtlinie dokumentieren (Review durch 🎨 Frontend)
|
||||
- [x] 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
|
||||
- [x] **B-2 Wireframes** | Bewerb anlegen mit Abteilungs-Logik
|
||||
- [x] Dialog-Flow: Bewerb-Grunddaten → Abteilungs-Vorschlag → Bestätigung
|
||||
- [x] CSN-C-NEU Pflicht-Teilung: Visuelle Darstellung der automatischen Vorschläge
|
||||
- [x] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestalten
|
||||
- [x] Ergebnis in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Wireframes/Bewerb_anlegen_Abteilungs-Logik_v1.md`
|
||||
- [x] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestaltet
|
||||
- [x] Ergebnis: `docs/06_Frontend/Wireframes/Bewerb_anlegen_Abteilungs-Logik_v1.md`
|
||||
|
||||
- [ ] **B-3** | Wireframes: Veranstaltungs-Kassa
|
||||
- [x] **B-3 Wireframes** | Veranstaltungs-Kassa
|
||||
- [x] Gesamt-Saldo-Ansicht: Teilnehmer mit offenen Beträgen aus mehreren Turnieren
|
||||
- [x] Zahlvorgang-Dialog: Eine Zahlung, Aufteilung auf Turniere sichtbar
|
||||
- [x] Rechnungsvorschau: Zwei separate Rechnungen je Turnier nebeneinander oder als Tab
|
||||
- [x] Ergebnis in `docs/06_Frontend/` ablegen → `docs/06_Frontend/Wireframes/Kassa_Veranstaltung_v1.md`
|
||||
- [x] Rechnungsvorschau: Zwei separate Rechnungen je Turnier als Tab
|
||||
- [x] Ergebnis: `docs/06_Frontend/Wireframes/Kassa_Veranstaltung_v1.md`
|
||||
|
||||
---
|
||||
|
||||
## 🔴 Sprint B — Offen (höchste Priorität)
|
||||
|
||||
- [ ] **B-1 Abschluss** | Finale Design-Entscheidung Editier-Formulare
|
||||
- [ ] Review durch 🎨 Frontend Expert durchführen
|
||||
- [ ] Entscheidung (AlertDialog vs. Fullscreen) als verbindliche Richtlinie dokumentieren
|
||||
|
||||
- [ ] **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
|
||||
- [ ] Konsistente Vorlage als Composable umsetzen (z. B. `MsEmptyState`)
|
||||
|
||||
---
|
||||
|
||||
## 🟡 Sprint C — Mittelfristig (in 2 Wochen)
|
||||
## 🟠 Sprint C — Priorität 2 (nächste Woche)
|
||||
|
||||
- [ ] **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-1** | Wireframes aus Sprint B in Compose umsetzen
|
||||
- [ ] Editier-Dialog / Fullscreen-Edit gemäß finaler Entscheidung (B-1)
|
||||
- [ ] Bewerb-Anlegen-Dialog mit Abteilungs-Logik (B-2)
|
||||
- [ ] Kassa-Screen (B-3)
|
||||
|
||||
- [ ] **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`)
|
||||
- [ ] Wiederverwendbare Komponenten als Composables extrahieren (Cards, Badges, Chips)
|
||||
|
||||
- [ ] **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)
|
||||
- [ ] Wireframe: Ranglisten-Zusammenführung bei `ORGANISATORISCH`
|
||||
|
||||
---
|
||||
|
||||
## ⏸️ 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
|
||||
> ⏸️ **Web-App / PWA Design** — Nach Desktop-MVP; Anforderungen noch nicht definiert
|
||||
|
||||
---
|
||||
|
||||
## 📌 Abhängigkeiten
|
||||
|
||||
| Warte auf | Von wem |
|
||||
|---------------------------------------------|---------------|
|
||||
| Domänen-Modell final (Abteilung, Kassa) | 🏗️ Architect |
|
||||
| ViewModel-Struktur (welche States gibt es?) | 🎨 Frontend |
|
||||
| Warte auf | Von wem | Betrifft |
|
||||
|-------------------------------------|---------------|--------------------------|
|
||||
| Domänen-Modell (Kassa, Abteilung) ✅ | 🏗️ Architect | B-3 Kassa-Wireframes ✅ |
|
||||
| ViewModel-Struktur ✅ | 🎨 Frontend | B-1 Finale Entscheidung |
|
||||
| Meine Wireframes (B-1, B-3) | 🎨 Frontend | B-3, B-4 Implementierung |
|
||||
| Meine Wireframes (B-2) | 🎨 Frontend | Bewerb-Anlegen-Dialog |
|
||||
|
||||
| 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 |
|
||||
---
|
||||
|
||||
## 💡 Empfehlungen (nach Priorität)
|
||||
|
||||
1. **B-1 Finale Entscheidung** — Frontend wartet auf die Richtlinie für Editier-Formulare; ohne sie können keine
|
||||
konsistenten Edit-Dialoge implementiert werden.
|
||||
2. **B-4 Empty States** — Alle Listenansichten zeigen aktuell nichts bei leerem Zustand; schlechte UX für neue Nutzer
|
||||
und beim ersten Start.
|
||||
3. **C-2 Design-System** — Frühzeitige Konsolidierung verhindert kostspielige Nacharbeit; am besten parallel zu C-1
|
||||
erledigen.
|
||||
|
||||
Reference in New Issue
Block a user