HTeuMeuLeu

La première mise à jour avec du contenu téléchargeable de Mario Kart 8 est sortie aujourd’hui. La meilleure partie de cette mise à jour pour moi est la suivante, annoncée en début de mois :

L’ordre du menu suivant chaque course sera modifié en « Course suivante, suivi par « Voir les temps forts ».

Non seulement ils ont corrigé ce problème, mais surtout ils choisissent de le mettre en avant comme l’une des « fonctionnalités conçues pour améliorer l’expérience de conduite des joueurs ».

Le bon design, c’est aussi apprendre et corriger ses erreurs.

L’attribut srcset est un nouvel attribut pour les balises images décrit dans la spécification de HTML 5.1. Il permet de résoudre en partie l’une des plus grosses problématiques de l’intégration de sites responsive : les images.

Venant en complément de l’attribut src habituel d’une balise <img>, l’attribut srcset permet de spécifier une liste d’images à afficher selon des critères particuliers. L’immense avantage, c’est que c’est le navigateur qui décide quelle image afficher, et que seule cette image sera téléchargée.

Son implémentation a déjà commencé depuis février dernier dans la version 34 de Chrome, mais limitée à la sélection d’image selon la densité de pixels de l’écran d’un appareil. Ainsi dans le code suivant, je peux préciser le chemin d’une image optimisée pour des appareils avec une densité de pixels à l’écran d’au moins 2 (aussi vulgairement appelés « écrans rétina »).

<img src="default.jpg" srcset="hidpi.jpg 2x" />

C’est déjà un bon début. Mais ce qui est vraiment bien, c’est que les navigateurs commencent maintenant à implémenter la suite, à savoir la sélection d’images selon le viewport. C’est en cours d’implémentation dans Chrome, Opera, et dans Firefox derrière un flag. Et surtout, ce sera activé par défaut dans Safari 8 sur iOS 8 et OS X Yosemite. Cela signifie que d’ici la fin de l’année, la majorité des navigateurs supporteront srcset. (Pour Internet Explorer, c’est pour l’instant « en considération ».)(On me fait signe que la version beta actuelle de Safari 8 ne supporte que la première partie de la spécification, et pas la sélection d’images selon le viewport).

Il y a donc de quoi être tout excité par cette nouveauté. J’ai fait mumuse avec srcset ces derniers jours, et voici que j’ai appris et compris.

Tout d’abord, pour tester tout ça, il va falloir installer ou configurer les navigateurs compatibles. Pour avoir Safari 8 sur iOS, vous pouvez télécharger la beta de Xcode 6 dans laquelle vous aurez la dernière version du Simulateur iOS. Pour avoir Safari 8 sur OS X, vous pouvez télécharger la bêta publique de OS X Yosemite.
Pour Chrome, vous pouvez télécharger Chrome Canary (actuellement en version 38).
Pour Firefox, vous pouvez télécharger Firefox Nightly (actuellement en version 34). Puis il faudra activer le support de srcset à la main. Pour ça, il faut aller à l’adresse about:config, chercher les préférences dom.image.srcset.enabled et dom.image.picture.enabled, et les passer toutes les deux à la valeur true.

Nous sommes prêts pour tester. Pour commencer, nous allons préciser dans srcset une liste de quatre images : small.png (320×240), medium.png (640×480), large.png (1024×768) et xl.png (1920×1080). Si le navigateur ne supporte pas srcset, c’est l’attribut src qui prendra le relais avec l’image default.png (1024×768). Voici le résultat de ce premier exemple avec le code suivant :

<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" alt="Test" />

Comme vous pouvez le constater, chaque image est accompagnée d’un « descripteur w » (dixit la spécification, en opposition au « descripteur x » utilisé lui pour la sélection selon la densité de pixels d’écran). J’ai eu beaucoup de mal à comprendre la signification de ce descripteur, notamment à cause d’article comme celui publié chez Alsacréations (désolé Geoffrey) qui confondent descripteur w et largeur de viewport. À ce stade, il faut bien comprendre qu’il n’y a aucun lien entre les deux. Le descripteur w est une indication laissée au navigateur sur la largeur en pixels de l’image correspondante.

Là où la spécification de srcset est surprenante, c’est dans la façon de décrire comment un navigateur va choisir l’image à afficher :

L’agent utilisateur va calculer la densité de pixel réelle de chaque image à partir du descripteur w spécifié et des tailles de rendus spécifiées dans l’attribut sizes. Il peut ensuite choisir n’importe quelle ressource en fonction de la densité de pixels de l’écran de l’utilisateur, de son niveau de zoom, ou peut-être d’autres facteurs comme les conditions de réseau de l’utilisateur.

En gros : le navigateur fait ce qu’il veut. Cela signifie que Chrome pourrait décider de choisir l’image la plus petite si la connexion est un peu lente, alors que Safari pourrait au contraire décider de systématiquement choisir l’image la plus grande. Bienvenue dans un futur nouvel enfer du responsive !

À noter qu’actuellement, Firefox ne va charger une image qu’au chargement initial de la page, mais ne rafraîchira pas son affichage au redimensionnement de la fenêtre. La dernière version de Chrome Canary gère très bien ça au redimensionnement (et au passage, la nouvelle vue device mode des outils de développement de Chrome est vraiment bien foutue).

Les choses sérieuses vont commencer en introduisant l’attribut sizes. Celui-ci permet de spécifier la largeur d’affichage de l’image selon des points de rupture. Dans l’exemple ci-dessus, les images vont toujours par défaut prendre 100% de la largeur du viewport. La spécification explique clairement que la valeur par défaut de l’attribut sizes est de 100vw et que dans ce cas, l’attribut peut-être omis. Malheureusement les développeurs de chez Mozilla ont du s’arrêter de lire la spécification juste avant ce paragraphe car dans l’implémentation actuelle, il faut impérativement préciser l’attribut sizes, même pour une valeur de 100vw. (J’ai remonté le problème, et il a déjà été affecté, donc on peut espérer une correction en moins de douze ans.)

