HTeuMeuLeu

Le mois dernier, j’ai eu la chance d’assister pour la première fois aux conférences de Paris Web. Mais surtout, j’ai eu le privilège de donner pour la toute première fois un lightning talk. J’ai pris beaucoup de plaisir à lire les retours d’autres participants ou orateurs, comme Sophie, Xibe, ou Marie. Alors j’avais envie de partager ma propre expérience.

Un lightning talk, c’est une « conférence éclair » de 4 minutes. Au delà de 4 minutes, le micro est coupé et c’est fini pour vous. A Paris Web, ce sont Daniel Glazman et Robin Berjon (du W3C) qui s’occupent d’organiser la session, où 10 orateurs se succèdent dans un amphithéâtre plein à craquer et une ambiance survoltée. Si vous voulez un aperçu, je vous invite vraiment à regarder les lightning talks de Paris Web 2011.

En juin dernier, j’ai donc répondu à l’appel à orateurs de Paris Web en proposant un sujet de conférence de 15 minutes, et un lightning talk de 4 minutes. Mon sujet de conférence, complètement hors-sujet, a été judicieusement écarté (mais donnera lieu à cet article). Le nombre de propositions de lightning talk étant peu élevés, un nouvel appel à orateurs dédié a été lancé en août. J’ai donc renvoyé ma proposition. Et à ma grande surprise, j’ai été retenu.

Voici mon sujet et l’introduction de mon lightning talk :

Le thème de Paris Web cette année, c’est la fin d’un monde, inspiré par le calendrier Maya. Je ne crois pas en ça ni en aucune religion. Mais si c’est vraiment c’est la fin du monde, je ne suis pas fou, je préfère quand même me confesser au cas où. Je vais en faire profiter tout le monde en confessant 20 pêchés du web.

Je me suis dit que 4 minutes c’était beaucoup trop court pour aborder un sujet sérieux. Alors je me suis dit que j’allais plutôt essayer de faire rire, voire juste sourire (ou même un petit rictus, quoi, vas-y décoince toi). J’avais déjà plutôt une bonne idée des 20 points que j’allais aborder (si vous êtes curieux, vous pouvez voir mes slides). J’ai passé un peu de temps à réfléchir aux commentaires humoristiques ou sarcastiques que je pourrais faire pour chaque point. Mais ce que je ne savais pas, c’est que ça demande un temps démesuré de préparer une conférence de 4 minutes. Stéphane Deschamps, qui donnait lui aussi un lightning talk, résumait très bien la chose une semaine avant :

Plus jamais je ne propose un lightning talk pour @parisweb : plus de boulot qu’une bête conf de 45 minutes, je trouve. Faut être sot.

Et dieu sait qu’il a raison. Le plus long, ce n’était pas tant de réfléchir sur mon sujet, de trouver des remarques rigolotes, ou de préparer mes slides. Non, le plus long, c’était de s’entraîner, encore et encore, tous les jours, pour tenir 4 minutes, et pas une seconde de plus. J’avais préparé des notes, dictant mot pour mot ce que je voulais dire. En répétant tout seul et en lisant mes notes, je finissais à l’aise en 3’50 (« That’s what she says« ). Par contre, la semaine venue, en répétant devant ma copine ou devant mes collègues, je dépassais de justesse les 4 minutes. J’ai donc continuer à m’entraîner, à revoir un peu mon texte, à supprimer quelques passages, à prévoir quelques raccourcis au cas où. Le matin même, en m’entraînant tout seul, à 3’55, je me sentais prêt.

Mais ça c’était sans compter sur le stress. Et je l’ai senti monter, dès le jeudi matin, en arrivant pour la première fois dans l’auditorium d’IBM pour assister à la conférence de Daniel Glazman. « Ok donc là, demain soir, c’est moi qui serait sur scène. » Aïe. « Bon bah, quitte à parler devant tout le monde, autant s’entraîner dès maintenant. » Et j’en ai donc profiter pour poser une question à la fin de sa conférence. J’avais la voix un peu tremblante, je ne trouvais pas tout à fait mes mots, mais ça s’est pas trop mal passé. Mais ça n’a pas empêché le stress de monter petit à petit. Le vendredi a été horrible. J’avais envie d’uriner toutes les 10 minutes. Les conférences de la matinée s’enchaînaient, puis vint la pause déjeuner, et les quelques conférences de l’après-midi. Et là je remettais tout en doute. Est-ce que je vais vraiment réussir à parler devant plus de 400 personnes, dont pleins de grands noms de la profession ? Est-ce que je vais vraiment réussir à faire rire de blagues qui d’habitude ne font rire que moi ? Et est-ce que je vais vraiment faire un sujet d’une liste de 20 mauvaises pratiques ? J’ai horreur des articles de listes. Pourquoi est-ce que j’ai proposé ça ! Argh !

Et puis ça y est, il était bientôt 17h, l’heure pour tous les spectateurs de se rassembler dans l’auditorium principal. Daniel Glazman et Thomas Berjon avaient préparé eux aussi un lightning talk en remplacement d’un désistement de dernière minute. Ils ont ouverts le bal, et puis c’était au tour de Sébastien Delorme et ses « 4 minutes accessibles » (à moins que ce ne soit l’inverse ? mon cerveau était en mode panique à ce moment là, alors je ne me souviens plus trop). Et puis ça a été mon tour. Je suis monté sur scène, j’ai cherché avec Daniel Glazman mes slides.

Et là il s’est passé un truc incroyable et totalement inattendu. Alors que mon premier slide est apparu devant toute la salle (avec dessus inscrit uniquement « Rémi, Intégrateur, @HTeuMeuLeu »), j’ai entendu un « bravo » et quelques applaudissements dans la salle. Alors je me suis peut-être trompé, et peut-être que ça ne m’était pas du tout destiné et qu’il s’est passé un truc dans la salle au même moment. Mais dans mon élan de narcissisme d’orateur éphémère, j’ai pris ça pour moi. Et ça m’a fait un bien fou. (Qui que vous soyez, si vraiment c’était pour moi, alors merci.)

Et c’est ainsi que je suis parti pour 4 minutes. J’ai bafouillé un petit peu dans mon introduction, omettant de dire que j’avais 20 points à présenter. « Merde, t’as oublié de dire qu’il y avait 20 points. C’est important de dire qu’il y en a 20. Vite vas-y dis le tu viens de perdre 3 secondes à réfléchir là. » Et puis tout s’est enchaîné, presque parfaitement. Les développeurs Flash étaient en colère quand j’ai dit « Pardonnez-nous d’avoir utilisé Flash au détriment de l’accessibilité, l’intéropérabilité, la maintenabilité et du référencement ». Les gens ont rit quand j’ai dit que « Comic Sans Ms, c’est une police de Connare ». Daniel Glazman s’est arraché les cheveux quand j’ai dit « Pardonnez-nous pour les préfixes navigateurs ». Et les graphistes étaient en colère quand j’ai dit « Pardonnez-nous d’avoir utiliser Photoshop pour faire du web ». Excellent.

Au final, c’était vraiment une chouette expérience. Je suis conscient que ça n’a pas plus à tout le monde (sérieusement, décoincez-vous), mais les quelques retours que j’ai pu avoir le lendemain aux ateliers ou sur Twitter étaient plutôt positifs. Et du coup, ça me motive beaucoup pour la suite. Pour continuer à tweeter, pour continuer à écrire sur ce blog, pour lancer des projets comme 24 jours de web, ou pour peut-être donner des conférences dans d’autres évènements web en 2013.

Hier soir, je suis tombé avec effroi devant cette bannière publicitaire :

Il y a tellement de choses de travers dans cette publicité. Adobe corrobore l’idée qu’écrire du code, c’est un inconvénient. Adobe véhicule l’idée que le code HTML est une conséquence de la conception web, et non la conception web en elle-même.

Je ne vais pas vous le cacher, je n’aime pas Adobe. Je n’aime pas leur modèle économique désuet qui consiste à vendre des logiciels près de 1000€. Je n’aime pas les interfaces honteuses de leurs logiciels. Je n’aime pas leurs formats propriétaires horriblement conçus. Je n’aime pas leur hypocrisie.

Mais surtout, je pense qu’Adobe n’a jamais rien compris au web.

La récente suractivité d’Adobe au sein du W3C est très intéressante, comme avec les filtres ou les régions CSS, même si ça ressemble aussi à une énième tentative désespérée de reproduire du print sur le web. C’est déjà un comportement moins pathétique que ça.

L’échec de Flash sur mobiles en est un bon exemple de l’incompréhension du web d’Adobe. L’horrible prototype Wallaby en est un autre. Et Muse n’en est qu’un supplémentaire.

Adobe Muse est un des derniers nés du Creative Cloud d’Adobe, disponible en abonnement pour 20$ par mois. La promesse d’Adobe est de pouvoir créer des sites « de qualité professionnelle, conformes aux derniers standards web » « sans savoir écrire de code ». En bon concepteur web, j’ai donc testé rapidement Adobe Muse en créant deux simples pages, avec un simple titre en Helvetica Neue et un paragraphe de Lorem Ipsum. Vous pouvez voir le résultat sur jsFiddle. Voici quelques remarques :

