Bret Victor est un concepteur logiciel/développeur/visionnaire. Il a travaillé 4 ans chez Apple et a plus récemment travaille sur l'excellent livre interactif Our Choice sur iPad. Hier matin, la toile était en ébullition devant une vidéo d'une conférence de Bret Victor au CUSEC2012 : "Inventing on Principle". Au cours de cette conférence, il explique l'importance dans le monde informatique d'avoir des principes qui guident vos choix, vos décisions techniques et vos créations. Et il détaille son propre principe :

Si nous écrivons du code sur un ordinateur, pourquoi est-ce que nous simulons ce que l'ordinateur devrait faire dans notre tête ? Pourquoi l'ordinateur ne peux pas juste le faire et nous le montrer ?

Au cours des 35 premières minutes de sa conférence, Bret présente différents outils et interfaces qu'il a développé pour faciliter sa créativité, et obtenir un rendu immédiat de tout son code. Si vous faites du développement JavaScript, du développement Flash, de l'animation pour le web ou du web en général, vous devez impérativement regarder cette conférence.

Au cas où vous n'auriez pas le temps de regarder cette vidéo ou ne seriez pas encore totalement convaincu, voici quelques détails sur sa présentation.

En premier lieu, Bret présente un éditeur Canvas HTML5. La particularité de cet éditeur, fidèle à son principe de création, est d'afficher en temps réel la moindre modification. Il présente d'abord l'exemple d'une illustration d'un paysage en Canvas (de 2'30 à 9'30), puis d'un mini jeu de plates-formes inspiré de Braid (de 10'30 à 16'30). Si vous n'avez que quelques minutes, prenez le temps de regarder ce deuxième exemple.

Outre les petits détails bien pensés de son interface (comme la possibilité de moduler rapidement la valeur d'une variable, numérique ou d'une couleur par exemple), la nature même de JavaScript et son exécution à la volée est ici mise en avant de façon extraordinaire. Si vous faites du Flash, ça risque d'être difficile de revenir à la réalité et à votre routine habituelle : je code pendant 5 minutes, je compile pendant 1 minute, je teste 30 secondes, et je recommence.

Un des gros avantages de JavaScript et son exécution à la volée est également mis en avant à travers un 3ème exemple (de 17' à 23'): la création d'un algorithme de tri binaire. Si vous développez, vous connaissez la routine : vous réfléchissez à un algorithme, vous codez une première version, vous testez un premier cas, vous ajustez si nécessaire, vous testez un deuxième cas, vous réajustez si nécessaire, etc... Ici, une partie de l'interface retranscrit en direct les valeurs des différentes variables de votre code, tout en précisant vous même les valeurs de tests des paramètres passés à votre fonction.

S'en suit une présentation d'un 4ème exemple (de 23' à 28') démontrant cette fois-ci l'intérêt d'une interface en temps réel hors programmation informatique avec des circuits électroniques. Et enfin, le clou du spectacle (de 29' à 34'), la réalisation en 2 minutes d'une animation sur iPad, littéralement faite à la main, qui aurait pris une journée à faire sur l'IDE de Flash pour un néophyte.

Cette conférence véhicule pleins de valeurs que j'essaie de défendre à travers mes articles : l'importance d'un mantra, la pertinence de JavaScript comme étant un langage digne de ce nom, ou encore le fait que HTML5 pousse à la créativité au delà des limites de tout IDE. Comprenez, donc, mon emballement.

Vu la semaine dernière sur Twitter via Asa Dotzler, un article de Mark Shead intitulé "Pourquoi vous devez avoir des connaissances de votre domaine" :

Voici le pistolet à air comprimé Feinwerkbau P11 Piccolo. Il coûte aux alentours de 1500$, et on dirait qu'il a été conçu principalement pour des gens qui font de la compétition. Le canon noir est ce qui propulse la bille, et le canon argenté contient l'air comprimé.

Si vous avez un pistolet qui fonctionne à l'air comprimé, ce serait bien de savoir combien d'air il vous reste n'est-ce pas ? Je ne suis pas sûr que le design ait été bien réfléchi cependant.

Je ne connais pas l'histoire de ce pistolet, mais je sais que vous ne devriez pas avoir à pointer un canon vers votre visage pour lire une jauge.

Quand je vois quelque chose comme ça, j'aime bien m'arrêter et me demander si je fais des erreurs similaires dans mon domaine de développement logiciel. Des erreurs de pauvre conception ne sont pas limitées aux pistolets.

