2 points par GN⁺ 2023-10-14 | 1 commentaires | Partager sur WhatsApp
  • À mesure que les barres de défilement deviennent plus petites ou masquées, elles posent de vrais problèmes d’utilisabilité non seulement aux personnes qui ont du mal à utiliser la molette ou les gestes tactiles, mais aussi à celles qui veulent se déplacer rapidement dans un document
  • Les personnes qui ont des difficultés de contrôle moteur fin, ou qui utilisent des dispositifs de pointage à précision limitée comme les eye trackers, peinent à viser une barre de défilement de 8 pixels de large ; les utilisateurs de commande vocale préfèrent eux aussi cliquer directement à l’endroit voulu plutôt que de répéter des commandes de défilement
  • Dans GTK, Qt, Firefox, Chrome et Electron, même lorsqu’il est possible d’ajuster la largeur ou le mode d’affichage des barres de défilement, cela dépend de méthodes difficiles d’accès pour le grand public, comme des modifications CSS, gsettings, about:config, la recompilation de thèmes ou des réglages propres à chaque application
  • Autrefois, il existait des boutons de défilement qui faisaient avancer petit à petit tant qu’on les maintenait enfoncés, mais ils ont disparu discrètement ; les touches fléchées remplacent une partie de cette fonction, mais leur comportement varie selon l’état du focus
  • Une interface de type minimap de document, permettant de voir le contenu et de se déplacer via une grande zone cliquable, peut constituer une méthode de navigation alternative utile aussi pour les utilisateurs d’eye trackers et de stylets de tablette

Des barres de défilement plus petites et masquées

  • La barre de défilement est une UI de base qui permet de cliquer-glisser pour changer la position courante dans une zone défilable
  • Récemment, les barres de défilement sont devenues si petites qu’il est même difficile de les montrer dans une capture d’écran, et la tendance à les réduire encore ou à les masquer nuit à l’utilisabilité
  • L’approche consistant à dire « il suffit d’utiliser la molette » suppose que tous les utilisateurs peuvent utiliser une molette de souris ou un balayage sur écran tactile
  • Même les personnes qui utilisent bien la molette peuvent parfois vouloir sauter rapidement à un emplacement précis

Effets sur l’accessibilité

  • Les utilisateurs ayant des difficultés de contrôle moteur fin ont du mal à saisir précisément une barre de défilement fine
  • Les dispositifs de pointage comme les eye trackers sont impressionnants, mais insuffisants pour viser de manière fiable une barre de défilement de 8 pixels de large
  • Les personnes qui contrôlent leur ordinateur à la voix ou au son peuvent utiliser des outils comme Talon Voice, mais préférer voir l’emplacement voulu dans la barre de défilement et cliquer dessus plutôt que de répéter scroll down ou d’utiliser le défilement automatique
  • Dès 2015, le problème de largeur des barres de défilement GTK3 était discuté ; les barres de défilement fines imposent une charge aux utilisateurs non techniques ainsi qu’aux personnes ayant des difficultés de manipulation ou de vision

Comment les barres de défilement sont devenues moins faciles à utiliser

  • Dans certains cas, la largeur de la barre de défilement est restée identique en pixels, mais l’augmentation de la résolution des écrans a rendu la cible réelle plus petite
  • Dans d’autres cas, la barre de défilement elle-même est effectivement devenue plus petite
  • Le cas des barres de défilement très fines qu’Ubuntu avait autrefois tenté d’introduire est également mentionné
  • Pendant que les barres de défilement rétrécissaient, les boutons de défilement, qui permettaient de se déplacer petit à petit en les maintenant enfoncés, ont eux aussi disparu
    • Les touches fléchées remplacent une partie de cette fonction, mais dépendent du contenu qui a actuellement le focus
    • Les boutons pouvaient être utilisés indépendamment de l’état du focus
  • Dans l’ensemble, les barres de défilement sont devenues moins utilisables, et les réglages permettant de corriger cela sont inexistants ou enfouis dans des piles techniques difficiles à trouver pour le grand public

