Design et Libre

Ce post aujourd'hui part d'une réflexion de Julien Dudebout sur le blog Marie & Julien. Cette réflexion part d'une bonne intention en soit: Faire réfléchir sur, Pourquoi la majorité des softs open-sources à vocation grand public ont une interface mal designée. J'ai par contre beaucoup de mal avec le ton employé. L'idée est sérieuse mais le ton est à la limite du troll ou de l'humour foireux et les commentaires ne sont guère mieux dans l'ensemble. Il m'a fallu du temps pour écrire et essayer de prendre du recul.

Commençons par le commencement

Définitions

Design, un mot fourre tout à usage principalement marketeux mais sans avoir jamais de vrai explication de ce que c'est censé englober suivant le domaine où il est employé. Non, c'est pas ça la définition? Julien ne la donne pas vraiment non plus et c'est bien dommage, car dans son article, on a des moments où on parle de logo, d'autres moments de l'interface, d'autres moments encore d'ergonomie, ... Bref, plein de choses finalement mais une brève définition de ce qu'il entend par design ça donne une petite idée pour comprendre ce qu'il entend par là. Il faut trouver au fin fond du 70ème commentaire fait par Julien, pour n'avoir encore qu'une vague idée de ce qu'est design pour lui.
Design: L'identité, l'ergonomie, une partie de la communication,...

Partons de là, nous avons une définition disons acceptable.

Ensuite, il nous faut d'autres définitions:

Utilisateur: Personne utilisant le logiciel
Développeur: Personne développant une fonctionnalité ou l'ensemble d'un logiciel
Designer: Personne s'occupant de concevoir l'identité, l'ergonomie, la communication du logiciel

Ces trois là me semble importantes.

Le design, pourquoi et pour qui?

La question n'est jamais posée et c'est bien dommage car elle me semble importante et on retrouve au détour de certains commentaires une vague réponse à cette question. Le design c'est tout ce qui est à destination de l'utilisateur d'un point de vue ergonomie, interface, identité visuel. Tout doit être fait pour rendre service à l'utilisateur le plus simplement et agréablement possible. Mais il nous faut séparer ensuite plusieurs choses: Pourquoi et Pour qui est fait ce design?

Il y a un manque de clareté que ce soit dans les commentaires et dans l'article. Pourquoi, est pourtant la question qui me semble centrale dans ce billet. Pourquoi devrais-je m'intéresser particulièrement au design lorsque je fais une application, pourquoi ça devrait être important, pourquoi devrais-je commencer avec un designer quand je fais une application,...

Pour répondre à pourquoi, il est nécessaire de s'intéresser à pour qui? Ce logiciel que je conçoit et que je vais rendre open-source. Je le fais pour qui? Pour moi en premier lieu? Pour une poignée d'utilisateurs identifiés? Pour le grand public?

Ici, si on se résume à ça, nous avons donc 3 populations différentes et donc 3 niveaux de réflexion sur le design différentes.

  • Pour le grand public: on est d'accord il faut penser au design et le plus tôt possible mais ne pas oublier quand même qui est l'utilisateur cible. Un utilisateur industriel n'a pas les mêmes attentes qu'un utilisateur grand public, que ce soit en terme d'ergonomie, de design,... Un design gris avec des boutons carrés, convient bien à un industriel qui s'intéresse aux fonctionnalités tandis qu'un utilisateur grand public s'attendra à des choses un peu moins austère.
  • Pour une poignée d'utilisateurs: c'est déjà nettement moins essentiel, Il faut voir le temps que prend cette réflexion/analyse et le gain qu'elle apporte par rapport au temps que le développeur a à accorder au projet et si ça apporte quelques choses à ces quelques utilisateurs où s'ils s'en moquent éperdument.
  • Pour moi: je n'ai clairement pas le temps et le besoin de passer un temps fou sur le design. L'application n'étant pas destiné à avoir une audiance autre que moi et peut être quelques autres personnes qui trouverai mon projet intéressant pour eux.

