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
+3
-1
@@ -1,7 +1,9 @@
|
||||
# Lokaler Obsidian UI-/Tab-Zustand.
|
||||
.obsidian/workspace.json
|
||||
.obsidian/graph.json
|
||||
|
||||
# Temporaere lokale Preview-Labs fuer Brainstorming. Nach Abschluss loeschen.
|
||||
# Temporaere lokale Preview-Labs fuer Brainstorming.
|
||||
# Wenn eine Preview dauerhaft gebraucht wird, liegt eine versionierte Kopie beim passenden Ticket.
|
||||
99 Temp/
|
||||
|
||||
# Lokale System-/Dependency-Dateien nicht ins Wireframe-Repo uebernehmen.
|
||||
|
||||
@@ -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"}
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -37,7 +37,7 @@ Es soll wachsen, wenn echte, validierte Standards entstehen.
|
||||
| [[08_Todo]] | Laufende Aufgaben, Pruefpunkte und Nacharbeiten |
|
||||
| `Layout/` | Validierte Layout-, Spacing-, Dialog-, Table- und Composition-Regeln |
|
||||
| [[AI/07_AI-References]] | Arbeitskontext und Ablauf fuer AI-Aenderungen |
|
||||
| [[AI/08_AI-Change-History]] | AI-Verlauf fuer Aenderungen am Vault |
|
||||
| [[AI/08_AI-Change-History]] | AI-Verlauf nur fuer Aenderungen am Subframe UI Standards / Component Library Regelwerk |
|
||||
| `Components/` | Einzelne Komponenten-Notizen mit Subframe-Link, Bereich und Regel-Referenzen |
|
||||
|
||||
## Grundmodell
|
||||
@@ -51,7 +51,7 @@ Standards werden so hoch wie moeglich und so spezifisch wie noetig dokumentiert.
|
||||
5. Einzelne Komponenten-Notizen stehen unter `Components/`.
|
||||
6. Dauerhafte Layout-Regeln stehen unter `Layout/`, sobald sie validiert sind.
|
||||
7. Laufende Aufgaben und Pruefpunkte stehen in [[08_Todo]].
|
||||
8. AI-Aenderungen werden in [[AI/08_AI-Change-History]] protokolliert.
|
||||
8. AI-Aenderungen am Subframe UI Standards / Component Library Regelwerk werden in [[AI/08_AI-Change-History]] protokolliert; fuer repo-weite Aenderungen ist Git der Verlauf.
|
||||
|
||||
Bei Arbeit mit AI zuerst [[AI/07_AI-References]] lesen.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Entscheidungen
|
||||
|
||||
Status: Entwurf
|
||||
Status: Aktiv
|
||||
|
||||
Diese Datei haelt Entscheidungen fest, die spaeter wieder auffindbar sein sollen.
|
||||
|
||||
@@ -8,6 +8,16 @@ Diese Datei haelt Entscheidungen fest, die spaeter wieder auffindbar sein sollen
|
||||
|
||||
| Datum | Thema | Entscheidung | Grund | Status |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 2026-07-02 | D03 Text-Rhythmus | Page Title zu Page Description nutzt 0px Gap, Page Header zu erstem Content 24px, Section Title zu Section Description 0px und Section Description zu Content 12px. Beschreibende Page-/Section-Texte muessen 150%-Texttokens nutzen; 0px ist ein bewusst definierter Auto-Layout-Gap, kein fehlender Abstand. `0`-Line-height-Tokens sind nur fuer garantierte Einzeiler erlaubt. | 150%-Line-height erzeugt bereits optische Hoehe im Textblock. Der Abstand soll deshalb zwischen gerenderten Textboxen stabil bleiben, auch wenn Beschreibungstexte umbrechen. | Entschieden |
|
||||
| 2026-07-02 | D06 Table Layout Ownership | Row Height, Cell Padding, Header-Dichte und Tabellenvarianten werden ueber die Table-Komponente abgedeckt. Screen-Layouts sollen Tabellen-Padding oder Row-Hoehen nicht manuell nachbauen. IBM Carbon dient als Referenz fuer Row-Size-Systematik (`xs 24px`, `sm 32px`, `md 40px`, `lg 48px`, `xl 64px`) und 16px Column Padding; konkrete HiveGrid-Werte kommen aus der Table-Komponente. | Tabellen sind komponentengetrieben. Einzelne Screens sollen keine eigenen Tabellen-Padding- oder Row-Height-Regeln einfuehren. | Entschieden |
|
||||
| 2026-07-02 | D05 Form Layout Gap | Komplette Formular-Field-Komponenten stehen standardmaessig 16px auseinander. 12px bleibt kompakter Sonderfall, 24px ist fuer getrennte Formular-Sections. Label/Input-Abstand, Help-/Description-Text, Error-/Message-Abstand und Input-Padding gehoeren zur Form-Input-Komponente. | Formularlayout soll auf Screen-Ebene konsistent bleiben, ohne die Field-Anatomy der Komponenten zu ueberschreiben. | Entschieden |
|
||||
| 2026-07-02 | D04 Button Layout Ownership | Button-Hoehen, Button-Padding und Button-Varianten werden ueber die Button-Komponente abgedeckt. Standardaktionen nutzen die Default-Variante der Button-Komponente; diese ist `Medium` und 36px hoch. | D-D0b soll keine Button-Komponentenregeln duplizieren. Screens sollen den Komponentenstandard verwenden. | Entschieden |
|
||||
| 2026-07-02 | D08 Dialog Internal Gaps | Normale Dialoge nutzen die `Balanced`-Gap-Logik: `Title -> Description 8px`, `Field/Form Row Gap 16px`, `Section Gap 24px`, `Footer Button Gap 8px`. Footer Actions sind standardmaessig rechts ausgerichtet. Mehrzeiliger Text nutzt die 150%-Texttoken; die Gap-Werte bleiben zwischen den gerenderten Bloecken gleich. | Die Dialoge sollen dicht, aber lesbar bleiben und nicht je Screen eigene Innenabstaende bekommen. Die 150%-Lineheight macht mehrzeilige Textbloecke von selbst hoeher, ohne zusaetzliche Sonderabstaende. | Entschieden |
|
||||
| 2026-07-02 | D07 Dialog Sizes | Zentrierte Dialoge nutzen `XS 420px`, `S 560px`, `M 720px` und `L 1200px max`. Dialoge wachsen auf 4K nicht automatisch mit, sondern bleiben in ihrer Breitenklasse zentriert. Fullscreen Dialog nutzt Fill fuer Width und Height innerhalb des Overlays mit aeusserem Rand; Arbeitswert Desktop: `width: calc(100vw - 48px)`, `max-width: 2512px`, `height: calc(100vh - 48px)`. `2512px` entspricht 2K-Breite `2560px` minus 24px Rand pro Seite. | Vier neutrale Groessen decken kurze Bestaetigungen, kleine Formulare, normale Formulare und grosse Editor-Dialoge ab. Fullscreen Dialog bleibt ein temporaeres Overlay und ersetzt keine Page. Auf sehr breiten Monitoren wird er zentriert und nicht unendlich breit. | Entschieden |
|
||||
| 2026-07-02 | Page, Dialog, Fullscreen Dialog und Drawer | Settings und vergleichbare Verwaltungsbereiche sind Pages, keine Dialoge. Dialoge sind temporaere Overlays ueber einer Page. Fullscreen Dialoge sind grosse temporaere Overlays fuer abgeschlossene Arbeitsmodi, aber keine dauerhaften App-Bereiche. Drawer/Side Panels sind seitliche Bearbeitungsflaechen mit sichtbarem Kontext und brauchen eigene Breitenregeln. | D07 Dialogbreiten duerfen nicht mit Pages, Settings oder Side Panels vermischt werden. | Entschieden |
|
||||
| 2026-07-02 | Dialog Padding Varianten | Die Subframe-`Dialog`-Komponente bekommt zwei Padding-Varianten: `16px` als Default und `32px` als groessere/ruhigere Variante. Diese Werte sollen ueber die Dialog-Komponente kommen, nicht durch freie Padding-Overrides im Screen. | Dialoge brauchen je nach Groesse und Inhalt unterschiedliche Dichte. Gleichzeitig soll 32px nicht als beliebiger Surface-Standard missverstanden werden. | Entschieden |
|
||||
| 2026-07-02 | D02 Page, Card und Grid Padding | Page Padding ist immer mindestens 24px und wird nicht fuer kompakte Momente reduziert. Card/Surface Padding und Detail-/Editor-Surface Padding sind standardmaessig 16px. Grid/Card Gap Standard ist 16px, mit 12px als kompaktem Sonderfall fuer enge Teilbereiche. Section Gap Standard ist 24px. 32px Innenabstand ist kein frei verwendbarer Surface-Standard; Ausnahme ist die eigene 32px-Variante der Subframe-`Dialog`-Komponente. | HiveGrid soll als Admin-/CRM-App dicht und einheitlich wirken, ohne dass Seiteninhalte zu nah an App Shell oder Browserrand kleben. Kompaktheit entsteht lokal ueber Gaps, nicht ueber weniger Page Padding. Auch grosse Arbeitsflaechen sollen erst konsistent dicht bleiben. | Entschieden |
|
||||
| 2026-06-30 | Layout Spacing Scale | HiveGrid nutzt fuer Layout-Abstaende einen 8px-Rhythmus mit den Standardwerten `4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96`. Komponenten-Defaults bleiben fuehrend, wenn sie diesen Standard bereits abbilden. | D-D0b braucht eine klare Spacing-Basis, ohne bestehende Subframe-Komponenten durch manuelle Padding-Overrides zu umgehen. | Entschieden |
|
||||
| 2026-06-29 | HiveGrid-Integration | Die Subframe UI Standards werden als eigenes Standards-Projekt in das HiveGrid-Wireframe-Repo aufgenommen. | Layout- und Komponentenstandards sollen zentral versioniert werden, ohne die HiveGrid Screen-/Flow-Arbeitsregeln zu vermischen. | Entschieden |
|
||||
| 2026-06-29 | Aenderungsschutz | Die Subframe UI Standards duerfen nicht nebenbei in normaler Screen-Arbeit geaendert werden; Aenderungen brauchen explizite Aufgabe oder validierte Entscheidung. | Es ist ein eigenes Standards-Projekt und globale Standards duerfen nicht aus einzelnen Screens abgeleitet werden. | Entschieden |
|
||||
| 2026-06-02 | Speicherung | Das Regelwerk wird als Obsidian-kompatibler Markdown-Ordner gespeichert. | Es soll durchsuchbar, verlinkbar und leicht erweiterbar sein. | Entschieden |
|
||||
|
||||
@@ -6,7 +6,11 @@ Themen, die spaeter nuetzlich sind, aber nicht Teil des ersten Regelwerk-Durchga
|
||||
|
||||
| Thema | Warum spaeter? | Status |
|
||||
| --- | --- | --- |
|
||||
| D-D0b Folgepunkte | Detail-Backlog liegt im Wireframe-Bereich: [[D-D0b Backlog]] | Backlog |
|
||||
| IBM Carbon Spacing-Inspiration | Nuetzlich fuer spaetere Spacing-Recherche, aber noch keine Regelquelle | Backlog |
|
||||
| Button-/Action-Semantik | Klaeren, wann Actions Primary, Secondary, Destructive oder Positive sind; Destructive ist eindeutig rot, aber Confirm soll nicht automatisch gruen werden | 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 ueber State-/Alert-Komponenten | Backlog |
|
||||
| Mobile Layout Standards | Mobile wird in D-D0b noch nicht validiert; Padding, Breakpoints und mobile App-Shell-Verhalten spaeter separat klaeren | Backlog |
|
||||
| Farben | Werden groesstenteils in Subframe gepflegt | Backlog |
|
||||
| Radius | Wird groesstenteils in Subframe gepflegt | Backlog |
|
||||
| Shadows | Werden groesstenteils in Subframe gepflegt | Backlog |
|
||||
|
||||
@@ -19,7 +19,7 @@ Wichtig:
|
||||
- Die Standards sind nicht der Ort fuer Ticket-spezifische UX-Entscheidungen; diese bleiben in den Wireframe-Paketen.
|
||||
- Dauerhafte Layout-, Komponenten- oder Subframe-Konventionen koennen hier dokumentiert werden, wenn sie als systemweite Regel validiert sind.
|
||||
|
||||
## Vault-Struktur
|
||||
## Projektstruktur
|
||||
|
||||
| Bereich | Zweck |
|
||||
| --- | --- |
|
||||
@@ -33,7 +33,7 @@ Wichtig:
|
||||
| [[06_Backlog]] | Spaetere Aufgaben, offene Themen und Erweiterungen |
|
||||
| [[07_Global-Rules]] | Globale Component-API- und Arbeitsregeln |
|
||||
| [[08_Todo]] | Laufende Aufgaben, Pruefpunkte und Nacharbeiten |
|
||||
| [[AI/08_AI-Change-History]] | AI-Verlauf fuer Aenderungen am Vault |
|
||||
| [[AI/08_AI-Change-History]] | AI-Verlauf nur fuer Aenderungen am Subframe UI Standards / Component Library Regelwerk |
|
||||
| `Layout/` | Validierte Layout-, Spacing-, Dialog-, Table- und Composition-Regeln |
|
||||
| `Components/` | Einzelne Komponenten-Notizen mit Subframe-Link, Bereich, Notizen und Regel-Referenzen |
|
||||
|
||||
@@ -77,6 +77,19 @@ Sie werden in Komponenten-Dateien nur pauschal direkt nach [[03_Benennung]] verl
|
||||
Keine einzelnen Heading-Embeds fuer Global Rules in Komponenten-Dateien anlegen, ausser das wird spaeter bewusst entschieden.
|
||||
Spezifische Obsidian-Embeds bleiben fuer Gruppenregeln aus [[04_Gruppenregeln]] reserviert.
|
||||
|
||||
## Regel 3: Layout-Regeln bei Subframe-MCP-Arbeit verwenden
|
||||
|
||||
Bei jeder Subframe-MCP-Arbeit an HiveGrid-Screens, Dialogen oder Varianten muessen die validierten Layout-Regeln als aktive Referenz genutzt werden.
|
||||
|
||||
Pflicht:
|
||||
|
||||
- Vor dem Prompten oder Editieren `Layout/README.md` lesen.
|
||||
- Im Subframe-Prompt explizit erwaehnen, dass die validierten HiveGrid/Subframe-Layout-Standards verwendet werden sollen.
|
||||
- Page Padding, Card/Surface Padding, Grid Gap, Text-Rhythmus, Dialog Sizes, Dialog Padding und Dialog Internal Gaps nicht frei neu definieren.
|
||||
- Komponenten-Defaults und Varianten verwenden, wenn sie den Standard bereits abbilden.
|
||||
- Modale immer als echte Subframe-Dialog-Struktur bauen, nicht als Fake-Modal.
|
||||
- Nach MCP-Aenderungen per Readback pruefen, ob die Struktur und die Layout-Regeln wirklich angewendet wurden.
|
||||
|
||||
## Ablauf fuer Aenderungen
|
||||
|
||||
0. Zuerst klaeren, ob wirklich an den Subframe UI Standards gearbeitet werden soll oder ob die Information nur in ein HiveGrid-Wireframe-Paket gehoert.
|
||||
@@ -88,7 +101,7 @@ Spezifische Obsidian-Embeds bleiben fuer Gruppenregeln aus [[04_Gruppenregeln]]
|
||||
6. Komponenten-spezifische Notizen in der passenden Datei unter `Components/` pflegen.
|
||||
7. Der [[05_Komponenten-Index]] bleibt nur Link- und Statusuebersicht.
|
||||
8. Offene konkrete Aufgaben oder Pruefpunkte in [[08_Todo]] pflegen.
|
||||
9. Jede inhaltliche Datei-Aenderung in [[AI/08_AI-Change-History]] mit Datum, Uhrzeit, Kontext, betroffenen Dateien, Aenderungen und offenen Punkten dokumentieren.
|
||||
9. Jede inhaltliche Datei-Aenderung am Subframe UI Standards / Component Library Regelwerk in [[AI/08_AI-Change-History]] mit Datum, Uhrzeit, Kontext, betroffenen Dateien, Aenderungen und offenen Punkten dokumentieren.
|
||||
10. Nach jeder Aenderung die Referenzen pruefen.
|
||||
|
||||
## Pflichtpruefung am Ende
|
||||
@@ -103,7 +116,7 @@ Nach jeder Aenderung muss geprueft werden:
|
||||
| Wurde eine Komponente neu hinzugefuegt? | Dann [[03_Benennung]], [[07_Global-Rules]] und die passenden Gruppenregeln referenzieren. |
|
||||
| Wurde eine Komponente geaendert? | Dann pruefen, ob alle passenden Gruppenregeln referenziert sind. |
|
||||
| Entstand ein offener Pruefpunkt? | Dann in [[08_Todo]] eintragen, nicht nur im Chat behalten. |
|
||||
| Wurden Dateien erstellt, geaendert, verschoben oder geloescht? | Dann [[AI/08_AI-Change-History]] mit Datum, Uhrzeit, Kontext, Dateien, Aenderungen und offenen Punkten aktualisieren. |
|
||||
| Wurden Dateien im Subframe UI Standards / Component Library Regelwerk erstellt, geaendert, verschoben oder geloescht? | Dann [[AI/08_AI-Change-History]] mit Datum, Uhrzeit, Kontext, Dateien, Aenderungen und offenen Punkten aktualisieren. |
|
||||
| Wurde eine Regel entfernt oder verschoben? | Dann alte Referenzen in `Components/` bereinigen. |
|
||||
|
||||
Ziel: Regeln und Komponenten muessen in beide Richtungen konsistent bleiben.
|
||||
|
||||
@@ -4,11 +4,18 @@ Status: Aktiv
|
||||
Tags: #AIReference
|
||||
|
||||
Diese Datei ist nur fuer AI- und Projektpflege-Kontext gedacht.
|
||||
Sie dokumentiert kurz und nachvollziehbar, was durch AI oder mit AI-Unterstuetzung am Vault geaendert wurde.
|
||||
Sie dokumentiert kurz und nachvollziehbar, was durch AI oder mit AI-Unterstuetzung am Subframe UI Standards / Component Library Regelwerk geaendert wurde.
|
||||
|
||||
Scope:
|
||||
|
||||
- Diese Datei gilt nur fuer `04 Standards/Subframe UI Standards/`.
|
||||
- Sie ist keine Change-History fuer das gesamte HiveGrid-Wireframe-Repo.
|
||||
- Fuer repo-weite Aenderungen ist Git die Quelle der Wahrheit.
|
||||
- Normale Wireframe-, Ticket-, Canvas- oder Planning-Aenderungen werden hier nur eingetragen, wenn sie eine validierte Aenderung am Subframe UI Standards / Component Library Regelwerk verursachen.
|
||||
|
||||
## Pflichtregel fuer AI-Arbeit
|
||||
|
||||
Nach jeder inhaltlichen Aenderung am Vault muss diese Datei aktualisiert werden.
|
||||
Nach jeder inhaltlichen Aenderung am Subframe UI Standards / Component Library Regelwerk muss diese Datei aktualisiert werden.
|
||||
Der Eintrag muss kurz, konkret und nachtraeglich nutzbar sein.
|
||||
|
||||
Ein Eintrag muss enthalten:
|
||||
@@ -20,7 +27,7 @@ Ein Eintrag muss enthalten:
|
||||
- offene Folgepunkte, falls vorhanden
|
||||
|
||||
Wenn nur gelesen oder analysiert wurde, ist kein Eintrag noetig.
|
||||
Wenn Dateien erstellt, geaendert, verschoben oder geloescht wurden, ist ein Eintrag Pflicht.
|
||||
Wenn Dateien innerhalb des Subframe UI Standards / Component Library Regelwerks erstellt, geaendert, verschoben oder geloescht wurden, ist ein Eintrag Pflicht.
|
||||
Falls alte Eintraege ohne Uhrzeit nachtraeglich normalisiert werden, muss im Kontext stehen, dass die Uhrzeit geschaetzt wurde.
|
||||
|
||||
## Format
|
||||
@@ -44,6 +51,378 @@ Offen:
|
||||
|
||||
## Verlauf
|
||||
|
||||
### 2026-07-03 00:20:15 Europe/Berlin - Subframe-MCP Nutzung der Layout-Standards festgeschrieben
|
||||
|
||||
Kontext:
|
||||
- David wollte sicherstellen, dass die neu validierten Layout-Standards bei zukuenftiger Subframe-MCP-Arbeit wirklich verwendet werden.
|
||||
- Die D-D0b HTML-Preview sollte im fertigen Ticket referenzierbar sein, nicht nur lokal unter `99 Temp/`.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `AI README.md`
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `04 Standards/Subframe UI Standards/Layout/README.md`
|
||||
- [[AI/07_AI-References]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `Tickets/Fertige Tickets/D-D0b Layout Standards.md`
|
||||
- `Tickets/Fertige Tickets/Assets/D-D0b-Layout-Preview.html`
|
||||
|
||||
Aenderungen:
|
||||
- Pflichtregel ergaenzt, dass Subframe-MCP-Prompts und Edits die validierten Layout-Standards als aktive Referenz nutzen muessen.
|
||||
- Festgelegt, dass Page Padding, Card/Surface Padding, Grid Gap, Text-Rhythmus, Dialog Sizes, Dialog Padding und Dialog Internal Gaps nicht frei neu definiert werden sollen.
|
||||
- Readback-Pruefung nach MCP-Aenderungen ergaenzt.
|
||||
- D-D0b HTML-Preview als versioniertes Ticket-Artefakt abgelegt und im Ticket sowie in der D-D0b-Referenz verlinkt.
|
||||
|
||||
Offen:
|
||||
- Keine.
|
||||
|
||||
### 2026-07-02 23:50:12 Europe/Berlin - D-D0b Abschluss-Cleanup und Backlog ausgelagert
|
||||
|
||||
Kontext:
|
||||
- David wollte D-D0b als fertiges Ticket bereinigen.
|
||||
- Die HTML-Preview soll erhalten bleiben, aber nicht Source of Truth sein.
|
||||
- Backlog-Punkte sollten aus der Abschlussdoku in eine eigene Seite ausgelagert werden.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Backlog.md`
|
||||
- `04 Standards/Subframe UI Standards/Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[06_Backlog]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `Tickets/README.md`
|
||||
- `Tickets/Fertige Tickets/D-D0b Layout Standards.md`
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- D-D0b-Arbeitsdatei zu einer finalen, lesbaren Layout-Standards-Referenz bereinigt.
|
||||
- D-D0b-Folgepunkte in eine eigene Backlog-Datei ausgelagert.
|
||||
- Globalen Standards-Backlog um Verweis auf D-D0b-Folgepunkte erweitert.
|
||||
- Layout-Regeln und Entscheidungslog als aktive Standards markiert.
|
||||
- Lokale Preview als behaltene Referenzhilfe markiert, aber Markdown als Source of Truth festgelegt.
|
||||
- Fertige Ticket-Handoff-Datei fuer D-D0b angelegt und im Ticket-Index verlinkt.
|
||||
|
||||
Offen:
|
||||
- Keine fuer D-D0b. Nur Backlog-Punkte bleiben separat geparkt.
|
||||
|
||||
### 2026-07-02 23:37:56 Europe/Berlin - D03 Text-Rhythmus token-aware validiert
|
||||
|
||||
Kontext:
|
||||
- David hat D03 final als token-aware Text-Rhythmus entschieden.
|
||||
- 150%-Texttokens erzeugen bereits optische Hoehe im Textblock, deshalb sollen Titel und Beschreibung ohne zusaetzlichen Gap zusammenstehen.
|
||||
- Die Preview sollte 0px sichtbar machen, ohne selbst Abstand zu erzeugen.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- D03 als validierte Layout-Regel dokumentiert: `Page Title -> Page Description 0px`, `Page Header -> erster Content 24px`, `Section Title -> Section Description 0px`, `Section Description -> Section Content 12px`.
|
||||
- Festgelegt, dass beschreibende Page-/Section-Texte 150%-Texttokens nutzen muessen.
|
||||
- Festgelegt, dass 0px ein bewusst definierter Auto-Layout-Gap ist, nicht ein fehlender Abstand.
|
||||
- Festgelegt, dass `0`-Line-height-Tokens nur fuer garantierte Einzeiler genutzt werden duerfen.
|
||||
- Preview auf die finalen D03-Werte aktualisiert und 0px-Marker ohne Layout-Hoehe ergaenzt.
|
||||
|
||||
Offen:
|
||||
- Keine.
|
||||
|
||||
### 2026-07-02 22:23:16 Europe/Berlin - D04-D06 Ownership und Form Gap geklaert
|
||||
|
||||
Kontext:
|
||||
- David hat geklaert, dass Button- und Tabellen-Details ueber Komponenten abgedeckt werden.
|
||||
- Formulare sollen auf Screen-Ebene nur den Abstand zwischen kompletten Field-Komponenten regeln.
|
||||
- D03 Text-Rhythmus musste in der Preview sichtbarer und verstaendlicher werden.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- D04 als Button Component Ownership dokumentiert; Standardaktionen nutzen Button Default/Medium/36px.
|
||||
- D05 als Form Layout Gap validiert; komplette Field-Komponenten nutzen 16px Abstand.
|
||||
- D06 als Table Component Ownership dokumentiert; Carbon nur als Row-Size-/Dichte-Referenz.
|
||||
- Carbon Data Table Referenz konkretisiert: Row Sizes `xs 24px`, `sm 32px`, `md 40px`, `lg 48px`, `xl 64px` und 16px Column Padding.
|
||||
- D03 in der Preview verlinkt und erklaert.
|
||||
- Preview auf 36px Control-Hoehe und 16px Form-Gap angepasst.
|
||||
|
||||
Offen:
|
||||
- D03 Text-Rhythmus noch einzeln validieren oder in Backlog verschieben.
|
||||
|
||||
### 2026-07-02 22:10:49 Europe/Berlin - State Ownership und Error Dialog Backlog geklaert
|
||||
|
||||
Kontext:
|
||||
- David hat klargestellt, dass Empty, Error und No-Permission als inline States ueber Komponenten abgedeckt werden sollen.
|
||||
- Blockierende Error-/Result-Dialoge sollen spaeter separat als Overlay-/Feedback-Komponenten betrachtet werden.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- [[06_Backlog]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
|
||||
Aenderungen:
|
||||
- D-D0b-Uebersicht korrigiert: D08 ist Dialog Internal Gaps, D09 ist State / Component Ownership.
|
||||
- State-Komponenten als inline Inhaltszustaende abgegrenzt, nicht als Modale.
|
||||
- Error-/Result-Dialog-Komponenten als spaeteres Backlog-Thema aufgenommen.
|
||||
|
||||
Offen:
|
||||
- No-Permission spaeter als eigene State-Variante oder Komponente klaeren, falls benoetigt.
|
||||
- Error-/Result-Dialog-Komponenten spaeter separat validieren.
|
||||
|
||||
### 2026-07-02 21:36:25 Europe/Berlin - D08 Dialog Internal Gaps validiert
|
||||
|
||||
Kontext:
|
||||
- David hat die `Balanced`-Variante fuer normale Dialog-Innenabstaende validiert.
|
||||
- Footer Actions sollen standardmaessig rechts ausgerichtet bleiben.
|
||||
- Mehrzeilige Texte nutzen die 150%-Texttoken, wodurch Textbloecke selbst hoeher werden.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[06_Backlog]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- D08 als validierte Dialog-Internal-Gap-Regel dokumentiert: `Title -> Description 8px`, `Field/Form Row Gap 16px`, `Section Gap 24px`, `Footer Button Gap 8px`.
|
||||
- Footer Actions als rechts ausgerichteter Default dokumentiert.
|
||||
- Mehrzeilige Textbloecke mit 150%-Lineheight als Teil der Typografie-Logik beruecksichtigt.
|
||||
- Button-/Action-Semantik als separates Backlog-Thema aufgenommen.
|
||||
- D09 States in der Preview als spaeteres Thema erklaert.
|
||||
|
||||
Offen:
|
||||
- Button-/Action-Semantik spaeter separat validieren, insbesondere Primary, Destructive und Positive.
|
||||
|
||||
### 2026-07-02 15:09:13 Europe/Berlin - Fullscreen Dialog Max-Width validiert
|
||||
|
||||
Kontext:
|
||||
- David hat geklaert, dass Fullscreen Dialoge zwar fill-artig sein sollen, aber auf sehr breiten Monitoren nicht unendlich skalieren duerfen.
|
||||
- Als obere Grenze wurde die Breite eines 2K-Monitors abzüglich des validierten aeusseren Dialogrands verwendet.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- Fullscreen Dialog mit `width: calc(100vw - 48px)`, `max-width: 2512px` und `height: calc(100vh - 48px)` dokumentiert.
|
||||
- `2512px` als 2K-Breite `2560px` minus 24px aeusserem Rand pro Seite festgehalten.
|
||||
- Preview-Texte fuer D07 an die Maxbreiten-Regel angepasst.
|
||||
|
||||
Offen:
|
||||
- Drawer-/Side-Panel-Breiten spaeter als eigenes Thema klaeren.
|
||||
|
||||
### 2026-07-02 14:50:32 Europe/Berlin - D07 Dialoggroessen validiert
|
||||
|
||||
Kontext:
|
||||
- David hat die zentrierten Dialoggroessen validiert.
|
||||
- Fullscreen Dialog soll Fill in Breite und Hoehe nutzen, aber mit sichtbarem aeusserem Rand.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- Dialoggroessen als `XS 420px`, `S 560px`, `M 720px`, `L 1200px max` validiert.
|
||||
- 4K-Verhalten dokumentiert: Dialoge wachsen nicht automatisch mit, sondern bleiben zentriert in ihrer Breitenklasse.
|
||||
- Fullscreen Dialog als Fill-Overlay mit aeusserem Rand dokumentiert; Arbeitswert Desktop: 24px pro Seite.
|
||||
- D07-Preview von Kandidatenvergleich auf validierte Groessen umgestellt.
|
||||
|
||||
Offen:
|
||||
- Drawer-/Side-Panel-Breiten spaeter als eigenes Thema klaeren.
|
||||
|
||||
### 2026-07-02 01:31:47 Europe/Berlin - AI Change History Scope geklaert
|
||||
|
||||
Kontext:
|
||||
- David hat geklaert, dass diese History nur fuer die Subframe UI Standards / Component Library gelten soll.
|
||||
- Fuer das gesamte HiveGrid-Wireframe-Repo reicht Git als Verlauf.
|
||||
|
||||
Betroffene Dateien:
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- [[AI/07_AI-References]]
|
||||
- [[00_Start]]
|
||||
|
||||
Aenderungen:
|
||||
- Scope der AI Change History explizit auf `04 Standards/Subframe UI Standards/` begrenzt.
|
||||
- Klargestellt, dass normale Wireframe-, Ticket-, Canvas- oder Planning-Aenderungen hier nicht repo-global protokolliert werden.
|
||||
- Verweise in AI-References und Start-Datei sprachlich angepasst.
|
||||
|
||||
Offen:
|
||||
- Keine.
|
||||
|
||||
### 2026-07-02 01:24:20 Europe/Berlin - Overlay-Pattern fuer D07 definiert
|
||||
|
||||
Kontext:
|
||||
- David war unsicher, wie sich normale Pages, Dialoge, Fullscreen Dialoge und Side Panels unterscheiden.
|
||||
- Die Definition ist Voraussetzung, bevor Dialogbreiten sinnvoll validiert werden koennen.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- Begriffe `Page`, `Dialog`, `Fullscreen Dialog` und `Drawer / Side Panel` definiert.
|
||||
- Settings als `Page` abgegrenzt, nicht als Fullscreen Dialog.
|
||||
- Fullscreen Dialog als temporaeres Overlay fuer abgeschlossene Arbeitsmodi definiert.
|
||||
- Drawer/Side Panel als eigenes Pattern mit eigenen Breitenregeln markiert.
|
||||
- D07-Preview um Pattern-Karten vor den Breitenvarianten erweitert.
|
||||
|
||||
Offen:
|
||||
- D07 Dialogbreiten separat validieren.
|
||||
- Drawer-/Side-Panel-Breiten spaeter als eigenes Thema klaeren.
|
||||
|
||||
### 2026-07-02 00:13:25 Europe/Berlin - Dialog Padding Varianten validiert
|
||||
|
||||
Kontext:
|
||||
- David hat entschieden, dass Padding mit 32px nicht frei fuer beliebige Surfaces genutzt wird.
|
||||
- Stattdessen bekommt die Subframe-`Dialog`-Komponente zwei Varianten: 16px Default und 32px groesser/ruhiger.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- Dialog-Padding-Regel dokumentiert: `16px` Default, `32px` groessere Variante.
|
||||
- Festgelegt, dass diese Werte ueber die Dialog-Komponente bzw. deren Varianten kommen sollen.
|
||||
- D02-Regel korrigiert: 32px ist kein frei verwendbarer Surface-Standard; Ausnahme ist die eigene Dialog-Variante.
|
||||
- D07-Preview aktualisiert, sodass kleine/mittlere Dialoge 16px und der grosse Dialog die 32px-Variante zeigt.
|
||||
|
||||
Offen:
|
||||
- Dialogbreiten separat validieren.
|
||||
- Mobile Layout Standards spaeter separat klaeren.
|
||||
|
||||
### 2026-07-02 00:02:48 Europe/Berlin - D-D0b Detail-/Editor-Surface Padding praezisiert
|
||||
|
||||
Kontext:
|
||||
- David hat bestaetigt, dass grosse Detail-/Editorflaechen nicht automatisch mehr Innenabstand bekommen sollen.
|
||||
- 32px Innenabstand sollte zu diesem Zeitpunkt nicht frei als Standard gelten. Kurz danach wurde er als eigene Subframe-`Dialog`-Variante validiert.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
- `99 Temp/D-D0b Layout Preview/preview.html`
|
||||
|
||||
Aenderungen:
|
||||
- Detail-/Editor-Surface Padding als Standard auf 16px festgelegt.
|
||||
- 32px Innenabstand als nicht frei verwendbaren Surface-Standard markiert.
|
||||
- D02-Entscheidung entsprechend aktualisiert.
|
||||
- Lokale Preview wurde zunaechst als Vergleich beschriftet und danach auf die validierte Dialog-Variante umgestellt.
|
||||
|
||||
Offen:
|
||||
- Mobile Layout Standards spaeter separat klaeren.
|
||||
|
||||
### 2026-07-01 00:36:12 Europe/Berlin - D-D0b D02 Page Padding Minimum geklaert
|
||||
|
||||
Kontext:
|
||||
- David hat geklaert, dass Page Padding immer mindestens 24px sein soll.
|
||||
- Kompakte UI-Momente sollen nicht ueber reduziertes Page Padding entstehen, sondern ueber lokale Gaps.
|
||||
- Detail-/Editor-Surface Padding wurde zu diesem Zeitpunkt noch als offener Sonderfall notiert und am 2026-07-02 auf 16px als Standard praezisiert.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
- `99 Temp/D-D0b Layout Preview/preview.html`
|
||||
|
||||
Aenderungen:
|
||||
- Page Padding als Mindeststandard `24px` dokumentiert.
|
||||
- 16px Page Padding als kompakter Sonderfall entfernt.
|
||||
- Card/Surface Padding weiterhin auf 16px festgelegt.
|
||||
- Grid/Card Gap weiterhin auf 16px festgelegt; 12px als kompakter Sonderfall fuer enge Teilbereiche dokumentiert.
|
||||
- Detail-/Editor-Surface Padding als grosse Arbeitsflaeche erklaert und zu diesem Zeitpunkt offen gelassen.
|
||||
- Lokale Preview so angepasst, dass der Kompakt-Modus Page Padding bei 24px laesst und nur Grid/Card Gap auf 12px reduziert.
|
||||
|
||||
Offen:
|
||||
- Detail-/Editor-Surface Padding wurde am 2026-07-02 auf 16px als Standard praezisiert.
|
||||
- Mobile Layout Standards spaeter separat klaeren.
|
||||
|
||||
### 2026-06-30 23:08:49 Europe/Berlin - D-D0b D02 Padding-Standards validiert
|
||||
|
||||
Kontext:
|
||||
- David hat die D02-Basiswerte fuer Page Padding, Card/Surface Padding und Grid/Card Gap validiert.
|
||||
- Mobile soll aus der aktiven Preview entfernt bleiben und grosse Detail-/Editorflaechen sind noch unklar.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- D02 als validierte Layout-Entscheidung dokumentiert.
|
||||
- Page Padding Standard auf 24px festgelegt; ein 16px-Sonderfall wurde damals als Zwischenstand notiert und am 2026-07-01 wieder verworfen.
|
||||
- Card/Surface Padding Standard auf 16px festgelegt.
|
||||
- Grid/Card Gap Standard auf 16px und Section Gap Standard auf 24px festgelegt.
|
||||
- Standard Desktop Page und kompakte Settings Page in der Preview auf dieselbe Basis gesetzt.
|
||||
- Mobile aus der aktiven D02-Preview entfernt; grosse Detail-/Editorflaechen damals als offen markiert und am 2026-07-02 auf 16px als Standard praezisiert.
|
||||
|
||||
Offen:
|
||||
- Grosse Detail-/Editorflaechen separat klaeren.
|
||||
- Mobile Layout Standards spaeter separat klaeren.
|
||||
|
||||
### 2026-06-30 22:42:30 Europe/Berlin - D-D0b D02 Begriffe und Mobile-Backlog geklaert
|
||||
|
||||
Kontext:
|
||||
- Beim D02-Brainstorming musste getrennt werden zwischen App Shell, Page Padding, Section/Grid Gap und Komponenten-Padding.
|
||||
- David hat entschieden, Mobile vorerst nicht in D02 zu validieren, sondern in den Backlog zu legen.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- [[06_Backlog]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
- `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
Aenderungen:
|
||||
- D02-Begriffsklaerung fuer App Shell, Page Padding, Section Gap, Grid Gap und Card/Surface Padding ergaenzt.
|
||||
- D02-Arbeitsannahmen fuer Desktop/Settings/Card/Editor-Padding dokumentiert, aber noch nicht final validiert.
|
||||
- Mobile Layout Standards in den Backlog aufgenommen.
|
||||
- Lokale Preview markiert Mobile als Backlog statt als aktive D02-Entscheidung.
|
||||
|
||||
Offen:
|
||||
- D02-Werte weiterhin mit David validieren.
|
||||
|
||||
### 2026-06-30 22:27:07 Europe/Berlin - D-D0b Spacing Scale validiert
|
||||
|
||||
Kontext:
|
||||
- David hat fuer D-D0b den 8px-Rhythmus mit definierten Zwischenwerten validiert.
|
||||
- Gleichzeitig wurde geklaert, dass Layout-Standards nicht gegen bestehende Subframe-Komponenten-Defaults arbeiten sollen.
|
||||
|
||||
Betroffene Dateien:
|
||||
- `02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Brainstorming.md`
|
||||
- `Layout/README.md`
|
||||
- [[02_Entscheidungen]]
|
||||
- [[AI/08_AI-Change-History]]
|
||||
|
||||
Aenderungen:
|
||||
- D01 Grundraster / Spacing Scale als validierte Entscheidung dokumentiert.
|
||||
- Erlaubte Layout-Spacing-Werte festgelegt: `4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96`.
|
||||
- Komponenten-Ownership-Regel ergaenzt: vorhandene Defaults von Dialog, Modal, Button, Text Input, Table oder Card verwenden, wenn sie den Standard bereits abbilden.
|
||||
|
||||
Offen:
|
||||
- D02 Page & Card Padding als naechste Entscheidung einzeln validieren.
|
||||
|
||||
### 2026-06-29 04:57:39 Europe/Berlin - Repo-Struktur und Standards-Benennung geschaerft
|
||||
|
||||
Kontext:
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Layout-Regeln
|
||||
|
||||
Status: in Aufbau
|
||||
Status: Aktiv
|
||||
|
||||
Dieser Bereich ist die Zielstruktur fuer dauerhafte Layout-Regeln der Subframe UI Standards.
|
||||
|
||||
@@ -26,6 +26,226 @@ Dokumentiert werden koennen spaeter:
|
||||
|
||||
## Arbeitsregel
|
||||
|
||||
D-D0b ist aktuell der Arbeitsort fuer Layout-Entscheidungen.
|
||||
D-D0b war der Arbeitsort fuer die erste Layout-Entscheidungsrunde.
|
||||
|
||||
Erst wenn David eine Entscheidung validiert hat und sie wirklich als systemweite Regel gelten soll, wird sie hier dokumentiert.
|
||||
Die validierten Regeln aus D-D0b sind hier als dauerhafte Layout-Regeln dokumentiert.
|
||||
|
||||
Neue oder geaenderte Layout-Regeln duerfen erst nach Davids Validierung hier aufgenommen werden.
|
||||
|
||||
## Validierte Layout-Regeln
|
||||
|
||||
### D01 Grundraster / Spacing Scale
|
||||
|
||||
Status: validiert am 2026-06-30, praezisiert am 2026-07-02.
|
||||
|
||||
HiveGrid nutzt fuer Layout-Abstaende einen 8px-Rhythmus als Hauptstandard.
|
||||
|
||||
Erlaubte Standardwerte:
|
||||
|
||||
`4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96`
|
||||
|
||||
Regeln:
|
||||
|
||||
- `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.
|
||||
|
||||
### D02 Page, Card und Grid Padding
|
||||
|
||||
Status: validiert am 2026-06-30.
|
||||
|
||||
Validierte Standards:
|
||||
|
||||
- `Page Padding Standard`: 24px.
|
||||
- `Page Padding Minimum`: 24px. Page Padding wird nicht unter 24px reduziert.
|
||||
- `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.
|
||||
|
||||
Regeln:
|
||||
|
||||
- Standard Desktop Pages und kompakte Settings Pages nutzen beide als Basis `Page Padding 24px`, `Card/Surface Padding 16px` und `Grid/Card Gap 16px`.
|
||||
- `Page Padding` gehoert dem Page-/Content-Container nach der App Shell.
|
||||
- `Card/Surface Padding` gehoert der Card-, Surface- oder Panel-Komponente.
|
||||
- `Detail-/Editor-Surface Padding` gehoert grossen Arbeitsflaechen wie Detail-Editoren, Rollen-/Permission-Editoren oder grossen Dialog-Bodies.
|
||||
- `Grid/Card Gap` ist Abstand zwischen Karten, Spalten oder zusammengehoerigen Layout-Bloecken.
|
||||
- Kompakte Momente reduzieren nicht das Page Padding, sondern nur lokale Gaps/Abstaende innerhalb dichter UI-Bereiche.
|
||||
- 32px Innenabstand ist kein frei zu verwendender Standard fuer normale Detail-/Editorflaechen. Ausnahme: Die Subframe-`Dialog`-Komponente darf eine eigene 32px-Padding-Variante besitzen.
|
||||
- Vorhandene Subframe-Komponenten-Defaults bleiben fuehrend, wenn sie diese Werte bereits korrekt abbilden.
|
||||
|
||||
Offen:
|
||||
|
||||
- Mobile Padding wird spaeter separat validiert und bleibt Backlog.
|
||||
|
||||
### D03 Text-Rhythmus
|
||||
|
||||
Status: validiert am 2026-07-02.
|
||||
|
||||
D03 definiert vertikale Gaps zwischen Page-/Section-Textbloecken und Content.
|
||||
Diese Regel gilt nur zusammen mit 150%-Texttokens fuer beschreibende Texte.
|
||||
|
||||
Validierte Standards:
|
||||
|
||||
- `Page Title -> Page Description`: 0px.
|
||||
- `Page Header -> erster Content`: 24px.
|
||||
- `Section Title -> Section Description`: 0px.
|
||||
- `Section Description -> Section Content`: 12px.
|
||||
|
||||
Regeln:
|
||||
|
||||
- `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.
|
||||
|
||||
### Button Layout Ownership
|
||||
|
||||
Status: component-owned, geklaert am 2026-07-02.
|
||||
|
||||
- Button-Hoehen, Button-Innenpadding und Button-Varianten werden ueber die Button-Komponente abgedeckt.
|
||||
- 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.
|
||||
|
||||
### Form Layout Gap
|
||||
|
||||
Status: validiert am 2026-07-02.
|
||||
|
||||
- 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.
|
||||
|
||||
Komponenten-Ownership:
|
||||
|
||||
- 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.
|
||||
|
||||
### Table Layout Ownership
|
||||
|
||||
Status: component-owned, geklaert am 2026-07-02.
|
||||
|
||||
- Row Height, Cell Padding, Header-Dichte und Tabellenvarianten werden ueber die Table-Komponente abgedeckt.
|
||||
- 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. Sehr grosse Rows sind fuer zwei Inhaltszeilen gedacht.
|
||||
- Fuer HiveGrid gilt: Table-Komponente verwenden und deren passende Dichte waehlen, statt in einzelnen Screens eigene Tabellenwerte zu definieren.
|
||||
|
||||
### Dialog Padding
|
||||
|
||||
Status: validiert am 2026-07-02.
|
||||
|
||||
Die Subframe-`Dialog`-Komponente bekommt zwei Padding-Varianten:
|
||||
|
||||
- `16px` als Default.
|
||||
- `32px` als groessere/ruhigere Variante fuer Dialoge, die bewusst mehr Innenraum brauchen.
|
||||
|
||||
Regeln:
|
||||
|
||||
- Diese Werte sollen ueber die Dialog-Komponente bzw. deren Varianten kommen, nicht durch frei platzierte Padding-Overrides im Screen.
|
||||
- `Modal` ist der UX-Begriff; in Subframe soll die echte `Dialog`-Komponente genutzt werden.
|
||||
- Normale Cards, Surfaces und Detail-/Editor-Surfaces bleiben bei 16px, solange nicht explizit die Dialog-Variante genutzt wird.
|
||||
|
||||
### Dialog Internal Gaps
|
||||
|
||||
Status: validiert am 2026-07-02.
|
||||
|
||||
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.
|
||||
|
||||
### Page, Dialog, Fullscreen Dialog und Drawer
|
||||
|
||||
Status: Begriffsklaerung validiert am 2026-07-02.
|
||||
|
||||
- `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. Beispiele: Settings, Profil Settings, Mitarbeiter, Rollen & Berechtigungen.
|
||||
- `Dialog`: temporaeres Overlay ueber der aktuellen Page. Blockiert den Hintergrund, hat einen klaren Abschluss wie Speichern, Abbrechen oder Schliessen und fuehrt den User danach zur vorherigen Page zurueck.
|
||||
- `Fullscreen Dialog`: temporaeres Overlay wie ein Dialog, aber nimmt den Viewport fast oder ganz ein. Wird fuer groessere, abgeschlossene Arbeitsmodi genutzt, die aus einem konkreten Kontext gestartet werden und danach wieder geschlossen werden. Er ist keine normale App-Page und soll nicht fuer dauerhafte Bereiche wie Settings genutzt werden.
|
||||
- `Drawer / Side Panel`: seitliches Overlay oder Panel, meistens rechts. Wird genutzt, wenn die urspruengliche Page sichtbar bleiben soll, z. B. Liste links und Detail/Inspector rechts. Das ist kein zentrierter Dialog und braucht eigene Breitenregeln.
|
||||
|
||||
Entscheidungsregel:
|
||||
|
||||
- Wenn der User navigiert und in einem App-Bereich bleibt, ist es eine `Page`.
|
||||
- Wenn der User eine temporaere Aufgabe ueber der aktuellen Page erledigt und danach zurueckkehrt, ist es ein `Dialog`.
|
||||
- Wenn diese temporaere Aufgabe fast die ganze Flaeche braucht, aber trotzdem geschlossen wird und nicht als eigener App-Ort gelten soll, ist es ein `Fullscreen Dialog`.
|
||||
- Wenn der Kontext sichtbar bleiben und rechts/seitlich bearbeitet werden soll, ist es ein `Drawer / Side Panel`.
|
||||
|
||||
### Dialog Sizes
|
||||
|
||||
Status: validiert am 2026-07-02.
|
||||
|
||||
Zentrierte Dialoge nutzen vier Breiten:
|
||||
|
||||
- `XS`: 420px.
|
||||
- `S`: 560px.
|
||||
- `M`: 720px.
|
||||
- `L`: 1200px max.
|
||||
|
||||
Richtwerte:
|
||||
|
||||
- `XS`: kurze Bestaetigung oder knapper Hinweis.
|
||||
- `S`: kleines Formular mit wenigen Feldern.
|
||||
- `M`: normales Formular mit mehreren Feldern oder kurzer Section-Struktur.
|
||||
- `L`: grosser Editor mit Navigation, Suche und komplexeren Einstellungen.
|
||||
|
||||
Responsive / grosse Viewports:
|
||||
|
||||
- Dialoge wachsen auf breiten Monitoren, auch 4K, nicht automatisch mit.
|
||||
- Die Breitenklasse bleibt fix, der Dialog bleibt zentriert und nur der aeussere Overlay-Abstand wird groesser.
|
||||
- Auf kleineren Viewports braucht der Dialog eine Max-Width-Regel relativ zum Viewport, damit er nicht ueber den Rand laeuft.
|
||||
|
||||
Fullscreen Dialog:
|
||||
|
||||
- Fullscreen Dialog nutzt Fill fuer Width und Height innerhalb des Overlays.
|
||||
- Es bleibt ein aeusserer Rand zum Viewport sichtbar.
|
||||
- Arbeitswert fuer den aeusseren Rand: 24px pro Seite auf Desktop.
|
||||
- Die Breite skaliert nicht unendlich. Maximalbreite ist die Breite eines 2K-Monitors abzueglich Desktop-Rand.
|
||||
- Arbeitswert fuer 2K: 2560px Breite. Daraus ergibt sich `max-width: calc(2560px - 48px)` bzw. 2512px.
|
||||
- Umsetzungsidee: `width: calc(100vw - 48px)`, `max-width: 2512px`, `height: calc(100vh - 48px)`.
|
||||
- Auf breiteren Monitoren bleibt der Fullscreen Dialog zentriert und der aeussere Rand wird groesser.
|
||||
- Der Fullscreen Dialog bleibt ein temporaeres Overlay und ersetzt keine normale Page.
|
||||
|
||||
### Komponenten-Ownership bei Layout-Abstaenden
|
||||
|
||||
Layout-Regeln beschreiben den gewuenschten sichtbaren Standard, nicht automatisch manuelle Overrides.
|
||||
|
||||
Wenn Subframe-Komponenten wie `Dialog`, `Modal`, `Button`, `Text Input`, `Table` oder `Card` das passende Padding/Gapping bereits intern besitzen, wird dieses Komponentenverhalten benutzt.
|
||||
|
||||
Beim Erstellen von Screens oder MCP-Prompts gilt:
|
||||
|
||||
- den validierten Layout-Standard einhalten
|
||||
- vorhandene Komponenten-Defaults verwenden, wenn sie den Standard bereits abbilden
|
||||
- Padding oder Gap nicht pseudomaessig nachbauen, wenn die zuständige Komponente dafuer bereits eine Eigenschaft, Variante oder Auto-Layout-Struktur hat
|
||||
|
||||
### Nutzung bei Subframe-MCP-Arbeit
|
||||
|
||||
Status: Pflichtregel fuer Screen- und Modal-Arbeit.
|
||||
|
||||
Wenn mit dem Subframe-MCP neue Screens, Modale oder Varianten gebaut oder editiert werden, muessen diese Layout-Regeln als aktive Referenz verwendet werden.
|
||||
|
||||
Arbeitsregel:
|
||||
|
||||
- Vor einem Subframe-MCP-Prompt diese Layout-Regeln lesen.
|
||||
- Im Prompt ausdruecklich verlangen, dass die validierten HiveGrid/Subframe-Layout-Standards verwendet werden.
|
||||
- Bei Dialogen zusaetzlich die echte Subframe-Dialog-Struktur verlangen, nicht nur ein visuell nachgebautes Modal.
|
||||
- Page Padding, Card/Surface Padding, Grid Gap, Text-Rhythmus, Dialog Sizes, Dialog Padding und Dialog Internal Gaps aus dieser Datei anwenden.
|
||||
- Komponenten-Defaults und Varianten verwenden, wenn sie den Standard bereits korrekt abbilden.
|
||||
- Keine manuellen Tailwind-Overrides fuer Werte setzen, die bereits ueber Auto Layout, Subframe-Komponenten oder Varianten abgedeckt sind.
|
||||
- Nach dem MCP-Edit per Readback pruefen, ob die relevante Struktur und die Layout-Regeln wirklich im Ergebnis gelandet sind.
|
||||
@@ -56,6 +56,14 @@ Gemeint ist der lokale Ordner `./03 Quellen und Referenzen/hivegrid-cloud/`. Wen
|
||||
|
||||
Subframe-Links stehen in den jeweiligen Screen-Dateien im Frontmatter-Feld `subframe`.
|
||||
|
||||
Bei jeder Subframe-MCP-Arbeit an Screens oder Modalen muessen die validierten Layout-Standards als Referenz genutzt werden:
|
||||
|
||||
- Vor dem Prompten oder Editieren `04 Standards/Subframe UI Standards/Layout/README.md` lesen.
|
||||
- Im Subframe-Prompt explizit sagen, dass die Layout-Regeln aus den Subframe UI Standards einzuhalten sind.
|
||||
- Page Padding, Card/Surface Padding, Text-Rhythmus, Dialogbreiten, Dialog-Padding und Dialog-Internal-Gaps nicht frei nachbauen, sondern die Standards und vorhandenen Komponenten-Defaults verwenden.
|
||||
- Wenn eine Subframe-Komponente den Standard bereits intern abbildet, diese Komponente/Variante nutzen statt manuelle Tailwind- oder Container-Overrides zu setzen.
|
||||
- Nach MCP-Aenderungen per Readback pruefen, ob die relevante Struktur und die Layout-Standards tatsaechlich angewendet wurden.
|
||||
|
||||
Modal-Screens muessen als echte Subframe-Dialoge gebaut werden:
|
||||
|
||||
- Struktur: `DialogLayout` -> `Dialog` -> `Dialog.Content` -> Modal-Inhalt.
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,83 @@
|
||||
---
|
||||
kind: ticket-handoff
|
||||
project: HiveGrid Screen Project
|
||||
ticket: D-D0b
|
||||
area: Foundation / Layout Standards
|
||||
status: Fertig / Review
|
||||
repo: https://git.tool-ctrl.de/david/Hivegrid-Wireframes
|
||||
stand: 2026-07-02
|
||||
---
|
||||
|
||||
# D-D0b Layout Standards
|
||||
|
||||
Repo: https://git.tool-ctrl.de/david/Hivegrid-Wireframes
|
||||
|
||||
Arbeitsbereich im Repo: [D-D0b Layout Standards](../../02%20Wireframes/D0%20Foundation/D-D0b%20Layout%20Standards/D-D0b%20Layout%20Brainstorming.md)
|
||||
|
||||
Backlog: [D-D0b Backlog](../../02%20Wireframes/D0%20Foundation/D-D0b%20Layout%20Standards/D-D0b%20Backlog.md)
|
||||
|
||||
Dauerhafte Standards: [Subframe UI Standards / Layout](../../04%20Standards/Subframe%20UI%20Standards/Layout/README.md)
|
||||
|
||||
Entscheidungslog: [Subframe UI Standards / Entscheidungen](../../04%20Standards/Subframe%20UI%20Standards/02_Entscheidungen.md)
|
||||
|
||||
HTML-Preview-Artefakt: [D-D0b Layout Preview](<Assets/D-D0b-Layout-Preview.html>)
|
||||
|
||||
Lokale Arbeitskopie der Preview: `99 Temp/D-D0b Layout Preview/index.html`
|
||||
|
||||
## Kurzfassung
|
||||
|
||||
Fuer `D-D0b` wurden die grundlegenden Layout- und Composition-Standards fuer HiveGrid validiert, dokumentiert und in die dauerhaften Subframe UI Standards uebertragen.
|
||||
|
||||
Die HTML-Preview bleibt lokal erhalten, ist aber nicht Source of Truth. Die verbindlichen Regeln stehen in den Markdown-Dateien.
|
||||
|
||||
Eine bereinigte Kopie der Preview liegt als Ticket-Artefakt im Repo, damit sie spaeter direkt aus dem fertigen Ticket heraus referenziert werden kann.
|
||||
|
||||
## Gemacht
|
||||
|
||||
- 8px-basiertes Spacing-System mit erlaubten Standardwerten festgelegt.
|
||||
- Page-, Card-, Surface-, Grid- und Section-Abstaende validiert.
|
||||
- Token-aware Text-Rhythmus fuer Page-/Section-Header validiert.
|
||||
- Button-, Form-, Table- und State-Ownership abgegrenzt, damit Screen-Layouts Komponentenstandards nicht nachbauen.
|
||||
- Dialog- und Fullscreen-Dialog-Groessen validiert.
|
||||
- Dialog-interne Gaps validiert.
|
||||
- Backlog-Punkte in eigene Backlog-Datei ausgelagert.
|
||||
- Lokale Preview behalten und als lokale Referenzhilfe markiert.
|
||||
- HTML-Preview als versioniertes Ticket-Artefakt abgelegt.
|
||||
|
||||
## Validiert
|
||||
|
||||
- `D01 Spacing Scale`: `4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96`.
|
||||
- `D02 Page/Card/Grid`: Page 24px minimum, Card/Surface 16px, Grid/Card Gap 16px, kompakt lokal 12px, Section Gap 24px.
|
||||
- `D03 Text-Rhythmus`: `0 / 24 / 0 / 12`, nur zusammen mit 150%-Texttokens fuer beschreibende Page-/Section-Texte.
|
||||
- `D04 Button Ownership`: Standardaktionen nutzen Button Default/Medium/36px; Button-Padding und Varianten kommen aus der Button-Komponente.
|
||||
- `D05 Form Layout Gap`: Komplette Field-Komponenten stehen 16px auseinander; Field-Anatomy kommt aus der Input-Komponente.
|
||||
- `D06 Table Ownership`: Tabellen-Dichte kommt aus der Table-Komponente; Carbon ist nur Referenz.
|
||||
- `D07 Dialog Sizes`: XS 420, S 560, M 720, L 1200; Fullscreen `width: calc(100vw - 48px)`, `max-width: 2512px`, `height: calc(100vh - 48px)`.
|
||||
- `D08 Dialog Internal Gaps`: Balanced mit Title/Description 8px, Field/Form Row 16px, Section 24px, Footer Button 8px.
|
||||
- `D09 States`: Empty/Error/No-Permission sind inline State-Komponenten, keine Modale.
|
||||
|
||||
## Wichtige Arbeitsregeln fuer neue Screens
|
||||
|
||||
- Komponenten-Defaults verwenden, wenn sie den validierten Standard bereits abbilden.
|
||||
- Padding oder Gap nicht manuell nachbauen, wenn die zuständige Komponente dafuer bereits Varianten, Props oder Auto Layout besitzt.
|
||||
- Modale in Subframe als echte Dialog-Komponenten bauen, nicht als Fake-Modal.
|
||||
- Page-/Section-Beschreibungen als 150%-Texttokens setzen, wenn sie umbrechen koennen.
|
||||
- `0px` bei D03 ist bewusst definiert und darf nicht automatisch durch 4px/8px ersetzt werden.
|
||||
|
||||
## Backlog / Offen
|
||||
|
||||
Nicht blockierend fuer den Handoff:
|
||||
|
||||
- Mobile Layout Standards.
|
||||
- Drawer / Side Panel Breitenregeln.
|
||||
- Button-/Action-Semantik.
|
||||
- Error-/Result-Dialog-Komponenten.
|
||||
- No-Permission-Komponente und Table No-Permission State.
|
||||
- Fill Buttons fuer XS/S Dialoge.
|
||||
- Weitere Accessibility- und Carbon-Recherche.
|
||||
|
||||
Details: [D-D0b Backlog](../../02%20Wireframes/D0%20Foundation/D-D0b%20Layout%20Standards/D-D0b%20Backlog.md)
|
||||
|
||||
## Hinweis fuer Ticket-System
|
||||
|
||||
Diese Datei ist der kompakte Handoff fuer `D-D0b`. Fuer verbindliche Regeln sind die [Subframe UI Standards / Layout](../../04%20Standards/Subframe%20UI%20Standards/Layout/README.md) massgeblich.
|
||||
@@ -7,9 +7,17 @@ Dieser Bereich ist der Handoff-Index fuer Ticket-Zusammenfassungen.
|
||||
| Pfad | Zweck |
|
||||
|---|---|
|
||||
| `Fertige Tickets/` | fertige oder handofffaehige Ticket-Zusammenfassungen |
|
||||
| `Fertige Tickets/Assets/` | referenzierbare Zusatzartefakte fuer fertige Tickets, z. B. HTML-Previews |
|
||||
|
||||
## Regel
|
||||
|
||||
Wenn ein Ticket fertig oder uebergabereif ist, wird eine Markdown-Datei in `Fertige Tickets/` angelegt oder aktualisiert.
|
||||
|
||||
Die Detailwahrheit bleibt in den Wireframe-Paketen und im `Screen Paket Tracker`; die Ticket-Datei ist der kompakte Handoff-Index.
|
||||
|
||||
## Fertige Tickets
|
||||
|
||||
| Ticket | Datei |
|
||||
|---|---|
|
||||
| D-P2 | [D-P2 Auth Wireframes](<Fertige Tickets/D-P2 Auth Wireframes.md>) |
|
||||
| D-D0b | [D-D0b Layout Standards](<Fertige Tickets/D-D0b Layout Standards.md>) |
|
||||
Reference in new issue
Block a user