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