Accepter et entendre la critique dans le libre
Je n’aime pas qu’on me dise comment je dois utiliser un outil/logiciel/produit. Si il est bien conçu/pensé alors son utilisation, sa prise en main sera simple et naturelle. Elle aura du sens.
Il est nécessaire de fournir une documentation évidemment. C’est une bonne chose de présenter, argumenter, justifier les choix effectués (fonctionnement, technos, architecture, UI/UX…) : Pourquoi on a fait ça, comment on l’a fait. Pourtant il y a une chose cruciale à ne pas oublier : Une grosse partie des utilisateurs ne lira pas la doc, se fout complètement de vos problématiques et justifications. Ils veulent un truc qui tombe sous le sens, qui soit pratique/utile pour eux, qui fonctionne de manière simple. Si l’utilisateur pense avoir affaire à un outil/logiciel/produit mal conçu, vos arguments et justifications n’en feront pas quelque chose de bien conçu. L’utilisateur adaptera peut-être son comportement, sera moins critique, plus compréhensif car il aura compris le pourquoi/comment mais cet outil/logiciel/produit demeurera mal foutu dans son esprit.
Je vois régulièrement ça dans le logiciel libre : « Bon c’est mal foutu mais voilà l’explication »… mais ça reste mal foutu ! C’est comme si on avait intégré/accepté l’idée que le logiciel libre est imparfait, mal fini. C’est une véritable culture. De là découle le très fameux « c’est un logiciel libre, contribue ». Non ! Il faut accepter, entendre la critique. C’est bien plus constructif que tenter une justification.
Il faut de l’empathie pour comprendre, c’est-à-dire se mettre à la place de l’autre (ici l’utilisateur). L’utilisateur dit « c’est mal foutu », on lui explique que non et pourquoi puis on lui rappelle/rétorque « tu peux l’améliorer, tu peux contribuer ». Il est intéressant de souligner que souvent on lui explique qu’il a tort en justifiant un choix technique par exemple alors que l’utilisateur donne seulement/simplement son ressenti.
J’aime bien la blague (certains appellent ça un argument) de la possibilité de contribuer. Quiconque a déjà contribué sait que c’est loooooooiiiiiiiinnnn d’être simple. En vrac complet : 1/ La doc est en Anglais, on communique en Anglais, on remonte les issues en Anglais 2/ Prenons GitHub. Il faut connaître (de « simples » utilisateurs ne connaissent pas), il faut avoir un compte, il faut savoir créer/remonter une issue ou un bug 3/ Il faut savoir. Combien d’utilisateurs sont à des années-lumière de pouvoir juste expliquer de manière compréhensible le problème rencontré ? 4/ La contribution simple, systématique, rapide, on n’est pas loin du mythe. Une pull-request peut rester des semaines/mois sans être pushée dans le projet, évidemment elle peut être rejetée. Ce n’est pas parce que le logiciel est libre que les contributions sont systématiquement acceptées et que l’accueil est chaleureux (il est souvent inexistant). Pour la simplicité, voir les points précédents
Oui il est possible de contribuer en théorie, dans la pratique c’est nettement plus compliqué. L’utilisateur signale juste un problème, il n’est pas dans une démarche/réflexion pour contribuer et même si il l’était, le chemin restant avant qu’il le fasse est long et difficile.
Une majorité d’utilisateurs est dans une position de consommateurs. L’utilisateur n’est pas satisfait, il le dit. Le sympathisant du libre, le contributeur doit se mettre à son niveau, comprendre son besoin. Il doit lui tendre la main sinon l’utilisateur restera déçu, impuissant et incapable d’utiliser l’outil/logiciel/produit pour finir par aller voir ailleurs.
Certains penseront que ce n’est pas une grosse perte. Je cite une devise Framasoft : « Parce que ce serait l’une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d’autre que du code ».
Déjà 18 avis pertinents dans Accepter et entendre la critique dans le libre
Les commentaires sont fermés.
Tcho !
Et si tu es dév et que tu ne veux pas communiquer, c’est ton droit, mais ne publie rien en ouvert, juste une page Web avec les binaires.
Moi je dis les grands esprits se rencontrent
Tcho !
Ce que tu décris est le truc le plus évident. Je voulais souligner davantage les comportements genre sur Clubic ou Next INpact où un mec dit « c’est mal foutu » (on est d’accord qu’il n’est pas vraiment dans la discussion) et un sympathisant du Libre lui répond « tu peux contribuer » (ce n’est pas vraiment de l’argumentation et aider l’utilisateur).
Tcho !
https://developer.apple.com/app-store/resources/
notamment
https://developer.apple.com/design/human-interface-guidelines/
Si je cite Apple, c’est que ce machin a quand même, depuis 30 ans au moins, apporté une interaction plutôt bien conçue avec l’utilisateur et qu’elle est largement recopiée, mais pas toujours suffisamment à mon gout
Ces guides ont été adaptés avec le temps, ils font part aussi aux technologies propres d’Apple ce qui n’est pas opportun sur les autres os, mais les principes décrits peuvent être adaptés.
Steeve Jobs était un tyran, mais il avait une vision. Si elle est bonne et qu’elle est rentrée dans les mœurs, on gagne du temps. Donc un dev doit ravaler un peu sa fierté et se conformer aux bonnes règles, on gagnera du temps. Il y a quelques fois des innovations qui sortent des clous et si elle « tombe sous le sens » alors l’interaction avec l’utilisateur sera améliorée. Cela prolonge la vision.
Je vois sur Windows il n’y a aucune cohésion entre les applications, les raccourcis clavier ont un groupe commun très réduit, alors que sous macOS le groupe commun est énorme. Ce que l’on a appris dans une application on le conserve dans une autre et on fait certaines actions d’instinct et on n’est pas obligé de réfléchir. Il n’y a pas de « friction ». Le seul truc bien vu dans Windows et en quelque sorte dans Android et manquant dans macOS c’est le ALT + TAB. Je ne sais pas si madame Michu s’en sert, mais moi beaucoup.
Je connais dans l’ordre décroissant d’usage : macOS, Linux en console, iOS, Windows XP, 7 et 10 , Android et un peu Ubuntu en desktop. J’ai eu connu AmigaOS avant Mac OS.
Tout n’est pas parfait à mon gout sur macOS et iOS, mais je pense que c’est le moins pire
Issue ca veut dire sortie dans un texte en français. Ca veut dire remontée de problème en anglais. Alors qu’on arrête avec ce franglais qui justement fait fuire le grand public et nous rend ridicule en plus quand on voit le niveau d’anglais ( j’ai halluciné encore dans une reunion cette semaine avec des autrichiens) Pour le reste je suis d’accord.
Ca fait des milliers de fois qu’on lit cette plainte: les bénévoles à qui on n’a jamais rien donné, n’en font pas assez, ça nous freine dans notre business ou nos hobbies. Et c’est pas propre au logiciel.. Et après, on fait quoi ?
Je trouve toujours ça compliqué de parler du « logiciel libre » en général dès qu’on aborde le thème du rapport développeur/utilisateur. Entre le logiciel développé pour soi même qu’on met à disposition dans l’idée « Servez-vous faites en ce que vous voulez » (ce en quoi je m’inscris un peu en faux avec le commentaire de Gilles, le binaire n’a aucune importance, si il y a une chose à publier c’est les sources) et le logiciel clairement destiné au grand public (en sachant qu’il doit exister tout un continuum entre les deux), il n’y a rien de comparable dans ce rapport dev/utilisateur.
Même dans le cas d’un logiciel destiné au grand-public, la position de consommateur n’a pas vraiment de sens. Qu’il y ait des milliers de consommateurs et un seul développeur ne fera pas avancer ce logiciel (pourquoi je pense à DFLinux ?). Ce sont les gens qui y participe qui le feront avancer. Donc, le ressenti d’un consommateur qui dit « C’est mal foutu » sans aller plus loin, ben c’est parfaitement inutile. Cela n’empêche effectivement pas d’essayer de transformer ce ressenti en information exploitable par la discussion, mais encore faut-il que le « consommateur » y passe un peu de temps, et là il devient contributeur.
C’est donc bien le contributeur qu’il faut satisfaire, pas le consommateur. Pour ma part, c’est là que je trouve que ce que fait Framasoft avec « Contributopia », c’est à dire trouver des solutions pour faciliter la contribution (qui n’est pas que du code) pour tous va dans le bon sens, et c’est comme ça que je comprends sa devise. Le logiciel libre, ça n’est pas uniquement une histoire de code, mais d’état d’esprit qui transforme le consommateur en contributeur (le consommacteur des AMAP
)
Non tu ne vas pas te faire tuer, il y a du respect ici. Je comprends ce que tu veux dire, il y a une cohérence, une continuité, une logique commune, ça apporte beaucoup à l’utilisateur dans son utilisation de tous les jours.
Tcho !
Je ne suis pas sûr d’avoir compris ta remarque. Issue(s) c’est le mot utilisé massivement, je le préfère largement à « remontées » plutôt pas terrible. Oui issue(s) c’est un terme technique probablement peu connu du grand public mais ça me semble compréhensible dans le texte et plutôt cohérent si on parle de GitHub.
Ceci étant dit je suis d’accord avec toi sur le fond.
Tcho !
Je suis désolé mais tu peux reformuler : « les bénévoles à qui on n’a jamais rien donné, n’en font pas assez, ça nous freine dans notre business ou nos hobbies. Et c’est pas propre au logiciel.. Et après, on fait quoi ? »
Tcho !
C’est ce vers quoi tendent maintenant des distributions comme Mint et Elementary, un effort sur l’uniformisation et l’esthétique des outils intégrés à leur OS respectif.
Pour Apple, il est indéniable que c’est une réussite. Le chemin pour y arriver fut autoritaire. Dans le monde du logiciel libre, c’est une autre façon de faire et cela aurait occasionné 12 forks au projet initial
Par exemple, on parle souvent d’intuitivité et d’ergonomie, et à mon avis ces deux notions sont des contraires. L’intuitivité s’adresse aux nouveaux utilisateurs, qui prennent rapidement le logiciel en main. L’ergonomie s’adresse aux utilisateurs intensifs, pour qu’ils fassent rapidement ce qu’ils ont à faire, mais cela peut nécessiter un apprentissage. À vouloir trop abaisser la barre pour que de nouveaux utilisateurs arrivent, on risque de perdre tout l’intérêt du logiciel original.
Autre point: quel est le but d’un logiciel? Quand il est commercial, c’est de faire le plus de ventes, donc maximiser les utilisateurs. Les logiciels libres sont souvent faits pour répondre à un besoin, puis sont partagés avec les autres. Avoir un maximum d’utilisateurs n’est pas la raison d’être du logiciel, et le ( souvent unique) développeur fait avec ses moyens.
Alors oui, le logiciel libre est hétéroclite et ce n’est pas forcément simple d’avoir un tout bien intégré, c’est un fait, même si cela s’est bien amélioré par rapport à il y a quelques années.
Un des problème est que peu de développeurs se soucient de développer des logiciels « agnostique » qui peuvent simplement s’intégrer a à peu près n’importe quel environnement.
Alors oui, contribuer demande de s’investir, il faut faire un effort, ce n’est pas forcément évident mais cela ne fait-il pas partie d’une philosophie? Bien entendu rien n’oblige un utilisateur à contribuer d’une quelconque manière, mais si on se cantonne dans une position de consommateur, n’est-il pas préférable de s’orienter vers des solutions qui offrent un support afin de pouvoir contacter un service qui fournira l’assistance demandée?
Prenons le cas d’un étudiant qui a développé quelque chose pour son mémoire/travail de fin d’étude ou d’une personne qui a fait un truc mais qui n’a plus le temps de s’en occuper : ces personnes pourraient très bien publier le code source de leur création afin que d’éventuelles personnes intéressées puissent s’approprier le travail effectué pour lui donner une seconde vie. C’est d’ailleurs un peu ce qui s’est passé avec Netscape, si le code source n’avait pas été publié à moment de son abandon, jamais Firefox n’aurait vu le jour !
Gnome & KDE le font depuis toujours
ElementaryOS est vraiment très beau mais amha, c’est aussi un extrême qui mise tout sur l’esthétique mais qui est bourré de bogues. Les outils intégrés sont rarement un problèmes. Là ou le bât blesse c’est au niveau de certaines applications qui ne sont pas intégrées. Par exemple les applications Qt étaient horribles sur les env. GTK+ et inversement. Pour ma part, je trouve que cela va beaucoup mieux à présent (même si cela reste perfectible bien entendu). Le gros problème reste l’ergonomie de certaines applications qui ne colle pas à l’ensemble. Cela peut en partie être du à des contraintes technologiques héritées de choix passés mais de mon point de vue, ces manques de cohésions vient avant tout des développeurs qui font peu ou pas d’effort à ce niveau ou qui ne suivent pas les recommandations de freedesktop.org (qu’elles soient bonnes ou pas).