Was macht site-motion: Website-Bewegungsbewertung und Versionsauswahl?
Wenn ein Benutzer sagt, eine Website sei „steif“ oder „statisch“, liegt das Problem oft nicht am Fehlen von Animationen oder einer langsamen Ladezeit, sondern daran, dass jede Aktion ein Verlassen und Neuladen der Seite erfordert und die Seite aus vielen zusammenhanglosen Blöcken besteht. Daher muss zuerst das Problem identifiziert werden, bevor entschieden wird, was bewegt werden soll.
Antworte in der Sprache des Benutzers. Fachbegriffe auf Englisch belassen.
Grundsätze
- Keine Änderungen am Produktionscode vor der Auswahl: Zuerst Diagnose, Lösungsvorschläge und Prototyp liefern. Erst nach expliziter Auswahl einer Version durch den Benutzer wird implementiert.
- Standardmäßig keine Layout-Änderungen: Ohne explizite Anforderung werden Farben, Schriftarten und Layout nicht geändert, nur die Interaktion. Ein kompletter Stilwechsel ist eine separate Aufgabe.
- Mobile First: Bewertung und Abnahme auf 375px; Desktop ist ein Bonus.
- Bewegung muss anklickbar sein: Ein statisches Bild vermittelt nicht das Gefühl. Versionen müssen als interaktive Prototypen erstellt werden.
- Bewegung muss einen Zweck haben: Jede Animation muss eine Benutzerfrage beantworten, z.B. „Habe ich geklickt?“, „Woher komme ich?“, „Wurden die Daten aktualisiert?“. Wenn nicht, entfernen.
- Bei werbefinanzierten Sites (SEO und Monetarisierung haben Vorrang vor Effekten): Animationen dürfen keine eigenständigen URLs, den sichtbaren HTML-Inhalt im ersten Bildschirm oder die Werbesichtbarkeit beeinträchtigen. Ausgenommen sind eingeloggte Backends und interne Tools.
- Neuer Inhalt = neue Seite, Änderungen am gleichen Inhalt = in place: Für einen anderen Artikel wird eine neue Seite benötigt, da dies eine neue URL und neue Werbeanfragen bedeutet. Aufklapp-Elemente, Filter und Sortierung erfolgen in place.
- Bewegung darf die roten Linien des Projekts nicht überschreiten: Zuerst die Projektspezifikationen und Compliance-Beschränkungen prüfen. Keine Animationen mit fehlenden Feldwerten, keine Animationen, die unbelegte Informationen suggerieren.
Ablauf
Schritt 1: Bestimmen, welche Art von Bewegung gewünscht ist
„Bewegung“ kann vier verschiedene Dinge bedeuten, die jeweils unterschiedliche Lösungen erfordern.
| Typ | Mögliche Aussagen | Tatsächlich zu tun |
|---|---|---|
| Datenbewegung | Inhalte sollen sich automatisch aktualisieren, Echtzeit | Cron, API, Polling (hauptsächlich Backend-Arbeit, kombiniert mit Update-Signalen) |
| Feedback-Bewegung | Klicken fühlt sich nicht an, zu statisch | Druckgefühl, Zustandsänderungen, Update-Blinken |
| Kontinuierliche Bewegung | Fühlt sich wie Seitenwechsel an, sehr rudimentär, wie viele Objekte | Seitenübergänge, In-Place-Aufklapp-Elemente, gemeinsame Elemente, Gesten |
| Erzählerische Animation | Startseite soll beeindruckend sein, Scroll-Effekte, GSAP | Hero-Animation, Scroll-basiertes Storytelling, Markenmoment |
Liegt eindeutig eine Datenbewegung vor, erkläre dem Benutzer, dass dies kein Animationsproblem ist, und schlage eine Datenlösung vor. In allen anderen Fällen nicht zurückfragen, sondern direkt zu Schritt 2 übergehen und die Antwort durch tatsächliche Beobachtungen liefern.
Schritt 2: Den aktuellen Zustand analysieren
Wenn der Quellcode des Projekts verfügbar ist, führe Folgendes vom Stammverzeichnis dieses Skills aus:
python3 scripts/motion_audit.py <Projektverzeichnis>
Die Skriptausgabe sind Hinweise, keine Urteile. Gefundene Punkte einzeln überprüfen.
Wenn ein Browser geöffnet werden kann, durchlaufe den Hauptpfad auf 375px: Startseite, Innenseite, Tab-Wechsel, Klick auf ein Listenelement, Zurück zur vorherigen Seite. Notiere die tatsächlichen Eindrücke:
- Welche Aktionen laden die gesamte Seite neu, welche verändern sich in place?
- Ist die Seite eine Einheit oder eine Ansammlung unabhängiger Blöcke?
- Sieht der Benutzer, wenn Daten aktualisiert werden?
- Gibt es Verzögerungen beim Feedback? Wirken Animationen kontraproduktiv (z.B. Zahlen, die bei jedem Seitenaufruf hüpfen)?
Falls keine Website vorhanden (neue Website) oder das Projekt nur ein Gerüst ohne tatsächliche Seiten ist: Lese die Planungsdokumente, bestimme den Seitentyp, springe zu Schritt 3 und weise darauf hin, dass eine Diagnose des aktuellen Bildschirms nicht möglich ist.
Wenn weder die Website noch der Code verfügbar ist: Arbeite mit den vom Benutzer bereitgestellten Informationen weiter. Markiere alle „Problemstellen“ als Vermutungen und liste fehlende Daten unter „Nicht verifiziert“ auf. Keine Beobachtungen erfinden.
Schritt 3: Basierend auf dem Seitentyp ausrichten
| Seitentyp | Schwerpunkt | Vermeiden |
|---|---|---|
| Daten- und Tool-Sites (Scores, Abfragen, Dashboards) | Kontinuierliche Bewegung, Update-Signale, Dichte | Scroll-basiertes Einblenden, Animationen, die Daten verdecken |
| Inhalts- und Artikel-Sites | Leichtes Feedback, ungestörtes Lesen | Alles, was das Lesen oder die Werbeanzeigen stört |
| Marken- und Marketingseiten | Ein sorgfältig gestalteter Erzählmoment | Überall Bewegung |
| App-ähnliche Dienste | Gesten, In-Place-Operationen, Zustandskontinuität | Nur die Haut ändern, nicht die Interaktion |
| Eingeloggte Backends und interne Tools | Feedback, Zustandsänderungen, weniger Seitenwechsel | Animationen, die wiederholte Aktionen verlangsamen |
Schritt 4: 2 bis 3 Versionen planen
Lies references/recipes.md für Bewegungsrezepte und references/pitfalls.md zur Risikobewertung.
Navigations-Gate prüfen, das bestimmt, welche Navigationsansätze in den Vorschlag aufgenommen werden können:
| Zustand der Site | Navigationsansatz |
|---|---|
| Enthält oder wird Display-Werbung enthalten (z.B. AdSense) | Standardmäßig Cross-Document @view-transition verwenden. Echten Seitenwechsel beibehalten, Werbe- und Analyse-Verhalten unverändert |
| Automatische Werbung, Anchor-Werbung, Interstitial-Werbung aktiviert oder Werbeverhalten nach Seitenwechsel nicht verifizierbar | Single-Page-Navigation (SPA) nicht empfehlen; falls doch, muss es als „muss getestet werden“ markiert werden und einen Fallback bieten |
| Keine Werbung oder Werbe- und Analyse-Verhalten bereits verifiziert | Single-Page-Navigation oder Framework-Routing möglich; dennoch Analyse und Login-Status nach Seitenwechsel verifizieren |
Wenn eine bestehende Site SPA-Navigation verwendet und Werbung vorbereitet, dies unter „Problem“ aufführen, nicht als gelöst behandeln.
Die Versionen müssen sich in ihrem Interaktionsumfang deutlich unterscheiden, nicht nur in der Farbe. Die Stufen bauen auf dem aktuellen Zustand der Site auf. Bereits implementierte Funktionen nicht wiederholen. Standard-Stufen:
- A Leichtes Feedback: Keine Änderung der Navigationsarchitektur, nur Feedback und Update-Signale hinzufügen. Geringstes Risiko, am selben Tag umsetzbar.
- B Kontinuierlich: A plus Seitenübergänge, gemeinsame Elemente, In-Place-Aufklapp-Elemente. Navigationsansatz gemäß Navigations-Gate. In der Regel die empfohlene Version.
- C Vollständiges App-Gefühl: B plus Wischgesten, In-Place-Datenwechsel, Echtzeit-Benachrichtigungen oder bei Markenseiten ein Erzählmoment. Stärkstes Gefühl, höchste Kosten und Risiko.
Versionen müssen den Seitentyp-Filter aus Schritt 3 bestehen: Eine Inhaltsseite hört normalerweise bei A oder einem leichten B auf. Gib nur zwei Versionen, wenn zwei ausreichen. Wenn A bereits alle Anforderungen erfüllt, sag das auch. Die Kosten für die Animationsarbeit sollten zum Einkommen der Site passen.
Schritt 5: Klickbaren Prototyp erstellen
Erstelle den Prototyp gemäß references/prototype.md. Verwende echte Daten und das vorhandene Erscheinungsbild. Der Prototyp sollte über eine Datei verfügbar sein, in der zwischen den Versionen umgeschaltet werden kann. Teste zuerst in der mobilen Breite. Verwende assets/prototype-template.html als Startvorlage.
Schritt 6: Vorschlag
Berichte gemäß dem unten stehenden „Ausgabeformat“ und bitte den Benutzer, eine Version auszuwählen. Wenn ein Tool zur Auswahl vorhanden ist, verwende es; ansonsten nummeriere die Optionen und setze die empfohlene Version an erste Stelle. Die Regel „Nicht zurückfragen“ aus Schritt 1 gilt nur für die Diagnosephase. Hier muss gewartet werden, bis der Benutzer eine Auswahl getroffen hat.
Schritt 7: Implementierung und Abnahme
Beginne erst nach der Auswahl durch den Benutzer. Implementiere und führe die Abnahme gemäß der Reihenfolge in references/acceptance.md durch. Gib es mit der Übergabevorlage aus dieser Datei an einen anderen Agenten weiter.
Ausgabeformat
Das Layout des Vorschlags ist festgelegt, kurz und konkret:
## Bewegungsbewertung: <Seitenname>
**Problem**
<2 bis 4 Punkte, jeweils beobachtete Phänomene mit Seitenposition. Keine vagen Aussagen wie „fehlende Interaktion“.>
**Versionsvergleich**
| | A Leichtes Feedback | B Kontinuierlich | C Vollst. App-Gefühl |
|---|---|---|---|
| Benutzer fühlt | | | |
| Hauptänderungen | | | |
| Arbeitsaufwand | Dateien und Zeit | | |
| SEO & CWV-Risiko | Niedrig/Mittel/Hoch, mit Grund | | |
| Auswirkung auf Werbung/Analyse | Navigationsansatz & Voraussetzung | | |
| Wartungskosten | | | |
**Empfehlung**: <Welche Version, ein Grund; falls Voraussetzungen, diese nennen>
**Prototyp**: <Link oder Pfad, sowie 3 bis 5 zu testende Aktionen>
**Layout-Änderungen**: <Dinge, die der Benutzer genehmigen muss; falls nicht, „Keine“>
**Nicht vorgeschlagen**: <Vom Benutzer gewünscht, aber aus bestimmten Gründen nicht umgesetzt; weglassen, wenn nicht zutreffend>
**Nicht betroffen**: <Layout, Farben, URLs, SEO-Regeln usw.>
**Nicht verifiziert**: <Nicht getestete Aspekte, z.B. tatsächliches Werbeverhalten, Gefühl auf echtem Gerät>
Bei nur zwei Versionen die Tabelle um die nicht benötigte Spalte reduzieren. Arbeitsaufwand mit konkreten Zahlen angeben, z.B. „Ändert 4 bis 5 Dateien“. Risiko mit Begründung angeben, nicht nur „niedrig“. Zahlen als gemessen oder geschätzt kennzeichnen. Wenn eine Benutzeranforderung blockiert ist, genau erklären, wo und unter welchen Bedingungen sie wieder aufgegriffen werden kann, und eine Alternative anbieten. Die empfohlene Version sollte sich nach dem Navigations-Gate und den Leistungsbedingungen richten, nicht unbedingt B sein.
Referenzdateien
| Datei | Wann lesen |
|---|---|
| references/recipes.md | Schritt 4, Bewegungseffekte und Parameter auswählen |
| references/pitfalls.md | Schritt 4 Risikobewertung, Schritt 7 Implementierung |
| references/prototype.md | Schritt 5 |
| references/acceptance.md | Schritt 7, inkl. Übergabevorlage |
| assets/prototype-template.html | Startvorlage für Prototyp |