HTeuMeuLeu

Des discussions intéressantes ont émergé récemment sur la pertinence de la dénomination du métier d’intégrateur à travers des articles comme « Je ne suis pas développeur » (par STPo), « Front-end designer ou intégrateur ? » (par Éric Daspet) ou dans un document collaboratif (lancé par Marie Guillaumet).

J’ai un attachement personnel déraisonné pour le nom d’intégrateur. Mais à chaque fois que je lis des discussions sémantiques sur des termes de nos métiers, je ne peux pas m’empêcher de repenser à ces sages paroles de Richard Feynman.

Un lundi, quand nos pères étaient au travail, nous autres enfants jouions dans un champ. Et l’un des enfants m’a dit : « Tu vois cet oiseau ? Quelle espèce d’oiseau est-ce que c’est ? » Et j’ai dit que je n’avais pas la moindre idée de quelle espèce d’oiseau il pouvait s’agir. Et il dit : « C’est une grive à gorge brune. Ton père ne t’apprend rien du tout ! » Mais c’était tout le contraire.

Il m’avait déjà tout appris. « Tu vois cet oiseau ? » me disait-il. « C’est une fauvette de Spencer » (il ne connaissait pas le vrai nom). « Et bien, en italien, c’est une Chutto Lapittida. En portugais, c’est un Bom da Peida. En chinois, c’est un Chung-long-tah, et en japonais, c’est un Katano tekeda. Tu peux apprendre le nom de cet oiseau dans toutes les langues du monde, mais quand tu auras fini, tu ne connaîtras absolument rien de cet oiseau. Tu en sauras seulement plus sur les humains à différents endroits, et comment ils nomment cet oiseau. Alors regardons cet oiseau et voyons ce qu’il fait — c’est ça qui compte. »

J’ai appris très tôt la différence entre savoir le nom de quelque chose et savoir quelque chose.

Je me fiche pas mal que mes collègues ou clients me désignent comme intégrateur, développeur front-end, monteur HTML ou développeur guichet. L’important, c’est qu’ils comprennent ce que je fais, là où mon métier commence, et là où il s’arrête. Et ça peut très bien varier d’un client à un autre, ou d’un projet à un autre.

Depuis un peu plus d’un an, j’habite à la campagne. Le vacarme du ramassage des poubelles au réveil a été remplacé par le chant des oies et le meuglement des vaches. En contrepartie, j’ai dû troquer ma connexion ADSL citadine à 10 Mbits/s contre une connexion ADSL de campagne à 2 Mbit/s.

2 Mbit/s, c’est quand même pas mal. J’ai découvert le web avec une connexion 56 K, et j’ai grandi avec une connexion ADSL à 512 Kbit/s. À 2 Mbit/s, je peux télécharger presque 1 Go en une heure. (Avec une connexion 56 K, il m’aurait fallu plus de 2,5 jours.) C’est une connexion suffisante pour surfer sur le web dans des conditions convenables. Mais il y a quand même quelques inconvénients. Par exemple, dès que je veux regarder une vidéo en streaming. En dehors de Youtube et Vimeo, la plupart des lecteurs vidéo du web sont absolument atroces pour ma connexion. Par exemple ce matin, j’ai voulu regarder une vidéo chez Polygon vantant les graphismes d’un nouveau jeu Star Wars.

Voici ce que j’ai vu.

Autant dire que je ne trouve pas ces graphismes folichons. En forçant manuellement la vidéo en qualité élevée, j’étais déjà plus emballé. Mais j’ai du attendre près d’une minute pour que le lecteur ait téléchargé une dizaine de secondes. J’ai donc rapidement abandonné le visionnage de cette vidéo.

