De simples fonctionnalités web

• Avec la multiplication des nouvelles plateformes de réseaux sociaux, de leurs clients, applications et portages web basés sur React Native, on voit de plus en plus de sites perdre des comportements web de base que les utilisateurs attendent
• Parmi les causes principales : la pression pour sortir vite, l'absence d'ingénieur UI, des conceptions mobile first tactile, et des implémentations qui remplacent le comportement natif du navigateur par du JavaScript
• La copie de texte, le clic droit sur les liens et ctrl + click, le zoom du navigateur, les mises en page responsives, :hover et :focus, la mise à jour de l'URL et de l'historique, les barres de défilement, ou encore les fonctions natives du navigateur comme ctrl + f doivent continuer à fonctionner normalement
• Dans les cartes cliquables, retirer pointer-events ou superposer des calques, ainsi que faire naviguer avec un div et on-click au lieu d'une ancre, casse l'expérience classique des liens
• Même si beaucoup de points recoupent des violations d'accessibilité, les web apps doivent préserver les fonctionnalités web ordinaires attendues par les utilisateurs plutôt que d'essayer de ressembler à des apps mobiles

---

Les comportements de base que les sites web ont perdus

• Il devient fréquent que des projets web bloquent des fonctionnalités web ordinaires que les utilisateurs considèrent comme acquises
• Avec l'essor de nouvelles plateformes sociales, de nombreux clients et apps sont créés, et beaucoup de projets tentent aussi de partager du code entre plateformes, comme avec React Native
• Ces tentatives sont positives en soi, mais il arrive qu'en plus d'exigences d'accessibilité de base comme le texte alt des images, les modes d'interaction ordinaires du web disparaissent aussi
• On peut notamment l'expliquer par :
  • la pression de livrer rapidement une version testable
  • l'absence d'ingénieur UI sur le projet
  • des conceptions qui privilégient l'entrée tactile mobile et ignorent les autres modes d'entrée ou appareils
  • des implémentations qui contournent ou remplacent le comportement natif du navigateur avec du JavaScript

Les fonctionnalités web ordinaires à préserver

• La copie de texte doit être possible
  • Dans des composants de carte cliquable, retirer pointer-events ou superposer une couche cliquable peut empêcher la sélection et la copie du texte
• Les éléments qui servent à naviguer comme des liens doivent conserver les fonctionnalités des liens
  • Il faut pouvoir ouvrir le menu contextuel par clic droit pour copier le texte du lien ou son adresse
  • Les raccourcis habituels pour ouvrir dans un nouvel onglet, comme ctrl + click sous Windows, doivent fonctionner
  • Il faut utiliser un élément d'ancre plutôt qu'un div avec on-click pour naviguer
• Le zoom du navigateur ne doit pas casser la mise en page, et l'utilisateur doit pouvoir zoomer pour lire
• Un site responsive ne doit pas basculer brutalement vers une simple mise en page mobile dès qu'il passe sous 1200 px, mais utiliser l'espace de manière appropriée même dans un viewport étroit
  • Mastodon et Twitter sont des exemples où l'interface reste familière quand on réduit la largeur du navigateur et où l'espace reste globalement bien exploité
• Une web app doit fournir correctement les états d'interaction comme :hover, :focus et :active
  • Dans certains portages d'apps React Native vers le web, il arrive qu'il n'y ait pas de style :hover ou :focus, ou qu'un style :active apparaisse de façon étrange comme s'il s'agissait d'un état désactivé
• Si après un clic l'interface change entièrement comme s'il s'agissait d'une nouvelle page, l'historique du navigateur et l'URL doivent aussi être mis à jour
  • Si l'on ne peut pas créer de lien vers un état d'interface qui ressemble à une page indépendante, et que cet état disparaît après navigation, l'utilisabilité se dégrade
• Les barres de défilement ne doivent pas être masquées
  • Certains utilisateurs peuvent vouloir cliquer et faire glisser la barre de défilement
• Les raccourcis standard du navigateur ne doivent pas être détournés par des fonctions internes à l'app
  • Si ctrl + f ouvre un champ de recherche personnalisé dans l'app, la recherche dans la page peut cesser de fonctionner comme d'habitude
