mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
15b3f17d1d
meldestelle/docs/04_Agents/Roadmaps/UIUX_Roadmap.md
Stefan Mogeritsch 52f2a54e0b feat(docs): finalize editing forms guideline and define empty state specification 
- Marked `Editier-Formulare_Dialog-vs-Fullscreen_v1.md` as APPROVED with finalized mapping for all edit screens.
- Created `Empty-States_Spezifikation_v1.md` to outline design, behavior, and implementation plan for empty states across 10 screens.
- Logged session outcomes in `2026-04-03_UIUX_B1_B4_Editier-Formulare_Empty-States_Curator_Log.md`.
- Updated `UIUX_Roadmap.md` to reflect Sprint B completion and tasks for Sprint C-1.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-03 11:54:44 +02:00

5.5 KiB
Raw Blame History

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

Stand: 3. April 2026 (aktualisiert — Sprint B vollständig abgeschlossen) 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 dokumentiert und als verbindliche Design-Richtlinie festgeschrieben (Status: APPROVED)
    • Mapping aller bestehenden Edit-Screens auf AlertDialog / Side Sheet / Fullscreen dokumentiert

  • 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 — Abgeschlossen (3. April 2026)

  • B-1 Abschluss | Finale Design-Entscheidung Editier-Formulare

    • Review durch 🎨 Frontend Expert durchgeführt (bestätigt durch bestehende Implementierungen)
    • Entscheidung (AlertDialog / Side Sheet / Fullscreen) als verbindliche Richtlinie dokumentiert
    • Ergebnis: docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md (Status: APPROVED)

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

    • Liste aller Screens mit möglichen leeren Zuständen erstellt (10 Screens, 3 Typen)
    • Icon-Konzept: Material Symbols Outlined — kein Custom-Illustration-Set für MVP
    • Texte (Titel, Beschreibung, CTA) für alle Screens und alle Typen definiert
    • Composable-API MsEmptyState spezifiziert (Ablageort, Parameter, Verhalten, Beispiel)
    • Ergebnis: docs/06_Frontend/Guidelines/Empty-States_Spezifikation_v1.md (Status: APPROVED)

🟠 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) — Richtlinie: APPROVED ✅
    • Bewerb-Anlegen-Dialog mit Abteilungs-Logik (B-2)
    • Kassa-Screen (B-3)
    • MsEmptyState-Composable implementieren (Spezifikation: docs/06_Frontend/Guidelines/Empty-States_Spezifikation_v1.md)
    • Empty States in alle 10 Listenansichten integrieren (Prioritätsreihenfolge laut Spezifikation)
    • PferdProfilEditDialog zu Fullscreen-Edit migrieren (> 8 Felder, Async-Lookups — laut B-1 Mapping)

  • 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 Richtlinie B-1 ✅ 🎨 Frontend C-1 Edit-Dialoge implementieren
Meine Spezifikation B-4 ✅ 🎨 Frontend C-1 MsEmptyState implementieren
Meine Wireframes (B-2, B-3) 🎨 Frontend C-1 Bewerb-Dialog, Kassa-Screen

💡 Empfehlungen (nach Priorität)

  1. C-1 MsEmptyState implementieren — Spezifikation liegt vor (APPROVED); Frontend kann sofort mit der Composable-Implementierung beginnen. Alle 10 Listenansichten laut Prioritätsliste abarbeiten.
  2. C-1 PferdProfilEditDialog → Fullscreen migrieren — Aktueller Dialog überschreitet die Komplexitätsgrenze (> 8 Felder, Async-Lookups); Migration gemäß B-1-Richtlinie für Sprint C-1 vorgesehen.
  3. C-2 Design-System — Frühzeitige Konsolidierung verhindert kostspielige Nacharbeit; am besten parallel zu C-1 erledigen.