MARIE & JULIEN

101 réactions

• 1 De pyg - 09/02/2017, 00:03

  Merci. Merci ! Merci !!!
  D'abord, j'ai appris (ce qui n'était pas dur), et j'ai ri (déjà plus touchy) en lisant ton article.

  Attention, hein, j'ai pas dit que j'étais d'accord avec toi sur tout pour autant
  Il y a pas mal de choses, même, où je pense que tu caricature en prenant un exemple pour en faire une généralité (si je prends le tweet de Bortzmeyer, par exemple, il est clair qu'il n'est pas représentatif, et surtout je doute qu'il se soit jamais plein de l'aspect graphique d'un outil).

  Ensuite, tu as je pense identifié dès le départ le point bloquant sur lequel je n'arrivais pas à mettre le doigt : oui, un projet libre *devrait* intégrer dès le départ un designer/communiquant. Maintenant, comme tu le fait remarquer dès le début de ton billet, un développeur libre commence souvent seul, et souvent sans moyens (et quasi-systématiquement sans autre compétence que celle de développeur).

  Du coup, j'entends parfaitement ta remarque, mais je fais quoi moi ?!

  Par exemple, je veux développer Framapétitions (une alternative à Avaaz/change dont les modèles éco, le traitement des données perso, et la taille très importante ne me conviennent pas). Techniquement, pas de souci, je sais le faire. Mais j'ai mes propres contraintes : j'ai en gros 4 à 8j ETP à y consacrer (je voudrais avoir plus, mais ce n'est pas possible, sauf si vous me trouvez un moyen de passer les journées à 48H ).

  Je veux bien faire appel à un-e designer, mais... où je la/le trouve ?
  Combien de temps passer à la/le chercher ? Comment entamer une relation de confiance sur un projet qui, soyons honnête, ne rapportera pas un kopek (j'aime beaucoup Cozy, mais ils ont fait le choix d'un modèle éco qui est différent du notre, leur ouvrant des capacités de financements que je ne peux pas envisager pour une asso comme Framasoft).

  Alors bon, certes, j'en entends déjà qui vont dire "Ben vous n'avez qu'à avoir un modèle éco qui permettent d'embaucher un designer". Certes, mais non en fait Libre ne veut pas dire gratuit, mais je fais partie de ces sales anarcho-libertaires qui ne veulent garder l'économie en périphérie des projets libres (ce qui ne signifie pas l'exclure pour autant, hein, juste ne pas en rendre le logiciel dépendant).

  Je n'ai pas de désaccord profond avec ton billet, mais j'aimerai y apporter quelques compléments (qui serviront peut être dimanche, même si - snif - je ne pourrai être là).

  Premier point : comme dit plus haut, il faut prendre en compte la réalité de l'histoire d'un logiciel libre. Souvent, il n'y a pas "d'architecte", tout simplement parce que quand tu te lance dans un logiciel libre (à moins d'un gros projet à la Firefox), tu veux juste un outil qui réponde à *ton* besoin de développeur. Je pense que 80% au moins des logiciels libres sont conçus sans avoir d'autres publics que leur auteur au départ (statistique fournie gracieusement par l'Institut de la Louche). Même des projets très répandu comme VLC ont commencé sans avoir en tête "Tiens on va juste rentrer dans le top 5 des players vidéos les plus utilisés de la planète" ou Linux ("I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)").
  Vraiment, je pense que #lesgens doivent garder cela à l'esprit.

  Ca ne veut pas dire qu'on se moque des utilisateurs, juste que souvent, ben l'utilisateur, c'est l'auteur.

  2. Longtemps, les designers ont boudés le logiciel libre.
  C'est en train de changer. Doucement. Des gens comme toi, ou Geoffrey Dorne, ont même clairement fait des appels du pied en disant "Je peux aider".
  Mais ça fait 15 ans que je fais du libre, et c'était très, très marginal avant. Ca l'est juste un peu moins maintenant. Et c'est très bien.

  Je pense que si on veut faire évoluer les choses, il faut donc continuer à sensibiliser les étudiants en design au libre (pas seulement logiciel). Ca avance aussi de ce côté là. Après, les étudiants feront leurs propres choix (comme un étudiant en info peut parfaitement choisir de faire du proprio, mais il n'aura pas pu passer à côté du libre dans ses études).

  Car c'est à force de collaborations que ces 2 (ou plus) communautés finiront par vraiment infuser l'une dans l'autre, à terme. En tout cas, je veux y croire.

  3. Que faire des projets "déjà entamés" ?
  Je te rejoins vraiment à 100% que dans l'idéal, il faut penser stratégie/public/design/comm dès le départ. Ca, c'est la situation idéale.
  Maintenant, pour la raison expliquée au premier point, ça n'est souvent pas le cas. Donc je me/te pose la question : que faire dans ce cas là ?
  On se dit que c'est mort et on laisse tomber ? (c'est pas une question provoc, la réponse peut être "oui").
  Là encore, ton article est éclairant sur le fait que c'est l'enfer pour un-e designer de bosser sur un projet libre. Je ne le voyais pas comme ça, et j'y prêterai donc bien plus attention à l'avenir (promis !).
  Maintenant que le constat est fait, que pouvons nous faire pour améliorer la situation ? Je veux dire concrètement ?
  Je note tes propositions :
  * lâchons prise et ayons confiance dans la/le designer/communiquant-e
  * limiter les décisionnaires et juger par rapports aux objectifs initiaux
  Sur ce dernier point, tu ne t'en rends peut être pas compte, mais ça bouscule beaucoup de choses pour le libriste qui est en moi (et c'est très bien !!! ). C'est un conseil simple et applicable facilement, même s'il réclame des changements de pratique.

  Je trouverais extrêmement interessant, si ça n'existe pas déjà, un petit guide "Recommandations pratiques du designer adressé aux dév", avec ce genre de conseils dedans. Car ce qui parait pour vous une évidence ne l'est probablement pas pour nous.

  Bref, encore merci pour cet article fort intéressant, qui (r)ouvre un débat qui l'est encore plus

  (PS : mon commentaire est à chaud, en vrac, et très - trop ? - long. Vire le si tu veux, je ne t'en voudrais pas, promis )

• 2 De Julien - 09/02/2017, 00:30

  À chaud sur le chemin du dodo également :

  >Je veux bien faire appel à un-e designer, mais... où je la/le trouve ? Combien de temps passer à la/le chercher ?

  La trouver c'est pas très dur, en combien de temps, ça dépend, pas plus ni moins qu'un bon dev/inté/whatever

  >passer du temps sur un projet qui, soyons honnête, ne rapportera pas un kopek

  C'est pas forcément un problème si ça profite à tous (on est pas dans le cas d'exploitation de travail gratuit à des fins mercantiles)

  >Je pense que 80% au moins des logiciels libres sont conçus sans avoir d'autres publics que leur auteur au départ

  Ce qui n'est pas un problème… Au départ

  >Longtemps, les designers ont boudés le logiciel libre

  J'ai pas ce sentiment. Par contre on peut dire que longtemps les designers ont boudé les logiciels libres inutilisables *tousse* the gimp *tousse*.

  >Que faire des projets "déjà entamés" ?

  S'il y a une volonté de communiquer / de les améliorer : c'est loin d'être mort, il suffit d'accepter les contributions design et même marketing (brrr). Et écouter. (exemple d'un échec frappant : le logo spip)

  Suivre les 2 conseils que tu cites et les solutions apportées dans ce billet devraient suffire à améliorer largement les choses. On ne perd pas espoir.

  Le guide est une bonne idée sur le papier, mais encore une fois il n'y a pas vraiment de guide dev > designer, parce qu'on a intégré que le dev était un métier à part. C'est peut être un peu sec mais il faudrait que les devs acceptent de juste s'asseoir et de regarder bosser les pros sur des sujets qui les dépassent. On veut bien expliquer comment travailler globalement, mais pour aller plus loin le mieux c'est d'étudier le design, qui est un métier (si si).

• 3 De pyg - 09/02/2017, 00:42

  (moi aussi sur le chemin du dodo, car train pour Paris dans ... pas longtemps :P )

  Juste un truc :
  > On veut bien expliquer comment travailler globalement, mais pour aller plus loin le mieux c'est d'étudier le design, qui est un métier (si si).

  Je me suis mal exprimé, je ne veux pas d'un guide "le design pour les dév", mais je me demandais plutôt s'il existait un ensemble de recommandations de "Comment faire pour que le dev et le designer s'entendent et s'écoutent ?"

  Je suis quasi-sûr que d'autres designers et dev proposeront d'autres idées dans les commentaires

• 4 De Hugopoi - 09/02/2017, 01:33

  Il est tard mais :
  L'ergonomie de certain logiciel libre est à revoir et là je suis d'accord, il faut faire avancer les choses.
  Cependant le design/beauté n'apporte pas grand chose, cdiscount est toujours aussi moche mais toujours aussi rentable. Donc les fonctionnalités et l'ergonomie sont le cœur du logiciel.
  Enfin je penses que le logiciel libre est avant tout pensé comme un outil et pas un produit. Donc il y a généralement pas de stratégie si ce n'est répondre aux besoins du mieux possible.

• 5 De Roukow - 09/02/2017, 07:30

  @Hugopoi, je pense que si Cdiscount est "moche", c'est aussi lié à une stratégie visuelle : les discounts st svt liés à des couleurs flashy, des bonnes grosses promos qui hurlent "pas cher"!! Du coup c'est pe moche mais c'est sans doute à dessein... à mon sens
  Cool réflexions en tt cas ac cet article !

• 6 De Migus - 09/02/2017, 09:16

  C'est tres intéressant à lire, mais vous comparez des choux et des carottes. Avez vous deja vu le look calamiteux des applications en entreprise ? Juste que l'on ne fait pas les investissements dedans. Si les investissements ne sont pas fait, c'est que des managers l'ont décidé ainsi. Donc vous prêchez pour votre paroisse, mais vous en avez pour au moins 10 ans.

  Le monde de l'IT ne se limite pas aux jeux vidéos et au ouaib.

  Petite anecdote. Dans mon travail, je vois regulierement des AS400. Pour ceux qui ne connaissent pas imaginez un ecran de minitel. Suivant le trends, Les utilisateurs sont migres sur des interfaces graphiques. Sauf que les utilisateurs expliquent qu'ils allaient plus vite avec l'as400, qu'ils comprenaient l'enchainement et ils avaient des raccourcis clavier. Aujourd'hui, ils ne comprennent pas toujours les interfaces graphiques, et developpent des troubles musculo-squeletiques.

  Donc oui il faut travailler sur l'ergonomie des apps, mais SVP, allez faire un tour en entreprise avant de dire que le logiciel libre est à la traine...

• 7 De JulienW - 09/02/2017, 09:46

  Lors de mon boulot sur Firefox OS, je me permettais de critiquer (constructivement, enfin je crois) le boulot des UX et visual designers. Après, soit ils prenaient en compte ma remarque, soit pas, mais toujours avec une explication. Et en fin de processus, c'est toujours eux qui avaient le dernier mot sur ces domaines.

  Je crois qu'en travaillant ainsi on avait obtenu des bons résultats.

• 8 De nylnook - 09/02/2017, 10:13

  Le constat me semble assez grossier et peu étayé même si tu as eu une mauvaise expérience...
  Pour le projet libres avec un véritable design tu peux au moins ajouter :
  - Blender
  - Inkscape
  - Gnome
  - KDE
  - Cura
  - Atom
  - Godot
  - ...

  Ça se résume souvent à une question de moyens et d'organisation des projets. Bref, exactement comme pour les projets propriétaires. Ce n'est pas plus simple quand on arrive dans une entreprise où tout le monde veut choisir les couleurs sur un projet.

• 9 De Julien - 09/02/2017, 10:17

  @nylnook : j'ai arrêté de lire la liste à "blender"

• 10 De Natouille - 09/02/2017, 10:30

  @pyg : je pense que le tweet de Bortzmeyer était sarcastique

  Il y a peu, j'ai filé un coup de main sur un projet open source. Ils avaient déjà développé pas mal de fonctionnalités mais partaient dans le mauvais sens. Après avoir eu une discussion en vrai avec 2 dévs de l'équipe (oui le IRL aide beaucoup à faire passer les idées), le reste s'est fait via les zinternets. Et quand j'ai proposé de revoir pas mal d'écrans et de leur refaire un proto, on m'a dit "non, mets des screenshots en issue sur GitHub". Ce qui revenait à faire le pompier à coup de rustine, chacune corrigeant un point mais ne prenait pas en compte l'ensemble.

  Sinon, lors d'une conférence libriste, un intervenant a eu ce joyeux discours :
  "D'un côté il y a la ligne de commande qui permet d'être libre et de maîtriser ce qu'on fait et de l'autre il y a l'UX design à la Google".
  Depuis, il est revenu sur ce point mais nombreux sont les libristes qui croient dur comme fer que l'utilisateur DOIT apprendre la ligne de commande si il veut passer au libre.

• 11 De Julien - 09/02/2017, 10:32

  @Natouille : avec le fameux terme infâmant de "clicodrome" pour dire "nul parce qu'il faut utiliser une souris".

  IMAGINE, des utilisateurs qui utilisent une interface qui leur plait… brrrr

• 12 De Peha - 09/02/2017, 10:34

  Des dev qui ne comprennent même pas l'utilité d'une interface graphique, ça existe, j'en ai rencontré. ("seul le terminal permet un réel contrôle de sa machine" lol)
  Et c'est évidemment impossible de discuter avec eux de design graphique.

  En moins extrême, mon expérience est que bp de gens trouvent plaisant de "choisir des couleurs" comme ils choisiraient la tapisserie de leur salon, et ne comprennent absolument pas qu'il puisse exister d'autres enjeux que "j'aime / j'aime pas".
  C'est la petite pause agréable et rigolote du projet et y'a pas de raison que seuls les graphistes aient le droit de "s'amuser."

• 13 De f4b1 - 09/02/2017, 10:40

  Cet article vraiment très intéréssant, je ne suis pas designer mais plutôt dev, et je n'avais pas imaginé la problématique sous cet angle. Merci pour le point de vue !

• 14 De Peha - 09/02/2017, 10:41

  Perso, j'ai fait une licence pro dont l'objectif n°1 était de faire bosser des dev, des chefs de projets et des graphistes ensemble.
  C'était hyper enrichissant, mais ça suppose que chacun se forme à minima dans le domaine de l'autre, avoir l'idée spontanément n'est pas évident.

• 15 De Peha - 09/02/2017, 10:49

  Peut être que la solution serait d'arrêter de laisser aux devs l'exclusivité des initiatives libres (j'exagère à peine) ?
  Les designers pourraient concevoir des projets, et recruter des devs ensuite ?

• 16 De AD - 09/02/2017, 11:08

  @nylnook : j'ai arrêté de lire la liste à "blender"

  Aïe, aïe, aïe... Quelqu'un qui n'a jamais travaillé sur des logiciels pro.

  La "beauté" est toute relative, bien entendue. Les gros logiciels (d'adultes) n'ont pas nécessairement besoin d'un joli design, ils ont besoin d'être efficaces (efficacité de l'IHM) donc ergonomique.

  Bortzmeiyer vs Dubedout, il y a comme un déséquilibre. Je fais dans l'efficacité, la connaissance vs je fais des jolis dessins (mais je suis adulé des graphistes et DA, donc on me défendra toujours becs et ongles sur tous les réseaux sociaux et les blog).

  Pour rester sur le design - sinon on te perd - : Softimage, Blender (le seul open source de la liste, qui ne l'était pas à l'origine), Maya, Catia : autant de logiciels "moches" mais tellement efficaces et qui donnent de tellement belles images !

  Toi, tu t'amuses, les autres, ils bossent Mais c'est ta voix que l'on entend car toujours relayée par ton fan-club. C'est certain, ce dernier n'ira pas lire le blog de Bortzmeyer...

  Donc pour conclure, on ne veut pas du design, on veut de l'ergonomie. Et je suis le premier à dire que la plupart des logiciels, open-source ou non, en manque énormément.

• 17 De enwin - 09/02/2017, 11:11

  Je voudrais répondre sur un point précis de @pyg. Vu que Framapétitions est encore en chantier, et à moins que tu te sois fixé une date de livraison, est-ce que ce ne serait pas le moment de prendre du temps pour trouver un•e designer ? Soumettre tes attentes en termes de fonctionnalités et avancer ensemble sur les parties visuelles et fonctionnelles ? Et, pourquoi pas, poser une nouvelle charte graphique pour Frama* en partant de Framapétitions ? (Je m’emballe.) Je pense que plusieurs personnes ici seraient prêtes, au moins, à publier ta recherche de designer.

• 18 De Antoine Cezar - 09/02/2017, 11:18

  Et si plutôt que les développeurs c'était les designers qui lançaient les projets ?

• 19 De pyg - 09/02/2017, 11:30

  @Peha : oui, nul doute que ça serait interessant. Maintenant, comme expliqué plus haut : je pense qu'il y a mécompréhension sur ce qu'est un logiciel libre. Il est très rare qu'un logiciel libre démarre avec *l'intention* de devenir utilisable par d'autres personnes que son auteur.
  Eric Raymond écrivait déjà en 99 dans La cathédrale et le Bazar (qui est un des textes fondamentaux du libre) : "1. Tout bon logiciel commence par gratter un développeur là où ça le démange. "
  Dans ces conditions, c'est le dev qui est à l'origine du projet (ce qui peut être une mauvaise chose, on est d'accord)

  Par contre, oui, on peut imaginer l'inverse : un designer qui aurait l'envie de se lancer dans un soft et qui chercherait des dév ensuite (j'ai déjà vu des cas sur Dribbble).

  Bref, dans cette réfléxion sur design et libre, j'apprends qu'il faut par exemple limiter le nombre de décisionnaires, mais si je peux me permettre d'apprendre un truc aux designers, ça serait de discuter avec les développeurs originaux (=/= la communauté) pour connaître l'historique d'un projet et les ressources qu'ils sont derrière.

  Le cas de Gimp, cité par Julien, est interessant, car sans juger de son ergonomie (évidemment largement critiquable), je doute que beaucoup de designers sachent quelles sont les ressources de Gimp (personne n'est payé, une poignée de développeurs bénévoles font ce qu'ils peuvent sur leur temps libres). Lire par exemple https://linuxfr.org/news/entretien-... peut être très instructif

  Bref, je me répète, mais je pense qu'il y a là deux visions très différentes du libre :
  * les utilisateurs et designers nous voient parfois comme des (bisoun)ours mangeurs de pizzas/bières, complètement fermés au design, ne jurant que par la ligne de code, mais voulant changer le monde à coups de logiciels sur AS400
  * la réalité, c'est qu'on est souvent *de bons maçons sans architecte* ! On fait une maison au départ parce qu'on a *besoin* d'un toit. Pour nous. Maintenant. Tout de suite. On ne veut pas la Trump Tower. Juste se mettre à l'abri. Et là débarquent les utilisateurices. C'est chouette. Mais c'est pas confortable. Alors on retape, on aggrandi. Et là, on a des designers/communiquants qui viennent nous dire "Mais elle est toute pourrie, votre bicoque ! Fallait penser l'espace comme si ou comme ça." etc.

  Et merde, ils ont raison ! Oui, il aurait fallu le faire comme ça. Mais au départ, quand on a construit notre maison, on ne pensait pas, on aurait même jamais rêvé qu'elle accueillerait des milliers de personnes. On voulait juste se protéger de la pluie !

  Pour moi, cette métaphore du maçon sans architecte résume assez bien le débat actuel.
  * certains maçons s'en foutent de l'architecture, du design, ou des habitants. Ils font un trucs pour eux. "T'es pas content ? Rajoute tes briques."
  * d'autres *veulent* y faire attention (c'est mon cas, je pense), mais ont des contraintes fortes (temps/argent) qui font que si on leur montre des super-plans au départ, on va juste laisser tomber ("Désolé, mais tes plans sont trop ambitieux pour moi, là, je ne peux pas gérer ça, je n'en ai pas les moyens")
  * d'autres sont des maçons très ambitieux, ils veulent louer leur habitation dès le départ, et savent donc qu'ils leur faut faire appel à des compétences qu'ils n'ont pas (architectes, designers, etc). Dans ce cas là, le projet peut être un succès. Mais ils ont des moyens importants (ex: Firefox, Wordpress). Ce cas est bien évidemment possible, mais il n'est pas généralisable, tout simplement car rares sont les projets ayant cette ambition dès le départ.

• 20 De Gaëtan - 09/02/2017, 11:34

  Je note que l'article fait l'impasse sur 2 choses qui se recoupent:

  L’absence de la culture de la contribution dans les métiers créatifs.
  Cette absence est à mon avis issue de nombreux facteurs historiques et identitaires. Le résultat est qu'il y a un certain dédain pour la contribution au libre parmi ces métiers. Par effet de cercle vicieux : les logiciels sont moches je ne vais pas les utiliser ni y contribuer, ma suite Adobe ne tourne pas sous Linux je ne vais pas l'utiliser ni y contribuer. On pourra prendre pour preuve les nombreux quolibets (dont le fond est surement souvent juste) sur les environnement et système libres.

  Le faible développement et connaissance des licences libres adaptées au design et plus généralement des outils techniques permettant ces contributions.
  La licence GPL date de 1989 et les licences Creative Commons en 2002 seulement ! Il n'est d'ailleurs pas rare que leurs principes soient absolument méconnus des métiers graphiques, la plus part des freebies trouvables sur le net ne précisent aucune mention, souvent tout juste le très flou "free".

  On peut aussi préciser que pour créer un logiciel/application, le plus petit dénominateur c'est le code qui en quelque sorte défini son existence. C'est donc assez peu étonnant que le design passe souvent au deuxième plan. C'est d'ailleurs notable dans toutes les évolutions technologiques du secteur numérique, l'innovation se fait avant tout dans les outils techniques pour les développeurs, puis les métiers créatifs s'adaptent aux nouveaux usages.

• 21 De Nico - 09/02/2017, 11:37

  > La trouver c'est pas très dur, en combien de temps, ça dépend, pas plus ni moins qu'un bon dev/inté/whatever

  Je n'ai pas eu cette expérience : pour plusieurs projets en accessibilité (pas pour moi à proprement parler, et quoi qu'on en dise, c'est un domaine où il y a vraiment BESOIN de designers/UX/ergo/toussa), je me suis cassé les dents pendant des mois pour trouver un designer : très peu de réponses et toutes négatives.

  Qu'on soit clairs : je ne leur reproche PAS de refuser, c'est leur droit

  (d'ailleurs, in fine, qq mois plus tard, j'en ai trouvé une géniale qui s'appelle Enza et qui a fait un job d'enfer, sur Van11y.net pour ne pas le nommer)

  > C'est pas forcément un problème si ça profite à tous (on est pas dans le cas d'exploitation de travail gratuit à des fins mercantiles)

  Le fait que ça martèle régulièrement sur le travail non-rémunéré (ce que je comprends tout à fait et que je ne discute pas) fait que c'est un peu délicat quand tu as un petit projet mais sans budget (quand tu paies le dev en le faisant toi-même, l'hébergement, le NDD, etc.).

  Perso, j'ose à peine demander, de peur de me faire descendre en flammes.

• 22 De pyg - 09/02/2017, 11:48

  @enwin :
  > Je voudrais répondre sur un point précis de @pyg. Vu que Framapétitions est encore en chantier, et à moins que tu te sois fixé une date de livraison, est-ce que ce ne serait pas le moment de prendre du temps pour trouver un•e designer ? Soumettre tes attentes en termes de fonctionnalités et avancer ensemble sur les parties visuelles et fonctionnelles ?

  Ha mais moi je veux bien. Mais il faudra que ces personnes comprennent et acceptent mes contraintes. A savoir que j'ai prévu 4j de dév ETP dessus, et que je peux tirer jusqu'à 8j ETP (j'ai aussi l'équivalent de 2j "d'à côté", dont la promotion). Si le service ne peut pas sortir dans ce délai là, alors il y a de fortes chances qu'il soit repoussé sine die
  Dans ce cas là, tout le monde sera déçu : moi, les designers, les communiquants, les utilisateurs, nos donateurs.... Et ça, je veux absolument l'éviter.

  Evidemment, il peut être amélioré par la suite, mais il faut qu'il soit fonctionnel dans les 4/8j ETP de dev.

  Si vous pensez que ça peut interesser un-e designer, je peux donc consacrer les 2j que j'avais prévu sur la comm aux échanges avec cette personne. Mais je ne pourrais sans doute y consacrer plus (Framasoft, c'est actuellement 31 services libres et ethiques en ligne, et on a beau avoir une super équipe, on est déjà à 200%, et sans possibilité de tirer plus sur la corde).

• 23 De le Dev de base - 09/02/2017, 11:58

  Peut être que la solution serait d'arrêter de laisser aux devs l'exclusivité des initiatives libres (j'exagère à peine) ?

  => libre a qui veut de créer du libre.

  Les designers pourraient concevoir des projets, et recruter des devs ensuite ?

  => "recruter" ?...

• 24 De Xavor - 09/02/2017, 12:05

  Des projets de libre par des designers ça existe:
  http://osp.kitchen/
  http://freeze.sh/dok

• 25 De Shirak - 09/02/2017, 12:10

  Bonjour, cool cet article

  Du coup vous seriez dispo pour travailler sur un projet libre et nous prêter vos skills de designer / directeur artistique / ergonome / retoucheur de peinture caca ?

• 26 De Lunar - 09/02/2017, 12:13

  Merci pour l'article. C'est des discussions dont on a besoin.

  Merci à pyg d'avoir donné ses éclairages sur comment se passe le développement de la plupart des logiciels libres. Je suis d'accord avec sa vision, et ce sont des précisions utiles vu que certains aspects de l'article me semble décalé par rapport à ma connaissance des processus de développement du logiciel libre.

  Ça se voit dans la réponse de Julien :

  Julien:
  > pyg:
  > >Je veux bien faire appel à un-e designer, mais... où je la/le trouve ? Combien de temps passer à la/le chercher ?
  > La trouver c'est pas très dur, en combien de temps, ça dépend, pas plus ni moins qu'un bon dev/inté/whatever

  Mon expérience autour du logiciel libre, c'est que pour obtenir des contributions de devs, il faut sortir une première version, même incomplète, faire un peu de buzz en demandant de l'aide. Avec un peu de chance et de la bienveillance, on peut attirer d'autres personnes ayant le même problème ou que la solution amuse. La politique du « release early, release often » (sortir de nouvelles versions tôt et régulièrement) a pour avantage de laisser des fonctionnalités incomplètes (donc des manières de s'impliquer) et faire un peu de buzz pour peut-être attirer de nouvelles personnes.

  Je n'ai que très rarement eu l'expérience de designers qui avait une culture de la contribution et qui voulait bien fonctionner par petites touches incrémentales. J'ai souvent entendu des graphistes dire « Gimp est inutilisable » — d'ailleurs je demande à tout le monde d'y retourner voir, y a eu du progrès — mais, avant même de parler de le proposer à d'autres contributeur·ice·s du projet — je n'en connais aucun·e qui ont pris le temps de réfléchir à comment améliorer son design.

  Ceci dit, y a des initiatives chouettes pour essayer de pouvoir mieux se trouver :
  http://opensourcedesign.net/jobs/
  À nous de les populariser ?

  Clairement, y a des batailles idéologiques à mener pour que nous puissions avoir des logiciels libres plus utilisables, par tou·te·s, et heureusement je vois les lignes bouger ces dernières années. Mais il y a autant de travail pour faire intégrer aux auteur·e·s de logiciels libres que le design fait partie du développement, que pour faire intégrer aux designers qu'illes doivent contribuer aux logiciels libres s'illes veulent les voir s'améliorer. Le fond étant aussi de faire comprendre à toujours plus de monde que nous avons besoin de logiciels libres si on veut garder le contrôle des ordinateurs qui pullullent toujours d'avantage dans nos vies.

• 27 De Peha - 09/02/2017, 12:43

  @le Dev de base Je comprends ce que tu veux dire mais je pense que tu m'avais compris, mettre de l'eau dans son vin dans l'intransigeance militante peut aider à se comprendre -> http://edgard.fdn.fr/blog/index.php...

• 28 De Longhost - 09/02/2017, 13:18

  Le constat n'est absolument pas grossier mais pointe les cas symptomatique de la situation du monde Libre.

  Le fait est que même pour moi, un développeur front "reconvertit" dans l'UX ( que je considère plus comme une spécialisation) dans une équipe de Dev doivent faire face à la condescendance de ces collègues toujours Dev montre le sentiment que seul le producteur de code est utile au projet qui règne dans le milieu du Libre.

  Je ne dit pas que c'est partout, que les concepteurs (architectes techniques compris) sont martyrisés, mais le fait est que la principale plateforme moderne du Libre est github, intégralement centré sur le code.

  Je pense que la situation peut s'améliorer à partir du moment où une plateforme permettant de réunir ou tout du moins de faire communiquer les parties prenante ermergera et fera consensus.

  Pour moi ces difficultés sont aussi lié à l'éducation des développeurs au design. Sans être des stratèges, on demande aux membres d'une équipe de comprendre la stratégie du coach, pour la suivre, et innover quand la situation s'y prête.

  Une petite communautée tente de faire avancer la cause du design dans le libre: http://opensourcedesign.net

  Je suis de loin le sujet mais j'aimerais vraiment et pourquoi pas contribuer à l’émergence d'un github du design ou qui fait un lien plus naturel qu'une PR sur github.

• 29 De MartinLucas - 09/02/2017, 13:20

  C'est drôle, ce que décrit Peha, je suis justement en train de le faire ! Je suis architecte (bâtiment) et suis en train de concevoir une appli de modélisation architecturale. Je suis donc dans le rôle du designer. Je cherche des développeurs pour concrétiser cette idée (ce serait payé). Allez y faire un tour si ça vous intéresse : Naos.pro

• 30 De Pixocode - 09/02/2017, 13:29

  En tant que dev je suis complètement d'accord avec l'article.

  J'appuierai une autre chose, le fait que je suis d'accord sur "L’absence de la culture de la contribution dans les métiers créatifs."
  Par contre en contre partie, les métiers créatifs souffrent d'un gros problème de considération... (moins bien payé, voir très souvent gratuitement pour du boulot commercial, considéré en second plan, jugé sans les connaissance, parfois considéré comme un passe temps et pas un métier, et j'en passe...)
  Les deux se nourrissent l'un de l'autre, et font clairement pas bon ménage...

  Ensuite personnellement j'ai souvent ressenti un certain égo démesuré parmi les "supporters de première ligne" du logiciel libres, j'ai souvent l’impression de me retrouver face à des religieux sur leur piédestal qui brandirait leur bible en criant à l'hérétique à la moindre phrase qui colle pas à leur dogme.
  Si en tant que dev je peux être effrayer, j'ai du mal à imaginer les non-devs...
  C'est assez décevant pour un mouvement qui parle d'ouverture de paraître aussi fermé...

  Ça me parait fou qu'autant on demande pas à un designer de juger du code et ça paraîtrais stupide, autant ça parait normal qu'un dev est un mot à dire sur un design...
  Ca lie le problème de considération et d'égo entre ces 2 métiers... c'est un problème très ancré et très grave à mon goût... mais pas uniquement lié à l'open source, dans beaucoup d'entreprise ce problème existe (ce qui change en rien le problème)...

  Peut être une des solutions serait de savoir faire des concessions, de pragmatisme, et surtout de considéré l'UI/UX à l'égal du code ?

  Puis si on peut arrêter de se focaliser uniquement sur le fonctionnement mais aussi et à égale, sur son utilisation... penser dès le départ à comment une personne extérieur pourra l'utiliser... ça sera forcement bénéfique pour l'auteur... et ça sera une façon de faire de l'open source pas uniquement pour soi ou ses copains, mais surtout pour que n'importe qui puisse l'utiliser...

• 31 De Lanza - 09/02/2017, 15:02

  Héhé.

  Très intéressant, mais irréaliste, pour les raisons déjà évoquées. A moins d'être *très* copain avec un designer, ou d'avoir soi-même des notions de design au départ, il n'est pas possible d'intégrer cette dimension au démarrage du projet. Parce que je ne connais pas UN designer qui veuille intégrer un développement inexistant, dont on a même pas l'idée qu'il sera peut-être un jour diffusé. Et il a raison, parce qu'on ne connaît pas le nombre de projets inaboutis et qui n'aboutiront jamais, mais je le subodore à minima astronomique.

  Ce qui fait qu'un développeur s'intéresse à un projet libre, c'est qu'il lui plaît, mais qu'il lui manque un petit truc pour que ça marche comme il veut. Et donc pouf, il participe.

  Ce qu'il manque au libre, ce sont des designers qui vont, au début d'un projet, se dire : tiens ce truc est pas mal, mais ce serait mieux s'il était fichu comme ça plutôt que comme ça. Sauf qu'en général, quand le projet commence à être connu/susceptible d'intéresser des designers, il est déjà trop tard, la codebase est déjà trop grosse pour être ré-architecturée facilement, et effectivement, le designer qui débarque est vu plus comme un empêcheur de tourner en rond que comme une réelle force de proposition.

  On ne sortira pas de cette situation tant que les dev n'auront pas un peu de culture design et les designers un peu de culture dev. Certains l'ont, et ils sont rares. On rencontre, de moins en moins, mais encore aujourd'hui surtout du mépris de part et d'autre.

  Je suis de ceux qui pensent cependant qu'il y a une foultitude de points communs entre les 2 métiers. Ne serait-ce que parce que même les arguments d'une ligne de commande, ça se designe.

• 32 De Julien - 09/02/2017, 15:27

  Pour le fait de s'y prendre au départ, ça peut être mieux, mais pas absolument nécessaire.

  Refondre des sites internet, des outils et des identités on fait ça au quotidien, sur des bases pas forcément cleans, donc pourquoi pas faire pareil dans le libre ? (à part bien sûr à cause des problèmes que je soulève plus haut)

• 33 De wiko - 09/02/2017, 15:50

  C'est une discussion que j'ai eu depuis des années.
  Le plus gros problème est :
  refaire une interface "utilisable" de logiciel est coûteuse en temps de dev.
  Les projets déjà aboutis en terme de code (on peut prendre blender/gimp/inskape en exemple) ne sont pas du tout ergonomiques, productives ou facile à utiliser.

  Pourtant ces solutions s'adressent à des gens qui font ou veulent faire de l'image(les 3 que j'ai cité).

  On se fout de faire du joli, il faut faire efficace :
  utile on l'a souvent dans les projets open-source
  utilisable difficilement
  utilisé rarement

  j'entends les libristes hurler d'ici, mais si c'est utilisable ... tu ne veux pas changer tes habitudes.

  Le fait de faire fonctionner quelque chose ne le rend pas utilisable en terme utilisateur.

  les designers prêts à faire du libre il y en a, les licences qui vont jusqu'au copy-left (oui on peut en faire en design) existent depuis le début.

  Ce sont surtout le ton condescendant des devs qui refroidissent l'ardeur des designer/ux. Le plus souvent les projets que j'ai vu fonctionner étaient dans le jeu vidéo à l'epoque de flash. Le design et le game play étaient parti intégrante du projet.

  Pourquoi cela ne fonctionne pas dans le domaine soft ? parce-que bootstrap par exemple. Un dev back-end web pourra fournir une interface fonctionnelle de service (au sens qu'elle fonctionne les tests au vert et tout).
  Est ce ergonomique ? Non, mais les fonctionnalités sont là.
  Est ce utilisable ? Non, mais les fonctionnalités sont là.
  Est-ce utilisé ? Non, mais les fonctionnalités sont là.

  un designer désabusé.

• 34 De Adrien Plazas - 09/02/2017, 16:55

  Vient chez GNOME, on a une équipe de designeurs extra et ils sont grandement respectés par les devs !

• 35 De Fla - 09/02/2017, 17:18

  Alors oui... et non.

  Il y a du progrès à faire sur les interfaces utilisateurs. L'UX, l'ergonomie, ce sont des sujets importants sur lesquels les développeurs n'ont pas forcément de compétences et où les suggestions voire les contributions feraient le plus grand bien.

  À l'opposé, les goûts et les couleurs. Il ne faut vraiment pas confondre UX et design. Expliquer "tu ne devrais pas mettre ce bouton de validation en rouge parce que pour les gens ça signifie annuler / supprimer etc..." est une remarque UX qu'il faut que les développeurs apprennent à prendre en compte. Débarquer en disant "les couleurs à la mode c'est ça, il faut que le design soit flat, comic sans MS c'est le mal" ça, c'est un jugement. Et typiquement, le logo d'un logiciel n'a absolument rien à voir avec son ergonomie. Si les développeurs d'un projet ne veulent pas d'un logo parce qu'ils ne l'aiment pas, je ne vois pas en quoi l'argument "laissez le designer faire son travail" qui a l'air de vouloir dire "laissez le imposer ses choix" est valide. Oui, un logo et une interface moderne et à la mode donnent confiance dans le logiciel et encouragent les utilisateurs à essayer. Non, #88cc44 n'est pas forcément mieux que #338899 (aucune idée des couleurs, je mets ça au pif).

  Bref, je trouve que la comparaison travail de designer / travail de dév peu valable, car là où ce qu'on attend d'un dév est toujours pareil (pas de bugs, performances, fonctionnel etc) ce qu'on attend d'un design est très subjectif. Il y AURA des mécontents. Forcément, c'est moins facile.

• 36 De Julien - 09/02/2017, 17:49

  @Adrien : POurquoi pas pour GNOME !

  @Fla : je pense que c'est là que tu fais complètement fausse route, justement il n'y a pas que l'ergonomie qui compte dans la perception d'un logiciel, et SI telle couleur peut être mieux que telle autre (selon la cible, les objectifs etc). Contrairement à ce que tu penses, ça n'a justement rien de subjectif.

  Laissez les designers faire leur travail

• 37 De Pixocode - 09/02/2017, 18:12

  @Fla A preuve du contraire, faire un logo (ou un design) fait parti du métier de graphiste (je t'assure c'est un vrai métier :p), et ça n'est pas une simple histoire de goût mais d'un travail de conception dont certains aspects échappent aux développeurs...
  Après, refuser un logo c'est pas un problème je pense, le problème c'est surtout le conseil du genre "tu devrais changer cette couleur", "et si tu mixe ces 2 propositions"... en gros faire intervenir le gout d'une personne non qualifié pour *modifier* le travail d'une personne qualifié... (et ça dans n'importe quel métier)

  En faite le meilleur conseil que je donnerais à un(e) développeur c'est de vivre avec un(e) graphiste... (et inversement) ça permet de mieux appréhender les problèmes qui font que les 2 métiers ont du mal à se comprendre et à s'entendre... ^^

• 38 De STPo - 09/02/2017, 18:12

  @Fla : Quand on présente un projet, on s'inscrit dans un écosystème qui existe déjà, et si on veut faire comprendre qu'on s'adresse à telle cible on utilisera les codes déjà en vigueur dans ce milieu. À l'inverse si le but c'est de transgresser et de révolutionner les choses, on optera pour des couleurs totalement nouvelles/différentes. Dans un cas comme dans l'autre ça n'a rien d'innocent et c'est le fruit d'une réflexion sur l'identité visuelle et la culture graphique du milieu dans lequel (ou hors duquel) on inscrit son projet. C'est le même raisonnement pour un logo ou une identité de façon générale.

  Les logos, les couleurs, c'est DÉJÀ de l'ergonomie.
  Penser qu'un designer les crée au hasard ou en fonction de ses lubies du moment c'est juste méconnaître cette discipline.

• 39 De yamo - 09/02/2017, 18:22

  @Fla : Ta réponse est assez typique d'une culture française pour laquelle le design est avant tout un gros malentendu.

  Non, le design n'est pas "subjectif". Du moins pas plus que n'importe quelle pratique faisant intervenir une expertise humaine, développement compris.

  C'est même en vérité tout le contraire. Si le design était subjectif, il n'aurait tout simplement jamais fonctionné, et serait tombé dans l'oubli il y a bien longtemps. Or c'est l'inverse qui s'est passé depuis 100 ans, avec une explosion de l'usage du design dans toutes les strates de l'économie, au point qu'il est aujourd'hui totalement impossible de passer outre pour toute démarche sérieuse de développement (sous peine de se planter assez minablement, ce qui est d'ailleurs l'un des sujets du présent article).

  De fait, cet argument des "goûts et couleurs", censé suffire à attribuer au design un côté gentiment "subjectif" (qui en creusant un peu finit souvent par ressembler à une sorte de mépris, basé sur une distinction fantasmée entre des disciplines jugées "sérieuses" et d'autres moins) ne masque en réalité chez ceux qui l'utilisent - et ils sont nombreux - qu'une profonde ignorance des enjeux de base du design et plus largement des arts appliqués.

  En l'espèce, tout comme n'importe quel boulot de développeur (et souvent d'ailleurs avec les mêmes outils), le travail d'un designer est parfaitement quantifiable et évaluable. Plutôt que de le paraphraser ici je t'invite à aller lire cet article qui pose quelques-unes des bases dont je parle >> http://kitdesurvie.metiers-graphiqu...

  En résumé, cette propension d'une bonne partie de la population (vraie sur une base générale, mais probablement encore plus vraie dans les secteurs du développement et du libre) à assimiler, par la plus totale des ignorances, le design à une affaire de "goûts et de couleurs" explique à mon sens une bonne partie des problèmes soulevés par Julien dans son article. Des problèmes qui justement ne sont pas prêts de se régler tant que ce malentendu fondamental persistera.

• 40 De Clément - 09/02/2017, 18:28

  Salut,
  Dans l'idéal, design et développement sont assez intimement liés.

  Parce que le design va au-delà de l'aspect UX/graphisme, ou plutôt parce que l'UX va au-delà de "ce bouton rouge est mal choisi". A mon sens l'UX touche de très près l'architecture d'un projet, du type "segmentons cette action en 3 actions" ou au contraire "rassemblons toutes ces fonctionnalités en un formulaire de paramétrage simple".

  Ces choix peuvent avoir un impact assez important dans l'architecture technique, un petit exemple simple (mais réel car vécu) qui me vient en tête :
  vue dev (orienté fonctionnalité) : 1 inscription membre > 2 création contenu
  vue designer (orienté utilisateur) : 1 création contenu > 2 validation et inscription membre
  Dans les deux cas l'appli fonctionne, dans le deuxième elle sera (dans certains cas) bien plus utilisée car on freine moins l'utilisateur.
  Ça change un peu la logique du code tout de même.

  Çà explique aussi pourquoi certains redesign sont quasi impossibles dans les contraintes temps/budget du libre. Je parle de réels redesign, et non de "simples" themings.

  Le design à mon sens, c'est avant tout une question de réflexion autour de questions simples, aux réponses parfois complexes :
  - qui est l'utilisateur ?
  - quelle est l'utilisation ?
  - quels sont les contextes ? etc
  Ensuite les réponses se traduisent par un résultat à la fois graphique et ergonomique (donc qui peut toucher en profondeur la technique). Un logiciel bien développé à mon sens se doit de répondre à ces mêmes questions avant tout. N'oublions pas que le terme design est aussi beaucoup utilisé dans le monde du dev (les fameux design pattern par exemple).

  Maintenant comme le dit PYG, le souci est que le dev libre se crée sa propre solution en répondant à ses propres contraintes design. Quand le projet prend de l'ampleur, les choix techniques qu'il a fait uniquement pour lui deviennent souvent moins pertinents pour une base utilisateur étendue.

  A mon niveau (je suis à la fois designer et dev web), c'est la raison pour laquelle nombre de plugins wordpress que je développe (entre autres) restent dans mes cartons : ils répondent au besoin d'un projet en particulier, avec ses propres contraintes, et en faire un plugin libre de qualité signifierait recoder l'ensemble en prenant en compte une utilisation beaucoup plus large et moins spécifique.

  Mes deux centimes

• 41 De Fla - 09/02/2017, 19:34

  Je savais que mon commentaire allait avoir des réponses, super

  Je l'ai rédigé un peu à la va vite avant de sauter dans mon TGV donc il n'est pas aussi bien tourné que je l'aurais souhaité et certainement un peu trop "rentre dedans".

  Je reconnais complètement le travail de graphiste / designer, qui est d'ailleurs selon moi encore différent de celui d'ergonome. Comme je l'ai dit : "un logo et une interface moderne et à la mode donnent confiance dans le logiciel et encouragent les utilisateurs à essayer." Ca a une valeur ajoutée énorme ! Et ne doit évidemment pas être négligé, comme c'est souvent encore le cas dans les projets libres.

  Mon propos cependant était bien sur le fait que l'impact d'un design reste compliqué à évaluer car il est très différent selon les personnes. Je continue de penser qu'il y a du subjectif là dedans. Pour reprendre l'exemple de Pyg et de sa maison, une belle peinture et des jolies finitions encourageront les gens à venir s'y installer. Actuellement dans le libre on en est encore trop souvent à "y'a un lit donc ils peuvent dormir" point. L'objectif "pur" est atteint. Il y a un semblant de prise de conscience autour de l'UX "le lit est placé dans un courant d'air avec le soleil dans la tête quand on se réveille". La majorité des gens conviendront que déplacer le lit est une bonne idée, mais ca y est, il y en a un ou deux qui diront qu'ils aimaient bien se faire réveiller par le soleil. Quand on arrive au design, "la chambre est plus lumineuse en orange c'est plus sympa", là, ca commence à être le drame, une personne sur 4 va pas aimer la couleur et va assurer que le bleu c'est mieux. Quant-à faire du marketing pour savoir ce que les gens pensent de la maison et essayer d'avoir plus de visites, on en est encore loin. Pensez-vous, des marketeux.

  Devant tous les débats (parfois rageux) que ce genre de sujet provoque, le développeur initial, pas forcément fermé mais ni community manager ni spécialement social, va finir par laisser le lit à sa place et la chambre sans peinture, ou avec un mix d'orange et de bleu, ce qui vous en conviendrez est pire que tout (Julien le dit bien dans l'article).

  Bref, je suis dev front-end, je fais souvent de l'UX car je suis dans une petite boite, je bosse avec des designers extérieurs avec qui je m'entends très bien et qui font un super boulot, mais non, clairement, dire "si on laissait les designers bosser on aurait la solution parfaite qui convient à tous", je n'y crois pas. À la limite, "on aurait la solution qui convient au plus de monde", je veux bien. Mais tout dépend des gens à qui on s'adresse. On a de nombreux clients dans des collectivités, qui veulent une interface à la windows millenium. On a même perdu des clients en passant en flat. Je bosse aussi sur le front end de diaspora*, et on a fait quelques changements d'interface dans la dernière majeure (rien de transcendant, rien n'a changé de place, on a modifié des couleurs pour mieux mettre en valeur le contenu et mieux séparé les messages d'origine différente). Et bien on a été "obligé" de faire un thème "ancienne version" pour tous les réfractaires au changement. Bref, pas comme les algorithmes où une spec claire peut être établie, le design est un art compliqué et où tout le monde ne peut pas être contenté, d'où les problèmes évoqués.

• 42 De Breizh - 09/02/2017, 19:45

  Je dirais que les utilisateurs ne sont pas tous superficiels, et que certains s'intéressent plus à l'ergonomie. Plus que vous ne le pensez du moins.

  Je ne suis pas dev, et avant même de m'intéresser à l'informatique du côté arrière, j'ai été utilisateur. Et le principal problème est rarement l'interface, mais la méconaissance des logiciels. Et même si l'interface provoque un choix à priori, ça ne le reste pas longtemps.

  À l'époque où j'étais un utilisateur ignorant, les interfaces « jolies » me plaisaient évidemment un peu plus. Mais entre WMP et VLC par exemple, j'ai rapidement quitté WMP. Moins performant (j'avais un PC pourri), moins complet, et beaucoup plus compliqué à utiliser pour des trucs tout simples comme changer de piste audio.

  Il se trouve également que depuis je préfère l'utile à l'agréable, et que même du côté « joli », le design deviens vraiment n'importe quoi. En plus d'être anti-ergonomique, il est devenu tellement simpliste…

  Depuis, je fais des études d'info, je tourne sous GNU/Linux avec i3wm, et je tape mes rapports en LaTeX. La plupart de mes logiciels (gestionnaire de fichiers, lecteur audio, aggrégateur de flux RSS) sont en CLI (ils ont quand même une UI, en l'occurence Ncurse, et soyons honnêtes, c'est pas pire que le Flat Design). Et je galère à utiliser des environnement graphiques « classiques ».

  D'ailleurs, si vous connaissez des thèmes GTK pas Flats, je suis à vôtre écoute, on trouve plus que ça maintenant…

  Ah, et si vous êtes toujours là, sachez que je crache pas sur les designers eux-même. Juste sur les tendances actuelles, le fait que les grosses boîtes influent tellement sur le monde du design est extrêmement ennuyeux (y'a que du moderne et du flat, je cherche du rétro réaliste), et je vous l'accorde, certains logiciels pourraient être plus beaux. Mais il ne faut pas oublier l'ergonomie.

  Breizh.

• 43 De Julien - 09/02/2017, 20:53

  @Fla / Breizh

  Je pense très honnêtement que vous faites fausse route avec vos flat/pas flat et les utilisateurs n'aiment/n'aiment pas, et en partageant des anecdotes de redesign qui visiblement ont été réalisés sans objectifs.

  C'est justement tout le problème, et c'est pas une histoire de flat ou pas, et d'analogie bancale avec une maison.

• 44 De tetue - 09/02/2017, 21:41

  Merci d’avoir pris la peine de poser cela par écrit et de façon constructive. Tu as écrit, point par point, le billet que j'ai en tête depuis 5 ans (mais que je n'avais pas le courage d'écrire, craignant le retour de bâton libriste). Merci, beaucoup, donc.

  Ayant longtemps contribué à des projets libres (en dev front et UX), j'aurais beaucoup à dire, du bon et du moins bon, mais trop long pour un commentaire ici. Je réponds juste à quelques points :

  @pyg : que la plupart des logiciels libres soient faits pour leur auteur, OK et c'est une excellente motivation initiale. Mais ça devient faux dès l'instant où le soft est publié et utilisé par d'autres. Et contradictoire avec la plainte, si fréquente, des libristes qui se demandent pourquoi leur soft n'est pas davantage utilisé, voire rejeté, et comment changer ça, etc.
  Pour continuer d'ignorer les utilisateurices au prétexte que c'est d'abord conçu par et pour l'auteur initial, il faudrait soit assumer qu'il s'agit là d'une posture de diva, soit ne pas publier (ou vers une communauté restreinte ou privée). Sinon, bin… faut pas se plaindre (n'y voyez aucune attaque, hein, je déroule juste l'idée jusqu'au bout).

  @Peha : que l'initiative des projets libres ne soit pas le fait des seuls devs mais de designers, quelle bonne idée ! Autre approche : travailler en binôme designer et dev, main dans la main. Ça marche. Difficilement sur les projets libres, mais ça marche. Très bien même.

  Dernier point, non évoqué ici, sinon en filigrane à travers les faux prétextes de manque de moyens (temps et/ou budget), celui du vrai problème qu'est le manque de reconnaissance (euphémisme) des contributeurs non codeurs.
  D'abord le prétexte du temps : faut pas oublier que travailler avec un designer peut faire gagner du temps au dev, parfois beaucoup de temps (en évitant par exemple de développer telle fonctionnalité qui s’avérera finalement totalement inutile ou inutilisable).
  Ensuite l'argent : pourquoi faudrait-il des sous pour designer… sur un projet où les autres, dev, sont bénévoles ? Pourquoi cette différence de traitement ? Pourquoi envisager le designer comme prestataire, externe, qu’on rémunère ? et non comme co-contributeur ? comme volontaire motivé ? comme libriste, lui aussi ? Est-ce parce que la seule contribution pensable est celle qui se présente sous forme de code ?
  De fait, l'écosystème libriste (les outils, paternités, etc.) ne reconnaît que les contributeurs-codeurs. Les autres contributions (design mais aussi documentation, traductions, animation de la communauté, organisation, etc.) n'ont aucune existence, parce qu'aucune visibilité… entretenant le mythe que le logiciel libre est fait par (et pour) les dev d'une part et ne le rendant pas attractif pour d'autres talents, d'autre part. Et la boucle est bouclée.

  Sur ce dernier point, la remise en question se place de part et d'autre : comment la communauté libriste peut s'ouvrir (pas seulement dans l'intention d'accueil, mais aussi dans son fonctionnement et ses outils) à d'autres que les seuls dev ? et côté designers (graphique, UX, ergo, etc.) : qu'est-ce que serait du design libre (pas seulement du design appliqué à des objets libres, mais une démarche libriste de design) ? Je n'ai pas de réponse, mais une grosse curiosité d'en chercher

  Pardon, tout cela mériterait d'être plus amplement développé, mais je voulais déjà jeter les idées ici, en réponse à ce billet qui le mérite bien.

  Julien, bonne idée, je viendrais aussi dimanche.

• 45 De débile - 10/02/2017, 05:54

  En tant que dev, j'ai déjà travaillé avec des designers. Tous m'ont montré en quoi ce qu'ils faisaient était mieux, aidait à l'utilisation, tous ont expliqué et discuté.
  Et avant, tous ont écouté ce que je cherchais à faire avant de m'apprendre la "vérité" et j'ai même eu des "maintenant que j'ai compris ton raisonnement, j'aime bien ta façon de voir" et ont changé leur fusil d'épaule pour proposer un truc qui rendait le tout présentable et plus utilisable tout en conservant mon idée de base. Aucun ne m'a jamais dit, "tu fais comme ça parce que je sais ce que je dis et toi le petit dev t'y connais rien".

  Bref, j'espère ne jamais avoir à travailler avec l'auteur de ce post ou avec les designers qui commentent ici !

  C'est dommage, j'avais bien aimé la réflexion sur le fonctionnement en pull-request qui n'est pas adapté à tout les métiers.

• 46 De Bob - 10/02/2017, 10:33

  Plutôt que de tenter de contribuer directement à des projets libres − en tant que designer − par petites touches, ce qui mène invariablement à la situation où tout le monde donne un avis subjectif qui se résume à "moi, j'aime pas", est-ce qu'une première étape ne pourrait pas être pour les graphistes/designers de proposer des études de cas ?

  Càd s'emparer de projets libres dans leur état actuel pour pointer les problèmes et apporter des solutions ("l'interface de Gimp est imbitable parce que ça, ça et ça ; elle pourrait être améliorée comme ça, comme ça et comme ça") puis proposer ça en bloc aux développeurs concernés ?

  J'imagine que dans certains cas (la plupart ?) ça déplacerait les mêmes problèmes en aval ("j'ai a-do-ré ta proposition de redesign mais j'aime pas le logo") et que ça pourrait être décourageant de passer énormément de temps sur un boulot énorme pour qu'au final il n'aboutisse à rien de concret, mais peut-être qu'une vue d'ensemble cohérente et argumentée sur la refonte de projets phares permettrait de faire un peu avancer les choses ?

• 47 De Marthym - 10/02/2017, 11:43

  Bonjour,

  Merci pour ce billet.
  Il m'a permis (enfin) de comprendre pourquoi il est si difficile de trouver des graphistes/designer sur des projets open source. Et je ne peux qu'être d'accord avec toi, surtout sur la partie "chacun son métier".

  Personnellement, je n'ai eu la chance de travailler avec un designer sur un projet opensource qu'une seule fois mais ça a été une expérience vraiment intéressante. Libérer des prises de têtes que le design représente un dev, on peut se concentrer sur ce que l'on sait faire, l'architecture technique et le code et c'est un réel plus dans un projet.

  Après ce qui est difficile dans l'intégration d'une designer dés le début c'est que les projets partent souvent d'un dev qui a une idée et la code. Et pour l'avoir vécu plusieurs fois, trouver un designer intéressé par le projet qui accepte de se joindre à l'aventure n'ai pas gagné :s

  En tout cas merci

• 48 De Stéphane Bortzmeyer - 10/02/2017, 12:17

  Alors, déjà, j'aurais une question : c'est quoi, le design ? Parce que ce n'est jamais défini. À lire l'article, « design » désigne tantôt le graphisme (le logo de SPIP, les termes relevant de l'esthétique comme « repoussant »), tantôt l'ergonomie (logiciel plus ou moins facile à utiliser), tantôt des concepts plus vagues comme l'UX, tantôt le marketing (définir le produit), tantôt l'architecture globale du projet.

  Les commentaires semblent indiquer que je ne suis pas le seul à n'avoir pas compris : certains parlent de graphisme, d'autre d'IHM...

  Je crois que je vois bien ce que fait un graphiste, et en quoi c'est un domaine de compétence à part entière (comme la programmation). Je crois aussi que je vois ce que fait un expert de l'IHM. Mais un « designer » ? À part lancer des insultes scatologiques contre les développeurs, ça fait quoi ? J'ai lu http://opensourcedesign.net/ qui est recommandé par plusieurs commentaires, mais ça n'a ne m'a pas éclairé.

  En tant qu'utilisateur (car, oui, on est tous utilisateurs, même le geek le plus hardcore n'a pas lu une ligne du code source de la plupart des logiciels qu'il utilise), je demande par exemple à un logiciel de ne pas avoir de bogue (rien de plus agaçant que ces logiciels à la somptueuse interface utilisateur mais qui se bloquent tout à coup avec un message incompréhensible : LibreOffice, je pense à toi) et de ne pas avoir de faille de sécurité (Wordpress cité comme exemple réussi : sûr, M. Michu adore retrouver son site Web défiguré, et il prend son pied à faire des mises à jour du code). C'est du design ? (C'est une vraie question.)

  (Et, au passage, l'article attaque CozyCloud comme n'ayant aucun designer alors que la page citée en montre au contraire un, plus deux « product owners ».)

• 49 De Alexandre Hocquet - 10/02/2017, 13:12

  Bonjour à tous,
  Je trouve ce débat / controverse tellement intéressant que si par hasard quelqu'un qui passe ici et qui fait un master de sociologie/anthropologie/histoire des sciences/mediation scientifique veut en faire son sujet de mémoire qu'il me contacte!

  http://poincare.univ-lorraine.fr/fr...

• 50 De STPo - 10/02/2017, 13:54

  @Stéphane Bortzmeyer : La question de la définition du design est au cœur du sujet effectivement, et le fait est qu'ici on mélange plusieurs choses. Suivant ses acceptions (anglo-saxonne ou non) on trouve sous ce terme mille disciplines, de la stratégie à l'identité en passant par le graphisme, l'ergonomie et même le code.
  La partie que les profils techniques comprennent le mieux, c'est tout ce qui a trait à l'ergonomie : c'est tangible et directement lié à leur travail, et ça explique que la discussion s'arrête souvent sur ce point.
  La partie concernant l'identité est largement plus méconnue (et, oserais-je, fréquemment méprisée). C'est donc sans doute là qu'il y a le plus de travail. À commencer par reconnaître sa légitimité et sa nécessité dans une démarche de démocratisation des outils open source...

• 51 De Julien - 10/02/2017, 14:36

  @Stéphane Bortzmeyer : Tu penses taper dans le mille avec ton commentaire,mais il ne fait qu'étayer le billet. Le design a plusieurs facettes, et souvent le libre montre des lacunes dans chacune d'elles. Le billet parle d'ergo, d'identité, de stratégie, de communication… tout ça doit être améliorer si on veut que le logiciel libre perce auprès du grand public. C'est un tout.

  Ne pas avoir de bug c'est important, être sécurisé c'est important, avoir une bonne communication et un bon design au sens large c’est important. Acceptez-le et puis c'est marre.

  Ça me fait marrer de voir des libristes tourner autour du pot avec mille anecdotes sur comment un jour tel bouton était mal placé dans un logiciel proprio et comment ils n'aiment pas tel logo d'un produit à la mode. On s'en fout de ça, ce sont juste des écrans de fumée qui servent à se voiler la face.

  M'enfin après chacun fait ce qu'il veut.

  Pour Cozy Cloud, ils ont un designer freelance sur 27 salariés, con ils ne salarient aucun designer. Je vais cependant préciser, sans que ça ne change rien au fond. Si tu veux marcher sur les plates-bandes de google, dropbox et consorts il faut muscler le marketing (brrr quel mot sale) ou continuer à se demander pourquoi ça ne marche pas (le grand public est surement trop con).

• 52 De Stéphane Bortzmeyer - 10/02/2017, 14:50

  « Le design a plusieurs facettes » De ce que je comprends, « design » veut dire « tout ce qui n'est pas le code », c'est ça ? Je me méfie un peu d'une définition aussi large. Surtout si on veut faire reconnaitre la compétence spécifique des gens : je doute fort que quelqu'un soit compétent dans tout le  « non-code ».

  Concernant l'adoption par le grand public, c'est autre chose qui en effet me gênait dans l'article original : il alterne technocratie (« laissez faire les designeurs, ne vous mêlez pas de leur travail, acceptez comme parole d'Évangile tout ce qu'ils disent ») avec populisme (les utilisateurs ont toujours raison, c'est la voix du peuple).

• 53 De Ugo - 10/02/2017, 14:51

  Yo,

  @De Julien

  1) Je suis d'accord avec toi, un logiciel se doit d'être "joli" pour être adopté par un utilisateur.

  2) La raison qui pourrait expliquer que bcp de logiciels libres soient moche pourrait être que (je n'ai pas de chiffre, c'est juste une impression) la plupart des contributeurs soient programmeur et pas des graphistes ou des ergonomes.

  3) Je pense aussi que la plupart des logiciels (libre et non libre) manque de structuration au niveau des participants. Je lis souvent (et notamment dans ton article) que travailler à plusieurs dans le libre c'est le bordel. Je pense que cela est du à un manque d'orga, de culture d'orga collaborative etc...

  4) Tout cela peut s'expliquer notamment, par la sociologie des contributeurs (que des devs), par le côté "amateur" de bcp de projet (sur le temps libre) et l'absence de dialogue entre le l'utilisateur et le producteur du logiciel (comme on ne vend pas, on n'a pas cet outils de mesure du succès/appréciation de l'utilisateur)

• 54 De STPo - 10/02/2017, 15:07

  @Stéphane Bortzmeyer : « De ce que je comprends, « design » veut dire « tout ce qui n'est pas le code », c'est ça ? Je me méfie un peu d'une définition aussi large. Surtout si on veut faire reconnaitre la compétence spécifique des gens : je doute fort que quelqu'un soit compétent dans tout le « non-code ».»

  Absolument. Tout comme quelqu'un de compétent dans le « tout-code » (back, front, admin, 50 000 langages et paradigmes) éveillera à juste titre des soupçons. Il y a des spécialisations partout, personne ne peut être bon partout, personne ne nie ça.

  Concernant la technocratie et le populisme je passe mon tour par contre, je ne suis pas certain que ce soit le propos de l'auteur...

• 55 De Julien - 10/02/2017, 15:35

  En fait on va pas tourner 10 ans autour du pot car les faits sont là.

  J'essaye d'expliquer pourquoi et de trouver des pistes, ça peut être nié en bloc quelque part je m'en tape je vais pas rentrer dans un débat sans fond sur des provocations un peu neuneus.

  En fait je pense qu'une avant garde du libre a très bien compris comment ça marchait et utilise les ressources à leur disposition pour assurer le succès de leur produit (quelle que soit la manière de le quantifier) et d'autres continuent à se demander si les designers n'ont pas trop d'ego et est-ce que finalement le design est utile.

  Quand on aura épuisé toutes les raisons fallacieuses qui feraient que les gens seraient trop stupides pour ne pas utiliser des solutions supérieures, libres et bien souvent gratuites par rapport à leurs alternatives payantes et fermée, on se penchera peut être sur la plus évident, le manque de design.

• 56 De Pixocode - 10/02/2017, 15:35

  @Stéphane Bortzmeyer

  technocratie (« laissez faire les designeurs, ne vous mêlez pas de leur travail, acceptez comme parole d'Évangile tout ce qu'ils disent »)

  Technocratie, c'est jolie comme mot, mais pourquoi être utilisé uniquement dans le contexte des designers ? C'est technocrate aussi de ne pas demander l'avis des designers sur le choix des langages ou des framework ?
  Ou alors que contrairement au dev que seuls les devs peuvent comprendre, le design c'est à la portée de tous et chacun peut donner son avis ?

• 57 De aaarg - 10/02/2017, 15:54

  Bonjour,

  Les difficultés soulignées ne sont pas spécifiques au design.
  En général, les projets libres tournent autour d'un "dictateur à vie bienveillant", et énormément de projets ont été forké parce que le noyau dur n'était pas d'accord avec une idée proposée.

  Le design est quelque chose de fondamental pour un logiciel. Encore plus au niveau de son identité. Imposer à un groupe de développeurs un design avec lequel ils ne sont pas à l'aise revient à leur imposer une fonctionnalité qu'ils n'aiment pas.

  Tout ça pour en arriver à la question: avez vous envisagé de forké le projet ?
  Cela ne demande pas énormément de compétence en informatique, puisqu'il suffit de suivre les mises à jour du logiciel principal.
  Avez vous connaissance de designers qui maintiennent un tel fork ?

• 58 De pyg - 10/02/2017, 17:13

  La vache, je suis juste atterré de la plupart des réponses de dev ci-dessus.

  1. je demande comment on peu améliorer la collaboration entre designers et développeurs
  2. Julien fait un billet de réponse (avec lequel j'ai des points de désaccord, cf premier commentaire). Billet critiquable, mais dont le principal point pour moi est "Les libristes rejettent et dénigrent le design, ça irait mieux si on se faisait confiance mutuellement"
  3. avalanche de commentaires de devs en mode attaque sur le métier, le coût, l'utilité, et anecdotes sorties du contexte
  4. article sur LinuxFR montrant encore plus le côté obtus de nos communauté. https://linuxfr.org/users/igor--2/j... (on traite carrément l'auteur de "frustré", que son raisonnement est "débile", qu'il ne pense qu'à être embauché, on lui dit "qu'il n'a qu'a forker"... C'est sûr que ça donne envie d'aider !)

  Moi, ça me peine (vraiment). Je pense qu'on vient de donner une image détestable. Je me met à la place d'un non-développeur (ou même d'un designer), et je vois une communauté (trop) sûre d'elle-même, de ses compétences, de sa supériorité.
  Je suis conscient qu'on peut retrouver *exactement* les mêmes travers chez les designers. Mais p$!§%n on devrait être capable de se parler de façon un peu plus constructive

  Que des devs estiment ne pas avoir besoin de designers, pas de problème (perso, si je fais un soft pour moi, je me moque bien de son ergonomie/design/stratégie). Mais dans le cas inverse, on pourrait peut être écouter ceux qui pensent qu'ils ont des trucs à nous apprendre ? Au pire on utilisera pas leur conseils :P

  Bref, je trouvais Julien dur avec son « designer sur un projet libre, c’est L’ENFER. », mais en fait non : il a raison

  Je nous trouve plein de morgue dans nos réponses, et c'est bien dommage. Mais en tout cas très très éclairant...

• 59 De milouse - 10/02/2017, 18:09

  Je rejoins tout à fait @aaarg au final et un autre point qui a été abordé plusieurs fois : le souci du fonctionnement par incrément et contribution.

  N'étant pas du tout graphiste/designer/whatever, je ne dirai rien de ce côté là. Je veux juste partager une constatation de développeur : contribuer à un projet libre, c'est souvent, d'abord, déposer un ticket pour dire « ça, ça ne marche pas ou ça ne me plaît pas ». Après, la meilleure manière de se faire accepter dans la communauté en question est de proposer une solution au problème (patch, pull request, screenshot annoté, etc.)

  Comme cela a été plusieurs fois abordé ici, les projets libres, même les plus « gros » en apparence, sont souvent portés par peu de gens. Exemple de gimp, spip, dotclear, emacs… Je ne me froisse donc pas si un ticket mets plus d'un an à être pris en compte. J'avoue ne même pas compter le nombre de ticket qui semblent ignorés.

  Design ou pas, il ne faut pas penser que, parce qu'on a une bonne idée, trouvé une solution à un bug, produit une nouvelle feature, on va sauver le monde et le projet. Quoi qu'on puisse en penser, chaque projet avance comme il peut suivant une route qui lui est propre. C'est le principe même de la cathedral vs le bazaar.

  Et parfois ça marche pas du tout. Comme partout il y a des mauvais coucheurs, des affreux qui vous enverrons balader dans tous les cas. Et alors ? Ok c'est frustrant d'avoir une super idée et de ne pas se faire intégrer par la communauté. Mais c'est ça aussi le libre : la liberté d'emmerder le monde.

  Moyennant quoi (oui, ouf, j'arrive enfin à mon accord avec @aaarg), rien n'empêche de forker un projet, c'est le miracle du libre. Un logiciel semble tout pourri et on n'a aucun retour des devs ? Et bien on fork. @Julien dit qu'il est important d'impliquer un designer dès le début d'un projet. Mais rien ne détermine ce qu'est le début d'un projet ! De même que rien n'empêche des designers de lancer from scratch des projets (déjà évoqué), rien ne les empêche non plus de forker un projet pour se concentrer exclusivement sur du design ! Quitte à tout pêter en cours de route. C'est le libre, c'est permis !

  Quelques exemples qui me viennent en tête, pas toujours réussi (après, qu'est-ce que la réussite ? Un regret que je porte à cet article c'est son aspect « winner » : un projet qui n'aurait que 2 user ou à l'arrêt au bout de 3 mois serait forcément un truc de loser. NON ! Le libre (et c'est super important) sert aussi bien souvent à des développeurs à s'autoformer, seul ou à plusieurs, à tester des concepts, etc. Il n'y a rien de MAL à être mal branlé, pas utilisé ou abandonné. C'est la vie) mais qui montrent que ça peut fonctionner : openoffice vs lotus note machin d'ibm qui avait tenté les premier le principe du volet, désormais ajoutés dans libreoffice / gimp en une seule fenêtre, finalement mergé dans gimp quelques temps plus tard / Torcs vs Speed dreams / Gnome vs Mate desktop (oui car tout le monde n'a pas les mêmes goûts)…

  Désolé pour le long commentaire pas forcément clair non plus mais je voulais effectivement redire l'importance de la prise d'initiative dans le libre. Ne pas attendre d'être contacté/embauché etc. mais y aller à fond. Ticketiser / forker / appeler à l'aide.

• 60 De milouse - 10/02/2017, 18:34

  Du coup je vois que @pyg a commenté entre temps et que mon précédent commentaire peut effectivement être perçu comme légèrement ras du bonnet. Histoire de tenter de le redresser (même si j'assume entièrement mes propos), je serai curieux @Julien, que tu nous livres un mirroir à mon commentaire.

  Autrement dit, de la même manière que j'ai décrit un fonctionnement classique de travail dans le libre de nos jours (ticket/PR/fork/contribs), j'aimerai connaître les habitudes de travail des designers. Comment vous fonctionnez en vrai ? Afin que l'on puisse identifier les points de friction ou point d'accroche d'une relation. Tu semble dire que le modèle ticket/PR/fork/contribs ne vous convient pas. Que faire alors ?

  Pour reprendre les interrogations de @Pyg : j'ai mon projet, il a déjà démarré. J'aimerai avoir un·e designer avec moi. Imaginons que j'arrive assez facilement à en trouver un·e (tu sembles dire que le problème n'est pas là). Après quoi ? On fait des réunions en présentiel ? Comment lui permettre d'avoir de bonnes peer review comme tu l'évoques ? Iel place les propositions sur dribbble et iel attend ? Comment déterminer quand le design est bon (si on considère que moi, en tant que dev, je n'ai pas la parole) ? Est-ce uniquement un travail de presta « boîte noire » où je fais part de mon ressenti de mon logiciel et quelques temps plus tard « automagically » j'ai un truc à implémenter ?

  Oui tout ces questions font débile et super naïve, mais je n'ai effectivement pas la moindre idée de comment procéder et oui, j'ai souvent été déçu de mes précédentes interactions avec des designers. Du coup, j'aimerai vraiment avoir des retours sur comment améliorer cette situation, mieux se parler etc.

  Bref, aussi con que puisse paraître la question, quel est votre github ? Et donc effet tirroir, s'il le modèle même de github ne convient pas du tout, quel est ce modèle collaboratif ?

  Merci d'avance pour tes éclairages !

• 61 De neuneu - 10/02/2017, 18:52

  @pyg et moi effaré des attaques sur les devs. Ce post est hautain, méprisant au possible et proclame le designer comme seul étant capable de voir la vérité. C'est vraiment la bonne approche pour "discuter" ?

  Il n'y a aucune discussion ici, puisque la seule vérité est celle de Julien, qui est parfait et doit se coltiner des connards de devs. ("En fait on va pas tourner 10 ans autour du pot car les faits sont là", "ça peut être nié en bloc quelque part je m'en tape").

  Quand on dit qu'on sait que c'est important mais qu'on a pas les moyens, il n'entend pas. Quand on dit qu'on a le droit d'avoir un avis, il répond que non car on ne comprend rien. Quand on dit qu'on dev pour nous d'abord, il dit qu'on ne s'occupe pas de la cible. Quand on demande des définitions, il répond qu'on sait pas lire. Sa solution ? Remplacer la moitié des dev par du marketing. Avec quels moyens ? On ne sait pas ... il ne va pas s'abaisser à nous répondre de toutes façons. Certains ont pointé le manque de culture participative des designer. Aucune réponse.

  Et si son problème était là ? S'il expliquait son travail ? S'il se demandait pourquoi on lui fait telle ou telle réponse ? S'il montrait en quoi ce n'est pas pertinent sans mépris ? Non, son attitude ne peut-être remise en question, on doit se taire et exécuter.
  Alors oui, le dev libre n'est pas un milieu facile, mais je trouve qu'il n'a vraiment aucune leçon à donner sur ceux qu'il critique. Au contraire, quand il aura fait sa place, il s'y trouvera comme un poisson dans l'eau.

  Avant de venir ici j'avais une super image des designers. Je n'avais rencontré que ceux qui pensent qu'écouter fait partie de leur métier (sans doute les tocards). C'est dommage, dans ma boite, j'étais le seul à demander l'embauche d'un designer alors que le service client (aucun dev, je précise au cas où) a toujours rejeté la demande.

• 62 De pyg - 10/02/2017, 18:53

  @Milouse, ton commentaire n'est pas ras-du-bonnet. Je suis le premier à dire "si t'es pas content, tu peux forker". Ce qui me dérangeait était plutôt la forme (plus que le fond), notamment dans les réponses sur LinuxFR. (bon, après c'est trolldi, donc on se lâche plus facilement)

  On peut répondre à quelqu'un "Tu n'es pas satisfait ? Tu peux forker.", ça ne me choque pas du tout. Mais il faut laisser la porte ouverte au débat et aux propositions constructives (ce que tu as fait dans le commentaire suivant). Après, personne ne dit qu'on donnera un blanc-seing aux designers. Mais en lisant certains commentaires, je me suis dit qu'on fermait plus de portes qu'on en ouvrait :P

  Bref, au Bingo du Troll, on approche bientôt de la ligne complète : https://troll.framasoft.org/#5-7-9-...
  :D

• 63 De Jérémie - 10/02/2017, 18:58

  Bonjour et merci pour cet article. Je rejoins votre conception.
  Elle ne s'applique pas qu'au designer. Il y a beaucoup de logiciel qui sont adressés à des codeurs ou codeuses. Petit à petit démocratisons les logiciels libres et invitons chacun à s'impliquer (cela est déjà le cas avec wikipédia ou d'autres, mais bcp ne savent pas que certains de leurs logiciels sont libres et n'utilisent pas leurs données perso).
  C'est pourquoi il faut pousser les dynamiques de croisement avec l'éducation populaire ou l'économie sociale et solidaire. ( le collectif happy dev est dans cette démarche par exemple en poussant notre coopérative à choisir du livre pour la refonte de tout le SI).
  Le piratage et la libre modification sont des choses à porter.
  Merci à vous
  Jérémie Wach-Chastel

• 64 De RastaPopoulos - 10/02/2017, 19:20

  - Rapide première remarque Julien : le lien concernant le commentaire sur le logo de SPIP est donné en exemple pour appuyer une argumentation comme quoi ce n'est pas évalué par des pairs, avec des jugements persos subjectifs et non-étayés… sauf que… le lien pointe vers un commentaire de Mathieu Drouet qui est… un pair de Sébastien, graphiste, pas du tout dev ! Ce qui n'empêche pas que son commentaire était non-étayé donc pourri, mais quand même : ça ne colle pas avec l'argumentation du paragraphe du coup. Histoire d'être cohérent.

  - "Chacun son métier" : je comprends que c'est un article rapide mais quand même, je ne suis pas du tout d'accord avec cette direction (ni les commentaires qui vont dans ce sens). Mille fois oui on ne peut pas tout savoir, et chacun a des compétences, et on doit reconnaitre les compétences des autres. En revanche, ce n'est pas le monde dans lequel j'ai envie de vivre. D'après moi les devs DOIVENT se forcer à connaître des rudiments (voire plus !) de conception d'interface et de graphisme pour comprendre et discuter, et inversement les ergonomes et graphistes DOIVENT comprendre comment est architecturé tel ou tel logiciel s'ils veulent participer. Et on doit tous être capable de commenter *dans une certaine mesure* le travail des autres, même hors de nos métiers. Si depuis que je travaille, je travaille uniquement en SCOP, en coopérative, dans un environnement démocratique et en parallèle uniquement dans des communautés de logiciels libres aussi, ce n'est pas pour reproduire un putain de fonctionnement cloisonné avec des "chefs" qui chapeautent tout et où on doit dire Amen à tout ce qui n'est pas notre spécialité méga précise. Non : on doit apprendre à discuter *avec des arguments*, sur des choses en dehors de nos compétences précises. On doit apprendre à faire des choix ensemble, tout en respectant les avis de celleux qui connaissent plus en détail tel ou tel sujet. La démocratie ce n'est pas inné, ça s'apprend. Sinon c'est exactement ce que dit Stéphane : une technocratie. (Ce point vaut pour les devs aussi hein.)

  - Mais le principal : je ne suis absolument pas d'accord avec l'argument déjà présent dans l'article et repris par Tetue ensuite (mais on se dispute en se faisant des bisous sur cette question depuis des années haha :-*).

  NON une grande partie des devs ne font pas leur code gratuitement dans leur coin (et donc corollaire : soit disant il serait possible de faire pareil pour les ergonomes et graphistes aussi : bah non plus).

  En tout cas pas que. Très loin de là. Je ne nie absolument pas que ça existe, y compris dans des gros projets. Mais en ce qui concerne ce que j'utilise au quotidien depuis des années : les logiciels pour le web, les CMS, les frameworks de back ou de front, etc : pour tout ce que j'ai utilisé et utilise encore, l'immense majorité des contributions *en code* est le fait de devs qui ajoutent des choses sur leur temps de TRAVAIL, parce que ça correspond à une fonctionnalité dont on a besoin pendant un projet pour un client.

  Il y a aussi des contributions bénévoles, ou "pour le plaisir", ou "pour mon assoc", ne me faites pas dire ce que je n'ai pas dit, et ça m'arrive moi-même ! Mais réellement, la majorité est fait sur du temps de travail. C'est le cas y compris dans un "petit" projet comme SPIP, où l'énorme majorité des ajouts fonctionnels (notamment les plugins) sont faits parce que telle fonctionnalité n'existe pas et que telle personne en a besoin dans un projet. Et c'est d'autant plus le cas pour des centaines de plugins chez Drupal ou autre.

  Donc à mon avis il faut arrêter de baser votre argumentation sur le "travail gratuit" fait de nuit par plein de geeks barbu⋅e⋅s dans leur grotte en mangeant des chips. C'est une image d’Épinal qui ne correspond pas du tout à la réalité au quotidien. Nous sommes plein à préférer nous balader en forêt, jouer avec nos enfants, apprendre la musique, etc, sur notre temps libre, et oui ça nous arrive aussi de contribuer bénévolement mais ce n'est PAS la majorité des contributions, en tout cas dans les CMS et logiciels pour le web.

  En conséquence, postuler que ce point n'est pas un problème, et que les ergonomes et graphistes pourraient aussi donner de leur temps libre alors qu'on parle de faire des tâches méga complexes et méga longues (refondre l'interface d'admin d'un CMS ce n'est pas refaire 4 icônes !), ça me parait complètement farfelu…

  D'après moi, le problème principal n'est donc pas du tout uniquement qu'il y a une défiance envers ces métiers, et que la solution principale ce serait "juste" d'être mignon avec elleux en étant plus inclusif⋅ve⋅s. Même si nous les devs étions plus gentil⋅le⋅s ça ne changerait rien à la différence systémique.

  D'après moi le problème principal est avant tout qu'au niveau fonctionnel-code, 90% des contribs peuvent être payées dans des projets durant les jours de travail (je dis bien "peuvent", ce n'est pas toujours le cas, mais techniquement c'est possible), alors que pas du tout au niveau interface, ou encore pire au niveau communication général du projet libre (son site de présentation, la documentation non technique, etc).

  Pendant un projet classique (faire le site d'un magazine, d'une mairie, etc) il est très simple de faire rentrer l'ajout d'une fonctionnalité manquante (gestion d'abonnements, plugin d'animation de la page d'accueil, n'importe quoi…), *au moins en partie* même s'il peut manquer des choses qui seront ajoutées/améliorées bénévolement ensuite. Alors que jamais "refaire l'admin du CMS XXX", ou "refonte du site principal de XXX" ne sera intégré dans un projet durant la semaine de travail !

  Les projets où il y a eu des améliorations, c'est parce qu'il y avait des grosses boites riches derrière et/ou des fondations qui récoltaient des fonds, et dans les deux cas (boite ou fondation) qui payaient des gens. Auttomatic, Aquia, Canonical… Faut pas s'étonner.

  Je n'ai pas de solution toute faite. Seulement je constate cette immense différence centrale pour moi entre "création/ajout de fonctionnalités" et "création/refonte de l'interface globale" dans un logiciel.

  On peut dire que le temps, c'est de l'argent, et qu'il faut donc trouver de l'argent pour des ergonomes et des graphistes. Mais ce n'est pas si simple, et en plus en ce qui me concerne je suis contre cette solution telle quelle. Comme PYG et comme de tradition dans SPIP, je ne veux pas que la communauté soit liée à une grosse boite (comme Auttomatic pour WP, etc) ou qu'une fondation ait à choisir qui payer dans la communauté (super les relations entre les gens, et les conflits qui en découleront, pire que quand il n'y a pas d'argent).

  Pas de solution… donc continuer à discuter… mais en ce qui me concerne c'est un sujet très important, sans aucun doute.

• 65 De pyg - 10/02/2017, 19:28

  (@milouse, je t'ai fait une réponse, mais elle a été retenue pas la modération automatique)

  @neuneu : pour moi tu ne fait que compléter que le bingo
  https://troll.framasoft.org/#5-7-9-...
  Manque encore le Godwin :P

  Tu n'a pas l'impression de généraliser, là ?
  > Il n'y a aucune discussion ici, puisque la seule vérité est celle de Julien,
  => Ben si, on discute dans les commentaires

  > qui est parfait et doit se coltiner des connards de devs.
  => Généralisation à outrance.
  Il donne son point de vue. Si je viens affirmer un point de vue basé sur *mon*expérience (ex: "les automobilistes sont dangereux pour les cyclistes") je ne suis ni parfait, ni ne traite les automobilistes de connards.
  Par contre, le mec qui vient me répondre, "Mais non, c'est pas les automobilistes, c'est la faute (de la route|du fait que les cyclistes ne regardent pas|.*)", ben je peux écouter, mais je ne vois pas de raison de changer mon point de vue *si* je ne suis pas convaincu.

  Nos réponses ne l'ont pas convaincu, il nous le dit, il ne traite pas les devs de connards, non plus...

  > « (blabla) On ne sait pas ... il ne va pas s'abaisser à nous répondre de toutes façons. Certains ont pointé le manque de culture participative des designer. Aucune réponse. »
  => Euh, attends, j'ai raté un truc, là. Il est contractuellement obligé de nous répondre sous les 12H ? Sinon un chaton est assassiné ?
  S'il y avait une recette toute faite, toute simple, évidente, je pense qu'on aurait pas eu besoin d'ouvrir ce débat.
  Si on insistait gentiment et poliment sur la question des outils de collaboration, sur la prise en compte des historiques/contextes de développement, on arriverait peut être à construire des réponses, ensemble. Mais admettons que le traiter de frustré et autres noms d'oiseaux ne doit pas être très motivant pour répondre à chaud.

  > « Et si son problème était là ? S'il expliquait son travail ? »
  => Euh, ben il a quand même écrit un bouquin dessus : http://www.profession-graphiste-ind...
  Ha et il est aussi apparemment co-auteur de http://kitdesurvie.metiers-graphiqu... « ensemble d’articles originaux rédigés par des professionnels du graphisme, destinés à orienter et informer tous ceux qui abordent ce secteur ou y évoluent déjà. »
  (je précise que je ne connaissais pas le travail de Julien il y a 24H)

  //Edit de Julien : Il y a en fait confusion avec Julien Moya, je ne suis pas l'auteur du livre (mais j'ai participé à des initiatives connexes dans l'association métiers graphiques et pour le kit de survie)

  Après, c'est peut être de la merde, hein, j'en sais rien, j'ai pas lu.
  Mais bon, je n'attends pas une réponse divine dans un commentaire, non plus.
  La proposition, c'était qu'on ouvre le débat. Et là, je maintien qu'on lui (et les autres graphistes/designers s'étant exprimé) a fermé la porte au nez.

  > « S'il se demandait pourquoi on lui fait telle ou telle réponse ? S'il montrait en quoi ce n'est pas pertinent sans mépris ? Non, son attitude ne peut-être remise en question, on doit se taire et exécuter. »
  => Là encore, je pense que tu exagère. Il propose des pistes. Chacun est libre de les suivre ou pas.

  > « Alors oui, le dev libre n'est pas un milieu facile, mais je trouve qu'il n'a vraiment aucune leçon à donner sur ceux qu'il critique. »
  Il donne un point de vue. Qui moi aussi m'a bousculé (cf premier commentaire). De là à dire que c'est une leçon, je trouve que s'est s'emballer.

  > « Au contraire, quand il aura fait sa place, il s'y trouvera comme un poisson dans l'eau. »
  J'espère que tu te rends compte qu'en plus d'être péremptoire, ton propos peut être interprété comme "A lui de prouver qu'il est digne de travailler avec des développeurs. Quand il se sera plié à nos contraintes, il découvrira notre monde merveilleux, et connaîtra l'Éveil." #traduisonsles

  Bref, que ce billet soit imparfait, incomplet, ou que le ton ou les remarques nous bousculent et nous dérangent, je peux l'entendre. Ayant initié le msg sur Framasphère, je sais qu'il a été rédigé sur une soirée, et doit donc être pris comme une réaction à chaud.

  Maintenant, je reste choqué du fait que, parce que le contenu ne nous convient pas, une partie d'entre nous le rejette en bloc avec un ton dont je ne nous pensait pas capable.

  C'est pas la fin du monde, hein, mais du coup la réaction plus que virulente de certains m'ont fait prendre conscience que la dureté de notre communauté n'était pas qu'une fausse réputation

• 66 De milouse - 10/02/2017, 20:09

  @pyg apparemment ton commentaire est quand même passé. Enfin je crois xD

  Pour compléter mon second commentaire, je précise que lorsque je parlais de fork, c'était surtout dans un cadre « amical », pour développer de nouvelles idées justement. Je ne voulais pas parler des forks violents (joomla/mango, redmine/chili project…).

  En fait, à nous lire, je me demande si finalement un truc intéressant à faire ne serait pas de définitivement crever l'abscès ? Se poser tranquillement sur un pad et que chaque corps de métier écrive posément ce qu'il reproche à l'autre, de manière à avoir une meilleure vision globale de nos divergences et, comme je le notais dans mon second commentaire, voir les points de friction (et potentiellement les points d'accroche), afin de mieux panser les plaies ?

  Parce que s'il y a bien une chose que ce thread montre, c'est qu'en fait on n'a, des deux côté, qu'une vision super biaisée de l'autre. Alors plutôt que de continuer notre bingo, si on essayait de s'expliquer posément, quitte à saigner au début, mais qu'au moins tout soit dit ?

• 67 De Julien - 10/02/2017, 20:17

  @tout le monde : j'étais pas dispo aujourd'hui, je prépare un commentaire synthétique.

  @milouse : on peut forker (je l'ai déjà fait) mais le but c'était d'aider des solutions qu'on aime bien.

  >"Se poser tranquillement sur un pad "
  Un google doc tu veux dire ? :trollface:

• 68 De milouse - 10/02/2017, 20:19

  Side note: on m'a soufflé l'existence de ce site également pour essayer de mettre en relation différents acteurs potentiels pour des projets libres : https://projectgroupie.com/

  Bon pour l'instant, malgré l'étiquetage par métier demandé, il n'est pas possible de chercher que les projets nécessitant un designer ou a contrario les projets initiés par des designers et recherchant des devs. Mais l'initiative vaut peut-être le coup qu'on s'y intéresse.

• 69 De milouse - 10/02/2017, 20:21

  @Julien : on peut aider en forkant. Comme je l'ai précisé, un fork n'est pas forcément synonyme d'inimitié, bien au contraire : ça permet d'avancer dans son coin pour ensuite pouvoir le proposer quand c'est bon (et éviter du même coup l'effet « yakafokon »).

• 70 De Julien - 10/02/2017, 23:33

  Donc, pour essayer de synthétiser tout ça, en espérant répondre à toutes les questions :

  Déjà, le premier point que j'ai du mal à comprendre, même avec tous les commentaires, c'est pourquoi les devs (dans cette discussion) sont si chatouilleux et s'insurgent sur un point pourtant simple : que certains sujets sont mieux maîtrisés par des personnes dont c'est le métier. Ça me semble tellement évident que je ne vois pas pourquoi des gens se sentent insultés par ce simple fait ou parlent "d'ego".

  les développeurs développent mieux que les graphistes, les pilotes de courses pilotent mieux que les développeurs, les pizzaïolo font de meilleures pizzas que les designers, et les designers sont meilleurs en design que les développeur. Pourtant, seul le 3e point génère des discussions sans fin.

  Est-ce que c'est parce que certaines personnes ont du mal à avaler que c'est un vrai métier et pas un truc de guignol / diva qui fait des petits dessins ? Je me répète mais je ne vois même pas pourquoi ce point fait débat. Ça n'est ni insultant ni pédant que d'affirmer que quelqu'un dont c'est le métier connait mieux son métier que quelqu'un dont ça ne l'est pas. Get over it.

  Ceci étant dit, pour les autres points abordés :

  • Les trolls et l'accueil : franchement ça me fait juste rigoler, et au fond je me dis que ceux qui se lâchent le plus ne sont pas concernés par la problématique, donc tant pis, continuons entre gens de bonne volonté, et les autres suivront quand ils verront qu'ils sont comme des couillons sur le bord de la route à avoir lutté contre le progrès. À 99 % l'accueil du billet a été très bon.
  •  
  • C'est quoi le design ? Cette question est posée comme un piège, avec le sous entendu "ouuuhhh tu mélanges tout dedans c'est pas clair". C'est simplement que "design" est un terme qui regroupe tout ça. L'identité, l'ergonomie, une partie de la communication… Et c'est tout ou certains de ces aspects dont manque le libre, mais toujours dans la discipline "design".
  •  
  • Sur la collaboration impossible : Je pense qu'il est possible de collaborer, il faut juste comprendre que si on se prend ce genre de discussion à chaque modif / pull request (et c'est le cas, comme je le disais dans mon billet, et nous en avons la preuve en live) ben… ça ne donne pas envie de continuer. On ne participe pas pour le plaisir de prendre des coups. Néanmoins j'ai confiance en ceux qui ont compris l'intérêt d'une collaboration.
  •  
  • "Ha ouais et si on a pas besoin de com/design ?" : Ce point revient souvent, si vous jugez ne pas en avoir besoin ben… tant mieux. Tout projet n'a pas pour vocation à être largement diffusé / adopté / whatever. Comme certains l'ont dit, ça sert souvent à palier à un problème personnel, donc très bien. Je n'ai strictement rien contre ça.
  •  
  • "Oui mais l'UX…" : L'UX et le beau / pas beau revient dans presque tous les commentaires, avec un mélange d'un peu tout et n'importe quoi (par exemple confondre ergonomique et "beau", dire que parfois la ligne de commande est plus ergonomique, ce que personne n'a jamais nié, ou interpréter "design" comme "trendy" etc.) Moi je parle de design dans son ensemble, avec une vision holistique. Pour un logiciel donné, la ligne de commande peut être parfaite selon la cible, mais rien ne justifie une identité et une com' inexistante (si le logiciel a vocation a être largemet adopté)
  •  
  • La comparaison avec les softs propriétaires : De nombreux commentaires ont pointé que "c'est pas mieux dans le proprio". Je confirme, et ça n'est pas une excuse. La différence c'est que dans le proprio, on peut pas aider. Et aussi, le billet parle du libre.
  •  
  • Les anecdotes personnelles érigées en vérités générales : Oui vous avez sûrement déjà croisé un logiciel "que tout le monde trouvait beau mais pas vous" ou "qui soi disant est ergonomique mais a un bouton mal placé". Super, ça me fait une belle jambe, mais ça sert à rien dans la discussion, c'est hors de propos.
  •  
  • Sur la rémunération du travail : C'est une remarque pertinente, il est vrai que les devs sont souvent payés via leur boite, ou codent sur du temps payé pour enrichir un soft utilisé par celle-ci. Beaucoup plus difficile à adapter au design et/ou à l'identité, qui par définition doit être réalisée sur mesure, et avec un gros bloc en début de chantier. Je n'ai pas de solution pour ça, c'est vrai que les projets libres adossés à une boite ou une fondation ont moins de problème pour traiter cette question.
  •  
  • Sur la fragmentation du travail : C'est en effet un aspect difficile, on le peut pas dire en design "je fais une partie du logo parce que j'ai un peu de temps, je commit et je m'y remets". Certaines tâches sont fractionnables (surtout dans l'execution) d'autres moins, c'est peut être ce décalage qui complique les choses, surtout avec les outils habituellement disponibles pour contribuer au libre.
  •  
  • Sur forker un projet pour en améliorer les design : J'ai justement adopté cette approche pour repositionner le projet Librarybox sur un truc moins orienté bibliothécaires/profs et cibler les jeunes et les gens qui voyagent (pour partager du contenu dans le train par exemple) avec 2 approches différentes et 2 logos différents (bon exemple de "produit identique / positionnement différent). Une fois l'identité terminée, je voulais refondre l'ergonomie mais j'ai manqué de temps. Je trouve que c'est une solution viable si on veut complètement s'écarter du projet, mais un peu dommage si on veut soutenir le projet original car on l'aime bien. C'est un peu extrème quoi.
  •  
  • Sur mon utilisation du libre : J'essaye au maximum d'utiliser des logiciels libres, tout simplement car il faudrait être con pour préférer des solutions payantes et fermées à celles gratuites et libres. La seule condition c'est que ce soit aussi performant que d'autres logiciels, surtout pour une utilisation pro. Et ça n'est actuellement pas le cas pour mon OS (impossible d'installer mes outils pro sur Linux) ou mes logiciels professionnels (Pas d'équivalents à la creative suite, la suite google et d'autres). Donc je fais au mieux avec ce qui est disponible. Et vive Dotclear !
  •  
  • Sur ma participation au libre : Un détective en herbe de linuxfr a essayé de démontrer que comme je facturais des droits d'auteurs (c'est mon métier), c'est surement que je voulais juste saper le logiciel libre, et que mon billet était un cheval de Troie du grand capital. Au risque de le décevoir, je participe aussi au libre si j'ai du temps et à ma mesure (soit pas grand chose), en proposant des thèmes pour des CMS ou pour Atom, en codant (mal, car c'est pas mon métier, tiens tiens) des outils débiles ou utiles, en mettant quelques visuels en creative commons. Une typo que j'avais créée et mis en licence OFL s'est même retrouvée intégrée dans la distro Fedora. Plus récemment, ayant plus de temps libre et voulant améliorer la communication des outils libres, j'ai fait un appel à propositions pour aider les projets qui le souhaitaient à bâtir leur stratégie de communication, et ça a donné d'intéressantes discussion avec les projets Caliopen et Piwigo notamment (+ quelques autres, mais moins en profondeur).
  •  
  • Sur framasoft : Je termine par Framasoft puisque tout a commencé avec Pyg ;). J'ai su que le libre existait car un collègue m'a parlé de SPIP. J'ai ensuite cherché à creuser et j'ai trouvé toutes les informations vulgarisées sur Framasoft. Le pourquoi, le comment, la philosophie. Puis grâce à leur annuaire, j'ai découvert plein de softs libres. Puis la framakey… puis tout le reste. Ils m'ont même aidé à publier du contenu sous licence libre quand j'y pigeais rien mais que je voulais le faire quand même, via leur initiative dédiée dont j'ai oublié le nom. Tout ça c'est de la communication, et c'est une BONNE chose. Sans leur com', sans leur site, je n'aurais jamais découvert tout ça. C'est pareil pour tous les "framaservices" et la degooglisation. Des libristes étroits d'esprits pourraient se dire "gnagnagna les softs équivalents existent les gens n'ont qu'à se renseigner", mais ça ne marche JAMAIS comme ça. Et j'aimerais bien prolonger cette action de communication dans le libre pour faire encore plus connaitre et adopter les produits libres, et renvoyer l'ascenceur. Sinon le grand public n'adoptera jamais les outils libres. Ils ne les adoptent que quand c'est bien foutu et bien marketé (Firefox, Android…). Quand on ne connait pas les outils, on se lance souvent sur le ressenti.

  Pour conclure : je posais des pistes de réflexion pour proposer mon aide sur un sujet. On ne va pas se battre contre toute la communauté du libre et se justifier à chaque seconde pour améliorer un projet si personne ne veut de nous, c'est déjà assez bouffeur de temps comme ça. Du coup, soit ces critiques et ces pistes de réflexions (qui, si j'en crois l'immense majorité de réactions positives que j'ai eu sont largement partagées) sont utiles et c'est tant mieux, soit on ne change rien et… bah tant pis. C'est quand même dommage qu'à peu près tous les secteurs aient intégré que le design était un facteur améliorant depuis des siècles (millénaires ?) mais que le libre fasse encore de la résistance.

