- Les interfaces utilisateur (UI) complexes des logiciels libres constituent une barrière à l’entrée pour les utilisateurs ordinaires
- Même une tâche simple comme la conversion vidéo pousse le grand public à abandonner à cause de l’UI pensée pour les experts d’outils comme Handbrake
- Pour résoudre ce problème, l’auteur a créé Magicbrake, un frontend simple avec une interface à bouton unique, qui ne fait qu’une chose : « convertir des fichiers vidéo bizarres en MP4 normaux »
- En masquant les fonctions complexes et en n’exposant que les 20 % de fonctions dont la grande majorité des utilisateurs a réellement besoin, on améliore la productivité et la satisfaction
- L’écosystème du logiciel libre doit adopter une conception plus accueillante pour les utilisateurs ordinaires afin d’élargir le champ d’usage de ses outils
Le fossé entre le logiciel libre et les utilisateurs ordinaires
- Les utilisateurs ordinaires rencontrent des difficultés de format même pour des tâches de base comme convertir, téléverser ou lire une vidéo
- Tout format qui ne se lit pas dans QuickTime ou sur Facebook est perçu comme « bizarre »
- Handbrake est puissant, mais son UI pensée pour les utilisateurs avancés provoque malaise et confusion chez le grand public
- Ce problème est répandu dans l’ensemble du FOSS (Free and Open Source Software), si bien que les utilisateurs ordinaires finissent par renoncer ou par demander de l’aide à des experts
Le cas Magicbrake
- Magicbrake masque la complexité de Handbrake et n’accomplit qu’une seule tâche : « convertir une vidéo bizarre en MP4 normal »
- Le résultat de la conversion est un petit fichier MP4 qui fonctionne dans la plupart des environnements
- L’interface ne comporte qu’un seul bouton
- Cette approche constitue une solution rapide et simple, adaptée aux utilisateurs qui n’ont pas besoin de fonctions complexes
Objections à la simplification et réponses
- Certains posent des questions du type : « pourquoi avoir rendu Handbrake moins puissant ? », « et si j’ai besoin d’un autre format ? », « qu’en est-il des fonctions spéciales ? »
- La réponse est simple : ceux qui ont besoin de fonctions avancées peuvent continuer à utiliser Handbrake tel quel, tandis que les autres peuvent utiliser un outil plus simple
- C’est une idée comparable au fait de cacher avec du ruban adhésif les boutons inutiles d’une télécommande TV : les fonctions existent toujours si nécessaire, mais elles ne gênent pas l’usage de base
La valeur d’une UI simple
- Il existe quantité d’outils comme des serveurs multimédias difficiles à configurer pour le grand public, des éditeurs audio qui exigent un apprentissage même pour des tâches élémentaires, ou des outils de supervision réseau qui excluent les débutants
- Ces outils sont excellents sur le plan fonctionnel, mais leur conception qui cherche à tout mettre dans une seule UI les rend peu accessibles aux utilisateurs ordinaires
- 80 % des utilisateurs n’ont besoin que de 20 % des fonctions ; masquer le reste permet donc d’offrir une expérience plus productive et plus satisfaisante
Proposition aux développeurs
- Concevoir une interface simple pour les utilisateurs ordinaires est quelque chose qui peut se faire en une soirée et qui a une vraie valeur pratique
- Au lieu d’exposer toute la complexité, une philosophie de conception qui ne montre que les fonctions nécessaires améliore l’accessibilité du logiciel libre
- L’auteur encourage les développeurs à créer davantage d’outils simplifiés de ce type
9 commentaires
On pourrait parler de complexité de l’UI/UX,
mais je pense que le problème, dans les logiciels développés aujourd’hui, qu’ils soient libres ou propriétaires, c’est qu’ils sont conçus pour qu’un seul cas précis fonctionne, et qu’on se soucie assez peu de ce qui arrive dans toutes les autres situations.
Par exemple, lorsqu’on modifie une configuration en toml ou en yaml, il arrive que quelque chose qui devrait absolument marcher ne fonctionne pas. En général, ce n’est pas correctement documenté : est-ce un problème d’encodage, d’indentation, ou bien une fonctionnalité inutilisable lorsqu’un certain flag est activé ? L’utilisateur finit par essayer une quantité folle de cas un par un, jusqu’à trouver péniblement la bonne réponse.
Dans l’UI, c’est encore plus grave. Comme le montre le mème bien connu autour de la réinitialisation de mot de passe, quand un écran contient 100 champs, il est impossible de savoir « sans essayer » quelles sont leurs relations mutuelles, ni quelle est la meilleure façon de les modifier.
C’est un problème d’UI/UX, mais aussi un problème d’« expertise » cachée. Faute d’une courbe d’apprentissage progressive, ce qui permet à une personne experte de saisir immédiatement la bonne réponse devient, pour un débutant, une sorte d’examen ou de passage obligé qui lui fait subir une multitude de refus.
Dans le même ordre d’idées, j’ai l’impression qu’un GUI est plus pratique qu’un CLI pour le grand public, donc j’utilise aussi
yt-dlgcomme interface graphique pouryt-dlp. Pourffmpegaussi, je note les commandes que j’utilise souvent, donc on pourrait sans doute en faire un GUI.Comme toujours, c’est l’UI/UX !!
Personnellement, j’ai souvent eu des réflexions similaires, donc je comprends assez bien ce point de vue. Quand j’essayais de trouver sous Linux des applications du genre Paint, Bloc-notes ou Lecteur Windows Media de l’époque WinXP~7, qu’on peut « simplement ouvrir et utiliser vite fait », j’estimais déjà avoir de la chance si je finissais par en trouver une qui me plaisait après en avoir installé cinq ou six.
Quand il s’agit juste de faire une capture d’écran et de rogner l’image, impossible d’utiliser Gimp ; je ne me souviens plus de tout ce que j’ai essayé, mais comme je n’ai rien trouvé parmi les applis gtk, j’ai fini par me rabattre sur Kolourpaint. Pour le Bloc-notes, il y a Gedit, Kate, Mousepad, Leafpad, Xed, etc., et si on veut encore plus léger, il faut carrément aller chercher des trucs comme xedit, nano ou vim, qui semblent avoir renoncé à être conviviaux pour l’utilisateur. Quant aux lecteurs multimédias, rien que penser à mpv, VLC ou mplayer commence déjà à me donner mal à la tête.
Ces textes me gênent un peu : ils affirment avoir raison sans même s’appuyer sur des statistiques ou autre.
Les utilisateurs ne se soucient que de 20 % d'une application
D'une certaine manière, cela semble aussi lié à l'article ci-dessus.
« La plupart des utilisateurs n’exploitent qu’environ 20 % des fonctionnalités d’une application dont ils ont besoin, mais ces 20 % diffèrent selon les utilisateurs. »
N’est-ce pas là l’essentiel ?
Dès qu’on demande quelque chose, on nous répond souvent « lis d’abord le
man/README/la doc ».En réalité, l’important en UX, c’est qu’on puisse comprendre immédiatement comment l’utiliser, même sans explication.
Comme ce n’est pas un travail rémunéré, on passe là-dessus, mais du point de vue d’un utilisateur non développeur, il est vrai que l’expérience d’utilisation n’est pas très bonne.
Avis Hacker News
Bon article, mais je pense que le raisonnement est erroné
Créer une interface concise et unifiée n’est jamais facile
Implémenter une UI adaptée à un cas d’usage précis n’est pas si difficile, mais le vrai problème est de définir ce « cas d’usage exact » et d’empêcher les demandes du type « pouvez-vous juste ajouter encore ça ? »
Cette simplicité est souhaitable, mais c’est un état instable
La complexité du code se voit, mais celle de l’UI ne se voit pas
Les boutons et champs de saisie ont l’air simples, mais résoudre des problèmes avec ce langage est extrêmement complexe
L’échec est clair, mais le succès est ambigu et varie selon les utilisateurs
Une bonne interface transmet beaucoup de choses de manière « implicite », et c’est la partie la plus difficile
Même si le bouton n’a presque aucun rapport avec sa fonction initiale Y, ils insistent pour qu’il fasse absolument cela
Ce genre de demandes de « petit changement » s’accumule, l’UI devient de plus en plus complexe et finit par s’effondrer
Ils ne veulent pas sacrifier leur confort pour l’ergonomie des 80 % d’utilisateurs ordinaires
Définir à l’avance l’ensemble des fonctionnalités, puis se concentrer ensuite sur les corrections de bugs et les gains d’efficacité
Les nouvelles fonctionnalités ne devraient être ajoutées qu’après un examen strict
C’est difficile pour les logiciels qui évoluent vite, mais cela pourrait être efficace dans la plupart des domaines stables
À long terme, l’application elle-même pourrait intégrer l’IA et évoluer vers une génération automatique de l’UI souhaitée par l’utilisateur
Je pense qu’au fond c’est une question de familiarité
Ma femme n’est pas à l’aise avec la technologie, mais elle utilise Linux
En lançant une nouvelle activité, elle a dû utiliser Windows, mais l’expérience était si désagréable qu’elle a voulu revenir à Linux
J’ai eu une expérience similaire avec le Mac vs PC
Quand j’ai été forcé d’utiliser un Mac, ma productivité est tombée à 10 %, c’était très pénible
Au final, on travaille toujours mieux dans l’environnement auquel on est habitué
Au final, ce n’était « qu’un ordinateur »
Heureusement, le VPN et les applications dont j’ai besoin fonctionnent tous avec Linux + interface web
Il faut une distribution stable offrant une UI presque identique aux OS commerciaux, sans nécessité d’ouvrir le terminal
Ce n’est pas une question de « ressemblance approximative », mais de finition dans les détails
Les UI open source paraissent au départ étranges et complexes
Elles sont conçues de manière centrée sur les développeurs, donc le principe consistant à « ne pas surprendre » l’utilisateur ordinaire n’est pas respecté
Mais avec un usage régulier, on s’habitue à cette nouvelle philosophie et on peut les utiliser avec succès
Moi-même, j’utilise très bien Firefox, LibreOffice, Avidemux et Virt-manager
Le problème, c’est le manque de designers
Le FOSS attire surtout des développeurs disposant de temps libre, alors que les artistes ou designers sont relativement moins nombreux
Résultat : on se retrouve souvent avec des UI qui n’atteignent qu’un niveau de base
Les problèmes d’UX de l’éditeur audio gratuit Audacity sont déjà identifiés par des designers
Ils ont publié une vidéo de refonte UX pour résoudre les problèmes de « modes » et de « Audacity says no »
Des améliorations sont prévues ; dans l’open source, la bonne UX reste rare, mais les choses évoluent
Au départ, c’est une appli créée pour son propre usage, puis les gens disent : « les fonctionnalités sont bien, mais l’UX laisse à désirer »
À l’inverse, si on améliore l’UX, on entend : « il manque des fonctionnalités »
À force de vouloir satisfaire tout le monde, on tombe dans un enfer infini de redesign
Il arrive même que des projets s’effondrent en voulant créer des choses comme un moteur de thèmes
Si elle avait été publiée sous un autre nom, personne ne se serait plaint
Je pense que la solution à ce problème réside dans la standardisation au niveau de l’OS
L’OS doit fournir une UI et un workflow cohérents
Par exemple, au lieu de « Handbrake », il y aurait une application par défaut nommée « Video Converter »,
capable de comprendre des commandes comme « convertis pour que ça puisse être lu sur Facebook » et d’appliquer automatiquement les bons réglages
La marque des applications devrait être minimisée, et l’utilisateur devrait pouvoir contrôler entièrement les thèmes et les polices
Il faudrait aussi un langage de shell standard relié aux fonctions GUI
Au final, les gens veulent surtout des fonctionnalités
Même avec une UI complexe, ils l’acceptent si, une fois apprise, elle leur permet de faire ce qu’ils veulent
Les logiciels avec seulement des options simples ont un petit marché
Les utilisateurs qui ne comprennent pas les formats vidéo finissent de toute façon par chercher sur le web « convert x to y » pour s’en sortir
Dès qu’on utilise un outil spécialisé, on est déjà dans le domaine des utilisateurs avancés
Une UI simple du style « déposez le fichier ici et cliquez sur Fix It » est tout à fait possible
Je pense que c’est précisément le point principal de l’article d’origine
Si l’open source est complexe, c’est pour plusieurs raisons
Mais la plupart des FOSS exigent une certaine culture technique
Apprendre un logiciel complexe est au contraire plus efficace sur le long terme
Pour des développeurs open source au temps limité, il est difficile d’en faire une priorité
Il y a cette blague : si Handbrake vous semble difficile, surtout ne montrez pas ffmpeg
Quand j’ai utilisé Handbrake pour la première fois, moi aussi je l’ai trouvé bien plus pratique que ffmpeg
À l’inverse, les outils GUI s’apprennent souvent en regardant des vidéos
ffmpeg -i input.avi output.mp4et c’est terminéHandbrake affiche toutes les options, tandis que ffmpeg ne demande que ce dont on a besoin
Une fois qu’on y est habitué, on obtient un contrôle très précis
Cette simplicité du type « il suffit d’indiquer l’entrée et la sortie » a justement son charme
Ce n’est pas parfait, mais j’ai l’impression que c’est meilleur que moi
Donc je trouve l’exemple de l’article d’origine un peu étrange
Quelqu’un comme moi préfère les interfaces complexes
J’aimerais qu’on parte du principe que je suis intelligent
Plus un outil est utilisé souvent, plus il vaut mieux qu’il permette de travailler vite, même s’il est complexe
Le problème, c’est que tout le monde veut ses propres 20 % de fonctionnalités
Une bonne UI/UX exige une boucle de feedback étroite entre testeurs, designers, développeurs et utilisateurs
Le FOSS manque de ressources pour cela
Mais l’utilisateur moyen du FOSS est un power user du top 1 %, donc il ne le comprend pas
C’est pourquoi toute tentative de recentrage sur les utilisateurs ordinaires se heurte à une résistance de la communauté
Les développeurs le créent pour leurs propres besoins, donc la satisfaction des utilisateurs n’est pas forcément l’objectif
Ce n’est pas un échec, juste un but différent
Seule une minorité utilise les fonctions avancées
Donc le plus réaliste est de séparer UI de base + mode avancé
Comme seuls des utilisateurs déjà habitués à cette UI la testent, on entend surtout « ne changeons rien »
À l’inverse, les grandes entreprises peuvent financer des tests utilisateurs payants auprès de nouveaux utilisateurs
C’est pourquoi leurs améliorations UX avancent plus vite
Quand on demande des contributions à des spécialistes UI/UX, ils ont le plus souvent l’impression de ne pas être compris