jamesonedge/interactive-mockup

Interaktiver Mockup

Echte Alternativen erkunden, den Benutzer wählen lassen, und die Wahl dann im Browser funktionsfähig machen – ohne sie stillschweigend neu zu gestalten.

Wann verwenden

• "Mock up", "Prototyp", "Zeig mir ein paar Richtungen", "Mach das klickbar".
• Ein Design-Review hat eine Spezifikation ergeben und der Benutzer möchte sie fühlen.
• Neuland-Bildschirme, bei denen die Informationsarchitektur noch offen ist.

Wann nicht verwenden

• Nur Kritik ohne Bau – verwende einen Design-Review-Workflow.
• Produktionsimplementierung im echten Framework der App.
• Eine einzelne Padding-, Farb- oder Textänderung.
• Alles, was echte Benutzer- oder Produktionsdaten benötigt. Prototypen verwenden ausschließlich synthetische Daten.

Eingaben

• Die Aufgabe und Einschränkungen (Plattform, Viewport, ggf. Tokens).
• Repräsentative synthetische Daten. Kennzeichne sie in der Benutzeroberfläche als synthetisch. Füge niemals Produktions- oder persönliche Daten ein.
• Optional: ein Design-Review oder eine Spezifikation, die zu befolgen ist.
• Optional: eine Richtung, die der Benutzer bereits gewählt hat. Falls ja, überspringe die Divergenz und gehe direkt zu Schritt 3.

Workflow

1. Divergieren: zwei oder drei Richtungs-Briefings

Schreibe ein Briefing pro Richtung unter Verwendung von templates/direction-brief.md. Alle Richtungen teilen sich die gleichen Einschränkungen, Daten und Aufgaben. Sie müssen sich in der Informationsarchitektur oder im Interaktionsmodell unterscheiden – zum Beispiel Liste-zuerst vs. Fokus-Modus vs. Board – nicht nur im Farbschema.

• Wenn deine Laufzeitumgebung wirklich unabhängige Worker (Sub-Agenten oder separate Sitzungen) unterstützt, generiere die Richtungen unabhängig und sage dies.
• Andernfalls generiere sie seriell und kennzeichne sie: "Richtungen seriell von einem Agenten erstellt."

Baue jede als statische, eigenständige HTML-Datei aus templates/direction.html. Statisch bedeutet repräsentatives Layout und Zustände; Interaktionen sind noch nicht erforderlich.

2. Vergleichen und den Benutzer wählen lassen

Erstelle eine Vergleichsseite aus templates/comparison.html, die jede Richtung verlinkt und die sinnvollen Kompromisse darlegt (was jede optimiert, was sie opfert, für wen sie geeignet ist). Halte an und bitte den Benutzer zu wählen. Baue die interaktive Version nicht bevor er wählt, es sei denn, er delegiert die Wahl explizit.

3. Strenges Aufpfropfen: den interaktiven Prototypen bauen

Befolge references/graft-rules.md. Kurzgefasst:

1. Lies den HTML-Quelltext der gewählten Richtung.
2. Behalte ihre Markup-Struktur, CSS und visuellen Entscheidungen bei.
3. Versehe neue Klassen oder IDs, die kollidieren könnten, mit einem Namensraum.
4. Füge funktionierende Interaktionen mit vanilla JavaScript hinzu.
5. Halte jede Änderung in einem Protokoll fest, unter Verwendung von templates/change-ledger.md. Alles, was keine reine Ergänzung ist, benötigt einen Grund.

Keine stillschweigende Neugestaltung. Wenn die gewählte Richtung einen Fehler hat, protokolliere ihn im Protokoll und frage vor einer Änderung.

4. Qualitätskontrolle

Überprüfe den Prototypen gegen references/prototype-quality.md: offline, viewport meta, responsiv, Tastatur, sichtbarer Fokus, reduzierte Bewegung, leer-/Lade-/Fehlerzustände, keine toten primären Aktionen, synthetische Daten gekennzeichnet.

Standardeinstellungen

• Eine eigenständige .html-Datei pro Artefakt: inline CSS und JS, kein CDN, keine Webfonts, keine externen Bilder (verwende inline SVG oder CSS).
• System-Schriftfamilie.
• Funktioniert von file:// ohne Server.
• Niemals automatisch veröffentlichen, bereitstellen oder hochladen.

Ausgaben

<ausgabe-verzeichnis>/
├── richtungen/
│   ├── a-<name>.html
│   ├── b-<name>.html
│   └── c-<name>.html   (optional)
├── vergleich.html
├── prototype.html
└── aenderungsprotokoll.md

Ehrlichkeit

Ein Prototyp demonstriert Interaktion und Layout. Er ist kein Beleg für native Machbarkeit, Leistung, Barrierefreiheitskonformität oder Produktionsreife. Sage dies bei der Übergabe.

Lizenzhinweis

Der folgende Hinweis begleitet diesen eigenständigen Skill und seine unterstützenden Dateien.

MIT Lizenz

Copyright (c) 2026 jamesonedge

Hiermit wird unentgeltlich, jeder Person, die eine Kopie
 dieser Software und der zugehörigen Dokumentationsdateien (der "Software") erhält, die Erlaubnis erteilt, sie uneingeschränkt zu nutzen, inklusive und ohne Ausnahme mit dem Recht, sie zu verwenden, zu kopieren, zu modifizieren, zusammenzuführen, zu veröffentlichen, zu verteilen, unterzulizenzieren und/oder zu verkaufen, und Personen, denen diese Software überlassen wird, diese Rechte zu verschaffen, unter den folgenden Bedingungen:

Der obige Urheberrechtshinweis und dieser Genehmigungshinweis müssen in allen Kopien oder wesentlichen Teilen der Software enthalten sein.

DIE SOFTWARE WIRD OHNE JEDE AUSDRÜCKLICHE ODER IMPLIZIERTE GARANTIE BEREITGESTELLT, EINSCHLIESSLICH DER GARANTIE ZUR BENUTZUNG FÜR DEN VORGESEHENEN ODER EINEM BESTIMMTEN ZWECK SOWIE JEGLICHER RECHTSVERLETZUNG, JEDOCH NICHT DARAUF BESCHRÄNKT. IN KEINEM FALL SIND DIE AUTOREN ODER COPYRIGHTINHABER FÜR JEGLICHE ANSPRÜCHE, SCHÄDEN ODER ANDERE VERPFLICHTUNGEN HAFTBAR, OB IN EINER VERTRAGS- ODER DELIKTSHANDLUNG ODER ANDERWEITIG, DIE AUS ODER IM ZUSAMMENHANG MIT DER SOFTWARE ODER DER NUTZUNG ODER ANDEREN GESCHÄFTEN MIT DER SOFTWARE ENTSTEHEN.