• jQuery est inclus par défaut sur toutes les pages, même si vous n’en avez absolument pas l’utilité, ainsi qu’une plâtrée de JavaScript en dur dans chaque page.
• Mon texte en Helvetica Neue a été transformé automatiquement en image. Ça pourrait être pertinent pour une page unique, mais comme j’utilise cette police ailleurs sur mon site, il aurait été plus pertinent d’opter pour l’inclusion une police en CSS.
• Le code HTML est peu sémantique, et truffé de balises inutiles.
• Le code CSS n’utilise pas tous les préfixes navigateurs (comme les horribles déclinaisons de device-pixel-ratio)
• Quand vous créez un nouveau site dans Adobe Muse, la première chose qu’on vous demande, c’est la largeur et la hauteur de votre site web. Et moi qui croyais que j’allais faire du web.

Je ne vais pas y passer des heures, mais vous avez compris l’idée : on est loin, mais alors très loin du travail qu’un intégrateur professionnel doit réaliser. Alors bien sûr, il y a déjà eu pas mal d’améliorations dans Muse depuis son lancement en 2011. Mais je doute que le logiciel ne parvienne un jour à atteindre la qualité du travail d’un professionnel.

Et c’est là pour moi le problème. Adobe essaie de vendre Muse comme un logiciel professionnel. Muse n’est pas un logiciel professionnel. C’est un logiciel amateur, pour des amateurs, destiné à faire des sites de qualité amateur.

Il y a 6 ou 7 ans, dans la première agence web dans laquelle j’ai travaillé, l’équipe de graphistes a failli me rendre fou. J’avais l’impression que la plupart d’entre eux avaient une culture web proche du néant. Digg ? « Jamais entendu parler, c’est quoi ? » LaFraise ? « Un site de bonbons ? » 37signals ? « Combien de quoi ? » Et encore aujourd’hui, il n’est pas rare que je lise des commentaires de personnes travaillant dans le web se vantant fièrement de ne jamais avoir eu de compte Facebook, ou de ne pas avoir de smartphone. Je trouve ça fou.

Selon moi, pour être un bon concepteur web, vous devez être un bon utilisateur. Et ce, que vous soyez chef de projet, graphiste, développeur, intégrateur, etc.

Être un bon utilisateur, c’est avant tout être curieux. C’est ne pas rechigner à s’inscrire sur un site, ou à installer une nouvelle application pour remplacer votre IDE ou votre logiciel de retouche photo habituel. En tant qu’utilisateur, vous allez peut-être faire de très bonnes découvertes, ou au contraire tomber sur des expériences exécrables. Vous allez peut être tomber sur un e-mail extrêmement bien rédigé. Ou vous allez peut être vous rendre compte que votre grille-pain veut vous tuer. Mais ce qui est bien, c’est que dans les deux cas, ce sera enrichissant pour vous.

Récemment, Jason Fried avait écrit ce tweet :

You know that thing you don’t like? What’s one good thing about it?

Être un bon utilisateur, c’est aussi faire attention au moindre détail. En utilisant un produit que vous n’aimez pas, essayez d’identifier ce que vous n’aimez pas. En utilisant un produit que vous aimez, essayez d’identifier ce que vous aimez. Dans les deux cas, est-ce que vos critiques sont universelles, ou alors purement subjectives et personnelles ? Soyons réalistes : aucun produit n’est universellement parfait. En répondant à ces questions, vous devriez commencer à prendre conscience de la cible des produits que vous concevez.

L’excellent Dustin Curtis a écrit un article plus ou moins sur ce sujet la semaine dernière :

 « Le meilleur » n’est pas nécessairement un produit ou un objet. C’est la récompense d’avoir gagné le combat entre la patience, l’obsession et le désir. Cela prend une quantité de temps déraisonnable pour trouver le meilleur de quelque chose. Cela vous demande de connaître tout à propos du marché du produit, de sa fabrication, de son design, et d’arriver à naviguer parmi les prix trompeurs et le marketing. Cela vous demande de trouver le meilleur objet pour vous-même, ce qui demande de savoir ce qui compte réellement pour vous.

Des gens raisonnables ne passeraient probablement pas leur temps à lire un livre sur l’histoire des couverts, à en acheter vingt ensembles, et à tester le ressenti de chaque ustensile en métal contre leurs dents. Cela paraît fou. Mais qui se soucie des gens raisonnables ?

Si vous êtes une personne déraisonnable, croyez moi : le temps passé à trouver le meilleur de quoi que ce soit vaut totalement la peine. Il vaut mieux avoir quelques objets fantastiques conçus pour vous plutôt que d’avoir de nombreux objets peu fiables conçus pour plaire à tout le monde. Le résultat, être capable de faire confiance aveuglément aux objets que vous possédez, est intensément libérateur.

Être un bon utilisateur, c’est aussi savoir faire la différence entre le suffisant, le bon, et le meilleur.

Un placeholder ne remplace pas un label. Voilà. C’est tout. Je n’ai rien d’autre à ajouter. C’est une déclaration évidente. Et pourtant, j’ai l’impression de visiter de plus en plus de sites qui ont la manie d’utiliser un placeholder en guise de label. Voici quelques exemples aperçus récemment (et ce sont pourtant des gens biens qui ont fait ces sites).

En avril dernier, Roger Johansson résumait très bien le problème d’ergonomie lié à une telle présentation de formulaire :

La description de l’attribut placeholder dans la spécification HTML5 est très claire :

« L’attribut placeholder ne doit pas être utilisé en tant qu’alternative à un label. »

Pourquoi pas ? C’est assez évident. Puisque chaque texte dans l’attribut placeholder est visible uniquement lorsque le champ est vide, une fois que vous avez commencé à écrire quelque chose (ou si une valeur est pré-remplie par le serveur), votre indication a disparu. Vous voulez revenir en arrière et changer quelque chose ? Vous avez intérêt à vous souvenir de ce que le faux label en placeholder disait avant que vous ne commenciez à écrire, sous peine de devoir vider le champ pour voir le label apparaître à nouveau. Et, comme je le disais avant, dans certains navigateurs, le simple fait de placer le focus sur le champ suffit à faire disparaître le placeholder. Ne pas savoir ce que vous êtes censé indiquer dans un champ, ce n’est… pas très bien.

Au delà de ce problème d’utilisabilité, il y a aussi un problème clair d’accessibilité lorsque le champ texte ne propose pas d’alternative autre que le placeholder. Chris Coyier abordait brièvement le sujet dans l’un de ses articles :

C’est tentant d’utiliser un texte en placeholder en remplacement d’un label (en particulier maintenant que certains navigateurs laissent afficher le texte jusqu’à ce qu’on commence à écrire), mais n’utilisez pas de « display:none » et ne supprimez pas les labels. J’ai récemment entendu l’histoire navrante d’une aveugle qui essayait de s’inscrire à l’université, dont le formulaire d’inscription n’avait pas de label. Elle n’avait alors aucune idée de ce qu’il fallait mettre dans les champs. Donc si vous utilisez un texte en placeholder en remplacement d’un label, utilisez une technique accessible pour masquer les labels.

Voici une liste des pour et des contre l’utilisation d’un placeholder en guise de label.

Pour : 

• C’est joli, et on gagne de la place.

Contre :

• Ça diminue l’ergonomie de votre site. Même avec quelques champs, vos formulaires sont plus difficiles à utiliser. Et c’est encore pire sur mobile, où la suppression du texte d’un champs pour faire réapparaître son faux label est une tâche complexe.
• Ça réduit l’interopérabilité de votre site. Oui, ça fonctionne bien sur les machines à l’heure à laquelle vous avez développé votre site. Et oui, vous avez mis un polyfill de placeholder pour les vieux navigateurs. Mais rien ne vous garantit que ça ne fonctionnera encore sur les machines de demain, puisque ce n’est pas fait pour ça à la base.
• Ça détruit l’accessibilité de votre page. Sauf si vous prenez le temps de mettre en place une solution fiable et accessible (note : masquer les labels pour les utilisateurs qui ont JavaScript activés n’est pas une solution fiable et accessible). J’ai une astuce pour vous : une solution existe en HTML, et ça s’appelle un label.
• Ça a un impact sur le temps d’intégration, et donc le coût de votre projet.

Ça ne vous rappelle rien ?

A moins que vous ne détestiez votre métier et que vous ne détestiez les gens qui utilisent votre site web, n’utilisez pas de placeholder en remplacement d’un label.

Ce week-end, j’ai regardé la vidéo du test du Nexus 4 de The Verge. Les tests vidéo de The Verge sont particulièrement bien réalisés, et le Nexus 4 semble être un bon rapport qualité/prix pour un téléphone Android. Mais à un moment, je suis un resté bloqué devant un petit détail de l’interface d’Android. De 4:15 à 4:30 dans la vidéo, Joshua Topolski joue avec le menu de notifications et le nouveau panneau de préférences.