Dans un commentaire, quelqu'un dit plus ou moins ceci:

"Si tu ne vises pas l'adoption par d'autres utilisateurs pourquoi le mettre en open-source et le publier?".

Ce commentaire pose la question de l'idéologie derrière le libre. Si je conçois un logiciel pour moi, ne veut pas dire que je penses et estime être le seul utilisateur possible. Je ne prétends pas connaître les besoins de la planête entière. S'il ne me sert qu'à moi, tant pis, s'il sert à d'autre tant mieux, c'est bien, mon travail sert d'autres gens. Et c'est bien là le point de départ de la majorité des projets open-source. Il n'y a en pas beaucoup qui dès le départ se sont dit: "Bon ce logiciel, il vise directement l'adoption par 10 millions d'utilisateurs, la disponibilité sur l'ensemble des plateformes et bien sûr il me faut une communauté de développeurs derrière"

La majorité des projets open-source, commence seul et reste développés seul et ce même quand ils sont utilisés par beaucoup de monde.

Et ce dernier point pour beaucoup de raisons diverses:

  • Personne n'a envie de travailler avec le développeur du projet.
  • Le développeur du projet refuse toute contribution à son code.
  • Le développeur n'a pas le temps de gérer des contributeurs ou des contributions.
  • Les moyens de contribuer sont difficile ou inutilisable
  • Personne ne prend le temps de se plonger dans ce projet
  • ...

Ceci explique pourquoi la grand majorité des logiciels open-sources ne se préocupent assez peu du design. Manque de temps et intérêt limité aux vus de la cible, car oui ceux qui visent le grand public directement sont très très peu nombreux au départ et ceux qui réussissent à atteindre leur cible encore plus. Et je compte pas tous les projets abandonnés en cours de route qui n'auront jamais vu de première version. Intégrer un designer pour que lui aussi perde son temps au final car le projet ne nous est plus utile, ne nous intéresse plus,... me semble assez peu pertinent.

Collaboration

Selon Julien, contribuer c'est l'enfer pour un designer. C'est bien possible mais son discours dessert son propos car il manque à mon sens d'analyse sur un certain nombre de point.

Les outils

Utiliser git, faire des pull request sur Github, Gitlab ou autres c'est l'enfer et pas adapté pour un designer. On ne modifie pas un design par petite touche, si je résume. Je ne vois en aucun cas à quel moment un designer à besoin d'aller là dedans s'il ne touche pas au code. Uniquement pour les assets graphiques, auquel cas oui, il faut se mettre à utiliser ces outils. Pour le reste, ses contributions vont passé par la création de ticket, l'écriture de mail sur une mailing liste, un wiki, ou autres. Et s'il manque des outils, c'est effectivement au designer de le signaler, de faire entendre leur voix pour que ces outils arrivent un jour. En attendant, il faut trouver des parades et éventuellement apprendre à utiliser les outils de l'autres.

Les outils sont aussi revenu dans les commentaires ou sur twitter. Le Designer utilise photophop, illustrator, ou autre. Pourquoi pas, mais le principe de l'open-source c'est que n'importe qui puisse prendre les sources, les analyser, les modifier. Ceci doit aussi s'appliquer aux éléments de design. Le soucis des logiciels cités c'est que le format "source" est fermé et plus ou moins bien supporté par d'autres outils libre. Il faut donc avoir un format ouvert, sinon on impose un outils propriétaire dans un projet open-source. Je laisse le choix aux développeur d'utiliser sont éditeur favori propriétaire ou non tant que le format du fichier est ouvert, il doit en être de même pour les assets. Fournir la sortie png ou autre de l'asset graphique n'est pas suffisant pour satisfaire au besoin de pouvoir étudier, modifier la source. De plus, fournir un fichier dans un format propriétaire pour de l'open-source est limite aussi insultant que proposer un steak de boeuf à un végétarien.