Là où ça se gâte, c’est quand la télévision (via ADSL) est allumée. Je passe alors d’un débit de 2 Mbits/s à 0,2 Mbits/s. Ça devient alors un tout autre monde. À 0,2 Mbit/s, il me faut environ quarante secondes pour charge une page d’un mégaoctet. Le web presque tout entier devient alors très, très lent. Quand il se charge. À 0,2 Mbits/s, n’importe quelle interface reposant lourdement sur du JavaScript devient tout simplement inutilisable. L’écran de chargement de Gmail me semble interminable. Je maudis les sites utilisant des polices personnalisées en CSS, car je suis condamné à regarder des pages sans aucun texte pendant qu’elles se chargent.

Je rencontre aussi parfois des surprises. Par exemple, le soir où Apple annonce le langage Swift et que je veux voir par simple curiosité à quoi ça ressemble, j’essaye de télécharger le livre de présentation sur iBooks.

« 2 heures » de téléchargement restant pour 308 Ko. Ça fait beaucoup. J’ai compris un peu plus tard pourquoi c’était si long. Au même moment, ma Wii U avait décidé de se mettre à jour. 2 Mbits/s moins la télé moins le téléchargement d’une mise à jour pour la Wii U égale plus grand chose pour le web.

Alors face à ça, je m’adapte. Je laisse des pages se charger en arrière-plan, et j’y retourne cinq minutes plus tard, en espérant que tout soit bien chargé. Mais là encore, je maudis certains sites qui forcent le rafraichissement des pages en utilisant une <meta http-equiv="refresh">. Je maudis aussi les sites qui utilisent un scroll infini plutôt qu’une pagination, parce que ça signifie que je suis condamné à regarder des contenus se charger, plutôt que de passer directement à la page suivante en arrière-plan. Et je maudis aussi les sites qui utilisent des scripts de lazyload pour des images (qui permettent de ne déclencher le chargement des images qu’une fois que l’utilisateur a scrollé jusqu’à leur niveau). Avec ma connexion de campagne, ça signifie que je dois encore une fois attendre devant mon écran que ces contenus se chargent.

Mais tout ça est en passe de changer ! En fin d’année dernière, j’ai découvert qu’Orange avait installé une antenne 4G à trois kilomètres de chez moi. Je suis alors aussitôt passé chez Sosh. J’avais pris un téléphone du boulot pour tester le débit en 4G. J’ai hurlé de joie en voyant le premier résultat sur SpeedTest.

Malheureusement, mon iPhone 5 ne supporte pas la 4G française (à part sur les fréquences de Bouygues Telecom). Mais rien qu’en 3G+, j’ai déjà un débit dépassant les 8 Mbit/s. C’est déjà un grand pas en avant pour moi pour le moment. Et je changerais peut-être de téléphone dans le courant de l’année pour profiter de la 4G.

Alors pourquoi je raconte tout ça ? Parce que ça me fait beaucoup réfléchir sur les statistiques de débit que je peux lire et parfois communiquer à mes clients. Juste parce que j’ai une connexion théorique de 2 Mbit/s ne signifie pas que j’ai ces 2 Mbit/s de disponibles pour surfer sur le web. Même quand ma télévision n’est pas allumée, je suis quasiment en permanence sur Spotify, qui pompe forcément une partie de mon débit.

Ça me fait réfléchir aussi, parce que les bonnes pratiques de report de chargement de fichiers se révèlent en fait être un enfer avec un petit débit.

Et puis ça me fait réfléchir, parce que la connexion la plus rapide avec laquelle j’ai accès au web est désormais sur mon téléphone. J’utilise quasiment en permanence cette connexion partagée depuis mon téléphone sur mon ordinateur. Si mon forfait n’était pas limité en téléchargement (à 3 Go), j’aurais probablement déjà résilié mon abonnement ADSL.

 

J’ai découvert chez Khoi Vinh ce sketch de Tommy Johnagin qui aide sa mère à installer iTunes. J’ai ri tout haut à ce passage :

