Wie aus einem Querschnitt-Drift ein UI-Pattern wurde
Eine Wand mit 120 Millimeter Stärke, eine ausgewählte Holzart mit 100 Millimeter Querschnitt. Niemand sagte was. Aus der Iteration wurde eine Konvention für vier Arten von Hinweisen, plus einer Tailwind-v4-Cascade-Erkenntnis, die wir uns merken konnten.
Die Wand war 120 mm stark. Die Holzart, die der Tester im Material-Panel ausgewählt hatte, kam in 100, 140 und 160 mm. Der Editor zeigte eine 120-mm-Wand mit 100-mm-Holz. Niemand sagte was. Bis zur Stückliste, in der dann eine Wand stand, die so nicht baubar ist.
Erste Reaktion: Inline-Warnung
Der erste Reflex war ein roter Rand am Querschnitt-Feld im Property-Panel plus ein Warnungs-Icon. Funktioniert, sieht aber zwei Probleme nicht. Erstens: das Property-Panel ist rechts, der Tester schaut auf die Komponente in der Mitte. Wer am Querschnitt vorbeiarbeitet, sieht das Property-Panel gar nicht. Zweitens: ein roter Rand sagt "etwas ist falsch", aber nicht "die Stärke 120 mm passt zu keinem Standard-Querschnitt der ausgewählten Holzart, hier sind die nächsten passenden Werte".
Zweite Iteration: Toast über dem Canvas
Die Lösung wurde ein nicht-blockierender Toast, der über dem Canvas oben schwebt, sobald genau eine Komponente selektiert ist und ihre Maße vom Lumber-Querschnitt abweichen. Drei konkrete Diffs in Millimeter ("Länge 2400 mm passt, Breite 120 mm sollte 100 oder 140 sein, Tiefe passt") plus ein Button "Auf Querschnitt anpassen", der die Komponente auf den nächsten Standard zwingt. Cmd-Z funktioniert weiter, das Anpassen ist ein normaler Store-Update.
Toast verschwindet von selbst, sobald die Auswahl sich ändert oder die Diskrepanz weg ist. Kein Schließen-Knopf, kein Nag.
Was daraus wurde: vier Notice-Patterns
Beim Bauen des Toasts fiel auf, dass Struqo bisher drei verschiedene Visual Languages für Hinweise hatte. Inline-Fehlermeldung im Form-Feld. Banner für Email-Verifikation. Tooltip für Tool-Erklärungen. Jetzt ein Toast über dem Canvas. Vier Sprachen, kein Wörterbuch.
Aus der Iteration entstand eine Konvention. Vier Pattern, jedes mit klarer Zuständigkeit:
- Inline für feldgebundene Validierung (Form-Field zeigt selbst den Fehler)
- Banner für persistente Account-Zustände (Email-Verifikation, Plan-Wechsel-Hinweise)
- Toast für canvas-bezogene Hinweise mit Action (Querschnitt, Snap-Konflikt, Multi-Select-Tipp)
- Tooltip für Discovery (was tut dieses Icon)
Plus eine Voice-Regel: das Label trägt die Farbe, die Box bleibt neutral. Roter Toast mit weißem Text fühlt sich wie ein 404 an. Toast mit roter Headline und neutralem Body fühlt sich wie ein präziser Hinweis an.
Punchline: Tailwind v4 hat eigene Pläne
Die Voice-Regel wurde mit text-error, text-success, text-warning an <span class="eyebrow"> gehängt. Funktionierte überall, außer auf der Eyebrow. Der Eyebrow zog die Farbe nicht. Eine halbe Stunde Diagnose später war klar: .eyebrow lag in globals.css außerhalb eines @layer. Tailwind v4 vergleicht erst Layer, dann Specificity. Eine unbelayerte Custom-Klasse schlägt jede Tailwind-Utility, egal wie spezifisch.
Fix: ein Zweizeiler. .eyebrow in @layer components wickeln. Funktioniert.
Die Tooling-Erkenntnis steht jetzt im Memory als Pattern für das nächste Mal, an dem eine Custom-Klasse stur bleibt.