coastdigitalgroup/coastai-skills

Skeleton-Zustandssystem

Zweck

Das Skeleton-Zustandssystem stellt eine Methodik zur Gestaltung des Ladezustands einer Benutzeroberfläche bereit. Anders als generische Spinner oder Fortschrittsbalken bilden Skelette mithilfe von „Knochen“ (schematische Platzhalter) das endgültige Layout nach. Dies reduziert die gefühlte Wartezeit des Nutzers und verhindert kumulative Layoutverschiebungen (CLS), indem vor dem Eintreffen der Inhalte bereits der benötigte Platz reserviert wird.

Anwendungsfälle

• Datenschwere Dashboards: Mehrere Widgets laden mit unterschiedlichen Geschwindigkeiten.
• Content-Feeds: Scrollen durch Listen von Artikeln, Produkten oder Social-Media-Beiträgen.
• Bildlastige Raster: Reservieren von Platz für hochauflösende Bilder, um ein „Springen“ der Seite zu verhindern.
• Such- und Filteransichten: Sofortiges Feedback, dass das System eine Anfrage verarbeitet.
• Single-Page-Anwendungen (SPAs): Verwalten von Übergängen zwischen Routen, bei denen Daten asynchron geladen werden.

Wann NICHT verwenden

• Sofortige Interaktionen: Wenn Inhalte in unter 300ms laden, kann ein Skeleton ablenkendes „Flackern“ verursachen.
• Einfache, kontextarme Ladevorgänge: Für kleine Elemente wie einen einzelnen Button oder ein winziges Tag ist ein Standard-Spinner oder „Lädt…“-Text angemessener.
• Statische Inhalte: Inhalte, die fest codiert oder gecached sind und sofort rendern.
• Hochfrequente Echtzeitdaten: Wenn sich Daten so schnell ändern, dass das Skeleton ständig ein- und ausgeblendet würde, kann das zu visueller Ermüdung führen.

Eingaben

1. Ziellayout: Das finale „voll geladene“ Design der Komponente oder Seite.
2. Inhaltsvariablen: Welche Teile der UI dynamisch sind (Text, Bilder, Preise, Avatare)?
3. Räumliche Dimensionen: Die exakten Höhen, Breiten und Seitenverhältnisse der finalen Elemente.
4. Markenton: Die Primär- und Sekundärfarben für die Knochen-Basis und den Shimmer-Effekt.

Ausgaben

1. Skeleton-Blueprint: Eine schematische Karte, die die Anordnung der Knochen zeigt.
2. Knochenspezifikation: Definitionen für Form (Kreise vs. Rechtecke) und Größenfestlegung (fest vs. prozentbasiert).
3. Übergangsstrategie: Regeln dafür, wie das Skeleton aus- und der Inhalt eingeblendet wird.
4. Barrierefreiheitsanforderungen: Richtlinien für die Implementierung von aria-busy und aria-hidden.

Arbeitsablauf

1. Zielgeometrie abbilden

Zerlege die finale Komponente in ihre grundlegenden geometrischen Primitive:

• Kreise: Für Avatare, Icons oder abgerundete Buttons.
• Rechtecke (abgerundet): Für Karten, Bildcontainer und Textblöcke.
• Linien: Für einzelne Textzeilen (Überschriften, Metadaten).

2. Knochenhierarchie definieren

Nicht jedes Element benötigt einen Knochen. Fokussiere dich auf die strukturellen „Anker“:

• Primärer Knochen: Das größte visuelle Element (z. B. ein Produktbild).
• Sekundäre Knochen: Überschriften und primäre Metadaten.
• Tertiäre Knochen: Kleine Metadetails oder Aktionsbuttons (können oft weggelassen werden, wenn sie zu klein sind).

3. Räumliche Anpassung herstellen (Die CLS-Regel)

Stelle sicher, dass die Maße des Skeletts exakt dem Behälter des endgültigen Inhalts entsprechen:

• Seitenverhältnis: Verwende feste Seitenverhältnisse (z. B. 16:9 für Videos) für den Knochen, damit er seine Größe nicht ändert, wenn das Asset geladen wird.
• Textgrößen: Verwende Knochen, die der Zeilenhöhe und der ungefähren Breite des dargestellten Textes entsprechen.

4. Rhythmus und Shimmer-Animation gestalten

Skelette sollten sich „lebendig“ anfühlen, aber nicht ablenken:

