entro314-labs/ui-declutter

UI declutter

Modifiez une interface pour que chaque mot et ornement qui s'y trouve soit là pour la personne qui l'utilise. Les écrans générés ont tendance à s'expliquer eux-mêmes : une étiquette au-dessus du titre, une phrase en dessous, une indication à côté du bouton. Chaque ajout semble anodin, et ensemble, ils enterrent les trois mots que l'utilisateur est venu chercher.

L'objectif est un écran qui sert son utilisateur. Ce n'est pas un écran qui évite de paraître généré. La différence compte lorsqu'une règle et le besoin de l'utilisateur divergent : le besoin de l'utilisateur prime, et vous le mentionnez dans le rapport.

Cible : le fichier, dossier ou composant nommé par l'utilisateur. S'il n'en a nommé aucun, utilisez les fichiers d'interface modifiés dans cette conversation. S'il n'y en a pas, demandez.

Périmètre : copie, actions, états, contenu inventé, décoration et graphiques. La surface visuelle (règles X1 à X4) n'est incluse que lorsque l'utilisateur le demande, en mots ou avec --surface.

Étape 1 : dites qui est sur cet écran

Avant de lire la moindre chaîne, écrivez une ligne :

Qui : un joueur en pleine mission qui a appuyé sur Échap. Action : décider s'il retourne dans le jeu, modifie un paramètre ou redémarre.

Cette ligne est ce contre quoi vous jugez tout. Sans elle, les règles ci-dessous sont appliquées comme une correspondance de motifs, et une correspondance de motifs supprime les exigences de mot de passe en même temps que le remplissage. Un visiteur pour la première fois sur une page de tarification a besoin de plus de mots qu'un utilisateur quotidien d'un tableau d'administration. Un jeu peut contenir un texte d'ambiance qu'un formulaire fiscal ne peut pas.

Si le code ne vous dit pas qui est l'utilisateur, déduisez-le du produit et indiquez la déduction. Ne demandez que si deux interprétations plausibles conduiraient à des modifications différentes.

Étape 2 : le test

Pour chaque élément de texte visible et chaque élément décoratif, demandez :

Sans cela, cet utilisateur hésiterait-il, ferait-il une erreur ou serait-il surpris par la suite ?

• Non → supprimez-le.
• Non, mais quelqu'un en a besoin ailleurs → déplacez-le. Un fait destiné aux développeurs va dans un commentaire de code. Un fait que quelques utilisateurs recherchent va dans une infobulle ou la documentation. Un nom dont seule la technologie d'assistance a besoin va dans aria-label.
• Oui, mais c'est mal dit → réécrivez-le, en utilisant uniquement des faits que vous pouvez trouver dans le code, le contenu ou la conversation.
• Oui → conservez-le et ne le touchez pas.

Les règles qui suivent sont les manières courantes dont les écrans générés échouent à ce test. Elles vous aident à repérer rapidement les candidats. Lorsqu'un écran échoue au test d'une manière qu'aucune règle ne nomme, le test s'applique toujours. Lorsqu'une règle signale quelque chose qui réussit le test, conservez-le.

Texte qui mérite une phrase complète

Ceux-ci réussissent le test presque à chaque fois. Ne les réduisez pas à une étiquette et ne les supprimez pas :

• Contraintes que l'utilisateur doit satisfaire : règles de mot de passe, types et tailles de fichiers acceptés, formats de date et de nombre, limites de caractères.
• Conséquences : ce qu'une action destructive ou irréversible supprime, ce qu'un paiement facture et quand, ce qu'une permission accorde, qui verra quelque chose une fois partagé.
• Erreurs : ce qui a mal tourné et quoi faire ensuite.
• États vides : ce qui va ici et comment ajouter le premier élément.
• Texte de consentement, juridique et réglementaire. Ne modifiez jamais son libellé. Signalez-le s'il semble incorrect.
• Instructions pour une tâche que l'utilisateur effectue rarement et ne peut pas annuler.

Règles

Les identifiants sont stables. Citez-les dans le rapport.

Copie