Là où sizes est bien pratique, c’est qu’il va permettre de spécifier différentes largeurs d’affichage pour notre image selon le reste du gabarit de notre page. Si par exemple je suis sur un viewport de 800px de large, mais que j’affiche mon image à seulement 400px de large, je peux le préciser dans l’attribut sizes et le navigateur tentera de charger l’image qu’il juge la plus appropriée. En reprenant le premier exemple et en y appliquant cette condition, ça donnerait ce deuxième exemple et le code suivant :

<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" sizes="(width:800px) 400px" alt="Test" />

Ici, l’image est toujours affichée à une largeur correspondant à 100% du viewport, sauf si celui-ci vaut exactement 800px, auquel cas l’image est fixée à une largeur de 400px. Cet exemple est totalement stupide dans la vraie vie.  On pourra alors plutôt écrire ce genre de code un peu verbeux pour ce troisième exemple :

<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" sizes="(min-width:20em) and (max-width:50em) 20em, (min-width:50em) and (max-width:80em) 40em, (min-width:40em) 10em" alt="Test" />

J’ai défini ici trois points de rupture précisant des tailles d’images respectivement de 20em, 40em et 10em. Si aucune des conditions des points de rupture n’est remplie, alors le navigateur appliquera à l’image sa valeur par défaut de 100vw.

Là où ça peut devenir un joyeux bazar, c’est qu’on peut combiner les descripteurs w et x. Et tout ça peut être combiné à la balise <picture> qui elle aussi commence à être supportée. Opera a récemment publié un article pour donner des cas pratiques d’utilisation d’images responsive. L’article d’Eric Portis sur « srcset et sizes » est magnifiquement illustré et très complet sur le sujet et m’a aidé à comprendre un tas de trucs.

J’avais lu cette information il y a déjà plus d’un mois, mais de nouvelles photos destinées à la presse sorties ce week-end en sont un malheureux rappel. L’écran de la Moto 360 n’est pas rond. Il y a une coupure droite en bas sur toute la longueur.

Depuis que je sais ça, je ne vois plus rien d’autre. D’après un responsable de Google répondant à The Verge, c’est une « inévitable étrangeté de conception ». Personne ne sait si Apple travaille sur un projet similaire, mais si c’est le cas, et si je devais répondre à ce tweet, je donnerais la réponse C.

J’ai toujours été fasciné par les statistiques globales de parts de marché ou d’utilisation des navigateurs, même si c’est toujours à prendre avec de grosses pincettes. En 2011, je suivais attentivement l’adoption d’IE9 et de Firefox 4. Je m’interrogeais même sur l’avenir que pourrait avoir le marché des navigateurs, en me disant que ce serait chouette d’arriver à un marché sain avec trois concurrents à parts égales.

Ce doux rêve ne dura pas longtemps. L’année dernière, je constatais le passage de la domination d’IE à la domination de Chrome. Ce constat m’a été rappelé cette semaine sur Reddit avec cette carte des navigateurs les plus utilisés par pays (d’après les données de StatCounter).

Ça en devient presque effrayant. Si on compare avec la même carte un an plus tôt, Chrome a réussi à devenir le principal dans de nombreux pays, ne laissant plus qu’à IE que le Japon et la Corée. Firefox s’est aussi bien fait devancer un peu partout dans le monde, et surtout en Afrique, par Opera. L’explosion du web mobile en Afrique que j’évoquais à la sortie de Firefox OS se fait sentir.

Si on regarde le chemin parcouru depuis juillet 2011 (d’après StatCounter), le constat n’en est que plus effrayant. 

En trois ans, en seulement trois petites années, on est passé d’une utilisation de Firefox de 28 % à seulement 17 %. En trois ans, on est passé d’une utilisation d’Internet Explorer de 42 % à 21 %. Et en trois ans, on est passé d’un Chrome à 22 % à 45 %.

Ce qui m’inquiète, c’est que sans bouleversement majeur du marché de l’informatique personnelle, la dégringolade d’IE et Firefox au profit de Chrome ne risque que de s’accentuer. En trois ans, on est passé d’un marché où Windows représentait 85 % des OS utilisés sur le web, à seulement 55 %, suivi par une forte croissance d’Android et d’iOS représentant à eux deux 28 % des OS utilisés sur le web. L’insignifiance de Firefox et Internet Explorer sur le marché mobile ne va certainement pas arranger ça.

En étant pessimiste, dans trois ans, Chrome sera peut-être utilisé par au moins 75 % des internautes. En étant optimiste, dans trois ans, Internet Explorer et Firefox seront peut-être encore là pour voir ça.

A Blind Legend est un jeu d’action-aventure audio jouable sur mobile.

Il s’appuie sur les sons binauraux permettant de se repérer dans un environnement en 3 dimensions uniquement par le biais de l’audio, et l’écran tactile du mobile pour contrôler le héros.

Ce jeu est créé par les lyonnais de DOWiNO, et il est en financement participatif sur Ulule depuis un peu plus d’un mois. Il ne reste plus que deux jours pour les aider à financer 22 % du montant total.

Je trouve que c’est vraiment un beau projet, et j’ai participé à son financement sans hésitation. Les développeurs ont sorti une démo du concept de jeu audio (pour Windows ou OS X), et ça m’a conforté dans mon premier ressenti. Je suis fasciné par l’idée de jouer à des jeux à l’aveugle depuis que j’ai lu les histoires de ce canadien qui a fini Zelda : Ocarina Of Time ou cet américain qui a fini Oddworld : L’exode d’Abe.

J’espère que le financement arrivera à son but, et que peut-être vous aussi vous participerez à cette belle aventure.

 

En mai dernier, j’avais retweeté cette comparaison que j’aime beaucoup (traduite par mes soins) :

Une interface utilisateur, c’est comme une blague. Si vous devez l’expliquer, c’est qu’elle n’est pas si bonne.

La citation a été reprise en français (sans mention de l’auteur original, tant pis), mais avec une légère déformation au passage :

