Pour les 10 ans de D3, son créateur Mike Bostock partage 10 enseignements

Plusieurs centaines de personnes attendaient, ce mercredi 17 février, l’intervention de Mike Bostock en direct. Il y a 10 ans, début 2011, Mike a mis en ligne la 1re version de D3, cette librairie graphique qui a révolutionné notre façon de construire des datavisualisations. 

« Reject the tyranny of charts » (rejeter la tyrannie des graphiques prédéfinis), c’est l’un des slogans fondateurs de D3 : créer, dans le navigateur web, avec JavaScript, CSS et SVG, de nouvelles formes visuelles pour faire intelligemment parler les données.

La plupart des graphiques que nous contemplons dans nos journaux en ligne sont programmés en D3 ou via une surcouche de D3. Pour autant, son auteur reste étonnamment discret et pudique. La dizaine d’enseignements qu’il a partagés en visio lors de la célébration de ce dixième anniversaire n’en sont que plus précieux. 

Outre l’intelligence du propos, le sourire et la sincérité de ce créateur hors du commun m’ont impressionné, et avec le recul touché au delà de ce j’aurais cru, j’y reviendrai en fin d’article.

J’en propose une transcription (résumée) à partir de cette vidéo (40e minute et suivantes). Je tiens à préciser que je suis seul responsable de cette traduction/formulation. Voici donc, point par point, l’intervention de Mike Bostock.

EDIT : le texte intégral en anglais est désormais publié et accessible ici.

Quelques enseignements – sans hiérarchie particulière – de ce que j’ai appris au cours de ces 10 ans. Je ne prétends pas à l’exhaustivité, si je reprenais l’exercice de zéro à nouveau demain, il est fort possible qu’émergerait une autre liste de leçons !

Je ne crois pas l’avoir déjà partagé, avant de retenir D3 comme dénomination, j’avais imaginé Epheme (NDT : ou FM ?), comme “ephemeral”, en référence au mécanisme de sélection au cœur de D3, léger et volatile. Une sélection manipule des objets et, après avoir rempli son office, s’efface et laisse le navigateur faire ce qu’il sait bien faire.

Je trouve plutôt drôle que 10 ans après, ce parfum d’”éphémère” soit toujours bien présent, central même dans ma vie quotidienne, et en évolution constante, profitant à un nombre croissant de personnes.

L’impressionnante puissance de la documentation
et des exemples

J’avais dès le début conscience de l’importance de cela, mais constater à quel point cela a été moteur dans le développement de D3 a renforcé chez moi cette croyance initiale. Quand vous construisez un outil, vous vous retrouvez complètement pris dedans, vous réfléchissez aux nouvelles fonctions à développer… Tout vous est familier, vous vous sentez évidemment à l’aise avec son maniement, et vous pouvez perdre de vue que, pour les autres, cela reste un objet étrange ou déconcertant.

Si vous voulez créer un outil que les autres pourront utiliser, il faut vraiment vous préoccuper de la doc et de l’enseignement, cela doit être au cœur de votre stratégie. Le plaisir seul du créateur à créer ne suffit pas, même si c’est un critère important ! La valeur d’un outil réside et ne réside que dans ce que les gens en comprennent et en retiennent.

Mais je veux dire aussi que la doc et les exemples sont parfois trop puissants dans leurs effets. Ils peuvent masquer certains défauts de conception de l’outil. Et aussi, poussant les gens à trop s’appuyer sur les exemples, les conduire à négliger l’apprentissage des concepts fondamentaux.

Je ne porte pas de jugement, chacun fait ce qui lui parait le mieux pour être productif. Construire à partir d’un exemple qui vous parle peut être une bonne stratégie. Mais savoir aussi partir d’une feuille blanche, sans être sur-dépendant des exemples, vous ouvrira de grands espaces de liberté et de création. Les deux démarches peuvent aller de pair.

Les animations et effets d’interaction
sont d’un intérêt surestimé

Venant de moi cette affirmation peut vous surprendre, et je fais moi-même cette erreur trop souvent !

Toutes ces possibilités nouvelles de création d’effets avec D3 sont évidemment excitantes. Mais le risque est de distraire vos lecteurs et vous-mêmes de ce qui est ou devrait être le véritable objectif de la dataviz que vous construisez : découvrir quelque chose de nouveau à partir des données, ou transmettre aux autres un enseignement, une vision : « The purpose of visualization is insight » (NDT : citation fameuse de Ben Schneiderman).

