Outils pour utilisateurs

Outils du site


ateliers:trdesignopensource

Table Ronde sur le Design Libre et Open Source

  • Dernière Table Ronde : le 4 Juin 2017
  • Prochaine table ronde : non défini
  • Lieu de l'atelier : La Mutinerie (à Paris)
  • Matériel nécessaire : Votre ortinateur si vous le souhaitez !
  • Niveau de l'atelier : tout contributeur du libre intéressé par le design est convié !
  • Organisation : Hypsoline

Compte rendu du 12 février 2017

Nous étions nombreux lors de la table ronde sur l'Open-Source (OS) et le design. Beaucoup de designers étaient présents par rapport aux développeurs, et toutes les personnes ont exprimé leur intérêt pour le logiciel libre et open-source. Mais de la même manière, beaucoup de retours d'expérience négatifs ont été présentés sur la manière dont il est possible de contribuer au logiciel libre quand on n'est pas développeur. La table ronde était une première rencontre afin de travailler sur les ponts possibles entre ces deux milieux. S'intégrer dans un projet libre n'est pas simple, au-delà de la connaissance du projet, d'autre obstacles ont été identifiés comme les rapports entre développeurs et designers (qui ne sont pas inhérents au libre mais où le logiciel propriétaire à des méthodes de travail, le libre n'a pas de réponse). Beaucoup se sont aussi exprimés sur la difficulté d'utiliser des outils développés pour des développeurs lorsqu'on n'est pas développeur ainsi que la manière dont un outil formate la manière dont on contribue à un projet. La logique du « pull request » a beaucoup été remise en question. En plus des outils, un développeur n'est pas designer et l'inverse est vrai aussi. Quelles sont les approches de design qui pourraient être abordée ? L'UX/UI (User Experience / User Interface) a souvent été mentionné par des développeurs pourtant le design ne se cantonne pas qu'à ça. Il s’agit aussi d’importer la notion de direction artistique dans les projets libres. Comment organiser le travail entre développeur et designer ? Comme intégrer des designers et a fortiori, des non-développeurs dans un projet OS ?

L'outil, comme base de la pensée et de la participation

Une chose est certaine : la réflexion du logiciel libre est partie de l'outil, de la liberté de l'utiliser, de le modifier, de le partager. C'est l'outil qui sert aussi aux libristes à participer à différents projets. C'est donc une conséquence attendue que l'outil forme la pensée et les pratiques. Très souvent, un logiciel libre est créé pour répondre à un besoin direct du développeur, la réflexion de l'utilisation est plutôt orientée vers des utilisateurs identiques. Le besoin répond à une cible particulière et n'est pas pensé dans sa totalité (sans design, donc) parce que ce n'est pas l'origine de sa création. Pourtant, le logiciel libre, l'open-source, sont des pensées et des méthodes de création qui se démocratisent et qui rencontrent d'autres utilisateurs qui ne sont pas les publics historiques. Cela amène de nouveaux défis, notamment celui de l'inclusion de publics variés dans les processus de création et de développement. La méthode du « pull-request » instaurée par des méthodes comme Git, est adaptée pour des développeurs mais pas pour des designers, encore moins pour les autres contributeurs. C’est d’autant plus vrai lorsque la demande ne se résume pas à l'amélioration d'un pictogramme ou d'une bannière, mais concerne un projet global de communication. Le travail du designer amène non seulement les questions d’ergonomie (première chose à laquelle les développeurs sont sensibles) mais aussi de direction artistique. C’est à dire adapter son produit en fonction de la cible, comment communiquer auprès de celle ci, mise en place d’une stratégie pour toucher et répondre à un public en besoin (souvent monopolisé par des produits propriétaires) Une incompréhension a été reconnue entre les développeurs qui ne comprennent pas le travail d'un designer et vice-versa. Il est reporté un manque de pédagogies des deux cotés. Les deux groupes se retrouvent donc à avoir des difficultés à collaborer sur un projet, par ce que ne parlant pas le même langage, n’abordant pas le projet de la même manière ni les même problématiques. Le manque de représentativité des différentes capacités, la supériorité numérique des développeurs est aussi vécue comme un frein. Si le graphisme se voit de tous ce n’est pas pour autant que cela permet à chaque personne capable de voir d’être un expert en stratégie de communication. Par ce manque de compréhension de sa valeur, il n'est pas toujours aisé pour un nouveau ou nouvelle designer de s'intégrer à un projet et de trouver ses marques. Particulièrement si ses propositions risquent d'être prises comme une remise en question du travail déjà effectué. Le designer au lieu d’effectuer un travail de fond, de direction artistique, se retrouve à faire des créations ponctuelles qui peuvent rester au fond d’un ticket pendant des années par ce que jugé comme non urgentes comparées à des aspects plus techniques nécessitant de manier / corriger du code.

« Inscris-toi à la mailing-list et rejoins le canal IRC »

La question de la participation d'un designer (ou de tout autre personne non-développeuse) à un projet OS reste sans réponse malgré le partage du constat problématique actuel. Plusieurs pistes de réflexions ont été établies :

  • Adaptation de l'outil : quel outil pour quel usage ? Est-ce que Git est adapté à la participation de tous (designer, développeurs, autre contributeur) ? Vu que cet outil est orienté vers le code, comme un designer pourra-t-il l'utiliser ? Serait-il possible d'envisager d'autres interfaces pour faire communiquer différents groupes de travail ? Est-ce qu'il existe des alternatives à Git pour inclure le maximum de personnes non-développeurs dans un projet ? De la même manière, est-ce que IRC ou les mailing-lists, les pads qui sont l'alpha et l'omega de la culture du logiciel libre, sont adapté à d'autres publics et sont efficaces ?
  • Comment penser la gestion de projet dans le libre quand nombreux sont les projets qui ont vocations à être utilisé par tous ?
  • Comment aller voir des utilisateurs du libre pour comprendre ce dont ils ont besoin lors de leur utilisation quotidienne d'un projet ? De nombreuses personnes ont relevé l'importance de l’inclusion des non-contributeurs dans le processus par exemple via des sondages, comprendre la recevabilité de la communauté, de la culture du travail dans le logiciel libre…

Un constat amer qui résume une partie des discussions est celui-ci : « Les solutions propriétaires gagnent parce que le libre ne se pose pas la question des utilisateurs. » Un exemple abordé parmi d’autres qui illustre ce constat est la manière dont InDesign a siphonné les utilisateurs de Quark. La différence est que le logiciel propriétaire est tourné vers l'extérieur de lui-même : ses clients. Il faut que le client soit content et donc achète ou consomme le produit. Un logiciel libre est fait par une communauté et le plus souvent pour une communauté. Autant que cette tendance change et se modifie dernièrement, c'est le moment de faire bouger les lignes et de tenter de nouvelles expériences. La discussion ne doit pas relever que de la question de l’UX/UI, ou autre considération superficielle comme la couleur de tel ou tel bouton, mais poser des questions de fond sur sa communication. Plus encore, des ponts de compétences peuvent se créer par plus de communication sur les projets qui gagneraient en crédibilité et en participation. Un des grands avantages qu'à le logiciel libre par rapport au logiciel propriétaire est qu'il est possible d'expérimente. Il y a une communauté qui est prête à mettre la main à pâte pour faire avancer les choses. Nous en avons un bon exemple avec Mastodon, qui permet à chaque instance de mettre en place un fonctionnement et un design d’interface différent avec des spécificités propres à un public spécifique. Daltonien, malvoyants, etc. La souplesse que permettent les milieux décentralisés est à exploiter. Le problème n’est donc pas du manque d’envie ou du bénévolat, mais de la façon dont tous ensemble nous collaborons.

Instaurer des bonnes pratiques


Il ne s’agit pas de remettre en cause le travail de chaque projet libre et de venir caller un designer dans chaque équipe. Le libre est une culture riche. Au même titre que l’art, il faut plusieurs approches car il y a plusieurs publics.
L’ambition au sein du Reset est de permettre à ces publics de se rencontrer, de discuter, se remettre en question et instaurer des méthodes de travail pour permettre à des petit projets de voir le jour ou d’être améliorer. Pour les utilisateurs, par les utilisateurs, développeurs, designers, contributeurs et curieux compris, qu’importe le niveau de compétence. La stratégie, le design, la traduction, la communication font autant le produit que le reste. Prendre en compte la valeur que chacun peut apporter et la valoriser est un premier pas à faire. Le but de tout le monde est que le projet marche. Un travail d’inclusivité, de bienveillance et de pédagogie est primordial. 
Cela passe par inclure d’autre corps de métiers que des développeurs, mais aussi des femmes et autres minorités. Cela permettrait entre autre de mieux penser certains aspects que le milieu du libre à majorité masculin ne rencontre pas. Comment aborder la question du genre ou du sexe dans un formulaire d’inscription ? Comment prendre en charge le cyber harcèlement dans la messagerie? Comment rendre lisible pour touTes, cette interface ? Quelle alternative aux pictogrammes pour que les personnes autistes puissent utiliser ce produits sans difficultés ? Accueillir les nouvelles personnes et permettre à tout le monde de travailler aisément passe par définir clairement le projet. Savoir l’expliquer sans trop jargonner, savoir définir à qui il s’adresse, ses contraintes. Cela peut aider en amont à réajuster la direction d’un projet, mais aussi de permettre à tout le monde, novice comme habituée de se sentir mieux accueilli et de partir avec des bases saines de travail. Dites ouvertement où vous avez besoin d’aide, ce qui est en train de se faire, où telle ou telle personne pourrait se greffer si elle le souhaite. Les personnes habitués à participer à des projets libres peuvent encadrer les novices. Cela permet de souder une équipe en plus d’aider les nouveaux. Parlez des outils avec lesquels chacun travail afin de vous mettre d’accord du meilleur moyen de collaborer. Tous les designers ne bossent pas sur les même logiciels, tous les gens ne sont pas à l’aise avec les pads, certains sont perdu sur un wiki. Adaptez vous ! Bien s’entourer, à petite échelle et se faire confiance. 
S’éparpiller et s’entourer de trop de monde peut être à double tranchant. Si il est important d’être ouvert à la critique extérieure venant de personnes novices il faut savoir faire confiance aux personnes compétentes. Les avis personnels, les ressentis non étayés voir condescendants, qui manquent d’encrage dans le réel peuvent être contre productif pour un projet. Si vous avez jugé qu’un developpeur / designer / traducteur / autre digne de confiance pour vous rejoindre, laissez lui mettre en applications ses compétences sans toujours les remettre en question. Toute critique n’est pas toujours bonne à mettre en application.

Ressources et autres lectures :

Designers, Women, and Hostility in Open Source http://smarterware.org/2011/03/designers-women-and-hostility-in-open-source/

The Intimidation Barrier http://opendesign.foundation/articles/barriers-for-designers/

How to get designers (or anyone) to work on your open source project http://opendesign.foundation/articles/import-designers/

Le design dans le libre : pistes de réflexion http://mariejulien.com/post/2017/02/08/Le-design-dans-le-libre-:-pistes-de-r%C3%A9flexion

UX et logiciels libres : retour d’expérience (TAILS) http://romy.tetue.net/ux-et-logiciels-libres-retour-d-experience-tails

L'ergonomie, indispensable à l'adoption massive du libre - Matthias Dugué - Luc Chaffard
 https://www.april.org/l-ergonomie-indispensable-l-adoption-massive-du-libre-matthias-dugue-luc-chaffard

L’exemple d’InDesign et Quark : https://arstechnica.com/information-technology/2014/01/quarkxpress-the-demise-of-a-design-desk-darling/

Usability in Free software : http://jancborchardt.net/usability-in-free-software


How designers detroyed the world https://vimeo.com/68470326

Quelques astuces pour gérer vos designers-divas en mode associatif http://weblog.redisdead.net/main/post/2017/03/30/Quelques-astuces-pour-gerer-vos-designers-divas-en-mode-associatif

Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. https://opensource.guide/code-of-conduct/

ateliers/trdesignopensource.txt · Dernière modification: 2017/07/19 14:39 par hypsoline