UI-Polish – Benutzeroberfläche verfeinern

UI-Polish

Ein Bildschirm kann gut organisiert sein und sich dennoch unfertig anfühlen: zwei Spalten mit Feldern, die 17 px außer Linie stehen, 88 px große Boxen auf einem 390 px Telefon, eine Einheit, die jedem Feld nachhängt, ein Link, den man mit dem Daumen nicht treffen kann. Menschen spüren das sofort; Modelle, die Screenshots begutachten, sehen es selten. Diese Fähigkeit misst zuerst, urteilt dann und nennt einen Fehler erst behoben, wenn die Messung das sagt.

Eingaben

Fragen Sie nur, was fehlt.

1. Ziel. Eine URL, eine HTML-Datei oder die Komponente in einem Repository plus eine URL, unter der sie rendert. Sie brauchen eine Möglichkeit zum Rendern; wenn Sie nichts rendern können, sagen Sie das und fallen auf die Rubrik allein zurück, wobei Sie jede gemessene Prüfung als „nicht gemessen“ markieren.
2. Bereich (optional). Ein CSS-Selektor für den Teil der Seite, der poliert werden soll, z. B. das Formular oder main. Standard: main, sonst body.
3. Referenz (optional). Ein Bildschirm, den der Benutzer für besser hält (eine URL, Datei oder ein Screenshot). Messen Sie ihn ebenfalls und verwenden Sie ihn als Richtung für das Erscheinungsbild; kopieren Sie niemals dessen Marke, Inhalt oder Behauptungen.

Arbeitsablauf

1. Den aktuellen Bildschirm messen

Führen Sie das gebündelte Skript aus (benötigt Node und Playwright mit Chromium; installieren mit npm i -D playwright && npx playwright install chromium, falls das Projekt es nicht hat):

node <skill-dir>/scripts/measure.cjs <datei-oder-url> --out ui-polish/vorher [--scope "<selektor>"] [--primary "<selektor>"] [--hide "<selektor>,…"] [--profile formular|inhalt]

• Es rendert auf Telefon (390×844) und Desktop (1366×900) (Exit 1, solange Fehlerbefunde vorhanden sind, 2 bei Anwendungsfehlern, 3 wenn der Lauf selbst fehlschlägt), schreibt measure.json in --out (relativ zum aktuellen Verzeichnis aufgelöst) mit zwei Screenshots pro Viewport, <viewport>.png (der erste Bildschirm) und <viewport>-bereich.png (der gesamte Bereich, einschließlich allem unter dem Falz), und gibt jeden Befund mit einem Selektor aus. Elemente, die eine gemeinsame Ursache haben, sind ein Befund mit einer Anzahl und Beispielselektoren, und ein Befund, der auf Telefon und Desktop identisch ist, wird einmal ausgegeben, mit beiden in viewports (verwenden Sie viewports, nicht viewport, wenn Sie einen zusammengeführten Befund nach Viewport filtern).
• Skripte sind standardmäßig deaktiviert, sodass das statische Layout gemessen wird; fügen Sie --js für Seiten hinzu, die nur mit JavaScript rendern. --offline blockiert jede Netzwerkanfrage außer der Zielseite (hermetisch); --assets-only lässt zusätzlich entfernte Schriftarten, Stylesheets und Bilder laden, für gespeicherte Kopien, die ihre Schriftarten benötigen, und kontaktiert diese Hosts.
• --hide setzt display: none auf Overlays wie ein Cookie-Banner oder einen Chat-Launcher vor dem Messen und Aufnehmen, damit sie weder die Screenshots verdecken noch Befunde hinzufügen. Ein --hide-Selektor, der nichts findet, gibt eine Warnung aus.
• --profile inhalt ist für Artikel und andere lange Textseiten: Es überspringt die Prüfungen, die für Formularschritte entwickelt wurden (typ-skalierung, aktions-abstand, aktion-unter-dem-falz, tote-flaeche). Der Standard ist formular.
• Mehrere Ziele in einem Lauf (measure.cjs <seite1> <seite2> … --out verzeichnis) gehen jeweils in verzeichnis/<slug>/, und verzeichnis/zusammenfassung.json führt einen Befund, der sich über Seiten wiederholt, in einer Zeile mit Auflistung der Seiten zusammen; beheben Sie eine gemeinsam genutzte Komponente einmal. Vergleichen Sie Seite für Seite (--compare vorher/<slug>/measure.json nachher/<slug>/measure.json).
• Prüfungen und Schwellwerte sowie die übliche Korrektur für jede sind in reference/pruefungen.md. Fehler lassen den Lauf fehlschlagen; Warnungen benötigen eine Korrektur oder einen angegebenen Grund.
• Geben Sie einen Grund einmal an, nicht bei jedem Lauf: Eine ui-polish.config.json im aktuellen Verzeichnis (oder --config <datei>) listet akzeptierte Entscheidungen auf, z. B. { "ignore": [{ "check": "text-groesse", "selector": ".eyebrow", "reason": "Marken-Kicker-Labels" }] }. Übereinstimmende Befunde werden zu accepted mit dem Grund verschoben, in einem eigenen Abschnitt ausgegeben und beeinflussen den Exit-Code nicht. Notieren Sie nur eine Entscheidung, die der Eigentümer getroffen hat; fügen Sie niemals eine hinzu, um die Zahlen bestehen zu lassen.