• Beaucoup de ces points recoupent des problèmes d'accessibilité, mais l'enjeu ici est d'éviter que les web apps ne brisent les attentes de base des utilisateurs vis-à-vis du navigateur
• D'autres exemples oubliés peuvent être partagés sur Mastodon

[plastic041]

Il semble que le contenu principal soit erroné.

[xguru]

Oh, c’est curieux. Il semble que le crawling de cet article de blog lui-même se fasse de manière un peu étrange.
Il va falloir jeter un œil à la partie du crawler.

[GN⁺]

Avis sur Hacker News

• Si l’on apprend d’abord le web avec React et seulement ensuite HTML, on finit parfois par ne plus se soucier du comportement par défaut des liens
  Quand j’ai rejoint mon équipe, tous les liens étaient des boutons, des éléments arbitraires ou étaient gérés avec onClick, et personne ne s’en plaignait, mais Ctrl+clic ne servait à rien et le menu contextuel n’offrait pas les options attendues
  À mon avis, sur les liens, il n’y a pas de marge de négociation

  • Je déteste vraiment cet abus de JS, qui casse de plus en plus de choses qu’il faudrait faire correctement
    Même archbee, une plateforme de documentation financée par YC, ne permet pas d’ouvrir les résultats de recherche dans un nouvel onglet : il faut en ouvrir un dans l’onglet courant, sinon revenir en arrière, refaire la recherche et ouvrir le résultat suivant
    On peut voir l’exemple ici : https://docs.sparklayer.io/
  • Dans la nouvelle version web de Reddit, tous les liens sont des boutons, donc impossible de les ouvrir dans un nouvel onglet
    C’est vraiment étrange, et ça rend fou, qu’un service Internet aussi énorme ait un problème d’accessibilité aussi évident
  • C’est à peu près la moitié des raisons pour lesquelles j’utilise nitter au lieu de Twitter
    Il y a aussi le fait qu’il ne nécessite pas de compte, mais on peut faire un clic droit sur un fil de tweets et l’ouvrir dans un nouvel onglet
    Vu la nature des conversations sur Twitter, on veut souvent ouvrir plusieurs fils dans de nouveaux onglets tout en gardant sa position sur la page d’origine, mais l’UI réelle de Twitter rend cela très difficile
  • Le problème des liens est une colline sur laquelle je suis prêt à mourir à tout moment
    Peu de choses m’agacent davantage ; à la rigueur, il y a le fait de casser l’historique du navigateur
  • Sur un site avec une vue liste et une vue détail, ne pas pouvoir faire un clic droit sur un élément, ou utiliser une extension, pour ouvrir la vue détail dans un nouvel onglet est une catastrophe pour l’usage du web
    Si le retour arrière fonctionnait instantanément et de façon fluide, ce serait encore pardonnable, mais en pratique on attend que le contenu se recharge et on perd aussi sa position de défilement
    Pire encore, certains sites comme Facebook imposent le même état de fenêtre de chat contextuelle sur plusieurs onglets. Si on la ferme dans un onglet, elle se ferme aussi dans les autres, alors qu’on a ouvert plusieurs onglets pour une raison

• À partir du moment où l’on touche au comportement fourni par défaut, on en assume aussi la responsabilité
  La “fonctionnalité” créée ne se limite pas au périmètre étroit imaginé par son concepteur : elle devient l’ensemble de l’expérience réellement vécue par le visiteur
  Si l’on change la logique du bouton retour, on change le sens même que le retour arrière fournit sur ce site, et il faut aussi assumer les utilisateurs confus et en colère qui traiteront le site de « cassé »
  Il faut se demander si l’on est vraiment prêt à assumer jusqu’aux comportements qui diffèrent selon les navigateurs et les systèmes d’exploitation, comme les barres de défilement
  Au final, on fait parler au site web une sorte de créole ; il n’y a donc rien d’étonnant à ce que le visiteur ne comprenne pas cette langue ou l’« interprète mal »
  Ces fonctionnalités ne sont pas seulement à éviter par bienveillance envers le visiteur : les gains semblent limités et les pertes presque illimitées

  • C’est exact. Les sites web bénéficient de conventions de design affinées au fil du temps
    Les sites qui ignorent ces conventions deviennent plus difficiles à utiliser parce qu’ils ne parlent pas la langue à laquelle les utilisateurs sont habitués
    Il existe aussi un long article sur la perte des conventions de design : https://loeber.substack.com/p/4-bring-back-idiomatic-design

