Layout
Position, Abstand und Ausrichtung vermitteln Hierarchie, bevor ein Wort gelesen wird. Dieser Skill schafft diese Struktur und stellt sie auf die Probe: Größe ändern, übersetzen, für RTL spiegeln.
Schreibe jede Korrektur im projekt eigenen Gestaltungssystem. Die Zahlen unten sind Ausgangspunkte für Oberflächen ohne etabliertes Dichtesystem. Wo eines angewendet wird, verwende es wie beschrieben und nicht als vertraut aussehenden Ersatz. Behalte bewusste Plattform-Chrome, kompakte professionelle Werkzeuge und Projekt-Tokens bei, wo sie die Stresstests noch bestehen.
Treffbereiche und Fokusverhalten gehören zu better-accessibility. Ecken, Schatten und Animationen gehören zu better-ui. Zeilenlänge und Textabstand gehören zu better-typography.
Mit Abstand gruppieren, nicht mit Linien
Abstände gruppieren zuerst, Hintergrundformen als Zweites, Trennlinien zuletzt und nur dort, wo Abstand allein die Struktur nicht tragen kann. Der Abstand zwischen Gruppen muss mindestens das 2‑fache des Abstands innerhalb einer Gruppe betragen (8px innerhalb der Gruppe zu 16px+ zwischen Gruppen), sonst wirkt die Gruppierung wie Rauschen. Ausrichtungskanten und Wichtigkeitsreihenfolge sind in grouping-and-alignment.md beschrieben.
Steuerelemente von Inhalten unterscheiden
Gib jedem interaktiven Element eine Hintergrundform, einen Rahmen oder eine konsistente Platzierungszone. Ein Steuerelement, das wie der statische Text daneben gestaltet ist, wird nicht als Steuerelement erkannt.
An gemeinsamen Kanten ausrichten
Wähle Ausrichtungskanten und bleibe bei ihnen; jede abweichende Kante wirkt wie Rauschen. Verwende einen Schritt des projekt eigenen Abstandssystems pro Unterordnungsebene, wobei 16px ein nützlicher Standard ist.
Verwende logische Eigenschaften für richtungsabhängiges Layout: padding-inline-start, margin-inline-end. Behalte physisches links und rechts für wirklich physische Geometrie vor.
Nach Wichtigkeit ordnen
Der wichtigste Inhalt befindet sich nahe dem oberen und dem vorderen Rand. Die Lesereihenfolge verläuft von oben nach unten, von vorne nach hinten. Denke in vorderer und hinterer Richtung, nicht in links und rechts.
Auf verborgenen Inhalt hinweisen
Progressive Offenlegung benötigt einen sichtbaren Hinweis. Verwende das etablierte Signal des Projekts, oder lasse das nächste Element 16–32px über die Scrollkante hinausragen, oder zeige ein Offenlegungs-Steuerelement. Inhalt, der ohne Hinweis verborgen ist, könnte genauso gut nicht existieren.
Atemraum zwischen Zielen
Ohne etabliertes Dichtesystem beginne mit 12px zwischen benachbarten umrahmten oder gefüllten Steuerelementen und 24px um randlose Text- und Symbol-Steuerelemente. Kompakte Layouts können weniger verwenden, solange die Treffbereiche von better-accessibility sich nicht überlappen und die Steuerelemente unterscheidbar bleiben. Layout-Ränder und Breakpoint-Rezepte sind in spacing-and-adaptivity.md beschrieben.
Schaltflächen von den Rändern einrücken
Halte in Inhaltslayouts vollbreite Schaltflächen innerhalb der Layout-Ränder mit einem sichtbaren Radius, beginnend bei etwa 16px inline auf Mobilgeräten. Rand-an-Rand-Aktionen funktionieren, wenn sie der etablierten Plattform-Chrome folgen, sichere Bereiche berücksichtigen und von der System-UI unterscheidbar bleiben.
Inhalt läuft aus, Steuerelemente schwimmen
Hintergründe und Medien erstrecken sich bis zu den Viewport-Kanten. Steuerelemente und Text bleiben innerhalb der Layout-Ränder und sicheren Bereiche (env(safe-area-inset-*)). Sticky-Chrome schwebt über der Inhaltsebene, anstatt sie zu blockieren.
Struktur halten, bis sie bricht
Breakpoints kommen vom Inhalt, nicht von Gerätevorgaben. Behalte das erweiterte Layout so lange bei, wie es wirklich passt, und wechsle spät um. Bevorzuge Container Queries für komponentenbasierte Anpassung und teste zuerst die kleinsten und größten Größen.
Auf Wachstum und Beschneiden vorbereiten
Übersetzte Zeichenketten wachsen, und kurze wachsen proportional mehr, daher ist ein einsilbiges Schaltflächenlabel das riskanteste Element auf dem Bildschirm. Setze keine feste Breite oder Höhe auf einen Textcontainer und lasse Zeilen umbrechen. Teste mit Pseudo-Lokalisierung und einem repräsentativen Gebietsschema, anstatt einen Prozentsatz zu veranschlagen.
Parke niemals eine kritische Aktion dort, wo Größenänderung oder Scrollen sie abschneidet. Halte sie im normalen Fluss oder in stabilem Chrome, das zum Produkt passt.
Bevor du fertig bist
| Fehler | Korrektur |
|---|---|
margin-left / padding-right in einem lokalisierbaren Layout | margin-inline-start / padding-inline-end |
| Inhaltslayout-Schaltfläche berührt Viewport-Kante | Innerhalb der Projekt-Ränder einrücken; bewusste Plattform-Chrome beibehalten |
| Breakpoints bei 768/1024, weil sie die Standardwerte sind | Umbrechen, wo der Inhalt tatsächlich nicht mehr passt |
| Textcontainer mit fester Breite, nur auf eine Sprache ausgelegt | max-width und Umbruch; Pseudo-Lokalisierung testen |
| Primäraktion am abschneidegefährdeten unteren Rand eines Bereichs | Sticky-Positionierung oder stabiles Chrome mit safe-area-Padding |
Berichterstattung
Schweregrad. HIGH blockiert Inhalt oder eine Aktion bei einem unterstützten Viewport. MEDIUM schadet der Hierarchie, Lesereihenfolge oder Anpassbarkeit. LOW ist isolierte Ausrichtungs- oder Abstands-Politur.
Überprüfung. Ohne Browser: logische Eigenschaften anstelle physischer, Container- und Media Queries gegen die Liste der unterstützten Viewports und DOM-Reihenfolge gegen die beabsichtigte Lesereihenfolge. Mit einem: jede unterstützte Breite, 200 % Zoom und RTL-Spiegelung. Melde jede Prüfung, die du nicht durchführen konntest, als Not verified.
Format. Gruppiere die Ergebnisse unter dem Prinzip, das jedes verletzt, geordnet nach Schweregrad, eine Zeile pro Ursache, die jede Stelle auflistet, an der sie auftritt:
| Severity | Location | Before | After | Why |
|---|
Location ist path/to/file:line. Why benennt das Prinzip und die Auswirkung auf den Benutzer.
Beende mit Block, wenn HIGH verbleibt, sonst mit Approve, und lasse den Rest in der Tabelle als zu erledigende Arbeit stehen. Approve niemals für Bereiche, die du nicht inspiziert hast. Wenn es nichts zu melden gibt, gib an: „No actionable layout findings“ und melde die Überprüfung.