Seminar DatoCMS: Structured Text und modulare Inhalte

Structured Text und Modular Content werden nicht als beliebige Layoutbaukästen, sondern als kontrollierte Inhaltsstrukturen entworfen. Das Seminar verbindet DAST, Blockbibliothek, Links, Inline-Records, Editor Experience, GraphQL-Fragmente, Renderer, Barrierefreiheit, Tests und Migration bestehender Rich-Text-Inhalte.

Inhaltsübersicht

Kapitelinhaltsverzeichnis

• Lernziele und Einsatzbereiche
• Vorbereitung und Arbeitsweise
• Seminarinhalte
• Praktische Übungen und Anwendung

Lernziele und Einsatzbereiche

Kapitelinhaltsverzeichnis

• Kompetenzziele
• Typische Einsatzszenarien
• Abgrenzung und Schwerpunkt

Kompetenzziele

Die Inhalte sind auf unmittelbar anwendbare, prüfbare Kompetenzen ausgerichtet.

• Structured Text, Modular Content und Beziehungen nach klaren Kriterien unterscheiden.
• Eine wiederverwendbare, begrenzte Blockbibliothek mit guter Editor Experience entwerfen.
• GraphQL-Fragmente und Renderer mit defensiver Typbehandlung implementieren.
• Barrierefreiheit, Migration und langfristige Wartbarkeit durch Tests absichern.

Typische Einsatzszenarien

Das Seminar eignet sich insbesondere für die folgenden Projekt- und Betriebssituationen.

• Redaktionell flexible Landingpages.
• Lange Artikel mit eingebetteten Medien und fachlichen Bausteinen.
• Ablösung unstrukturierter HTML- oder Rich-Text-Felder.

Abgrenzung und Schwerpunkt

Die fachliche Tiefe wird durch folgende Grenzen bewusst fokussiert.

• Kein vollständiges Design-System-Seminar.
• Freie HTML-Eingabe wird nicht als Zielmodell empfohlen oder geübt.
• Frameworkspezifische Details werden anhand einer Referenzimplementierung behandelt.

Vorbereitung und Arbeitsweise

Kapitelinhaltsverzeichnis

• Zielgruppen
• Vorkenntnisse und Schulungsumgebung
• Didaktisches Vorgehen
• Qualitäts- und Abnahmekriterien

Zielgruppen

Content Modeling, Redaktion, UX, Frontend-Entwicklung, technische Architektur und Design-System-Teams.

Vorkenntnisse und Schulungsumgebung

Grundkenntnisse in DatoCMS-Modellen und Komponentenarchitektur. Für die Renderingübungen sind JavaScript- oder TypeScript-Kenntnisse erforderlich.

1. Schritt 1: Zugänge, Rollen und Schulungsprojekt vor Seminarbeginn kontrollieren.
2. Schritt 2: Beispieldaten, Assets, Quellmaterial oder Codebasis entsprechend dem Seminarthema bereitstellen.
3. Schritt 3: Ausgangszustand dokumentieren, damit Übungen wiederholt und Abweichungen eindeutig bewertet werden können.

Didaktisches Vorgehen

Kurze Fachblöcke werden unmittelbar mit Demonstrationen, geführten Arbeitsschritten, eigenständigen Laborphasen und kontrollierten Fehlerfällen verbunden.

1. Schritt 1: Ausgangsproblem und gewünschtes Sollverhalten präzisieren.
2. Schritt 2: Konfiguration oder Implementierung in kleinen, überprüfbaren Schritten ausführen.
3. Schritt 3: Normalfall, Grenzfall und mindestens einen Fehlerfall testen.
4. Schritt 4: Nachweis, Betriebsregel oder Checkliste aus dem Übungsergebnis ableiten.

Qualitäts- und Abnahmekriterien

• Konfigurationen und Arbeitsschritte sind reproduzierbar dokumentiert.
• Berechtigungen, Datenstände und Environments sind eindeutig voneinander getrennt.
• Positive und negative Testfälle besitzen ein erwartetes und nachvollziehbares Ergebnis.
• Fehlerzustände führen zu einer kontrollierten Diagnose und einem definierten Wiederanlauf.