Elle m’a appelé une heure après. « J’ai téléchargé une chanson. Est-ce que c’est censé s’ouvrir dans Microsoft Works ? » Non, maman. Non, ce n’est pas censé s’ouvrir dans Microsoft Works. Je ne sais même pas comment tu as fait pour que cela se produise. Je ne suis pas suffisamment intelligent pour être suffisamment bête pour revenir à l’envers et comprendre le nombre de choses que tu as fait de travers pour ouvrir une chanson dans Microsoft Works. Bill Gates ne pouvait pas ouvrir une chanson dans Microsoft Works. Le nombre de fois où ton ordinateur a du te dire « Êtes-vous sûr ? ». Et en toute confiance : « Oui ! Pourquoi est-ce que tu continues à demander ? ». L’ordinateur doit se dire « je ne pense pas que nous sommes censés être là Madame ».

J’aime beaucoup l’expression « être suffisamment intelligent pour être suffisamment bête ». Aussi je ne sais pas si c’est une erreur ou du génie, mais le sketch en question dans son album s’intitule « Mom Itunes ». Je penche pour la seconde option.

En décembre dernier, j’ai lancé la troisième édition de 24 jours de web, « le calendrier de l’avent des gens qui font le web d’après ». J’ai déjà donné quelques détails sur l’intégration du site. J’avais aussi écrit un compte rendu de l’édition 2012, mais rien sur l’édition 2013. Voici quelques remarques personnelles sur cette dernière édition et sur le projet en général.

Lire la suite de « Retour sur 24 jours de web, édition 2014 »

Les attentats perpétrés ce mercredi 7 janvier à Paris m’ont laissé sans voix. Je n’ai aucune idée de comment réagir face à ce genre de situation. Je regarde les chaînes d’infos en boucle. Je lis et relis des articles sur tous les sites d’information ressassant les mêmes informations. Comme si j’avais besoin de me rappeler que c’était bien arrivé.

Néanmoins, je trouve un certain réconfort à observer des rassemblements, un peu partout dans le monde ou en ligne, souvent derrière le slogan « Je suis Charlie ». Mais je n’ose pas prononcer ce slogan pour autant. Parce que si je suis pour la liberté d’expression, je n’ai jamais œuvré pour sa défense. Je n’ai jamais acheté le moindre exemplaire de Charlie Hebdo. Et je ne me suis encore moins battu pour pouvoir librement publier mes idées.

Charlie, oui. Et des journalistes, dessinateurs, et policiers assurant leur protection sont morts pour ça. Je n’ai pas le millionième de courage et de valeurs que ces gens avaient.

Ce matin, je lis que le site français d’Apple arbore fièrement une bannière avec le slogan « Je suis Charlie ». Et ça me met hors de moi.

Il y a une page Wikipédia recensant quelques exemples de censures opérées par Apple. Le plus approprié à vous donner est le suivant :

En décembre 2009, Apple a banni une application de dessins humoristiques appelée NewsToons par le dessinateur Mark Fiore, sur les motifs qu’elle « ridiculisait des personnalités publiques ».

En avril 2010, Fiore a gagné le prix Pulitzer pour ses dessins satiriques politiques, rentrant dans l’Histoire comme le tout premier dessinateur publié uniquement sur Internet à gagner le prestigieux prix journalistique. Suite à un tollé général après que l’affaire ait fait grand bruit au lendemain de sa récompense, Apple a demandé à Fiore de resoumettre son application, et elle a cette fois-ci été acceptée.

Fiore déclara : « Bien sûr, mon application a été approuvée. Mais que se passe-t-il pour quelqu’un qui n’a pas gagné un Pulitzer et qui fait peut-être une meilleure application politique que la mienne ? Est-ce qu’il faut une frénésie médiatique pour qu’une application avec du contenu politique soit approuvée ? »

Cet exemple date d’il y a quelques années, et il avait fait grand bruit dans la presse généraliste. Mais il ne se passe pas une semaine sans que je ne lise un exemple du même genre. Encore ce matin, justement, je suis tombé sur ce tweet :

Notre application iOS a été rejetée de l’App Store parce qu’un lien de support va sur le web vers une FAQ où nous mentionnons que nous avons une application disponible sur Android.