Les obstacles côté réglages GTK

  • Dans GTK2, il était possible de modifier directement la largeur des barres de défilement dans gtkrc, et il existait aussi des programmes GUI pour le faire
  • Dans GTK3, il faut passer par CSS ; sans comprendre les thèmes, il manque une méthode de configuration conviviale
  • Un fil Reddit présente un script qui ajoute slider { min-width: ...; min-height: ...; } à gtk.css pour GTK3 et GTK4, tout en gérant les overrides Flatpak et le réglage d’overlay scrolling
  • Les applications Flatpak peuvent nécessiter un override séparé, si bien que le thème système ne s’applique pas forcément tel quel
  • GTK utilise aussi par défaut un mode où la barre de défilement est masquée puis affichée lorsqu’on passe la souris à son emplacement
    • Dans GTK3, on peut l’afficher en permanence avec la commande suivante gsettings set org.gnome.desktop.interface overlay-scrolling false
    • Elle est aussi trouvable dans Dconf Editor, mais il faut connaître son emplacement
  • Un fil GNOME Bugzilla est cité pour indiquer que, dans GTK4, ce réglage ne peut pas être défini globalement
    • La discussion souligne le problème d’une situation où il faut demander une option de barre de défilement non overlay pour chaque application

Les obstacles côté réglages Qt

  • La largeur des barres de défilement Qt est déterminée par le plugin de style de widgets Qt utilisé
  • Dans une réponse sur r/kde, /u/cfeck_kde explique qu’à sa connaissance seul le style Skulpture permet de régler la taille, tandis que les autres styles comme Breeze nécessitent de modifier le code source C++ puis de recompiler
  • Les plugins de style Qt sont du vrai code, ce qui permet un contrôle puissant, mais il faut trouver un plugin qui expose le réglage voulu
  • Kvantum rend le réglage de largeur de barre de défilement difficile à trouver, mais permet de désactiver la fonctionnalité de disparition des barres de défilement appelée « Transient scrollbars »
  • Skulpture mérite d’être essayé, mais aucune méthode de configuration via GUI sans KDE Plasma n’a pu être confirmée
  • S’il faut dépendre d’un seul moteur de thème, l’inquiétude demeure quant à sa maintenance au fil de l’évolution de Qt

La situation dans Firefox, Chrome et Electron

  • Firefox utilise lui aussi des barres de défilement très petites, mais elles peuvent actuellement être ajustées dans about:config
    • Saisir about:config dans la barre d’adresse
    • Modifier widget.non-native-theme.scrollbar.size.override avec la valeur souhaitée
    • Modifier widget.non-native-theme.scrollbar.style pour changer l’apparence
    • La valeur 4 donne une forme rectangulaire épaisse
    • Dans la fenêtre des réglages généraux about:preferences, on peut activer « Always show scrollbars »
  • Par exemple, on peut définir la taille de la barre de défilement de Firefox à 50 ; même si l’on ne souhaite pas vraiment l’utiliser aussi grande, le fait de pouvoir l’agrandir est un avantage
  • L’article d’Athena Lilith Martin sur les réglages supplémentaires des barres de défilement dans Firefox couvre d’autres améliorations, comme la désactivation des overrides CSS des pages web
  • Chrome est jugé peu susceptible de fournir des réglages utiles
  • Les applications Electron sont également difficiles à configurer, et il n’est pas certain qu’une injection de CSS personnalisé permette de corriger le problème ; aucune solution claire n’est proposée

Une meilleure méthode de navigation : la minimap

  • Une minimap permet de voir le contenu, de cliquer sur le contenu et de se déplacer vers l’emplacement du contenu cliqué
  • Comme la cible de clic est très grande, elle est également utile aux utilisateurs d’eye trackers et de stylets de tablette
  • Les « principes de design moderne » courants jouent en défaveur des barres de défilement et des personnes qui utilisent l’ordinateur de différentes manières

