Polissage d'UI

Que fait Polissage d'UI ?

Un écran peut être bien organisé et sembler néanmoins inachevé : deux colonnes de champs décalées de 17 px, des boîtes de 88 px sur un téléphone de 390 px, un mot d'unité qui traîne après chaque champ, un lien impossible à atteindre avec le pouce. Les utilisateurs le ressentent instantanément ; les modèles qui examinent des captures d'écran le voient rarement. Cette compétence mesure d'abord, juge ensuite, et ne déclare un défaut corrigé que lorsque la mesure le confirme.

Entrées

Ne demandez que ce qui manque.

1. Cible. Une URL, ou un fichier HTML, ou le composant dans un dépôt plus une URL où il s'affiche. Vous avez besoin d'un moyen de le rendre ; si vous ne pouvez rien rendre, dites-le et utilisez uniquement la grille, en marquant chaque vérification mesurée comme "non mesurée".
2. Périmètre (optionnel). Un sélecteur CSS pour la partie de la page à polir, par exemple le formulaire ou main. Valeur par défaut : main, sinon body.
3. Référence (optionnel). Un écran que l'utilisateur considère meilleur (une URL, un fichier ou une capture d'écran). Mesurez-le aussi et utilisez-le comme direction pour l'aspect ; ne copiez jamais sa marque, son contenu ou ses affirmations.

Workflow

1. Mesurer l'écran actuel

Exécutez le script fourni (nécessite Node et Playwright avec Chromium ; installez avec npm i -D playwright && npx playwright install chromium si le projet ne les a pas) :

node <skill-dir>/scripts/measure.cjs <file-or-url> --out ui-polish/before [--scope "<selector>"] [--primary "<selector>"] [--hide "<selector>,…"] [--profile form|content]