Ma réaction a été de me dire : « Whao, cette animation est vraiment naze ». Alors que je regardais ce passage en boucle pour comprendre pourquoi, mon cerveau n’arrêtait pas de me dire « Ce n’est pas possible. On n’y croit pas une seule seconde. Pitié arrête moi ça ».

A ce stade de votre lecture, il y a quelque chose que vous devez savoir sur moi : j’adore les animations. Et pas juste des courts-métrages animés, comme celui-ci, celui-ci ou celui-là. Mais plus particulièrement, les animations d’interface. Bien réalisé, c’est le genre de détails qui peut totalement transformer et donner vie à une interface. Et dans ce domaine, Apple maîtrise plutôt bien le sujet.

Alors j’ai me suis tourné vers Youtube pour voir des vidéos du centre de notifications d’iOS, et essayer de comprendre en quoi l’animation d’Apple était si différente. Voici une comparaison côte à côte.

iOS et Android utilisent deux métaphores différentes pour cet effet d’apparition, que j’appelerais le tiroir et le parchemin. Quand vous ouvrez un tiroir, le contenu qui se révèle à vous suit le mouvement du tiroir. Pour voir le contenu qui apparaît, il suffit de laisser votre regard fixe vers le haut du tiroir. Quand vous déroulez un parchemin, le contenu qui se révèle à vous reste fixe. Pour voir le contenu qui apparaît, vous devez suivre du regard le déroulement en cours.

Retranscrits dans notre monde informatique, vous comprendrez déjà que l’effet du parchemin est naturellement plus fatigant pour notre cerveau et nos yeux. Mais surtout, sans notion physique et sans indication visuelle du contenu restant à dérouler, je pense que cette métaphore ne fonctionne pas.

Et le problème, c’est que sur le web, on en voit partout, des menus déroulants en parchemin. Voici quelques exemples glânés sur le web et via Twitter (merci @synapse_studio) : Ville d’Agen, Beats by Dr Dre, World Trade Center de Lyon, Highcharts JS, La cinémathèque française.

Alors cela ne signifie pas qu’il faut bannir les animations en parchemin. Mais ça signifie que si vous tenez vraiment à faire une animation en parchemin, vous allez devoir faire quelques kilomètres en plus pour que ça fonctionne vraiment. Récemment, Justin Windle a publié Makisu, une impressionnante démonstration de menu déroulant en CSS 3D. Je pense que cette animation rend particulièrement bien car elle est très détaillée. Mais le rendu est du coup visuellement un peu trop lourd et beaucoup trop caractérisé pour une utilisation réelle sur un site institutionnel.

Je pense que la propagation de cette animation est dûe en partie à jQuery. En jQuery, pour faire une animation en parchemin, il suffit d’appeler la fonction slideDown() sur n’importe quel élément. Et c’est tout. A l’opposé, pour faire une animation en tiroir, il faudra surcharger son code HTML pour avoir un conteneur avec une hauteur souple et un overflow:hidden, pour ensuite jouer sur un margin-top négatif sur un élément global à l’intérieur. Ce n’est pas forcément plus compliqué, mais ça demande plus de travail, et plus de réflexion. Certains sites, comme Converse, font ça pas trop mal.

Après jQuery, il devient désormais plus facile que jamais de faire des animations dans une page web. Mais comme j’aime à le répéter : juste parce que vous pouvez le faire ne signifie pas que vous devez le faire. Voici quelques conseils pour animer vos sous-menus :

1. Une animation sert à attirer l’attention et à renforcer la compréhension d’une action. Si vous n’êtes pas sûr de ce que vous faites, ou si vous n’avez pas beaucoup de temps pour travailler sur ces animations, alors ne faites rien. Une mauvaise animation va rendre votre site pire que sans animation.
2. A moins que vous n’ayez de solides arguments, privilégiez une animation en tiroir (plus reposante visuellement), et pas en parchemin (plus difficile à suivre pour notre cerveau, et beaucoup plus complexe à mettre en place pour être réellement efficace).
3. Ne répétez pas votre animation à l’apparition de chaque sous-menu quand on passe d’un onglet à un autre. Votre animation doit se jouer à la première ouverture d’un sous-menu, et puis c’est tout. Cela signifie que même si vous utilisez des animations CSS, vous aurez besoin d’un peu de JavaScript pour détecter ce comportement. Si cela vous semble trop contraignant à mettre en place, alors ne faites pas d’animation.

S’il y a une chose particulièrement importante que vous devez savoir à propos de l’intégration, c’est qu’il s’agit avant tout de faire des choix. Tout le temps. Choisir la bonne balise, le bon nom de classe, la bonne méthode de positionnement, le bon framework, etc… En mai dernier, j’abordais déjà (maladroitement) ce sujet dans mon article sur les contraintes de l’intégration. Mais l’importance de nos choix en intégration m’est revenu à l’esprit à travers deux exemples.

A Paris Web, j’ai pu assister au très bon atelier de Jean-Pierre Vincent sur la performance sur les sites mobiles. Ce qui m’a marqué, c’est la dualité entre certaines bonnes pratiques. Par exemple, afin d’améliorer le temps de chargement de votre site, il est conseillé de diminuer le nombre de requêtes. Une bonne pratique consiste alors à privilégier l’emploi de propriétés CSS pour éviter d’utiliser des images pour des effets graphiques (bords arrondis, ombres, fond en dégradés). Sauf que l’utilisation de ces propriétés a un coût important sur le temps de rendu de la page une fois téléchargée côté client. En optimisant d’un côté, vous alourdissez de l’autre. Quel choix allez vous faire ?

Et puis la semaine dernière, il y a eu ce tweet de Raphaël Goetter : « WebPerf says : « id is the best CSS selector »; OOCSS says : « don’t use id ». Well.« . Si l’impact bénéfique sur la performance d’un id n’est plus vraiment d’actualité, son utilisation reste toujours sujet à débat. En utilisant des ids dans votre HTML, vous aurez potentiellement une page plus légère. Mais vous serez contraint d’alourdir vos sélecteurs CSS, en compliquant au passage la maintenabilité de votre code. Quel choix allez vous faire ?

Si certains choix vont être faits en réponse à des objectifs clairs de votre site, d’autres vont plutôt relever de votre personnalité d’intégrateur. En mai dernier, je résumais  :

S’il est assez naturel de voir la personnalité d’un graphiste transparaître à travers ses créations, il en va de même pour un intégrateur. Mais contrairement à un graphiste, le travail de l’intégrateur est souvent invisible, et beaucoup plus difficile à juger.

L’intégration, c’est faire des choix. Mais souvent, il ne s’agit pas forcément de faire le meilleur choix, mais plutôt de faire le moins pire.

Après 3 trimestres exceptionnels, Apple a présenté hier ses résultats pour le quatrième trimestre 2012, clôturant ainsi son année fiscale.

La société a publié un chiffre d’affaire pour le trimestre de 36 milliards de dollars et un bénéfice net de 8,2 milliards de dollars, ou 8,67$ par action diluée. […]

La société a vendu 26,9 millions d’iPhones au cours de ce trimestre, soit une hausse de 58% en comparaison au même trimestre il y a un an. Apple a vendu 14 millions d’iPads au cours de ce trimestre, soit une hausse de 26% en comparaison au même trimestre il y a un an. La société a vendu 4,9 millions de Macs au cours de ce trimestre, une hausse de 1% en comparaison au même trimestre il y a un an. Apple a vendu 5,3 millions d’iPods, une baisse de 19% en comparaison au même trimestre il y a un an.

Si on additionne les chiffres de l’année 2012, ça donne :

• 125,04 millions d’iPhones vendus (37,04 + 35,1 + 26 + 26,9)
• 58,23 millions d’iPads vendus (15,43 + 11,8 + 17 + 14)
• 18,1 millions de Macs vendus (5,2 + 4 + 4 + 4,9)
• 35,2 millions d’iPods vendus (15,4 + 7,7 + 6,8 + 5,3)

Avec 41,73 milliards de dollars de bénéfices, Apple enregistre ainsi le plus gros record de bénéfices depuis 2008 (détenu alors par ExxonMobile). De manière assez amusante, la seule société d’électronique qui s’en sort aussi bien en ce moment, c’est Samsung.

Je le dis et je le répète : nous vivons dans le monde d’Apple. Je suis curieux de voir combien de temps cela va durer, et ce que cela va donner en 2013.

La conférence de Véronique Marino à Paris Web la semaine dernière, Comprendre l’autisme pour améliorer les projets transmédias, était pour moi une très bonne surprise. Certes, ce n’était pas une grande conférence ni du grand spectacle, comme ont pu l’être les conférences de Mike Monteiro ou Jake Archibald. Mais c’était une conférence avec un sujet important, le genre de sujet qu’on garde bien dans un petit coin de sa tête et qui mûrit en nous tout doucement.

