Mark sprint tasks A-1 and parts of B-1 through B-3 as complete. Finalize design inventory, add Editier-Formulare guidelines, Bewerb creation workflow with Abteilungs-Logik, and Veranstaltungs-Kassa wireframes to documentation.

This commit is contained in:
2026-04-03 00:36:44 +02:00
parent 2b3e2d8c1b
commit 62c0d9d75c
4 changed files with 443 additions and 16 deletions
@@ -0,0 +1,143 @@
---
type: Frontend Guideline
status: DRAFT
owner: 🖌️ UI/UX Designer
last_update: 2026-04-03
related:
- docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
- docs/04_Agents/Roadmaps/UIUX_Roadmap.md
---
# Entscheidungsrichtlinie — Editier-Formulare
Ziel: Klare, implementierbare Regeln, wann wir ein Edit als AlertDialog, als dedizierten Fullscreen oder als Sliding Panel (Modal Bottom/Side Sheet) umsetzen. Grundlage: Navigation V3, High‑Density Desktop UX, Offline‑First.
Leitsatz: Kontext bewahren, kognitive Last minimieren, sichere Eingaben (Undo/Cancel) bevorzugen.
---
## TL;DR — Entscheidungsmatrix
- AlertDialog (modal, klein)
- Felder: ≤ 3 (einfache Felder: Text, Toggle, Single Select)
- Keine abhängigen Validierungen/Async‑Laden
- Sofortige Aktion, geringe Tragweite, seltene Nutzung
- Dauer des Vorgangs < 20 s
- Back‑Stack: kein Eintrag (Schließen kehrt zum Ursprungs‑Screen)
- Sliding Panel (Side/Bottom Sheet)
- Felder: 3–8, mittlere Komplexität, evtl. Sektionen
- Kontext muss sichtbar bleiben (Liste/Detail im Hintergrund relevant)
- Leichte Abhängigkeiten erlaubt (z. B. abhängige Selects), klare Inline‑Validierung
- Dauer 20–60 s
- Back‑Stack: kein Eintrag; Reopen über denselben Trigger
- Fullscreen Edit (eigener Screen)
- Felder: > 8 oder mehrere Sektionen/Steps
- Starke Abhängigkeiten, Validierungen, asynchrone Daten (z. B. Lookup Reiter/Pferd)
- Kritische Aktion mit größerer Tragweite (z. B. Stammdatenänderung)
- Benötigt volle Tastatur‑Fokusstrecke, Hotkeys, Review/Preview
- Dauer > 60 s
- Back‑Stack: eigener Eintrag; Zurück führt sicher zurück, Unsaved‑Changes‑Guard aktiv
Hinweis: Auf Desktop bevorzugen wir Side Sheet (rechts) als „Kontext‑Erhalt bei mittlerer Komplexität“.
---
## Do/Don’t (Auszug)
- Don’t: Mehr als 3 Eingabefelder in AlertDialogs stapeln → führt zu Scrollen/Übersehen.
- Do: Kurze Bestätigungen/Umbenennen/Flag toggeln als Dialog lösen.
- Don’t: Async‑Suchfelder im Dialog (z. B. Reiter‑Lookup) → Side Sheet oder Fullscreen.
- Do: Unsaved‑Changes vor Navigation abfangen (Confirm‑Dialog, kein Stack‑Eintrag für Modal/Sheet; V3‑Regel).
---
## Beispiel A — Reiter bearbeiten (Side Sheet empfohlen)
Kontext: Edit von Stammdaten, typ. 4–7 Felder (Name, Lizenzklasse, Verein, Notizen, aktiv). Liste/Detail im Blick behalten (Suche, Auswahl vergleichen).
ASCII‑Wireframe (Desktop, Right Side Sheet ~420–520 px):
```
┌──────────────────────────── AppContent (z. B. Reiter‑Liste) ────────────────────────────┐┌───────────── Side Sheet ─────────────┐
│ Suche [__________] Filter [v] ▢ ✕ ││ Reiter bearbeiten ✕ │
│───────────────────────────────────────────────────────────────────────────────────────││──────────────────────────────────────│
│ ▸ Mayer, Anna | Lizenz B | Verein X ││ Name [ Anna Mayer ] │
│ ▸ König, Tom | Lizenz A | Verein Y ││ Lizenzklasse [ A v ] │
│ ▸ … ││ Verein [ Suche… 🔎 ] │
│ ││ Aktiv [ ✓ ] │
│ ││ Notizen [ ............. ] │
│ ││ │
│ ││ ← Abbrechen Speichern → │
└─────────────────────────────────────────────────────────────────────────────────────┘└──────────────────────────────────────┘
```
Interaktion:
- Öffnen: Button „Bearbeiten“ in Zeile/Karte → Side Sheet schiebt von rechts ein.
- Validierung inline; Verein‑Lookup als Such‑DropDown (debounced, Offline‑Cache).
- Schließen: ESC/✕/Abbrechen; bei Änderungen Confirm‑Dialog (Unsaved‑Changes‑Guard).
---
## Beispiel B — Pferd bearbeiten (Fullscreen empfohlen)
Kontext: Mehr Felder und Abhängigkeiten (Name, Jahrgang, Geschlecht, Rasse, Besitzer/Verein, Registrier‑Nrn., Notizen). Teilweise Lookups, ggf. Bild.
ASCII‑Wireframe (Dedicated Screen):
```
TopBar: ← Pferd bearbeiten [Abbrechen] [Speichern]
Breadcrumb: Reiter & Pferde > Pferd.Detail > Edit
┌─ MeldestelleCard: Stammdaten ───────────────────────────────────────────────────────┐
│ Name [ ....................... ] Jahrgang [ 20__ ] Geschlecht [v] │
│ Rasse [ ....................... ] Farbe [ ..... ] │
│ Registrier‑Nr. [ ....................... ] Chip‑Nr. [ ..... ] │
└──────────────────────────────────────────────────────────────────────────────────────┘
┌─ MeldestelleCard: Zuordnung ────────────────────────────────────────────────────────┐
│ Besitzer [ Suche Person/Verein 🔎 ] Verein [ Suche Verein 🔎 ] │
│ Lizenzzuordnung [ None v ] (Info‑Badge zu Regeln) │
└──────────────────────────────────────────────────────────────────────────────────────┘
┌─ Notizen ────────────────────────────────────────────────────────────────────────────┐
│ [ Mehrzeiliges Textfeld ………………………………………… ] │
└──────────────────────────────────────────────────────────────────────────────────────┘
```
Interaktion:
- Eigener Screen mit vollem Tastatur‑Support, Fokus‑Reihenfolge, Hotkeys (Ctrl+S speichert).
- Unsaved‑Changes‑Guard auf Back/Navi, Validierung vor Speichern, Fehler an Feldern.
---
## Komponenten & States (für Frontend)
- Reusable: `MeldestelleCard`, `SectionHeader`, `FormRow`, `PrimaryButton`, `SecondaryButton`, `StatusBadge`.
- Validation: Inline (per Field), Summary oben optional; Disabled Save wenn kritisch.
- Loading: Per‑Field Spinner bei Lookups; Gesamtscreen nie blockieren.
- Accessibility: Tab‑Order, sichtbare Fokus‑Ringe, Labels neben/über Feldern (Dichte abhängig).
---
## Navigation & Back‑Stack (V3‑Konformität)
- Dialog/Sheet: Kein eigener Stack‑Eintrag; Schließen führt zum Ursprungs‑Screen zurück.
- Fullscreen: Eigener Stack‑Eintrag. Deep‑Link baut synthetische Eltern auf (siehe V3).
- Vor Navigation prüfen: Unsaved‑Changes → Confirm‑Dialog.
---
## Entscheidung als Regel (pseudocode)
```
if fieldCount <= 3 and complexity == low and noAsyncLookups:
use AlertDialog
elif 3 < fieldCount <= 8 and complexity in {low, medium} and contextRelevant:
use SideSheet (preferred on Desktop)
else:
use FullscreenEdit
```
Status: Freigabe durch 🎨 Frontend Expert ausstehend.
@@ -0,0 +1,109 @@
---
type: Frontend Wireframe
status: DRAFT
owner: 🖌️ UI/UX Designer
last_update: 2026-04-03
related:
- docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
- docs/03_Domain/01_Glossary/Ubiquitous_Language.md
- docs/04_Agents/Roadmaps/UIUX_Roadmap.md
---
# Wireframes — Bewerb anlegen (mit Abteilungs‑Logik)
Ziel: Klarer 3‑Step‑Flow für das Anlegen eines Bewerbs inkl. automatischer Abteilungs‑Vorschläge gemäß CSN‑C‑NEU Pflicht‑Teilung. Desktop‑optimiert (Compose), Offline‑Friendly.
Flow: Grunddaten → Abteilungs‑Vorschlag → Bestätigung.
---
## Step 1 — Grunddaten
ASCII‑Wireframe (Modal Sheet empfohlen; Fullscreen falls weitere Metadaten benötigt):
```
┌────────── Bewerb anlegen — Grunddaten ──────────┐
│ Bezeichnung [ Springen 1,10 m ] │
│ Disziplin [ Springen v ] Niveau [A] │
│ Alters-/Lizenz [ Lizenz B v ] │
│ Startgeld [ 25,00 ] Währung [EUR v] │
│ Optional: Max Nennungen [ 60 ] │
│
│ ← Zurück Weiter → │
└─────────────────────────────────────────────────┘
```
Hinweise:
- Felder minimal halten; Tooltips für Regelwerk.
- Validierung live; „Weiter“ erst bei gültigen Pflichtfeldern.
---
## Step 2 — Abteilungs‑Vorschlag (CSN‑C‑NEU)
Visualisierung der automatischen Vorschläge, klare Unterscheidung der Abteilungs‑Typen:
```
┌──── Bewerb anlegen — Abteilungs‑Vorschlag ─────┐
│ Vorschläge (automatisch): │
│ ▣ SEPARATE_SIEGEREHRUNG (Pflicht‑Teilung) │
│ • A (Lizenz A) ▢ zusammenlegen │
│ • B (Lizenz B) ▢ zusammenlegen │
│ • R1 (R1) ▢ zusammenlegen │
│ │
│ ○ ORGANISATORISCH (nur Startlisten trennen) │
│ • A+B zusammen (gemeinsame Wertung) │
│ │
│ Darstellung: │
│ [A] [B] [R1] → 3 Siegerehrungen getrennt │
│ [A+B] → 1 Siegerehrung gemeinsam │
│ │
│ Optionen: │
│ [ Editieren… ] (Abteilungen manuell anpassen) │
│ [ Info zur Pflicht‑Teilung ] │
│ │
│ ← Zurück Weiter → │
└─────────────────────────────────────────────────┘
```
UI‑Muster:
- Toggle zwischen `SEPARATE_SIEGEREHRUNG` und `ORGANISATORISCH` als RadioGroup mit erklärendem Subtext.
- „Zusammenlegen“ Checkbox erlaubt in Grenzfällen organisatorisches Zusammenführen; deaktiviert bei harter Pflicht‑Teilung.
- Badge/Hint „CSN‑C‑NEU: Pflicht‑Teilung aktiv“ mit Link zum Regeltext.
---
## Step 3 — Bestätigung (Review)
```
┌──── Bewerb anlegen — Review & Bestätigung ─────┐
│ Bewerb: Springen 1,10 m | Disziplin: Springen │
│ Lizenz: B | Startgeld: 25,00 EUR │
│ │
│ Abteilungen (Typ: SEPARATE_SIEGEREHRUNG): │
│ • A (eigene Wertung/Siegerehrung) │
│ • B (eigene Wertung/Siegerehrung) │
│ • R1 (eigene Wertung/Siegerehrung) │
│ │
│ [Zurück] [Bewerb anlegen] │
└────────────────────────────────────────────────┘
```
Validierung & States:
- Blocking Errors verhindern „Bewerb anlegen“.
- Backend‑Konflikte (Dubletten) als Inline‑Fehler mit CTA „Zum bestehenden Bewerb“.
---
## Komponenten & Implementierungshinweise
- Reusable: `FormRow`, `RadioCard` (Typ‑Auswahl mit Subtext), `DivisionPreviewChips` (Abteilungs‑Chips), `InfoBadge`.
- Accessibility: Fokus‑Reihenfolge, ARIA‑Rollen analog (Compose Semantics).
- Offline: Vorschläge aus lokalem Regelwerk + Cache berechnen; Sync klärt spätere Abweichungen.
---
## Edge‑Cases
- Pflicht‑Teilung aktiv, aber zu wenige Nennungen: Hinweis, spätere Zusammenlegung möglich (nur organisatorisch) — dokumentieren.
- Manuelle Anpassung erzeugt Konflikt mit Regel: Deutlicher Fehlerhinweis, Button disabled, Link „Warum?“.
@@ -0,0 +1,111 @@
---
type: Frontend Wireframe
status: DRAFT
owner: 🖌️ UI/UX Designer
last_update: 2026-04-03
related:
- docs/06_Frontend/Navigation_V3_Screen-Baum_und_Back-Stack.md
- docs/04_Agents/Roadmaps/UIUX_Roadmap.md
---
# Wireframes — Veranstaltungs‑Kassa
Ziel: Übersicht über offene Beträge der Teilnehmer über mehrere Turniere einer Veranstaltung, klarer Zahlungsflow mit Aufteilung und Rechnungsvorschau. V3‑konforme Navigation (Push über Detail; Back geht zurück).
---
## A. Gesamt‑Saldo‑Ansicht (Event‑Ebene)
```
TopBar: ← Kassa — Veranstaltung „CSN Frühling 2026“ [Suche 🔎]
┌─ Filter/Tools ─────────────────────────────────────────────────────────────────────┐
│ Teilnehmer/Team [________] | Status [Offen v] | Turnier [Alle v] | [ Export CSV ] │
└────────────────────────────────────────────────────────────────────────────────────┘
┌─ Tabelle: Teilnehmer (aggregiert über Turniere) ───────────────────────────────────┐
│ Teilnehmer | Turniere mit offenen Posten | Offen gesamt | Aktionen │
│───────────────────┼─────────────────────────────┼───────────────┼─────────────────│
│ Anna Mayer | Springen SA, Dressur SO | € 75,00 | [Zahlen] [Detail]
│ Team König | Dressur SA | € 30,00 | [Zahlen] [Detail]
│ … │
└────────────────────────────────────────────────────────────────────────────────────┘
Hinweis: „Detail“ öffnet pro Teilnehmer eine Side‑Panel‑Auflistung je Turnier.
```
Side Panel „Teilnehmer‑Detail“ (optional):
```
┌───────────── Side Sheet: Anna Mayer ─────────────┐
│ Turnier Springen SA | Offen € 50,00 │
│ • Nennung € 25,00 │
│ • Nachnenngebühr € 25,00 │
│ Turnier Dressur SO | Offen € 25,00 │
│ • Nennung € 25,00 │
│ [Zahlvorgang…] │
└──────────────────────────────────────────────────┘
```
---
## B. Zahlvorgang‑Dialog (Aufteilung über Turniere)
```
┌──────── Zahlung erfassen — Anna Mayer ────────┐
│ Eingabe: │
│ Betrag erhalten [ 75,00 ] Währung [€] │
│ Zahlungsart [ Bar v ] │
│ Beleg‑Nr. [ ....... ] (optional) │
│ │
│ Aufteilung auf Turniere: │
│ Springen SA Offen € 50,00 [ 50,00 ] │
│ Dressur SO Offen € 25,00 [ 25,00 ] │
│ Rest € 0,00 (Auto) │
│ │
│ [Abbrechen] [Weiter →] │
└───────────────────────────────────────────────┘
```
Regeln:
- Default: Verteilt automatisch Top‑Down nach offenem Betrag; editierbar.
- Restbetrag darf nicht negativ sein; Validierungs‑Hinweis inline.
- Speicherung erzeugt Buchungen je Turnier (Transaktion), Offline‑fähig mit Pending‑Status.
---
## C. Rechnungsvorschau (Tabs oder Side‑by‑Side)
Variante 1 — Tabs (einfacher, platzsparend):
```
┌──────── Rechnungsvorschau — Anna Mayer ────────┐
│ Tabs: [ Springen SA ] [ Dressur SO ] │
│ │
│ (PDF‑Preview/Komposition) │
│ │
│ [← Zurück] [Buchen & Drucken] │
└────────────────────────────────────────────────┘
```
Variante 2 — Side‑by‑Side (breit, schneller Vergleich):
```
┌──────── Rechnungsvorschau — Anna Mayer (2 Spalten) ──────────────────────────────┐
│ ┌─ Springen SA ───────────────────────────┐ ┌─ Dressur SO ────────────────────┐ │
│ │ Leistungen … │ │ Leistungen … │ │
│ │ Summe € 50,00 │ │ Summe € 25,00 │ │
│ └─────────────────────────────────────────┘ └──────────────────────────────────┘ │
│ │
│ [← Zurück] [Buchen & Drucken] │
└───────────────────────────────────────────────────────────────────────────────────┘
```
Entscheidungsempfehlung: Tabs als Default; Side‑by‑Side optional, wenn Fensterbreite ≥ 1440 px.
---
## Komponenten & Hinweise
- Reusable: `DataTable`, `SideSheet`, `MoneyField` (lokalisiert), `PaymentMethodSelect`, `PdfPreview`.
- States: Offline Pending, Fehlerbehandlung pro Turnierbuchung, Undo (sofortiges Rückgängig in Snackbar mit Timeout).
- Navigation: Kassa als Push über Detail (V3), kein eigener Tab; Back kehrt zum Detail zurück.