1 commentaires

 
GN⁺ 2023-10-14
Avis sur Hacker News
  • Ce n’est pas seulement un problème de barres de défilement. À cause de la suppression des bordures de fenêtre, il devient impossible de distinguer une fenêtre d’une autre au fond de couleur similaire, et presque impossible d’attraper un bord pour redimensionner la fenêtre.
    La barre de titre est remplie d’un champ de recherche et de boutons inutiles, si bien qu’il ne reste presque aucun endroit à saisir pour déplacer la fenêtre, et la navigation au clavier avec Tab entre les champs de texte ne fonctionne pas comme prévu, voire pas du tout.
    Les infobulles gênent l’interface et l’encombrent, elles masquent souvent ce qu’on veut voir, et dans 95 % des cas elles donnent des informations redondantes ou inutiles.
    Ces dix dernières années, le UI/UX de type culte du cargo a abandonné des décennies de principes d’utilisabilité accumulés, pour produire quelque chose qui a seulement l’air joli mais ne fonctionne pas correctement pour beaucoup de gens.
    Des apps comme Postman, Teams, la plupart des apps Microsoft actuelles, Chrome ou Insomnia devraient servir d’exemples de ce qu’il ne faut pas faire pour concevoir l’UI d’un logiciel desktop.
    Le péché le plus grave, c’est que ces éléments ne poseraient pas problème s’ils étaient configurables au niveau du système de fenêtrage et impossibles à remplacer par les développeurs d’apps ; or Windows et Gnome/GTK vont au contraire dans le sens de la suppression des options existantes.

    • Je trouve que le terme « imbéciles » est approprié. Je n’ai pas envie d’insulter gratuitement les gens qui travaillent, mais aujourd’hui, pour déplacer une fenêtre, il faut cliquer partout comme un idiot pour comprendre si l’on est sur la barre de titre ou sur un bouton.
      À chaque lancement de « New Teams », on me demande si je veux revenir à Old Teams, et quand j’ouvre un PDF avec New Teams depuis l’Explorateur de fichiers, il n’est même pas clair comment fermer le PDF sans perdre son emplacement dans le système de fichiers.
      En plus, tout est atrocement lent. Un nombre non négligeable de personnes chez Microsoft/Apple/Google ne savent pas faire leur travail, et elles devraient en avoir honte.
    • J’ai l’impression que Windows XP a été le sommet des interfaces utilisables, et qu’il aurait fallu s’arrêter là. Bien sûr, c’est peut-être juste moi qui vieillis et qui crie aux gamins de quitter ma pelouse.
      Pour Windows, en tout cas, c’est clairement le cas à mes yeux, et toutes les versions suivantes ont dégradé l’expérience utilisateur.
    • Je ne pense pas que les insultes soient nécessaires. L’une des raisons pour lesquelles j’aime HN, c’est que c’est l’un des rares endroits où la discussion courtoise passe avant le ton haineux qu’on trouve sur d’autres plateformes.
      Je suis fondamentalement d’accord pour dire que l’utilisabilité est plus importante que l’esthétique, mais je ne sais pas exactement qui désigne l’expression « imbéciles du UI/UX de type culte du cargo ».
      Ayant travaillé plus de 20 ans comme responsable UX/UI, j’ai souvent constaté que les principaux responsables de la dégradation de l’utilisabilité étaient davantage les dirigeants métier et les marketeurs que les designers.
      Bien sûr, certains designers pensent que la forme prime sur la fonction et imposent de petites barres de défilement, mais quand on leur explique le problème, ils reculent souvent et produisent un design utilisable.
      Les dirigeants de niveau C, les responsables marketing et les managers sont plus dangereux, parce qu’ils connaissent mal l’UI tout en ayant des avis très tranchés, avec des demandes du genre « j’aime la barre de défilement de ce site web » ou « le design n’a pas l’air moderne ».
      Se battre pour préserver l’utilisabilité et l’accessibilité est extrêmement pénible, et certains niveaux hiérarchiques devraient agir de façon plus professionnelle et faire confiance aux experts. Les designers, eux aussi, doivent évidemment mettre l’utilisabilité en premier.
    • Le problème plus vaste, c’est qu’il n’y a désormais presque plus aucune tentative de structurer l’information.
      Les menus de paramètres sont un cauchemar de listes empilées sur d’autres listes, la structure des menus est totalement aléatoire d’une app à l’autre, et même des choses qui pourraient être réglées en local renvoient souvent vers un lien externe.
      Il est vraiment difficile de comprendre l’intention du designer, et on ne sait pas si l’on n’a simplement pas trouvé le réglage ou s’il a été délibérément exclu de ce menu.
      J’ai dû chercher sur Google bien trop souvent pour changer un réglage par défaut, et c’est pareil même dans les jeux, où l’expérience représente la moitié de la valeur du produit.
      Dans le menu de paramètres de CS2, les boutons textuels en haut ressemblent à des onglets, mais en réalité ils ne font que faire défiler une longue liste de paramètres jusqu’à un point arbitraire, ce qui rend difficile de séparer mentalement ce que signifie chaque bouton.
      Le sens des concepts n’est pas relié ni structuré, ce qui rend l’exploration de l’informatique inutilement beaucoup trop difficile.
      L’UI de Macromedia Flash me manque ; je ne l’ai pas beaucoup utilisée, mais elle était vraiment simple et facile à prendre en main.
      L’une des grandes raisons qui me poussent à rechercher la confidentialité et des solutions faites maison, c’est aussi de vouloir échapper à cette pollution de l’expérience et du savoir qu’on voit aujourd’hui.
    • C’est précisément pour cela qu’existait la case de redimensionnement. En réalité, le bord déplaçable n’a pas de chair, si bien qu’on a surchargé un élément d’un pixel avec trop de rôles, créant des conflits.
      L’ancienne case de redimensionnement était une poignée séparée dédiée au redimensionnement de la fenêtre, située tout en bas de la barre de défilement verticale, juste sous le bouton fléché du bas.
      Comme elle se trouvait juste à côté du bouton de défilement permettant de voir le contenu non visible au départ, elle faisait presque office de point de départ naturel et de repère pour interagir avec le viewport.
      Ironiquement, elle a disparu de la plupart des UI d’applications, mais les navigateurs web la rendent encore parfois sur des éléments comme textarea lorsque la barre de défilement et le redimensionnement sont activés. Cela dit, dans la plupart des UI, les boutons de défilement associés n’existent plus.
  • J’ai eu une prise de conscience amusante récemment. Ce n’est pas ma vue qui s’est dégradée, c’est l’UI qui s’est dégradée
    Les minuscules barres de défilement au contraste ridiculement faible ne sont accessibles à personne
    J’ai récemment commencé à utiliser KDE avec le thème Oxygen, et c’est un plaisir parce qu’il est agréable à utiliser sans fatigue oculaire
    Ce genre de barre de défilement est une chose lamentable, sans aucune possibilité de personnalisation, et il faut beaucoup de chance pour appliquer un thème aux apps verrouillées
    Il est trop évident que les designers UI ne se soucient pas des besoins des utilisateurs, et le monde FOSS ne fait pas exception
    Il est triste d’être passé d’une époque où les logiciels étaient beaux, fonctionnels, accessibles et rapides, à des saletés Electron verrouillées et impossibles à thèmer
    Si les UI avaient eu suffisamment de contraste et de lisibilité, on n’aurait même pas eu besoin de choses comme le « mode sombre »

    • Je n’utilise pas le mode sombre pour le contraste, mais parce que le mode clair de beaucoup de logiciels est tout simplement blanc pur. Les écrans sont devenus de plus en plus lumineux et puissants
      Quand j’utilise un logiciel sans mode blanc, il est souvent si lumineux que le mur voisin paraît éclairé par une lampe de poche
      Donc je baisse la luminosité de l’écran, mais les couleurs et le contraste deviennent catastrophiques et je ne vois toujours rien
      Les interfaces grises de l’époque Windows 9x me manquent ; elles n’étaient pas jolies, mais on pouvait vraiment les regarder
    • Le contraste joue aussi, mais la mode de l’UI plate a évincé les gris moyens et les gris clairs pour imposer du blanc éclatant et du quasi-blanc, ce qui a rendu le mode clair bien plus éblouissant qu’avant
      Il n’est pas du tout étonnant que les gens aient réclamé un mode sombre après la domination de ces UI plates éblouissantes
    • J’aimerais qu’il y ait davantage de contrôles analogiques dans le monde numérique. Des boutons rotatifs au lieu de boutons haut/bas sur 10 niveaux
      Les commandes manuelles numériques, où l’on quitte facilement un menu puis, en essayant d’y revenir, on règle tout autre chose, sont devenues trop numériques et pénibles
      Avant, il était facile de régler le contraste et la luminosité d’un écran, le volume d’un ampli, une TV analogique, un thermostat, un autoradio, etc.
      On ne voit pas encore vraiment de mouvement pour réintroduire beaucoup de contrôles analogiques, mais au fond, notre monde est analogique. Les entrées le sont, avec la parole, les mouvements musculaires, etc., et les sorties aussi, comme la lumière et les vibrations qui touchent nos sens
      Je ne comprends pas pourquoi les contrôles ne sont pas plus analogiques ; c’est probablement une question de coût
      Un écran ou un ordinateur portable avec des contrôles analogiques, je l’achèterais tout de suite. Même si, en réalité, c’était un cadran à 16 millions de niveaux, ça suffirait s’il réagissait instantanément et donnait la sensation d’un vrai potentiomètre
      Ce serait bien d’avoir un bouton permettant, selon le contexte, de changer rapidement l’intensité ou de parcourir les options pour rendre les choses plus faciles à lire et à écouter
      Comme 90 % de ce qu’on fait aujourd’hui se passe dans le navigateur, ce serait bien que le navigateur fournisse une API d’accessibilité permettant de le contrôler avec un bouton rotatif, en Bluetooth ou autre. Une sorte de molette de défilement améliorée
    • Le nouveau mouvement « don’t theme my app » est particulièrement regrettable. Le problème des feuilles de style CSS de GTK devrait être résolu en remplaçant CSS par une meilleure technique de stylisation, pas en jetant tout et en empêchant l’utilisateur d’utiliser son propre thème
    • Je pense qu’il y a environ 20 ans, à l’époque Windows 2000, l’utilisabilité a atteint son sommet. Les captures d’écran de l’article semblent d’ailleurs dater à peu près de cette période, des débuts d’OS X 10.x, probablement autour de 10.3
  • Je tombe souvent sur des sites web avec des popovers défilants ou d’étranges cadres internes, où la barre de défilement du petit cadre interne est masquée ; on ne peut donc pas savoir s’il y a davantage de contenu, et on finit par penser que le site est complètement cassé
    C’est vraiment exaspérant, et j’en viens à blâmer iOS et macOS pour avoir encouragé et popularisé cette folie. La mode de l’UI « plate », qui a rendu difficile de deviner ce qui est quoi, porte aussi une responsabilité indirecte
    L’UI est une forme de communication, et les designers UI ont décidé que marmonner était cool

    • Dans le contexte originel de l’iPhone, masquer les barres de défilement quand on ne fait pas défiler avait un certain sens. L’écran faisait 3,5 pouces, on visait l’affichage de contenu de niveau desktop, il n’y avait pas beaucoup de place pour une barre de défilement, et la plupart des gens n’allaient pas interagir avec la barre elle-même
      En revanche, sur un système d’exploitation desktop, même les plus petits écrans utilisés sont beaucoup plus grands, donc il y a peu de bonnes raisons de masquer les barres de défilement
    • Au risque de détourner ce fil de récriminations dans une direction encore plus inflammable, c’est peut-être une imitation de ce qui se fait aujourd’hui dans les films et la TV
      Même quand les enfants sont calmes, dorment ou sont à l’école, beaucoup de films et de séries actuels sont difficiles à regarder sans sous-titres
    • Je ne comprends même pas comment cette UI plate a pu devenir à la mode
  • Il faut encore une fois féliciter Firefox de fournir, dans about:config, des outils permettant de désactiver ce genre de choses. Dans le meilleur des cas, c’est une décoration mignonne ; dans le pire, c’est agaçant et abusif
    L’UI du navigateur devrait être presque entièrement exclue de ce que les sites web peuvent modifier, et les barres de défilement en font partie

    • À l’inverse, Chrome m’a fait beaucoup rire avec son « imaginez pouvoir configurer quelque chose d’utile dans Chrome »
      L’ensemble de l’article est très bien écrit, et je salue son auteur
      Moi aussi, je suis revenu à Firefox parce qu’Edge continuait à me pousser la recherche Bing et d’autres fonctionnalités, et même l’invite de restauration des onglets était trop pénible. Qu’il se taise et arrête, tout simplement
    • Je garde un souvenir très vif d’avoir défendu bec et ongles, sur des forums du début des années 2000, la fonctionnalité de stylisation des barres de défilement d’IE6. À l’époque, le camp Mozilla la qualifiait d’abomination
      Maintenant que je suis plus âgé, avec à la fois le recul nécessaire et la faiblesse d’une vue qui a baissé, je peux admettre que j’avais tort. C’est beaucoup trop facile à détourner
    • Il faut aussi ajouter le défilement fluide à cette liste. Que l’on fasse défiler avec la molette de la souris ou que l’on passe d’un mot trouvé par Ctrl-F à un autre, c’est pareil
      Heureusement, on peut le remplacer avec uBlock Origin
    • Le vaste écosystème d’auteurs d’extensions mérite lui aussi des éloges. À la fin, l’auteur salue la barre latérale en minimap comme une amélioration des barres de défilement existantes, et en fait, cela existe déjà
      https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
    • Cela fonctionne aussi sur mobile, mais il faut chercher l’incantation exacte pour passer outre
      Je pense que c’est probablement celle-ci
      <https://www.makeuseof.com/change-firefox-scrollbar-style/>
  • L’auteur voit la moitié du problème, mais propose la mauvaise moitié de la solution
    La barre de défilement n’est pas seulement un contrôle, c’est aussi un indicateur de position. Elle montre où se trouve la fenêtre d’affichage actuelle dans une vue plus grande, comme une longue liste
    Masquer la barre de défilement, comme dans certaines interfaces graphiques telles que macOS, est très discourtois, un peu comme rendre les boutons impossibles à distinguer du texte ou mettre du texte gris clair sur un fond gris clair
    La solution existe déjà et elle est implémentée presque partout : la molette de la souris et les gestes de défilement du trackpad
    Il est très rare qu’une vue puisse défiler avec une barre de défilement, mais pas avec le geste standard du trackpad ou la molette de la souris. Ma souris permet aussi le défilement horizontal avec la molette, tout comme les contrôles TrackPoint
    Pour ce type de défilement, le pointeur n’a même pas besoin d’être au-dessus de la barre de défilement ; il suffit qu’il soit au-dessus de la vue, du contrôle ou du widget voulu
    C’est très facile à faire même avec un périphérique d’entrée imprécis, des mains qui tremblent ou une mauvaise vue
    Mais justement, quand on dispose d’un mode de défilement aussi naturel et facile, la barre de défilement manque encore plus lorsqu’elle sert d’indicateur
    Les minimaps sont parfois utiles, mais souvent non ; personnellement, je les trouve encombrantes et peu utiles dans l’édition de texte. Je suis bien sûr favorable à ce qu’elles existent en option pour ceux qui les apprécient

    • La molette et les gestes sont des dispositifs de déplacement dans la page, et la barre de défilement joue aussi ce rôle, mais c’est aussi un contrôle qui permet de dire « amène-moi au milieu du document »
      Si l’on part du principe que le document réagit correctement, on peut facilement parcourir de grandes distances avec la barre de défilement, surtout dans les gros documents. Sur le Web d’aujourd’hui, il est difficile de faire confiance à ce principe
      Dans de vieux gros PDF sans liens, qui utilisent des numéros de page de section comme « B-29 », il m’est arrivé un nombre incalculable de fois de faire en pratique une recherche binaire avec la barre de défilement pour trouver une page enfouie
      Bien sûr, le Web moderne, avec l’abus du chargement différé et du défilement infini, a presque détruit la possibilité d’utiliser la barre de défilement comme indicateur
      Sur Mac, il m’est souvent arrivé de faire Cmd-flèche bas pour sauter à la fin d’un document en espérant qu’il y en ait une, et en attendant que tous les embeds qui cassent la mise en forme se chargent
      Mais au final, on a l’impression d’être monté dans un train sans fin : impossible de savoir combien on a parcouru ni combien il reste
      Comme la barre de défilement est donc devenue pratiquement inutile, j’utilise une molette de souris lourde montée sur roulement, conçue pour le doom scrolling à grande vitesse
    • On dirait que vous n’avez pas lu l’article. Dès le premier paragraphe, il dit : « on pourrait dire que c’est à ça que sert la molette de défilement, mais tout le monde ne peut pas utiliser une molette ou le balayage sur écran tactile »
      Le paragraphe suivant traite aussi des difficultés que les barres de défilement petites ou masquées posent à d’autres modes de saisie comme les dispositifs de suivi du regard
    • Exact. Enfin quelqu’un qui comprend à quoi servent les barres de défilement
      Le rôle principal d’une barre de défilement est de montrer à l’utilisateur que le document est plus grand que la fenêtre ; son rôle secondaire est de montrer quelle partie du document est visible. Faire défiler l’utilisateur n’est pas sa fonction principale
      J’ai vraiment été surpris quand Apple a commencé à masquer par défaut les barres de défilement dans macOS. Les designers UI d’Apple semblent ne pas savoir ce que font réellement les contrôles d’interface de base
    • Les dispositifs d’entrée pour le défilement ne sont pas disponibles partout
      Les utilisateurs de Wacom/stylet n’ont pas de molette
      Beaucoup de trackballs n’ont pas non plus de molette, même si certains ont un anneau de défilement autour de la boule
      J’ai retiré la molette de ma souris après avoir développé une lésion due aux gestes répétitifs dans le doigt qui faisait défiler. Il y a aussi eu une période où j’avais trop sollicité le bras avec lequel j’utilisais la souris, au point de devoir utiliser un trackball de l’autre main pendant plusieurs semaines
    • Si l’on doit faire défiler sur une très grande distance, la molette de souris s’effondre
  • Il faut aussi parler des bordures de fenêtres. J’ai plusieurs fenêtres VS Code ouvertes et superposées, avec un fond noir et des bordures noires, sans ombre
    On ne voit absolument pas où se trouve le cadre/la bordure d’une fenêtre au-dessus d’une autre. Cela devrait relever du système d’exploitation, mais apparently c’est un problème d’application
    En plus, VS Code a « retiré » la prise en charge des réglages de bordure : https://github.com/microsoft/vscode/issues/160159

    • On trouve davantage de choses sur les bordures et les barres de titre ici
      https://news.ycombinator.com/item?id=37865824
      Ma théorie, c’est que les designers ciblent des utilisateurs qui ne regardent qu’une seule fenêtre en plein écran à la fois
      Leur utilisateur modèle est assis devant un ordinateur portable de 13 pouces, dans une pièce à l’éclairage idéal et sans reflets ; il ne déplace ni ne redimensionne les fenêtres, et n’ouvre pas plus de trois onglets/documents par jour
  • Chaque fois que je lis ce genre d’article ou des blogs UX, il devient trop évident à quel point nous nous soucions peu de l’accessibilité
    Une « bonne » conception accessible est assez ennuyeuse et dépouillée par rapport à ce qu’on attend des applications Web modernes
    J’ai lu le livre d’Adam Silver sur les formulaires et compris que, du point de vue de l’accessibilité, nous faisons complètement fausse route, mais l’accessibilité n’est pas une priorité

    • Il est ironique que, pour qu’un commentaire soit accessible, le lecteur doive chercher que a11y signifie « accessibility »
    • D’un point de vue business, ce n’est pas forcément faux. Quand une entreprise fait des choses qu’elle ne pourrait pas faire si elle créait un site Web accessible, le calcul est souvent plus favorable
      Les dark patterns, en particulier, sont très opposés à l’accessibilité
      C’est pourquoi il faut des lois qui rendent l’accessibilité obligatoire
  • Savez-vous ce qui pose un problème d’accessibilité à beaucoup de personnes de plus de 40 ans ? Du texte blanc sur fond sombre.
    Je crois que je ne me lasserai jamais d’entendre plaider pour que les pages web soient lisibles par les gens de ma génération.
    En ouvrant les outils de développement et en modifiant le CSS de l’auteur, j’ai pu lire la page, mais le script shell est alors devenu illisible.

    • Même en ayant moins de 40 ans, cette combinaison fatigue énormément les yeux. Après avoir lu quelques paragraphes puis regardé un mur, des lettres fantômes restent dans mon champ de vision pendant plus de 30 secondes.
      C’est tellement inconfortable que, si le fait de sélectionner tout le texte n’atténue pas le contraste fond sombre/texte blanc, je ne lis tout simplement pas la page.
    • Malheureusement, les besoins d’accessibilité entrent souvent en conflit, et les personnes qui créent des pages web n’ont pas un temps infini pour garantir des options adaptées à tout le monde.
      On peut aussi envisager de désactiver complètement le CSS.
    • Je n’ai pas encore 40 ans, mais chez moi c’est l’inverse. J’ai une forte myodésopsie, donc les corps flottants ressortent sur fond blanc.
      Ce qui a été vraiment appréciable ces cinq dernières années, c’est que la plupart des grandes interfaces utilisateur proposent désormais à la fois un mode sombre et un mode clair.
    • Dans le navigateur, ça vaut le coup de jouer avec l’extension Dark Reader. On l’utilise généralement pour un mode sombre global, mais on peut aussi définir un mode clair par site ou globalement.
    • Ce n’est pas exactement le même problème, mais je vois souvent du texte gris foncé ou gris moyen sur un fond clair ou gris moyen.
      Ma solution est la suivante :
      https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
      Au minimum, cela force le texte en noir. C’est assez fiable, et les rares exceptions nécessaires se configurent facilement.
  • Je suis d’accord pour dire que les barres de défilement sont en train de mourir et de devenir inutilisables. Elles devraient être larges, clairement visibles et faciles à atteindre.
    Leur taille devrait être proportionnelle afin d’indiquer la part du document actuellement visible, et la partie mobile devrait avoir des caractéristiques qui suggèrent une sensation de friction plutôt que de glissement.
    Les boutons fléchés devraient être placés ensemble, et non aux extrémités opposées, et les états de survol et d’appui de la souris devraient être signalés par la couleur.
    Parmi les barres de défilement classiques présentées ici, celle de Nextstep sur https://scrollbars.matoseb.com/ est celle qui se rapproche le plus de ces critères, et je trouve que Mac OS 8 est globalement la plus jolie.

    • En plus de cela, si le document le prend en charge, il devrait aussi y avoir une option permettant un panoramique dans les deux directions à partir d’un seul widget de barre d’outils. J’ai déjà vu ce type d’implémentation, mais jamais avec les boutons fléchés regroupés plutôt qu’aux deux extrémités.
      Autrefois, il existait un domaine de recherche appelé interaction humain-machine, où l’on apprenait la loi de Fitts et le fait que les bords de l’écran avaient en pratique une taille infinie, ce qui les rendait particulièrement précieux.
      Sous OS X, je garde MS Teams ouvert comme punition ; la fenêtre est collée au bord droit de l’écran, avec une barre de défilement sur son bord droit.
      Quand je pousse la souris vers la droite et que je clique pour attraper la barre de défilement, qui s’est élargie au survol jusqu’à toucher le pixel du bord, c’est toute la fenêtre qui se met à être déplacée.
      Je ne sais pas comment on en est arrivé là. Il y a eu une époque où l’on étudiait activement ce qui faisait une bonne interface utilisateur, où ces travaux se retrouvaient dans l’expérience utilisateur réelle, et où les résultats se voyaient.
    • Je n’avais jamais pensé au fait que les boutons fléchés devraient être placés côte à côte plutôt qu’aux extrémités opposées, mais c’est logique.
      Je me demande pourquoi c’est si rare, à part parce que « ça a toujours été comme ça ».
  • On dit que « les designers ne font pas de tests d’utilisabilité avec des utilisateurs non techniques », mais même s’ils en faisaient, cela ne changerait probablement pas grand-chose.
    J’ai travaillé comme développeur web pendant près de 25 ans et collaboré avec beaucoup de designers ; ce qui les intéresse, c’est un layout pixel perfect conforme à leur « vision ». L’UX n’est même pas une pensée fugace.

    • Tous les designers ne sont pas comme ça, mais beaucoup le sont. J’ai déjà vu un designer sortir d’une étude UX menée avec de vrais utilisateurs et dire : « Ce n’est qu’un point de données, et nous considérons que ces utilisateurs se trompent. »
      Dans ce genre de cas, la persuasion ne fonctionne pas.