La conférence tournait beaucoup autour de la description de l’autisme et les effets du handicap, mais aussi sur les solutions pour accompagner les autistes. Les exemples n’étaient pas nombreux, mais pourtant bien marquants.

Par exemple, les autistes comprennent difficilement le langage imagé. Donc si vous dîtes à un autiste que vous allez « manger un buffet froid », il comprendra plutôt que vous allez manger le meuble de votre grand-mère sans le réchauffer. Et ça, ça pose évidemment des problèmes dans la vie quotidienne, notamment face à des pictos.

Alors qu’ils sont d’usage courant, un autiste ne comprendra pas les pictogrammes de toilettes avec un homme ou une femme. Pour lui, c’est juste un homme ou une femme. Rien n’indique qu’il s’agit de toilettes dans le pictogramme en lui-même. Ça laisse à réfléchir sur les pictogrammes qu’on utilise sur nos sites (et ça rejoint l’autre excellente conférence de Sébastien Desbenoit sur l’utilisation des pictos).

L’autisme est un sujet que je connais peu, mais qui m’attire beaucoup. En début d’année, j’étais tombé sur cet article intitulé « Attention to Detail » qui m’avait particulièrement marqué (et il se base sur des exemples de Toy Story et Plants vs Zombies, donc allez le lire, vraiment).

Il y a une société appelée Specialist People Foundation qui traite abondamment des problèmes dans ce domaine. Elle emploie des personnes atteintes d’autismes et autres troubles similaires, et s’appuie sur la différente nature de perception de ses employés pour s’attaquer à une variété de problèmes. J’aime beaucoup de chose à propos de cette organisation, mais je pense que le plus impressionnant est comment ils ont efficacement créé une force de quelque chose qui est perçue comme une faiblesse.

« Nos consultants ont une passion pour le détail sans égal, et apportent des compétences uniques à des tâches pour lesquelles les employés de la plupart des sociétés ont moins de motivation à réaliser, laissant ainsi plus de places à des erreurs. Les caractéristiques uniques de l’autisme font que nos consultants apprécient vraiment des tâches que la plupart des employés trouvent ennuyeuses, répétitives ou difficiles dues au niveau de détail et de concentration requis.« 

En attendant la vidéo de Paris Web, vous pouvez consulter ses slides, ou regarder la vidéo de sa conférence donnée l’année dernière à Web-In à Montréal.

Suite à Paris Web la semaine dernière, j’avais très envie de vous parler de la conférence de Jake Archibald : Application cache is a douchebag. J’avais vu passer les slides de sa conférence en début d’année et j’avais trouvé ça plutôt rigolo. J’avais tort. C’est carrément excellent.

Jake Archibald prend un sujet en apparence assez simple, le cache d’application en HTML5, et explique en détails à quel point en pratique c’est complexe. Et le tout en enchaînant des blagues à un rythme soutenu tout au long de sa conférence. A tel point que Jake Archibald ferait passer Le comte de Bouderbala pour Anne Roumanoff.

Voici comment sa conférence débute.

A l’époque des modems 56k, on utilisait seulement Internet pour des courtes durées. Vous vous connectiez, vous vérifiez vos e-mails, et puis vous partiez. Mais maintenant on est presque toujours connecté. Et ça transforme le fait de ne pas avoir de connexion en un gros problème. Ceux qui comme moi doivent utiliser une connexion à l’étranger savent de quoi je parle. Quand je me connecte depuis l’étranger, je me sens comme un accro au jeu. A chaque fois que je me connecte, je sais que je dépense de l’argent. Mais je ne peux pas m’en empêcher. Je dois savoir ce qu’Internet dit sur mon dos ou ce qu’il se passe. Mon téléphone émets un petit son quand j’utilise des données en 3G depuis l’étranger. Mais je n’en ai pas vraiment besoin car j’arrive presque à entendre les bouchons de Champagne sauter à chaque fois que j’utilise un méga-octet.

Et ma propre dépendance me dégoûte vraiment. Il y a un moment, là où je travaillais, je devais aller faire la grosse commission aux toilettes. Il y avait cinq cabinets à l’intérieur. Malheureusement, les quatre premiers étaient occupés. En général ce n’est pas grave, je n’ai besoin que d’un cabinet. Mais je savais par mes expériences passées que le Wi-fi du bureau n’allait que jusqu’au quatrième.

J’y ai réfléchi un instant et je me suis dit : « Non. Je trouve cela totalement inacceptable. » Et j’ai fait demi-tour et je suis retourné à mon bureau et j’ai attendu.

Je suis devenu quelqu’un qui a besoin d’une connexion Internet pour aller faire caca.

Et c’est ainsi que Jake Archibald nous emmène dans les méandres du fonctionnement du cache d’application, en personnifiant cette spécification, et en la présentant comme un trou-du-cul (ou plus précisémment un « douchebag« ). Le genre de personne qui dirait « I’m going to turn your offline user experience from sucks-ass… to success !« .

J’étais mort de rire quand Jake expliquait qu’il ne faut surtout jamais changer le nom de fichier de manifeste. En faisant ça, vous rentrez dans une boucle infinie ou vos anciens utilisateurs ne recevront plus jamais aucune mise à jour.

J’ai fait ça sur Sprite Cow de façon totalement idiote. Et j’ai mis 30 minutes à me rendre compte de ce que j’avais fait et de pouvoir le corriger. D’après Google Analytics, 20 personnes ont visité le site pendant cette période. Ces 20 utilisateurs ne recevront plus jamais la moindre mise à jour du site. Jamais, jamais.

Ils vivent maintenant la vie de développeurs Drupal. Tous les autres s’amusent à faire des trucs nouveaux super cools, et eux sont coincés avec la vieille même merde.

Vous l’aurez compris, je vous recommande vraiment de voir cette conférence. Si la vidéo de Paris Web n’est pas encore en ligne, vous pourrez en trouver quelques unes dans d’autres événements, comme celle-ci à Mobilism 2012. Les slides de sa conférence sont eux déjà disponible sur le site de Paris Web. Et vous pouvez également lire son article du même nom chez A List Apart publié en mai dernier.

La semaine dernière, j’ai eu la chance d’assister aux conférences de Paris Web. Je vais essayer de revenir cette semaine sur les conférences qui m’ont le plus marqué. L’une des principales têtes d’affiche était Mike Monteiro, avec sa conférence intitulée How Designers Destroyed the World.

J’avais découvert Mike Monteiro via sa conférence « Fuck you, pay me« , puis via ses podcasts sur Mule Radio Syndicate, ou encore son travail via sa société Mule Design Studio sur AllThingsD ou Evening Edition, et en avril dernier son livre « Design Is a Job » (horriblement traduit en français en « Métier web designer« ).

Comme le nom de sa conférence l’indique, Mike Monteiro nous raconte comment les designers ont détruit le monde. Comment les designers ont détruit le monde en se préoccupant de projets futiles plutôt que de s’attarder sur des choses qui comptent vraiment. A-t-on vraiment besoin de plus de 60 projets de pochettes pour iPad sur Kickstarter ? A-t-on vraiment besoin de cette veste imaginée par des étudiants du MIT qui se gonfle quand on reçoit un J’aime sur Facebook ?

Mike tourne ensuite toute sa conférence autour d’un exemple concret de mauvais design qui a ruiné la vie d’un être humain. A cause des préférences incompréhensibles sur la vie privée de Facebook, Bobbi Taylor a révélé malgré elle son homosexualité, jusqu’alors tenue secrète, à son père. Problème : son père est un trou du cul et l’a menacée de la renier et s’est mis à insulter les gens de sa chorale gaie sur Facebook. Comme le dit Mike, « Je suis père d’un garçon, et ceci n’est pas une façon de traiter vos enfants ». Vous pouvez lire l’article original du Wall Street Journal ou en français sur les blogs du Monde.

Mike enchaîne alors les conseils pour éviter de se retrouver dans une telle situation. « Décide d’être le connard qui va faire bouger les choses. Personne ne te donnera la permission. » (piqué chez Les Intégristes). Et surtout : si vous n’êtes pas d’accord avec ce qu’on vous demande de faire, dites non. Quittez votre boulot. Mais arrêtez de faire du mauvais travail.

« You are responsible for the work you put into the world » est à mon avis la phrase qui résume le mieux sa conférence (thème qu’on retrouve largement dans son livre).

Ce que j’ai particulièrement aimé, c’est que cela ne concerne vraiment pas que les designers au sens graphique du terme. Cela concerne tous les créateurs. Les développeurs, les intégrateurs, les entrepreneurs, les chefs de projet. Si vous créez quelque chose, que ce soit une affiche, un site web, un article sur votre blog, une vidéo sur Youtube, vous êtes responsable de l’impact que cela aura sur les gens.

Reste que certains conseils de Mike sont vraiment propres à la culture américaine, et ça s’est senti pendant les questions-réponses. Aux États-Unis, vous pouvez quitter votre boulot un lundi soir et trouver un autre travail le mardi matin, comme si de rien n’était. En France, on préfère vous garder deux mois en préavis au cas où, même si vous avez manifestement montré votre désintérêt dans votre boîte en démissionnant.

