Les bons outils sont invisibles
(gingerbill.org)- Un bon outil est un outil qui disparaît en arrière-plan pendant que l’utilisateur se concentre sur sa tâche ; l’objectif de son créateur est aussi de faire en sorte que l’outil lui-même ne soit plus remarqué
- Quand on requalifie les défauts d’un outil en « puzzle amusant », il devient facile de confondre le sentiment d’avoir été astucieux avec une productivité réelle
- Le choix d’un éditeur comme vim, emacs ou Sublime peut convenir à un workflow personnel, mais si l’on défend même ses défauts comme un signal d’identité, il devient difficile d’en voir honnêtement les forces et les faiblesses
- Dans le débat TUI contre GUI, il ne faut pas prendre les insuffisances des implémentations actuelles pour des limites intrinsèques de la catégorie elle-même ; beaucoup de problèmes viennent simplement de l’absence de bonnes implémentations
- De bons réglages par défaut sont une conception qui économise le temps de l’utilisateur ; une forte configurabilité ou une courbe d’apprentissage abrupte ne valent la peine que lorsqu’elles sont compensées par une productivité réelle
Les critères d’un bon outil
- Un bon outil doit être invisible
- Lorsqu’un utilisateur peut continuer à travailler sans penser à l’outil lui-même, celui-ci disparaît en arrière-plan
- Dès qu’un outil le freine dans une tâche donnée, l’utilisateur reprend conscience de l’outil
- Requalifier ses lacunes en « puzzle amusant » brouille l’évaluation de l’outil
- Le plaisir de trouver un contournement ne prouve pas la qualité de l’outil
- Prendre ses défauts comme un loisir et avoir un outil réellement bon sont deux choses distinctes
Le débat sur les éditeurs de texte
- vim n’est qu’un exemple, et le même raisonnement s’applique à d’autres éditeurs comme emacs ou Sublime
- Certains utilisateurs louent davantage le processus de résolution des défauts de vim comme un puzzle amusant que ses qualités
- Il existe des cas où créer une macro pour un refactoring de texte ponctuel a été jugé amusant
- Si la même tâche pouvait être effectuée en moins d’une minute avec les curseurs multiples de Sublime, ou résolue par un simple script, le travail de macro devient faible au regard de la productivité réelle
- Un éditeur est important dans un workflow, mais suivre un éditeur particulier de manière quasi religieuse pour son « ambiance hacker » est dangereux
- Cette ambiance peut séduire les personnes qui découvrent vim ou emacs
- L’habitude peut masquer les défauts et pousser à s’en vanter comme d’un jeu
Pourquoi utiliser Sublime, et les limites reconnues
- Sublime est l’éditeur utilisé depuis 15 ans, et ce choix se résume à quelques raisons
- Ses raccourcis clavier sont proches d’un sur-ensemble de l’environnement graphique de l’OS, ce qui réduit le coût de changement cognitif quand on passe d’une application à l’autre
- Les curseurs multiples sont considérés comme meilleurs que les macros dans 99,999 % des cas
- Les curseurs multiples fournissent un retour visuel direct
- C’est l’éditeur qui présente le moins de « puzzles » à résoudre dans le workflow d’édition de texte
- Sublime conserve toutefois des défauts
- Il arrive qu’un outil nécessaire manque, obligeant à utiliser un plugin ou à traiter la transformation de texte dans un programme séparé
- Ces défauts ne sont pas présentés comme des « puzzles amusants », mais simplement acceptés comme des désagréments
- vim peut être meilleur pour l’édition de base, mais il est jugé plus faible pour les opérations en masse qui ne relèvent pas de grep
- Les motions de vim ne semblent pas beaucoup plus productives qu’un workflow Sublime
- Comme l’écriture de code se fait très rarement dans le terminal, un éditeur orienté terminal n’est pratiquement pas nécessaire
Quand l’outil devient une identité
- Le choix d’un outil peut fonctionner comme un étendard indiquant quel genre de personne on est
- L’« ambiance hacker » peut dépasser la simple esthétique et devenir un signal de tribu
- Quand l’identité se lie à un outil, reconnaître ses défauts peut donner l’impression de se renier soi-même
- On ne se contente alors plus de tolérer les défauts : on les défend et on s’en vante
- Il est difficile d’avoir une conversation honnête sur un outil avec quelqu’un pour qui cet outil est devenu une partie de sa personnalité
Le sentiment d’être productif et la productivité réelle
- L’exemple des macros d’éditeur montre la différence entre le sentiment d’être productif et la productivité réelle
- Le sentiment d’intelligence qui naît quand on résout un problème difficile se confond facilement avec le résultat concret
- Un outil qui rend une tâche difficile héroïque et donne l’impression que l’astuce est une réussite peut sembler puissant
- En même temps, la vitesse de travail réelle peut être discrètement plus lente
- Le critère honnête n’est ni l’immersion ni le sentiment d’intelligence, mais le temps passé et le nombre d’erreurs
- Les outils recommandés avec un zèle quasi évangélisateur peuvent être moins bons selon ce critère
- Si l’objectif est la productivité, il faut réellement remettre ses convictions en question et vérifier ce qui est plus productif
Le débat TUI contre GUI
- Pour les utilisateurs qui passent toute la journée dans le terminal, les avantages des applications terminal sont évidents
- Mais la plupart des programmeurs ne sont pas enfermés dans un terminal toute la journée
- La critique selon laquelle une application GUI ne peut pas être parcourue uniquement au clavier ne signifie pas que les GUI soient intrinsèquement mauvaises
- Beaucoup de GUI ne prennent tout simplement pas assez en charge la navigation au clavier
- Il n’y a rien d’intrinsèquement impossible à rendre une GUI navigable au clavier
- De nombreux créateurs d’outils ne l’implémentent pas, ou ne réalisent pas que la navigation au clavier est souvent plus productive que l’usage fréquent de la souris
- Il peut être pertinent de comparer une application TUI donnée à une alternative GUI précise et de conclure qu’elle est meilleure
- Mais juger que les TUI sont intrinsèquement meilleures que les GUI revient presque à prendre les limites des implémentations actuelles pour des limites intrinsèques
Le desktop Linux et le plaisir de la configuration
- Même en 2026, « l’année du desktop Linux » n’est pas arrivée
- L’une des raisons est que beaucoup d’utilisateurs de Linux aiment modifier des fichiers de configuration et transformer leur système comme un puzzle amusant
- Même après être passé soi-même par cette étape, avec le temps on finit par vouloir des outils qui fonctionnent tout simplement bien
- Passer des heures ou des jours à configurer n’est plus quelque chose que l’on souhaite faire
- Les réglages par défaut doivent être bons et fonctionner immédiatement
- Quand un petit ajustement est nécessaire, il doit pouvoir être fait en quelques secondes
- La configurabilité maximale ne doit pas être l’objectif d’un outil, mais une option à utiliser lorsqu’elle est réellement nécessaire
- Concevoir des outils ergonomiques consiste à fournir à la fois de bons réglages par défaut et des issues de secours lorsque c’est nécessaire
Les bons réglages par défaut et la responsabilité des créateurs d’outils
- Les bons réglages par défaut relèvent de la responsabilité des créateurs d’outils
- Les créateurs d’outils ont facilement tendance à transférer aux utilisateurs la charge de la configuration, de l’ajustement et de l’apprentissage
- Une grande partie de cette charge résulte de décisions que les concepteurs ont évité de prendre
- Une « forte configurabilité » peut devenir une excuse pour transmettre le problème à l’utilisateur sans exprimer de point de vue
- De bons réglages par défaut sont une marque de respect pour le temps de l’utilisateur
- Si le créateur de l’outil réfléchit une fois au problème, d’innombrables utilisateurs n’ont pas à répéter la même réflexion
- Les issues de secours sont des mécanismes destinés à une vraie minorité ayant des besoins particuliers
- Elles ne doivent pas remplacer le fait de bien traiter les cas courants
Une courbe d’apprentissage abrupte n’est pas une fonctionnalité
- Certains défendent l’idée que la difficulté d’un outil serait centrale
- Selon cette logique, elle filtre les personnes qui ne sont pas engagées et, une fois le cap franchi, récompense pour toute la vie
- La courbe d’apprentissage est un coût, pas une vertu
- Ce coût peut en valoir la peine, mais la récompense doit être une productivité réelle
- La satisfaction d’avoir payé ce coût ne doit pas devenir la récompense en soi
- L’argument « je l’ai appris pendant des mois, donc cela doit avoir de la valeur, et les autres doivent faire pareil » habille un coût irrécupérable en compétence
- Dans ce cas, le puzzle n’est plus le travail réalisé avec l’outil, mais l’outil lui-même
L’attitude compte davantage que le choix de l’outil
- Il ne s’agit pas d’un argument contre un outil précis, mais d’une critique de la manière de penser les outils
- On peut utiliser vim, emacs ou Sublime
- Le critère est de savoir si l’outil disparaît en arrière-plan et permet à l’utilisateur de continuer à travailler
- Ce critère est personnel
- Le problème, ce sont les récits qui entourent le choix de l’outil
- On requalifie les limites en fonctionnalités
- On vend l’effort de contournement des défauts comme une récompense
- L’outil passe de quelque chose que l’on « utilise » à une « partie de soi »
- Le signe le plus clair qu’un outil rend correctement service est l’état dans lequel l’utilisateur ne le remarque plus
- Le meilleur outil n’est pas celui qui a la meilleure histoire, mais celui qui fait oublier à l’utilisateur qu’il est en train de l’utiliser
1 commentaires
Avis sur Hacker News
Pour avoir conçu pas mal d’outils internes pour des équipes de développeurs, je suis vraiment d’accord
Avant, je pensais que, puisque les utilisateurs étaient des développeurs, il valait mieux laisser la « structure interne » accessible, mais en pratique cela ne faisait que créer des obstacles à mes collègues dans leur vrai travail
Les membres de l’équipe utilisent l’outil que j’ai créé pour faire ce dont l’entreprise a besoin, pas parce qu’ils ont envie de bricoler un petit outil qu’ils ne verraient nulle part ailleurs, et ils n’ont aucune raison de devoir le faire
Je laisse encore beaucoup d’issues de secours, mais j’essaie de concevoir les outils internes de façon à ce que l’utilisateur tombe naturellement dans la fosse du succès
Et les messages d’erreur, les messages d’erreur, les messages d’erreur, ainsi que les suggestions automatiques pour les erreurs fréquentes, sont essentiels
C’est aussi décevant de voir autant de gens s’accrocher uniquement aux exemples de l’article sans en voir l’idée générale
Si l’outil aide l’utilisateur à faire directement quelque chose qui lui importe, la configurabilité a beaucoup de valeur ; mais si l’outil sert à écarter un problème qu’il juge moins important, elle peut au contraire devenir gênante
Par exemple, la façon dont Gusto prend en charge la paie, les impôts et le dépôt des formulaires est vraiment excellente, parce qu’il n’y a presque pas besoin d’y penser ni d’y toucher
Mais pour quelqu’un dont le métier est la paie, la comptabilité ou la fiscalité, ou qui travaille dans les RH, le juridique ou la finance d’une grande entreprise, cette simplification peut être nuisible. Soit il doit se battre contre l’outil, soit, pour le dire un peu moins gentiment, l’outil rend son travail trop simpliste
La question de savoir qui paie réellement est aussi majeure, tout comme celle de savoir si l’outil poursuit un objectif défensif — auditabilité, sécurité, restriction des comportements indésirables — ou un objectif créatif. Les fonctionnalités créatives sont plus séduisantes, mais plus difficiles à quantifier, et les utilisateurs finaux ne sont généralement pas prêts à payer très cher pour elles, même si elles les aident beaucoup dans leur rôle
Il s’agit d’avoir des valeurs par défaut raisonnables, avec la possibilité de personnaliser si nécessaire. Il faut commencer par les 80 % de cas, permettre de changer si on le souhaite, et faire en sorte que ce soit optionnel
Dans les outils pour développeurs en particulier, on a tendance à hésiter à assumer des choix très marqués. Si l’on n’est pas sûr qu’une option soit « toujours la bonne », il paraît plus sûr de demander à l’utilisateur, d’autant que les développeurs peuvent être assez exigeants
Se dire « 95 % voudront probablement cette approche, mais les 5 % restants ont aussi des arguments valables, donc je vais traiter tout le monde de la même manière » aboutit à un outil moins bon pour la grande majorité des utilisateurs
Prendre en charge la personnalisation est beaucoup plus complexe qu’on ne l’imagine. Ce n’est pas seulement une question de bugs : chaque option rend plus difficile le polissage de l’expérience utilisateur. La surface de test augmente aussi, et des abstractions plus flexibles sont plus difficiles à concevoir
Cela dit, il reste un équilibre à trouver : imposer aux gens la bonne manière de faire
Il y aura toujours des gens pour râler parce qu’ils sont bloqués à faire les choses correctement, et ils ont souvent l’impression que c’est une perte de temps
Du point de vue de l’organisation, l’objectif est de maximiser la courbe de performance de l’employé pendant qu’il est en poste ; du point de vue de l’employé, c’est de maximiser sa courbe de performance sur l’ensemble de sa carrière
Beaucoup dépend des relations entre les personnes concernées. Si un déménageur a fait du sport la veille et a des courbatures, de mon point de vue il sera plus lent et le résultat sera moins bon ; mais du point de vue de l’entreprise de déménagement, c’est peut-être positif à long terme, parce qu’il deviendra plus fort et pourra faire davantage de travail. En revanche, s’il démissionne ou se fait licencier ce jour-là, cela redevient un mauvais résultat
La vraie évaluation ne consiste pas à savoir ce qui est mieux entre les macros et l’édition dans Sublime, mais à déterminer si le processus de réflexion nécessaire pour créer des macros aide aussi dans d’autres tâches, et ce que la personne faisait avant cela
D’après mon expérience, presque personne n’aurait consacré à du vrai travail significatif le temps passé à utiliser des macros ou à apprendre Vim. Ces personnes sont souvent ennuyées ou en burn-out, et veulent penser à autre chose qui leur semble amusant à ce moment-là
Le problème n’est pas que les employés utilisent des scripts aléatoires, mais qu’ils n’ont pas de sentiment d’urgence ni d’intérêt pour la tâche en cours
L’effet par lequel une interface devient « invisible » est en réalité une fonction du temps passé dans cette interface
Ce à quoi l’auteur réagit semble plutôt relever de la friction discrétionnaire ajoutée par des designers ou des responsables produit sous forme de fonctionnalités ou de complexité
Mais pour accomplir une tâche donnée, cette friction peut être nécessaire. Il suffit de penser à la résolution de conflits de merge. Et si l’on utilise l’outil assez longtemps, même ces étapes « gênantes » finissent par disparaître en arrière-plan
Concrètement, le cockpit d’un 737 est extrêmement dense en commandes. L’avion lui-même a plusieurs modes, et beaucoup de frictions intentionnelles
Mais si vous demandez à un pilote qui travaille sur 737 depuis plus de dix ans, il dira que cette interface est devenue invisible
Il en va de même pour le Bloomberg Terminal, souvent considéré comme « mauvais ». Dans le domaine médical aussi, pour quelqu’un qui utilise un logiciel de scan IRM plus de huit heures par jour et veut un accès immédiat à toutes les commandes, une interface remplie de boutons peut être exactement la bonne solution
Les programmeurs ont tendance à généraliser beaucoup trop vite leur propre expérience et leurs préférences pour les appliquer aux autres
Source : j’ai conçu pendant dix ans des logiciels grand public et professionnels chez IDEO
L’article aborde cela du côté des utilisateurs, et considère qu’il existe une catégorie d’utilisateurs qui aiment apprendre des fonctionnalités « supplémentaires » dont la valeur finale est inférieure à celle des fonctions centrales
Le passage clé est celui-ci : « Si les gens utilisent vim, emacs, etc. parce qu’ils les trouvent vraiment bons et productifs, je ne les critique pas. On se sent le plus à l’aise avec ce que l’on connaît. Mais les personnes dont je parle ne voient plus les défauts de l’outil à cause de cette familiarité, et finissent par les exhiber et les célébrer comme s’il s’agissait d’un jeu. »
Pour quelqu’un qui utilise le terminal depuis longtemps, ce n’est pas très surprenant que les gens ne comprennent pas. La conversation se déroule généralement ainsi :
« Dans le terminal, on peut faire telle ou telle chose avec une simple commande »
« Dans mon FrobnicatorStudio, il y a un raccourci Ctrl+Alt+So pour ça »
Et ça continue sans fin, avec des comparaisons presque dénuées de sens du genre « dans Vim, on peut supprimer 24 lignes en quatre frappes » contre « Sublime a des curseurs multiples »
Le vrai point est sans doute que le terminal couvre une infinité de cas d’usage grâce à sa façon de combiner de petits outils en ligne de commande dans des pipelines, mais avec une courbe d’apprentissage d’environ un an avant de devenir confortable
Une fois ce stade atteint, on peut être bien plus productif que l’utilisateur moyen d’une GUI, mais y parvenir demande de l’engagement et de la douleur, et beaucoup de gens y arrivent par contrainte plutôt que par choix
Dans mon cas, mon premier emploi consistait à administrer des serveurs clients via ssh, et ces serveurs avaient une installation minimale. Souvent il n’y avait même pas vim, seulement vi, et je n’avais pas d’autre choix que de trouver comment travailler efficacement dans cet environnement
Sans cette expérience, je ne suis pas sûr que j’aurais accepté la douleur nécessaire pour commencer à travailler dans le terminal
Mais à un moment, j’ai eu l’impression d’y perdre trop de temps. Je suis revenu à la ligne de commande avec tshark et jq, le vieux bash/awk/grep et gnuplot ; ensuite j’ai utilisé Python, mais toujours à partir de la sortie de tshark
Au final, j’ai fini par créer des parseurs pcap et pcapng, du traitement ethernet-ip-udp/tcp, et même un IDE Java complet, et je ne suis jamais revenu en arrière
J’ai suivi le même chemin sinueux pour tous les outils de capture et d’exploration de données que je devais utiliser de façon répétée
Je ne pense pas être le seul à passer par ces étapes itératives d’amélioration des outils, et j’aimerais qu’il existe une échelle bien nommée pour les décrire
Le terminal donne infiniment plus de possibilités, mais en pratique il y a probablement une vingtaine de choses que l’on fait régulièrement. Si ces 20 choses suffisent, la courbe d’apprentissage rend l’argument difficile à vendre
Par exemple, si l’on est dans le terminal et qu’on veut trouver les scripts de build, on peut faire quelque chose comme
cat packages.json | jq .scriptsDans le terminal, c’est utile, mais si l’on est dans VSCode,
ctrl-p -> packages.json -> ctrl-f -> scrsuffit, et il y a même moins de frappes en pratiqueLes workflows des gens sont vraiment personnels, donc je ne dirais pas à quelqu’un de changer, mais dans mon cas je préfère les outils qui comprennent la structure du projet aux outils qui traitent simplement un projet comme du texte, donc un IDE me convient mieux
Les applications en ligne de commande sont des outils avec lesquels on interagit en tapant des commandes dans le shell, comme grep, sort, cp, git, ls ou tar. Quand on connaît leur usage courant, on peut aussi les utiliser dans des scripts, et donc les combiner en pipelines
Les applications à interface utilisateur textuelle désignent des applications interactives qui prennent le contrôle du terminal pendant leur utilisation, comme Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander ou Claude Code
Celles-ci ne se combinent pas en pipelines. Plus précisément, on ne les met pas dans un pipeline en les utilisant de la manière habituelle. Si c’est possible, c’est probablement parce que l’application fournit une interface en ligne de commande séparée de sa TUI
Il faut du temps pour pouvoir utiliser la même boîte à outils pour résoudre tous les problèmes, mais au final c’est plus efficace
Cela dit, c’est difficile à expliquer. Tant qu’on n’a pas résolu un problème difficile à traiter autrement qu’avec des outils en ligne de commande, il est difficile d’en comprendre la simplicité
J’utilise quand même beaucoup la ligne de commande pour tout. En général, je garde une fenêtre konsole ouverte, et quand j’ai besoin de compiler ou de lancer des tests, je fais alt+tab au lieu d’utiliser le support “build system” de Sublime
Je n’utilise Vim que quand j’ai besoin de ssh ou quand j’utilise Termux sur mon téléphone
Les outils GUI extensibles comme Sublime, VSCode, etc. couvrent eux aussi une infinité de cas d’usage, et fournissent même un environnement d’exécution plus stable et reproductible
Si ce débat ne se termine jamais, c’est à mon avis parce que les gens ont généralement l’esprit fermé. Il est difficile de se mettre à la place des autres, et encore plus difficile de prendre au sérieux l’éventualité d’avoir tort
Au fond, cette question n’a d’importance que pour les débutants. Une fois qu’on est suffisamment à l’aise, quel que soit l’outil utilisé, le goulot d’étranglement de la productivité n’est plus l’outil. Sauf peut-être avec ed
À propos de l’affirmation selon laquelle « on ne sait pas que la navigation au clavier est beaucoup plus productive que de prendre souvent la souris », beaucoup de gens qui se disent plus productifs ne l’ont jamais vraiment mesuré
Il y a eu au fil des années beaucoup de compétitions navigation au clavier contre navigation à la souris, et selon les détails de conception des tests, l’un ou l’autre l’emportait ; les écarts étaient souvent assez importants
Il n’était pas rare que la méthode que les utilisateurs disaient plus productive avant de voir les résultats réels perde finalement
Je ne cherche pas à maximiser un indicateur absolu de productivité, je veux un environnement qui ne casse pas le flow
Pour beaucoup de gens, le fait de prendre la souris casse le flow et semble maladroit, et c’est souvent pire que de perdre une seconde. Parce que cela fait sortir du contexte qu’on avait en tête
Dans mon cas, utiliser la souris quand je travaille me paraît naturel ; modifier tout mon workflow pour tout naviguer au clavier représenterait donc un énorme effort supplémentaire, simplement parce que cela pourrait faire gagner un tout petit peu de temps dans certaines situations
Dans des outils comme les traitements de texte, les IDE ou les gestionnaires de fichiers, où l’activité centrale consiste à lire, saisir, puis traiter ce qu’on a lu et saisi, on peut montrer que la navigation au clavier est plus rapide et plus naturelle lorsque l’utilisateur a appris les raccourcis
À l’inverse, dans les outils centrés sur des informations visuelles plutôt que textuelles, le débat clavier contre souris penche beaucoup plus du côté de la souris
Il existe tout de même des moments où des raccourcis efficaces sont bien plus utiles que des menus et des icônes. Dans les logiciels de CAO ou de modélisation 3D, 90 % du travail de l’utilisateur consiste à manipuler des données spatiales affichées visuellement, mais connaître les raccourcis pour changer d’outil ou modifier les paramètres des outils accélère beaucoup les choses et réduit le besoin de fouiller sans cesse dans des menus imbriqués
Je crains que l’auteur ne confonde le fait d’être familier avec son outil avec une preuve qu’il est meilleur
En réalité, tous les outils comportent des compromis, et si un utilisateur préfère l’outil X à l’outil Y, ce n’est sans doute pas parce qu’il est stupide, mais parce qu’il exploite mieux les affordances de cet outil, que seuls les utilisateurs expérimentés comprennent
Si l’on faisait utiliser à un développeur vim, emacs et Sublime Text pendant dix ans chacun, il ne serait probablement pas certain de savoir lequel est meilleur. Il aurait des préférences personnelles, mais il saurait aussi expliquer pourquoi d’autres préfèrent d’autres outils
Cela ressemble à une controverse née du fait de n’avoir jamais vraiment donné sa chance à un logiciel auquel on n’est pas habitué
À mes yeux, la marque d’un vieux briscard, c’est une méfiance diffuse envers tous les logiciels et envers les promesses de les améliorer. À long terme, tous les logiciels convergent vers la médiocrité
Il a seulement dit qu’il n’était pas d’accord avec l’idée de considérer la friction d’un outil comme une fonctionnalité
On pourrait reprendre son argument tel quel pour montrer que Vim est l’éditeur parfait pour moi. Parce que, quand j’utilise Vim, il devient invisible, et aussi, dans une certaine mesure, parce que j’ai transformé Vim en l’outil que je voulais
Lui a transformé Sublime en l’outil qu’il voulait. Mais l’idée de base reste valable. Si l’on crée quelque chose que d’autres vont utiliser, rendre cet outil invisible pour l’utilisateur est une propriété puissante
Médiocre signifie « d’une qualité ordinaire ou moyenne »
Pour développer la prochaine appli CRUD, on n’a pas forcément besoin de la technologie extraordinaire la plus récente et la plus avancée
Si je cite ce que j’ai écrit, cela donne : « Ce qui me déconcerte, c’est que beaucoup de gens traitent cette friction — l’effort nécessaire pour contourner les limites de l’outil — comme la partie “amusante”, et la présentent comme une preuve que l’outil est excellent. »
Cela n’a rien à voir avec les raisons pour lesquelles moi ou quelqu’un d’autre choisissons tel ou tel outil ; il s’agit de l’attitude qui consiste à traiter les défauts comme quelque chose à contourner comme dans un jeu de puzzle
Les mainteneurs de bons outils ont souvent une perception bien plus négative de leur outil que la manière dont les utilisateurs le voient réellement
Il est difficile de distinguer « aujourd’hui, 10 personnes se sont plaintes d’un bug ou d’une fonctionnalité manquante, et 9 990 l’ont utilisé sans problème » de « aujourd’hui, 10 personnes se sont plaintes, et seulement 90 l’ont utilisé sans problème ». Mais l’effort nécessaire pour passer de 90 % à 99,9 % de satisfaction utilisateur est colossalement différent
Je soupçonne fortement que c’est un facteur majeur dans beaucoup de cas de burn-out des mainteneurs open source
Les utilisateurs insatisfaits sont beaucoup plus visibles que les utilisateurs satisfaits, et à mesure que le nombre de nouveaux utilisateurs augmente, la proportion d’utilisateurs mécontents qui génèrent le même volume de rapports de bugs et de demandes de fonctionnalités diminue
Au final, le mainteneur a l’illusion que, quoi qu’il améliore, la perception de la qualité globale ne change pas, ce qui érode sa motivation à continuer
Je ne connais pas de bonne solution à ce problème. La réponse évidente serait de féliciter plus souvent quand les choses fonctionnent bien, mais dans la pratique, cela ressemble plutôt à un problème d’action collective qui se produit rarement
Personnellement, quand quelque chose fonctionne bien, j’essaie délibérément de donner souvent un retour positif et enthousiaste, mais tant que tout le monde ne fait pas pareil, il est difficile de produire un grand changement
Cette citation me revient en tête
« Nous remarquons toujours celui qui se penche sans cesse, s’agite et se montre servile, et nous dirons peut-être : “Comme il est humble !” Mais la personne véritablement humble ne se remarque pas. Le monde ne la connaît pas. »
~ Tito Colliander
Le passage « Le signe le plus évident qu’un outil vous sert bien, c’est que vous cessez d’en avoir conscience, qu’il devient invisible. Vous ne transformez pas ses défauts en hobby, donc vous ne les glorifiez pas ; vous les contournez simplement avec une légère irritation » me semble relever davantage de la dépendance à l’utilisateur que de l’outil
Bien sûr, différents outils attireront différents utilisateurs, et l’on pourrait sans doute mesurer une forte corrélation
Cette position manque aussi d’équilibre. Un outil n’est jamais parfait ; on se rend parfois compte qu’il peut être amélioré, et il faut alors mettre en balance l’implémentation de ce changement et son effet sur les habitudes
Plus on l’utilise longtemps, plus ces changements deviennent modestes, mais il est naturel que les usages évoluent tout au long d’une vie, et que l’outil évolue avec eux
Interprétation assez particulière
Je trouve étrange que l’auteur s’acharne à dire que Vim se « voit », tout en laissant entendre que les curseurs multiples et les fonctionnalités de Sublime ne se voient pas. Ce n’est pas parce que le cerveau a été entraîné à ne plus y penser que c’est moins visible
Les curseurs multiples ne sont pas une fonctionnalité de base dans beaucoup d’outils, et savoir les utiliser efficacement, cela s’apprend aussi. Comme les key bindings de Vim
De plus, Vim est plus qu’une option TUI pour les utilisateurs exclusivement en terminal. Ce sont aussi des key bindings utilisés par des gens qui ont appris à faire du clavier une extension naturelle de leur corps, afin de ne pas devoir sans cesse faire des allers-retours avec la souris. Tout comme les curseurs multiples peuvent jouer ce rôle pour quelqu’un qui utilise Sublime depuis 15 ans
« J’ai vu des gens expliquer à quel point il est “amusant” de créer une macro pour traiter un problème ponctuel de refactoring de texte. Mais en voyant ce qu’ils faisaient et le temps que cela prenait, ma réaction honnête était : avec les curseurs multiples de Sublime, je l’aurais fait en une minute, ou bien j’aurais simplement écrit un petit script. »
Et : « Ce qui me laisse perplexe, c’est que beaucoup de gens considèrent cette friction, c’est-à-dire l’effort nécessaire pour contourner les limites de l’outil, comme la partie “amusante”, et la présentent comme une preuve que l’outil est excellent. »
Si vous pouvez utiliser efficacement les macros Vim, tant mieux. Mais si, même après des dizaines d’années avec Vim, vous n’y arrivez pas, il ne faudrait pas présenter cela comme la partie « amusante »
Le sentiment le plus courant, c’est plutôt qu’il y a une courbe d’apprentissage, mais qu’au final cela en vaut la peine
Je ne vois pas ce que cela veut dire. Les macros Vim fournissent aussi un retour visuel direct pendant qu’on les écrit. On édite comme d’habitude pendant l’enregistrement, puis on rejoue ensuite cette édition
Il est peut-être techniquement possible d’utiliser une macro sans voir son effet en temps réel sur le texte pendant qu’on l’écrit, mais je ne l’ai jamais fait ainsi
Par curiosité, je me suis renseigné sur les curseurs multiples, et leur avantage semble être qu’il s’agit d’une interface unique facile à expliquer. En pratique, on utiliserait plusieurs commandes Vim pour les remplacer
Je suis d’accord pour dire que, pour la plupart des tâches où les curseurs multiples sont pertinents, ils peuvent être meilleurs que les macros. Mais en général, on n’utilise pas de macros pour ce genre de tâches
La plupart des choses que je fais avec des macros ne semblent pas faisables avec des curseurs multiples
S’il existe un exemple du type « dans cette situation, les curseurs multiples sont excellents et Vim n’a pas de bonne alternative », j’aimerais qu’on me démontre que j’ai tort
Cela ne veut pas dire pour autant que les curseurs multiples n’ont pas de courbe d’apprentissage. Il faut toujours réfléchir à la manière de placer les curseurs au bon endroit
J’avais déjà utilisé l’expression « invisible » pour décrire emacs magit
C’est une fine couche au-dessus de la sortie de git : elle apparaît, déduit les paramètres depuis l’état de l’UI, appelle les commandes git habituelles, puis disparaît
Léger et rapide. Peut-être pas sur de gros projets, mais c’est ce qu’on dit