🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português
🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português

FaceFlow — Layout System

A layout is the structural frame that wraps every page. It defines where the header goes, where the footer goes, what global styles apply, and where page-specific content is placed. Think of it as the "shell" of your website — consistent across all pages that use it.

Layout-Entwicklerdokumentation

Layouts definieren den gemeinsamen Seitenrahmen, der von FaceFlow-Seiten verwendet wird.

Für technische Anwender ist ein Layout der Page-Shell-Vertrag. Es legt fest, wo gemeinsam genutzte Bereiche liegen, wo Seiteninhalte eingefügt werden und wie eine Familie von Pages einen konsistenten Rahmen behält, ohne Struktur Seite für Seite zu duplizieren.

Core Responsibility

Ein Layout sollte kontrollieren:

  • die gesamte Dokumentstruktur
  • Platzierung von Header, Footer und gemeinsamen Bereichen
  • den Haupteinfügepunkt für Inhalte
  • strukturelle Wrapper und Rahmen für die Seiten-Familie
  • optionales layout-weites Styling oder Verhalten

Ein Layout sollte keine seiten-spezifischen Marketinginhalte besitzen.

Layout Skeleton

Die meisten Layouts lassen sich durch ein einfaches Muster verstehen:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>{{ page.title }}</title>
</head>
<body>
  {header}
  {siteComponents}
  <main>
    {content}
  </main>
  {footer}
</body>
</html>

Die zentrale Anforderung ist ein verlässlicher {content}-Einfügepunkt. Ohne diesen haben Pages keinen vorhersehbaren Ort zum Rendern.

Shell Contract Example

Ein Layout kann zusätzliche gemeinsam genutzte Bereiche bereitstellen und gleichzeitig die Ownership-Grenze sauber halten:

<body class="resource-layout">
  {header}
  <div class="resource-shell">
    <aside class="resource-sidebar">
      {siteComponents}
    </aside>
    <main class="resource-main">
      {content}
    </main>
  </div>
  {footer}
</body>

Die wichtige Regel ist, dass die Shell strukturell bleibt. Die Page besitzt weiterhin die Sequenz, die in {content} gerendert wird.

Relationship to Pages and Components

Behalte das Ownership-Modell klar:

  • Layout besitzt die Shell
  • Seite (Page) besitzt die Komposition der Experience
  • Komponente (Component) besitzt wiederverwendbare Inhaltsabschnitte innerhalb der Experience

Wenn Layouts strukturell bleiben, lassen sich Seiten-Familien leichter weiterentwickeln.

Shared Regions

Layouts sind der richtige Ort für gemeinsam genutzte Bereiche wie:

  • persistente Navigation
  • standardmäßige Footer-Rahmung
  • Dokumentations-Sidebars
  • Support-Leisten, die in einer Seiten-Familie verwendet werden

Beispiel:

<body class="docs-layout">
  {header}
  <div class="docs-shell">
    <aside class="docs-sidebar">
      {siteComponents}
    </aside>
    <main class="docs-content">
      {content}
    </main>
  </div>
  {footer}
</body>

Das ist strukturelle Wiederverwendung. Ein einmaliges Werbebanner gehört nicht hierher.

Layout Families

Gängige Layout-Familien umfassen:

  • Haupt-Marketing-Site-Shell
  • Kampagnen-Landing-Shell
  • Ressourcen- oder Dokumentations-Shell
  • Portal- oder Knowledge-Base-Shell

Jede Familie sollte ein dauerhaftes Strukturmuster darstellen, nicht eine temporäre Inhaltsvariante.

Layout-Level Styling

Layouts können gemeinsame Stilentscheidungen definieren, die zur Shell gehören:

<body class="min-h-screen bg-slate-950 text-white">
  {header}
  <main class="mx-auto max-w-7xl px-6 py-16">
    {content}
  </main>
  {footer}
</body>

Das ist angemessen, wenn der Stil zum Seitenrahmen gehört. Abschnittsspezifisches Styling gehört weiterhin in Komponenten.

Change Impact

Layout-Änderungen haben große Auswirkungen, weil ein Layout oft viele Pages beeinflusst.

Vor einer Änderung am Layout prüfen:

  • welche Seiten-Familie davon abhängt
  • ob sich die Bedeutung gemeinsamer Bereiche ändert
  • ob sich Inhaltsbreite, Abstände oder Navigationsannahmen ändern
  • ob bestehende Komponenten noch korrekt in die Shell passen

Layout Review Pattern

Wenn eine Layout-Änderung vorgeschlagen wird, prüfe die Auswirkungen in folgender Reihenfolge:

shell semantics
-> shared regions
-> content width and spacing
-> component fit
-> dependent page-family behavior

Das hilft Teams zu vermeiden, eine scheinbar kleine Shell-Änderung zu genehmigen, die stillschweigend mehrere abhängige Pages bricht.

Technical Review Checklist

  • Exponiert das Layout einen klaren Inhaltseinfügepunkt?
  • Kümmert es sich nur um Shell-Ebenen-Angelegenheiten?
  • Können mehrere Pages es ohne Einmal-Ausnahmen wiederverwenden?
  • Sind gemeinsame Bereiche wirklich gemeinsam?
  • Würde eine Änderung dieses Layouts viele Pages in verständlicher Weise beeinträchtigen?

Anti-Patterns

Vermeide:

  • direktes Einbetten seiten-spezifischer Texte im Layout
  • Erstellen nahezu identischer Layouts für kleine Variationen
  • Verschieben von Abschnittslogik in die Shell
  • Nutzung des Layouts als Ablageort für allen gemeinsamen Inhalt
  • Ändern der Shell-Semantik ohne Prüfung der abhängigen Pages

Example Decision Rule

Verwende ein Layout, wenn die Änderung den Rahmen um viele Pages betrifft:

new docs sidebar across the whole docs section -> Layout
new CTA block inside one page section -> Component
new page-specific proof content -> Page composition