HiveGrid-Wireframes/04 Standards/Subframe UI Standards/Layout

Layout-Regeln

Status: Aktiv

Dieser Bereich ist die Zielstruktur fuer dauerhafte Layout-Regeln der Subframe UI Standards.

Hier hinein gehoeren nur Regeln, die als systemweite Subframe-/HiveGrid-Regel validiert wurden.

Zweck

Dokumentiert werden koennen spaeter:

• Layout-Raster und Spacing-Rhythmus
• Page-, Card-, Dialog- und Table-Padding
• Dialogbreiten
• Text-Rhythmus
• Form- und Settings-Composition
• Table-, List- und State-Layouts

Nicht hier hinein

• unvalidierte Brainstorming-Werte
• einzelne Screen-Entscheidungen
• Ticket-spezifische Sonderfaelle
• Komponenten-Details, die besser in Components/ oder 04_Gruppenregeln liegen

Arbeitsregel

D-D0b war der Arbeitsort fuer die erste Layout-Entscheidungsrunde.

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.