Qui pour juger?

Une fois la question des outils passée: qui est en droit de juger le boulot d'un designer? Et c'est là que je trouve qu'il manque le plus son propos. Il confond plein de choses et les définitions que j'ai donné plus haut sont importante. On a 3 populations importantes qui se recoupent: Designer, Développeur, Utilisateur. En effet, je ne trouve pas pertinent qu'un designer juge mon code, il n'est pas pertinent qu'un développeur juge l'agencement et la technique employé pour produire un logo ou les règles d'ergonomie. Par contre qu'un designer me dise tel ou tel fonctionnalité serait bien, celle ci n'est pas bonne, elle pourrait se faire comme ça, ce n'est pas le résultat que j'attend quand je lis ça. Là, le designer n'est qu'un simple utilisateur qui fait des remarques sur le boulot du développeur. De la même façon, quand un développeur trouve le logo moche, la proposition d'ergonomie pas terrible, la communication pas adapté. Il ne juge pas le boulot du designer sur sa qualité, il le juge d'un point de vue utilisateur. Trouvé un logo moche ne veut pas dire que techniquement il est mauvais! Trouvé que la fonctionnalité ne répond pas à un besoin ne veut pas dire que techniquement le développeur à fait un mauvais boulot!

Qui es-tu pour juger?

Au delà de l'argument d'autorité présenté dans l'article (ce que j'ai tendance à détester...):

"J'ai 11 ans d'expérience dans le domaine, donc je sais mieux que toi ce qui est bon pour ton soft ou non"

la question est qui es-tu pour affirmer ça? Parce que tu es designer, tu sais tout mieux que tout le monde sur comment devrait être ce logiciel? Je dois me fier à ton CV? Aller me renseigner auprès de tes précédents employeurs pour avoir des références fiables? Tu es en train de me proposer de réécrire toute l'ergonomie de mon logiciel, mais en es-tu seulement utilisateur pour savoir si ce que tu proposes est une bonne chose ou une mauvaise chose pour mon logiciel? As-tu demandé aux utilisateurs ce qui clochait dans mon logiciel et au non utilisateur pourquoi il n'adoptait pas massivement mon logiciel? En utilisant cet argument, tu te place en dieu du design auquel il faut qu'on obéisse aveuglément parce que toi seul est la voix de la raison. Je crois qu'ici tu oublie clairement que non. Ceux que l'on doit écouter c'est les utilisateurs et à partir d'eux on essaye de faire au mieux. A aucun moment tu n'es au dessus d'eux. De la même façon que ton client est toujours roi. Que tes idées soit les meilleurs au monde ou non, l'utilisateurs doit rester roi. Ton expérience peut être enrichissante mais a aucun moment elle te place au dessus des autres. Tu veux être juger par tes pairs, soit juger sur l'aspect technique de ton boulot par eux, pour le résultat et l'application c'est l'utilisateur le roi.

Point éducation

Dernier point qui m'embête profondément mais qui n'est pas lié à l'article mais à un commentaires, et ça me fait bondir de lire ça. Ce commentaire montre une complète ignorance de tout le poids marketing et l'enfermement qu'offre certaines solutions propriétaires.

"Un logiciel qui est bien designé, c'est à dire bien pensé, clair et intuitif, t'as pas besoin de consulter trois tonnes de doc ou de te forcer à changer plein d'habitudes.".

Apprentissage

