Bret Victor fut un "inventeur d'interfaces humaines" chez Apple de 2007 à 2010, où il travailla notamment sur iOS. Lors de la Canadian University Software Engineering Conference, il fit une présentation d'une heure sur les derniers concepts qu'il a mis au point.
Ceux-ci sont particulièrement intéressants, notamment pour quiconque a déjà développé dans sa vie. Pour Bret Victor, le développement se fait "à l'aveuglette" : on tape du code, on compile, on voit le résultat, et on recommence, au lieu de voir directement les modifications mises en application.
Cela présente deux inconvénients : d'une part nombre de bugs pourraient être évités, et d'autre part le simple fait de pouvoir constater directement les effets des modifications dans le code est en soi-même un excellent moyen d'avoir de nouvelles idées.
Dans cette conférence d'une heure, Bret Victor a donc présenté un outil qui permet de voir directement les effets concrets que peuvent avoir des modification d'un code en JavaScript. Il est ainsi possible de modifier chaque valeur numérique à la souris pour en voir les conséquences dans une fenêtre séparée. Sur un petit jeu, il peut ainsi modifier les paramètres pour les ajuster au pixel près. Mieux encore, son système permet de rejouer la partie qu'il vient de faire à n'importe quel point dans le temps, et même une représentation temporelle montrant toutes les positions du personnage : là encore, les trajectoires affichées sont modifiées rien qu'en ajustant les valeurs numériques de son code, de manière limpide.
Bret Victor souligne une autre incongruité du métier de développeur : en écrivant le code, il faut "jouer à l'ordinateur", c'est à dire imaginer les résultats de ce que l'on écrit, avant de pouvoir les constater de visu. Ceux qui sont les plus doués à ce jeu de l'esprit font partie des meilleurs développeurs, mais pourquoi "jouer à l'ordinateur" quand l'ordinateur lui-même pourrait jouer son propre rôle? Il fait la démonstration d'une fonctionnalité qui permet d'appliquer des valeurs d'exemple à une fonction alors même qu'elle est en cours d'écriture (en l'espèce une recherche par dichotomie), ce qui lui permet de se rendre compte directement des cas de figure qu'il n'a pas géré dans sa fonction et ainsi d'éviter plus facilement des bugs.
Et ce principe peut être décliné à l'infini : il présente par la suite le cas d'un schéma électronique… fonctionnel, c'est à dire simulé par l'ordinateur. Là encore, il fallait imaginer le résultat avant de pouvoir le vérifier dans les faits. Là aussi, il peut modifier les valeurs à la souris et constater directement leurs conséquences, ou surveiller le voltage entre chaque composant et les comparer d'un simple survol de la souris.
Il compare l'approche actuelle de la programmation à sa propre genèse : les cartes perforées. Celles-ci ne prenaient pas en compte le concept d'interactivité, et pour cause, puisqu'il fallait poinçonner ces cartes pour pouvoir entrer la moindre instruction dans un ordinateur, sans même avoir un retour vidéo. Il est donc plus que temps de reléguer cette approche au passé auquel elle appartient.
Enfin, il présente un outil d'animation sur iPad qui offre une approche beaucoup plus intuitive que les outils de Flash, puisqu'il permet de réaliser les animations "aux doigts", en temps réel. Là encore il suit sa philosophie de l'approche directe et du retour en temps réel sur une création dont les résultats sont d'ordinaire présentés en différés.
De ce principe simple, l'utilisation même de nombreux outils pourrait en être bouleversée, offrant une approche directe et intuitive, un énorme gain de temps, et la naissance de nouvelles idées alors même que l'on "joue" divers scénarios sur ces outils.
En s'appuyant sur l'illustre exemple de Larry Tesler, un ingénieur du Palo Alto Research Center de Xerox qui mit un terme aux différents modes de manipulation de texte, inventant au passage le couper-copier-coller (il travailla plus tard sur le Newton chez Apple), Bret Victor va plus loin encore en bâtissant une réflexion au niveau social : le grand mérite de Larry Tesler a été d'identifier et de résoudre un problème qu'il était le seul à voir. Pour tout le monde, les modes faisaient partie de l'informatique et nul n'imaginait qu'il puisse en être autrement, de la même manière qu'Elizabeth Cady Stanton a réalisé que les femmes devraient avoir le droit de vote. Faisant appel à d'autres illustres prédécesseurs tels que Doug Engelbart (lire Une vieille histoire de rongeur), Alan Kay, ou Richard Stallman, Bret Victor invite son auditoire à suivre leur exemple pour identifier des problèmes que nul n'avait encore appréhendé pour y apporter des réponses innovantes.
Une approche qu'on retrouve tout au long de l'histoire d'Apple : résoudre des problèmes qu'on ignorait avoir. Vous pouvez voir les autres travaux de Bret Victor sur son site. Son passage chez Apple ne semble malgré tout pas lui avoir fait forte impression : sur la page qu'il dédie à cette période de sa vie, il indique qu'il y a créé de nombreuses choses, mais celles auxquelles il tenait le plus n'ont jamais dépassé le stade de la démo. De manière facétieuse, il indique qu'il publie dans un cadre toutes les choses qu'il a le droit de partager en espérant que cela en inspirera d'autres, mais le cadre en question est désespérément vide, et suivi d'une FAQ :
Q - Mais ce cadre est vide !
A - Oui, exactement
Q - Ah, d'accord, je croyais que c'était une erreur
A - Oui, exactement.
Ceux-ci sont particulièrement intéressants, notamment pour quiconque a déjà développé dans sa vie. Pour Bret Victor, le développement se fait "à l'aveuglette" : on tape du code, on compile, on voit le résultat, et on recommence, au lieu de voir directement les modifications mises en application.
Cela présente deux inconvénients : d'une part nombre de bugs pourraient être évités, et d'autre part le simple fait de pouvoir constater directement les effets des modifications dans le code est en soi-même un excellent moyen d'avoir de nouvelles idées.
Dans cette conférence d'une heure, Bret Victor a donc présenté un outil qui permet de voir directement les effets concrets que peuvent avoir des modification d'un code en JavaScript. Il est ainsi possible de modifier chaque valeur numérique à la souris pour en voir les conséquences dans une fenêtre séparée. Sur un petit jeu, il peut ainsi modifier les paramètres pour les ajuster au pixel près. Mieux encore, son système permet de rejouer la partie qu'il vient de faire à n'importe quel point dans le temps, et même une représentation temporelle montrant toutes les positions du personnage : là encore, les trajectoires affichées sont modifiées rien qu'en ajustant les valeurs numériques de son code, de manière limpide.
Bret Victor souligne une autre incongruité du métier de développeur : en écrivant le code, il faut "jouer à l'ordinateur", c'est à dire imaginer les résultats de ce que l'on écrit, avant de pouvoir les constater de visu. Ceux qui sont les plus doués à ce jeu de l'esprit font partie des meilleurs développeurs, mais pourquoi "jouer à l'ordinateur" quand l'ordinateur lui-même pourrait jouer son propre rôle? Il fait la démonstration d'une fonctionnalité qui permet d'appliquer des valeurs d'exemple à une fonction alors même qu'elle est en cours d'écriture (en l'espèce une recherche par dichotomie), ce qui lui permet de se rendre compte directement des cas de figure qu'il n'a pas géré dans sa fonction et ainsi d'éviter plus facilement des bugs.
Et ce principe peut être décliné à l'infini : il présente par la suite le cas d'un schéma électronique… fonctionnel, c'est à dire simulé par l'ordinateur. Là encore, il fallait imaginer le résultat avant de pouvoir le vérifier dans les faits. Là aussi, il peut modifier les valeurs à la souris et constater directement leurs conséquences, ou surveiller le voltage entre chaque composant et les comparer d'un simple survol de la souris.
Il compare l'approche actuelle de la programmation à sa propre genèse : les cartes perforées. Celles-ci ne prenaient pas en compte le concept d'interactivité, et pour cause, puisqu'il fallait poinçonner ces cartes pour pouvoir entrer la moindre instruction dans un ordinateur, sans même avoir un retour vidéo. Il est donc plus que temps de reléguer cette approche au passé auquel elle appartient.
Enfin, il présente un outil d'animation sur iPad qui offre une approche beaucoup plus intuitive que les outils de Flash, puisqu'il permet de réaliser les animations "aux doigts", en temps réel. Là encore il suit sa philosophie de l'approche directe et du retour en temps réel sur une création dont les résultats sont d'ordinaire présentés en différés.
De ce principe simple, l'utilisation même de nombreux outils pourrait en être bouleversée, offrant une approche directe et intuitive, un énorme gain de temps, et la naissance de nouvelles idées alors même que l'on "joue" divers scénarios sur ces outils.
En s'appuyant sur l'illustre exemple de Larry Tesler, un ingénieur du Palo Alto Research Center de Xerox qui mit un terme aux différents modes de manipulation de texte, inventant au passage le couper-copier-coller (il travailla plus tard sur le Newton chez Apple), Bret Victor va plus loin encore en bâtissant une réflexion au niveau social : le grand mérite de Larry Tesler a été d'identifier et de résoudre un problème qu'il était le seul à voir. Pour tout le monde, les modes faisaient partie de l'informatique et nul n'imaginait qu'il puisse en être autrement, de la même manière qu'Elizabeth Cady Stanton a réalisé que les femmes devraient avoir le droit de vote. Faisant appel à d'autres illustres prédécesseurs tels que Doug Engelbart (lire Une vieille histoire de rongeur), Alan Kay, ou Richard Stallman, Bret Victor invite son auditoire à suivre leur exemple pour identifier des problèmes que nul n'avait encore appréhendé pour y apporter des réponses innovantes.
Une approche qu'on retrouve tout au long de l'histoire d'Apple : résoudre des problèmes qu'on ignorait avoir. Vous pouvez voir les autres travaux de Bret Victor sur son site. Son passage chez Apple ne semble malgré tout pas lui avoir fait forte impression : sur la page qu'il dédie à cette période de sa vie, il indique qu'il y a créé de nombreuses choses, mais celles auxquelles il tenait le plus n'ont jamais dépassé le stade de la démo. De manière facétieuse, il indique qu'il publie dans un cadre toutes les choses qu'il a le droit de partager en espérant que cela en inspirera d'autres, mais le cadre en question est désespérément vide, et suivi d'une FAQ :
Q - Mais ce cadre est vide !
A - Oui, exactement
Q - Ah, d'accord, je croyais que c'était une erreur
A - Oui, exactement.