mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7ff48ed3d7
meldestelle/docs/04_Agents/Roadmaps/UIUX_Roadmap.md
Stefan Mogeritsch 236876a043 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>
2026-04-03 09:43:11 +02:00

4.3 KiB
Raw Blame History

🖌️ [UI/UX Designer] — Zwischenstand & Roadmap

Stand: 3. April 2026 Rolle: High-Density Design, Wireframes, Usability, Design-System, Empty States

✅ Erledigte Sprints

Sprint A — Abgeschlossen

  • A-1 | Design-Inventur: Bestehende V3-Screens analysiert
    • Alle vorhandenen V3-Screens katalogisiert (Screenshots in docs/06_Frontend/Screenshots/)
    • Inkonsistenzen in Spacing, Typografie und Farbgebung identifiziert
    • Offene UX-Probleme und fehlende Empty States dokumentiert
    • Issue-Liste für Sprint B vorbereitet

Sprint B (Teilweise) — Wireframes erstellt

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

    • Entscheidungsgrundlage erarbeitet: Wann AlertDialog, wann Fullscreen-Edit?
    • Wireframes für beide Varianten erstellt (Reiter-Edit, Pferd-Edit als Beispiele)
    • Ergebnis: docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md
    • Finale Entscheidung dokumentieren und als Design-Richtlinie festschreiben (Review durch 🎨 Frontend ausstehend)

  • 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 gestaltet
    • Ergebnis: 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 als Tab
    • 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 als Composable umsetzen (z. B. MsEmptyState)

🟠 Sprint C — Priorität 2 (nächste Woche)

  • 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 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: Ranglisten-Zusammenführung bei ORGANISATORISCH

⏸️ Web-App / PWA Design — Nach Desktop-MVP; Anforderungen noch nicht definiert

📌 Abhängigkeiten

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

💡 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.