• Je vois cela comme l’appification des sites web, et il faut maintenant arrêter
  Les sites web devraient revenir au rendu côté serveur et n’ajouter que la quantité de JavaScript nécessaire
  À l’inverse, les apps web peuvent se permettre de travailler un peu plus l’UX si cela apporte de la valeur à l’utilisateur, mais tant qu’elles sont dans le navigateur, les principes de base s’appliquent toujours
  Je soutiens les apps web parce qu’elles constituent une plateforme de développement accessible à tous en dehors des murs des app stores, mais il faut arrêter de traiter tous les sites web comme des apps
  Si une page veut apparaître dans les résultats des moteurs de recherche, ce n’est pas une app web, c’est un site web

  • Ce serait bien que le navigateur puisse envoyer Accept: text/markdown pour les documents bruts, mais à mon avis ce navire a pris le large dès l’apparition de CSS
  • Cet article pourrait vous plaire : https://notan.app/
  • Je suis d’accord avec l’idée que « les sites web devraient revenir au rendu côté serveur avec un peu de JS »
    Heureusement, grâce à des choses comme React Server Components, on semble revenir vers une approche où l’on ajoute progressivement du JavaScript aux sites web, et c’est une bonne chose
  • Une bonne app web peut aussi être un site web
    C’est un problème qui peut se résoudre avec suffisamment de temps

• Je ne comprends pas pourquoi les sites bancaires bloquent le coller
  Quand on se rend compte qu’on ne peut pas coller, on a déjà copié le texte
  La saisie à la main provoque plus facilement des erreurs, et si le presse-papiers est contaminé, au moment où l’on découvre l’interdiction de coller, la copie est déjà faite

  • On a l’impression qu’un endroit du genre « Introduction à la programmation de formulaires » contenait du code pour empêcher le copier-coller, et que ce concept a laissé des milliers de descendants partout sur le Web
    On dirait que les gens imaginent que c’est une mesure de sécurité et le recopient de leur plein gré
    Je ne comprends même pas pourquoi on empêcherait l’utilisateur de coller au départ
  • Le site de ma banque ne se contente pas de bloquer le collage du « mot de passe » : il bloque aussi la saisie au clavier
    Ce « mot de passe » n’est qu’un nombre à 6 chiffres, et je ne peux même pas le définir moi-même. Comme si 6 chiffres étaient bien plus sûrs qu’une chaîne aléatoire de 16 caractères générée par un gestionnaire de mots de passe
    La page oblige à le saisir via des boutons placés aléatoirement ; mais si l’appareil est déjà infecté au point que les frappes et les clics sont enregistrés, il me semble que l’attaquant peut aussi simplement lire le mot de passe dans la mémoire du navigateur
  • Il y a quelques jours, je me suis inscrit chez un nouveau FAI, et le champ de mot de passe bloquait le collage, ce qui a cassé mon gestionnaire de mots de passe
    Du point de vue de la sécurité, c’est une décision incroyablement mauvaise
  • En général, ça commence quand une entreprise a un problème de trafic de bots
    Elle essaie diverses choses pour gêner les bots, puis un jour des développeurs poussés par un cadre intermédiaire empêchent le copier-coller sur la page de connexion, et les bots s’arrêtent un moment
    Quelques jours plus tard, les bots contournent la mesure, mais le « correctif » précédent reste en place avec l’idée que « ça bloquera peut-être certains bots »
    C’est ainsi qu’une dizaine de lignes de JavaScript survivent jusqu’à la réécriture v6, puis quelques mois ou années après un nouveau départ, la même interdiction revient
    Je ne parle absolument pas d’expérience
  • Je ne dis pas que c’est le cas ici, mais il a bien existé des malwares de presse-papiers qui, lorsqu’un contenu copié ressemblait à une adresse Bitcoin, le remplaçaient par leur propre adresse
    https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
    Ils avaient peut-être ce genre de menace en tête