Ça n’en reste pas moins une très bonne conférence, et un très bon moment. L’ambiance dans la salle était électrique, presque religieuse. Alors oui Mike Monteiro lisait son texte sur son écran. Oui, il utilise l’effet de fumée de Keynote dans ses slides. Ça n’en reste pas moins un très bon spectacle avec quelques bonnes idées à retenir et à mettre en pratique.

En attendant que la vidéo de la conférence ne soit en ligne (si on en croit les années précédentes, ce ne sera pas avant avril prochain), je vous recommande vraiment le livre « Design is a job« . Je vous invite également à voir sa conférence « What Clients Don’t Know (… And Why It’s Your Fault) » donnée au TYPO Talks en mai dernier, où Mike raconte comment il s’est acheté un vélo, et comment éduquer les clients en leur expliquant notre travail.

J’adore les petites erreurs du quotidien, celles qui résultent d’une petite incompréhension ou d’un manque d’interrogation. Je suis retombé sur ma petite collection d’exemples d’erreurs glanées sur le web, issues de demandes prises un peu trop… littéralement.

Comme par exemple, quand vous demandez à un votre collègue d’écrire sur votre camion citerne « Diesel fuel » et « No smoking » en arabe.

Ou quand vous demandez à votre boulanger un gateau avec écrit dessus « Meilleurs voeux Suzanne » et en-dessous de ça « Tu vas nous manquer ».

Ou quand votre collègue devait traduire un panneau anglais en gallois, et qu’il a traduit votre première réponse à son mail de demande du texte à traduire (qui manque de bol était « Je ne suis pas au bureau pour le moment. Envoyez tout message à traduire. »).

Ou quand vos ouvriers ont creusé un trou dans votre plafond de la forme des nuages de révision d’AutoCAD.

Ou quand vos ouvriers ont pris la flèche vers l’info-bulle de votre plan pour une découpe dans vos escaliers.

Ou quand l’acteur principal de votre série hurle à voix haute la didascalie censée lui indiquer son intonation (en l’occurrence, « disappointed« ).

Des erreurs, ça arrive à tout le monde. Mais celles-là, je prie pour les éviter.

Dans iOS6, Safari intègre une nouvelle fonctionnalité assez discrète : les smart banners. Une smart banner (ou « bannière intelligente », en opposition à toutes ces bannières stupides), c’est une bannière qui vient s’ajouter en haut de votre site dans Safari pour mettre en avant votre application iOS.

Pour ce faire, il vous suffit d’ajouter la balise meta suivante avec l’identifiant de votre application, n’importe où dans votre code HTML. Pour obtenir l’identifiant de votre application, vous pouvez utiliser l’iTunes Link Maker d’Apple.
<meta name="apple-itunes-app" content="app-id=562772514" />

La bannière affiche alors l’icône, le nom, le développeur, la note et le prix de l’application, ainsi qu’un lien pour y accéder depuis l’App Store et une croix pour faire disparaître définitivement la bannière. Voici le rendu final sur une page web (avec ici l’excellentissime Devil’s Attorney).

Si vous faites parti du programme d’affiliation d’Apple, vous pouvez également ajouter votre identifiant d’affilié comme suit :

<meta name="apple-itunes-app" content="app-id=562772514, affiliate-data=partnerId=42&siteID=darkmaul" />

Sur son blog, David Smith détaille également l’existence d’un paramètre supplémentaire permettant de passer une URL à votre application dès son premier lancement, pour afficher par exemple un contenu spécifique.

Je ne suis en général pas friand de ce genre de gadget purement marketing, mais c’est clairement beaucoup moins intrusif que des alertes JavaScript ou des lightbox maison. Et ça vous évite un peu de tomber dans les pratiques mobiles du Mal.

S’il y a bien une spécification qui m’excite plus que tout parmi les nouveautés de HTML5 et CSS,  c’est bien celle des filtres CSS. Cette spécification regroupe deux notions importantes : les filtres par défaut, et les filtres personnalisés. En voici un rapide aperçu.

La propriété filter permet d’appliquer des effets à n’importe quel élément d’une page web. Par défaut, la spécification prévoit plusieurs fonctions de filtres qui vont jouer sur le rendu de l’élément. On retrouve des filtres de couleurs (grayscale, sepia, saturate, invert, brightness, contrast, opacity) ou des filtres de transformation (blur, drop-shadow). Prenons l’exemple simple du filtre de niveau de gris (grayscale). Ce qui nécessitait un rendu côté serveur ou via un plugin il y a 5-6 ans, puis quelques lignes de JavaScript en Canvas il y a 2-3 ans, est désormais devenu un one-liner.

filter:grayscale(1);

La cerise sur le gateau, c’est que comme il s’agit de propriétés CSS à valeur numérique, vous pouvez les animer grâce à la propriété transition ou aux déclarations d’animation CSS.

Parmi ces filtres natifs, la fonction drop-shadow est particulièrement intéressante. Contrairement à la propriété box-shadow (qui se contente de faire une ombre rectangulaire autour d’un élément), le filtre CSS drop-shadow s’adapte aux formes. Cette démo issue de cet article chez Bricss illustre très bien la différence entre les deux propriétés.

Mais là où ça devient vraiment intéressant, c’est avec les filtres personnalisés, connus aussi sous le nom de shaders CSS. Un shader, dixit Wikipédia, est « une suite d’instructions donnée à un ordinateur, utilisé en image de synthèse, pour paramétrer une partie du processus de rendu réalisé par une carte graphique ou un moteur de rendu logiciel ». Présentés pour la première fois par Adobe en octobre 2011 et décrits comme « des effets cinématiques pour le web« , les shaders CSS ont rejoint la spécification des filtres en août dernier.

Pour créer un shader CSS, pas de JavaScript, mais du GLSL (langage proche du C déjà utilisé en 3D avec OpenGL, WebGL ou DirectX). AlteredQualia a récemment écrit un article très complet pour débuter avec les shaders CSS. Concrètement, il existe deux types de shaders :

• Les vertex shaders, qui permettent de déplacer et déformer les sommets d’un polygone
• Les fragment shaders, qui permettent de modifier le rendu des pixels d’un objet

J’ai récemment commencé à lire Switch : how to change things when change is hard de Chip et Dan Heath. Comme son titre l’indique, le livre explique comment parvenir à changer des choses quand le changement semble impossible. Et pour ça, tout le livre tourne autour d’une analogie sur notre cerveau : l’éléphant et son cavalier. Voici un extrait du premier chapitre.

Le savoir conventionnel en psychologie est que le cerveau a deux parties indépendantes qui travaillent en permanence. Premièrement, il y a ce qu’on appelle le côté émotionnel. C’est la part de vous qui est instinctive, qui ressent de la douleur et du plaisir. Deuxièmement, il y a le côté rationnel, aussi connu comme le système réflectif ou la conscience. C’est la part de vous qui délibère et analyse et se penche vers l’avenir.

Ces dernières décennies, les psychologues ont beaucoup appris sur ces deux systèmes, mais bien sûr l’Homme a toujours été conscient de la tension. Platon disait que dans nos têtes nous avons un cocher rationnel qui doit maîtriser un cheval indiscipliné qui « répond à peine à la cravache et l’aiguillon combinés ». Freud écrivait à propos de l’identifiant égoïste et du superégo consciencieux (et aussi l’égo, qui sert d’intermédiaire entre les deux). Plus récemment, des économistes comportementaux ont surnommé les deux systèmes le Planificateur et le Faiseur.

Mais, pour nous, la tension du duo est mieux capturée par une analogie utilisée par le psychologue de l’Université de Virginie Jonathan Haidt dans son fantastique livre The Happiness Hypothesis. Haidt dit que notre côté émotionnel est un Éléphant et notre côté rationnel son Cavalier. Perché en haut de l’éléphant, le cavalier tient les rênes et semble être le chef. Mais le contrôle du cavalier est précaire car le cavalier est tout petit à côté de l’éléphant. A chaque fois que l’éléphant de six tonnes et le cavalier sont en désaccord sur la direction à prendre, le cavalier va perdre. Il est totalement soumis.

La plupart d’entre nous sont bien trop familiers avec des situations dans lesquelles notre éléphant domine notre cavalier. Vous avez déjà vécu cela si vous vous êtes déjà reveillé en retard malgré votre réveil, si vous avez déjà trop mangé, rappelé votre ex à minuit, procrastiné, essayé d’arrêter de fumer et échoué, laissé tomber le sport, si vous vous êtes déjà mis en colère et avez dit quelque chose que vous regrettiez, abandonné vos cours d’espagnol ou vos leçons de piano, refusé de parler lors d’une réunion parce que vous aviez peur, et ainsi de suite. La bonne nouvelle c’est que personne ne compte les points.