Alors, non, Apple, tu n’es pas Charlie. Tu œuvres au quotidien contre la liberté d’expression pour défendre tes intérêts commerciaux. Je comprends que tu sois ému par ces attentats et que tu souhaites apporter ton soutien. Mais dans ce cas, il est peut-être temps de revoir ta politique de revue des contenus afin de défendre la liberté d’expression plutôt que la brider.

Le mois dernier, j’ai été missionné par le Père Noël pour trouver une poupée « Elsa Chantant » pour ma filleule. Après une recherche sur Google, j’ai rapidement décidé de passer commande sur le site de Toys“R”Us (qui m’assurait d’être livré dans les temps, vu que je ne m’y prenais pas du tout à la bourre…). Je n’avais jamais passé de commande sur le site, et j’ai été très agréablement surpris par la simplicité et la facilité d’achat sur le site. En effet, dès la page panier, le site de Toys“R”Us propose un bouton « Acheter avec Paypal » qui me redirige directement vers Paypal. Je n’ai alors eu qu’à me connecter à mon compte Paypal, et toutes mes coordonnées ont été récupérées. J’ai ainsi pu passer une commande sans avoir à me créer de compte chez Toys“R”Us, ce qui est vraiment pratique dans ce genre de cas où je ne compte pas refaire d’achat.

À ce moment précis, j’étais un client totalement satisfait. Mais je ne sais pas si je peux en dire autant pour tout ce qui a suivi ma commande, hors du site, à travers les différents e‑mails reçus. Et en y repensant, j’ai l’impression que mon expérience est assez représentative de ce qui se passe pour un client après une commande en ligne. Cet article n’a donc rien du tout de personnel contre Toys“R”Us. Je tenais plutôt à partager quelques remarques et réflexions.

Lire la suite de « L’expérience après une commande »

Pour la troisième année consécutive, mon mois de décembre est rythmé par 24 jours de web (le « calendrier de l’avent des gens qui font le web d’après » dont j’avais parlé ici en 2012 et 2013). Le mois dernier, j’ai un peu retravaillé l’intégration du site, en particulier la page d’accueil et sa vue en calendrier. Voici des détails sur quelques points sur lesquels j’ai porté mon attention pour cette mise à jour.

Lire la suite de « Quelques détails sur l’intégration de 24 jours de web »

Le mois dernier, je suis tombé via Twitter sur cette excellente conférence TED de Maysoon Zayid, une comédienne atteinte de paralysie cérébrale qui raconte son parcours face au ressenti de son handicap. C’est vraiment l’une des meilleures conférences TED que j’ai regardé ces dernières années. Voici quelques morceaux choisis :

S’il y avait des Jeux Olympiques de l’Oppression, je gagnerais la médaille d’or. Je suis Palestinienne, Musulmane, je suis une femme, je suis invalide, et je vis dans le New Jersey. […]

J’ai eu une bourse pour l’Université d’État d’Arizona, parce que je remplissais chacun des quotas. […]

Les gens avec des handicaps constituent la plus grande minorité au monde, et nous sommes les plus sous-représentés dans le spectacle. […]

En l’écoutant, ça m’a rappelé un sketch de Louis C.K. (qui avait fait le tour du web en image) :

J’ai lu quelque chose dans le journal qui m’a vraiment embrouillé l’autre jour. Ça disait que 80 % des habitants de New York sont des minorités…

Est-ce qu’on ne devrait pas arrêter de les appeler « minorités » quand elles représentent 80 % de la population ? C’est vraiment une attitude de blanc, vous voyez. Vous pourriez emmener un homme blanc en Afrique, et il vous dirait « Regarde toutes les minorités qu’ils ont ici ! ».

Cela m’amène à un projet qui m’occupe actuellement. J’ai commencé à travailler sur le lancement d’un nouveau site pour un client. J’ai regardé les statistiques d’un autre site du même client, et voici ce que j’ai vu :