Une interface utilisateur, c’est comme une blague, s’il faut l’expliquer c’est qu’elle n’est pas bonne.

Cette déperdition dans la traduction a généré quelques débats intéressants ici ou là. Et si je suis le premier à détester les explications pour utiliser une porte et à préférer l’apprentissage par le design, je sais aussi reconnaître que la complexité est parfois nécessaire.

Prenons par exemple le tableau de bord d’un Airbus A380.

Au premier abord, pour le néophyte que je suis, cette interface me paraît atrocement compliquée. Mais c’est peut-être parce que je n’y connais absolument rien en aviation. Et cette interface est destinée à être utilisée par des professionnels, ayant suivi des années de formations spécifiques. En soi, c’est plutôt rassurant de se dire que l’interface d’un appareil servant à transporter 800 personnes dans les airs est incompréhensible pour le premier venu.

Je pourrais en dire de même pour les interfaces des logiciels de traders ou même l’interface de World of Warcraft. Mais ces remarques sur les interfaces sont aussi valables pour les blagues.

Voici une de mes blagues préférées découverte ces dernières années (catégorisée dans les « blagues de papas »).

— Call me a taxi.
— OK. You’re a taxi.

Au risque de passer pour un idiot, je n’avais pas compris cette blague à sa première lecture. Mais dès que je l’ai comprise, j’ai trouvé ça drôle. C’est une bonne blague. La même chose est valable pour la blague anglophone suivante, lue chez Bruce Lawson :

Jean-Pierre : Toc-toc.
Armand : Qui est là ?
Jean-Pierre : Loste.
Armand : Loste qui ?
Jean-Pierre : Oui, malheureusement.

J’ai dû chercher des explications pour comprendre cette blague. Ça ne signifie pas que c’est une mauvaise blague. Maintenant que je la comprends, je l’apprécie beaucoup.

Une interface utilisateur, c’est comme une blague. Certaines blagues sont compréhensibles instantanément. D’autres nécessitent des explications pour être comprises par des gens comme moi qui pourront ensuite la trouver drôle. Mais ça ne suffit pas pour déterminer si une interface est bonne ou pas.

J’ai aussi regardé récemment Tim’s Vermeer, un documentaire produit par Penn & Teller (les magiciens). Ils suivent un de leurs amis informaticiens, Tim Jenison, qui s’est mis en tête de reproduire La Leçon de musique de Vermeer.

Je ne connaissais pas Vermeer plus que ça, mais il est soupçonné d’utiliser un système de projection et d’optique afin de reproduire des scènes avec un rendu précis et réaliste.

Ça m’a fait bizarre, parce que ça m’a rappelé certaines techniques employées au début du millénaire pour reproduire des pages web au pixel près (rires), où l’on superposait une maquette en JPG au dessus d’une page web pour s’assurer de bien respecter le travail du gentil graphiste web (à la main ou avec des outils comme Pixel Perfect).

Tim’s Vermeer est disponible en import chez Amazon.fr, et la bande-annonce est visible sur son site officiel ou sur Youtube.

Le week-end dernier, j’ai enfin regardé The Crowd Work Tour de Todd Barry. Le principe : pas de sketchs, pas de blagues préparées. Todd arrive chaque soir sur scène les mains dans les poches, et il commence à discuter avec certaines personnes du public. C’est au final très plaisant et plutôt drôle. Et c’est disponible pour seulement 5$ dans une version sans DRM chez Louis CK. (Si vous n’avez jamais rien acheté chez Louis CK, faites-le, c’est une très bonne expérience).

J’aime bien ce spectacle, parce que ça corrobore l’idée que la personne la plus intéressante lors d’une représentation n’est pas forcément celle qui est sur scène. Ça me fait penser à la « quête de sens » de Sud Web 2013.

En préparant ma conférence pour Sud Web 2014, je suis tombé sur une excellente citation de Donald Rumsfeld, ancien Secrétaire à la Défense des États-Unis d’Amérique. Il répondait en 2002 aux reproches de journalistes sur le manque de preuves de possession d’armes de destruction massive par le gouvernement Irakien.

Il y a des connaissances connues; ce sont les choses que nous savons que nous savons. Nous savons aussi qu’il y a des méconnaissances connues; c’est à dire que nous savons qu’il y a des choses que nous ne savons pas. Mais il y a aussi des inconnues inconnues, celles que nous ne savons pas que nous ne savons pas.

Ça lui a valu un Foot in Mouth Award. Mais j’ai trouvé que ça collait parfaitement à la description de mon métier d’intégrateur et la façon dont j’aborde ma veille.

Tout d’abord, il y a les choses que je sais que je sais. Par exemple, je connais les positionnements flottants en CSS, et je sais m’en servir. Ensuite, il y a les choses que je sais que ne sais pas. Par exemple, je sais qu’il existe des polices d’icônes, mais je ne sais pas m’en servir car je n’ai jamais eu l’occasion d’en utiliser sur aucun de mes projets. Enfin, il y a les choses que je ne sais même pas que je ne sais pas. Je ne peux pas vous donner d’exemple, puisque par définition, je ne sais pas ce que je ne sais pas.

Le but pour moi dans ma veille quotidienne est de réduire au maximum cette zone « d’inconnues inconnues ». Le métier d’intégrateur devient de plus en plus complexe et diversifié. Il y a deux ans, déjà, j’écrivais qu’une maîtrise complète de l’intégration n’est plus possible. Du coup, l’objectif pour moi est d’avoir une vision suffisamment large pour qu’à chaque choix que je doive faire lors d’une intégration, j’ai un maximum de cartes en main pour m’assurer de faire le bon choix.

Mario Kart 8 est sorti, et j’ai pu m’en délecter une bonne partie du week-end. J’adore certaines nouveautés, comme les portions de circuits sur des routes anti-gravité. Je m’accommode de certains changements, comme le fait qu’on ne puisse plus maintenir un objet à l’arrière de son kart et prendre un autre objet en même temps. Mais il y a un changement qui m’insupporte déjà plus que tout.