Posez-vous la question : le temps que je consacre à programmer cette animation ou cet effet, est-ce que cela en vaut vraiment la peine, est-ce que cela va m’aider à faire passer le message ?

Je suis conscient que les exemples en ligne peuvent pousser à en faire trop. Ces exemples ne sont pas toujours représentatifs des exigences du monde réel. Ils sont d’abord là pour illustrer un concept, une technique, parfois de façon spectaculaire.

Mais au-delà de l’excitation que vous ressentez, et que je ressens et partage comme développeur, ne perdez pas de vue vos lecteurs et utilisateurs. Si ce sujet de « quand l’interaction et l’animation sont utiles en dataviz » vous intéresse, je vous invite à lire cet article de Gregor Aisch.

En tout cas je vous recommande de toujours commencer par un design statique, cela vous obligera à bien poser vos objectifs de communication, à définir ce qui est le plus important à transmettre, et c’est évidemment essentiel si votre démarche est pédagogique est explicative. En revanche si vous êtes dans une démarche exploratoire, les process de requêtage interactifs sont utiles.

La préparation des données prend du temps
et c’est une étape fondamentale

Si vous ne passez pas tout votre temps à programmer des animations, en réalité, qu’est-ce qui vous occupe le plus ? Je pense que, aussi décevant que cela puisse paraitre, c’est la préparation/manipulation des données : trouver les données, les nettoyer, les transformer, les modéliser, apparier différents jeux…

Souvent, la réponse à un objectif de datavisualisation réside dans la structure même des données. L’essentiel du travail consiste à mettre des données dans la bonne structure, la visualisation n’est que la traduction ultime de cette démarche.

Les éléments de D3 que j’utilise probablement le plus sont d3.array, d3.group et d3.rollup, tous dédiés à la manipulation de données, et ces modules ou fonctions ont sensiblement évolué dans la dernière version de D3. Mais je suis aussi emballé par des travaux complémentaires comme Arquero (de Jeffrey Heer, UW Interactive Data Lab), qui est aussi compatible avec Apache Arrow, ou le projet tidyjs. Le paradigme “tidy data” d’Hadley Wickham (NDT : directeur technique chez RStudio) est d’une valeur inestimable.

Ne vous fixez pas sur une idée de dataviz avant d'avoir vérifié qu'elle était compatible avec vos données

Votre dataviz ne devient réelle que lorsque vous avez injecté vos données dedans. Et encore une fois, il y a ce risque d’être d’abord fasciné par un bel exemple de dataviz avant d’avoir vérifié si cet exemple était approprié pour vos données, s’il exprimait bien la tendance ou la structure que vous voulez transmettre.

C’est l’une des choses qu’avec Observable nous avons cherché à rendre plus facile, vous aider à injecter vos propres données dans des exemples.

Visualisations explicatives vs visualisations exploratoires

Entre les deux extrémités de ce spectre, il y a en réalité un continuum, il importe que vous sachiez vous situer : selon que vous travaillez pour vous-même, que vous construisez un tableau de bord pour vos collègues en leur permettant d’agir sur quelques manettes, ou que vous ayez un message très précis à délivrer à un large public.

Ce que j’ai appris au New York Times, c’est à quel point annotations et légendes sont importantes. Si vous ne savez pas encore quel commentaire, quel titre même donner à votre dataviz, c’est qu’à l’évidence elle n’est pas prête pour la publication, c’est que vous n’êtes pas allé au bout de l’analyse, ce qui vous permet de mettre vos propres mots, d’expliquer vos propres découvertes.

10 % du code est à l’origine de 90 % des bugs

Vous pourriez penser que si une section de code est buggée, c’est juste parce que son développeur est moins bon qu’un autre. Mais ce n’est pas comme cela que cela se présente.

Certains modules sont par nature plus exposés au risque de bugs, et par conséquent demandent plus de support et de maintenance. Dans D3, il est apparu que cela concernait justement la gestion des interactions : d3.zoom, d3.drag, d3.brush.

On est là dans un monde d’évènements asynchrones, qui se présentent dans des séquences plus ou moins arbitraires, l’espace des possibles est presque infini. Des choses inattendues peuvent se produire, et les navigateurs eux-mêmes, qui offrent les soubassements pour ces modules D3, rencontrent de réelles difficultés. Parfois, selon les types d’appareils, les « mouse events » et les « touch events » sont gérés ensemble, parfois de façon différente.