Wenn eine Referenz angegeben wurde, messen Sie sie auf die gleiche Weise in ui-polish/referenz.

2. Betrachten

Öffnen Sie die Screenshots (die -bereich.png zeigen den gesamten Bereich) und gehen Sie alle zehn Punkte von reference/rubrik.md durch. Schreiben Sie eine Urteilstabelle mit einer Zeile pro Punkt (und einer Zeile pro Unterprüfung von Punkt 10): bestanden, nicht bestanden oder n.z., das lokalisierte Problem und die Korrektur. Beurteilen Sie nur, was auf dem Bildschirm zu sehen ist. Die Messungen sind Beweise für die Rubrik, kein Ersatz dafür: Ein Bildschirm mit null gemessenen Befunden kann dennoch bei Hierarchie, Labels und Einheiten, Gruppierung oder Vertrauen durchfallen, und das sind normalerweise die Fehler, die Menschen zuerst bemerken.

3. Die Korrekturen planen

Listen Sie jeden gemessenen Befund und jeden nicht bestandenen Rubrikpunkt mit seiner Korrektur auf, gruppiert nach dem Element, das sie betreffen. Bevorzugen Sie strukturelle Korrekturen, die mehrere Befunde auf einmal beseitigen (z. B. Labels über Feldern in einem zweispaltigen Raster behebt Ausrichtung, gleiche Breiten, Feldausfüllung, Label-Platzierung und barrierefreie Namen gemeinsam) gegenüber dem Flicken jedes einzelnen Befunds. Ordnen Sie nach Auswirkung auf die Person, die den Bildschirm nutzt.

4. Die Korrekturen in der Quelle anwenden

Bearbeiten Sie die echte Quelle: die Komponente und ihre Styles in einem Repository oder die HTML-Datei. Regeln:

• Behalten Sie Aufgabe und Inhalt. Gleiche Fragen, gleiche Eingaben und Einheiten, gleiche Aktionen, gleiche Marke. Entfernen Sie keine Funktionen, um eine Prüfung zu bestehen.
• Erfinden Sie nichts. Fügen Sie keine Fakten hinzu, die der Bildschirm nicht in Worten ausgedrückt hat: Schrittzahlen, Zeiten, Preise, klinische, rechtliche oder datenschutzbezogene Behauptungen. Ein Wert, den Sie aus dem Code errechnet haben (ein aria-valuenow einer Fortschrittsanzeige, eine CSS-Breite, ein Routenname) ist immer noch nicht ausgedrückt; setzen Sie auch diesen in Klammern. Wenn das Design solchen Text benötigt, verwenden Sie einen geklammerten Platzhalter (Frage [n] von [N], [~3] Minuten, [Warum wir fragen: …]) und listen Sie ihn zum Ausfüllen durch den Eigentümer auf.
• Verwenden Sie das vorhandene System. Nutzen Sie die Tokens, Komponenten und Abstandsskala des Projekts wieder; fügen Sie neue Werte nur hinzu, wenn keiner passt.
• Halten Sie es funktionsfähig. Jedes Steuerelement muss weiterhin das tun, was es tat (und, wo es defekt war, funktionieren). Behalten Sie die Tastaturfokussierung sichtbar.