Ce qui me fascine avec ce genre d'exemple, c'est qu'il s'agit d'un produit récent réalisé par une grande société spécialisée dans la fabrication d'armes. La conception de ce produit a très certainement fait intervenir des dizaines de personnes avant de passer en production. A aucun moment, personne n'a eu la présence d'esprit de se dire que ce n'était peut être pas une très bonne idée.

Les États-Unis et l'Union Européenne viennent de donner leur approbation pour le rachat de Motorola Mobility par Google annoncé en août dernier, pour la modique somme de 12,5 milliards de dollars. MG Siegler avait publié il y a quelques semaines un très bon article résumant ce que Google achetait pour cette somme :

Motorola Mobility ont livré — livré, pas vendu — 5,3 millions de smartphones au cours du trimestre. Pour rappel, Apple en a vendu 37 millions.

Sur toute l'année, Motorola a livré — livré, pas vendu — 18,7 millions de smartphones. Pour rappel, Apple a vendu 37 millions de smartphones ce dernier trimestre.

Ils ont livré — livré, pas vendu — 200 000 tablettes ce dernier trimestre. DEUX CENT MILLE. Pour rappel, Apple a vendu 15 millions de tablettes.

Sur toute l'année, Motorola a livré — livré, pas vendu — 1 million de tablettes. Pour rappel, Apple a vendu 15 millions de tablettes ce dernier trimestre.

La société a perdu 80 millions de dollars au cours du trimestre — dont 70 millions étaient de la division mobile. L'unité a perdu 285 millions de dollars au cours de l'année.

Et tout ça pour DOUZE VIRGULE CINQ MILLIARDS DE DOLLARS. En août dernier, John Gruber rappelait ce que cette somme représentait pour Google :

Regardez les résultats financiers de Google. Ils ont rapporté 8,5 milliards de revenus nets cette année, et 6,5 milliards l'année dernière. C'est pour la totalité de Google. Ils offrent 12,5 milliards de dollars pour Motorola. Donc Google vient de dépenser quasiment deux années de ses bénéfices pour acheter un fabricant de téléphone de seconde classe qui est lui même peu rentable, a quasiment fait faillite, et est sans doute seulement le troisième meilleur fabricant d'appareils sous Android, derrière HTC et Samsung.

J'ai un tout petit peu de mal à croire que Google ait dépensé autant pour laisser Motorola "opérer comme une unité commerciale distincte".

Après le débat lancé par le W3C face aux préfixes des navigateurs, Raphaël Goetter d'Alsacréations a partagé sa solution pour facilement adapter ses sites en utilisant le script -prefix-free.

Comme beaucoup d’outils de ce genre, -prefix-free nécessite une requête HTTP et un traitement du JavaScript, au détriment des performances du navigateur.

En ce qui me concerne, je considère que les avantages fournis contrebalancent ce handicap. Mais sur mobiles, où les temps de chargement sont prépondérants, la question mérite le détour.

J'ai d'abord cru à une blague, mais il est apparemment très sérieux. Jérémie Patonnier a ce matin très bien détaillé la problématique, en titrant son article "Lier CSS à JavaScript : une mauvaise idée".

De manière générale, ce genre d'interrogations arrive rarement quand on applique un mantra, une philosophie globale, un fil conducteur qu'on applique dans n'importe quelle situation. Personnellement, ma philosophie se résume en une question.

Qu'est-ce qui est le mieux pour l'utilisateur ? 

Le graphiste a maquetté des listes déroulantes personnalisées. Je peux utiliser un script pour simuler une liste déroulante avec la charte maquettée, au détriment des performances de la page, ou laisser les listes déroulantes par défaut du navigateur, au détriment de la charte graphique. Qu'est-ce qui est le mieux pour l'utilisateur ?

Je dois intégrer une page simple avec quelques éléments à rendre dynamique (apparition au clic ou au survol). Je peux utiliser une librairie type jQuery pour coder ça rapidement, ou prendre un peu plus de temps pour coder la même chose en JavaScript seul. Qu'est-ce qui est le mieux pour l'utilisateur ?

J'ai du texte dans une police personnalisée. Je peux importer une police en CSS3 de plusieurs dizaines de Ko, ou découper une image de quelques Ko. Qu'est-ce qui est le mieux pour l'utilisateur ?

En octobre dernier, je partageais déjà mon point de vue sur la finalité d'une page web :

On ne fait pas un site web pour le client. On fait un site web pour un utilisateur. Un utilisateur est une vraie personne. Un utilisateur a son terminal (ordinateur, smartphone, télévision, ...), son entrée (clavier/souris, tactile, ...), sa sortie (écran 16/9, 4/3, 72 dpi, 326 ppi, ...), sa connexion internet (56k, ADSL, Fibre, Edge, 3G, ...). Un terminal à son système d'exploitation (Windows, Mac OS, iOS, Android, ...), son processeur, sa carte graphique, ... En pratique, vous aurez quasiment autant de configurations possibles que de visiteurs. Quand vous travaillez pour le client, vous rendez 1 personne heureuse. Quand vous travaillez pour l'utilisateur, vous rendez des milliers voire des millions de personnes heureuses.