À la fin de chaque course en mode Grand Prix, il y a un écran de menu qui permet  de passer à la course suivante, de voir le replay de la course, ou de quitter la partie. Voici un aperçu de ces écrans dans les précédentes versions de Mario Kart (respectivement Mario Kart Double Dash, Mario Kart Wii, Mario Kart DS, et Mario Kart 7).

Et voici maintenant le même écran dans Mario Kart 8.

Nintendo a choisi de mettre le bouton vers le replay en premier, et le bouton vers la course suivante en second. Résultat : je me trompe régulièrement en appuyant par réflexe sur le bouton de validation dès la fin d’une course et je me tape donc le replay au lieu de passer à la course suivante.

C’est vraiment le genre de changement que je déteste dans une interface. 95 % du temps, je vais choisir d’accéder à la course suivante. Les 5 % restants seront partagés entre l’envie de revoir la course si vraiment il s’est passé un truc exceptionnel, ou de quitter la partie si je me suis complètement planté. Du coup, j’ai le sentiment que Nintendo me force à utiliser son nouveau système de replay Mario Kart TV, au détriment du jeu en lui même.

Il y a quelques années, j’ai donné des cours d’intégration web dans une école supérieure de Lille. L’expérience fut particulièrement enrichissante, mais j’ai arrêté au bout de deux ans pour pas mal de raisons. Et parmi ces raisons, il y a le fait que je me suis rendu compte à l’époque qu’enseigner l’intégration, c’est incroyablement difficile.

Cela fait partie des sujets que j’ai abordés vendredi dernier lors de ma conférence à Sud Web. J’ai eu le droit à pas mal de questions, et notamment une de Delphine : est-ce que les cours que je donnais sont disponibles quelque part, et sinon quelles ressources utiliser pour enseigner l’intégration ?

Je me suis tout de suite revu me poser exactement cette deuxième question quelques années auparavant, malheureusement sans y trouver de réponse satisfaisante. Dans un milieu où le partage de nos savoirs est si important, il semblerait que les ressources de cours destinés aux débutants et orientés sur la qualité et les bonnes pratiques soient plutôt rares. Et c’est ainsi qu’est né l’envie d’animer un atelier avec Delphine le lendemain à Sud Web sur ce sujet : comment enseigner l’intégration web ? Romy nous a rejoint pour l’occasion, ainsi qu’une bonne vingtaine de participants pour en discuter pendant une heure et demie.

Voici un résumé des grands points que j’ai retenus de ces échanges :

• Plus que la technique, il faut que les étudiants comprennent et retiennent les grands principes du web : accessibilité, interopérabilité, maintenabilité, référencement, standards du web, sémantique.
• Les étudiants ont besoin d’un projet concret pour motiver l’apprentissage. Lister la centaine de balises HTML5 n’a aucun intérêt en soi. Les grands principes théoriques doivent être distillés à petite dose, au bon moment, et toujours appuyés par un scénario pratique, qui peut partir d’un cas simple pour ensuite se complexifier.
• Les étudiants doivent apprendre à apprendre. Ils doivent devenir autonomes face à un problème. La recherche d’autorité quand on débute est importante (comme dans le cas de l’apprentissage d’un élève artisan avec son maître). Mais il faut aussi apprendre à peser les pours et les contres de chaque solution, et apprendre de ses erreurs.
• On manque aujourd’hui de ressources et d’outils destinés à des cours pour débutants. Un outil conçu spécialement pour l’apprentissage (comme un Bootstrap destiné uniquement à ça), ou un éditeur visuel adapté. L’idée d’avoir des tests automatisés permettant d’avoir un résultat clair à atteindre, un peu comme lors d’un Coding Dojo, a été suggérée.
• L’enseignement de l’intégration dépends fortement du format et de la fréquence des cours, ainsi que du profil des étudiants. On n’approfondira pas de la même manière si l’on n’a qu’une heure de cours par mois face à des étudiants hétérogènes que si l’on a huit heures par semaine avec des étudiants développeurs.

Si cet atelier n’a abouti à rien de concret, il me fait beaucoup réfléchir, et me donne vraiment envie de chercher comment améliorer cette situation.

En attendant, j’aimerais beaucoup avoir les retours d’enseignants ou d’étudiants en intégration web. Comment enseignez-vous l’intégration web ? Ou comment avez-vous appris l’intégration web ? N’hésitez pas à partager vos réponses sur votre blog ou dans les commentaires ci-dessous…

Mozilla a sorti hier Firefox 29, avec plein de nouveautés, dont l’interface Australis présentée en août 2011. Pour l’occasion, la page d’atterrissage après téléchargement arbore un nouveau slogan : « Engagé pour vous, votre vie privée et le Web ouvert ».

Curieux de voir comment la page était construite (en particulier le guide interactif des nouvelles fonctionnalités), j’inspecte le code source. Et là, à ma grande surprise, je découvre que la page inclut le script de Google Analytics, et que tous les clics au sein de la page sont trackés, et les données envoyées à Google. Je relève cette contradiction avec le slogan de la page sur Twitter. Et rapidement, mon tweet est retweeté en grand nombre. Et @clochix aura la bonne idée de remonter cette incohérence sur Bugzilla.

Mais les réponses apportées par les membres de la communauté Mozilla seront à l’encontre de mes attentes. La discussion est très rapidement close, et on y explique que l’utilisation de Google Analytics fait partie de la politique de respect de la vie privée sur les sites de Mozilla. Chris More, responsable de l’équipe des sites de Mozilla, invite au téléchargement d’une extension pour bloquer Google Analytics. Et David Bruant, contributeur Mozilla, invite à poursuivre la discussion dans un groupe Google.

À ce stade, voici l’image qui me vient à l’esprit d’un Mozillien typique :