• Ce qui m’agace, c’est quand des développeurs JS flamboyants cachent de la complexité et des fonctionnalités que personne n’a demandées derrière des menus select qui ressemblent à du HTML natif
  Je le vois souvent pour la saisie de la ville et de l’État : la ville est un champ texte, et l’État un menu déroulant/select
  Comme je suis texan, je saisis la ville, je vais au choix de l’État avec Tab, puis j’appuie sur t, t avant de passer à l’élément de formulaire suivant
  Mais de nos jours, il s’agit souvent d’un champ de recherche texte déguisé en menu déroulant, donc t, t ne sélectionne pas Texas après Tennessee : cela lance littéralement une recherche sur tt
  Ça ne fonctionne comme prévu que pour les gens qui cliquent à la souris sur le petit triangle et font défiler la liste des États
  Si ce n’est pas cassé, il ne faut pas le réparer

  • Ce problème venait surtout d’un trou dans la plateforme Web
    Historiquement, un vrai <select> était très difficile, voire impossible, à styliser ou à étendre dans son comportement, si bien que beaucoup d’apps l’ont réimplémenté elles-mêmes, généralement très mal
    Il semble que de nouveaux remplaçants intégrés et stylables arrivent
    Et comme le partage de code entre apps, frameworks et entreprises était difficile, seules les grandes entreprises pouvaient créer des remplaçants de composants intégrés avec toutes les fonctionnalités, l’accessibilité et la personnalisation nécessaires
    Les Web Components peuvent résoudre ce problème en permettant une collaboration mondiale sur des composants terminaux courants comme <select>
    Article lié : https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

• Je pense qu’une bonne partie des comportements de liens cassés vient du manque de méthodes de plus haut niveau pour remplacer le comportement par défaut des liens
  Par exemple, je n’ai pas envie d’attacher un listener d’événement de clic pour ouvrir un lien dans une modale. L’événement de clic est d’un niveau trop bas, il faut vérifier soi-même les touches modificatrices
  Ce que l’on veut vraiment, c’est dire au navigateur : « si l’URL de la fenêtre actuelle est sur le point de changer à cause de cet élément d’ancre, appelle plutôt cette fonction »
  Ainsi, l’utilisateur peut librement ouvrir le lien dans une nouvelle fenêtre ou un nouvel onglet, et dans ce cas mon code ne s’exécute pas
  Même chose pour CSS : je n’ai pas envie de définir une image de curseur pour chaque élément et pseudo-classe. Je veux dire : « là où tu aurais utilisé le curseur par défaut main/attente/redimensionnement, utilise cette image personnalisée »
  Ainsi, même si de nouveaux éléments ou de nouvelles UI apparaissent, le code reste robuste pour l’avenir
  Certaines API de navigateur semblent parfois souffrir du problème XY

  • C’est tout à fait possible en JavaScript
    Il suffit d’enregistrer un onclick sur la balise et d’annuler la navigation par défaut dans le gestionnaire d’événement
    Si l’utilisateur désactive JavaScript, le site continue de fonctionner correctement, et les comportements intégrés du navigateur comme le menu contextuel du lien ou Ctrl+clic fonctionnent aussi tels quels
    Cela dit, c’est un « truc » assez obscur ; ce serait bien que l’API DOM le rende plus simple
  • https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
    Je pense que c’est un cas d’usage de la Navigation API
  • J’ai enfin vu quelqu’un exprimer mon idée en ligne
    Il nous faut un événement visit de haut niveau, pas des événements de clic ou de pointeur