• Basis-Farbe: Verwende eine kontrastarme, neutrale Farbe (z. B. Hellgrau).
• Shimmer (Der Puls): Wende eine subtile Gradienten-Animation an, die von links nach rechts verläuft.
• Synchronisation: Wenn mehrere Skelette auf dem Bildschirm sichtbar sind, sollten ihre Animationen synchronisiert sein, um visuelles Chaos zu vermeiden.
• Reduzierte Bewegung: Umschließe die Shimmer-Keyframe-Animation mit einer @media (prefers-reduced-motion: reduce)-Abfrage, die die Bewegung deaktiviert und auf einen statischen oder sanft pulsend opaken Knochen zurückfällt.

5. Den „Hand-off“-Übergang definieren

Plane den Ausstieg des Skeletts:

• Timing: Verwende eine kurze Einblendung (z. B. 200ms) für den echten Inhalt, um einen abrupten „Snap“-Übergang zu vermeiden.
• Staffelung: Entscheide bei Listen, ob Elemente alle auf einmal oder einzeln beim Laden erscheinen sollen.

Entscheidungsregeln

• Die 300ms-Regel: Zeige ein Skelett nur an, wenn der Ladevorgang voraussichtlich länger als 300ms dauert.
• Knochgenauigkeit: Ein Knochen sollte den Behälter darstellen, nicht die spezifischen Daten. Ein Textknochen sollte beispielsweise ein einfacher Balken sein, keine gezackte Linie, die bestimmte Buchstaben nachahmt.
• Zeilenanzahl: Verwende für mehrzeiligen Text 2 oder 3 Knochen mit unterschiedlichen Breiten (z. B. die letzte Zeile mit 60 % Breite), um den natürlichen Absatzfluss zu simulieren.
• Spinner vs. Skeleton:
  • Verwende ein Skeleton für seiten- oder abschnittsweise Übergänge.
  • Verwende einen Spinner für kleine, lokalisierte Aktionen (wie einen „Speichern…“-Button-Zustand).

Einschränkungen

• Barrierefreiheit: Skelette müssen mit aria-hidden="true" markiert werden, damit Screenreader nicht versuchen, die leeren Balken „vorzulesen“. Der übergeordnete Container sollte aria-busy="true" verwenden, während geladen wird, und idealerweise eine visuell verborgene aria-live="polite"-Region enthalten, die den Ladezustand und nach dem Ersetzen des Skeletts den Abschlusszustand ankündigt – verwende aria-live nicht auf den Skelett-Knochen selbst. Beachte prefers-reduced-motion für den Shimmer-Effekt.
• Kontrast: Die Skeleton-Farben müssen sich vom Hintergrund abheben, aber nicht so kontrastreich sein, dass sie wie aktiver Inhalt aussehen.
• Responsivität: Skeleton-Knochen müssen mit derselben Grid/Flex-Logik skalieren wie der endgültige Inhalt.

Häufige Fehlermuster

• Der „CLS-Sprung“: Ein 200 px hohes Skeleton wird durch 300 px hohen Inhalt ersetzt, was die Seite „springen“ lässt.
• Shimmer-Überlastung: Zu schnelle oder kontrastreiche Animationen, die Übelkeit oder Ablenkung verursachen.
• Inhalt-Knochen-Konflikt: Verwenden eines runden Knochens für ein quadratisches Bild oder umgekehrt.
• Überkomplexität: Versuch, jedes winzige Icon als Knochen nachzubilden, was zu einem überladenen „Geister“-Layout führt.
• Das „statische Skeleton“: Ein Skeleton ohne Animation, das leicht mit einer defekten oder leeren Seite verwechselt werden kann.

Validierungskriterien

• Skelett-Maße stimmen exakt mit dem finalen „geladenen“ Zustand überein (Kein CLS).
• Seitenverhältnisse für Bilder/Videos werden durch feste Container reserviert.
• Shimmer-Animation ist subtil und bewegt sich von links nach rechts.
• Textlastige Bereiche verwenden Knochen, die natürliche Zeilenlängen simulieren.
• aria-hidden="true" wird auf die Skeleton-Elemente angewendet, und der Ladecontainer verwendet aria-busy="true".
• Shimmer-Animation respektiert prefers-reduced-motion: reduce.
• Der Übergang vom Skeleton zum Inhalt erfolgt als sanfte Einblendung (ca. 200ms).
• Das Skeleton erscheint nicht bei Ladevorgängen, die schneller als 300ms sind.