Position	Navigateurs	Pages vues
1.	Microsoft Internet Explorer 11	12,8%
2.	Mobile Safari 7.0	10,3%
3.	Microsoft Internet Explorer 9	8,2%
4.	Microsoft Internet Explorer 10	6,6%
5.	Google Chrome 36.0	5,4%
6.	Microsoft Internet Explorer 8	5,3%
7.	None	4,4%
8.	Android Browser 4.0	3,7%
9.	Google Chrome 37.0	3,3%
10.	Mozilla Firefox 31.0	2,9%
11.	Google Chrome 32.0	2,0%
12.	Google Chrome 35.0	2,0%
13.	Safari (unknown version)	2,0%
14.	Google Chrome 31.0	1,7%
15.	Mozilla Firefox 30.0	1,6%
16.	Google Chrome 33.0	1,5%
17.	Mobile Safari 6.0	1,5%
18.	Mozilla Firefox 26.0	1,4%
19.	Mozilla Firefox 32.0	1,4%
20.	Google Chrome 34.0	1,0%

Regardez toutes ces minorités ! Aucune version de navigateur ne dépasse les 13 % d’utilisation. Même constat avec les différentes résolutions d’écran, où la plus courante (1024×768) ne représente que 14,3 % d’utilisation. Et tout ça, c’est sur près de deux millions de pages vues le mois dernier.

Je me suis toujours intéressé de près aux statistiques des navigateurs. Et ça me fascine toujours autant de voir à quel point, en à peine dix ans, nous sommes passés d’un marché monopolistique composé majoritairement d’utilisateurs d’Internet Explorer 6 sous Windows XP en 1024×768, à un marché composé d’un ensemble de minorités.

En juin dernier, Fiona Taylor Gorringe soulevait une question intéressante sur son blog : « 3 % des utilisateurs naviguent avec IE9 et 14 % des utilisateurs ont un handicap. Pourquoi on ne se préoccupe seulement que des premiers ? ». Je ne dirais pas qu’on se préoccupe « seulement » des vieux navigateurs et jamais des utilisateurs avec un handicap. Mais j’ai clairement bien plus de demande explicite pour ces premiers que ces derniers. C’est un peu une « attitude de blanc » appliquée au web. Mais les minorités sur le web ne sont plus forcément celles qu’on croit.

La semaine dernière se sont déroulées les conférences de Paris Web. Cet événement tient une place toute particulière dans mon coeur parce que c’est là-bas, il y a à peine deux ans, que j’ai donné mon tout premier lightning talk en public. Depuis, j’ai poursuivi mon petit bonhomme de chemin en tant qu’orateur, de la Kiwi Party l’an dernier à Sud Web en mai dernier. Cette année, j’ai eu l’immense honneur d’être retenu pour donner une conférence de cinquante minutes sur l’intégration d’e-mails à Paris Web. C’était à la fois la conférence la plus importante que j’ai pu donner, mais aussi celle qui m’a le plus déçu. Voici mon retour d’expérience sur ma conférence à Paris Web 2014.

On me traite souvent de masochiste parce que je parle d’intégration d’e-mails. J’ai même ouvert un blog sur le sujet. Mais l’intégration d’e-mails est au coeur de presque chaque projet web (de newsletters commerciales à un e-mail de mot de passe oublié pour l’admin d’un blog). Et pourtant, l’intégration d’e-mails est considérée comme un sujet anecdotique, presque tabou, et que personne ne prend réellement au sérieux. J’avais déjà proposé une conférence sur le sujet à Paris Web en 2013, en vain. N’ayant pas particulièrement d’autre sujet en tête ou me tenant à coeur cette année, j’ai re-proposé la même chose. Et j’ai été retenu.