Seminarinhalte

Kapitelinhaltsverzeichnis

• Entscheidung zwischen Text, Modular Content und Beziehungen
• DAST-Grundstruktur
• Blockbibliothek und Wiederverwendung
• Links, Inline-Records und eingebettete Records
• Editor Experience und Inhaltsregeln
• GraphQL-Fragmente für polymorphe Inhalte
• Komponentenbasierter Renderer
• Medien und Barrierefreiheit
• Validierung und automatisierte Tests
• Migration bestehender Inhalte

Entscheidung zwischen Text, Modular Content und Beziehungen

Die Datenstruktur folgt Semantik, Wiederverwendung und Renderingbedarf statt einem universellen Baukasten.

1. Schritt 1: Inhaltsbeispiele und Autorenaufgaben analysieren.
2. Schritt 2: Eigenständige Records, eingebettete Blocks und Fließtext unterscheiden.
3. Schritt 3: Feldtypentscheidung mit Vor- und Nachteilen dokumentieren.

DAST-Grundstruktur

Structured Text wird als validierter Dokumentbaum mit definierten Node-Typen verstanden.

1. Schritt 1: Beispieldokument im Editor anlegen.
2. Schritt 2: Dokumentstruktur und relevante Knoten in der API untersuchen.
3. Schritt 3: Ungültige oder nicht unterstützte Struktur als Grenzfall diskutieren.

Blockbibliothek und Wiederverwendung

Blocks besitzen begrenzte Verantwortung, klare Namen und stabile Felder.

1. Schritt 1: Benötigte Inhaltsbausteine aus dem Designsystem ableiten.
2. Schritt 2: Blockmodelle mit Validierungen und Hilfetexten anlegen.
3. Schritt 3: Wiederverwendung in Structured Text und Modular Content prüfen.

Links, Inline-Records und eingebettete Records

Verknüpfungen werden nach Lesefluss, Wiederverwendung und Darstellung unterschieden.

1. Schritt 1: Link-, Inline- und Blockfälle aus Beispielen klassifizieren.
2. Schritt 2: Zulässige Modelle im Feld konfigurieren.
3. Schritt 3: Gelöschte, unveröffentlichte und unvollständige Ziele testen.

Editor Experience und Inhaltsregeln

Slash-Befehle, Toolbar, Blockauswahl und Hilfetexte unterstützen einen konsistenten Schreibprozess.

1. Schritt 1: Erlaubte Formatierungen und Blocktypen begrenzen.
2. Schritt 2: Benennung, Vorschau und Feldhinweise redaktionstauglich gestalten.
3. Schritt 3: Eine reale Pflegeaufgabe mit Testredaktion durchführen.

GraphQL-Fragmente für polymorphe Inhalte

Jeder Blocktyp erhält ein eigenes Fragment und einen gemeinsamen Basisvertrag.

1. Schritt 1: Node-, Link- und Blocktypen inventarisieren.
2. Schritt 2: Fragmente und Typunterscheidung formulieren.
3. Schritt 3: Query mit allen vorgesehenen Typen sowie leerem Dokument testen.

Komponentenbasierter Renderer

Der Renderer ordnet Datentypen explizit Komponenten zu und besitzt einen kontrollierten Fallback.

1. Schritt 1: Mappingtabelle aus Typen und Komponenten erstellen.
2. Schritt 2: Renderer für Standardknoten, Links und Blocks implementieren.
3. Schritt 3: Unbekannten Typ, fehlende Daten und verschachtelte Inhalte testen.

Medien und Barrierefreiheit

Bilder, Videos, Überschriften und Links werden mit strukturellen und zugänglichen Regeln gerendert.

1. Schritt 1: Alt-Text-, Fokus- und Beschriftungsanforderungen definieren.
2. Schritt 2: Medienkomponenten mit responsiver Ausgabe anbinden.
3. Schritt 3: Überschriftenhierarchie, Linktexte und Tastaturzugriff prüfen.

Validierung und automatisierte Tests

Schema- und Renderingänderungen werden gegen einen Katalog repräsentativer Dokumente geprüft.