• C1. Étiquettes sourcilières. Petit texte en majuscules ou avec un espacement de lettres au-dessus d'un titre ("FONCTIONNALITÉS", "COMMENT ÇA MARCHE", "OPÉRATION EN ATTENTE" au-dessus de "EN PAUSE"). Le titre nomme déjà la section, donc supprimez l'étiquette sourcilière. Si l'étiquette sourcilière est la meilleure ligne (texte d'ambiance dans un jeu, terme propre à un produit), promouvez-la en titre et supprimez le titre générique. Un des deux, jamais les deux.
• C2. Numérotation décorative. "01 02 03", "01 // Fonctionnalités", préfixes "§" et "//". Supprimez sauf si l'ordre est réel et que l'utilisateur le suit, comme dans les étapes de paiement ou un guide d'installation.
• C3. Réflexe de sous-titre. Une phrase sous chaque titre, une description sous chaque élément de menu ("Paramètres : Mettez à jour vos paramètres"). N'en conservez qu'une seule lorsqu'elle énonce un fait que le titre n'énonce pas.
• C4. Narration. Texte d'aide et légendes qui décrivent ce que l'élément est visiblement ou fait ("Cliquez sur le bouton ci-dessous pour commencer", "Cette carte affiche votre activité récente"). Supprimez.
• C5. Notes d'implémentation divulguées. Texte sur le fonctionnement sous-jacent de l'écran, ou une exigence de l'invite rendue comme copie : "Reprendre récupère la souris", "(mise à jour en temps réel)", "(propulsé par l'IA)", "Les données sont mises en cache pendant 5 minutes". L'utilisateur n'agit pas en fonction. Déplacez-le dans un commentaire de code, ou supprimez-le.
• C6. Chaînes d'état. Faits enchaînés avec "·" ou "|" ("12 éléments · Mis à jour il y a 2 min · Synchronisé · v2.1"). Conservez le fait sur lequel l'utilisateur agit. Mettez les autres là où ils sont nécessaires, ou supprimez-les.
• C7. Indices en double. Une étiquette qui répète l'espace réservé, l'icône, le texte du bouton ou le titre de la section. N'en conservez qu'un. Pour les champs de formulaire, conservez l'étiquette visible : un espace réservé disparaît lors de la saisie et n'est pas un nom accessible.
• C8. Slogans. "Un. Grand. Truc.", "Construit différemment.", "Livrez plus vite. Réfléchissez moins." Réécrivez en une phrase qui nomme la chose et ce qu'elle fait, si la source vous donne ces faits. Sinon, signalez-le au propriétaire.
• C9. Titres de section génériques. "Pourquoi nous choisir", "Tout ce dont vous avez besoin", "Conçu pour des équipes comme la vôtre". Un titre qui pourrait figurer sur la page de n'importe quel produit ne dit rien de celui-ci. Renommez-le pour ce que la section contient, ou supprimez le titre si le contenu tient sans lui.
• C10. Surcharge d'indications. Infobulles sur des contrôles qui ont déjà une étiquette textuelle, badges de raccourcis clavier sur chaque action, encarts "Astuce :" et "Conseil de pro", marques de coaching sur un écran ordinaire. Conservez une indication lorsque le contrôle est autrement ambigu (un bouton avec seulement une icône) ou que le raccourci est la principale façon de l'utiliser.

Actions