J’étais alors particulièrement enthousiaste. « Ça y est », me suis-je dit, je vais enfin pouvoir mettre au grand jour tous les problèmes qui entourent l’intégration d’e-mails. Et avec un public comme celui de Paris Web, composé de représentants de tous horizons (W3C, fabricants de navigateurs, grosses boîtes en tout genre), c’est l’occasion idéale pour tenter de faire prendre conscience du problème, et quitte à rêver encore un peu plus, pour initialiser un changement. J’étais d’autant plus ravi quand lors de l’annonce du programme des conférences Paris Web, j’ai découvert que j’aurais l’honneur d’être dans la plus grande salle. C’est le coup de projecteur rêvé pour tenter de faire quelque chose.

J’ai donc commencé petit à petit en juin dernier à rassembler mes notes, mes idées, les horreurs que je peux rencontrer parfois en intégrant ou en recevant des e-mails. Et puis je me suis réellement lancé dans la préparation de ma présentation en septembre dernier. Et c’est à partir de là que ça s’est gâté. Fin septembre, j’ai reçu un e-mail d’un membre de l’équipe de Paris Web m’informant que l’oratrice prévue en même temps que moi ne pouvait plus venir. Ils ont réussi à trouver un remplaçant, mais comme il est anglophone, il faudra qu’il occupe la plus grande salle, qui est équipée pour une traduction audio simultanée. « Crotte », me suis-je dit. Et comme si ça ne suffisait pas, l’orateur en question n’est autre que Vitaly Friedman, le papa de Smashing Magazine, qui venait parler de bonnes pratiques du responsive. « Double crotte », me suis-je dit. Non seulement j’étais relégué dans la plus petite salle. Mais en plus j’allais avoir en face de moi une immense star internationale pour parler d’un sujet autrement plus attrayant que l’intégration d’e-mails.

J’ai poursuivi la préparation de ma présentation, en restant sur mon idée principale de faire une conférence pas trop technique, visant surtout à sensibiliser sur le sujet et toutes ses problématiques. J’ai aussi essayé de rendre ça un minimum divertissant, en y ajoutant des extraits d’un de mes films préférés (j’ai dépensé sans compter). Je me dit toujours que quitte à prendre cinquante minutes à des gens, autant essayer de leur faire passer un moment agréable. Au moins, même s’ils n’apprennent rien, ils ne trouveront pas ça complètement nul.

La première répétition devant mes collègues lundi dernier fut pénible. Je n’étais clairement pas prêt. Et surtout, je tenais tout juste une trentaine de minutes. J’ai passé les deux jours qu’il me restait à retravailler tout ça. Au total, j’ai dû passer l’équivalent de six jours (soit une bonne quarantaine d’heures) à préparer cette conférence.

Le jour J arriva. En parcourant mes slides tout seul dans ma chambre d’hôtel le matin même, je me suis senti prêt. Je tenais la conférence que j’avais envie de donner. J’étais planifié pour passer en deuxième l’après-midi. J’ai choisi d’assister à la conférence me précédant dans la même salle. Autant dire que je n’ai rien suivi. Je repassais mes slides en boucle dans ma tête. Et puis je commençais petit à petit à stresser. La plus petite salle dans laquelle je me trouvais n’était finalement pas si petite. En regardant le public autour de moi, ça faisait quand même beaucoup de monde. « Est-ce que ces gens resterons pour ma conférence ? », me demandais-je. J’ai rapidement eu la réponse. Une fois la conférence terminée, la salle s’est vidée. Je suis monté sur scène pour tout préparer et vérifier que tout fonctionne bien. Et je contemplais la salle désespérément vide. « On attends encore une minute et tu peux commencer », m’a lancé un membre de l’équipe de Paris Web. « Ah ? Mais on attends pas qu’il y ait plus de monde ? En une minute il n’y aura pas beaucoup plus de monde ! » ai-je pensé naïvement. J’ai compté, et on devait à peine être une soixantaine. Je m’attendais à ce que Paris Web soit l’événement où je parle devant le plus de spectateur. C’est en fait devenu l’événement où j’ai parlé avec le moins de spectateur. Je ne me suis pas laissé décourager pour autant, et j’ai lancé mon premier slide. (Non sans ironie, j’avais prévu de démarrer ma conférence en expliquant que l’intégration d’e-mails est un sujet qui fait fuir les intégrateurs.)