Le problème, ce n’est pas l’utilisation de Google Analytics. C’est un excellent outil, et je suis le premier à m’en servir, et à le proposer à mes clients. Par contre, je sais pertinemment qu’en utilisant ce service de Google, j’expose mes visiteurs à fournir un peu plus de données sur eux à Google, sans leur consentement.
Et puis pour être honnête, la décision d’utiliser Google Analytics chez Mozilla semble avoir été murement balancée, en désactivant notamment l’exploitation des données envoyées avec Google et ses tiers. Et l’inclusion du code de suivi en lui-même est aussi faite proprement, avec l’utilisation de la fonction _anonymizeIp() qui « supprime le dernier octet de l’adresse IP avant son stockage » chez Google.

Le problème, c’est, de mon point de vue, de se vanter de s’engager pour la privée de ses utilisateurs d’un côté, et d’avoir une relation de plus en plus dépendante à Google de l’autre. Parce qu’il ne s’agit pas que de Google Analytics. Mozilla dépends financièrement de Google. C’est une relation idyllique : Google paye Mozilla 300 millions de dollars par an, et Mozilla renvoie tous ses utilisateurs sur une recherche Google par défaut pour y cliquer sur des publicités AdWords. Sur le marché des navigateurs, Mozilla a pour mission de vendre du temps de cerveau disponible à Google en quelque sorte. Et Google, en terme de vie privée, c’est le mal absolu.

J’utilise des tas de services Google. Mais en les utilisant, je sais pertinemment que c’est au détriment de ma vie privée. Ainsi, je n’ai absolument aucune confiance en Google en ce qui concerne la protection de mes informations personnelles.

Alors pourquoi est-ce que je devrais faire confiance à Mozilla ?

Mozilla s’est construit en menant une lutte acharnée contre le monopole de Microsoft au début des années 2000. Ils ont fait un travail remarquable qui a permis d’arriver aujourd’hui à un marché et une concurrence saine entre les navigateurs desktop. Mais aujourd’hui, la société monopolistique qui fait peur à tout le monde, ce n’est plus Microsoft. Ce n’est pas Apple, qui n’a jamais eu le moindre monopole. Non, c’est Google, qui grâce à son monopole dans le domaine de la recherche, s’impose partout ailleurs.

Cette année, le contrat de trois ans signé entre Google et Mozilla en 2011 arrive à son terme. Nulle doute qu’il sera reconduit, pour un montant probablement encore plus élevé que le précédent (sachant que Google donne trois fois plus d’argent à Apple qu’à Mozilla pour être le moteur de recherche par défaut). Mozilla a le pouvoir incroyable de faire trembler le monopole de Google en refusant un nouvel accord. Mozilla pourrait alors être plus crédible à mes yeux pour parler de respect de vie privée.

Francisco Tolmasky, ancien développeur dans l’équipe de Safari sur iPhone chez Apple, raconte des anecdotes sur Steve Jobs :

M. Jobs était connu pour s’imposer autant qu’il le pouvait. Une personne de l’équipe de design de l’iPhone s’appelait aussi Steve, ce qui causait une certaine confusion dans les réunions. M. Jobs a cherché à changer ça.

« À un moment, Steve Jobs était vraiment frustré à cause de ça et a dit « Devine quoi, à partir de maintenant tu seras Margaret » », expliqua M. Tolmasky. À partir de ce moment là, les membres de l’équipe s’adressèrent à Steve le designer comme Margaret.

Autrement dit, Steve Jobs avait un petit côté Dr. Cox.

Cette semaine, j’ai eu la tristesse d’apprendre la fermeture de Five Simple Steps, un éditeur de sympathiques livres numériques sur la conception web. Ça m’embête d’autant plus que j’avais plein de leurs livres sur ma liste de choses à acheter un jour. Heureusement, certains auteurs ont déjà franchi le cap pour remettre à disposition leur livre ailleurs, et ce parfois désormais gratuitement. Voici une liste où trouver les titres initialement publiés par Five Simple Steps (bien aidé par la liste démarrée par Nick Bramwell et iTunes Link Maker).

A Pocket Guide