• Il effectue le rendu en mode téléphone (390×844) et bureau (1366×900) (sortie 1 en cas de constats d'erreur, 2 pour les erreurs d'utilisation, 3 en cas d'échec d'exécution), écrit measure.json dans --out (résolu par rapport au répertoire courant) avec deux captures par viewport, <viewport>.png (le premier écran) et <viewport>-scope.png (l'ensemble du périmètre, y compris ce qui est sous la ligne de flottaison), et imprime chaque constat avec un sélecteur. Les éléments partageant une cause forment un seul constat avec un nombre et des sélecteurs d'exemple, et un constat identique sur téléphone et bureau est imprimé une fois, avec les deux dans viewports (utilisez viewports, pas viewport, lors du filtrage d'un constat fusionné par viewport).
• Les scripts sont désactivés par défaut pour que la mise en page statique soit mesurée ; ajoutez --js pour les pages qui ne s'affichent qu'avec JavaScript. --offline bloque toute requête réseau sauf la page cible (hermétique) ; --assets-only autorise également le chargement des polices, feuilles de style et images distantes, pour les copies sauvegardées qui ont besoin de leurs polices, et contacte ces hôtes.
• --hide définit display: none sur les superpositions telles qu'une bannière de cookies ou un lanceur de chat avant de mesurer et capturer, afin qu'elles ne couvrent ni les captures ni n'ajoutent de constats. Un sélecteur --hide qui ne correspond à rien imprime un avertissement.
• --profile content est destiné aux articles et autres pages longues : il ignore les vérifications conçues pour les étapes de formulaires (type-scale, action-distance, action-below-fold, dead-space). La valeur par défaut est form.
• Plusieurs cibles en une seule exécution (measure.cjs <page1> <page2> … --out dir) vont chacune dans dir/<slug>/, et dir/summary.json fusionne un constat qui se répète sur plusieurs pages en une seule ligne listant les pages ; corrigez un composant partagé une fois. Comparez page par page (--compare before/<slug>/measure.json after/<slug>/measure.json).
• Les vérifications et seuils, ainsi que la correction habituelle pour chacun, se trouvent dans reference/checks.md. Les erreurs font échouer l'exécution ; les avertissements nécessitent une correction ou une raison déclarée.
• Indiquez une raison une fois, pas à chaque exécution : un fichier ui-polish.config.json dans le répertoire courant (ou --config <file>) liste les décisions acceptées, par exemple { "ignore": [{ "check": "text-size", "selector": ".eyebrow", "reason": "étiquettes de marque de kicker" }] }. Les constats correspondants passent dans accepted avec la raison, sont imprimés dans leur propre section et n'affectent pas le code de sortie. N'enregistrez qu'une décision prise par le propriétaire ; n'en ajoutez jamais une pour faire passer les chiffres.

Si une référence a été donnée, mesurez-la de la même manière dans ui-polish/reference.

2. Examiner

Ouvrez les captures d'écran (les -scope.png montrent l'ensemble du périmètre) et parcourez les dix points de reference/rubric.md. Écrivez un tableau de verdict avec une ligne par point (et une ligne par sous-vérification du point 10) : réussi, échoué ou n/a, le problème localisé et la correction. Ne jugez que ce qui est à l'écran. Les mesures sont une preuve pour la grille, pas un remplacement : un écran sans constat mesuré peut encore échouer sur la hiérarchie, les libellés et unités, le regroupement ou la confiance, et ce sont généralement ces échecs que les utilisateurs remarquent en premier.

3. Planifier les corrections

Listez chaque constat mesuré et chaque point de grille échoué avec sa correction, regroupés par élément concerné. Préférez les corrections structurelles qui suppriment plusieurs constats à la fois (par exemple, des libellés au-dessus des champs dans une grille à deux colonnes corrige l'alignement, les largeurs égales, le remplissage des champs, le placement des libellés et les noms accessibles en une seule fois) plutôt que de corriger chaque constat individuellement. Ordonnez par impact sur la personne qui utilise l'écran.

4. Appliquer les corrections à la source

Modifiez la source réelle : le composant et ses styles dans un dépôt, ou le fichier HTML. Règles :

• Conservez le métier et le contenu. Mêmes questions, mêmes entrées et unités, mêmes actions, même marque. Ne supprimez pas de fonctionnalités pour faire passer une vérification.
• N'inventez rien. N'ajoutez pas de faits que l'écran n'a pas énoncés en mots : nombres d'étapes, délais, prix, affirmations cliniques, juridiques ou de confidentialité. Une valeur que vous avez déduite du code (un aria-valuenow de barre de progression, une largeur CSS, un nom de route) n'est toujours pas énoncée ; mettez-la aussi entre crochets. Si le design nécessite un tel texte, utilisez un espace réservé entre crochets (Question [n] sur [N], [~3] minutes, [Pourquoi nous demandons : …]) et listez-le pour que le propriétaire le remplisse.
• Utilisez le système existant. Réutilisez les tokens, composants et échelle d'espacement du projet ; n'ajoutez de nouvelles valeurs que lorsque aucune ne convient.
• Gardez-le fonctionnel. Chaque contrôle doit toujours faire ce qu'il faisait (et, là où il était cassé, fonctionner). Gardez le focus clavier visible.

5. Re-mesurer jusqu'à validation

node <skill-dir>/scripts/measure.cjs <file-or-url> --out ui-polish/after [same options]
node <skill-dir>/scripts/measure.cjs --compare ui-polish/before/measure.json ui-polish/after/measure.json

L'étape de comparaison liste également chaque nouveau texte pour que le propriétaire le révise, et échoue avec invented-number lorsque le nouveau texte contient un nombre en dehors des [crochets] (par exemple "Étape 2 sur [5]" : le 2 n'a jamais été énoncé).

Répétez les étapes 4 à 5 jusqu'à ce qu'il n'y ait aucune erreur, que chaque avertissement restant soit corrigé ou ait une raison déclarée, et que chaque point de grille échoué soit corrigé ou ait une raison déclarée, au maximum trois tours. Reparcourez la grille sur les nouvelles captures à chaque tour. Zéro erreur ne signifie pas terminé : les avertissements tels que des cibles tactiles de 36 px ou des libellés qui traînent sont exactement les détails que cette compétence existe pour finaliser. Ouvrez les nouvelles captures à chaque tour : une vérification peut réussir alors que l'écran semble moins bien, et cela compte comme une régression.

6. Rapport

• Captures avant et après en mode téléphone et bureau.
• Le résultat de la comparaison : corrigé, restant (avec la raison), nouveau et accepté (avec la raison du fichier de configuration).
• Le tableau de verdict de la grille avant et après, avec pourquoi pour tout ce qui reste en échec.
• Chaque espace réservé entre crochets que le propriétaire doit remplir.
• Tout ce qui nécessite une décision produit plutôt qu'un polissage (confiez-le à design-review ou au propriétaire).

Pièges

• Les captures d'écran cachent la géométrie. Un décalage de colonne de 17 px ou un champ de 88 px sur un écran de 390 px est évident pour une personne et invisible dans une capture d'écran réduite. Fiez-vous aux nombres pour la géométrie et à vos yeux pour l'équilibre et la hiérarchie.
• Un mot d'unité qui traîne est la cause habituelle des colonnes mal alignées. "Pieds" et "Stones" ont des largeurs différentes, donc tout ce qui les suit se décale. Mettez les libellés au-dessus des champs.
• Les petites modifications sur les gros fichiers restent petites. Lorsque la source est un fichier volumineux généré, modifiez le balisage et les styles du formulaire en bloc plutôt que de corriger attribut par attribut, sinon la mise en page ne changera jamais.
• S'arrêter quand les chiffres passent est l'échec classique. La géométrie n'est que la moitié du polissage ; l'autre moitié est la grille (un vrai titre, un seul interrupteur de mode au lieu d'un lien par champ, une raison pour les questions sensibles, l'orientation).
• Un token, plusieurs constats. Un constat de petite police ou de petite cible tactile qui se répète sur chaque page provient généralement d'un token de système de design ou d'un composant. Corrigez-le là, ou enregistrez la décision du propriétaire dans ui-polish.config.json, plutôt que de le trier page par page.
• Passer les vérifications n'est pas le but. Un écran ciblé avec un titre clair, des champs regroupés et une action principale à proximité l'est. Utilisez les vérifications pour prouver que vous y êtes arrivé.

---

Conçu par aictrl.dev. Cette compétence enseigne le workflow ; aictrl l'opérationnalise — ancré dans votre backlog, les normes de votre équipe et le graphe de connaissances de votre codebase. Voir comment →