Finalement, tout s’est bien passé. J’ai avalé mes 188 slides les uns après les autres. J’ai entendu les gens rire. Je pense en avoir entendu d’autres pleurer en découvrant certaines horreurs. Je n’ai pas eu l’impression de trop bafouiller. Je n’ai pas eu de trou de mémoire. Tout s’est bien passé.

Et puis est arrivée l’obligatoire séance de questions-réponses. Et c’est là qu’est intervenu Daniel Glazman, co-président du groupe de travail sur CSS au W3C. Secrètement, j’espérais qu’il soit présent. À la fin de ma conférence, j’évoquais une réunion de travail du W3C sur l’intégration d’e-mails qu’il avait dirigé en 2007. J’espérais qu’il puisse partager son expérience, et pourquoi pas raviver la flamme pour tenter de relancer quelque chose sur le sujet. Sauf que le discours qu’il a tenu m’a littéralement refroidi. Il a expliqué que les équipes de Microsoft qui travaillent sur le moteur de rendu d’Outlook sont totalement distinctes de celles qui travaillent sur le moteur de rendu d’Internet Explorer. Et les équipes d’Outlook n’ont strictement rien à cirer de la qualité de leur moteur de rendu HTML. Et le W3C n’a aucune légitimité à débattre sur des spécifications liées aux e-mails. Aussi, je suis bien gentil avec ma conférence et mon petit blog sur l’intégration d’e-mails, mais si je veux que les choses changent, il faut absolument que j’écrive en anglais et que je participe au groupe communautaire du W3C. « Soit », ai-je pensé. Je ne suis pas convaincu que les équipes du webmail de La Poste lisent souvent ce genre de ressources… « Merci d’avoir passé six jours pour rien à préparer tout ça. Tu peux rentrer chez toi avec l’assurance que rien ne bougera dans les dix prochaines années » ai-je retranscrit dans ma tête.

Une salle presque vide. Une ambition réduite au néant. Voilà comment ça s’est terminé. Peut-être que je m’étais un peu trop monté la tête, peut-être que je m’étais mis trop de pression, en m’imaginant que j’arriverais faire à bouger les choses… Ou peut-être pas.

Les vidéos de toutes les conférences de Paris Web ont été rendues disponibles en ligne dès le jour même. (Au passage j’en profite pour féliciter toute l’équipe de Paris Web qui réalise un travail colossal et profondément utile, tout ça bénévolement.) À ma grande surprise, ma conférence est en train de vivre une deuxième vie sur le web. Sur le site de Livestream, elle affiche déjà 1891 vues (soit la troisième plus vue après les lightning talks et l’excellente conférence de Christophe Porteneuve sur JavaScript). Et puis surtout, sur Twitter ou ailleurs, j’ai reçu des commentaires très positifs. Et notamment des remarques inattendues comme celle de PinGoo sur mon blog dédié à l’intégration d’e-mails :

Pour info, [ta conférence] a fait pas mal réfléchir nos chefs de projets sur le temps que l’on passait à vouloir faire du pixel perfect sur nos newsletters. Merci !

Il ne m’était même pas venu à l’esprit que des chefs de projet puissent être intéressés par ma conférence (et aussi que des boîtes vendent encore du pixel perfect, mais ça c’est une autre histoire).

Et puis pas plus tard que ce matin, j’ai vu passé ce tweet de David Rousset, évangéliste HTML5 chez Microsoft :

Grâce à l’excellente conf à Paris Web de HTeuMeuLeu, nous allons peut-être enfin améliorer nos newsletters Microsoft !

Bon, à choisir, je préférerais que Microsoft améliore le moteur de rendu HTML d’Outlook. Mais c’est déjà un bon début. Et peut-être que finalement je n’aurais pas fait tout ça pour rien…

