toolctrl-labs/HiveGrid-Wireframes
9
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
58df5360aab2953ca8070f736eec2a135b855ea2
HiveGrid-Wireframes/02 Wireframes/D0 Foundation/D-D0b Layout Standards/D-D0b Layout Standards.md
T

12 KiB
Raw Blame History

kind, ticket, area, status, stand
kind ticket area status stand
final-planning D-D0b Layout Standards Abgeschlossen 2026-07-03

D-D0b Layout Standards

Kurzfassung

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:

HTML-Preview:

  • Versionierte Referenz: D-D0b Layout Preview
  • Separate Full-Page-Vorschau: D-D0b Full Page Preview
  • Lokale Arbeitskopien fuer Self-Hosting: 99 Temp/D-D0b Layout Preview/index.html und 99 Temp/D-D0b Layout Preview/preview.html
  • Die versionierte Preview liegt bewusst im D-D0b-Ordner, damit sie zusammen mit den Layout-Entscheidungen auffindbar bleibt.
  • Die Full-Page-Preview enthaelt einen ausklappbaren Standards-Drawer und optionale Rule-Hints, damit sichtbar ist, welche Regel an welcher Stelle der realistischen Beispielseite angewendet wird.
  • Die Preview ist visuelle Referenz, 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 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 Fachflows.
  • Backend-/Datenmodell-Logik.
  • App-Shell-Definition.
  • Vollstaendige Komponenten-Spezifikation.
  • Mobile Layout Standards.

Entscheidungsuebersicht

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

Validierte Standards

D01 Grundraster / Spacing Scale

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

Validierte Standards:

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

Regeln:

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

D03 Text-Rhythmus

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.

D04 Button Component Ownership

Button-Hoehen, Button-Innenpadding und Button-Varianten werden ueber die Button-Komponente abgedeckt.

Regeln:

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

D05 Form Layout Gap

Validierte Regel:

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

D06 Table Layout Ownership

Row Height, Cell Padding, Header-Dichte und Tabellenvarianten werden ueber die Table-Komponente abgedeckt.

Regeln:

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

D07 Dialog, Fullscreen Dialog und Drawer

Pattern-Definition:

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

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

Externe Referenzen

Reference in new issue View Git Blame Copy Permalink