• 71 De Jojo - 10/02/2017, 23:48

  Je ne suis pas vraiment designer mais de "culture graphique" et je trouve la discussion super intéressante.
  De mon point de vue, Julien a tellement tout dit dans son post de départ + les quelques réponses aux commentaires que pour le coup je ne vois pas quoi rajouter de plus.

  Pour moi c'est clair que le jour où des initiatives comme Framasoft feront la diff, c'est le jour où des designers bosseront en amont des projets.
  Dans ce débat, le fait que Framasoft soit en quelque sorte le déclencheur du débat, pour moi c'est un bon signe que les choses évoluent dans le bon sens!

  Les outils Google deviennent petit à petit de plus en plus complexes, est-ce que le libre ne pourrait pas se démarquer en ne cherchant pas de faire l'"équivalent" mais en proposant des outils avec MOINS de fonctionnalités et un design mieux pensé que les outils propriétaires ?

• 72 De aaarg - 11/02/2017, 00:41

  Merci à @milouse d'avoir étayé mon commentaire. Je confirme en effet que moi également je ne considèrais pas le "fork agressif". Je pense même que forker et ensuite merger lorsqu'on a une solution qui prouve son avantage est une technique qui est apparue récemment et qui a peut-être énormément de potentiel pas encore exploité.

  @pyg: que certains le prennent mal, cela ne m'étonne pas même si je le déplore (et je déplore aussi des commentaires trollesques dans l'autre sens). Mais je pense que se focaliser là-dessus serait très dommage alors qu'on a l'occasion de justement avancer sur les discussions plus constructives.
  (Après, c'est dommage que l'apparence de la vitrine sur le libre qu'est linuxfr soit dominée par une petite dizaine de personnes qui sont très visibles parce que plus bruyant et qui ne sont pas des plus ouverts. Quand je fais un lien vers linuxfr, je prends soin de rappeler ça (que les plus bruyants ne sont pas forcément la majorité), pour éviter que les lecteurs ne tirent des conclusions sans se rendre compte de cet effet)

  @Julien: je pense réellement que ce que tu as montré en exemple sur Spip, c'est quelque chose que vivent les développeurs entre eux à longueur de temps. Je pense aussi que le refus d'intégrer ta collaboration est vue comme raisonnable par beaucoup de développeurs car eux-mêmes se sont rendus compte que refuser des collaborations est nécessaire si on veut éviter de défaire puis refaire (si un dev n'est pas convaincu d'une icône, il pensera avec légitimité qu'il peut exister une autre personne qui ne sera pas convaincu et que cette personne va elle-même proposer une solution, qui elle-même ne convaincra pas une autre personne, ...). Le créateur du projet est par la force des choses aussi celui qui mène la barque.
  (oh, et je pense aussi qu'il existe des bout de code que le développeur doit re-défendre à chaque commit en reprenant à nouveau les mêmes discussions)

  Du coup, je comprends les réactions de certains développeurs, car en pratique, ce que tu dis, à leur yeux, c'est que le designer devrait avoir un status particuliers que eux-mêmes n'ont pas (en ayant un accès privilégié à un aspect du logiciel).
  Cela explique aussi (selon moi) les accusations de diva: certains développeurs se prennent plein de refus, du coup, quand ils voient quelqu'un critiquer un refus et mettre ça sur une accusation de sectarisme de leur part, ils interprètent eux-mêmes ça comme une réaction d'égo.

  (le fait de dire que ce qui retient le libre, c'est juste le fait qu'on ne fait pas appel à vous est également un peu peu diplomatique. tout le monde a son avis sur "pourquoi le libre ne décolle pas", depuis des décennies, et je doute franchement qu'aucun d'entres eux soit en position de réellement prétendre connaitre la vérité. perso, j'ai mon avis aussi, mais je sais que mes idées peuvent être fausses et j'éviterais donc d'apparaitre "donneur de leçons")

  Peut-être que ma vision n'est pas l'exacte réalité. Mais peut-être que cela explique mieux certaines réactions, faites par des personnes qui ont une vision similaire à la mienne (mais qui n'ont pas pris de recul comme je tente de le faire).

• 73 De Okki - 11/02/2017, 03:08

  @Jojo : « est-ce que le libre ne pourrait pas se démarquer en ne cherchant pas de faire l'"équivalent" mais en proposant des outils avec MOINS de fonctionnalités et un design mieux pensé que les outils propriétaires ? »

  C'est justement l'approche du projet GNOME. Que ce soit simple et efficace. Ils accordent énormément d'importance au design (il y a d'ailleurs un designer payé à temps plein par Red Hat). Et pour que ce soit simple, il ne faut pas noyer l'utilisateur sous une tonne d'options superflues.

  Voir le blog d'Allan Day, https://blogs.gnome.org/aday/

  Et je pense qu'un certain nombre de critiques viennent de là. On a souvent reproché à GNOME de ne proposer que des applications simplistes. Mais comme le signale Julien, dès le départ, il faut savoir à qui l'on s'adresse, quelle est la cible. Une application pour monsieur tout le monde ou pour des utilisateurs confirmés ne proposera sans doute pas les mêmes options, avec un design qui sera lui aussi différent.

  Pour en revenir à GNOME, même si je ne suis pas développeur sur le projet (Adrien Plazas pourra sans doute mieux en parler), j'ai l'impression que leur équipe de design propose des maquettes accompagnées de commentaires ayant amenées à prendre telles ou telles décisions. Maquettes rendues publiques qu'on peut ensuite commenter. Et une fois que c'est validé, les développeurs peuvent implémenter tout ça.

  Il y a donc bel et bien des projets libres qui intègrent le design dès le départ. Et pour le coup, c’est pour moi l’environnement de bureau libre le plus simple d’accès, le plus facile à prendre en main.

• 74 De Jehan - 11/02/2017, 03:28

  Bonjour,

  Ce billet dit des choses justes, mais aussi d'autres qui me font peur, notamment après avoir vécu une mauvaise expérience avec un designer dans le libre justement.

  Globalement je suis totalement d'accord avec le fait que l'on doit laisser le designer bosser et qu'il est le boss dans son domaine. Il est celui qui doit avoir le dernier mot dans ce qu'il fait.

  Par contre, il est normal qu'il y ait une étape intermédiaire entre "inconnu au bataillon" et "mainteneur de tout l'aspect design du logiciel". C'est la même chose pour les développeurs. Dans beaucoup de logiciels libres, si un contributeur fait un très bon code dans une zone que personne n'a touché depuis des lustres, non seulement ce code sera accepté et intégré au logiciel, mais en plus si ce contributeur reste dans le coin et continue à contribuer, il sera considéré comme le "mainteneur" de ce bout de code et celui qui décide. Mais la condition, c'est bien: "si un contributeur fait un très bon code".
  Parce que du mauvais code, y en a aussi plein (développeur pro ou pas), et si un développeur se ramène dans un projet avec comme intro "J’ai 11 ans d’expérience dans le développement, j’ai réglé des problématiques conceptuelles sur des sites et des projets stratégiques gargantuesques impliquant des dizaines de personnes juste pour la partie logicielle, donc chill, je peux gérer ton projet", ben ça me fera ni chaud ni froid. Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.
  Note que j'ai croisé des professionnels qui ont des années d'expérience et dont les compétences m'impressionnent absolument pas, tout comme j'ai croisé des étudiants ou très jeunes développeurs qui trouvaient vraiment des solutions extrêmement pertinentes et qualitatives sur des problèmes très complexes. L'expérience, c'est important, mais ce n'est pas tout. Et ceci s'applique quel que soit le métier.

  Donc oui, je suis totalement d'accord sur le fait qu'il faut laisser travailler et avoir le dernier mot au designer, mais il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet. Tu ne peux absolument pas critiquer la décision de l'équipe SPIP comme tu le fais, par exemple. Note que je l'aime bien cette proposition de design, mais bon voilà, je contribue/décide pas chez SPIP. J'ai aussi eu des patchs refusés dans ma vie dans divers projets. Souvent j'y ai passé des heures et des heures. Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.

  Il y a aussi cette dualité stricte entre designer et développeur, que je n'aime pas. Comme je disais, je suis tout à fait d'accord que le designer doit décider des choses du design. Mais cela ne doit pas l'empêcher de pouvoir écouter les développeurs. Un développeur, c'est pas non plus un abruti qui a du caca dans les yeux, comme tu le dis si poétiquement. Ce n'est pas parce qu'on est développeur qu'on est forcément un débile du design ou qu'on ne peut pas avoir de bonne idées. De même qu'un designer peut aussi avoir de très bonne idée pour les développeurs (il n'est pas toujours nécessaire de savoir programmer pour comprendre le boulot du développeur, ce n'est qu'une — parfois minime même — partie du boulot de développeur, ce que certains designers ne semblent pas voir).
  Je parlais de mauvaise expérience, c'était justement avec un designer qui marquait une triple et très stricte catégorisation des gens: designer, développeur et utilisateur. Je me rappelle même qu'en réunion, une fois, il commence en notant un triangle sur tableau blanc pour noter les 3 catégories clairement séparées (la base de sa philosophie de contribution quoi). Il nous disait alors très clairement que les développeurs étaient des abrutis qui ne devaient absolument pas toucher ou parler du design. Un peu comme toi. Super expérience [ironique], je le dis tout de suite. Comme quoi, y a pas que les designers qui se font mal traiter par les dévs et peuvent mal vivre la collaboration (franchement j'ai très mal vécu cette collaboration et je suis très heureux qu'il soit parti, ça a débloqué beaucoup de choses car justement on le considérait comme le boss du design et on avait accepté son leadership dans ce domaine! Selon moi une erreur puisque c'était ce genre de personne, mais ça montre bien que c'est tout à fait possible). L'inverse existe donc aussi.
  Le fait est que le designer est en effet celui avec l'expérience, la connaissance théorique, etc. sur le design. Il est celui qui aura le dernier mot. Ça ne l'empêche pas de pouvoir parfois avoir tort (voire d'être mauvais, comme un développeur peut être mauvais, etc. Le fait d'être un professionnel n'empêche pas cela) ou de pouvoir revoir ses idées en prenant en compte des contre-propositions. Le dév, c'est un techos; mais ça l'empêche pas d'avoir des idées dans le champs du design, et parfois bonnes, qui sait! Quant à l'utilisateur (non parce que ce designer considérait aussi que les gens ne savaient pas ce qui était bon pour eux et qu'il ne fallait donc pas les écouter, ce avec quoi je ne suis absolument pas d'accord non plus; je ne sais pas quelle est ta position sur le sujet, mais puisque tu considères qu'il ne faut écouter que le designer dont c'est le métier, j'imagine que tu te positionnes donc aussi pareil?)… les designers et développeurs sont pas aussi des utilisateurs potentiels? Pourquoi faire une sorte de limite stricte? Au final, les "utilisateurs", ben c'est des gens. Et ils ont aussi le droit à une opinion (même si — encore une fois — oui ils sont pas des designers pros et le(s) designer(s) du projet sera celui avec le dernier mot).

  Ensuite dans ma vie, j'ai aussi eu de très bonnes interactions avec des designers (dans le logiciel propriétaire, c'est triste à dire!). Je me souviens de jobs où je lisais une spéc, puis j'allais m'asseoir à côté du designer et faisais quelques commentaires. Parfois il m'expliquait pourquoi mes idées n'allaient pas, puis après une discussion, je comprenais et remballais l'idée. D'autres fois, il comprenait mes idées, était d'accord, et faisait évoluer sa spéc. Franchement, ça se passait super bien, extrêmement bonne collaboration et très bon souvenir. Et c'était aussi un designer avec des années d'expériences, etc. etc. Mais la question n'est pas là!

  Au final, je conclurai généralement: le logiciel libre, c'est comme partout, c'est fait d'humains avant tout. Et comme tout entre humains, la collaboration, ça veut aussi dire discuter et savoir prendre un peu sur soi de temps de temps. Aussi savoir accepter les critiques d'ailleurs (du moment qu'elles sont constructives et pas agressives, bien sûr!).
  Je trouve que le libre est un très bon environnement pour se former à la fois une estime de soi, mais aussi une forme d'humilité.

  Je travaille sur des logiciels libres, dont un très gros, et je suis constamment à la recherche de designers qui accepteraient de prendre la charge du design (ou d'une partie de celui-ci) parce que c'est un très vieux logiciel qui a vraiment une vieille GUI basée sur des paradigmes d'il y a plus de 20 ans (22 ans cette année). Une fois qu'on se sera mis d'accord, on considérera leurs choix comme des décisions. Mais ça ne doit pas empêcher les discussions et clairement je suis à la recherche de quelqu'un qui ne considérera pas les développeurs comme des sous-hommes. Je ne dis pas que c'est nécessairement ton cas. Je n'ai aucune idée de comment se passerait la collaboration avec toi et ne connais pas ton travail, ni n'ai aucun moyen de juger vraiment juste par cet article de blog. Peut-être que ça se passerait super bien, qui sait! Mais j'avoue que ça fait un peu peur de lire ton avis sur la collaboration avec les développeurs, ou du moins ce que je crois en comprendre.

  Ensuite je lis peut-être mal entre les lignes et me plante peut-être sur tes dires et intentions. Donc bah j'espère que tu trouveras ton bonheur dans le design de logiciel libre! Car oui, beaucoup de logiciels en ont vraiment besoin (ceux auxquels je contribue aussi sont clairement du lot!). Je suis d'accord sur ce point.
  Donc bonne continuation!

• 75 De neuneu - 11/02/2017, 07:05

  @pyg : "J'espère que tu te rends compte qu'en plus d'être péremptoire, ton propos peut être interprété comme "A lui de prouver qu'il est digne de travailler avec des développeurs. Quand il se sera plié à nos contraintes, il découvrira notre monde merveilleux, et connaîtra l'Éveil." #traduisonsles"

  Non, je dis exactement l'inverse. Il fera parti de ceux qui accueillent mal les gens en les regardant de haut et ça ne lui posera plus aucun pb.

• 76 De Jojo - 11/02/2017, 10:03

  @okki Merci de m'éclairer sur Gnome, je n'ai jamais utilisé, seulement Mint (j'aime bcp) et Ubuntu(un peu moins). Je ne sais pas ce que ça donne en terme d'utilisation mais les captures Gnome que je vois donnent vraiment envie.

  De façon générale, je trouve que le design sous Linux s'est vraiment amélioré depuis quelques années, et s'il n'y avait pas la suite Adobe, il y a longtemps que je serais passé sous Linux!

  Bravo à l'équipe Gnome =)

• 77 De Panix - 11/02/2017, 16:24

  Tant de bonnes volontés s'engageant sur ces «pistes de réflexion pour le design dans le libre», ça fait chaud au cœur.
  Question: un designer travaillant pour le libre ne devrait-il pas se cantonner à l'utilisation de logiciels libre? Je me vois mal proposant des maquettes de la nouvelle barre d'outil Inkscape conçues avec Illustrator

• 78 De Julien - 11/02/2017, 16:38

  @Jehan

  Mais la condition, c'est bien: "si un contributeur fait un très bon code".

  Très bon (ou mauvais) code qui sera jugé… par des développeurs (dont c'est le métier) et pas par des graphistes. Tout ce qu'on demande depuis le départ c'est de SIMPLEMENT être traité comme les développeurs le sont.

  Et la réponse sera la même que pour un autre: ok on accepte les patchs, on attend le tien.

  Ça me va si celui qui me dit ça est à même de l'évaluer.

  il faut d'abord que ce dernier passe l'étape où on l'accepte comme un designer du projet.

  Je comprends, il faut aussi avoir le bagage pour pouvoir en juger.

  Je me répète, mais on voudrait simplement que ce que vous appliquez entre vous soit appliqué pour nous, c'est à dire se faire refuser des patches comme vous vous faites refuser des patches (vous par un développeur, nous par un designer) et se faire juger par nos pairs ou du moins des gens sachant de quoi ils parlent (ça peut être des devs si c'ets aussi leur domaine).

  Je pense que tu accepterais moins ces "refus de patches" et de contributions si elles étaient repoussées par des non devs sur des prétextes fallacieux. "Tenez j'ai codé un système pour améliorer la sécu" "lol non on en veut pas et on aime pas ton indentation".

  Bref, on ne veut pas de traitement de faveur, on veut juste être traité comme les autres contributeurs : que les contributions soient jugées, acceptées ou refusées par des gens au même niveau au moins que ceux qui les soumettent.

• 79 De Jojo - 11/02/2017, 16:54

  @Panix Théoriquement oui mais concrètement du coup on peut tourner en rond encore longtemps non ?

  - Les designers ne trouvent pas de logiciels de design libres vraiment pratiques à utiliser
  - Ces bons logiciels n'existent pas car les devs créent les outils de design en fonction de leurs propre besoins et logique (cf. Gimp utilisé par tous les devs mais par aucun designer car pensé par et pour les devs)

  Si les devs attendent un coup de main des designers, ben pas de solution magique, soit ça demande de s'adapter à la manière de bosser existante des designers et de bosser avec softs propriétaires, des psd et cie, soit les devs et designers s'attellent ensemble à concevoir un *vrai* logiciel de design, pensé avec et pour les designers. Je vois pas d'autre option en fait (mais si vous en voyez ça m'intéresse!)

• 80 De Julien - 11/02/2017, 17:00

  @Jojo : et ce logiciel surement bâti avec des softs proprios au départ, pour combler le manque.

  Je suppose que les premiers softs libres n'ont pas été designés/codés avec du libre :D

• 81 De Panix - 11/02/2017, 17:07

  Je suis designer et j'ai trouvé des logiciels qui me conviennent dans le libre. Je reconnais les défauts dont tu parles et trouve très finement observées les conditions de développement qui ont pu conduire à de tels défaut.

  Mais non, je ne suis pas tout à fait d'accord avec le constat de départ. En ce qui concerne un logiciel tel que Gimp, par exemple. Je veux bien entendre les arguments qui disent qu'un tel logiciel est boudé parce ses fonctionnalités ou son intégration dans un flux de production professionnel (ah, le CMJN et le libre!) ne peuvent pas rivaliser avec ses équivalents propriétaires. Mais dire que c'est essentiellement à cause de la laideur de son interface!

  En ce qui concerne le grand public, le boycott est plutôt à mettre au crédit d'une écrasante supériorité marketing. Ma grand-mère aurait donc plutôt installé Photoshop pour s'autoriser quelques rotations anti-horaire sur les photos de famille, uniquement parce que l'interface lui semblait moins moche que celle de Gimp? Allons donc!

  À l'inverse, il me semble que c'est le succès d'une application qui conditionne l'amélioration de son interface. Tu as parlé de WordPress. C'est d'abord l'extraordinaire légèreté, malléabilité, simplicité de cet outil, qui en ont fait le succès. Avec le succès sont arrivées les bonnes volontés, et l'interface a évolué dans le bon sens. Que dire de Prestashop dont les premières versions de l'admin étaient à chier?

  Franchement, mettre le peu de succès des applications libre sur le compte de la mocheté de leur aspect (alors que l'inverse me semble plus vrai), c'est montrer l'arbre qui cache la forêt.

• 82 De Jojo - 11/02/2017, 17:13

  Au devs qui nous lisent, on donne tout le temps Adobe en ref, mais c'est pas que c'est un horizon indépassable ou que personne n'est intéressé par une alternative.
  Je suis sûr que bcp de designers seraient au taquet pour une vraie alternative libre à la suite Adobe.

  Photoshop* est pratique mais 1) hors de prix 2) n'a pas évolué depuis 10 ans 3) tout ce qui a été rajouté, c'est essentiellement des gadgets qui ne font qu'alourdir le logiciel

  *même chose pour Flash et After Effects, avec les bugs et plantages en bonus.

• 83 De Jojo - 11/02/2017, 17:34

  @Panix Julien, d'après ce que j'ai compris, parle de design au sens large, donc pas juste "la mocheté ou pas" des boutons d'une interface, mais l'ergonomie générale, la stratégie, la conception et même le marketing.

  Après, tu utilise Gimp et c'est très bien s'il y a des designers qui peuvent s'adapter à la logique existante d'outils libres. Perso j'ai l'impression que c'est prendre le pb à l'envers, ce n'est pas parcequ'il existe des bucherons capable de couper des arbres avec un opinel qu'il ne faut pas construire des scies.

• 84 De Panix - 11/02/2017, 18:34

  @Jojo Je cite: «certaines interfaces de logiciels libres semblent être designées avec du caca sur une paroi rocheuse inégale avec le soleil dans les yeux». Je ne remets pas en question cette affirmation. Je dis juste que ce n'est pas la raison principale de la désaffection du public.
  D'ailleurs tu y vas un peu fort avec ta métaphore du bûcheron. Les logiciels libres que j'utilise (mais pas tous) sont tout à fait présentables et n'ont pas grand chose à envier à leurs concurrents. D'autres confrères seraient bien en peine de les utiliser dans le contexte qui est le leur, je te l'accorde. Moi j'ai mille arguments pour les défendre.

• 85 De Julien - 11/02/2017, 18:36

  @Panix : tu fais l'impasse sur le fait que les softs peu ergonomiques ont été au départ utilisé MALGRÉ leur mauvaise ergo. Je pense qu'on est tous d'accord pour dire que si ça avait été mieux dès le départ, beh ce serait pas dommage.

  De surcroit comme dit @Jojo je ne parle pas que d'ergonomie, mais d'une problématique plus globales. Et comme il le dit également, si on pouvait se passer de photoshop, on le ferait, je ne paye pas ce soft bugué et figé par plaisir.

  Pour mon travail quotidien, au moins une douzaine de fonctions n'existent que dans photoshop, je ne peux pas faire autrement. Et aussi, si, l'aspect, l'interface et le logo comptent autant que le reste.

• 86 De Panix - 11/02/2017, 19:03

  «Si on pouvait se passer de Photoshop, on le ferait». Je suis sûr de ta bonne foi, mais combien qui n'ont surtout pas envie de remettre à plat leurs habitudes? Sans effets de calques, sans calque dynamique, point de salut? Je parie que si. Et que tout le monde n'en a pas besoin. En tous cas pas le «grand public» dont tu parles également dans ton constat en début de billet. L'aspect repoussant de ces softs, peut-être. Le succès qui n'est pas au rendez-vous, certainement. Mais l'évidente corrélation entre les deux, franchement, je n'y crois. Donc, pour répondre à ta question «est-ce juste un problème de design graphique ?», je dirais: bien sûr que non, mon cochon.

• 87 De Jojo - 11/02/2017, 19:48

  @Panix Un logiciel qui est bien designé, cad bien pensé, clair et intuitif, t'as pas besoin de consulter trois tonnes de doc ou de te forcer à changer plein d'habitudes. En 1/2h t'as pigé le concept, tu trouve rapidement tous les outils dont t'as besoin et t'es opérationnel. Et après t'apprend en faisant.

  Si pour utiliser un logiciel alternatif les gens ont besoin de passer des heures à changer leurs habitudes intuitives par des trucs pas vraiment plus pratiques, c'est quand même un petit peu la faute au design s'ils finissent par aller voir ailleurs.

• 88 De aaarg - 11/02/2017, 21:10

  Je suis un peu déçu de voir la discussion retourner dans le cliché au lieu de bâtir sur les éléments qui semblent plus porteur.

  J'aurais aimé avoir une réponse de Julien concernant un aspect que moi et d'autres avons souligné (ici et sur linuxfr aussi d'ailleurs, même si on y trouve aussi des réactions lamentables).

  Mon analyse de la situation est que la réaction de Julien est légitime: il a *cru* qu'on traitait sa contribution avec moins de respect qu'une contribution qu'aurait faite un développeur. C'est donc logique qu'il s'en indigne.

  Cependant, maintenant, plusieurs personnes font remarquer que sa contribution n'a pas été traitée moins bien qu'une qui aurait été faite par un développeur, mais elle a été traitée comme toutes les autres (et parfois c'est pas idéal, mais c'est simplement la réalité: accepter une contribution dans laquelle on n'a pas confiance est une connerie)

  Julien répond à ça que les développeurs sont jugés par les développeurs, et que donc les designers devraient être jugés par les designers.
  Il y a eu plusieurs réponses à ça (et je peux revenir là-dessus si nécessaire), mais un élément qui me semble important, c'est que quelqu'un a remarqué qu'une des personnes qui a répondu à Julien dans l'exemple de Spip EST designer (bon, je fais confiance à ce que j'ai lu, mais ça me parait probable).
  Du coup, je détecte là la possibilité d'un biais de la part de Julien: peut-être que le fait d'avoir donné des avis négatifs a biaisé son jugement envers la possibilité rassurante que cet échec est le résultat de cette situation injuste où un design est jugé par un développeur.
  J'aimerais par exemple savoir si Julien, en lisant le commentaire de ce designer, s'est dit "encore un développeur qui juge sans rien connaitre" ? Auquel cas, c'est quand même qu'une partie du problème est imaginaire.

  Personnellement, je pense qu'on avancera jamais sur le sujet si les deux partis ne font pas des pas en avant. Et j'ai l'impression (mais ça peut n'être qu'une impression) que si les torts des développeurs ont été reconnus par plusieurs, la situation de départ continue à être considérée comme valide. J'aimerais que Julien se positionne plus clairement là-dessus, et dise si oui ou non il revoit sa position de départ maintenant qu'il a reçu une description plus claire de la situation.

  Je ne dis pas ça par provocation. Je pense que ce serait une bonne chose de couper l'herbe sous le pied de ceux qui veulent jeter de l'huile sur le feu en montrant qu'on fait preuve de bonne volonté et qu'on arrive à comprendre leur point de vue.

• 89 De STPo - 11/02/2017, 21:11

  @panix : le problème avec Adobe est moins la qualité de leurs produits (discutable) ou les habitudes des utilisateurs (une réalité) que leur profond enracinement dans la chaîne de production. On est les premiers à critiquer Photoshop (et plus encore depuis le racket organisé qu'est la CC) mais personnellement si j'arrête de l'utiliser je n'ai plus de clients. Toutes les agences utilisent le PSD comme format de dialogue, s'en passer c'est s'aliéner d'office une bonne partie de la profession. Un risque que personnellement je ne peux pas prendre, et je suis loin d'être le seul.

  Ça commence à bouger avec Sketch et Affinity, mais c'est long, très long...

• 90 De Salaam - 11/02/2017, 21:32

  Salut,

  Ça a l'air que chez Tails, on a compris que le design pouvait être vital, au sens propre :

  http://romy.tetue.net/ux-et-logicie...

  Sinon, très intéressant, article comme commentaires ! C'est cool de voir des designers se prendre la tête avec des libristes, en espérant que ça débouche sur plus de design dans le libre et plus de libre dans le design !

• 91 De Julien - 11/02/2017, 23:10

  @aaarg : pour spip, le commentaire screené est peut être celui d'un designer (j'en sais rien) mais je parle de l'intégralité du fil (d'ailleurs linké sur l'image). Également je parle aussi de gens qui savent de quoi ils parlent, quel que soit leur métier. Je répète que des des devs sensibilisés au design, ça me va très bien.

  @STPo : Affinity et Sketch, 2 softs propriétaires d'ailleurs (dont un uniquement sur Mac) qui arrivent à percer bien plus vite que gimp qui est sur le marché depuis une décennie. En comprenant mieux leur cible ? Mystère :).

• 92 De Panix - 12/02/2017, 15:19

  @aaarg Je suppose que le cliché dont tu parles a à voir avec cette guéguerre stérile entre utilisateurs de logiciels de design libres et propriétaires (Gimp vs Photoshop, pour ne citer que ceux là), et je me sens un peu responsable de la tournure qu'ont pris ces derniers échanges.
  Ce que je pense, au fond, et peut-être un peu naïvement, c'est qu'une façon de faire progresser l'offre libre en matière de logiciels, c'est justement d'utiliser ces logiciels. Les utiliser au quotidien. Retours d'expérience, rapports de bugs, augmentation des téléchargements d'un soft permettent sans doute de conforter les auteurs dans leur efforts pour améliorer leur bébé. Découvrir la retouche d'image avec Gimp, ce n'est pas plus décontenançant qu'avec Photoshop. Le grand public peut y trouver son compte, d'autant plus que c'est gratuit, et le logiciel s'en trouvera amélioré, de mon point de vue. Quant aux professionnels, ils peuvent toujours apprendre sur leur temps libre. Ça fera une corde de plus à leur arc, et ils verront peut-être aussi les choses différemment.

• 93 De karl - 13/02/2017, 06:38

  Il y a plusieurs types de design. Et en effet une direction artistique globale aide sur le projet. Cependant il y a un beau défi culturel des deux côtés. Par exemple, qu'est-ce qui fait qu'un code est élégant et beau ou qu'une interface en lignes de commandes (CLI) soit belle.

  Travailler sur une CLI est peut-être un bon moyen pour dialoguer entre un designer de visuel et un designer de code

  Exemple:
  http://www.slideshare.net/hyfather/...

• 94 De Balam - 13/02/2017, 11:49

  Pour rappel, et pour situer le socle du débat: "Je ne sais pas comment on peut autant s'égarer. Cette croyance du libre que le design peut se traiter en démocratie et pull request." ( https://twitter.com/mariejulien/sta... )

  Que le design ne se fasse pas en pull request, ça peut être compréhensible (le design étant quelque chose de générale, souvent très en amont, avec une vision globale). Mais le côté démocratie, on en fait quoi? C'est "je décide seul, ta gueule"? C'est pas ce qui est proscrit dans l'article à l'encontre des développeurs?
  La démocratie, s'il en est, dans le libre est incompatible avec le design que tu représentes. Le design a une vision globale, ensembliste, imperméable au partitionnement. Ce qui est l'exact inverse du dev-model du libre, qui ce veux à dessein assez horizontal (donc de fait plutôt anarchique, avec des sous-projets, des forks, diverses branches… ).

  Tu aurais gagné du temps en disant: il faut un designer dés le départ. Et expliquer tes raisons, plutôt que de distiller des arguments que les dev libristes auront du mal à comprendre parce que contraignant après coup. C'est dommage. Solution qui arrange tous le monde, in fine, puisque meilleur base si le designer est là au début, meilleur code puisque créé pour le design. (cf. le nombre de projets logiciels, qui changent du tout au tout lors d'un (re)design)

• 95 De Leverbal - 13/02/2017, 12:40

  Continuez de creuser ces pistes, il en faut plus des débats de ce genre !
  Je me souviens d'un atelier de Vitaly Friedman il y a 3-4 ans au web2day à Nantes, où il avait commencé par dire que le métier de designer d'interface était sans doute l'un des plus complexes au monde.
  Oui créer le design d'une interface est extrêmement complexe parce qu'il faut en permanence changer de point de vue et intégrer dans son travail tout un tas de contraintes, qu'elles soient liées au fonctionnel, à l'accessibilité, à l'utilisateur, au marketing et j'en passe.
  Faire une contribution en tant que dev sur un logiciel libre parce qu'il y a un bug, parce qu'on veut ajouter une fonctionnalité, c'est l'équivalent de corriger la forme d'un picto ou d'ajouter un thème (et là je commence à me faire des copains).
  MAIS est-ce que dans le libre les designers interviennent pour juger de l'utilité fonctionnelle d'une contrib de dev ? Est-ce qu'ils donnent leur avis en tant qu'utilisateur de tel ou tel aspect d'un logiciel ?
  Il y a bien un triangle dev/design/user, mais est-ce que dans les faits les designers jouent (ou peuvent jouer) le jeu sur les contributions en tant qu'utilisateurs autant que les devs ?

• 96 De Chonunca - 13/02/2017, 16:34

  A titre perso, je pense que la solution la plus simple (au niveau gestion des avis négatif) c'est qu'au niveau du logiciel, ils développent un systeme de template, comme dans dotclear par exemple, n'importe quel designer pourra proposer son template et etre accepté sans plus de votes (tant que la proposition introduit pas de bugs majeurs). Ensuite libre a ceux qui aiment de switcher de template si le design leur plait, et a ceux a qui ca plait pas de garder le template par défaut.

  Perso étant un dev et n'ayant aucune compétence en design je pense toujours mes créations comme ca, je sépare toujours le code de l'interface, je le prévois à l'avance pour que tout a chacun puisse s'appuyer sur un template par défaut vierge, et de proposer un systeme qui scan tous les templates ajouté pour les proposer a l'utilisateur, libre a lui de choisir le template qui lui plait.

• 97 De Julien - 13/02/2017, 20:08

  @karl:

  >Travailler sur une CLI est peut-être un bon moyen pour dialoguer entre un designer de visuel et un designer de code

  Je ne sais pas pourquoi tout le monde m'oppose la CLI comme le contre argument ultime. Oui, une CLI est parfois la solution la plus adaptée, oui elle est aussi designée, oui les designers peuvent y participer. Reste tous les obstacles listées dans ce billet (et le suivant).

  @Balam : intégrer un designer depuis le départ, c'est exactement ce que je dis… depuis le départ. Sauf qu'il y a des projets déjà bien avancés, du coup on fait comment pour ceux-là ?

• 98 De Balam - 14/02/2017, 14:09

  @Julien Justement, la question que je poses, et que personne ni l’article, ni le suivant, ni les commentaires ne répondent. Forker c’est un bof/non, pull request: c’est supra-NON et intégrer un designer (soit il bon, soit il compétent, soit il gentil, soit il ce que l’on veut) en cours de route c’est difficile/compliqué/ingérable.
  Est-ce que arriver en cours de route, faire un “freeze” du code, se pencher sur le design et faire une v.X+1 ça t’irais? Ça parait injouable bénévolement sur du libre (puisque faut le coder, mais ça peut se tenter si en parallèle ça sort pas trop de features)

• 99 De RastaPopoulos - 14/02/2017, 17:16

  @Balam, si la volonté est là, quelque soit l’outil de versionnage, c’est à ça que servent les branches à priori hein…
  Mais pour ça il faut que la volonté soit là justement… et que donc celleux qui ont la main sur le code, s’organisent pour bosser en bonne collaboration avec des ergos/graphistes/etc sur une branche dédiée.

  Après ça dépend des projets, il existe aussi des logiciels où l’interface principale est elle-même conçue “modulairement”, notamment dans les CMS (mais pas tous). C’est le cas par exemple pour SPIP (et pour Drupal il me semble). Ce qui permet notamment de faire un plugin qui surcharge/remplace totalement l’interface par défaut, et donc de pouvoir travailler à part, en parallèle, même sans brancher le noyau pour ça, juste dans un plugin.

  Mais bon on le répète, c’est la volonté humaine qui prime d’abord, pour s’organiser et prendre des décisions en prenant en compte d’autres avis que juste les devs qui valident le code à la fin. Au niveau technique, même s’il peut y avoir des soucis, quand on veut vraiment on trouve des solutions.

• 100 De pat3 - 16/02/2017, 11:17

  N’étant ni développeur ni graphiste, ni totalement béotien (newbie), je trouve l’article et la discussion qu’il a déclenché vraiment très intéressants. Mais peut-être qu’il y a des malentendus qui excèdent le cadre du conflit/de la collaboration dev/graphiste (je suis d’accord que le terme designer est déjà en partie ambigu, je m’expliquerai plus tard sur ce point), et qu’il faudrait éclairer pour éviter les chausses-trappes de la discussion sans fin. Je propose de les résumer ci-dessous.

  ## L’opposition *code* VS *graphisme* est… caduque
  Je crois qu’il faut rappeler que sans le design d’interface, 80% d’entre vous n’aurait pas de boulot. L’informatique était juste inaccessible aux non ingénieurs en informatique avant l’avènement du WIMP (Xerox -> Apple -> Windows), et vous refaites en partie un débat plié depuis le premier mac : sans interface graphique, pas d’informatique grand public, mais pas non plus d’informatique professionnelle pour tous les métiers graphiques, voire même juste visuels : je vois mal les monteurs vidéo, les graphistes, les journalistes, les écrivains, et en général l’ensemble des producteurs de contenus travailler à la ligne de code.
  Ça devrait être suffisamment clair pour qu’il n’y ait pas de débat sur la supériorité des uns ou des autres: sans codeur, pas d’informatique, mais sans graphiste, pas d’informatique grand public - pour ne pas dire, juste publique, et non réservée à une poignée de spécialistes.

  ## *Ce qui se voit* VS *ce qui ne se voit pas* (du point de vue de l’utilisateur)
  Un préalable à la discussion aurait pu être : le travail d’un dev ne se *voit* pas (on l’expérimente sans le savoir), celui d’un graphiste se voit (on l’a tout le temps sous les yeux). Le travail du dev ne se voit quasiment que quand il n’est pas bon : le logiciel plante, ralentit, cafouille, on se dit que ce logiciel a été développé avec les pieds (quand on est un peu informé, sinon, on se dit juste : poubelle).
  Cette dissymétrie du point de vue de l’utilisateur est cruciale : des tas de gens ne “savent” même pas ce qu’est un développeur. Pour eux, il y a “les informaticiens”, une race qui commence à partir du moment où tu as redémarré leur ordinateur bloqué et qu’ils ont retrouvé leurs données, et les autres : eux, les utilisateurs, qui n’y connaissent rien, et dont l’opinion oscille entre “c’est génial” (snapchat, l’interface tactile, le chat vidéo, les réseaux sociaux) et “ça marche pas” (mais qu’est-ce qui ne marche pas exactement? - j’sais pas ça marche pas, c’est tout).
  Mais ils savent ce qu’est un graphiste.
  Du coup, oui, pour les gens, même s’ils ne savent pas le dire explicitement, une bonne interface, qui leur permet de penser qu’ils maitrisent un peu l’usage de leur machine, ben c’est chouette, c’est le début de la félicité interactive (le succès du tactile multipoint est là pour le démontrer).

  ## Le design est *nécessaire*… à l’utilisateur
  Les développeurs ne le comprennent pas toujours (ou toujours pas, selon qu’on veut être taquin ou non), et dans le libre, on dirait juste que c’est encore de l’ordre du facultatif. Ok, ça l’est certainement pour un développeur (et encore, les IDE ne sont pas tous *dépourvus* de design).
  Mais dans un monde du presque-tout-tactile et du bientôt-l’interface-vocale-généralisée, c’est quasiment suicidaire de penser qu’on va continuer à créer des applis en ligne de commande en espérant que les gens auront envie de s’en servir.
  Non, LES GENS NE VEULENT PAS UTILISER UN ORDINATEUR, ils veulent obtenir le plus rapidement et le plus confortablement possible un résultat (parler à X, lire les news, voir des vidéos, écrire à Y, lui envoyer une photo, regarder le monde à travers l’écran, etc.), comme ils veulent aller le plus vite et le plus confortablement d’un point à un autre avec un véhicule, uber / blablacar / le train / l’avion, et pas prendre la voiture, le bus, etc. L’ordinateur (ou le smartphone) n’est qu’un moyen qui doit être le plus transparent possible (ou mieux, le plus agréable possible) pour arriver à ses fins.
  On peut considérer que c’est dommage et qu’il faut justement amener l’utilisateur à être plus actif, plus intelligent que ça, mais ce n’est certainement pas en lui proposant des interfaces moches ou imbitables qu’on a des chances d’y arriver.
  Le design d’application est en train de prendre ça en compte avec l’UX Design, qui n’est pas que du graphisme, mais bien du code efficace avec une interface ergonomique et un graphisme agréable, pour une expérience agréable (facile, puissante - au sens de l’empowerment -, esthétique) de l’utilisateur.

  ## Domaine technique et cour de récré
  L’autre point de malentendu, me semble-t-il, est vieux comme le monde de la technique, et, pour le dire trivialement, ressemble au concours de quéquette de la cours d’école, en version adulte, homme, et technologique : l’ingénieur snobe le développeur back-end qui snobe le développeur front-end qui snobe le graphiste qui snobe l’artiste plasticien qui snobe le critique qui snobe le public… Qui en retour se fiche des critiques, qui se fichent des artistes, qui se fichent des pisseurs de commande que sont les graphistes, qui se fichent des développeurs front-end etc. Chacun se sent légitime et attaqué dans sa spécialité, et considère que la légitimité de l’autre est douteuse, et se sent puissant quand il peut faire la preuve de son exclusivité (sans moi, tu ne peux faire ça)… C’est une question de territorialité, et en cela, l’homme reste un animal comme les autres.

  ## Numérique et *bien commun*
  Or, on est tous sur le même bateau technologique : le numérique n’appartient ni aux uns ni aux autres, il est fait de couches successives que chacun s’approprie à sa mesure, mais il est devenu un environnement technologique englobant.
  Le web, par exemple, est un bien commun, de ce point de vue. Ce n’empêche pas d’y faire ses petits, d’y mener ses projets, de s’en nourrir; mais cela induit que nous partagions nos ressources, et que collaborent les utilisateurs des différentes couches : oui, sur un projet web, on peut utiliser un framework, un CMS ou un template pour se passer d’un développeur ou d’un webdesigner. Mais ces outils sont le fruit de la collaboration de développeurs et de webdesigners au bien commun.

  ## Projet libre et niveau de diffusion
  Alors pourquoi ne pas essayer de trier les projets libres par niveaux de diffusion ? Cela pourrait donner une idée du moment auquel le designer (graphique, UX) pourrait s’y investir, et éviter la guerre de territoire entre organes du même organisme :
  - si un projet libre est fait pour satisfaire son auteur, c’est un projet privé, il ne concerne que celui qui l’a créé pour ses besoins - et ses besoins d’interface ne concerne que lui ;
  - si un projet libre est partagé entre développeurs, c’est projet semi-privé, mais comme il est partagé, il a déjà besoin d’un consensus ergonomique.
  Mais ces logiciels sont aussi utilisés par des amateurs, plus habitués à une interface conviviale qu’à l’austérité de la ligne de commande. En cela, les projets libres semi-privés qui connaissent un peu d’audience deviennent rapidement semi-publics. L’élargissement de leur audience amène à penser qu’il sera nécessaire, pour la pérennité du logiciel, d’adjoindre des compétences de design graphique à l’équipe qui le développe; et pourquoi pas le penser ainsi dès le départ ?
  Ces amateurs contribuent à la notoriété de ces logiciels - *ou, si on ne les aide pas à le prendre en main, contribueront à la notoriété d’un logiciel plus facile d’accès.*
  - si un projet libre vise l’utilisation par des usagers non codeurs, c’est un projet public, et il devrait d’emblée prendre en compte l’utilisateur final qu’il vise (geek, spécialiste, grand public, débutant, …), ce qui veut dire : penser le design (des choix de développement à l’interface graphique) en fonction des compétences et des capacités de cet utilisateur (on rejoint la philosophie de l’UX Design). C’est peut-être là que le designer graphique est nécessaire, et c’est le cap que ne passe pas la majeure partie des logiciels libres… Mais je connais aussi de nombreuses exceptions que j’utilise fréquemment (de Freemind à Handbrake, en passant par certains logiciels de Framasoft)…

  Les graphistes et les développeurs ont chacun du chemin à faire vers l’autre, à mon avis. Les graphistes vers la problématique de développement d’un logiciel et l’anticipation de son utilité (qui guide son design, me semble-t-il), les développeurs vers la culture du design, qui dépasse largement celle du design d’interface, même si les principes restent les mêmes: fonctionnalité, utilisabilité, plaisir. Dans les deux cas, ce chemin mène à l’utilisateur, et on pourrait espérer que celui-ci s’intègre à la boucle si on vient vers lui.

  PS: écrit en Markdown, juste parce que ça me clarifiait les idées…

• 101 De Mika38 - 03/04/2017, 19:52

  Bonjour, je vais essayer de me concentrer sur les solutions et pas les causes. Voici les solutions que j’essaye de mettre en place pour FreeCAD: Mon premier objectif est de recruter plus de diversité dans la communauté, entre autre des designers. En consultant d’autre projet FOSS, j’ai repéré trois solutions :
  1) Améliorer la première impression. Pour ça, je vais mettre au même niveau tous les Rôles : dev, doc, trad, design, promo, admin/web dev. Je prends exemple sur le site web de Fedora.
  2) Mise en place un outil de visualisation des contributions quelques le rôle. Ainsi un designer sera autant visible qu’un dev. Peut-être quelque chose comme le karma de Inkscape (rechercher « Inkscape Top Contributors on Launchpad »).
  3) Création d’un blog, pour que les différents acteurs du projet soient au courant de l’évolution du projet. Cela va permettre au designer de mieux comprendre ce que fait le développer et vice versa , et peu-être les mettre en relation.
  Ensuite, faire en sorte que le développement soit orienté par les besoins des utilisateurs et non pas par les envies des développeurs:
  1) Intégration dans le logiciel d’un bouton pour reporter un bug, comme sur « onshape.com » ( !non open source !). Cela va augmenter les retours utilisateur.
  2) Faciliter l’installation de la version de développement, pour que n’importe qui puisse repérer les derniers bugs.
  3) Recueillir les besoins des utilisateurs, puis les résumer sous forme de fiches utilisateurs génériques. Ainsi, les développeurs auront une meilleure idée de leur audience. Solution assez courant chez Gnome.
  Enfin, comme proposer plus haut, je vais essayer de former les développeurs du projet aux notions de design. Là, je n’ai pas de solution: il faut que je fasse des recherches. Si vous avez des d’autres pistes, je suis tout ouïe.
  En essayant de faire avancer le débat,
  Mika38