La faiblesse de l’éléphant, notre côté émotionnel et instinctif, est claire : il est fainéant et capricieux, recherchant souvent la récompense à court terme (un cornet de glace) plutôt qu’à long terme (perdre du poids). Quand les efforts pour changer échouent, c’est habituellement la faute de l’éléphant, puisque les types de changements que nous voulons impliquent généralement des sacrifices à court terme pour une récompense à long terme. (On réduit les dépenses aujourd’hui pour obtenir un meilleur bilan l’année prochaine. On évite le cornet de glace aujourd’hui pour une meilleure silhouette l’année prochaine.) Les changements échouent souvent car le cavalier ne peut simplement pas tenir l’éléphant sur la route suffisamment longtemps pour atteindre la destination.

La faim de l’éléphant pour une gratification instantanée est l’opposée de la force du cavalier, qui a habilité de penser à long terme, de planifier, de penser au delà du moment (toutes ces choses que votre animal de compagnie ne peut pas faire).

Mais ce qui peut vous surprendre est que l’éléphant a aussi d’énormes forces et que le cavalier a des faiblesses handicapantes. L’éléphant n’est pas toujours le mauvais garçon. L’émotion est le truc de l’éléphant : l’amour et la compassion et la sympathie et la loyauté. Cet instinct féroce que vous avez pour protéger vos enfants du mal, ça c’est l’éléphant. Ce raidissement de la colonne vertébrale que vous ressentez quand vous devez vous défendre, ça c’est l’éléphant.

Et encore plus important si vous regardez un changement en cours : c’est l’éléphant qui fait avancer les choses. Progresser vers un but, qu’il soit noble ou grossier, demande l’énergie et la conduite de l’éléphant. Et cette force est le miroir de la plus grande faiblesse du cavalier : faire du surplace. Le cavalier a tendance à suranalyser les choses et à surréfléchir. Il y a des chances pour que vous connaissiez des gens qui ont le problème du cavalier : votre ami qui peut agoniser pendant 20 minutes avant de choisir ce qu’il va manger pour dîner; votre collègue qui peut se remuer les méninges pour trouver de nouvelles idées pendant des heures mais ne semble jamais pouvoir prendre la moindre décision.

Si vous voulez changer les choses, vous devez attirer les deux. Le cavalier fournit le planning et la direction, et l’éléphant fournit l’énergie. Donc si vous atteignez les cavaliers de votre équipe mais pas les éléphants, les membres de votre équipe auront la compréhension sans la motivation. Si vous atteignez leurs éléphants mais pas leurs cavaliers, ils auront la passion mais sans direction. Dans les deux cas, les défauts peuvent être paralysants. Un éléphant réticent et un cavalier qui fait du surplace peuvent tous deux faire en sorte que rien ne change. Mais quand les éléphants et les cavaliers bougent ensemble, le changement peut arriver facilement.

C’est ma nouvelle analogie préférée.

Cette semaine chez Le Train de 13h37, Anthony Ricaud (développeur web chez Mozilla) parle des dangers d’une culture mono-navigateur dans le monde mobile. Je suis globalement d’accord avec son propos et l’importance des standards sur le web. Par contre, je ne suis pas d’accord avec une partie de son article sous-titrée « Sans Firefox, pas d’iPhone ».

Nous sommes en 2004, Internet Explorer domine le marché des navigateurs, Netscape n’est plus. Après une compétition acharnée, la fameuse Browser Wars, le navigateur avec les fonctionnalités les plus intéressantes a gagné. Oui, c’était bien Internet Explorer le meilleur navigateur à ce moment-là.

Les développeurs web sont vraiment ravis de pouvoir utiliser tous les raffinements d’Internet Explorer 6 : font-face, AJAX, innerHTML. Malheureusement, la plupart de ces fonctionnalités sont inopérantes dans les navigateurs alternatifs de l’époque (Mozilla Suite, Opera, etc.), ce qui limite forcément leurs parts de marché : les utilisateurs pensent qu’ils sont défaillants et retournent donc dans le confort du navigateur dominant.

Imaginons maintenant que l’iPhone sorte dans ce contexte de 2004. Un téléphone mobile révolutionnaire, un iPod à écran panoramique doté de commandes tactiles et un appareil de communication sur Internet innovant.  » Appareil de communication sur Internet innovant  » ?
Avec si peu de sites compatibles ? Je ne crois pas : la plupart des sites incluent du code spécifique à Internet Explorer, rendant Safari iPhone bien inintéressant. Et franchement, un iPod qui passe des coups de fil sans un vrai navigateur, ça n’aurait pas valu ce prix-là. Et toute la révolution de l’internet mobile qui a suivi aurait été bien retardée.

Heureusement, entre la domination d’Internet Explorer et la sortie de l’iPhone, il y a eu un nouvel arrivant qui a changé la donne : Firefox.

La thèse d’Anthony, c’est qu’Apple n’aurait jamais sorti l’iPhone dans un contexte où des millions de sites n’auraient pas fonctionné dessus. Mais c’est pourtant exactement ce qu’ils ont fait. Et ce, délibérément.

Quand Apple a présenté l’iPhone en 2007, le monde s’insurgeait de l’absence de Flash. Et à raison : en 2007, le paysage des navigateurs était représenté principalement par IE6, IE7, et Firefox 2, un peu d’Opera et de Safari (mais pas encore de Chrome). On était alors très loin de l’omniprésence de HTML5 actuelle. Et Flash était alors un standard de facto. Non seulement Flash était utilisé pour lire des vidéos ou jouer à des jeux, mais aussi pour quasiment n’importe quel type d’animation et de contenu : carrousels, menus, sites full-flash. L’horreur. En refusant à Adobe de porter son plugin sur iPhone OS, Apple a délibérément choisi de rendre incompatible (en partie ou totalement) des millions de sites web. C’était une véritable plaie pour les utilisateurs et les auteurs des sites en question, mais l’histoire prouvera que c’était la bonne décision.

Et l’iPhone n’était pas un cas isolé. En 2010, avec l’iPhone 4, Apple a introduit pour la première fois ses écrans Retina, avec des écrans d’une résolution 2x supérieure. Cette année, pour la première fois, Apple a sorti un Macbook Pro avec un écran Retina 13″ d’une résolution de 2880x1800px. Problème : avec une telle résolution, tous les contenus non adaptés apparaissent atrocement flous. Avec ses écrans Retina, Apple a rendu des millions de sites web moches. Mais la bonne nouvelle, c’est que ça pousse les développeurs consciencieux à revoir leurs pratiques. Ce qui était il y a encore quelques années une pratique courante d’avoir du texte dans des images est devenue une pratique à éviter à tout prix. Et même si on est encore au balbutiement de l’adaptation de sites pour écrans Retina, la disparition de textes en image est plutôt une bonne chose pour le web.

Il y a quelques années, je me souviens d’avoir lu un tweet (dont j’ai oublié l’auteur) qui disait quelque chose comme ça :

Avec l’iPhone, Apple a fait plus pour les standards du web que Mozilla en 5 ans.

C’est assez catégorique, mais je pense que c’est vrai. En supprimant Flash de ses appareils, Apple n’a pas laissé le choix aux développeurs web que de se conformer à des standards pour laisser leur contenu visible. Je suis convaincu que si Flash avait été présent sur iPhone dès le départ, les standards du web n’aurait jamais autant d’écho qu’aujourd’hui.

Mozilla pousse les standards et les bonnes pratiques du web par l’évangélisme. Apple pousse les standards et les bonnes pratiques du web par la dictature.

Les deux méthodes portent leurs fruits, mais clairement pas aussi rapidement. Et si on devait attendre comme Mozilla que plus aucun site n’utilise Flash pour bloquer le plugin, il y a de fortes chances pour que ce jour n’arrive jamais.

Il y a quelques semaines, Charles de UXUI a écrit un chouette article sur l’expérience utilisateur du valet de piscine. Ça m’a rappelé des souvenirs de sorties piscine à l’école primaire. Ça m’a rappelé à quel point cet objet est mal conçu, et a sans doute contribué au fait que j’ai une certaine aversion pour les piscines municipales. Mais ça m’a surtout rappelé à quel point bon nombre d’objets du quotidien sont mal fichus.

Voici ma petite expérience de simple utilisateur avec un produit du quotidien : le grille-pain.

J’aime bien le pain grillé. J’aime l’odeur du pain grillé le matin. J’aime le bruit de mon couteau qui tartine mon pain tout juste grillé. J’aime le goût du pain encore chaud craquant dans ma bouche. Pourtant, c’est un plaisir que je me réserve assez rarement.

Et pour cause : je déteste mon grille-pain. Voici mon grille-pain actuel.

C’est un grille-pain plutôt classique, vendu environ 30€. On trouve 5 boutons sur ce grille-pain. Un bouton « pressoir » pour abaisser le pain une fois inséré et démarrer le grillage du pain, un bouton rotatif pour sélectionner le thermostat selon 6 positions, un bouton pour activer un mode décongélation, un bouton pour activer un mode réchauffage, et un bouton stop. A noter qu’en 6 mois, je ne me suis jamais servi de ces trois derniers boutons.