5. Erneut messen, bis es bestanden ist

node <skill-dir>/scripts/measure.cjs <datei-oder-url> --out ui-polish/nachher [gleiche optionen]
node <skill-dir>/scripts/measure.cjs --compare ui-polish/vorher/measure.json ui-polish/nachher/measure.json

Der Vergleichsschritt listet auch jedes neue Textstück zur Überprüfung durch den Eigentümer auf und schlägt mit erfundene-zahl fehl, wenn neuer Text eine Zahl außerhalb von [Klammern] enthält (z. B. „Schritt 2 von [5]“: Die 2 wurde nie ausgedrückt).

Wiederholen Sie die Schritte 4–5, bis keine Fehler mehr auftreten, jede verbleibende Warnung behoben oder begründet ist und jeder nicht bestandene Rubrikpunkt behoben oder begründet ist, maximal drei Runden. Gehen Sie die Rubrik jede Runde anhand der neuen Screenshots erneut durch. Keine Fehler bedeutet nicht fertig: Warnungen wie 36 px große Tippziele oder nachgestellte Labels sind genau die Details, die diese Fähigkeit zu Ende zu bringen existiert. Öffnen Sie die neuen Screenshots jede Runde: Eine Prüfung kann bestanden sein, während der Bildschirm schlechter aussieht, und das zählt als Regression.

6. Bericht

• Vorher- und Nachher-Screenshots auf Telefon und Desktop.
• Die Vergleichsausgabe: behoben, verbleibend (mit Grund), neu und akzeptiert (mit Grund aus der Konfiguration).
• Die Rubrik-Urteilstabelle vorher und nachher, mit Begründung für alles, was nicht bestanden bleibt.
• Jeder geklammerte Platzhalter, den der Eigentümer ausfüllen muss.
• Alles, was eher eine Produktentscheidung als eine Politur erfordert (diese an design-review oder den Eigentümer übergeben).

Fallstricke

• Screenshots verbergen Geometrie. Ein Spaltenversatz von 17 px oder ein 88 px-Feld auf einem 390 px-Bildschirm ist für einen Menschen offensichtlich und in einem verkleinerten Screenshot unsichtbar. Vertrauen Sie den Zahlen für die Geometrie und Ihren Augen für Ausgewogenheit und Hierarchie.
• Ein nachgestelltes Einheitenwort ist die übliche Ursache für nicht ausgerichtete Spalten. „Fuß“ und „Stein“ haben unterschiedliche Breiten, sodass alles dahinter verschoben wird. Setzen Sie Labels über die Felder.
• Kleine Änderungen an großen Dateien bleiben klein. Wenn die Quelle eine große generierte Datei ist, bearbeiten Sie das Markup und die Styles des Formulars als Block, anstatt Attribut für Attribut zu flicken, sonst wird sich das Layout nie ändern.
• Aufhören, wenn die Zahlen bestehen, ist der klassische Fehler. Geometrie ist nur die Hälfte der Politur; die andere Hälfte ist die Rubrik (eine echte Überschrift, ein Moduswechsel statt eines Links pro Feld, ein Grund für sensible Fragen, Orientierung).
• Ein Token, viele Befunde. Ein Kleintext- oder Tippziel-Befund, der sich auf jeder Seite wiederholt, stammt normalerweise von einem Designsystem-Token oder einer Komponente. Beheben Sie es dort oder notieren Sie die Entscheidung des Eigentümers in ui-polish.config.json, anstatt es Seite für Seite zu triagieren.
• Bestandene Prüfungen sind nicht das Ziel. Ein fokussierter Bildschirm mit einer klaren Überschrift, gruppierten Feldern und einer nahen primären Aktion ist das Ziel. Verwenden Sie die Prüfungen, um zu beweisen, dass Sie dort angekommen sind.

---

Erstellt von aictrl.dev. Diese Fähigkeit lehrt den Arbeitsablauf; aictrl betreibt ihn – verankert in Ihrem Backlog, Ihren Teamstandards und Ihrem Codebasis-Wissensgraphen. Sehen Sie, wie →