Alors première chose, l'apprentissage. Tout logiciel quel qu'il soit demande de l'apprentissage. Vous ne savez utiliser la calculatrice de votre téléphone que parce que vous avez appris ce qu'était les opérateurs et les différents chiffres. Puis vous avez appris aussi à écrire un calcul comme ça: (3x5)+(2x7) mais ce n'est pas la seul notation même si elle vous paraît logique du fait d'années d'apprentissages, cette notation nécessite des parenthèses. Ce même calcul s'écrit aussi + x 3 5 x 2 7 en Notation Polonaise. Je peux bien sûr mettre des parenthèses pour aider +(x 3 5)(x 2 7). Rien ne dit qu'un jour on n'utilisera pas cette notation tous les jours. Savoir que tel ou tel entré de menu fait tel ou tel choses, que ce logiciel a tel ou tel possibilité,... C'est bien en passant du temps à l'utiliser et plus le logiciel à de fonctionnalités plus long sera l'apprentissage. Bonne ergonomie ou pas. Rien n'est inné, tous s'apprends et tout cela demande du temps.

Et un logiciel complexe, peut necessité une documentation. Si tu es un génie, tu ne devra peut être pas la consulté souvent mais tu aura peut être besoin de le faire malgré tous les efforts d'ergonomies et d'intuivités que tu fera. Parce que si on était capable de faire des logiciels compréhensibles par tous facilement sans avoir besoin de la moindre documentation, on le ferait, rien n'est plus pénible comme exercice mental qu'à écrire une documentation. La documentation est aussi l'écriture de ce que tu es censé obtenir de tel ou tel fonctionnalités, si elle ne fais pas ce qu'il faut il y a un bug soit dans la doc soit dans le logiciel.

Habitudes

Seconde chose, les habitudes, vous avez passé des années à utiliser un logiciel, vous le maitrisez. De fait vos habitudes sont bien encrées, passer sous un autre logiciel qui a une façon de présenter les choses différentes, qui fait peut être mieux le boulot, vous semble difficile. Mais a moins d'être un standard, j'ai le droit de faire les choses différements, s'ils existent plusieurs logiciels open-sources qui font globalement la même chose, c'est bien parce que quelqu'un a pensé que la façon de faire était pas la bonne ou ne correspondait pas tout à fait à son besoin. Sinon ne faisons qu'un seul et unique logiciel pour chaque besoin, ce sera le logiciel universel. Mais c'est impossible. Si vos habitudes sont bien encrées et que vous ne voulez pas en changer demander pas aux autres de se plier aux votres! C'est pas forcément évident mais si réfléchissez si vous voulez vraiment changer de logiciel ou si celui que vous avez vous convient auquel cas laisser les autres logiciels tranquilles.

Les logiciels propriétaires ont cette vocation, vous enfermé dans leurs usages et faire en sorte que passer sur une alternative soit extrêmement pénible au point de vous découragez. Ça passe par des utilisations de formats fermé en passant par un marketing aggréssif et du lobbying auprès des écoles...

Pour conclure

Le même auteur disait quelques commentaires plus haut:

"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."

Si on conjugue ces deux commentaires. On veut bien une alternative libre pas cher qui évolue mais que de fonctionnalités utiles et ce sans changer nos habitudes prises sur le logiciel que je suis en train de critiquer. Si vous voulez changer de logiciel, il vous faudra sûrement réapprendre des choses, changer vos habitudes, si vous n'êtes pas prêt à cela ne dites pas que vous êtes prêt à changer de logiciel, ce n'est pas le cas.

Conclusion

Ami designer, vous pouvez contribuez mais ne vous prenez pas pour la solution qu'attende les développeurs pour leur logiciel. Contribuer par petite touche même si vous avez un plan plus global pour le projet. La confiance ça s'acquiert et on ne vous confie pas les clefs du projet sans avoir eu un avant goût de ce que vous proposez. Ne croyez pas que votre boulot plus que celui du développeur fonctionne selon un plan global d'ailleurs, le logiciel évolue tout les jours et pas forcéments dans les directions envisagées au départ. Si vous voulez contribuer à des projets commencer par des projets que vous utilisez vous même ou que vous aimeriez utiliser fautes de fonctionnalités, d'ergonomie adapté,... Venez contribuer au libre. Notez que proposer des guides sur l'ergonomie, le design,... ça peut aider déjà ceux qui ont pas le temps ni les moyens de gérer un designer. De même, vous avez conçu des logos que vos clients ont refusé, pourquoi ne pas les mettre en accès libre (dans un format adapté ;) )? Vous avez beaucoup à amener mais par contre faites le avec humilité. Vous êtes bon dans votre boulot, les développeurs sont bon dans le leur par contre vous restez des utilisateurs même si vous participez au même titre que le développeur est aussi un utilisateur.

