review

ultrahand : review

Revoyez une conception UI comme le ferait un inspecteur expert. Parcourez chaque flux, interaction et contrôle par rapport aux principes de la plateforme, aux 10 heuristiques de Nielsen et à WCAG 2.2 AA, puis vérifiez que la conception tient toujours à d'autres tailles. Le résultat est une liste de constats classés par gravité. Chaque constat nomme l'élément, le principe et sa source, et donne une correction concrète.

Chaque vérification se trouve dans references/checklist.md, et chaque vérification cite references/sources.md. Pour les règles de la plateforme en détail, utilisez les principes propres aux compétences de conception : mobile, tablette et desktop. Pour un projet avec un thème, vérifiez la conception par rapport à celui-ci avec la compétence theme-review : l'utilisation des tokens, la réutilisation des composants et la cohérence entre les écrans relèvent de cette compétence, pas de celle-ci.

1. Obtenir la conception et savoir ce qu'elle peut montrer

Utilisez la preuve la plus riche que l'utilisateur peut fournir. Dites de quel type vous disposez, car cela limite ce que vous pouvez confirmer.

• Artefact canvas ultrahand (un lien artifact claude.ai) : lisez son HTML. Il contient le balisage, les libellés, les couleurs et chaque écran et état. Si un outil navigateur est disponible, ouvrez l'artefact. Configurez chaque vue via window.ultrahandCanvas (voir le README du canvas dans shared/canvas/) : usePreset(id), setSize(w, h), setScheme('dark'), setTextScale(2), setState('error'), navigate(id). Activez afficher les cibles tactiles et lisez son résultat (#uh-targets-result), qui compte les cibles en dessous du minimum de la plateforme. Appelez refresh() après avoir ouvert une feuille ou un menu pour que le compte l'inclue. Le README du canvas liste les identifiants des éléments de la barre d'outils. Les maquettes d'un prototype (pas de vrai réseau, pas de clavier à l'écran) sont classées sous Non vérifié, pas dans les constats. Le clavier matériel est réel : piloter chaque flux avec lui.
• Build canvas local (un index.html de build.mjs) ou toute page que vous pouvez ouvrir : traitez-le comme l'artefact et utilisez-le avec le pilote d'entrée (étape 4).
• Code (HTML, SwiftUI, Compose, Flutter, etc.) : vous pouvez vérifier les libellés, les rôles, l'ordre de focus, les couleurs et les points de rupture, mais pas l'apparence à moins de pouvoir l'exécuter.
• Capture d'écran ou maquette : vous pouvez juger la disposition, la hiérarchie, le libellé et le contraste et les tailles approximatifs. Vous ne pouvez pas confirmer les libellés, l'ordre de focus ou le comportement ; marquez ces constats Probable ou listez-les sous Non vérifié.

Marquez la preuve de chaque constat : Confirmé (vu dans le code ou mesuré sur le canvas) ou Probable (déduit d'une image). Ne présentez jamais une supposition sur un comportement caché comme un fait.

2. Établir le contexte

Notez ceci avant de juger quoi que ce soit ; un constat n'a de sens que par rapport à cela.

• Plateforme : iOS, iPadOS, Android, macOS, Windows ou le web. Lisez-la depuis le canvas (size.platform), le code ou le style visuel. Si ce n'est pas clair, demandez une fois.
• Taille actuelle : largeur × hauteur, et la classe de taille en largeur : compact < 600, moyen 600–839, étendu 840–1199, grand 1200–1599, extra-large 1600+. Hauteur compact < 480, moyen 480–899, étendu 900+. Notez l'orientation et tout fractionnement.
• Entrées : tactile, pointeur, clavier ou un mélange. Une tablette ou un ordinateur portable tactile peut avoir les trois.
• Utilisateurs et tâche principale : qui utilise chaque écran, et la seule chose pour laquelle il est fait. Demandez si vous ne pouvez pas le déduire ; une revue sans tâche devient une liste d'opinions.
• Produit ou outil : une conception pour les utilisateurs finaux, ou un outil construit pour le propriétaire (le canvas lui-même, un éditeur, un visualiseur). Un outil est une application de bureau utilisée dans une fenêtre de navigateur de n'importe quelle taille : examinez-le avec les règles de bureau et passez 8. Son chrome reçoit les vérifications de passe 7 que la passe 8 liste (tailles de fenêtre, zoom du navigateur, ses propres thèmes), pas les préréglages de la conception, et la passe de composition comme n'importe quel écran.

Choisissez les règles de la plateforme par classe de taille de fenêtre et entrée, pas par nom d'appareil : tactile compact → principes mobiles ; tactile moyen et étendu, ou tout fractionnement → tablette ; une fenêtre avec pointeur et clavier → desktop. Une conception responsive reçoit tous les ensembles que ses tailles couvrent.

3. Inventorier la conception

Listez chaque écran et état, chaque flux entre les écrans, les sections de chaque écran (barres d'outils et leurs groupes, volets, en-têtes de volet, groupes de formulaires, cartes, listes, barres), et chaque contrôle interactif dans chaque section (boutons, liens, champs, bascules, onglets, menus, gestes, cibles de glisser-déposer). L'inventaire est la couverture de la revue : une section ou un contrôle que vous n'avez pas listé est quelque chose que vous n'avez pas vérifié.

Examinez à trois niveaux : l'écran entier, chaque section et chaque composant. Un écran dont tous les contrôles passent peut encore être encombré, désordonné et déroutant ; c'est un constat en soi, pas du polissage.

4. Inspecter par passes

Travaillez à travers les passes dans references/checklist.md dans l'ordre. Parcourez la conception deux fois : une fois pour l'apprendre, une fois pour trouver les problèmes.

Utilisez chaque contrôle avec une entrée réelle, à plusieurs tailles. Lire le balisage, ou appeler el.click(), dispatchEvent ou un setter, saute les tests de hit, le focus, les actions par défaut et le chaînage de défilement, donc un bouton couvert ou une molette bloquée semble encore correct. Utilisez la page comme le ferait une personne : événements de souris, de molette, de touche et tactiles fiables provenant de node "${CLAUDE_PLUGIN_ROOT}/shared/input/drive.mjs" (son README contient les étapes et les recettes), ou les clics et touches réels d'un outil navigateur. Le script est uniquement pour configurer une vue et lire l'état après.

• Faites-le à au moins trois tailles : la plus grande, une moyenne et la plus petite prise en charge (pour une conception, ses préréglages ; pour un outil, des fenêtres de navigateur telles que 1440×900, 1024×700 et 640×480).
• À chaque taille, listez les contrôles (controls), puis utilisez chacun comme son type est censé être utilisé : cliquez ou tapez, tapez, faites glisser et annulez avec Échap, cliquez droit, ouvrez et fermez avec le clavier, et faites défiler la molette ou balayez sur chaque défileur jusqu'au-delà de sa fin.
• Quelques contrôles natifs ne peuvent pas être pilotés avec une entrée fiable en mode headless : la popup d'un select, les sélecteurs de fichiers, et les sélecteurs de couleur et de date. Choisissez une option d'un select avec l'étape choose du pilote, et listez le reste sous Non vérifié.
• Lisez chaque résultat : un contrôle qui est covered, hors de vue sans moyen de l'atteindre, ou manquant à une taille ; un scrolled qui montre la molette bloquée ; le focus perdu vers body ; des erreurs de page. Chacun est un constat à cette taille.

1. Parcours de tâche : pour chaque flux, posez les quatre questions du parcours cognitif à chaque étape.
2. Composition : chaque écran dans son ensemble, puis chaque section, par rapport aux règles de composition (shared/composition/principles.md). Effectuez son audit à la plus grande et à la plus petite taille et lisez d'abord la capture d'écran floutée, avant de regarder un contrôle particulier. Lors de la révision d'une révision, comparez-la également avec la version précédente : qu'est-ce que la série a ajouté, et l'écran en est-il plus chargé ?
3. Contrôle par contrôle : chaque contrôle de l'inventaire par rapport aux vérifications de contrôle.
4. Heuristiques : chaque écran par rapport aux 10 de Nielsen.
5. Accessibilité : WCAG 2.2 AA. Calculez le contraste ; ne l'estimez pas à l'œil.
6. Plateforme : les règles pour la plateforme et la classe de taille de l'étape 2.
7. Redimensionnement et variantes : chaque préréglage, les largeurs de fractionnement, le reflow à 320, le texte à 200 %, le mode sombre, chaque état de données, et sur les appareils tactiles les deux orientations et le clavier levé (les fenêtres de bureau ne pivotent pas : vérifiez plutôt la fenêtre minimale, maximale et courte).
8. Outils : pour un outil construit pour le propriétaire, le travail reste en vue à chaque taille de fenêtre, la scène se déplace au-delà de ses bords, le zoom a des limites, et les raccourcis et les glissements se comportent.

Enregistrez un problème dès que vous le voyez, avec l'endroit où vous l'avez vu (écran › élément, plus la taille, le schéma et l'état). Un problème qui apparaît à plusieurs endroits est un seul constat avec plusieurs emplacements.

5. Évaluer la sévérité

Utilisez l'échelle 0–4 de Nielsen. Pesez combien d'utilisateurs rencontrent le problème, à quel point il leur nuit, et s'il continue de nuire une fois qu'ils le connaissent. Voir le guide de sévérité dans la checklist.

Évaluation	Signification
4 Catastrophe	Empêche les gens de terminer une tâche, ou perd leurs données. Corriger avant la publication.
3 Majeur	Ralentit ou déroute beaucoup de gens, ou échoue WCAG AA sur un flux principal. Corriger bientôt.
2 Mineur	Ralentit certains utilisateurs, ou il existe une solution de contournement évidente.
1 Cosmétique	Polissage. Corriger s'il reste du temps.

Ne signalez pas les 0. Un échec WCAG AA n'est jamais inférieur à 2.

6. Rapport

Commencez par un verdict d'un paragraphe : la plateforme, les tailles examinées, les preuves que vous aviez, la première impression (ce que montre l'écran flouté, et si l'écran semble organisé ou encombré), les comptes par sévérité, et le problème principal. Pesez une surface primaire désorganisée au même titre que les bugs : elle ralentit chaque utilisation, pas seulement un chemin. Listez ensuite les constats, les plus graves d'abord et dans l'ordre des flux au sein d'une gravité, en utilisant le modèle de la checklist :

• ID et sévérité, ex. R3 · 3 Majeur
• Élément : écran › section › élément (ou écran › section, ou l'écran entier, pour un constat de composition), et la taille, le schéma ou l'état où il apparaît
• Preuve : Confirmé ou Probable
• Problème : ce qui ne va pas pour l'utilisateur, en une ou deux phrases
• Principe : la règle qu'il enfreint, avec sa clé source (WCAG 1.4.3, NNG-H4, tablet:AND-T2)
• Correction : un changement concret avec des valeurs (élever le libellé à #595959 pour 7.0:1, pas améliorer le contraste)

Concluez par ce qui fonctionne bien (restez court), ce que vous n'avez pas pu vérifier et pourquoi (sortie du lecteur d'écran, vrais appareils, mouvement), et une note indiquant qu'un seul réviseur manque de problèmes que d'autres détectent, donc un second réviseur ou un test d'utilisabilité en vaut la peine.

Si le rapport est destiné à quelqu'un d'autre, proposez de le publier en tant qu'artefact. Proposez d'appliquer les corrections avec la compétence de conception ultrahand correspondante.