604 lines
22 KiB
Markdown
604 lines
22 KiB
Markdown
---
|
|
kind: rule
|
|
project: HiveGrid Screen Project
|
|
area: Wireframing
|
|
status: active
|
|
---
|
|
|
|
# Wireframing Playbook
|
|
|
|
Stand: 2026-06-24
|
|
|
|
Dieses Playbook definiert, wie Wireframe-Pakete fuer HiveGrid in Obsidian vorbereitet, validiert und als Markdown/Canvas abgelegt werden. Subframe wird nur nach expliziter Freigabe genutzt.
|
|
|
|
Ziel: Nicht jeden Spezialzustand einzeln bauen, sondern nur die Screens bauen, die Struktur, Aufgabe, Entscheidung oder Risiko sichtbar machen.
|
|
|
|
---
|
|
|
|
## 1. Grundprinzip
|
|
|
|
Ein Wireframe klaert:
|
|
|
|
- was der Nutzer auf diesem Screen tun soll
|
|
- welche Daten sichtbar sind
|
|
- welche Aktionen moeglich sind
|
|
- welche Entscheidungen oder Blocker existieren
|
|
- welche Komponenten/Archetypen wiederverwendet werden
|
|
|
|
Subframe wird erst nach expliziter Freigabe genutzt. Mikro-Zustaende werden dokumentiert, aber nicht jedes Mal als eigener Frame gebaut.
|
|
|
|
Wichtig: Der Assistant bereitet Flows, Screen-Dateien und Canvas in Obsidian vor. David validiert und kann die Screens selbst in Subframe bauen. Bestehende Subframe-Screens werden nicht automatisch bearbeitet, ueberschrieben oder geloescht, auch wenn sie gleich heissen.
|
|
|
|
---
|
|
|
|
## 2. Arbeitsablauf pro Wireframe-Paket
|
|
|
|
Kein Flow wird direkt gebaut. Vorher gibt es immer ein kurzes Brainstorming und eine Validierung.
|
|
|
|
Es wird immer nur **ein kleines Paket nach dem anderen** bearbeitet. Nicht mehrere Flows gleichzeitig finalisieren.
|
|
|
|
Grundregel:
|
|
|
|
```text
|
|
Ein Flow -> Varianten brainstormen -> Entscheidung treffen -> Screen-Kandidaten sammeln -> jeden Screen validieren -> erst dann bauen/ablegen.
|
|
```
|
|
|
|
Screen-Listen entstehen aus dem Brainstorming. Sie werden nicht vorab automatisch festgelegt.
|
|
|
|
0. **Intent Check: Was ist ueberhaupt gewollt?**
|
|
- Welches Ticket oder Modul ist betroffen?
|
|
- Was soll der Nutzer am Ende schaffen?
|
|
- Geht es um einen echten Flow, einen einzelnen Screen, einen Zustand oder nur Dokumentation?
|
|
- Welche Planning-Quellen muessen gelesen werden?
|
|
- Welche Annahmen sind noch unsicher?
|
|
- Was ist ausdruecklich nicht Teil dieses Pakets?
|
|
|
|
1. **Scope sammeln**
|
|
- Ticket/Modul
|
|
- Ziel des Flows
|
|
- Nutzerrolle
|
|
- Rollenunterschiede: normale Rolle vs. Admin
|
|
- Startpunkt
|
|
- wichtige Daten
|
|
- wichtige Aktionen
|
|
- bekannte Constraints aus Planning/Specs
|
|
|
|
2. **Mini-Brainstorming**
|
|
- Was ist der Happy Path?
|
|
- Wo verzweigt der Flow?
|
|
- Wo kann der Nutzer blockiert sein?
|
|
- Welche Fehler, Warnungen, Success-Zustaende und Hinweise koennen auftreten?
|
|
- Welche davon sind Inline, Banner, Toast, Modal oder eigener Screen?
|
|
- Welche UX-Varianten sind denkbar?
|
|
- Was spricht fuer oder gegen jede Variante?
|
|
- Welche Variante empfiehlt der Assistant?
|
|
- Welche Variante entscheidet David?
|
|
- Erst danach: Welche Screens/Zustaende koennten daraus entstehen?
|
|
|
|
3. **Entscheidungsschritt**
|
|
- David entscheidet die UX-Richtung.
|
|
- Offene Fragen werden markiert.
|
|
- Wenn keine Entscheidung moeglich ist, wird das Paket nicht gebaut.
|
|
- Erst nach der Entscheidung entsteht eine Screen-Kandidatenliste.
|
|
|
|
4. **Screen Validation Gate**
|
|
- Jeder Screen-Kandidat wird einzeln entschieden.
|
|
- Kein Screen wird in Subframe gebaut, bevor er validiert ist.
|
|
- Kein Screen wird in den Flow eingebaut, nur weil er "vielleicht gebraucht" wird.
|
|
- Fehler-/Meldungszustaende werden einzeln entschieden: Inline, Banner, Toast, Modal, eigener Screen oder nur Dokumentation.
|
|
- Ein Screen bekommt erst danach eine Umsetzung: `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter` oder `Raus`.
|
|
|
|
5. **Validierung vor dem Bau**
|
|
- Screen-Liste steht
|
|
- Reuse-vs-Bauen ist entschieden
|
|
- offene Fragen sind markiert
|
|
- Hauptflow und Varianten sind verstanden
|
|
- jeder Screen wurde einzeln geprueft
|
|
|
|
6. **Screen-Dateien/Canvas vorbereiten**
|
|
- nur die validierten Screens
|
|
- Canvas nur fuer den validierten Flow anlegen
|
|
- vorhandene D0-Komponenten und Archetypen dokumentieren
|
|
- keine unnoetigen Sonderkomponenten erfinden
|
|
- kein Subframe-Bau ohne ausdrueckliche Freigabe von David
|
|
- neue, geloeschte, umbenannte oder gesplittete Screens immer in Screen-Dateien, Paket-MD, Tracker und Canvas synchron halten
|
|
|
|
7. **Markdown-Paket schreiben**
|
|
- Screen-Liste
|
|
- Subframe-Links
|
|
- Daten je Screen
|
|
- Aktionen je Screen
|
|
- Banner, Toasts und Inline-Meldungen
|
|
- Zustaende
|
|
- offene Fragen
|
|
|
|
8. **Handoff-Check**
|
|
- jedes sichtbare Feld hat eine Datenquelle
|
|
- jeder Button hat eine Aktion
|
|
- die relevanten Zustaende sind beschrieben
|
|
- der Screen ist als `Bauen`, `Wiederverwenden`, `Nur dokumentieren`, `Spaeter` oder `Raus` markiert
|
|
|
|
---
|
|
|
|
## 2a. Brainstorming-Regeln
|
|
|
|
Brainstorming ist Pflicht, bevor Screens festgelegt werden.
|
|
|
|
Der Assistant darf nicht direkt eine finale Screen-Liste erzeugen. Er arbeitet zuerst mit Optionen.
|
|
|
|
### Ablauf
|
|
|
|
1. **Flow-Frage formulieren**
|
|
- Worum geht es in diesem Flow?
|
|
- Welches Nutzerproblem wird geloest?
|
|
- Was ist der Startpunkt und was ist das Ziel?
|
|
|
|
2. **Varianten anbieten**
|
|
- mindestens 2 sinnvolle Varianten, wenn es echte UX-Entscheidungen gibt
|
|
- pro Variante kurz: Vorteil, Nachteil, Aufwand, Risiko
|
|
- keine Scheingenauigkeit, wenn eine Variante offensichtlich falsch ist
|
|
|
|
3. **Empfehlung geben**
|
|
- der Assistant darf eine Empfehlung geben
|
|
- die Empfehlung ist nicht automatisch die Entscheidung
|
|
|
|
4. **David entscheidet**
|
|
- Entscheidung markieren als `genommen`, `spaeter`, `raus` oder `unklar`
|
|
- bei `unklar` wird nicht gebaut
|
|
|
|
5. **Screen-Kandidaten ableiten**
|
|
- erst nach Davids Entscheidung
|
|
- Kandidaten sind noch nicht final
|
|
- Meldungs-/Error-State-Kandidaten werden separat gesammelt
|
|
|
|
6. **Screen Validation Gate**
|
|
- jeder Kandidat wird einzeln geprueft
|
|
- danach erst finale Liste
|
|
- jeder relevante Fehler-/Meldungszustand bekommt eine UI-Form
|
|
|
|
### Entscheidungsformat
|
|
|
|
Fuer Brainstorming wird dieses Format genutzt:
|
|
|
|
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
|
|---|---|---|---|---|
|
|
| A | - | - | - | - |
|
|
| B | - | - | - | - |
|
|
|
|
Danach:
|
|
|
|
| Entscheidung | Status | Notiz |
|
|
|---|---|---|
|
|
| - | genommen / spaeter / raus / unklar | - |
|
|
|
|
### Meldungs-/Error-State-Check im Brainstorming
|
|
|
|
Bei jedem Flow wird waehrend des Brainstormings abgefragt:
|
|
|
|
- Was kann erfolgreich passieren?
|
|
- Was kann fehlschlagen?
|
|
- Was kann den Nutzer blockieren?
|
|
- Was muss der Nutzer sofort korrigieren koennen?
|
|
- Was darf nicht verschwinden?
|
|
- Was ist copy-kritisch oder sicherheitskritisch?
|
|
- Welche Meldungen duerfen nicht dem Developer ueberlassen werden?
|
|
|
|
Diese Matrix wird fuer jedes Paket genutzt:
|
|
|
|
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
|
|---|---|---|---|---|
|
|
| - | Inline / Banner / Toast / Modal / Screen | ja / nein | ja / nein | - |
|
|
|
|
Regel: Ein Fehler wird nicht danach entschieden, ob er technisch ein Error ist, sondern danach, was der Nutzer als Naechstes tun muss.
|
|
|
|
---
|
|
|
|
## 2b. Rollen- und Permission-Regel
|
|
|
|
Bei jedem Flow wird kurz geprueft, ob sich die UX fuer Admin und normale Nutzer unterscheidet.
|
|
|
|
Standardannahme:
|
|
|
|
- **Normale Rolle** = hoechste Rolle unter Admin.
|
|
- **Admin** = eigene Variante nur dann, wenn Ziel, Rechte, Daten oder Weiterleitung sichtbar anders sind.
|
|
|
|
Regeln:
|
|
|
|
- Wenn Admin nur nach erfolgreichem Login woanders landet, wird das als **Outcome** dokumentiert, nicht automatisch als eigener Screen gebaut.
|
|
- Wenn Admin andere Daten, andere Aktionen oder andere Risiken sieht, wird eine eigene Variante geprueft.
|
|
- Tenant-/Workspace-/Profil-Auswahl fuer Admin wird als eigener Flow behandelt, wenn sie mehr ist als eine reine Weiterleitung.
|
|
- Permission-Denied, gesperrte Funktionen und sichtbare Rechte-Unterschiede werden im Screen-Paket dokumentiert.
|
|
|
|
Beispiel Login:
|
|
|
|
| Rolle | Nach erfolgreichem Login |
|
|
|---|---|
|
|
| Normale Rolle | Home/Dashboard |
|
|
| Admin | Tenant-/Workspace-Auswahl oder Admin-Startpunkt |
|
|
|
|
---
|
|
|
|
## 2c. Zentrale Auth-Core-Flows
|
|
|
|
Manche Auth-Flows sind zentrale Sicherheitsbausteine und werden von mehreren anderen Flows angesteuert.
|
|
|
|
Aktuelle Produktentscheidung:
|
|
|
|
`Set Password` wird als zentraler Flow behandelt.
|
|
|
|
Er kann aus mehreren Zubringer-Flows gestartet werden:
|
|
|
|
- Passwort Reset
|
|
- Einladung / initialer Mitarbeiterzugang
|
|
- Passwort aendern
|
|
- Admin-Reset
|
|
- Sicherheitsmassnahme nach Incident
|
|
|
|
Regeln:
|
|
|
|
- Der zentrale Flow wird als eigenes Paket gebrainstormt und validiert.
|
|
- Zubringer-Flows dokumentieren nur, wie der Nutzer in den zentralen Flow kommt.
|
|
- Sonderregeln des Zubringer-Flows werden nicht im zentralen Flow versteckt, sondern im jeweiligen Paket dokumentiert.
|
|
- Auth-Core-Flows brauchen eine dokumentierte Zurueck-/Abbrechen-Aktion, wenn ein Nutzer den Einstieg versehentlich geoeffnet haben kann, z. B. bei Passwort Reset.
|
|
- Die Zurueck-Aktion ist normalerweise kein eigener Screen, sondern eine sekundare Navigation im jeweiligen Auth-Screen.
|
|
- 2FA wird im Set-Password-Flow grundsaetzlich angeboten.
|
|
- Wenn 2FA fuer den konkreten Einstieg verpflichtend ist, wird das im Zubringerpaket oder als Regel im Set-Password-Paket markiert.
|
|
- Admin-Reset kann bestimmen, ob 2FA verpflichtend oder freiwillig ist.
|
|
- Neukunden-Signup ist eine bewusste Ausnahme: Das Passwort wird direkt im Signup-Flow gesetzt, damit der Einstieg moeglichst wenig Reibung hat.
|
|
|
|
Wichtig: Diese Entscheidung weicht bewusst von der einfachen D-P2-Planung ab und ist eine UX-/Produktentscheidung nach Abstimmung mit Development.
|
|
|
|
---
|
|
|
|
## 2e. Subframe-Schutzregel
|
|
|
|
Subframe ist kein automatischer naechster Schritt.
|
|
|
|
Regeln:
|
|
|
|
- Kein bestehender Subframe-Screen wird ohne ausdrueckliche Freigabe bearbeitet.
|
|
- Kein bestehender Subframe-Screen wird geloescht oder ueberschrieben.
|
|
- Gleichnamige vorhandene Subframe-Screens sind nur Kontext, keine Arbeitsanweisung.
|
|
- Neue Subframe-Screens werden nur angelegt, wenn David den konkreten Flow und den Subframe-Bau freigibt.
|
|
- Bis zur Freigabe arbeitet der Assistant ausschliesslich in Obsidian: Paket-MD, Screen-MD, Canvas und Tracker.
|
|
- Wenn Subframe spaeter genutzt wird, werden neue Screens eindeutig verlinkt und im Tracker dokumentiert.
|
|
|
|
---
|
|
|
|
## 2f. Screen-Aenderungs- und Sync-Regel
|
|
|
|
Jede Aenderung an Screen-Struktur, Screen-Namen oder Screen-Zuschnitt muss als synchroner Paket-Update behandelt werden. Das gilt auch, wenn nur in Subframe oder nur in der Planung gearbeitet wurde.
|
|
|
|
Pflichtablauf bei jeder Screen-Aenderung:
|
|
|
|
1. **Bestand pruefen**
|
|
- Aktuellen Subframe-Flow per MCP lesen, wenn der Flow bereits in Subframe existiert.
|
|
- Aktuelle Screen-Dateien, Paket-MD, `Screen Paket Tracker` und Canvas-Datei pruefen.
|
|
- Vorhandene lokale Aenderungen respektieren; nichts ungefragt zuruecksetzen.
|
|
|
|
2. **Screen-Entscheidung klaeren**
|
|
- Ist es derselbe Screen mit anderem Namen?
|
|
- Ist es ein Zustand innerhalb eines Screens?
|
|
- Ist es eine Variante zur Auswahl?
|
|
- Oder ist es ein eigener Screen mit eigener Nutzeraufgabe?
|
|
- Wenn aus einer Variante ein eigener Screen werden soll, muss David das vorher validieren.
|
|
|
|
3. **Synchron eintragen**
|
|
- Screen-Datei: Frontmatter `screen`, Titel, Ziel, Route, Subframe-Link.
|
|
- Paket-MD: Flowbeschreibung, Screen Validation Gate, validierte Screen-Liste, Subframe-Grid, Screen-Pakete, Handoff-Check.
|
|
- `Screen Paket Tracker`: Name, Status, Route/Ort, MD-Link, Subframe-Link, Canvas-Link.
|
|
- Canvas: eigener Node fuer jeden echten Screen; Kanten und Labels passend aktualisieren.
|
|
- Subframe: nur nach Freigabe Screens anlegen, loeschen, umbenennen oder bearbeiten.
|
|
|
|
4. **Abgleich vor Abschluss**
|
|
- `rg` nach alten Screen-Namen und toten Subframe-Links ausfuehren.
|
|
- Subframe-Flow erneut lesen, wenn Subframe geaendert wurde.
|
|
- Canvas-Datei als JSON validieren, wenn sie geaendert wurde.
|
|
- `git diff --name-only` pruefen und dem Nutzer sagen, was bewusst nicht geaendert wurde.
|
|
|
|
Regeln:
|
|
|
|
- Ein Subframe-Screen ohne Tracker-/Canvas-Eintrag ist ein Fehler.
|
|
- Ein Canvas-Screen ohne Screen-Datei oder Tracker-Zeile ist ein Fehler.
|
|
- Eine Screen-Datei mit geloeschtem oder falschem Subframe-Link ist ein Fehler.
|
|
- Mehrere reale Einstiegssituationen duerfen nur dann als eine Screen-Datei bleiben, wenn David sie explizit als Zustandsvarianten desselben Screens validiert.
|
|
- Wenn zwei Einstiegssituationen eigene Screens sind, brauchen sie eigene Screen-Namen, eigene Tracker-Zeilen und eigene Canvas-Nodes.
|
|
- Vor David-Freigabe wird ein geplanter Split nur als offene Entscheidung oder Backlog notiert, nicht stillschweigend gebaut.
|
|
|
|
---
|
|
|
|
## 2d. Screen Validation Gate
|
|
|
|
Bevor ein Screen in einen Flow eingebaut wird, muss er einzeln validiert werden.
|
|
|
|
### Validierungsfragen
|
|
|
|
- Ist das ein eigener Arbeitsmoment fuer den Nutzer?
|
|
- Wird hier eine neue Struktur gebraucht?
|
|
- Gibt es eine neue Entscheidung oder einen Risiko-Moment?
|
|
- Reicht ein vorhandener Archetyp?
|
|
- Ist es nur ein Zustand, Banner, Toast oder Inline-Hinweis?
|
|
- Muss dieser Screen jetzt gebaut werden, oder reicht `Spaeter`?
|
|
- Welche Daten und Aktionen sind wirklich noetig?
|
|
|
|
### Ergebnis
|
|
|
|
Jeder Screen-Kandidat bekommt eine klare Entscheidung:
|
|
|
|
| Entscheidung | Bedeutung |
|
|
|---|---|
|
|
| Bauen | wird als eigener Subframe-Frame gebaut |
|
|
| Wiederverwenden | vorhandener Archetyp reicht |
|
|
| Nur dokumentieren | im MD festhalten, kein Frame |
|
|
| Spaeter | relevant, aber nicht fuer dieses Paket |
|
|
| Raus | bewusst nicht Teil des Scopes |
|
|
|
|
Erst nach dieser Entscheidung darf der Screen in die finale Screen-Liste.
|
|
|
|
### Copy-kritische Zustaende
|
|
|
|
Manche Zustaende sind technisch nur Banner, Inline-Meldung oder Erfolgsscreen, muessen aber trotzdem gebaut werden.
|
|
|
|
Grund: Der Text, die Tonalitaet und die naechste Handlung sollen vom Design entschieden werden, nicht spaeter zufaellig vom Developer.
|
|
|
|
Ein Zustand wird eher gebaut, wenn:
|
|
|
|
- er sehr haeufig vorkommt
|
|
- der Nutzer danach wissen muss, was als Naechstes passiert
|
|
- Sicherheit, Vertrauen oder Zugang betroffen ist
|
|
- der Text sensibel ist
|
|
- die Meldung ein eigener mentaler Schritt im Flow ist
|
|
- die Entscheidung nicht dem Developer ueberlassen werden soll
|
|
|
|
Beispiele:
|
|
|
|
- Magic-Link gesendet
|
|
- Passwort geaendert
|
|
- E-Mail nicht gefunden / neutraler Sicherheitstext
|
|
- falsche Login-Daten
|
|
- 2FA gesperrt
|
|
- Link abgelaufen
|
|
- Account gesperrt
|
|
|
|
Field-Validierungen wie "Passwort zu schwach", "Pflichtfeld fehlt" oder "ungueltige Telefonnummer" werden normalerweise nicht einzeln gebaut, wenn sie durch das Form/Input-Kit abgedeckt sind. Ausnahme: Der Zustand ist fachlich oder rechtlich wichtig.
|
|
|
|
---
|
|
|
|
## 3. Was gilt als Screen?
|
|
|
|
Ein Screen ist ein eigener Arbeitsmoment fuer den Nutzer.
|
|
|
|
Ein Screen liegt vor, wenn der Nutzer:
|
|
|
|
- auf einer eigenen Seite landet
|
|
- eine Entscheidung trifft
|
|
- Daten prueft
|
|
- etwas erstellt oder bearbeitet
|
|
- einen Flow startet, fortsetzt oder beendet
|
|
- blockiert ist und eine Loesung braucht
|
|
|
|
Beispiele: Login, 2FA, Profil-Auswahl, Kontaktliste, Projekt-Detail, Flow-Editor, Loeschbestaetigung, Reassign-Workflow.
|
|
|
|
---
|
|
|
|
## 4. Wann wird ein Screen in Subframe gebaut?
|
|
|
|
Ein Screen wird gebaut, wenn mindestens eine Regel zutrifft:
|
|
|
|
1. **Neue Struktur**
|
|
- Das Layout unterscheidet sich sichtbar von den bekannten Archetypen.
|
|
|
|
2. **Neue Aufgabe**
|
|
- Der Nutzer macht hier etwas Eigenes, nicht nur dieselbe Liste mit anderen Daten.
|
|
|
|
3. **Neue Entscheidung**
|
|
- Der Nutzer muss auswaehlen, bestaetigen, abbrechen, wechseln oder fortfahren.
|
|
|
|
4. **Risiko-Moment**
|
|
- Loeschen, sperren, Rechte fehlen, Zahlung offen, Datenverlust, irreversible Aktion.
|
|
|
|
5. **Bespoke UI**
|
|
- Kanban, Kalender, Plantafel, Flow-Editor, Form-Builder, Chat, Cmd+K, Public Booking.
|
|
|
|
6. **Auth oder Public**
|
|
- Screens ohne normale App-Shell oder mit hoher Aussenwirkung.
|
|
|
|
---
|
|
|
|
## 5. Was wird nicht als eigener Subframe-Screen gebaut?
|
|
|
|
Diese Dinge werden meistens dokumentiert, aber nicht als eigener Frame gebaut:
|
|
|
|
- normaler Error-Banner auf einer bestehenden Seite
|
|
- Toast nach Speichern, Loeschen oder Export
|
|
- Field-Error in einem Standardformular
|
|
- Empty-State einer normalen Liste, wenn A7 schon greift
|
|
- Loading-Skeleton einer normalen Seite
|
|
- Permission-State, wenn er nur Standard-A7 ist
|
|
- zweite oder dritte Liste mit gleicher Struktur
|
|
- Standard-Confirm-Modal ohne besondere Logik
|
|
- Hover, Focus, Disabled, Pressed
|
|
|
|
Ausnahme: Wenn der Zustand die Bedienung oder Struktur veraendert, wird er gebaut.
|
|
|
|
Beispiel: Account gesperrt und alle Aktionen sind deaktiviert, nur "Zahlung aktualisieren" bleibt moeglich.
|
|
|
|
---
|
|
|
|
## 6. Banner, Toasts und Inline-Meldungen
|
|
|
|
Banner und Meldungen gehoeren immer zum Screen-Paket, auch wenn sie nicht als eigener Frame gebaut werden.
|
|
|
|
### Entscheidungs-Hierarchie
|
|
|
|
| UI-Form | Wann verwenden? | Typische Beispiele | Meist bauen? |
|
|
|---|---|---|---|
|
|
| Inline | betrifft genau ein Feld und kann direkt dort korrigiert werden | Pflichtfeld fehlt, E-Mail ungueltig, Passwort zu kurz, 2FA-Code falsch | nein |
|
|
| Screen-Banner | betrifft den aktuellen Screen oder das aktuelle Formular | Login-Daten falsch, Captcha erforderlich, Formular konnte nicht gespeichert werden | nur wenn optisch/fachlich wichtig |
|
|
| Globaler Banner | betrifft App/Shell oder Tenant/Account allgemein | Zahlung offen, Tenant gesperrt, Wartung | D0/App-Shell |
|
|
| Toast | kurze Rueckmeldung nach Aktion, nicht blockierend | gespeichert, kopiert, Einladung versendet, Export gestartet | nein |
|
|
| Modal/Dialog | Nutzer muss bestaetigen oder kurz entscheiden, bleibt aber im Kontext | loeschen bestaetigen, Rolle wechseln, Reassign bestaetigen | falls eigener Entscheidmoment |
|
|
| Eigener Screen | Nutzer ist blockiert, in neuem Flow-Status oder braucht klare naechste Schritte | Link abgelaufen, Magic-Link gesendet, 2FA nicht verfuegbar, Account gesperrt | ja |
|
|
|
|
### Entscheidungsfragen
|
|
|
|
- Kann der Nutzer direkt im Feld korrigieren? Dann `Inline`.
|
|
- Bleibt der Nutzer im selben Screen und kann dort weiterarbeiten? Dann `Banner`.
|
|
- Ist es nur eine kurze Rueckmeldung nach einer Aktion? Dann `Toast`.
|
|
- Muss der Nutzer bestaetigen oder eine kleine Entscheidung treffen, ohne den Screen zu verlassen? Dann `Modal/Dialog`.
|
|
- Ist der Nutzer blockiert oder in einem neuen Flow-Zustand? Dann `eigener Screen`.
|
|
- Ist Sicherheit, Zugang, Vertrauen oder rechtlicher Kontext betroffen? Eher `Banner` oder `Screen`, nicht Toast.
|
|
- Darf die Meldung verschwinden? Wenn nein, kein Toast.
|
|
|
|
### Blockierende Error States
|
|
|
|
Blockierende Error States muessen im Screen-Paket genauer beschrieben werden.
|
|
|
|
Pflichtangaben:
|
|
|
|
- sichtbarer Titel oder Kernaussage
|
|
- Ursache in Nutzersprache
|
|
- naechste Primaeraktion
|
|
- sekundare Aktion, z. B. zurueck oder Support/Admin kontaktieren
|
|
- ob der Nutzer im aktuellen Screen bleiben kann oder einen eigenen Screen braucht
|
|
|
|
Beispiel:
|
|
|
|
| Ereignis | UI-Form | Bauen? | Inhalt |
|
|
|---|---|---|---|
|
|
| 2FA nicht verfuegbar | Eigener Screen | ja | 2FA kann nicht uebersprungen werden, Admin kontaktieren |
|
|
| Reset-Link abgelaufen | Eigener Screen | ja | Link ist nicht mehr gueltig, neuen Link anfordern |
|
|
| 2FA-Code falsch | Inline | nein | Code pruefen und erneut eingeben |
|
|
|
|
### Globale Banner
|
|
|
|
Gehoeren zur App-Shell/D0 und koennen ueberall auftauchen.
|
|
|
|
Beispiele:
|
|
|
|
- Zahlung offen
|
|
- Tenant gesperrt
|
|
- Account frozen
|
|
- Loeschung vorgemerkt
|
|
- Systemwartung
|
|
|
|
### Screen-Banner
|
|
|
|
Gehoeren direkt zum jeweiligen Screen.
|
|
|
|
Beispiele:
|
|
|
|
- Projekt ist abgeschlossen
|
|
- Lead hat keine Weiterverarbeitungsfreigabe
|
|
- Dieses Formular ist unveroeffentlicht
|
|
- Verbindung zu Integration fehlgeschlagen
|
|
|
|
### Action-Feedback
|
|
|
|
Wird bei der jeweiligen Aktion dokumentiert.
|
|
|
|
Beispiele:
|
|
|
|
- gespeichert
|
|
- geloescht
|
|
- Export gestartet
|
|
- Export fehlgeschlagen
|
|
- Einladung versendet
|
|
|
|
Regel: Banner, Toast oder Inline-Meldung nur bauen, wenn sie den Screen optisch oder funktional wesentlich veraendert. Sonst im Markdown dokumentieren.
|
|
|
|
---
|
|
|
|
## 7. Subframe-Grid-Regeln
|
|
|
|
Subframe wird wie ein Flow-Board genutzt.
|
|
|
|
### Hauptflow
|
|
|
|
- Der Hauptflow laeuft von links nach rechts.
|
|
- Jeder naechste Hauptschritt liegt eine Spalte weiter rechts.
|
|
- Der Happy Path bleibt in einer horizontalen Linie.
|
|
|
|
### Varianten und Branches
|
|
|
|
- Eine Variante geht eine Reihe nach unten.
|
|
- Zwei Varianten gehen zwei Reihen nach unten.
|
|
- Drei Varianten gehen drei Reihen nach unten.
|
|
- Jede Variante laeuft danach wieder nach rechts weiter.
|
|
|
|
Beispiel:
|
|
|
|
```text
|
|
S01 Login -> S02 2FA -> S03 Profil-Auswahl -> S04 Dashboard
|
|
|
|
|
v
|
|
B01 2FA gesperrt -> B02 Wiederherstellungscode
|
|
```
|
|
|
|
### Wann wird ein neuer Flow gebaut?
|
|
|
|
Ein neuer Flow wird gebaut, wenn:
|
|
|
|
- die Variante mehr als 2-3 eigene Screens braucht
|
|
- die Variante eine eigene Nutzeraufgabe ist
|
|
- eine andere Rolle betroffen ist
|
|
- die Grid-Ansicht unuebersichtlich wird
|
|
- ein Screen sehr spezifisch oder bespoke wird
|
|
- ein anderer Modulbereich beginnt
|
|
|
|
Regel: Lieber ein sauberer kleiner Flow als ein riesiges unlesbares Board.
|
|
|
|
### Canvas-Qualitaetsregeln
|
|
|
|
Jede Canvas-Datei muss vor Abschluss lesbar geprueft werden.
|
|
|
|
Pflichtregeln:
|
|
|
|
- Nodes gross genug anlegen, damit Titel und Inhalt lesbar bleiben.
|
|
- Gruppen brauchen genug Padding; Gruppenlabels duerfen keine Nodes oder Kanten verdecken.
|
|
- Kanten duerfen nicht durch andere Nodes laufen.
|
|
- Lange Kantenlabels vermeiden.
|
|
- Kantenlabels sind erlaubt, wenn genug Abstand zwischen den Karten ist.
|
|
- Labels kurz halten, z. B. `Magic-Link`, `falsch`, `Captcha`, `gesperrt`, `2FA`, `ok`.
|
|
- Wenn Labels ueber Nodes oder Gruppen liegen, Karten weiter auseinanderziehen statt die Labels direkt zu entfernen.
|
|
- Keine direkte Kante bauen, wenn sie durch einen anderen wichtigen Schritt laeuft.
|
|
- Outcomes duerfen als Text-Node dokumentiert werden, wenn sie keine eigenen Screens sind.
|
|
- Nach dem Schreiben der Canvas muss JSON validiert werden.
|
|
|
|
Richtwerte:
|
|
|
|
| Element | Mindestgroesse |
|
|
|---|---|
|
|
| File-Node | 360 x 170 |
|
|
| Text-Node | 420 x 170 |
|
|
| Gruppe | mindestens 80 px Padding um Nodes |
|
|
|
|
---
|
|
|
|
## 8. Umsetzung und Status
|
|
|
|
### Umsetzung
|
|
|
|
`Umsetzung` beschreibt, was mit dem Screen oder Zustand gemacht wird.
|
|
|
|
| Wert | Bedeutung |
|
|
|---|---|
|
|
| Bauen | Eigener Screen/Frame in Subframe |
|
|
| Wiederverwenden | vorhandenes Pattern/Archetyp reicht |
|
|
| Nur dokumentieren | kein Frame, aber im Markdown beschreiben |
|
|
| Spaeter | bewusst noch nicht jetzt |
|
|
| Raus | nicht im Scope |
|
|
|
|
### Status
|
|
|
|
`Status` beschreibt, wie weit der Eintrag gerade ist.
|
|
|
|
| Wert | Bedeutung |
|
|
|---|---|
|
|
| Idee | noch nicht entschieden |
|
|
| Brainstormed | grob besprochen |
|
|
| Validiert | entschieden, kann gebaut/dokumentiert werden |
|
|
| In Subframe | wird gerade gebaut |
|
|
| Review | gebaut, muss geprueft werden |
|
|
| Fertig | bereit zur Uebergabe |
|