- La qualité de finition d’une UI ne progresse pas juste après son implémentation, mais au fil d’un processus itératif où l’on continue réellement à cliquer dessus, que l’article compare au ponçage en menuiserie
- Les transitions de page et la navigation doivent être vérifiées via plusieurs points d’entrée : clic, bouton précédent du navigateur, clic droit « Back », retour intégré à l’app, raccourcis clavier, etc.
- En alignant
labeletinput type="radio"avec flexbox et en ajoutant ungap, on révèle une zone morte non cliquable entre le bouton radio et son libellé - La solution a consisté à supprimer le
gapet à ajouter du padding aulabel, ce qui conserve l’espacement visuel tout en élargissant la zone cliquable - Même de petits défauts d’interaction finissent par dégrader l’expérience utilisateur ; il faut donc utiliser l’UI de manière répétée et la peaufiner jusqu’à ce qu’on n’y sente plus aucune « écharde »
Trouver les aspérités d’une UI à force de cliquer
- Travailler sur une UI consiste moins à construire quelque chose qu’à beaucoup cliquer, corriger, puis cliquer à nouveau, en boucle
- Pour les transitions de page, vérifier un seul flux ne suffit pas ; il faut aussi revenir en arrière de plusieurs façons
- après un clic, utiliser le bouton précédent du navigateur
- après un clic, utiliser « Back » dans le menu contextuel du clic droit
- utiliser la navigation de retour dans l’application
- utiliser un raccourci clavier pour revenir en arrière
- Ce processus ressemble à une QA où l’on « clique pour essayer de tout casser », mais la sensation est plus proche du ponçage en menuiserie, où l’on cherche les aspérités et les échardes
- Une UI logicielle peut comporter beaucoup trop d’états et de variables ; on la retravaille donc par usage répété jusqu’à ce qu’on n’y accroche plus aucune « écharde »
La zone morte cliquable créée par le gap de flexbox
- Dans une liste d’options radio, le
<label>et le<input type="radio">associé étaient placés sur la même ligne - Le CSS était une structure simple appliquant au conteneur
display: flex,flex-direction: row,align-items: center,gap: .5rem - En cliquant de façon répétée, on a découvert qu’appuyer dans l’espace entre le bouton radio et son libellé ne basculait pas le contrôle : une zone morte
- La cause était le
gapde flexboxgappermet de créer facilement un espacement visuel- mais il n’est pas inclus dans la zone cliquable du label ou de l’élément input, ce qui crée un vide dans l’interaction
- La solution a été de supprimer le
gapet d’ajouter du padding aulabel- l’espacement est conservé
- la zone cliquable du label s’élargit, et la zone morte disparaît
- Un petit défaut isolé peut sembler anodin, mais l’accumulation de ces « petites échardes » peut rendre l’expérience UI pénible
1 commentaires
Avis sur Hacker News
Un développeur qui est aussi un utilisateur intensif du produit qu’il est en train de construire a un gros avantage pour repérer ce genre de petits problèmes.
Parce qu’il peut remarquer lui-même une petite friction avant que les utilisateurs ne tombent dessus, et qu’il est aussi en position de la corriger immédiatement.
C’est pourquoi les petites équipes avec un fort sentiment d’ownership semblent efficaces. Quand on se sent propriétaire du produit, les petits désagréments vécus par les utilisateurs deviennent aussi les siens, et rendre l’UX aussi fluide que possible devient une question de fierté.
Sauf dans les cas où il est difficile de les utiliser en interne, comme certains produits d’entreprise, cela crée au moins un intérêt direct dans la réussite du produit, même si l’ownership direct est plus faible.
Je me demande quelle est l’UI la plus aboutie.
On pourrait penser qu’avec les moyens des FAANG, l’UI/UX serait plutôt bonne, mais quiconque a utilisé Amazon.com, AWS, GCP ou Azure aura sans doute un autre ressenti.
Personnellement, je considère que mcmaster.com a l’UI/UX la mieux peaufinée. On peut trouver ce dont on a besoin en quelques minutes.
À l’inverse, sur les sites de grandes enseignes comme Home Depot ou Lowe’s, il faut parfois 10 à 15 minutes pour trouver des vis ou du bois aux dimensions exactes, et c’est encore pire sur mobile.
Il est incroyablement simple et pragmatique, tout en étant assez puissant. On peut affiner progressivement la recherche de pièces ou chercher directement, la comparaison des prix se fait automatiquement, et les catégories prix/qualité sont regroupées de façon utile.
Quand on trouve un numéro de pièce, on peut voir la compatibilité par année/fabricant/modèle, une courte description, des photos, ainsi que si elle sera expédiée depuis le même entrepôt que d’autres pièces du panier. Tout cela se fait sur une seule page, sans friction, et fonctionne très vite sur n’importe quelle plateforme.
Elle est extrêmement réactive, et je n’ai jamais vu de bug en l’utilisant. Elle a relevé mon niveau d’exigence sur ce que je pensais possible pour une web app.
Ils ont même eu une période dédiée uniquement à la correction de problèmes d’utilisabilité.
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
La plus agaçante est surtout la photo de profil temporaire. Elle ne fonctionne plus correctement depuis presque un an et ne revient pas à la photo d’origine.
On dirait que personne ne polit quoi que ce soit là-bas.
https://littlebigdetails.com illustre exactement cela.
La solution de base à ce problème précis consiste à mettre l’élément de saisie à l’intérieur du label.
Je me demandais pourquoi ; c’est probablement parce que cela simplifie l’application de thèmes quand on ajuste la position ou le padding du label ou de l’élément de saisie.
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for/idrestent nécessaires pour l’accessibilité avec les logiciels de commande vocale courants : https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...Pour les boutons radio ou les cases à cocher, le clic ne devrait pas seulement fonctionner sur la case et son padding, mais sur tout le libellé textuel.
Flexbox me semble un peu excessif. Même avec une syntaxe non imbriquée, les éléments seraient disposés en inline, et il suffirait selon moi d’ajouter le padding de la même manière.
Pour atténuer cela, il faut envelopper
Foodans un élément séparé.Ce genre de choses a trop disparu avec l’Agile
Les ingénieurs devraient avoir du temps pour peaufiner le produit, mais en pratique ils n’en ont pas. Si la QA ne crée pas de ticket pour un problème d’espacement, il ne sera jamais corrigé
Le client remarquera probablement ce genre de choses, mais qu’il le signale tient déjà du miracle, que cela finisse par devenir un ticket aussi, et que quelqu’un le priorise et le corrige en est encore un autre
En réalité, dans la plupart des entreprises, les tableaux d’issues sont tellement opaques du point de vue du client que, quand on trouve un petit problème ou un bug, il faut faire des allers-retours pendant 50 heures pour prouver que c’est bien un bug et réussir à le faire entrer dans le tracker, ce qui est exaspérant
Tu penses que le modèle en cascade prévoyait explicitement du temps pour tester et peaufiner l’UI ?
C’est normalement un processus que le chef de produit doit prioriser et traiter avec un ingénieur UX ou un designer compétent. Si on le souhaite, on peut intégrer cette priorité dans n’importe quelle méthode de développement, donc l’Agile n’a rien à voir ici
Je l’ai signalé plusieurs fois au cours des trois dernières années, parce que l’édition du texte pendant la rédaction est extrêmement difficile et agaçante
En tant que développeur web, je me demande comment une chose pareille a pu être cassée au départ. Je ne sais pas quel niveau d’incompétence il faut pour casser quelque chose qui fonctionne par défaut. C’est une correction qui ne devrait pas prendre plus de 30 minutes et qui rendrait l’expérience utilisateur de tout le monde 1000 fois meilleure, mais trois ans après l’avoir signalé, c’est toujours pareil
Dans Teams aussi, j’ai signalé via Microsoft Premiere Support un bug empêchant d’utiliser les touches HOME/END dans le champ de numéro de téléphone, et la réponse a été : « fonctionne comme prévu »
Ça ne m’étonne pas que les clients ne signalent plus ce genre de bugs. Les employés/développeurs comme l’entreprise s’en moquent de toute façon
Je suis développeur principal sur un produit, et il y a plein de petits problèmes un peu partout. Avoir la responsabilité de certaines choses sans avoir le pouvoir de les corriger, ce n’est évidemment pas une situation agréable
Du point de vue business, le raisonnement devient : pourquoi dépenser du temps et de l’argent pour corriger quelque chose qui n’affecte ni le chiffre d’affaires ni la marque ? À long terme, cela affectera la marque, mais la plupart des gens auront changé de rôle ou d’entreprise d’ici cinq ans, donc ils s’en fichent
Quand on obtient ne serait-ce qu’une réponse, c’est déjà un bon cas de figure
Il y a manifestement un processus qui ne répond pas aux besoins des clients, donc il suffit de le corriger avec l’équipe
S’il y a des cérémonies Scrum, on peut en parler en rétrospective, mais en réalité c’est possible à tout moment. La rétro n’est qu’un moment prévu pour revenir sur les dernières semaines ; ce qu’on remarque en cours de route, il faut essayer de le régler en cours de route
Les personnes capables de repérer et de corriger les petits problèmes d’UX sont vraiment importantes
En design UX, on compare souvent cela à des coupures de papier infligées aux utilisateurs. Ce n’est pas fatal, mais cela réduit leur satisfaction
Pour compléter ce que dit l’auteur, ce bouton radio ne suit pas la convention selon laquelle l’état sélectionné utilise un point plutôt qu’une coche. Au premier coup d’œil, l’utilisateur peut croire qu’il est possible d’en sélectionner plusieurs, ou de n’en sélectionner aucun
C’est très probablement un effet de bord de la fonctionnalité qui ferme la boîte quand on clique à l’extérieur
S’il existe des « Papercuts » côté négatif, côté positif il y a le Juice, dont HN a aussi parlé récemment
Cet article illustre bien pourquoi je déteste programmer des UI
Les choses imprévisibles qui peuvent se décaler de façon minuscule dépassent ma patience. J’apprécie dans une certaine mesure de réfléchir aux façons dont quelque chose peut échouer et d’écrire des tests, mais cliquer un peu partout au hasard pour voir si ça casse me paraît dispersé et agaçant
Je me demande si l’implémentation d’UI est intrinsèquement aussi complexe, ou si nous n’avons simplement pas encore trouvé le bon modèle de programmation. Parfois, je me demande s’il est déraisonnable d’espérer que les choses aient l’apparence et le comportement prévus dès le départ
On ne devrait avoir à peaufiner l’UI qu’au moment de créer les composants pour la première fois. Il peut arriver qu’il faille combiner des composants d’une autre manière ou faire une implémentation ponctuelle
Franchement, quand on sait ce qu’on fait, ça ne prend pas tant de temps. Un bon design engineer est spécialiste de ce rôle
Il y a beaucoup trop de degrés de liberté, et les éléments de base comme les formulaires devraient fonctionner correctement avec leurs valeurs par défaut
Il existe déjà de bonnes façons d’exprimer une UI par le code. Le problème, c’est le jeu à somme nulle côté business. L’UI multiplateforme coûte trop cher si on ne la fait pas avec la pile d’UI la plus laide qui soit : HTML/CSS/JS
Mais la plateforme web, même si elle est à peu près correcte pour les documents, n’a pas le bon niveau d’abstraction pour les applications. C’est pourquoi les UI web sont réinventées chaque année avec de nouvelles abstractions qui fuient
Rien que suivre le rythme représente déjà énormément de travail
C’est pareil dans d’autres domaines. S’il n’existe pas de moyen simple d’envoyer une requête ou de passer des paramètres à une requête, les gens, même en essayant d’être prudents, finissent sous la pression naturelle par inventer toutes sortes de solutions à moitié faites
La plateforme web est à la pointe côté graphisme, mais elle est vraiment lamentable comme UI. Pourtant, personne ne veut l’admettre ni la changer. Les gens ne voient que la première partie, et l’héritage ainsi que la complexité des navigateurs bloquent le changement. Si on en fait une bibliothèque, comme ce n’est pas un « standard », personne ne s’en soucie
Par ailleurs, certaines UI utilisent des cases carrées pour des boutons radio
Il y a parfois un bouton mis en évidence qui ne s’active pas avec la touche Entrée
Et il arrive aussi que trois menus soient cachés derrière des symboles différents (points de suspension, hamburger, kebab)
La qualité varie énormément. Les personnes qui peaufinent les UI méritent vraiment notre reconnaissance
Même Apple s’y met :(
Je ne comprends pas pourquoi la méthode qui consiste à mettre l’élément de saisie à l’intérieur du libellé n’est pas populaire
Avec ça, le problème disparaît complètement, et il n’y a même plus besoin de créer un
idunique pour leforMais comme on sait qu’il existe encore quelques technologies d’assistance qui n’interprètent pas les nouveaux motifs standards valides, la meilleure pratique reste de s’en tenir aux standards de l’âge du bronze [1]
J’imagine que d’autres frameworks font quelque chose de similaire. Si on enveloppe ces deux champs de saisie dans un élément
label, ce n’est plus du HTML valideCe n’est pas un problème pour les boutons radio, mais certains semblent avoir vécu ça puis adopté cette pratique « pour être sûrs ». C’est un peu comme mettre des points-virgules à la fin des lignes en JavaScript. C’est rarement nécessaire, mais comme on ne sait pas exactement quand ça l’est, on en met partout
Pour les cas d’usage courants des cases à cocher/boutons radio, la syntaxe est aussi beaucoup plus propre
Il suffit d’envelopper l’élément de saisie avec le libellé, et si on veut styliser le texte, de mettre le texte dans un
span. On peut mettre lelabelendisplay:flexet gérer ainsi la position du texteDans les bug bashes, j’utilise cette approche, et on en tire beaucoup plus de tickets que la personne qui a construit une matrice en produit cartésien multidimensionnel de combinaisons de cas de test
Connaître ce genre de cas de test comme point de départ est utile, mais pour trouver de petits problèmes, les tests aléatoires dépassent rapidement les tests planifiés
Les tests planifiés restent généralement sur le chemin nominal ou les erreurs attendues. Cette manière de peaufiner permet de trouver les bugs de bord beaucoup plus vite
Je finis toujours par trouver un problème ou une petite amélioration. Des choses qui ne seraient probablement pas ressorties avec des tests planifiés
Je peaufine mon site personnel (https://dustinbrett.com) depuis près de 4 ans, et j’ai l’impression que ça pourrait continuer indéfiniment
Heureusement, j’aime y travailler
J’espère que c’était tout :-)
Quand je vois un « OS de bureau dans une page web », la plupart donnent une impression de moitié fini et, honnêtement, c’est devenu trop courant ; celui-ci, au contraire, est très solide et bien peaufiné
C’est vraiment bien fait et inspirant. C’est aussi assez plaisant d’imaginer comment tout a été implémenté
Celui de vouloir utiliser un OS à fenêtres sur mon téléphone
S’il fallait trouver une chose qui manque, ce serait l’impossibilité d’utiliser mouse4/mouse5 dans l’explorer. Le « peaufinage » peut vraiment continuer éternellement