On m’a récemment rappelé sur Twitter une pratique qui m’exaspère au plus haut point ces derniers temps. Sur certains sites, le clic secondaire sur des liens est rendu inutilisable. C’est le cas par exemple sur Factornews (j’aime beaucoup Factornews, notamment quand ils font des jeux de mots comme à la fin de cet article).

Dans la première zone d’actualités du site, chaque encart d’actualité est entièrement cliquable. Mais si j’utilise le clic de la molette de ma souris (pour ouvrir le lien dans un nouvel onglet), il ne se passe strictement rien. Si je maintiens appuyé la touche majuscule de mon clavier (pour ouvrir le lien dans une nouvelle fenêtre), mon raccourci sera ignoré et le lien sera ouvert dans la fenêtre courante.

Si le clic se comporte comme ça, c’est parce que ce n’est pas un vrai lien HTML. Ici, pour chaque actualité, seul le titre de l’actualité est dans une balise <a>. Le clic sur le reste de la zone est géré via JavaScript. La volonté de rendre toute la zone cliquable est fortement louable, mais l’annulation du comportement natif d’un navigateur engendrée nuit fortement à l’utilisabilité. Je rencontre ce genre de problèmes régulièrement sur d’autres sites comme Le Bon Coin ou LEGO Ideas.

Ce problème d’intégration est vieux comme le monde. Prenons par exemple le code HTML suivant.

<article class="item">
	<h1><a href="/faire-un-lien-sur-toute-une-zone-en-css">Faire un lien sur toute une zone en CSS</a></h1>
	<p>On m'a récemment rappelé sur Twitter une pratique qui m'exaspère au plus haut point ces derniers temps…</p>
</article>

En XHTML ou en HTML4, une balise <a> ne pouvait contenir que des éléments inline. Du coup, l’utilisation de JavaScript (voire de jQuery) était fortement recommandée pour résoudre ce problème. Aujourd’hui, les quelques lignes suivantes suffiraient à rendre toute la zone cliquable pour tous les éléments .item sur notre page.

document.addEventListener('DOMContentLoaded', function() {
	var items = document.querySelectorAll('.item');
	for(var i=0; i < items.length; i++) {
		var item = items[i];
		item.addEventListener('click', function() {
			var url = this.getElementsByTagName('a');
			if(url.length > 0)
				url = url[0];
			window.location = url;
		});
	}
});

Mais cette solution est à l’origine des problèmes d’utilisabilité qui m’exaspèrent tant.

La spécification HTML5 a changé la donne, et on peut désormais englober dans un <a> n’importe quel élément. On pourrait alors simplement englober tout notre .item d’une balise <a>. Mais ce n’est pas forcément une bonne idée, en particulier pour le référencement où il serait préférable de conserver un contenu texte court et pertinent.

Heureusement, une solution est possible en CSS. En utilisant un pseudo-élément ::before ou ::after, on peut le positionner en absolu par rapport au conteneur principal parent et faire en sorte qu’il occupe tout l’espace. Il faudra bien s’assurer que le conteneur parent en question (.item) ait lui aussi un positionnement non statique afin de restreindre le pseudo-élément du lien. Le code suivant fait alors l’affaire.

.item {
	position:relative;
}

.item a:before {
	content:'';
	position:absolute;
	left:0;
	right:0;
	top:0;
	bottom:0;
	background-color:rgba(0,0,0,0);
}

Ça fonctionne bien dans Chrome, Firefox, Safari et Opera. Pour Internet Explorer (9 et plus), il est nécessaire d’ajouter un fond transparent afin que la zone soit cliquable même au-dessus des autres éléments.

L’inconvénient de cette solution est qu’elle ne s’applique pas sur IE8. Même si le pseudo-élément est bien créé, celui-ci restera non cliquable sous les autres éléments de la zone. Mais si vous pouvez vous permettre d’avoir un fonctionnement dégradé gracieusement sur IE8, cette solution me semble assez élégante.

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.