Cela rejoint ce que j’ai évoqué précédemment, le défi mais aussi le fardeau que représente la gestion des interactions.

Le support : indispensable mais gare à la submersion

Quand vous consacrez du temps à répondre en ligne aux questions que les gens peuvent se poser, ce n’est pas simplement par altruisme. Vous comprenez, en tant que concepteur, avec quoi précisément les utilisateurs se bagarrent, à quelles difficultés ils font face, comment ils modélisent les problèmes.

Vous intéresser à vos utilisateurs vous aidera à concevoir de meilleurs outils. Cela parait évident, mais ce n’est pas une attitude si universellement répandue !

La contrepartie de cet engagement dans le support, c’est qu’il vous faut comprendre et accepter que vous ne pouvez pas résoudre les problèmes de tout un chacun ! Il y a, à un moment, une limite humaine, physiologique (it doesn’t scale). Évidemment vous avez envie que chacun soit heureux, satisfait, se sente à l’aise avec l’outil, arrive à faire ce qu’il veut.

L’idée est, en évitant d’être submergé, de rester suffisamment impliqué et en mesure de détecter des motifs récurrents, pour les traiter en priorité. Cela peut déboucher sur un nouveau tutoriel, un design à modifier/affiner.

Si vous partagez votre travail sur Internet, Internet vous fera vous sentir mal

C’est vrai pour moi, et je pense pour beaucoup d’autres. Internet est terrible et éprouvant. Je regarde ce qui se dit sur D3 sur Twitter. Je fais même une collection – que je ne partage avec personne – des tweets “désagréables”. Il y a beaucoup de frustration qui s’exprime, et je ne juge personne, je sais que l’outil a ses faiblesses, sa documentation aussi.

Mais c’est aussi coûteux, émotionnellement, pour moi, d’absorber la frustration de tant de gens. C’est le problème des réseaux sociaux : si vous êtes frustrés, vous allez l’exprimer. Le problème est que si vous prenez du bon temps avec l’outil, vous n’allez pas en faire état, cela ne va pas faire un “bon tweet”. Les réseaux ne sont donc pas représentatifs de l’expérience réelle des usagers.

En tant qu’être humain, les feedbacks négatifs finissent par avoir un impact démesuré : je me souviens davantage des tweets critiques que des tweets positifs, et j’aimerais me souvenir davantage des tweets chaleureux ! Mais c’est comme ça, même si vous avez le cuir très épais, c’est difficile.

Ma demande est celle-ci : si vous éprouvez de la frustration, réfléchissez juste au moment de formuler les choses à l’impact que vos mots pourront avoir, car personne n’est à l’abri du burn-out et de la démotivation.

Comprenez-moi bien, si vous avez besoin d’aide, n’hésitez absolument pas à poser des questions, mais autant que possible de façon positive et contributive. Dans le monde de l’open-source, même si on en parle peu, le risque du burn-out est réel. 

Pourquoi je m’implique dans l’open-source, qu’est-ce que j’en retire au fond qui me fait continuer, soutenir et développer D3 ? J’ai vraiment envie d’aider les gens, de les aider à être productifs, à mieux comprendre leurs données et à avoir un impact positif sur le monde. J’ai aussi besoin que vous m’aidiez.

Entretenir une communauté stable et proche de vous

Pour mieux travailler, il est important de constituer une équipe, une communauté avec qui construire, avec qui partager feedback et créativité.

C’est vraiment ce que nous essayons de faire avec Observable, organiser une communauté de praticiens, qui peuvent apprendre les uns des autres, partager idées et techniques.

Cette communauté sert aussi de sas protecteur, plus proche de vous, et aussi capable ensuite de dissémination vers le large espace de l’internet.

Take it easy !

Cela peut paraitre bizarre venant de moi car je suis certainement la dernière personne au monde à savoir ‘take it easy’, et j’aimerais vraiment y arriver. Ah, je me sens en vous parlant comme un “coach spirituel”, et vous n’avez sans doute pas besoin de ça !

Réfléchissez-juste à ceci : quelle partie de votre job vous plait vraiment ? Si vous arrivez à lui donner plus de temps, alors probablement vous aurez plus de succès dans ce que vous entreprenez. C’est très bien de se fixer des objectifs ambitieux, mais vous devez vous assurer que vous allez apprécier le voyage, au jour le jour.