Sous le capot

Ce blog est propulsé par blogc. C'est pas un moteur de blog mais un compilateur. Il crée seulement des pages statiques à partir de fichiers "sources".

Avantages

Il y a plusieurs avantages à ça:

  • Sécurité
    Pas de base de données, rien que des fichiers html et du css en sortie.
  • Versionnable
    Les sources sont versionnable, ça me permet d'avoir un backup dans un dépôt git.
  • Léger à déployer
    Que du html et du CSS, ça fait donc un blog assez léger. Bien loin de ce qui est nécessaire pour faire tourner wordpress.
  • Outils léger
    Contrairement à d'autres outils du genre, il n'y a pas besoin d'avoir des centaines de dépendances.
  • Makefile
    Tout passe par un Makefile pour compiler le blog. Et les fichiers sources sont de simples fichiers texte avec une syntaxe particulière mais pas très compliqué.

Inconvénients

  • Projet Récent
    Blogc est un projet assez récent(2015) qui évolue régulièrement. Actuellement, c'est la version 0.12. La pérénité est pas garanti mais pour le moment il convient assez à mes besoins donc on verra par la suite si j'ai plus de besoin que ça qui nécessiteront de voir d'autre solution dans le genre.
  • Exemple diffile à trouver
    L'exemple de base pour le blog est indiqué nul part sur leur site. Quand on le trouve pas, on est un peu en galère pour faire quelque chose de viable.
  • Pas de thème
    Il faut mettre les mains dans le cambouis si vous voulez autre chose que ce qui est fourni de base.
  • Sources
    Il faut les sources complètes du site pour mettre à jour convenablement le site. C'est pas forcément le plus pratique
  • Linux
    Le compilateur fonctionne sur Linux, pour les autres systèmes c'est pas garanti. En soi, moi ça ne me gène pas puisque j'utilise principalement Debian comme système d'exploitation

De quoi vais je parler?

Ce blog est personnel, il va pas spécialement parler de mon boulot mais ça ne m'empêchera pas de parler d'éléments qui tournent autour de mon boulot par contre. Les thèmes principaux seront les suivants:

Développement

C'est ce qui occupe une bonne partie de mon temps, puisqu'il s'agit de mon boulot. De fait, il y a des moments où je vais avoir envie de parler de choses intéressantes que j'ai trouvé, que j'ai écrite ou auquel je suis sensible. Je parlerai surement d'open source, de projets que je trouve sympa et que j'utilise, en expliquant pourquoi je les utilise, ce que je trouve bien sur ces projets et ce qui pourrait être mieux, de projets perso,...

Cinéma

Je vais souvent au cinéma, je suis assez bon publique de manière général mais ça me donnera l'occasion de m'exprimer régulièrement sur des films que je trouve sympa. Il faudra après voir ce que vous chercher comme film pour voir si c'est le genre de film qui peut vous convenir ou non.

Musique

Comme pour le cinéma, j'écoute énormément de musique quand je bosse notamment ou quand je suis dans les transports. La musique tourne en moyenne 12h par jour dans mes oreilles. Du coup, beaucoup de groupe, de morceau passe par mes oreilles. Après, on aime ou on aime pas. Je vous laisserai seul juge.

3D

J'aime faire des modélisation sous blender, même si je prend pas assez le temps pour ça. Mais je vais essayer de prendre plus de temps pour moi pour m'ammuser sur cet outils assez génial que je ne maitrise pas assez comparativement à d'autres.

Autres

Et tout les autres trucs qui me viendront en tête à un moment ou à un autre.