Quand vous allez dans un magasin spécialisé en électro-ménager pour acheter un grille-pain, vous serez confronté à des dizaines de modèles du même genre. Vous aurez le droit à une grande variété de design, couleurs, prix, et fonctionnalités annexes. Mais fondamentalement, un grille-pain c’est une fente pour y déposer du pain, un bouton de mise en marche, et un bouton de thermostat.

C’est extrêmement simple. Et pourtant, ça me pose plusieurs problèmes à l’utilisation :

• Je n’ai aucune indication sur la durée du grillage. Avec l’habitude, j’arrive a peu près à estimer cette durée selon le thermostat. Mais quand j’arrive dans ma cuisine en provenance de ma salle à manger et que mon grille-pain est en marche, je n’ai aucun moyen de dire combien de temps il reste à chauffer.
• Je ne peux mettre que 2 à 3 morceaux de pain à la fois. Ça signifie que quand je petit-déjeune avec madame, il faudra faire 2 ou 3 aller-retours en cuisine pour faire griller chacun nos tartines, le tout prenant jusqu’à 10 minutes au total.
• Ces grille-pain sont dangereux. J’ai déjà vu des flammes de 10 cm s’échapper d’un précédent grille-pain parce que le pain avait trop chauffé. Pour éviter les incendies à domicile, le Ministère de l’Intérieur recommande officiellement de « se méfier des grille-pain ». Il est également difficile de récupérer des plus petits morceaux de pains qui peuvent se coincer au fond, et on risque alors l’électrocution. Je ne suis pas un expert en électro-ménager, mais je sais que je ne devrais pas avoir à craindre de risquer ma vie et la vie de mes proches quand j’ai envie de manger du pain grillé.

Alors que faire ? N’existe-t-il aucune alternative innovante ?

Récemment en vacances à l’étranger, j’ai profité des joies du petit-déjeuner à l’hôtel. Et surtout, j’ai découvert ceci.

Ceci est un grille-pain convoyeur. Il est composé en haut d’une partie chauffante où vos tartines défileront sur un convoyeur automatique, et d’une partie inclinée en bas où vos tartines tomberont et glisseront toutes seules une fois grillées. Il n’y a que deux boutons : un pour régler la mise en marche et le thermostat, et un pour régler la vitesse du défilement des tartines.

A près de 40 cm³, 17 Kg, pour un prix avoisinant les 600€, c’est un véritable monstre, difficilement adapté à une cuisine domestique. Et pourtant, son fonctionnement résout tous les problèmes rencontrés ci-dessus.

• Simplement en regardant le pain défiler, vous savez en un instant où ça en est. Pas besoin de minuterie électronique compliquée, la machine indique d’elle-même son état.
• Vous pouvez rapidement enchaîner toutes vos tartines. Pas besoin d’attendre que les premières soient terminées avant de mettre les suivantes.
• Il y a moins de risque d’incendie car le pain ne reste pas dans la zone chaude une fois grillée. Et le pain est très facilement récupérable en dessous, quelque soit sa taille.

Et vous savez quelle est la meilleure partie de ce grille-pain ? C’est amusant. C’est amusant de voir les morceaux de pain défiler et chauffer tout doucement, puis tomber et glisser avant de les récupérer.

Il existe des versions « mini » de ce type de grille-pain, plus adaptées en taille à une cuisine domestique, mais encore 15 fois plus chères qu’un grille-pain classique. Je ne m’y connais pas plus que ça en grille-pain, mais s’il était possible d’avoir un modèle de ce genre, même pour 2 à 3 fois le prix d’un grille-pain classique, je me jetterais probablement dessus.

Si vous êtes à la recherche du « next big thing« , du produit super innovant qui vous rendra riche, commencez par regarder autour de vous. Regardez les objets de votre quotidien. Regardez ce que fait Dyson avec les traditionnels sèche-mains. Ou ce que fait Nest avec son thermostat. Je bave bien plus devant ce genre de produits que devant des nouvelles tablettes ou smartphones.

Pour bien comprendre le monde du web, je pense qu’il est important de bien comprendre le marché des navigateurs. C’est un marché de plusieurs milliards de dollars. Pourtant, il y a de fortes chances pour que vous n’ayez jamais déboursé le moindre centime pour utiliser votre navigateur.

Ça n’a pas toujours été le cas. En 1994, la toute première version d’Internet Explorer était disponible uniquement au sein du pack Microsoft Plus! pour Windows 95, vendu 55$. Deux mois après, IE2 était inclus officiellement par défaut dans Windows 95. Jusqu’en 1998, Netscape était vendu 49$. Jusqu’en 2000, Opera était disponible pour 39$. Alors comment font les grosses sociétés comme Apple, Microsoft, Mozilla ou Google pour gagner de l’argent ? Voici quelques explications détaillées pour chaque cas.

Apple et Safari

Apple est un fabricant de matériel. En 2011, Apple a généré un chiffre d’affaires de 108 milliards de dollars, avec 60 400 employés. L’année d’avant, la majorité des revenus d’Apple provenaient de la vente de matériel (iPhone, iPod, Mac). Bien sûr, Apple conçoit et vend des logiciels (OS X, iWork, iLife), et distribue également de la musique, des films et des applications via iTunes et l’App Store. Mais en comparaison de ce que leur rapporte la vente de matériel, ça ne leur rapporte « quasiment rien » (on sera quand même dans l’ordre de milliards de dollars, mais hey, c’est Apple). Toutes ces applications et services ne sont que des moyens pour arriver à une fin : vendre du matériel. En proposant des logiciels exclusifs à leur plate-forme, Apple vend plus de matériel.

Et c’est donc dans la même idée qu’Apple développe WebKit et Safari gratuitement, pour proposer par défaut un service complet sur ses machines. Et il se trouve qu’au passage, ça leur rapporte un peu d’argent de poche. L’année dernière, Google a payé Apple 1 milliard de dollars pour être le moteur de recherche par défaut dans Safari.

Microsoft et Internet Explorer

Microsoft est un éditeur de logiciels. En 2012 (année fiscale), Microsoft a généré un chiffre d’affaires de 73 milliards de dollars, avec 94 000 employés. La majorité des revenus de Microsoft provient de la vente de logiciels (Windows et Office en tête). Pour vendre ses logiciels, Microsoft s’adresse soit directement, soit à des fabricants d’ordinateurs pour leur vendre des licenses et installer par défaut leurs logiciels et OS.

Pour Microsoft, un peu comme pour Apple, Internet Explorer est donc un moyen de proposer un système d’exploitation complet et attrayant, et ainsi de vendre plus de Windows. Au passage, Internet Explorer leur permet aujourd’hui de faire la promotion de Bing à faible coût.

Mozilla et Firefox

Mozilla est un éditeur de logiciels à but non lucratif. En 2011, la fondation Mozilla a généré un chiffre d’affaires de 123 millions de dollars, avec 600 employés pour la Mozilla Corporation. La majorité des revenus de Mozilla provient de Firefox, et indirectement de… Google. Google paye 300 millions de dollars par an à Mozilla pour être le moteur de recherche par défaut du navigateur.

La principale motivation de Mozilla est donc d’avoir suffisamment de parts de marchés pour imposer un tarif élevé à Google et Microsoft pour la place hautement convoitée de moteur de recherche par défaut.

Google et Chrome

Google est un moteur de recherche. En 2011, Google a généré un chiffre d’affaires de 37 milliards de dollars, avec 54 604 employés. La majorité des revenus de Google provient de la vente d’espace publicitaires sur son moteur de recherche et sur son réseau publicitaire. En 2011, 96% des revenus de Google provenaient de la vente d’espace publicitaire. Google conçoit également pleins d’autres services que son moteur de recherche, comme Youtube, Android, Google Maps ou Google Docs. Mais tous ces services ne sont que des moyens pour Google d’arriver à leur fin : vendre et diffuser encore plus de publicités. En utilisant plus de services de Google, vous permettez à Google de mieux vous cibler et ainsi de mieux vous revendre à leurs annonceurs.

Chrome est développé en partie dans cette logique. Avec Chrome, Google s’autorise à utiliser vos données de navigation à « des fins d’amélioration de leurs services ». C’est à dire, vous suivre et étudier ce que vous faites, même en dehors de leurs réseaux de sites (par exemple sur des intranets habituellement non accessibles pour Google). Mais aussi, comme vous l’avez vu jusque là, Google dépense des milliards afin de conserver la place de moteur de recherche par défaut sur les autres navigateurs. Avec Chrome, et avec une part de marché désormais non négligeable, Google peut négocier les tarifs à son avantage.

C’est important d’avoir une idée des liens entre chacun des acteurs majeurs, car ça permet de mieux comprendre certaines décisions. Par exemple, quand Apple abandonne en silence Safari sous Windows, c’est parce que ça ne leur rapporte rien du tout. Quand Google décide de lancer sérieusement Chrome comme navigateur par défaut sur Android, c’est pour mieux s’imposer et éviter de payer des fortunes à Apple et Mozilla.