• Quand j’ai vu Flutter Gallery pour la première fois, j’ai été surpris d’avoir l’impression que tout était cassé dans le navigateur Web : https://gallery.flutter.dev
  Je crois que c’était particulièrement le cas avec l’exemple Reply
  Ctrl+clic ou le bouton du milieu sur les liens ne fonctionnaient pas, le clic droit non plus, la sélection et la copie de texte non plus, l’inspection des éléments était impossible à cause de la structure technique, et tenter de zoomer dans la page ne faisait rien
  En repensant à cette expérience, ainsi qu’à certaines implémentations de SPA faites avec des technologies plus traditionnelles, cet article me paraît viser juste

  • Flutter est une autre impasse sur la voie des frameworks de développement unifiés
    Que ce soit sur le Web ou sur mobile, aucune démo Flutter ne m’a jamais convaincu qu’elle offrait une UX acceptable
  • Même dans les navigateurs mobiles, il semble gérer bizarrement la sélection de texte
    Si la promesse de Flutter est d’être identique partout, cette démo sera tout aussi mauvaise sur desktop

• J’aimerais aussi que le comportement de défilement ne soit pas remplacé
  Il ne faut pas chercher à l’améliorer pour rendre le défilement « plus fluide »
  Sous Windows, cela peut sembler correct, mais sur Mac avec un périphérique d’entrée Apple, le mouvement du doigt sur le trackpad ou la souris correspond 1:1 au mouvement de l’élément qui défile
  Ce genre d’« amélioration » donne généralement l’impression de faire défiler quelque chose dans de la mélasse
  En règle générale, il ne faut pas essayer d’améliorer le comportement par défaut du navigateur

• L’une des choses que je déteste dans le Web moderne en vrac, c’est de toucher à l’History API
  Quand on clique sur un lien qui a l’air intéressant depuis un endroit comme HN, qu’on arrive sur la page et qu’on fait défiler, chaque en-tête, voire chaque élément sans grande importance, ajoute une entrée à l’historique
  Pour revenir au site d’origine, il faut appuyer sur retour à peu près un million de fois
  Je déteste tous ceux qui font ça

  • J’aimerais ajouter à cela le défilement infini
    Utilisez simplement une pagination
    Elle est partageable par lien, recherchable, navigable, et fonctionne correctement avec l’historique
    Le défilement infini casse tout cela sans grande raison

• Il y a en fait ici deux problèmes aussi vieux que le Web : des attentes trop basses et l’absence de standards ou de critères définissant les personnes et les pratiques
  Aujourd’hui, les offres d’emploi disent toutes « Senior Fullstack Engineer », mais quand on regarde, ce qu’elles recherchent réellement est souvent une combinaison de Java ou Python, R, Spring et SQL
  Si ce n’est pas du fullstack, l’écrire ainsi fait perdre du temps aux gens et envoie au public le signal que vous ne comprenez pas la technologie, ou que vous ne vous en souciez pas
  En programmation, on appelle cela le « problème X/Y » : un antipattern où il faudrait résoudre l’état final souhaité X, mais où l’on ne parle à la place que de l’approche Y que l’on veut adopter
  Résultat, un employeur reçoit 500 CV pour une offre et a malgré tout l’impression que personne ne convient
  Le point de départ devrait être l’objectif : « Nous recrutons pour construire ce type d’application client/serveur ; le candidat devra écrire et prendre en charge les fonctionnalités X, Y, Z, avec les contraintes A, B, C », par exemple
  Si les entreprises n’y arrivent pas, c’est généralement parce qu’elles ne savent pas vraiment ce qu’elles font et qu’elles se traînent déjà une technologie abîmée après avoir emprunté plusieurs mauvaises voies. C’est pour cela qu’on appelle cela de la dette technique
  Quand l’objectif est ainsi clair, l’entreprise comme le candidat savent quoi vérifier pendant l’entretien et peuvent se filtrer mutuellement de manière appropriée. Sinon, cela devient un processus atroce, à mi-chemin entre un rendez-vous arrangé et un jeu télévisé
  Par exemple, on peut préciser qu’on recrute pour créer une application de conférence média hautement distribuée, que le développeur devra écrire du TypeScript, raccorder en pipeline des données de flux provenant de sockets, travailler à la fois côté navigateur et côté serveur, et écrire de l’automatisation de tests
  Les contraintes opérationnelles incluent la conformité WCAG AA, une checklist de conformité à la confidentialité établie par l’équipe juridique, ainsi que des considérations de performance visant la vitesse d’exécution et la latence réseau ; le candidat idéal devra montrer en entretien des solutions pour la latence réseau, la logique d’application dans le navigateur et la gestion d’état de données en streaming