Finalize D-D0b layout standards
This commit is contained in:
david committed
1 parent
be2054274d
commit
a18acf4900
15 files changed
+4737
-137
No files matched your search
@@ -0,0 +1,48 @@
|
||||
---
|
||||
kind: backlog
|
||||
ticket: D-D0b
|
||||
area: Layout Standards
|
||||
status: Offen
|
||||
stand: 2026-07-02
|
||||
---
|
||||
|
||||
# D-D0b Backlog
|
||||
|
||||
Diese Datei sammelt Folgepunkte aus `D-D0b Layout Standards`, die nicht Teil des abgeschlossenen ersten Standards-Durchgangs sind.
|
||||
|
||||
Die Punkte sind nicht blockierend fuer den aktuellen Handoff.
|
||||
|
||||
## Layout / Responsive
|
||||
|
||||
| Thema | Warum spaeter? | Status |
|
||||
|---|---|---|
|
||||
| Mobile Layout Standards | Mobile wurde in D-D0b bewusst nicht validiert. Padding, Breakpoints, mobile App-Shell und mobile Dialogverhalten brauchen eine eigene Runde. | Backlog |
|
||||
| Drawer / Side Panel Breitenregeln | Drawer wurden begrifflich abgegrenzt, aber noch nicht mit festen Breiten, Padding und Responsiveness validiert. | Backlog |
|
||||
| Toolbar-zu-Tabelle-Abstand | Nur relevant, wenn Table-/Toolbar-Komponenten den Abstand nicht bereits sauber abdecken. | Beobachten |
|
||||
|
||||
## Komponenten / Semantik
|
||||
|
||||
| Thema | Warum spaeter? | Status |
|
||||
|---|---|---|
|
||||
| Button-/Action-Semantik | Klaeren, wann Actions Primary, Secondary, Destructive oder Positive sind. Destructive ist eindeutig rot, Confirm aber nicht automatisch gruen. | Backlog |
|
||||
| Error-/Result-Dialog-Komponenten | Spaeter klaeren, welche blockierenden Fehler als `Result Dialog`, `Confirm Dialog` oder eigene Error-Dialog-Variante laufen. Normale Bereichsfehler bleiben inline. | Backlog |
|
||||
| No-Permission-Komponente | No Permission ist fachlich als inline State geklaert, aber lokal noch nicht als eigene Komponenten-MD finalisiert. | Backlog |
|
||||
| Table No-Permission State | Klaeren, ob die bestehende Table-Komponente eine eigene No-Permission-State-Variante braucht. | Backlog |
|
||||
| Fill Buttons fuer XS/S Dialoge | Fuer XS/S-Dialoge mit genau zwei Actions koennte eine Fill-Buttons-Variante sinnvoll sein. Noch nicht validiert. | Optional |
|
||||
|
||||
## Standards / Research
|
||||
|
||||
| Thema | Warum spaeter? | Status |
|
||||
|---|---|---|
|
||||
| Weitere IBM-Carbon-Spacing-Inspiration | Carbon wurde fuer D-D0b als Referenz genutzt, ist aber keine harte Regelquelle. Weitere Details nur bei konkretem Bedarf. | Backlog |
|
||||
| Accessibility-Regeln | Wichtig, aber nicht Teil des ersten Layout-Standards-Durchgangs. | Backlog |
|
||||
| Vollstaendige Komponenten-Dokumentation | Erst noetig, wenn eine Komponente echte Regeln oder Ausnahmen braucht. | Backlog |
|
||||
|
||||
## Nicht in D-D0b aufnehmen
|
||||
|
||||
Diese Themen gehoeren nicht in D-D0b:
|
||||
|
||||
- Farben, Shadows und Radius, solange sie groesstenteils in Subframe gepflegt werden.
|
||||
- Fachliche Feature-Flows.
|
||||
- Backend-/Datenmodell-Logik.
|
||||
- Vollstaendige App-Shell-Definition.
|
||||
+188
-108
@@ -1,157 +1,237 @@
|
||||
---
|
||||
kind: brainstorming
|
||||
kind: final-planning
|
||||
ticket: D-D0b
|
||||
area: Layout Standards
|
||||
status: In Planung
|
||||
status: Abgeschlossen
|
||||
stand: 2026-07-02
|
||||
---
|
||||
|
||||
# D-D0b Layout Brainstorming
|
||||
# D-D0b Layout Standards
|
||||
|
||||
## Ziel
|
||||
## Kurzfassung
|
||||
|
||||
D-D0b wird fuer diese Runde als Layout- und Composition-Standard geplant, nicht als Komponenten-Katalog.
|
||||
D-D0b definiert die ersten systemweiten Layout- und Composition-Standards fuer HiveGrid-Screens. Das Ticket ist abgeschlossen und die validierten Regeln wurden in die dauerhaften Subframe UI Standards uebertragen.
|
||||
|
||||
Source of Truth fuer spaetere Screen-Arbeit:
|
||||
|
||||
- [Subframe UI Standards / Layout-Regeln](<../../../04 Standards/Subframe UI Standards/Layout/README.md>)
|
||||
- [Subframe UI Standards / Entscheidungen](<../../../04 Standards/Subframe UI Standards/02_Entscheidungen.md>)
|
||||
- [D-D0b Backlog](<D-D0b Backlog.md>)
|
||||
|
||||
Lokale Vorschau:
|
||||
|
||||
- Versioniertes Ticket-Artefakt: [D-D0b Layout Preview](<../../../Tickets/Fertige Tickets/Assets/D-D0b-Layout-Preview.html>)
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
- Die Preview bleibt als lokale Arbeitskopie erhalten, ist aber kein Source of Truth.
|
||||
- `99 Temp/` ist per `.gitignore` ausgeschlossen.
|
||||
- Wenn Regeln spaeter abweichen, gelten die Markdown-Standards, nicht die HTML-Preview.
|
||||
|
||||
## Scope
|
||||
|
||||
Fokus:
|
||||
- Layout-Raster und Page Padding
|
||||
- Textabstaende und vertikale Rhythmik
|
||||
- Breiten fuer kleine, normale und grosse Dialoge
|
||||
- Form-, Tabellen-, Listen- und Settings-Composition
|
||||
- Zustandsflaechen wie Empty, Loading, Error, No Permission
|
||||
|
||||
- Layout-Raster und erlaubte Abstandswerte.
|
||||
- Page-, Card-, Surface- und Grid-Abstaende.
|
||||
- Text-Rhythmus fuer Page- und Section-Header.
|
||||
- Dialog- und Fullscreen-Dialog-Groessen.
|
||||
- Dialog-interne Gaps.
|
||||
- Ownership-Grenzen fuer Buttons, Formulare, Tabellen und States.
|
||||
|
||||
Nicht Fokus:
|
||||
- konkrete Subframe-Komponenten
|
||||
- App-Shell-Definition
|
||||
- fachliche Feature-Flows
|
||||
- Backend-/Datenmodell-Logik
|
||||
|
||||
## Temporaeres Preview-Lab
|
||||
- Konkrete Fachflows.
|
||||
- Backend-/Datenmodell-Logik.
|
||||
- App-Shell-Definition.
|
||||
- Vollstaendige Komponenten-Spezifikation.
|
||||
- Mobile Layout Standards.
|
||||
|
||||
Lokales Preview-Lab:
|
||||
## Entscheidungsuebersicht
|
||||
|
||||
`99 Temp/D-D0b Layout Preview/index.html`
|
||||
| ID | Thema | Status | Ergebnis |
|
||||
|---|---|---|---|
|
||||
| D01 | Grundraster / Spacing Scale | Validiert | 8px-Rhythmus mit erlaubten Standardwerten |
|
||||
| D02 | Page, Card und Grid Padding | Validiert | Page 24px, Card/Surface 16px, Grid/Card Gap 16px |
|
||||
| D03 | Text-Rhythmus | Validiert | Token-aware: 0 / 24 / 0 / 12 |
|
||||
| D04 | Button Ownership | Geklaert | Button-Details kommen aus der Button-Komponente |
|
||||
| D05 | Form Layout Gap | Validiert | Komplette Field-Komponenten stehen 16px auseinander |
|
||||
| D06 | Table Ownership | Geklaert | Tabellen-Dichte kommt aus der Table-Komponente |
|
||||
| D07 | Dialoge | Validiert | XS 420, S 560, M 720, L 1200; Fullscreen max 2512 |
|
||||
| D08 | Dialog Internal Gaps | Validiert | Balanced: 8 / 16 / 24 / 8 |
|
||||
| D09 | States / Component Ownership | Geklaert | Empty/Error/No-Permission sind inline Komponenten-Zustaende |
|
||||
|
||||
Dieses Lab dient nur dazu, Layoutgroessen und Abstaende visuell zu entscheiden. Es ist kein Source of Truth und darf nicht als finaler Screen oder Komponentenbibliothek behandelt werden.
|
||||
## Validierte Standards
|
||||
|
||||
Wichtig:
|
||||
- Der Ordner `99 Temp/` ist per `.gitignore` ausgeschlossen.
|
||||
- Nach Abschluss der D-D0b-Brainstorming- und Validierungsrunde muss `99 Temp/D-D0b Layout Preview/` geloescht werden.
|
||||
- Validierte Entscheidungen werden danach in diese D-D0b-Dokumentation uebertragen.
|
||||
- Nicht validierte Varianten bleiben nicht als finale Regel stehen.
|
||||
### D01 Grundraster / Spacing Scale
|
||||
|
||||
## Preview-Visualisierung
|
||||
HiveGrid nutzt einen 8px-Rhythmus als Hauptstandard.
|
||||
|
||||
Im lokalen Preview-Lab werden Abstaende visuell markiert:
|
||||
Erlaubte Standardwerte:
|
||||
|
||||
- Lila = `Padding` / Innenabstand.
|
||||
- Tuerkis = `Gap` / Abstand zwischen getrennten Elementen.
|
||||
- Weiss = eigentlicher Inhalt / Content.
|
||||
`4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96`
|
||||
|
||||
Begriffe:
|
||||
Regeln:
|
||||
|
||||
- `Padding`: Innenabstand innerhalb eines Containers. Beispiel: Abstand zwischen Kartenrand und Karteninhalt, zwischen Dialogrand und Dialoginhalt, zwischen Tabellenzellenrand und Zelltext oder zwischen Buttonrand und Buttonlabel.
|
||||
- `Gap`: Abstand zwischen mehreren Elementen innerhalb eines Layouts. Beispiel: Abstand zwischen Formularfeldern, Karten, Buttons oder Layout-Spalten.
|
||||
- `Margin`: Aussenabstand eines einzelnen Elements zu anderen Bereichen. In den HiveGrid-Layout-Regeln soll bevorzugt mit Auto Layout/Flex/Grid-Gaps gearbeitet werden, weil das konsistenter steuerbar ist.
|
||||
- `8px` ist die Basislogik fuer normale Layout-Gaps und Paddings.
|
||||
- `4px`, `12px` und `20px` sind erlaubte Zwischenwerte fuer kompakte UI-Situationen, Field-Anatomy, kleine Icon-/Text-Abstaende oder feinere visuelle Gewichtung.
|
||||
- `2px` ist kein normaler Layout-Abstand und darf nur fuer technische Feinkorrekturen wie Border-, Focus- oder Icon-Feintuning genutzt werden.
|
||||
- Werte wie `6px`, `10px`, `14px`, `28px`, `36px` oder `44px` werden nicht als Standard neu eingefuehrt. Sie duerfen nur vorkommen, wenn eine bestehende Komponente, ein vorhandener Token oder eine technische Vorgabe sie bereits mitbringt.
|
||||
|
||||
Regel fuer das Preview:
|
||||
### D02 Page, Card und Grid Padding
|
||||
|
||||
- Die Preview-Seite muss sich selbst an die Regeln halten, die sie gerade testet. Keine zusaetzlichen Zufallsabstaende nur fuer die Demo.
|
||||
- Nur der jeweils relevante Abstand soll visuell markiert werden.
|
||||
- Wenn es um Card Padding geht, wird die Card-Innenflaeche markiert.
|
||||
- Wenn es um Dialog Padding geht, wird Header/Body/Footer-Innenabstand markiert.
|
||||
- Wenn es um Tabellen geht, wird Cell Padding markiert.
|
||||
- Wenn es um Formularabstaende geht, muss klar unterschieden werden zwischen Input-Padding und Field-Gap.
|
||||
Validierte Standards:
|
||||
|
||||
## Carbon-Referenzen
|
||||
- `Page Padding Standard`: 24px.
|
||||
- `Page Padding Minimum`: 24px.
|
||||
- `Card / Surface Padding Standard`: 16px.
|
||||
- `Detail-/Editor-Surface Padding Standard`: 16px.
|
||||
- `Grid / Card Gap Standard`: 16px.
|
||||
- `Grid / Card Gap kompakter Sonderfall`: 12px fuer enge oder sehr dichte Teilbereiche.
|
||||
- `Section Gap Standard`: 24px fuer groessere inhaltliche Bereiche.
|
||||
|
||||
- 2x Grid: https://carbondesignsystem.com/elements/2x-grid/overview/
|
||||
- Spacing: https://carbondesignsystem.com/elements/spacing/overview/
|
||||
- Modal Usage: https://carbondesignsystem.com/components/modal/usage/
|
||||
- Forms Pattern: https://carbondesignsystem.com/patterns/forms-pattern/
|
||||
Regeln:
|
||||
|
||||
## Subframe UI Standards als zentrale Shell
|
||||
- Standard Desktop Pages und kompakte Settings Pages nutzen bei diesen Basiswerten dieselbe Spacing-Logik.
|
||||
- Page Padding gehoert dem Page-/Content-Container nach der App Shell.
|
||||
- Card/Surface Padding gehoert der Card-, Surface- oder Panel-Komponente.
|
||||
- Kompakte Momente reduzieren nicht das Page Padding, sondern nur lokale Gaps/Abstaende innerhalb dichter UI-Bereiche.
|
||||
- 32px Innenabstand ist kein frei zu verwendender Surface-Standard. Ausnahme: Die Subframe-`Dialog`-Komponente darf eine eigene 32px-Padding-Variante besitzen.
|
||||
|
||||
Die Subframe UI Standards liegen als eigenes Standards-Projekt im Repo:
|
||||
### D03 Text-Rhythmus
|
||||
|
||||
- [00_HiveGrid-Einordnung](<../../../04 Standards/Subframe UI Standards/00_HiveGrid-Einordnung.md>)
|
||||
- [Subframe UI Standards Start](<../../../04 Standards/Subframe UI Standards/00_Start.md>)
|
||||
- [Layout-Regeln](<../../../04 Standards/Subframe UI Standards/Layout/README.md>)
|
||||
D03 definiert vertikale Gaps zwischen Page-/Section-Textbloecken und Content. Diese Regel gilt nur zusammen mit 150%-Texttokens fuer beschreibende Texte.
|
||||
|
||||
Zweck:
|
||||
Validierte Standards:
|
||||
|
||||
- D-D0b bleibt der Arbeits- und Validierungsort fuer Layout-Entscheidungen.
|
||||
- Die Subframe UI Standards sind die dauerhafte Zielstruktur fuer systemweite Subframe-, Komponenten- und Layout-Standards.
|
||||
- Nach Davids Validierung koennen D-D0b-Entscheidungen in den Layout-Bereich der Subframe UI Standards uebertragen werden.
|
||||
- `Page Title -> Page Description`: 0px.
|
||||
- `Page Header -> erster Content`: 24px.
|
||||
- `Section Title -> Section Description`: 0px.
|
||||
- `Section Description -> Section Content`: 12px.
|
||||
|
||||
Abgrenzung:
|
||||
Regeln:
|
||||
|
||||
- Keine Regel in den Subframe UI Standards wird durch diese D-D0b-Datei automatisch geaendert.
|
||||
- Keine unvalidierten D-D0b-Werte werden als finale Subframe-Regel gespeichert.
|
||||
- Wenn eine Layout-Regel uebertragen wird, muss klar sein, ob sie allgemein gilt oder nur fuer bestimmte Layout-Archetypen.
|
||||
- `0px` ist ein bewusst definierter Gap. Es bedeutet: Kein zusaetzlicher Auto-Layout-Abstand zwischen Titel und Beschreibung.
|
||||
- Page- und Section-Beschreibungen muessen 150%-Texttokens nutzen, auch wenn sie gerade nur eine Zeile lang sind.
|
||||
- Die 150%-Line-height erzeugt bereits optische Hoehe im Textblock. Deshalb wird zwischen Titel und Beschreibung kein zusaetzlicher Gap addiert.
|
||||
- D03-Gaps werden zwischen gerenderten Textboxen gemessen, nicht zwischen einzelnen Buchstaben oder optischen Glyphen.
|
||||
- Wenn eine Beschreibung durch kleinere Breite von einer auf zwei Zeilen springt, wird nur der Textblock hoeher. Der Gap zum naechsten Content bleibt gleich.
|
||||
- `0`-Line-height-Tokens duerfen nicht fuer Texte genutzt werden, die umbrechen koennen.
|
||||
- `0`-Line-height-Tokens bleiben fuer garantierte Einzeiler reserviert, z. B. Button Label, Badge, Tab, kurze Navigation oder kompakte Tabellenzellen mit Truncation.
|
||||
|
||||
## Erste Entscheidungsbereiche
|
||||
### D04 Button Component Ownership
|
||||
|
||||
Die Entscheidungen werden einzeln validiert. David muss nicht die komplette Seite auf einmal abnehmen.
|
||||
Button-Hoehen, Button-Innenpadding und Button-Varianten werden ueber die Button-Komponente abgedeckt.
|
||||
|
||||
Validierungsreihenfolge:
|
||||
Regeln:
|
||||
|
||||
| ID | Entscheidung | Worum es geht |
|
||||
|---|---|---|
|
||||
| D01 | Grundraster / Spacing Scale | Welche Abstandswerte sind erlaubt? |
|
||||
| D02 | Page & Card Padding | Wie viel Innenabstand bekommen Seiten, Karten, Dialogbereiche, Tabellenzellen und Buttons? |
|
||||
| D03 | Text-Rhythmus | Wie nah stehen Titel, Beschreibung und erster Inhalt zusammen? |
|
||||
| D04 | Buttons | Welche Button-Hoehen und horizontalen Innenabstaende wirken richtig? |
|
||||
| D05 | Formulare | Wie dicht stehen Formularfelder, Labels und Help/Error-Texte? |
|
||||
| D06 | Tabellen | Welche Row Height und welches Cell Padding gelten fuer Admin-Tabellen? |
|
||||
| D07 | Dialoge | Welche Breiten gelten fuer kleine, normale und grosse Dialoge? |
|
||||
| D08 | States | Wie gross sind Empty, Error und No-Permission-Bereiche? |
|
||||
- Fuer Standardaktionen in Screens wird die Default-Variante der Button-Komponente genutzt.
|
||||
- Die Default-Variante entspricht `Medium` und ist 36px hoch.
|
||||
- Screen-Layouts sollen Button-Hoehen oder Button-Padding nicht manuell nachbauen.
|
||||
- Action-Semantik wie Primary, Secondary, Destructive oder Positive wird separat validiert.
|
||||
|
||||
Arbeitsregel:
|
||||
- Der Agent fuehrt David immer nur durch die naechste offene Entscheidung.
|
||||
- Jede Entscheidung wird erst dokumentiert, wenn David sie explizit validiert hat.
|
||||
- Wenn eine Entscheidung spaeter geaendert wird, muss ein Impact-Check auf die anderen Layout-Regeln erfolgen.
|
||||
### D05 Form Layout Gap
|
||||
|
||||
### 1. Grundraster
|
||||
Validierte Regel:
|
||||
|
||||
Zu klaeren:
|
||||
- Ist ein 8px-Rhythmus als Hauptstandard passend?
|
||||
- Welche Zwischenwerte sind erlaubt: 4px, 12px, 20px?
|
||||
- Welche Abstaende gelten fuer eng verwandte Elemente, Feldgruppen und grosse Sections?
|
||||
- Komplette Formular-Field-Komponenten stehen standardmaessig 16px auseinander.
|
||||
- 12px bleibt ein kompakter Sonderfall fuer sehr dichte Teilbereiche.
|
||||
- 24px wird fuer bewusst getrennte Formular-Sections genutzt, nicht als Standardabstand zwischen einzelnen Feldern.
|
||||
|
||||
### 2. Page Padding
|
||||
Komponenten-Ownership:
|
||||
|
||||
Zu klaeren:
|
||||
- Standard Desktop Page Padding
|
||||
- kompakter Admin-/Settings-Padding-Standard
|
||||
- Umgang mit Tabellen: full width vs. constrained
|
||||
- Label/Input-Abstand, Help-/Description-Text, Error-/Message-Abstand und Input-Padding gehoeren zur jeweiligen Form-Input-Komponente.
|
||||
- Wenn ein Screen gebaut wird, soll die vorhandene Field-Anatomy der Komponente genutzt werden.
|
||||
- Beschreibungen/Hilfetexte werden ueber die entsprechenden Komponentenfelder/Props/Slots ausgefuellt, nicht als manuelle Textbloecke neben das Input gebaut.
|
||||
|
||||
### 3. Text-Rhythmik
|
||||
### D06 Table Layout Ownership
|
||||
|
||||
Zu klaeren:
|
||||
- Abstand Page Title zu Subtitle
|
||||
- Abstand Subtitle zu erstem Content
|
||||
- Abstand Section Title zu Beschreibung
|
||||
- Abstand Beschreibung zu Inhalt
|
||||
Row Height, Cell Padding, Header-Dichte und Tabellenvarianten werden ueber die Table-Komponente abgedeckt.
|
||||
|
||||
### 4. Formulare
|
||||
Regeln:
|
||||
|
||||
Zu klaeren:
|
||||
- Label/Input-Abstand
|
||||
- Input/Help/Error-Abstand
|
||||
- Abstand zwischen Feldern
|
||||
- Abstand zwischen Form-Sections
|
||||
- Screen-Layouts sollen Tabellen-Padding oder Row-Hoehen nicht manuell nachbauen.
|
||||
- IBM Carbon dient als Referenz: Data Tables haben mehrere Row Sizes (`xs 24px`, `sm 32px`, `md 40px`, `lg 48px`, `xl 64px`), Column Padding von 16px und die Header Row soll zur Tabellen-Row-Groesse passen.
|
||||
- Fuer HiveGrid gilt: Table-Komponente verwenden und deren passende Dichte waehlen, statt in einzelnen Screens eigene Tabellenwerte zu definieren.
|
||||
|
||||
### 5. Dialogbreiten
|
||||
### D07 Dialog, Fullscreen Dialog und Drawer
|
||||
|
||||
Zu klaeren:
|
||||
- kleine Confirm-Dialoge
|
||||
- normale Formular-Dialoge
|
||||
- grosse Editor-Dialoge
|
||||
- maximale Breite relativ zum Viewport
|
||||
Pattern-Definition:
|
||||
|
||||
### 6. Listen und Tabellen
|
||||
- `Page`: eigener Ort in der App. Wird genutzt fuer Bereiche, in denen laenger gearbeitet wird, die eigene Navigation/Subnavigation haben oder spaeter direkt adressierbar sein sollen.
|
||||
- `Dialog`: temporaeres Overlay ueber der aktuellen Page. Blockiert den Hintergrund, hat einen klaren Abschluss und fuehrt den User danach zur vorherigen Page zurueck.
|
||||
- `Fullscreen Dialog`: temporaeres Overlay wie ein Dialog, aber fast oder ganz viewportfuellend. Keine normale Page.
|
||||
- `Drawer / Side Panel`: seitliches Overlay oder Panel, meistens rechts, wenn der Kontext sichtbar bleiben soll.
|
||||
|
||||
Zu klaeren:
|
||||
- Toolbar zu Tabelle
|
||||
- Row Height
|
||||
- Zell-Padding
|
||||
- Empty/Loading/Error-Bereich
|
||||
Zentrierte Dialoge:
|
||||
|
||||
- `XS`: 420px.
|
||||
- `S`: 560px.
|
||||
- `M`: 720px.
|
||||
- `L`: 1200px max.
|
||||
|
||||
Fullscreen Dialog:
|
||||
|
||||
- `width: calc(100vw - 48px)`.
|
||||
- `max-width: 2512px`.
|
||||
- `height: calc(100vh - 48px)`.
|
||||
- 24px aeusserer Rand pro Seite auf Desktop.
|
||||
- Auf breiteren Monitoren bleibt der Fullscreen Dialog zentriert und skaliert nicht unendlich.
|
||||
|
||||
Dialog Padding:
|
||||
|
||||
- `16px` als Default.
|
||||
- `32px` als groessere/ruhigere Variante fuer Dialoge, die bewusst mehr Innenraum brauchen.
|
||||
- Diese Werte sollen ueber die Dialog-Komponente bzw. deren Varianten kommen, nicht durch freie Padding-Overrides im Screen.
|
||||
|
||||
### D08 Dialog Internal Gaps
|
||||
|
||||
Die Subframe-`Dialog`-Komponente nutzt fuer normale Dialog-Innenabstaende die `Balanced`-Logik:
|
||||
|
||||
- `Title -> Description`: 8px.
|
||||
- `Field / Form Row Gap`: 16px.
|
||||
- `Section Gap innerhalb Dialog`: 24px.
|
||||
- `Footer Button Gap`: 8px.
|
||||
- Footer Actions sind standardmaessig rechts ausgerichtet.
|
||||
|
||||
Regeln:
|
||||
|
||||
- Diese Werte beschreiben Gaps zwischen gerenderten Bloecken, nicht manuelle Text-Margins.
|
||||
- Mehrzeiliger Text nutzt den jeweiligen 150%-Texttoken. Dadurch wird der Textblock hoeher; es wird kein zusaetzlicher Sonder-Gap oberhalb oder unterhalb des Texts addiert.
|
||||
- Eine `Fill Buttons`-Variante fuer XS/S-Dialoge mit genau zwei Actions bleibt optional und muss separat validiert werden, falls sie gebraucht wird.
|
||||
- Destructive/positive Action-Farben werden nicht allein aus `Cancel/Confirm` abgeleitet. Sie muessen semantisch zur Aktion passen und werden separat als Button-/Action-Regel validiert.
|
||||
|
||||
### D09 States / Component Ownership
|
||||
|
||||
States sind inline Inhaltszustaende, keine Modale.
|
||||
|
||||
Regeln:
|
||||
|
||||
- Empty, Error und No-Permission ersetzen inline den betroffenen Inhaltsbereich.
|
||||
- Empty State und Error State sind bereits im Komponenten-Index vorhanden.
|
||||
- Normale Bereichsfehler sollen ueber State-/Alert-/Partial-page-failure-Komponenten abgedeckt werden.
|
||||
- Blockierende Error-/Result-Dialoge werden spaeter separat als Overlay-/Feedback-Komponenten geklaert.
|
||||
|
||||
## Anwendung fuer neue Screens
|
||||
|
||||
Beim Erstellen neuer Screens gilt:
|
||||
|
||||
- Die validierten Standards aus [Subframe UI Standards / Layout-Regeln](<../../../04 Standards/Subframe UI Standards/Layout/README.md>) verwenden.
|
||||
- Komponenten-Defaults verwenden, wenn sie den validierten Standard bereits abbilden.
|
||||
- Padding oder Gap nicht pseudomaessig nachbauen, wenn die zuständige Komponente dafuer bereits eine Eigenschaft, Variante oder Auto-Layout-Struktur hat.
|
||||
- Modale in Subframe als echte Dialog-Komponenten bauen, nicht als Fake-Modal auf einer normalen Page.
|
||||
- Page-/Section-Beschreibungen als 150%-Texttokens setzen, wenn sie umbrechen koennen.
|
||||
- `0px` bei D03 bewusst als definierten Gap behandeln und nicht aus Versehen durch 4px/8px ersetzen.
|
||||
- Backlog-Themen nicht in Screens erzwingen, solange sie nicht validiert sind.
|
||||
|
||||
## Backlog
|
||||
|
||||
Offene Folgepunkte stehen in [D-D0b Backlog](<D-D0b Backlog.md>).
|
||||
|
||||
## Externe Referenzen
|
||||
|
||||
- Carbon 2x Grid: https://carbondesignsystem.com/elements/2x-grid/overview/
|
||||
- Carbon Spacing: https://carbondesignsystem.com/elements/spacing/overview/
|
||||
- Carbon Typography: https://carbondesignsystem.com/elements/typography/overview/
|
||||
- Carbon Modal Usage: https://carbondesignsystem.com/components/modal/usage/
|
||||
- Carbon Forms Pattern: https://carbondesignsystem.com/patterns/forms-pattern/
|
||||
- Carbon Data Table Usage: https://carbondesignsystem.com/components/data-table/usage/
|
||||
- Carbon Data Table Style: https://carbondesignsystem.com/components/data-table/style/
|
||||
@@ -3,19 +3,19 @@
|
||||
{"id":"group-main","type":"group","x":-120,"y":-680,"width":4280,"height":1440,"label":"Admin RBAC Hauptflow"},
|
||||
{"id":"group-notes","type":"group","x":-120,"y":900,"width":4280,"height":430,"label":"Dokumentierte Zustaende und Backlog"},
|
||||
{"id":"s02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S02 Rollen und Berechtigungen.md","x":1560,"y":440,"width":440,"height":230},
|
||||
{"id":"note-navigation","type":"text","text":"# Navigation\n\nS01 ist der Einstieg unter `Settings -> Mitarbeiter`.\n\nDer Rollen-Tab S02 ist direkt ueber die Settings-Tabs erreichbar und zusaetzlich ueber den Dropdown-Eintrag `Rollen und Berechtigungen bearbeiten`.","x":-40,"y":1020,"width":520,"height":240},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/S01 Mitarbeiterliste.md","x":0,"y":45,"width":440,"height":230},
|
||||
{"id":"m03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md","x":780,"y":45,"width":440,"height":230},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md","x":780,"y":-360,"width":440,"height":230},
|
||||
{"id":"note-seed","type":"text","text":"# Rollenmodell\n\nAdmin ist die einzige Start-/Systemrolle.\n\nWeitere Rollen werden vom Admin selbst angelegt.\n\nRollen-Vorlagen sind Work in Progress und werden nicht als feste Rollen in der Liste gezeigt.","x":1520,"y":1020,"width":520,"height":240},
|
||||
{"id":"m02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md","x":2680,"y":440,"width":440,"height":230},
|
||||
{"id":"m04a","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04A Rolle anlegen.md","x":2120,"y":-110,"width":440,"height":230},
|
||||
{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md","x":2120,"y":-475,"width":440,"height":230},
|
||||
{"id":"note-d01","type":"text","text":"# D01 Rollen-Dropdown\n\nKein eigener Screen.\n\nDas Dropdown ist direkt in S01 enthalten:\n- Rolle wechseln\n- `Rollen und Berechtigungen bearbeiten` fuehrt zu S02\n- letzter Admin wird ueber V01 blockiert","x":720,"y":1015,"width":500,"height":250},
|
||||
{"id":"m04b","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M04B Rolle duplizieren.md","x":2980,"y":-110,"width":440,"height":230},
|
||||
{"id":"note-backlog","type":"text","text":"# Backlog / V2\n\nReassign beim Deaktivieren, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Review-Zyklus, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz.","x":3520,"y":1020,"width":600,"height":240},
|
||||
{"id":"d03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/D03 Rolle in Nutzung blockiert.md","x":3600,"y":440,"width":440,"height":230},
|
||||
{"id":"note-permission","type":"text","text":"# Permission-Muster\n\nIm Rollen-Modal wird eine konkrete Permission-Zeile vorgebaut:\n\n`Mitarbeiter ansehen`\nBeschreibung darunter\nControl: Toggle `An/Aus`\n\nRead-only/Bearbeiten bleibt spaeteres Advanced Control, falls ein Recht nicht binaer ist.\n\nFinaler Rechtekatalog liegt bei Development.","x":2620,"y":1000,"width":560,"height":280}
|
||||
{"id":"note-navigation","type":"text","text":"# Navigation\n\nS01 ist der Einstieg unter `Settings -> Mitarbeiter`.\n\nDer Rollen-Tab S02 ist direkt ueber die Settings-Tabs erreichbar und zusaetzlich ueber den Dropdown-Eintrag `Rollen und Berechtigungen bearbeiten`.","x":-40,"y":1020,"width":520,"height":240},
|
||||
{"id":"m02","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M02 Rolle bearbeiten.md","x":2680,"y":440,"width":440,"height":230},
|
||||
{"id":"note-d01","type":"text","text":"# D01 Rollen-Dropdown\n\nKein eigener Screen.\n\nDas Dropdown ist direkt in S01 enthalten:\n- Rolle wechseln\n- `Rollen und Berechtigungen bearbeiten` fuehrt zu S02\n- letzter Admin wird ueber V01 blockiert","x":720,"y":1015,"width":500,"height":250},
|
||||
{"id":"note-backlog","type":"text","text":"# Backlog / V2\n\nReassign beim Deaktivieren, Rollen-Loeschen mit Ersatzrolle, Gruppen, Rechtekatalog, Rollen-Audit, Review-Zyklus, Rechte-Matrix, Bulk-Aktionen, erweiterter Admin-Schutz.","x":3520,"y":1020,"width":600,"height":240},
|
||||
{"id":"note-permission","type":"text","text":"# Permission-Muster\n\nIm Rollen-Modal wird eine konkrete Permission-Zeile vorgebaut:\n\n`Mitarbeiter ansehen`\nBeschreibung darunter\nControl: Toggle `An/Aus`\n\nRead-only/Bearbeiten bleibt spaeteres Advanced Control, falls ein Recht nicht binaer ist.\n\nFinaler Rechtekatalog liegt bei Development.","x":2620,"y":1000,"width":560,"height":280},
|
||||
{"id":"v01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/V01 Letzter Admin blockiert.md","x":2120,"y":-440,"width":440,"height":230},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M01 Mitarbeiter einladen.md","x":1000,"y":-360,"width":440,"height":230},
|
||||
{"id":"m03","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Admin RBAC/Screens/M03 Mitarbeiter deaktivieren.md","x":1000,"y":5,"width":440,"height":230}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-m01","fromNode":"s01","fromSide":"right","toNode":"m01","toSide":"left","label":"Mitarbeiter einladen"},
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"group-main","type":"group","x":-80,"y":-100,"width":1260,"height":420,"label":"Backlog / geparkte Konto-Loeschung"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":1260,"height":360,"label":"Backlog-Hinweise"},
|
||||
{"id":"group-main","type":"group","x":-80,"y":-60,"width":1440,"height":420,"label":"Backlog / geparkte Konto-Loeschung"},
|
||||
{"id":"group-notes","type":"group","x":-80,"y":560,"width":1440,"height":360,"label":"Backlog-Hinweise"},
|
||||
{"id":"s01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/S01 Settings Workspaces Loeschbereich.md","x":0,"y":0,"width":420,"height":200},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/M01 Loeschung anfragen.md","x":640,"y":0,"width":420,"height":200},
|
||||
{"id":"note-request","type":"text","text":"# Backlog\n\nDer gesamte Konto-Loeschworkflow ist geparkt.\n\nBestehende Screens sind nur Referenz und werden nicht als aktueller v1-Scope weitergebaut.","x":0,"y":680,"width":420,"height":200},
|
||||
{"id":"note-permission","type":"text","text":"# Trennung\n\nAccount/Konto loeschen und Workspace loeschen sind zwei unterschiedliche Workflows.\n\nNicht in einem Screen vermischen.","x":540,"y":680,"width":420,"height":200},
|
||||
{"id":"note-backlog","type":"text","text":"# Voraussetzung\n\nErst wieder aufnehmen, wenn Workspace Settings gebaut/validiert sind.\n\nDanach Flow neu mit David validieren.","x":1080,"y":680,"width":420,"height":200}
|
||||
{"id":"note-permission","type":"text","text":"# Trennung\n\nAccount/Konto loeschen und Workspace loeschen sind zwei unterschiedliche Workflows.\n\nNicht in einem Screen vermischen.","x":0,"y":680,"width":420,"height":200},
|
||||
{"id":"note-request","type":"text","text":"# Backlog\n\nDer gesamte Konto-Loeschworkflow ist geparkt.\n\nBestehende Screens sind nur Referenz und werden nicht als aktueller v1-Scope weitergebaut.","x":860,"y":680,"width":420,"height":200},
|
||||
{"id":"m01","type":"file","file":"02 Wireframes/P2 Auth/WF-P2 Konto loeschen/Screens/M01 Loeschung anfragen.md","x":860,"y":0,"width":420,"height":200},
|
||||
{"id":"note-backlog","type":"text","text":"# Voraussetzung\n\nErst wieder aufnehmen, wenn Workspace Settings gebaut/validiert sind.\n\nDanach Flow neu mit David validieren.","x":1440,"y":680,"width":420,"height":200}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"edge-s01-m01","fromNode":"s01","fromSide":"right","toNode":"m01","toSide":"left","label":"Loeschung anfragen"},
|
||||
@@ -14,4 +14,4 @@
|
||||
{"id":"edge-s01-permission","fromNode":"s01","fromSide":"bottom","toNode":"note-permission","toSide":"top","label":"Permission"},
|
||||
{"id":"edge-m01-request","fromNode":"m01","fromSide":"bottom","toNode":"note-request","toSide":"top","label":"Feedback"}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in new issue
Block a user