D'autres intégrateurs auront surement un mantra différent, privilégiant par exemple la charte graphique, le temps de réalisation ou le coût d'un projet. On peut y trouver un intérêt sur le court terme. Mais je pense que seule une conception pensée pour l'utilisateur reste valable sur le long terme.

Daniel Glazman, co-président du groupe de travail CSS du W3C, a lancé aujourd'hui un appel à tous les acteurs du web pour éviter que les fabricants de navigateurs n'implémentent les préfixes -webkit- sur le long terme.

Je demande à toute la communauté des acteurs du web d'arrêter de concevoir des sites pour WebKit seulement, en particulier quand le support d'autres navigateurs n'est qu'une question d'ajouter quelques lignes de propriétés CSS avec des préfixes.

Je demande à toute la communauté des acteurs du web de supprimer immédiatement et d'arrêter d'implémenter la détection (sniffing) de navigateurs basés sur WebKit. Vous possédez un tel site ? Montrez votre soutien pour le Web Ouvert et supprimer cette détection immédiatement après avoir lu cet appel.

Je demande à la communauté des utilisateurs du web et des designers du web d'arrêter de recommander des sites qui nécessitent un navigateur en particulier alors qu'ils pourraient être ouverts à plusieurs navigateurs. Ne faites pas de lien vers ces sites, et mentionnez les uniquement pour faire savoir à la communauté qu'ils échouent dans leur service du Web Ouvert. Ne nourrissez pas les trolls, blacklistez les, peu importe à quel point le service qu'ils fournissent est cool.

Je suis totalement d'accord avec Daniel Glazman sur les deux premiers paragraphes. Je plaide coupable d'avoir moi même déjà utilisé des propriétés CSS avec uniquement leur préfixe WebKit (en particulier il y a 1 ou 2 ans, avant que Firefox ne revienne dans la course et commence à implémenter pleins de nouvelles propriétés).

Par contre, je suis convaincu qu'il se trompe de combat en cherchant à lancer une chasse aux sorcières. Mais puisqu'il insiste...

http://www.w3.org/2008/site/css/minimum
Ligne 134: .w3c_leftCol a:hover,.w3c_leftCol li a:focus{ -moz-transition-property:background-color;-webkit-transition-property:background-color;-o-transition-property:background-color;-moz-transition-duration:.3s;-webkit-transition-duration:.3s;-o-transition-duration:.3s;}
Ligne 181: .button{border:0;-moz-border-radius:3px;-moz-box-shadow:0 1px 3px rgba(0,0,0,0.5);-webkit-border-radius:3px;-webkit-box-shadow:0 1px 3px rgba(0,0,0,0.5);border-bottom:1px solid rgba(0,0,0,0.25);background-color:#555;color:#FFF;cursor:pointer;font-size:81%;font-weight:bold;left:5px;padding:2px 5px;position:relative;text-shadow:0 -1px 1px rgba(0,0,0,0.25);} http://www.w3.org/2008/site/css/advanced
Ligne 31: .secondary_nav{ -webkit-box-shadow:0 1px 2px #fff;-moz-box-shadow:0 1px 2px #fff;-webkit-border-radius:5px;-moz-border-radius:5px; }
Ligne 35: #search-form{ -webkit-border-radius:5px;-moz-border-radius:5px;}
Ligne 233: #request_form fieldset input:focus,#request_form fieldset textarea:focus{ -webkit-transition:border .2s linear,-webkit-box-shadow .2s linear;-moz-transition:border .2s linear,-moz-box-shadow .2s linear; }


Le site du W3C lui-même n'utilise pas systématiquement les noms de propriétés non-préfixées, et jamais les préfixes pour l'ensemble des navigateurs (pourquoi tant de haine envers -ms- ?). Je suppose que je devrais faire comme Daniel Glazman, et lui envoyer un e-mail.

C'est facile de dénoncer et de pénaliser. Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Avant de vouloir pointer du doigt et pénaliser les sites qui favorisent WebKit, il serait peut être bon d'éduquer les acteurs du web. Nous sommes en 2012 et le W3C ne propose aucune documentation simple et claire, compréhensible par le commun des mortels, indiquant le bon usage et le bon fonctionnement des propriétés CSS. C'est regrettable, mais pas étonnant qu'on se retrouve dans une telle situation.