• Colour Accessibility, de Geri Coady, 5 $ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Combining Typefaces, de Tim Brown, 1,49 € (chez Amazon ou sur iTunes)
• Creating Symbol Fonts, de Brian Suda, 3 $ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• CSS Animations, de Val Head, payez ce que vous voulez (2,68 € chez Amazon ou 1,49 € sur iTunes)
• CSS3 Layout Modules, de Rachel Andrew, 3 $ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Design Evolution, de Josh Long
• Experiments for Designers, de Colin McFarland (pas encore disponible)
• Front-end Style Guides, de Anna Debenham, 2 £ (1,49 € chez Amazon ou sur iTunes)
• HTML Email, de Andy Croll (2,68 € chez Amazon ou 1,49 € sur iTunes)
• International User Research, de Chui Chui Tan, 2,75 £ (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Interviewing for Research, de Andrew Travers (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Psychology for Designers, de Joe Leech, 2,75 £ (ou 1,49 € chez Amazon ou sur iTunes)
• The Craft of Words. Part One : Macrocopy, de The Standardistas (2,68 € chez Amazon ou 1,49 € sur iTunes)
• The Craft of Words. Part Two : Microcopy, de The Standardistas (2,68 € chez Amazon ou 1,49 € sur iTunes)
• Usability of Web Photos, de James Chudley (2,68 € chez Amazon et 1,49 € sur iTunes)
• Web Performance, de Andy Davies, 2,75 £

Practical Guides

• Designing for the Web, de Mark Boulton, gratuit (ou 4,99 € chez Amazon ou sur iTunes)
• Designing the Invisible, de Robert Mills
• Designing with Data, de Brian Suda, 25 $ (ou 7,21 € chez Amazon ou 4,99 € sur iTunes)
• Information Architecture, de Donna Spencer (7,21 € chez Amazon ou 4,99 € sur iTunes)
• Managing Web Projects, de Breandán Knowlton
• Web App Success, de Dan Zambonini, gratuit

Specials

• Hardboiled Web Design, de Andy Clarke, 12,90 €
• The Icon Handbook, de Jon Hicks, 10 £

Si vous repérez les quatre livres manquants, n’hésitez pas à me faire signe sur Twitter ou dans les commentaires.

Récemment j’ai enfin mis le doigt sur quelque chose qui me dérangeait depuis pas mal de temps, mais sans trop savoir pourquoi.

Il y a d’abord eu ce tweet de Charles de UXUI, dénonçant le site d’une agence qui publie sur son blog des traductions d’articles anglophones, mais sans jamais mentionner qu’il s’agit de traduction, en cachant discrètement l’article original sous un vulgaire lien « source », et en indiquant à la fin « article rédigé par [membre de leur équipe] ». Je trouve ça particulièrement malhonnête. C’est essayer de s’attribuer les mérites du travail d’un autre. Quelques échanges plus tard, la mention « article rédigé par » a été changée par « article mis en ligne par », ce qui est déjà un peu mieux. Mais il reste toujours ce vilain lien source.

Quand vous mettez un lien derrière un simple « via » ou « source », vous vous assurez que ce lien n’aura quasiment aucune valeur pour l’auteur, alors que ça aurait été l’occasion d’offrir à l’auteur à l’origine de votre propre publication un joli backlink.

Il n’y a rien de dévalorisant à citer quelqu’un. Si je lis quelqu’un que j’apprécie, et qu’en plus cette personne me fait découvrir de nouveaux auteurs à suivre, je n’en serais que plus reconnaissant. J’ai l’impression que les gens qui ne citent pas ou cachent leurs sources ont peur de perdre une partie de leur lectorat. Mais si c’est vraiment le cas, ça veut alors dire que votre article n’apporte strictement rien par rapport à l’article d’origine, et qu’il faut donc peut-être se remettre en question…

Et puis cette semaine, il y a eu ce classement des « développeurs francophones les plus suivis sur Twitter ». Je passe sur la pertinence de ce « concours de celui qui a la plus grosse », sur le fait que sur 50 développeurs, 36 ont des bios en anglais, ou sur la promotion spamesque faite pour cette page sur Twitter. Par contre, je suis plus dérangé par le fait que la raison principale de l’existence de cette page, c’est de faire la publicité des formations organisées par la société qui l’a créé. C’est certes discret, tout en bas de page, mais c’est bien là.

C’est en me tournant vers mon astrophysicien préféré que j’ai réussi à éclairer ce qui me dérangeait dans tout ça. Lors d’une rencontre avec Neil deGrasse Tyson dans son université, Anna H. a eu la chance de lui poser une question sur l’importance de la sensibilisation du grand public sur son métier.

Anna H : Vous parlez beaucoup du changement de la perception publique de la science. Je me demandais si vous pouviez nous parler des changements de la perception des scientifiques de la sensibilisation de leur métier — dans quelle mesure la sensibilisation est valorisée dans la communauté scientifique.

Neil deGrasse Tyson : Ah, excellente question, et une qui me tient particulièrement à coeur.

Carl Sagan a fait des erreurs, mais il était le premier a faire de la sensibilisation publique très visible, à grande échelle, donc il avait le droit de faire des erreurs. Mais je ne suis pas le premier, donc j’ai pu apprendre de ses erreurs. Carl ne donnait souvent pas crédit quand il décrivait des résultats de recherche astronomique. Beaucoup de gens regardant son programme ont pensé que c’était lui qui faisait toutes ces découvertes. Après son décès, des journaux ont écrit des choses comme « la seule récompense à lui avoir échappé était le prix Nobel ! », ce qu’ils n’auraient pu écrire que s’ils avaient pensé que toutes ces découvertes dont il parlait étaient ses découvertes. C’étaient des travaux sur lesquels d’autres scientifiques avaient peut-être passé des décennies, et Carl recevait toute la reconnaissance. Ça a rendu plein de gens amers.

Quand je décrit des recherches scientifiques, je fais toujours attention à les attribuer au groupe qui a travaillé sur le projet. Quand un journal m’appelle et me demande des commentaires, je les redirige toujours vers le groupe qui a fait le travail.

Aussi, je ne parle jamais de mes propres recherches. Je n’utilise pas ma plate-forme comme une opportunité pour faire la publicité de mes résultats personnels. Ma spécialité ce sont les galaxies, mais presque personne ne le sait. Je parle de ce qui selon moi va captiver le plus le public, et j’appelle des collègues si je n’y connais pas grand chose.

Je n’ai jamais ressenti d’antagonisme de la communauté professionnelle d’astronomie, et je pense que c’est parce que je leur donne toujours crédit pour leur travail.

Toujours donner crédit à ses sources, et ne jamais faire son auto-promo. Ce sont deux règles que j’essaye de suivre sans m’en rendre compte depuis des années.

Jeremy Keith, sur son blog :

Cette idée d’un web comme une plate-forme, je la comprends d’un point de vue marketing. On aimerait utiliser cette phrase, parce qu’elle place le web à un pied d’égalité avec des véritables plate-formes.

Je dirais que Flash est une plate-forme, et native : iOS et Android et toutes ces choses. Ce sont des plate-formes, dans le sens où tout n’est qu’un gros paquet. Mais le web n’est pas comme ça.

Si vous utilisez la plate-forme Flash, n’importe qui ayant le plug-in Flash pourra accéder à votre contenu. C’est tout ou rien. C’est un ou zéro. C’est binaire. Soit ils ont la plate-forme, soit ils ne l’ont pas. Soit ils ont tout votre contenu, ou aucun de vos contenus.

Et c’est similaire avec les applications natives. Si vous avez le bon téléphone, vous pouvez avoir mon application. Toute mon application. Vous n’accédez pas à des morceaux de mon application, vous avez toute mon application. Ou vous n’avez rien du tout parce que vous n’avez pas ce téléphone spécifique que je supporte.

Le web n’est pas comme ça. Le web n’est pas binaire, un ou zéro, tout ou rien. Ce n’est pas une plate-forme où vous avez cent pour cent ou zéro pour cent. C’est un continuum.

La semaine dernière, le site Twitch a lancé Twitch Plays Pokemon. C’est grosso modo une version modifiée des jeux Pokémon Rouge et Bleu sur Game Boy contrôlée par les joueurs indiquant leurs commandes dans le chat. Ça donne un joyeux bordel où des milliers de joueurs indiquent toutes les commandes possibles et leurs contraires. Et aussi incroyable que ça puisse paraître, ils arrivent à progresser dans le jeu.

Le blog Minimaxir a publié un excellent compte-rendu de cette partie. Et plus particulièrement de certaines difficultés rencontrées :

HM 01 est un objet qui permet de donner la capacité de Couper à un Pokémon, ce qui est nécessaire pour couper des arbres bloquant le passage. En l’occurrence ici, l’arbre en face du gymnase de Vermilion City. Afin d’apprendre à un Pokémon à couper, le joueur doit :

1. Faire apparaître le menu Start.
2. Sélectionner « Objets. »
3. Sélectionner HM 01.
4. Confirmer que HM 01 doit être utilisé.
5. Choisir un Pokémon à qui apprendre à couper.
6. Confirmer que le Pokémon choisi doit apprendre à couper.
7. Choisir une capacité à remplacer par « couper ».

La partie marrante ? Appuyer sur le bouton B ou choisir la mauvaise option durant n’importe laquelle de ces sept étapes fait revenir le processus un pas en arrière.

À ce stade dans le flux, l’audience avait atteint 30 000 spectateurs. L’activité augmentée causait un délai d’entrée d’environ vingt secondes entre le moment où un utilisateur de Twitch avait saisi sa commande dans le chat et le moment où la commande était reconnue dans le jeu. Ça peut rendre la navigation dans les menus difficile quand une commande « Haut » ou « Bas » est appliquée à un menu qui n’est même pas encore visible.

En plus de ça, alors que le nombre de spectateurs augmentait, le nombre de trolls aussi. Et ces trolls adoraient spammer le bouton B.

Grâce à tous ces facteurs, la chaîne a passé plus de 4 heures sans parvenir à apprendre à un Pokémon à couper. Le chat était devenu un véritable bain se sang de reproches.

Et puis ça a fini par arriver. Le Canarticho a appris à couper. Personne ne sait comment, mais c’est arrivé. Mais ce n’était qu’un pas vers la progression.

La seconde étape était d’effectivement couper l’arbre en question. Afin de couper, il fallait

1. Faire face à l’arbre.
2. Faire apparaître le menu Start.
3. Choisir « Pokémon ».
4. Choisir le Pokémon avec qui couper.
5. Choisir « Couper ».

Même problèmes qu’auparavant. Et faire face à l’arbre est encore plus difficile puisque les commandes Haut/Bas pour naviguer dans le menu peuvent éloigner le personnage de l’arbre.

Il a fallu à nouveau 4 heures pour couper cet arbre. Et plus tard, quand le personnage a été vaincu dans le gymnase, l’arbre avait réapparu. Oui.

HM 01 est un dur rappel que plus il y a de personnes présentes, plus il y a de chances que votre tâche échoue. Pas forcément à cause d’incompétence ou de manque d’organisation, mais simplement à cause de personnes mal intentionnées.

Cette avant dernière phrase s’applique particulièrement bien aux réunions en entreprise.

Un paragraphe dans l’introduction de l’article m’a particulièrement marqué :

Au final, la communauté des joueurs se bat contre son plus grand ennemi : soi même. Le but de Twitch Plays Pokémon n’est pas de gagner. C’est de ne pas échouer de manière spectaculaire. Et ils échouent quand même quoi qu’il en soit. C’est une irrésistible collision ferroviaire qu’il est difficile de s’arrêter de regarder.

Je trouve que ça fait une bonne analogie pour parler du web. Parce que quand j’y pense, c’est quand même incroyable que le web existe toujours et qu’on arrive à aller de l’avant dans cette plate-forme ouverte et collaborative. Parce que dans ce joyeux bordel, tout le monde aussi veut avoir le contrôle.

Entre les opérateurs (qui rêvent d’un web fermé où ils pourront facturer votre navigation par forfait de sites comme les abonnements TV), les fabricants de navigateurs (qui rêvent d’avoir un monopole absolu et d’imposer leurs technologies propriétaires), les États (qui rêvent d’avoir un contrôle sur tout ce qui peut transiter sur le réseau), et puis nous autres petits concepteurs web (qui rêvons d’avoir un contrôle sur le rendu et le fonctionnement de nos pages), c’est tout bonnement incroyable qu’on arrive à faire le moindre progrès.

Et pourtant.

J’aime bien les histoires de plagiat. Je me délecte toujours quand je lis des histoires comme celles de Marc Maggiori, des « Simpalas », de Layervault contre Flat UI, les documents internes de Samsung expliquant tout ce qu’il faut recopier d’iOS, ou des développeurs de Candy Crush Saga. Récemment, deux histoires m’ont particulièrement intéressé.

Tout d’abord, il y a l’histoire de Casey Neistat, un vidéaste américain, qui fin 2012 a eu l’idée de rendre une visite surprise à sa copine à l’autre bout du monde, et de filmer tout son périple au passage. Ça donne une vidéo sympathique bien qu’un peu longuette de son aventure très personnelle. Fin 2013, un français (cocorico) du nom de Maxime Barbier décide de reprendre le même concept, d’en faire sa vidéo, et de la vendre au passage à Coca-Cola. Maxime ne s’est pas caché d’être un fan de Casey Neistat et de s’être « inspiré » de sa vidéo, mais l’inspiration allait ici jusqu’à reprendre mot pour mot certaines répliques de la vidéo originale. Casey Neistat a donc publié un article sur son blog pour dénoncer tout ça, et la vidéo copiée a rapidement été retirée. Il explique ce qui le dérange le plus dans toute cette histoire :

C’est difficile de pointer du doigt pourquoi ça m’énerve autant. Copier fait partie du jeu. Ce n’est pas la première, et certainement pas la dernière, fois que quelque chose comme ça se produit. Peut-être que c’est parce que mon film était fait entièrement d’amour et de bonheur. Je ne faisais pas expressément un film, ce n’était pas la motivation pour surprendre ma copine. Je me suis juste retrouvé coincé dans des avions pendant 27 heures et j’ai décidé de tout filmer. Ce n’était que quelques semaines après le voyage que mon ami Max Joseph m’a aidé à monter le tout en un film après lui avoir montré les scènes de ma copine en train de crier quand elle m’a vu à sa porte à 12 000 Km de chez moi. Ou peut-être que c’est parce que je n’ai jamais gagné le moindre centime avec ma vidéo, que je n’avais même pas monétisée sur Youtube. C’est une histoire qui m’a rendu tellement heureux de la revivre encore et encore en regardant mon film que de regarder la copie merdique pour Coca-Cola de cet intrus a tout gâché pour moi.

Comme si cette expérience qui était si intime et centrale dans ma vie pouvait être reproduite et vendue en canettes rouges de trente-trois centilitres.

Plus récemment, Dong Nguyen, un développeur vietnamien, a connu un succès foudroyant avec un jeu sur iOS et Android : Flappy Bird. Sorti en milieu d’année dernière, le jeu était passé inaperçu. Mais après un mystérieux effet boule de neige et la mention sur une chaîne Youtube aux vingt millions d’abonnés, les téléchargements du jeu ont explosé. Le jeu rapporterait alors 50 000 dollars par jour en publicités à son créateur. Et c’est alors qu’entre en scène Kek, un autre français (cocorico), auteur habituellement de sympathiques bande-dessinées. D’après lui, Flappy Bird serait une copie pure et simple d’un de ses jeux, Piou Piou contre les cactus. Il contacte Dong Nguyen, qui nie avoir déjà entendu parlé de son jeu. Kek tente alors de faire la démonstration du plagiat sur Twitter en publiant l’image suivante :

Et c’est là où ça commence à me déranger. Contrairement aux histoires de plagiat évidentes et avérées, ici Kek n’a aucun autre argument qu’une ressemblance entre les deux oiseaux. En réponse à certains détracteurs sur Twitter ou dans un article sur le Huffington Post, Kek estime être le créateur original du « petit oiseau jaune aux grosses lèvres ». Permettez-moi d’en douter. Au niveau du gameplay et de la réalisation, les deux jeux n’ont strictement rien à voir. Mais les deux jeux sont très inspirés de l’univers de Nintendo (les tuyaux pour Flappy Bird, les cactus et le désert pour Piou Piou). Mais ça suffit pour que le 8 février dernier, Dong Nguyen retire Flappy Bird de l’App Store et de Google Play, avec pour seul motif qu’il ne supporte plus le succès de son jeu. Et du coup, je ne peux pas m’empêcher de me poser la question : qu’attendait Kek en publiant cette image ? Est-ce que secrètement il espérait que l’auteur reconnaisse un plagiat, et lui verse un chèque ? Ou alors que l’auteur retire Flappy Bird pour que tout le monde se mette à jouer à Piou Piou (et tant pis si les deux jeux n’ont rien à voir, ludiquement parlant) ? Contrairement à la copie avérée de la vidéo de Casey Neistat, j’ai l’impression que la seule motivation du hurlement au plagiat ici est l’argent (ce qui ressent tout au long de la lecture de l’article de Kek, sobrement intitulé « Comment j’ai failli être millionnaire »).

Ça m’arrive aussi d’être copié. Parfois ce sont de simples tweets que je retrouve mots pour mots. Il y a quelques années, j’étais tombé sur un article ressemblant très fortement au mien sur l’e-mail le plus réussi au monde. Même sujet (pourtant assez spécifique et dont j’avais parlé pour des raisons personnelles évoquées en tout début d’article), et surtout, le « copieur » avait repris mot pour mot ma traduction de l’e-mail en question. Surpris mais amusé, j’avais posté les deux liens sur Twitter avec un message du genre « Copié / collé ». Ce que je n’avais pas prévu, c’est qu’en quelques minutes, le blog du copieur a été inondé de commentaires d’insultes, probablement de la part de certains de mes followers pas très malins. En voyant ça j’ai aussitôt supprimé mon tweet pour éviter d’autres commentaires nauséabonds. Mais le mal était fait. Plus tard, le copieur supprima son article. Je n’attendais rien de particulier en pointant du doigt cette copie. Mais au final, tout le monde a perdu : les lecteurs du blog copieur perdent un article intéressant, l’auteur du blog s’est fait insulté sans raison valable, et moi je me suis senti mal que tout ça arrive alors que je n’avais aucune attente particulière.

Et je crois que c’est ce qui me dérange dans l’histoire de Flappy Bird. Au final, tout le monde a perdu : les joueurs sont privés d’un jeu original, l’auteur a du retirer sa création personnelle, et Kek passe pour le méchant français avare de service.

La meilleure solution reste de prendre les plagiats comme des flatteries. Ou sinon, de ne plus rien créer du tout.

Je l’ai posté sur Twitter cette semaine, mais je le redis ici. Je trouve ce comparateur de portefeuille absolument génial.

Cette semaine, je suis tombé sur le site de Wired UK et cet article sur Tim Berners-Lee qui fait la une du numéro de mars. Et je suis resté jouer un petit moment avec la fonctionnalité d’agrandissement de l’image accompagnant l’article.

 

Quiz : à votre avis, en cliquant sur ce bouton « Enlarge« , que va-t-il se passer ?

1. L’image va s’agrandir à partir de son emplacement actuel
2. La page va scroller pour revenir tout en haut et afficher l’image

Évidemment, c’est la réponse 2. Si c’est comme ça, c’est parce que sur des petites résolutions, l’image en question se trouve en haut de l’article. Sauf que sur mobile, l’agrandissement de l’image ne sert à rien puisque l’image prend déjà toute la largeur de l’écran.

Ou comment une fonctionnalité mal conçue en mobile first vient pourrir l’expérience desktop.