1. Schritt 1: Fixture-Dokumente für jeden Node- und Blocktyp erstellen.
2. Schritt 2: Renderer- und Snapshot-nahe Tests definieren.
3. Schritt 3: Schemaerweiterung und Rückwärtsverträglichkeit simulieren.

Migration bestehender Inhalte

HTML oder Modular Content wird mit expliziten Transformationsregeln in Structured Text überführt.

1. Schritt 1: Quellstrukturen und Zielknoten inventarisieren.
2. Schritt 2: Transformation und Fallback für unbekannte Elemente implementieren.
3. Schritt 3: Gerenderte Ausgabe und Datenverlust anhand einer Stichprobe prüfen.

Praktische Übungen und Anwendung

Kapitelinhaltsverzeichnis

• Blockbibliothek für eine Landingpage
• GraphQL-Query und Renderer
• Barrierefreie Inhaltsprüfung
• Rich-Text-Migration
• Prüf- und Abnahmekriterien

Blockbibliothek für eine Landingpage

Szenario: Redaktion benötigt Text, Zitat, Bild-Text, Galerie und Call-to-Action.

1. Schritt 1: Komponenten und Inhaltsverantwortung analysieren.
2. Schritt 2: Blockmodelle und Felder definieren.
3. Schritt 3: Editor Experience mit Beispieldaten testen.
4. Schritt 4: Blockliste nach Redundanz und Überflexibilität prüfen.

Prüfkriterium: Die Blocks sind semantisch klar, wiederverwendbar, validiert und auf den tatsächlichen Komponentenbestand begrenzt.

GraphQL-Query und Renderer

Szenario: Ein Structured-Text-Dokument enthält Standardtext, Link, Inline-Record und drei Blocks.

1. Schritt 1: Fragmente je Typ erstellen.
2. Schritt 2: Renderer-Mapping implementieren.
3. Schritt 3: Fixture-Dokumente ausgeben.
4. Schritt 4: Unbekannten Typ und fehlende Referenz testen.

Prüfkriterium: Query und Renderer decken alle Typen, Nullfälle und einen unbekannten Block ohne Laufzeitabbruch ab.

Barrierefreie Inhaltsprüfung

Szenario: Ein Dokument enthält falsche Überschriftenfolge, unklaren Linktext und Bild ohne Alt-Text.

1. Schritt 1: Dokument mit Prüfkriterien untersuchen.
2. Schritt 2: Fehler nach Redaktion oder Renderer zuordnen.
3. Schritt 3: Inhalt beziehungsweise Komponente korrigieren.
4. Schritt 4: Erneute Tastatur- und Strukturprüfung durchführen.

Prüfkriterium: Struktur- und Medienfehler werden erkannt, korrigiert und als Redaktionsregel dokumentiert.

Rich-Text-Migration

Szenario: Ein HTML-Feld mit Listen, Links, Bildern und Sondercontainer soll in Structured Text überführt werden.

1. Schritt 1: HTML-Muster und Häufigkeiten erfassen.
2. Schritt 2: Mapping zu DAST-Knoten und Blocks definieren.
3. Schritt 3: Transformationslauf auf einer Stichprobe ausführen.
4. Schritt 4: Daten- und Renderingvergleich dokumentieren.

Prüfkriterium: Standardinhalte werden verlustarm transformiert; Sondercontainer sind als kontrollierte Blocks oder Nacharbeitsfälle behandelt.

Prüf- und Abnahmekriterien

Die Übungen werden nicht allein nach sichtbarer Funktion, sondern nach Reproduzierbarkeit, Sicherheit, Datenqualität und Betriebsfähigkeit bewertet.

• Der Ausgangszustand, die Änderung und der geprüfte Zielzustand sind dokumentiert.
• Mindestens ein Negativ- oder Störungstest wurde kontrolliert durchgeführt.
• Geheimnisse, produktive Daten und unbeteiligte Systeme wurden nicht in die Übungen einbezogen.
• Offene Punkte besitzen Priorität, verantwortliche Stelle und nächsten Prüftermin.