Il est facile de se laisser obséder par des objectifs ambitieux, et de ne même plus s’apercevoir que, jour après jour, le plaisir n’est plus là. Vous allez parfois buter, eu égard à ces buts élevés que vous vous êtes fixés, mais si vous prenez du plaisir chaque jour, vous emmagasinez autant de ressources pour passer des caps difficiles.

De mon côté, j’aime vraiment développer des outils que les gens apprécient utiliser, mais j’aime aussi développer des outils pour mon propre plaisir, construire des abstractions, résoudre des puzzles… Si vous êtes parfois déçus que je ne sois pas plus visible, à faire des conférences, des annonces, dites-vous que c’est probablement que je m’occupe à créer des choses nouvelles et amusantes.

Merci d’avoir écouté ce “random talk” !

Mike Bostock est le papa de la librairie de visualisation de données D3.js, qui permet de produire des “dynamic, interactive, online data visualizations” (c’est plus court et tellement plus simple à dire en anglais ;).

Il fait également partie des créateurs d’Observablehq. Observable un environnement de développement collaboratif tout en un dans le navigateur créé en 2017. Il prend, à juste titre, une place croissante dans le monde du partage de dataviz sur le web. 

Quand il est question de D3 ou d’Observable, l’adjectif qui va souvent avec est “révolutionnaire“.

Mike est un de ces visionnaires marquant leur époque, avec une véritable passion, un engagement profond dans les travaux qu’ils conduisent. Il a une longue expérience dans le domaine de la visualisation des données, après des années passées à concevoir des “dataviz” pour le New York Times.

Sa dernière “leçon” résonne tout particulièrement chez moi. Je n’avais pas du tout prévu de faire cette traduction, je suis à la bourre sur d’autres impératifs. Mais j’ai eu soudain envie de le faire, et pris grand plaisir à le faire car j’ai saisi, à la seconde audition, des choses plus subtiles qu’à la première. 

Préparer les données, c’est une étape qui prend du temps, indispensable, mais je la trouve aussi très agréable intellectuellement. Et quel plaisir de voir en effet la dataviz se programmer si facilement, avec un jeu de données bien organisé ! 

On ne peut faire de la bonne datavisualisation si l’on n’est pas aussi prêt à mettre les mains dans les données (merci R, Arquero, etc.) Mais à l’inverse, je reconnais des statisticiens accomplis à ce qu’ils sont amoureux des belles visualisations et soucieux du moindre détail de rendu et de lisibilité (merci D3, Vega, et bien d’autres outils !)

Comme créateur d’un logiciel (Géoclip), j’ai fait beaucoup de support et toujours considéré cette activité comme fondamentale et, la plupart du temps, gratifiante, celle qui donne le plus du sens à votre démarche. Comme Mike, j’ai frôlé le burn-out parfois et ma propre leçon est que vous devez vous entourer de gens qui apprécient autant que vous de “faire du support”, qui savent écouter. 

Si certains de vos collègues n’aiment pas le support, cela devient vite pesant, invitez-les à trouver leur vraie voie d’expression. A contrario, pouvoir discuter d’interactions difficiles (car le support n’est pas toujours facile) avec des personnes proches qui partagent les mêmes critères est chose précieuse, cela aide aussi à trouver des solutions au bénéfice de tous.

L’apprentissage de D3, indiscutablement, demande un investissement important. Les exemples peuvent être intimidants, et particulièrement ceux de Mike, même s’il a réalisé aussi d’excellents tutoriels ! Avec les formations que j’anime et que je construis, je milite pour une approche graduée et pratique : la réalisation d’un exemple du monde réel à chaque session. On pioche ainsi, par spirales successives, plusieurs ressources transversales, plutôt qu’absorber chaque concept l’un après l’autre, de façon extensive. Chaque leçon doit amener sa propre récompense, et surtout vous donner une méthode de travail.

Pour conclure et revenir à Mike Bostock, Isabelle m’a dit : “il est étonnant ton développeur de génie, il parle assez peu de technique, ne fait pas d’annonce pour les 10 ans qui viennent, en revanche il livre des choses assez intimes“. Je lui ai répondu : c’est justement en cela qu’il me parle le plus !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.