• A1. Étiquettes d'action vagues. "Commencer", "En savoir plus", "Soumettre", "Continuer", "OK", "Cliquez ici". Un bouton dit ce qui se passe lorsqu'il est pressé : un verbe, et un objet lorsque le verbe seul est ambigu ("Créer un compte", "Exporter CSV", "Envoyer une invitation"). "Continuer" et "Suivant" sont acceptables dans un flux par étapes.
• A2. Une action, plusieurs noms. "Supprimer" sur un écran, "Retirer" sur le suivant et "Corbeille" dans le menu pour la même opération, ou "Se connecter" à côté de "Connexion". Choisissez le terme que le projet utilise le plus et appliquez-le partout dans la cible. Lorsque deux termes nomment des opérations différentes (retirer d'une liste versus supprimer définitivement), conservez les deux.
• A3. Boîtes de dialogue de confirmation. "Êtes-vous sûr ?" avec "OK" et "Annuler". Le titre nomme l'action et son objet ("Supprimer 3 projets ?"), le corps énonce la conséquence s'il y en a une ("Cela supprime également leurs 14 tâches. Vous ne pouvez pas annuler cette action."), et le bouton de confirmation répète le verbe ("Supprimer les projets"). Une confirmation pour une action qui est trivialement annulable est elle-même du superflu : signalez-la au propriétaire.

États

Le texte de chargement, de succès, vide et d'erreur est l'endroit où le remplissage s'accumule, car personne ne regarde ces états lors de la révision d'un écran. Lisez references/states.md avant de modifier l'un d'eux : il indique ce que chaque état doit contenir, ce qui est plus que ce qu'il faut supprimer.

• S1. Remplissage de chargement. "Un instant !", "Calcul en cours…", "Patientez un moment pendant que nous préparons les choses". Ne nommez ce qui charge que si l'attente est assez longue pour le lire. Sinon, un spinner ou un squelette seul.
• S2. Remplissage de succès. "Enregistré avec succès !", "Vos modifications ont été enregistrées avec succès." Énoncez le résultat en aussi peu de mots que possible ("Enregistré", "Invitation envoyée à [email protected]"). Si l'écran montre déjà le résultat, pas de toast.
• S3. Remplissage d'état vide. "Rien ici pour l'instant !", "On dirait que vous n'avez pas encore créé de projets. Commencez par créer votre premier projet !" Dites ce qui va ici et donnez l'action unique qui l'ajoute.
• S4. Erreurs vagues ou mignonnes. "Oups ! Quelque chose s'est mal passé", "Une erreur s'est produite. Veuillez réessayer plus tard." Dites ce qui a échoué et ce que l'utilisateur peut faire. Si le code ne peut pas savoir ce qui a échoué, dites-le clairement et donnez la réessayer.

Contenu inventé

• F1. Preuve inventée. Nombre d'utilisateurs, chiffres de disponibilité, notes par étoiles, témoignages avec un nom et un titre de poste, rangées de logos "Approuvé par", "Comme vu dans". Si le projet n'a pas de source pour cela, c'est une fausse déclaration sur une page livrée. Ne le réécrivez pas en une fausse déclaration plus petite. Supprimez-le et listez-le dans le rapport afin que le propriétaire puisse fournir la vraie chose.
• F2. Données factices dans les écrans livrés. "John Doe", "Acme Corp", lorem ipsum, adresses example.com, services d'avatars génériques. Dans les maquettes, les tests et les histoires, c'est acceptable. Dans un écran livré, signalez-le comme une tâche. Vous ne pouvez pas fournir de vraies données.

Décoration

• D1. Badges sans état. "NOUVEAU", "EN DIRECT", "IA", "Bêta", "Pro", "Populaire" ajoutés pour l'ambiance. Ne conservez un badge que lorsqu'il reflète quelque chose que l'application suit.
• D2. Points d'état. Points pulsants ou colorés à côté du texte. Ne conservez que lorsqu'ils sont liés à un état réel, et donnez-leur un nom accessible.
• D3. Emoji et icônes décoratifs. Dans les titres, les boutons, les étiquettes et les éléments de liste. Supprimez. Une icône reste lorsqu'elle est le contrôle (un bouton icône avec un aria-label) ou lorsqu'elle porte un sens que le texte n'a pas.

Graphiques et tableaux de bord

• V1. Titres qui nomment le type de graphique. "Graphique à barres du chiffre d'affaires mensuel" devient "Chiffre d'affaires mensuel". Énoncez la conclusion à la place ("Le chiffre d'affaires a doublé depuis mars") uniquement si les données devant vous le montrent.
• V2. Instructions de lecture. "Chaque barre représente un mois", "Survolez pour plus de détails". Supprimez.
• V3. Dire la même chose deux fois. Un encodage par quantité. Un KPI avec une flèche, un pourcentage, le mot "en hausse" et une phrase reformulant les trois ne conserve que le nombre et une comparaison.
• V4. Échafaudage qui concurrence les données. Cadres de tracé, grilles sombres ou denses, bordures d'axes épaisses, 3D, ombres et lueurs sur les marques. Supprimez, ou réduisez ce qui doit rester à un trait fin. Même type de graphique, mêmes données, mêmes couleurs de série.
• V5. Légende là où une étiquette directe fonctionne. Avec quatre séries ou moins et de la place pour les étiqueter, nommez chaque série à l'extrémité de sa ligne ou à côté de sa barre et supprimez la légende.

Surface (uniquement lorsque demandé)

Lisez references/surface.md en premier. Il commence par une vérification de l'intention de conception qui décide si ces règles s'appliquent du tout : un jeu, une page marketing ou une mise en page éditoriale avec une typographie délibérée n'est pas un défaut à normaliser.

• X1. Dégradés et lueurs. Dégradés de teinte à teinte sur les surfaces et les boutons, texte en dégradé, lueurs colorées, blobs de couleur flous.
• X2. Espacement hors échelle. Valeurs ponctuelles telles que mt-[13px] ou gap: 7px alors que les frères utilisent l'échelle.
• X3. Poids lourds dans l'interface utilisateur courante. 800 et 900 sur le texte du corps, les étiquettes, les cellules de tableau et les contrôles. Les titres d'affichage sont hors de portée.
• X4. Mouvement décoratif. transition-all, cartes qui s'agrandissent au survol, rebonds et boucles qui n'expliquent rien.

Pour le style au niveau des chaînes dans ce que vous conservez ou réécrivez (casse, ponctuation, mots de remplissage, cohérence), lisez references/writing.md. Pour des exemples avant-après travaillés, y compris des cas où la bonne modification est de conserver le texte, lisez references/examples.md lorsque vous n'êtes pas sûr de la distance à parcourir.

Garde-fous

• N'ajoutez jamais un fait. Une réécriture utilise ce qui se trouve dans le code, les fichiers de contenu, les données ou la conversation. "Les modifications se synchronisent en quelques secondes" est une affirmation sur le produit, et vous ne savez pas que c'est vrai. Si la réécriture honnête a besoin d'un fait que vous n'avez pas, supprimez la ligne ou listez-la comme une tâche pour le propriétaire. C'est la règle la plus facile à enfreindre, car un élément spécifique inventé se lit mieux que la ligne vague qu'il remplace.
• Modifiez uniquement le texte visible et les éléments décoratifs. Laissez la logique, les données, les couleurs, la police et la structure de mise en page tranquilles. Les exceptions sont l'échafaudage du graphique sous V4 et les règles de surface lorsqu'elles sont demandées.
• Conservez les noms accessibles. Ne supprimez jamais aria-label, alt, title sur les boutons icône, ou le texte réservé aux lecteurs d'écran. Si le texte visible que vous avez supprimé était le seul nom accessible, déplacez-le vers aria-label.
• Modifiez le texte à sa source. Les chaînes provenant de fichiers i18n, d'accessoires, de maquettes ou d'un CMS sont modifiées là, ou signalées. Ne codez pas en dur un remplacement dans le composant. Lorsque vous modifiez une chaîne dans un fichier de locale, listez les autres locales comme tâches ; ne les traduisez pas vous-même sauf si on vous le demande.
• Nettoyez après une suppression. Supprimez le conteneur qui est maintenant vide et la marge ou l'espacement qui n'existait que pour l'élément supprimé.
• Laissez un écran propre tranquille. Si rien n'échoue au test, ne changez rien.
• Suivez le projet. Là où le projet a son propre guide de ton, glossaire, tokens ou système de conception, corrigez selon ceux-ci et non selon les valeurs par défaut de cette compétence.

Procédure

Suivez ces étapes :

- [ ] 1. Qui et action : une ligne
- [ ] 2. Comptage : python3 scripts/count_tells.py <cible>      (ajoutez --surface si demandé)
- [ ] 3. Regarder : capture d'écran de l'écran si possible
- [ ] 4. Lire chaque chaîne visible et chaque ornement dans chaque état ; appliquer le test ; marquer les échecs avec un identifiant de règle
- [ ] 5. Verdict : lourd, léger ou aucun
- [ ] 6. Modifier
- [ ] 7. Recompter, revoir
- [ ] 8. Rapport

scripts/ se trouve dans le dossier de cette compétence. Exécutez le script par son chemin complet.

Comptage. count_tells.py est un passage regex sur le code source. Il trouve des candidats et donne un nombre avant-après pour les motifs qui ont une signature de code. Il ne peut pas voir C3, C4, C5, C7, A2, V3 ou quoi que ce soit qui dépende du sens, et il signale des utilisations légitimes. Traitez sa sortie comme une liste d'endroits à regarder. Un nombre qui n'atteint pas zéro est acceptable lorsque ce qui reste est conservé intentionnellement.

Regarder. La source cache ce que l'utilisateur voit : quelles chaînes apparaissent ensemble, ce qui vient des données, ce qu'une suppression fait à la mise en page. Si vous avez un navigateur ou un outil de capture d'écran, capturez l'écran avant et après. Si vous n'en avez aucun, python3 scripts/screenshot.py <url-ou-fichier-html> <out.png> le fait là où Playwright est installé. Vérifiez l'image après pour les espaces orphelins, un titre qui a perdu sa hiérarchie et les contrôles qui ont bougé. Si vous ne pouvez pas rendre l'écran, dites-le dans le rapport.

Lire chaque état. La vue par défaut n'est qu'une fraction de l'interface. Recherchez dans la cible les branches de chargement, vides, d'erreur, de succès et désactivées, les toasts, les boîtes de dialogue et les validations de formulaire. Si un état n'est pas accessible via l'interface utilisateur, ouvrez les fichiers de composant et vérifiez le marquage conditionnel. Le texte que personne n'a vu en révision est celui qui enfreint le plus de règles.

Rapport. Après la modification, écrivez un rapport court dans la réponse :

• Le nombre avant-après (aucun changement acceptable si tout est intentionnel)
• Ce qui a été supprimé et pourquoi (avec les identifiants de règle)
• Ce qui a été conservé et qui enfreint une règle (avec la raison que le test l'exige)
• Tâches pour le propriétaire (faits inventés que vous ne pouviez pas vérifier, incohérences entre locales, actions trivialement annulables qui demandent une confirmation, directives de conception que l'écran ne suit pas — si vous en avez les compétences, vous pouvez également remédier à ces éléments lorsqu'ils sont dans la cible, en signalant ce que vous avez fait)