L’année dernière, le National Institute of Standards and Technology a diffusé sur Youtube des heures et des heures de vidéos brutes tournées le 11 septembre 2001 à New York. Assez fasciné et marqué par ces événements, j’étais abasourdi devant un extrait en particulier sur lequel j’étais tombé sur Reddit.

Un journaliste de la CBS se trouvait au coeur même du World Trade Center aux côtés des équipes de pompiers, juste après le crash du second avion sur la tour N°1. Alors qu’il ère aux pieds des tours, il rencontre un rescapé en costume-cravate. Il prend le bon réflexe de lui poser quelques questions, et de lui demander son nom et son lieu de travail. Puis, juste après, il rencontre un autre travailleur (à 17min40 dans la vidéo) :

– Je peux vous poser quelques questions ?
– Non, je ne préfère pas. Je passe une mauvaise journée.

Il filme ensuite l’homme, s’éloignant seul dans les rues déjà quelque peu assombries, traînant son sac sur le trottoir poussiéreux.

Dix secondes plus tard, la tour N°1 s’effondre dans un vacarme assourdissant. Un nuage de fumée poursuit les pompiers et civils qui tentent de se sauver, et plonge le journaliste dans l’obscurité la plus totale.

Ça m’arrive de croire que je passe de mauvaises journées, parce que j’ai eu trop de travail, parce que je n’ai pas réussi à faire ce que je voulais, ou parce que tout ne se passe pas comme je l’avais prévu. Mais depuis que j’ai vu cette vidéo l’année dernière, à chaque fois que j’ai l’impression de passer une mauvaise journée, je repense à cet anonyme des rues de New York qui pensait passer une mauvaise journée, avant même que les tours ne s’effondrent.

Il se trouve qu’en réalité, je n’ai pas vraiment passé de mauvaises journées.

Cette semaine, Amazon a présenté ses nouveaux modèles de Kindle. La version 8,9″ 32 Go 4G sera vendue 499$, contre 729$ pour le modèle d’iPad équivalent. Seul hic : pour ce prix là, vous aurez droit à une publicité plein écran à chaque fois que vous allumerez votre Kindle, et vous ne pourrez absolument rien faire pour éviter ça.

Je comprends l’utilisation de la publicité afin de proposer certains produits gratuitement, comme par exemple Gmail, ou les 18 heures de surf gratuites d’Oreka (high-five si toi aussi tu as connu ça). Par contre, même si c’est un modèle courant, notamment dans l’industrie de la presse ou du cinéma, je trouve ça insupportable de payer et de quand même devoir subir de la publicité. Dans l’absolu, pour moi, la publicité c’est le modèle économique du pauvre.

Hier, Shawn Dumas (développeur web chez Yahoo) résumait très bien la différence entre les tablettes Apple, Amazon et Google sur son compte Google+ :

Google vous veut. Google veut que vous regardiez des publicités. Android existe à cette fin. Plus d’utilisateurs égal plus d’yeux qu’ils peuvent vendre à des publicitaires. Android n’est pas une fin en soi, seulement un moyen pour arriver à une fin.

Amazon vous veut. Amazon veut que vous achetiez plus de ce qu’ils vendent – des médias, des biens, des services. Le Kindle Fire existe à cette fin. Plus d’utilisateurs égal plus de chances de vous vendre ce qu’ils colportent. Le Kindle Fire n’est pas une fin, seulement un moyen pour arriver à une fin.

Apple vous veut. Apple veut que vous achetiez un iDevice. Les iDevices existent à cette fin. Plus d’appareils vendus égal… plus d’appareils vendus. Les appareils d’Apple sont une fin en soi.

On connaît l’adage « Si vous ne payez pas pour un produit, c’est que vous êtes le produit. » Avec des tablettes sous Android (que ce soit de Google ou d’Amazon), même en payant pour le produit, vous restez le produit.

Mise à jour du lundi 10 septembre : tout compte fait, vous pourrez quand même désactiver les publicités sur votre Kindle à 499$ moyennant un supplément de 15$. Je trouve ça particulièrement pathétique : cela signifie que votre visionnage de publicité sur Kindle pendant 2-3 ans ne vaut pas plus de 15$. <

Il y a quelques semaines, le magazine Forbes rapportait qu’Apple était désormais la société ayant la plus grande valeur en capitalisation boursière (et historiquement, juste derrière le record de Microsoft en 1998). Cette nouvelle va dans la continuité de trois trimestres aux résultats exceptionnels pour Apple (1, 2, 3).

Je pense que les résultats d’Apple sont à prendre très au sérieux. Apple n’est pas pour autant la plus grosse société au monde (avec seulement 60 000 employés contre 2 millions pour WalMart). Apple n’est pas non plus la société générant le plus gros chiffres d’affaires (avec « seulement » 108 milliards de dollars en 2011 contre plus de 486 milliards de dollars pour ExxonMobil). Mais Apple est en tête des sociétés qui génèrent le plus de bénéfices au monde. En 2012, Apple cumule déjà 33,46 milliards de dollars de bénéfices, assurant ainsi la 7ème place au panthéon des sociétés ayant fait le plus de bénéfices en une année.

Les bénéfices, pour une entreprise, c’est vital. Comme le dit John Gruber, « les bénéfices sont l’oxygène que les sociétés respirent« . Les bénéfices sont ce qui permet à une entreprise de vivre, d’avancer, de se projeter, d’innover. Mais surtout, les bénéfices confèrent aux grandes entreprises une influence importante.

Il y a quelques mois, lors de l’annonce des résultats d’Apple pour son second trimestre de l’année fiscale 2012, j’écrivais :

Je suis né et j’ai grandi dans un monde où les rois du pétrole étaient les rois du monde. Nos moyens de locomotions, nos modes de vie, nos Guerres, ont directement été influencées par la possession et le contrôle du pétrole.

Depuis 6 mois, ce n’est plus le cas. Depuis 6 mois, c’est une société informatique qui a pris ce rôle. Depuis 6 mois, c’est Apple qui domine le monde.

La comparaison entre Apple et les compagnies pétrolières est une parfaite illustration de la théorie espagnole : les compagnies pétrolières gagnent de l’argent en vendant de la « matière noire », Apple gagne de l’argent en vendant de la matière grise.

L’idée de l’influence qu’Apple peut avoir sur notre société en comparaison avec l’influence qu’ont eu les compagnies pétrolières me fascine. Car c’est à la fois une très bonne chose, et une très mauvaise chose. C’est une bonne chose, selon moi, pour certaines valeurs d’Apple que je partage, comme le goût du design. Mais c’est une mauvaise chose, selon moi, pour d’autres pratiques moins appréciables, comme leur fermeture et leur propriétarisation à outrance.

Dans le monde informatique, l’influence d’Apple en matière de design se fait déjà fortement sentir. Jugez plutôt.

Il n’y a pas un seul produit Apple sur cette image. (De gauche à droite et de haut en bas : le N2-A de KIRF, la Chromebox de Google, un câble USB pour Galaxy Tab de Samsung, le HP Envy, le packaging d’une Galaxy Tab de Samsung, la tablette/laptop Series 7 de Samsung).

Le plagiat est éhonté, mais je préfère vivre dans un monde où nos appareils électroniques s’inspirent d’un bon design. Les comparaisons de produits avant/après l’arrivée de l’iPhone ou du Macbook Air en sont un bon témoignage. Ce goût du design minimaliste s’étend aussi petit à petit à d’autres produits, comme le thermostat Nest, le (feu) caméscope Flip, ou l’appareil photo Lytro.

Sur le web, l’influence d’Apple, bien que peu apparente, me semble toute aussi importante. Apple a par exemple joué un rôle majeur dans la disparition de Flash sur le web. Bien que n’étant pas les premiers à ne pas supporter Flash sur leurs appareils, l’influence d’Apple a clairement aidé.

Mais l’influence d’Apple sur le web n’est pas toujours aussi positive, et en voici quelques exemples.

• En choisissant délibérément de ne pas respecter les spécifications du W3C et en ne retirant pas les préfixes –webkit- des propriétés CSS en cours de recommandation, Apple a initié tout un tollé menant à la disparition des préfixes navigateurs.
• Avec le lancement d’iBooks Author en début d’année, Apple a préféré lancer son propre format de livre numérique dérivé d’EPUB, plutôt que de contribuer au standard pour en faire bénéficier toute l’industrie. On retrouve également une tripotée de propriétés CSS non standards qu’Apple a implémenté dans WebKit, sans aucune intention de les standardiser, au dépends des autres navigateurs et de l’éco-système ouvert du web.
• Le format vidéo ouvert WebM a été tué dans l’oeuf par Google, au profit du format H.264, format  plébiscité par Apple et indispensable pour lire des vidéos sur le web sur iOS.
• Avec le lancement d’iOS 4.3, Apple a grandement amélioré le moteur JavaScript de Safari (Nitro). Sauf que ces améliorations ne sont pas disponibles pour des applications web en dehors de Safari (via une UIWebView ou un raccourci sur l’écran d’accueil). Résultat : le développement d’application web est souvent laissé de côté.