HTeuMeuLeu

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é.

Il y a quelques semaines, j’ai découvert l’histoire de Ronald Opus. C’est l’histoire d’une enquête sur un meurtre racontée par Don Harper Mills (alors président de l’Académie Américaine des Sciences Médico-légales) en 1987 lors de l’ouverture d’un banquet. Attention, accrochez-vous bien.

Le 23 mars 1994, un médecin légiste examina le corps de Ronald Opus and conclut qu’il était décédé d’une blessure par balle à la tête causée par un fusil de chasse. Jusque là, l’enquête avait révélé que le défunt avait sauté du haut d’un immeuble de dix étages avec l’intention de se suicider. (Il avait laissé une note indiquant son désespoir.) Alors qu’il passait devant le 9ème étage au cours de sa chute, sa vie a été interrompue par un tir de fusil de chasse à travers la fenêtre, le tuant instantanément. Ni le tireur ni le défunt n’étaient au courant qu’un filet de sécurité avait été érigé au niveau du 8ème étage pour protéger des laveurs de vitres, et que le défunt n’aurait très certainement pas pu réussir son suicide à cause de cela.

D’ordinaire, une personne qui commence les événements avec l’intention de se suicider parvient finalement à se suicider même si la façon de faire n’est pas celle qu’il avait prévu. Le fait qu’on lui ait tiré dessus en chemin vers une mort certaine 9 étages plus bas ne change probablement pas la cause de sa mort d’un suicide en un homicide. Mais le fait que son suicide n’aurait pas pu être mené à bien a poussé le médecin légiste à déclarer qu’il avait un homicide sous la main.

La poursuite de l’enquête mena à la découverte que la chambre du 9ème étage, d’où le tir de fusil a été émis, était occupée par un vieil homme et sa femme. Il la menaçait avec le fusil à cause d’une dispute conjugale, et il était tellement en colère qu’il n’arrivait pas à tenir l’arme droite. Ainsi, quand il a appuyé sur la gâchette, il a complètement raté sa femme, et les balles de plomb ont traversé la fenêtre, touchant le défunt.

Quand une personne projette de tuer un sujet A mais tue un sujet B lors de sa tentative, celle-ci est coupable du meurtre du sujet B. Le vieil homme était confronté à cette conclusion, mais lui et sa femme étaient catégoriques en déclarant qu’aucun d’eux ne savait  que le fusil était chargé. C’était une vieille habitude du vieil homme de menacer sa femme avec un fusil déchargé. Il n’avait aucune intention de la tuer. Ainsi, le meurtre du défunt est apparue comme accidentelle. C’est-à-dire que l’arme a été accidentellement chargée.

Mais la poursuite de l’enquête a fait apparaître un témoin déclarant que leur fils a été vu en train de charger l’arme approximativement six semaines avant l’accident fatidique. L’enquête montra que la mère (la vieille femme) avait arrêté de supporter financièrement son fils. Et son fils, connaissant la propension de son père à utiliser le fusil de chasse de manière menaçante, a chargé l’arme en prévision que le père tirerait sur sa mère. L’affaire devient maintenant un meurtre, de Ronald Opus par le fils.

Maintenant voici la touche exquise. La poursuite de l’enquête révéla que le fils était devenu de plus en plus déprimé par l’échec de sa tentative de faire tuer sa mère. Cela l’a poussé à sauter de l’immeuble de dix étages le 23 mars, mais à être tué par un tir de fusil de chasse à travers une fenêtre du 9ème étage.

Le médecin légiste classa l’affaire comme un suicide.

Cette histoire, reprise dans le film Magnolia ou un épisode des Experts:Miami, ne s’est pas réellement produite. Don Harper Mills l’a inventée pour montrer l’importance d’avoir toutes les informations, et la différence que cela peut produire.

Mais cette anecdote m’a rappelé mon histoire d’un bug, et plus généralement la difficulté de résoudre un bug sans avoir toutes les informations à sa disposition. Comme je l’écrivais en commentaire d’un très bon article de Nicolas Hoffmann :

Un cas courant que je rencontre qui illustre bien ce problème, ce sont les chefs de projet qui m’envoient une capture d’écran d’un problème recadrée uniquement sur la partie de la page où le problème apparaît. Ça part d’une bonne intention, mais c’est particulièrement gênant car ça m’empêche de comprendre ce qui se passe réellement. Avec une capture d’écran complète, je suis capable de déterminer l’OS de test, le navigateur, la version de navigateur (a peu près), et tout autre phénomène extérieur pouvant jouer un rôle dans l’apparition du bug. J’ai déjà eu plusieurs fois des remontées de bugs qui provenaient en fait de la présence d’un plugin dans le navigateur (Skype, AdBlock, ou Flash).

Être un bon intégrateur, c’est aussi être un bon détective.

L’année dernière, j’ai découvert une ligne de commande Unix bien pratique : ln -s. Cette commande permet de créer un lien symbolique vers un fichier ou un dossier. Un lien symbolique, c’est une référence à un fichier ou dossier qui correspond fonctionnellement au fichier ou dossier original. Grossièrement, ça permet de retrouver un même dossier à plusieurs endroits sur son ordinateur sans avoir à le dupliquer.

Ça peut paraître tordu de vouloir retrouver un même dossier à plusieurs endroits, mais ça correspond pile poile à mon organisation. Je travaille souvent sur des petits projets d’intégration (des newsletters, des pages d’opérations commerciales, etc.) qui ne nécessitent pas de contrôleur de sources. En général, je vais me retrouver avec l’organisation suivante :

• Un dossier « ~/Boulot/Client/Nom_du_projet/ » avec à l’intérieur un dossier « Elements » (avec les fichiers envoyés par le client), un dossier « PSD » (avec les maquettes) et un dossier « HTML » (avec mon intégration).
• Un dossier sur mon serveur local dans « /Applications/MAMP/htdocs/Nom_du_projet », pour pouvoir tester la page dans de bonnes conditions.
• Eventuellement une sauvegarde dans mon dossier « ~/Dropbox », par précaution, et au cas où j’aurais besoin d’accéder à mes fichiers sur une machine différente chez moi.

Grâce à la commande ln -s, je peux retrouver mes fichiers dans ces 3 dossiers sans avoir à les dupliquer. Ainsi, il me suffit de taper dans le Terminal les deux commandes suivantes :

ln -s ~/Boulot/Client/Nom_du_projet/ /Applications/MAMP/htdocs/Nom_du_projet
ln -s ~/Boulot/Client/Nom_du_projet/ ~/Dropbox/Nom_du_projet

Et le tour est joué ! A noter que sous Windows, la commande mklink permet d’obtenir un résultat similaire.

Voici une vérité assez dérangeante : un intégrateur peut intégrer n’importe quelle page en 1 heure. Oui, mesdames et messieurs, en seulement une heure.

Alors, bien sûr, en aussi peu de temps, il ne faudra pas s’attendre à avoir un résultat de qualité (on en revient au classique trio coût-temps-qualité). Il y a des chances pour que, sous cette contrainte, vous ayez droit à des tableaux, des noms de classe CSS numérotés, des position:absolute partout, des grosses images, et des plugins jQuery à gogo. Votre page sera peut-être totalement inmaintenable, mal référencée, pas compatible IE6, super lourde et pas tout à fait fidèle à la maquette. Mais, youpi, vous avez fini en une heure.

Si vous travaillez en agence, ça vous est surement déjà arrivé : une newsletter, une page landing, voire un site complet à intégrer en urgence. On vous laissera quand même peut être plus qu’une heure. Mais le temps deviendra votre première contrainte.

Il est alors important de savoir ce que vous devez privilégier. Il y a quelques mois, j’expliquais mes critères de qualité d’une intégration basé sur les 3 questions suivantes :

1. Est-ce que c’est bien pour l’internaute ? (performance, compatibilité, accessibilité)
2. Est-ce que c’est bien pour le projet ? (graphisme, référencement, développement)
3. Est-ce que c’est bien pour moi ? (bonnes pratiques, maintenabilité)

Je pense que, même sous la contrainte du temps, il faut garder à l’esprit qu’on travaille pour l’internaute. Du coup, on sera amené à abandonner d’abord les dernières critères. Par manque de temps, je laisserai sûrement de côté mes bonnes pratiques habituelles et la maintenabilité de mon code. Et si vraiment je n’ai toujours pas le temps, je laisserai de côté le respect du graphisme, des bonnes pratiques du référencement ou des contraintes de dev. Et enfin seulement, si vraiment je n’ai pas le temps, je ferai l’impasse sur la performance, la compatibilité ou l’accessibilité.

Il paraît clair qu’avec trop peu de temps, on n’aura jamais un résultat de qualité. Mais à l’inverse, trop de temps devient nuisible à l’intégration. Si pour la même intégration, on vous accorde non plus une heure, mais une semaine complète, vous risquez fortement de tomber dans de la surréflexion et de chercher à faire de la sur-qualité. Votre page risque alors de devenir à nouveau inmaintenable, sur-optimisée et éloignée des vraies bonnes pratiques.

Le temps est sans doute le pire ennemi de l’intégrateur. Et plus que n’importe quelle notion technique, c’est certainement la chose la plus difficile à apprendre à gérer.

En tant qu’entrepreneur, le changement le plus bizarre apparu dans ma vie ces dernières années est mon rapport à l’argent. En étant gérant, je suis parfois amené à déposer des chèques sur le compte de ma société de plusieurs dizaines de milliers d’euros. Si ces sommes font tourner la tête lorsqu’il s’agit de votre compte personnel, ça en devient presque assez banal et anodin pour le compte de votre entreprise. Là où personnellement je vais mettre plusieurs mois à économiser et à me décider avant d’acheter un Macbook Air à 1000€, je pourrais faire ce genre d’achat de manière totalement impulsive pour ma société.

Il y a quelques temps, j’étais tombé sur cet article qui expliquait très bien le rapport qu’on peut avoir avec l’argent, et « Les différentes façons dont les gens dépensent de l’argent » :

L’économiste de renommée mondiale et académique, Milton Friedman, dit qu’il y a 4 façons basiques dont les gens dépensent de l’argent. […]

Il y a deux facteurs à considérer quand on regarde comment quelqu’un dépense de l’argent. Premièrement, qui possède l’argent, et deuxièmement, pour qui l’argent est dépensé.

Le premier facteur dicte l’économie de la décision, alors que le deuxième facteur affecte la valeur et la qualité de l’achat.

Avec ça en tête, on arrive alors à la conclusion de Friedman :

1. Dépenser votre propre argent pour vous-même.
Quand l’argent vient de votre propre poche, pour acheter quelque chose pour vous même, vous aurez tendance à économiser mais néanmoins rechercher le produit de meilleure qualité que vous pourrez avoir. […]

2. Dépenser votre propre argent pour les autres.
Cela arrive quand, par exemple, vous achetez un cadeau d’anniversaire pour un ami. Le comportement de base d’une personne ici, d’après Friedman, est qu’elle aura tendance à économiser mais ne cherchera pas le produit de meilleure qualité. […]

3. Dépenser l’argent de quelqu’un d’autre pour vous.
Vous partagez en voyage d’affaires aux frais de votre société ? Alors je suis sur que vous chercherez les meilleurs produits et services disponibles sans vraiment regarder le prix. […]

4. Dépenser l’argent de quelqu’un d’autre pour les autres.
Quand est-ce que quelqu’un dépenserait l’argent de quelqu’un d’autre pour d’autres personnes ? Pensez au gouvernement qui utilise l’argent des contribuables au bénéfice de leurs constituants.

Et à en juger par la façon dont Friedman définit les 3 premiers points ci-dessus, vous réaliserez que c’est peut être la raison pour laquelle les dépenses du gouvernement ont tendance à être si élevées mais la qualité du service rendu est (en général) si mauvaise. La nature de cette quatrième façon de dépenser ne cherche ni à économiser ni à atteindre la meilleure valeur pour l’argent.

Cela explique mon apparente schizophrénie. Quand je veux acheter personnellement un Macbook Air, je vais dépenser mon argent, pour moi (cf le premier point). Quand je veux acheter un Macbook Air pour ma société, je vais dépenser l’argent de ma société, pour moi (cf le troisième point).

La semaine dernière, Adobe a sorti la version 11.4 de Flash Player. Dans un communiqué intitulé « Flash Player et AIR ouvrent la voie à de nouveaux jeux« , j’ai eu un léger rictus devant le paragraphe suivant :

Nous avons posé les bases cette année pour augmenter la vitesse à laquelle les mises à jour du Flash Player sont adoptées. Flash Player 11.2 a introduit les mises à jour en arrière-plan, et plus de 400 millions de personnes ont opté pour l’utiliser. Cela signifie qu’avec n’importe quelle nouvelle version du plugin, 400 millions d’utilisateurs peuvent être mis à jour vers la dernière version du Flash Player en environ 48 heures. Pour mettre ça en perspective, 400 millions c’est a peu près six fois le nombre de Xbox 360 vendues depuis 2005. Les développeurs de jeux peuvent désormais rapidement adopter de nouvelles fonctionnalités en sachant qu’il y a un public énorme qui les attend.

Pour mettre ça en perspective, Apple a vendu plus de 374 millions d’appareils sous iOS depuis 2007 (avec 244 millions d’iPhone, 84 millions d’iPad et 46 millions d’iPod Touch rien qu’aux Etats-Unis). En élargissant les ventes d’iPod Touch au reste du monde, on ne devrait pas être loin de 400 millions d’appareils sous iOS vendus depuis 2007.

Ce sont 400 millions d’appareils qui n’ont jamais vu et ne verront jamais la moindre trace de Flash Player.

Et ça, ce n’est que pour iOS. Vous pouvez ajouter à ça pas loin de 400 millions d’appareils sous Android, avec 1 million de nouvel appareil activé chaque jour, qui n’ont officiellement plus la possibilité d’installer Flash Player depuis le 15 août.

Vous pouvez aussi ajouter à ça la totalité du marché des consoles de jeux vidéo de cette génération (dont bientôt la Xbox 360 avec Internet Explorer), soit un peu plus de 250 millions d’appareils qui peuvent accéder au web, mais sans Flash Player. Et ce, bien avant que Steve Jobs n’exprime le fond de sa pensée.

Et à partir d’octobre, vous pourrez ajouter des millions de Windows 8 qui ne supporteront Flash Player que sur quelques sites pré-sélectionnés dans son interface « Windows 8 » (anciennement Metro).

Pendant des années, Adobe annonçait fièrement que Flash avait un taux de pénétration de 99%. Déjà en 2009, Sam Johnston soupçonnait que la réalité était plus proche des 50%. Aujourd’hui, Adobe ne parle plus en pourcentage mais en nombre d’appareils. Parce qu’en réalité, le support de Flash est déjà bien en deçà de 50% des appareils connectés au web. Et ce chiffre ne va faire que diminuer.

A l’opposé, les navigateurs modernes (excluant IE6-7-8) représentent aujourd’hui entre 65% (d’après NetMarketShare) et 74% (d’après StatCounter) du marché des navigateurs. Et ce chiffre ne va faire qu’augmenter.

Je sais que ça sonne encore comme un article biaisé qui annonce la mort de Flash sur le web. Mais vraiment, si ce n’est pas encore fait, c’est votre dernière chance pour faire vos adieux.

En début d’année, Mozilla a timidement présenté son nouveau projet de système d’exploitation pour mobile, Boot to Gecko, tout en HTML5. À l’époque, les démonstrations faites à la presse n’étaient pas très emballantes et ressemblaient à quelque chose comme ça :

Oui, d’accord, je suis allé chercher la pire démonstration possible chez 01net. Les choses ont pas mal progressé depuis le début d’année.

Le mois dernier, Mozilla a officialisé le projet, le renommant au passage Firefox OS, et annonçant un partenariat avec de nombreux opérateurs dans le monde. Pas en France cependant, où aucun smartphone sous Firefox OS n’est prévu avant au moins 2014, dixit Tristan Nitot (président de Mozilla Europe). Cependant, rien n’empêche d’installer vous-même Firefox OS, que ce soit pour le tester sur votre ordinateur ou directement votre smartphone.

Sur le papier, Firefox OS me plaît beaucoup : un système tout en technologies web, installable et modifiable librement, avec un éco-système ouvert. On est à l’opposé d’iOS et d’Android.

Mais j’ai du mal à y croire. Je ne doute pas sur la capacité de Mozilla à mener à bien le projet. Mais je doute sur le fait que l’OS connaisse un réel succès, comme ça a pu être le cas avec Firefox.

La semaine dernière, MG Siegler a écrit un excellent article concernant ce type de projet, en prenant pour exemple App.net, le concurrent ouvert de Twitter. Son article part d’une excellente métaphore et citation de The Dark Knight : « You either die a hero or you live long enough to see yourself become the villain. » (dans l’horrible version française : « Le choix est de mourir en héros, ou de vivre assez longtemps pour devenir le méchant. »).

Je déteste être le trouble-fête. Le cynique. Le trou du cul. Mais je préfère me voir comme le réaliste. Si c’est génial qu’on soit tous enthousiastes autour des fondements altruistes du message ici, je pense que l’honnêteté est toute aussi importante. En fait, c’est même plus important.

App.net ne va pas réussir parce qu’on ne veut pas vraiment qu’il réussisse. Au fond, nous savons tous que c’est bien meilleur en tant qu’idée, plutôt qu’en tant que réalité. Parce que la réalité de la situation est que si App.net devait un jour être un succès, il rencontrerait nombre des mêmes choix difficiles que Twitter rencontre aujourd’hui. Ou alors il disparaîtrait.

En d’autres mots, pour citer Harvey Dent, « Soit vous mourrez en héros, soit vous vivez suffisamment longtemps pour vous voir devenir le méchant. »

App.net est destiné à mourir en héros. Il est destiné à rester dans les mémoires comme la chose qui devait tout changer, mais que le monde cruel a abattu. Peut-être qu’il rassemblera d’autres utilisateurs, ou peut-être pas. Ce n’est pas vraiment important. Ce qui compte c’est que l’idée nous ait réconforté pendant quelque secondes. Et puis la vie continue. La réalité passe son chemin.

On a déjà vu l’histoire auparavant. Indenti.ca devait être le « Twitter ouvert » avant qu’App.net ne doive devenir le « Twitter ouvert ». Diaspora devait remplacer Facebook en rendant le pouvoir aux utilisateurs. OpenID. OpenSocial. Open. Open. Open. Gratuit. Joie. Merveille. Paix. Perfection.

La vérité est que ces choses marchent rarement parce que ce n’est simplement pas comme ça que le monde fonctionne. Les gens tendent à se jeter sur les meilleurs services. Et les meilleurs services tendent à naître des meilleurs entrepreneurs. Et les meilleurs entrepreneurs finissent par réaliser qu’ils ont besoin de monter les meilleurs entreprises, par crainte de voir leur service mourir ou pire — traîner dans la médiocrité.

Vous pouvez relire cet extrait en remplaçant « App.net » par « Firefox OS », et « Twitter » par « Android/iOS », et vous aurez mon point de vue.

En réalité, j’ai peur que Firefox OS ne devienne « le méchant » très rapidement. La principale stratégie de Mozilla, c’est de s’associer avec les opérateurs pour déployer son système. La semaine dernière, le journal Les Échos titrait « Avec Firefox OS, les opérateurs télécoms cherchent à reprendre la main« .

Je ne suis pas certain que soit une bonne chose. C’est d’ailleurs un des points forts de l’entrée d’Apple sur le marché mobile il y a 5 ans. Apple a pris le contrôle de la main des opérateurs sur le design des téléphones, leurs fonctionnalités et les applications pré-installées. Pour bien illustrer le problème du contrôle des opérateurs, j’aime bien prendre l’exemple de Rovio (raconté chez Wired l’année dernière) qui a lutté pendant des années à développer des applications à la demande des opérateurs, avant de réellement connaître un succès libérateur sur iOS avec Angry Birds.

Je pense que si Mozilla souhaite un succès sain et honnête pour Firefox OS, ils devraient à tout prix rester à l’écart des opérateurs.

La semaine dernière, j’ai lu via MG Siegler un vieux mais excellent article de Paul Graham (co-fondateur de Y Combinator) sur « le planning du producteur et le planning du manager« .

Une raison pour laquelle les développeurs détestent les réunions est qu’ils sont sur un différent type de planning que les autres gens. Les réunions leur sont plus coûteuses.

Il existe deux types de plannings, que j’appellerais le planning du manager et le planning du créateur. Le planning du manager est pour les chefs. Il est incarné par le traditionnel carnet de rendez-vous, où chaque jour est découpé en intervalles d’une heure. Vous pouvez bloquer plusieurs heures pour une seule tâche si vous en avez besoin, mais par défaut vous changez ce que vous faites toutes les heures.

Quand vous gérez votre temps de cette façon, c’est seulement un problème pratique pour rencontrer quelqu’un. Trouvez un créneau disponible dans votre planning, réservez-le, et vous avez fini.

La plupart des gens puissants sont sous un planning de manager. C’est le planning du commandement. Mais il existe une autre façon d’utiliser son temps qui est plus courante parmi les gens qui créent des choses, comme les développeurs ou les auteurs. Ils préfèrent en général gérer leur temps au minimum par demi-journée. Vous ne pouvez pas écrire ou programmer correctement par tranches d’une heure. C’est à peine suffisant pour commencer.

Quand vous travaillez sous un planning de créateur, les réunions sont un calvaire. Une simple réunion peut faire sauter toute une après-midi, en la divisant en deux morceaux beaucoup trop petits pour pouvoir y faire réellement quelque chose. Et puis il faut que vous vous rappeliez d’aller à cette réunion. Ce n’est pas un problème pour quelqu’un sous un planning de manager. Il y a toujours quelque chose à venir l’heure suivante; la seule question est quoi. Mais quand quelqu’un sous un planning de créateur a une réunion, il faut qu’il y pense.

Je ne l’avais jamais vu sous cet angle auparavant, mais je crois que c’est une des choses les plus compliquées que j’ai du apprendre à gérer en devenant à la fois intégrateur et entrepreneur. Je ne pense pas qu’il y ait de recette miracle. Mais comme évoqué il y a quelques mois dans cette comparaison entre le travail et le sommeil, il faut éviter au maximum toutes les interruptions de travail. Si une réunion ou un appel téléphonique peuvent être formalisés plutôt par e-mail, alors je viens de gagner une demi-journée. Ça semblera peut-être gênant pour quelqu’un sous un planning de manager, mais le bénéfice pour quelqu’un sous un planning de créateur sera énorme.

Récemment, j’ai eu l’occasion de discuter avec un responsable technique d’un gros site e-commerce d’une grande marque française. Il m’expliquait qu’après avoir remarqué une erreur de texte sur une page dynamique du site, une demande de modification avait été faite auprès de leur équipe technique. L’équipe en question a alors réalisé un chiffrage de temps et de budget pour cette modification. Et le résultat m’a laissé sans voix : pour changer une ligne de texte, la modification a été estimée à 6 mois de travail, un budget de 15 000€, en faisant intervenir une quinzaine de personnes (un intégrateur, un développeur, un responsable technique, un responsable maintenance, un chef de projet, un responsable marque, etc…).

Ce n’est pas la première fois que je rencontre ce genre d’estimations, en particulier dans des grands groupes. Quand je travaille avec de nouveaux clients, ça m’amène à me poser régulièrement cette question : Combien de temps vous faut-il pour changer un « s » ? Combien de temps vous faut-il pour corriger une simple faute d’orthographe ? Combien de temps vous faut-il pour faire une simple modification de texte ?

En tant qu’intégrateur, j’aurais envie de répondre 5 minutes. Mais j’aurais certainement tort. Rien ne prends jamais 5 minutes. En réalité, je pense qu’il faut compter au minimum 15 minutes. C’est le temps qu’il me faut pour lire la demande, ouvrir le projet dans Coda, trouver le fichier à modifier, faire la modification, vérifier que ça marche bien en local, mettre en ligne, vérifier que ça marche bien en ligne, et répondre au client que la demande a été traitée. Si vous êtes freelance, et que vous travaillez seul sur la totalité d’un projet, vous serez surement assez proche de cette estimation.

Dans une petite ou moyenne agence, il faudra sans doute compter un peu plus d’intervenants. Un chef de projet va recevoir la demande du client et se chargera de la transmettre aux personnes concernées en interne. Un intégrateur pourra alors s’occuper de faire la modification. Une fois le tout vérifié par le chef de projet, un responsable technique pourra alors s’occuper de la mise en ligne. Pour une modification un peu plus complexe, il faudra peut être repasser par un graphiste et faire valider le tout avant intégration par le client. Au total, on atteint facilement une à deux heures de travail.

Dans une très grosse entreprise, c’est souvent bien pire. Il y a 2 ans, j’avais tweeté cet article intitulé « Combien faut-il d’employés chez Microsoft pour changer une ampoule ?« . La liste est particulièrement longue et impressionnante :

• Un développeur pour passer 5 minutes à implémenter ChangeLightBulbWindowHandleEx
• Un responsable programme pour écrire la spécification.
• Un expert localisation pour repérer d’éventuels problèmes de localisation dans la spécification.
• Un expert en utilisabilité pour repérer d’éventuels problèmes d’accessibilité et d’utilisabilité dans la spécification.
• Au moins un développeur, un testeur et un chef de projet pour réfléchir à des vulnérabilités de sécurité.
• Un chef de projet pour ajouter le modèle de sécurité à la spécification.
• Un testeur pour écrire le plan de test.
• Un responsable de tests pour mettre à jour le planning de tests.
• Un testeur pour écrire les cas de tests et les ajouter aux tests nocturnes automatiques.
• Trois ou quatre testeurs pour participer à de la chasse aux bugs.
• Un rédacteur technique pour écrire la documentation.
• Un relecteur technique pour vérifier la documentation.
• Un rédacteur pour relire et corriger la documentation.
• Un responsable de la documentation pour intégrer la nouvelle documentation dans le contenu existant, en mettant à jour les sommaires, etc.
• Vingt-cinq traducteurs pour traduire la documentation et les messages d’erreur dans toutes les langues supportées par Windows. Les managers des traducteurs vivent en Irelande (pour les langues européennes) et au Japon (pour les langues asiatiques), qui sont toutes deux fortement en décalage horaire avec Redmond, donc échanger avec eux peut devenir un problème logistique assez complexe.
• Une équipe de managers sénior pour coordonner tous ces gens, signer les chèques, et justifier leur coût à leur Vice Président.

On comprend vite comment on peut arriver à 6 mois pour une demande pourtant aussi simple. Si cela peut prêter à sourire chez Microsoft, je pense que ce mode de fonctionnement est particulièrement inadapté pour le web. Sur le web, votre capacité de réactivité doit l’emporter à votre administrativité. Débrouillez vous pour diminuer le nombre d’intervenants. Donnez plus de responsabilités à vos collaborateurs. Mais s’il vous faut plus de deux heures pour changer un « s », il y a peut être quelque chose qui cloche dans votre organisation.

Si vous avez regardé la télévision française ou si vous êtes allé au cinéma ces dernières semaines, vous n’avez sans doute pas pu échapper à la publicité suivante.

http://www.youtube.com/watch?v=7Yf7_EJpaEs

Après avoir vu cette publicité la première fois, vous vous êtes peut-être posé la même question que moi : pourquoi ? Pourquoi est-ce que Microsoft fait de la publicité pour IE9, seize mois après sa sortie ? Pourquoi est-ce que Microsoft fait de la publicité pour IE9, trois mois avant la sortie de Windows 8 et d’IE10 ? Pourquoi est-ce que Microsoft dépense des fortunes en budget publicitaire après un premier trimestre déficitaire historique ?

Je n’ai malheureusement pas les réponses à ces questions. Mais je ne peux qu’émettre une hypothèse : Microsoft est en train de perdre le marché des navigateurs, et ils en sont parfaitement conscients.

En juin dernier, StatCounter annonçait fièrement que les parts de marché de Chrome venaient de dépasser celles d’Internet Explorer (toutes versions confondues). Si ces chiffres ne font pas l’unanimité, la tendance du déclin d’Internet Explorer est bien réelle. D’après NetMarketShare, ces 2 dernières années, Internet Explorer a perdu 9% de parts de marché mondial (passant de 62% à 53%). D’après StatCounter, ces 2 dernières années, Internet Explorer a perdu 20% de parts de marché mondial (passant de 52% à 32%). Et tout ceci s’est fait au profit quasiment exclusif de Chrome, passant de 7% à 18% en deux ans d’après NetMarketShare, et de 9% à 33% d’après StatCounter. Pour rappel, jusqu’au milieu des années 2000, les parts de marché d’Internet Explorer dépassaient les 90%.

Avec ce genre de publicité, Microsoft tente de limiter la casse et de freiner le déclin d’Internet Explorer. Mais je ne suis pas sûr que ce soit suffisant…

Ce week-end, je suis tombé via Hacker News sur Adaptor, un énième slider en jQuery. J’ai été particulièrement surpris en essayant l’effet de défilement horizontal. Je vous invite à l’essayer sur la page de démo en cliquant sur le bouton « Horizontal scroll ». (MAJ : suite à un commentaire sur Hacker News, le script et sa démo ont été corrigés)

Au premier abord, j’ai eu l’impression que le défilement du slider était à l’envers. En cliquant sur la flèche de droite, j’affiche bien l’image suivante dans le slider, mais celle-ci apparaît par la gauche. Naïvement, mon petit cerveau s’attend à ce que les images soient côtes à côtes, de gauche à droite (comme le suggèrent les petits points de navigation en bas à droite), alors qu’en réalité elles sont placées en sens inverse. Pourtant, après quelques minutes passées à tester ce slider, mon cerveau a fini par s’habituer et à s’adapter. En cliquant sur la flèche de droite, je ne m’attends alors plus à voir l’image de droite, mais je m’attends à faire défiler l’ensemble du slider vers la droite. Et une fois que j’ai ce modèle mental en tête, je n’ai plus de problème à utiliser ce slider, et j’ai totalement oublié ma première intuition.

Ce n’est pas la première fois que je tombe sur un slider comme celui-ci. Ça arrive même assez souvent. Le premier qui me vient en tête, c’est celui d’iTunes. Je ne vais pas souvent dans iTunes, mais à chaque fois que j’y vais, je mets quelques secondes avant de comprendre le fonctionnement de ce slider.

Initialement, je m’attends à ce qu’en cliquant sur la flèche en bas à droite, j’affiche la vignette suivante sur la droite. Je m’attends alors à un défilement des vignettes de droite vers le haut. Or, c’est l’inverse qui se produit. En réalité, les vignettes vont défiler vers le bas, et c’est la vignette la plus en bas qui va prendre la place de la vignette principale. Mais comme dans le premier exemple, une fois que j’ai joué un peu avec ce slider, son fonctionnement me semble tout à fait correct, et mon premier modèle mental initial incorrect.

Ces problèmes de sliders m’ont alors rappelé un vieil article sur les interfaces utilisateurs qui traitait du problème des boutons d’ascenseurs :

Imaginez la situation suivante. Vous êtes au 3ème étage de cet immeuble et vous souhaitez vous rendre au 10ème. L’ascenseur est au 5ème étage et il y a un indicateur qui affiche où il se trouve. Sur quel bouton appuyez vous ?

La plupart des gens diront probablement « appuyez en haut », puisqu’ils veulent aller en haut. Il n’y a pas si longtemps j’ai vu quelqu’un faire l’inverse, et je l’ai interrogé à propos de son comportement. Il m’a dit : « et bien l’ascenseur est au 5ème, et je suis au 3ème, donc je veux qu’il descende vers moi ».

Comme pour nos sliders, sur le papier, les deux comportements semblent tout à fait valables. Mais tout est une question de point de vue. Quand je clique sur une flèche d’un slider, ou sur le bouton d’un ascenseur, est-ce que je dois indiquer l’action que moi je veux effectuer (comme afficher l’image suivante, ou me rendre à un étage supérieur) ? Ou est-ce que je dois indiquer l’action que je veux faire faire à l’appareil que je manipule (comme faire défiler le slider vers la droite, ou faire descendre l’ascenseur jusqu’à moi) ?

Si dans le cas de l’ascenseur, on devrait simplement trouver un unique bouton d’appel, je pense qu’une interface informatique doit se mettre à la place de l’utilisateur, et non l’inverse.

La semaine dernière, le WHATWG a annoncé discrètement son intention de dissocier officiellement ses spécifications HTML de celles du W3C. Si l’annonce a été plutôt bien relayée par la presse anglophone (comme chez TheVerge ou TechCrunch), j’ai l’impression qu’en France elle a été mal comprise, déformée et sensationnalisée (comme chez PC Inpact, Le Journal Du Net, et surtout chez Numerama). Voici ma modeste contribution d’intégrateur revenant sur ce qui a été annoncé, et sur ce qui pourrait changer dans le petit monde des standards du web.

Mais pour commencer, il faut bien comprendre ce que sont le W3C et le WHATWG.

Le W3C et le WHATWG

Le W3C est un organisme de normalisation, créé en 1994 par Tim Berners-Lee. Son but est de définir et promouvoir des normes libres et ouvertes pour le web. Le W3C s’occupe de standards tels que HTML, CSS, SVG, WOFF, XML, XSLT, HTTP. Administrativement, le W3C est une « institution hébergée » dirigée conjointement par le MIT, l’ERCIM et la Keio University. Le W3C est composé d’une équipe de 62 personnes à temps plein, et d’environ 350 membres participants au total. Le W3C est financé par les inscriptions de ses membres (entre 1950€ et 68000€ pour la France), par des fonds de recherches privés ou publics, et par des dons individuels.

Le WHATWG est un groupe communautaire en ligne, créé en 2004 par des membres d’Apple, Mozilla et Opera après un workshop du W3C, lors duquel ils ont relevé leur inquiétude face au désintérêt du W3C pour HTML par rapport à XHTML. Le but du WHATWG est de définir et faire évoluer les spécifications HTML, et certaines APIs intrinsèques (Web Storage, Web Workers, Web Sockets, …). Administrativement, le WHATWG n’a pas d’existence, c’est simplement une communauté sur le web. Le WHATWG est dirigé par un petit comité, le nombre de membres est illimité et la participation est gratuite.

Le principal intérêt du WHATWG, c’est de regrouper des développeurs web anonymes et des fabricants de navigateurs également membres du W3C. La volonté du WHATWG est de permettre une pratique beaucoup plus pragmatique des standards, là où le W3C a des processus de standardisations très administratifs et très longs. A titre d’exemple, les spécifications de CSS2.1, dont le premier brouillon a été publié en août 2002, sont devenues une Recommandation W3C seulement le 7 juin 2011. Il y a quelques années, le WHATWG estimait qu’à ce rythme, HTML5 deviendrait une Recommandation W3C en 2022. Le W3C a aujourd’hui comme objectif de faire de HTML5 un standard en 2014.

Pour bien comprendre la place du W3C sur le web aujourd’hui, j’aime bien faire la comparaison entre le W3C et l’Académie Française. L’Académie Française est l’institution qui s’occupe de normaliser et perfectionner la langue française. Pour formaliser ses avancées, l’Académie Française publie un dictionnaire, une à deux fois par siècle. Actuellement, on en est à la 9ème édition (mais seulement jusque la lettre Q). Le travail de l’Académie Française est avant tout un travail normatif, qui dixit Wikipédia « cherche à préserver en l’état la langue française littéraire, telle qu’elle devrait être écrite ». A l’opposé, des sociétés privées publient des dictionnaires annuellement, comme Le Petit Larousse ou le Petit Robert, « qui visent à décrire l’état de la langue française telle qu’elle est parlée aujourd’hui ». Ça a permis de voir arriver de nouveaux mots dans le Petit Larousse 2012, comme alien, jouabilité, ou abracadabrantesque. Mais ça ne signifie pas que ces mots n’existaient pas auparavant. Et surtout, peu importe le travail de l’Académie Française, ça n’empêche pas les gens de parler « comme c’est qu’ils veulent » (je sais de quoi je parle, j’habite dans le Nord). C’est un peu la même chose avec le W3C : les développeurs web et fabricants de navigateurs restent libres de tout néologisme.

HTML, HTML5 et HTML.next

Le 19 juillet dernier, Ian Hickson (un ancien de chez Netscape et Opera, actuellement chez Google, et auteur des spécifications HTML au sein du W3C et du WHATWG) annonçait sur une mailing list du WHATWG :

Il y a quelques années (vers 2007), nous avons commencé à travailler avec le W3C sur ce nous appelions officieusement « HTML5 », et officiellement « Web Applications 1.0 ». Nous avons renommé la spécification en « HTML5 », et le W3C a commencé la publication d’une copie en même temps. Peu de temps après, l’équipe en charge de ces essais au sein du W3C a décidé de séparer leur version des spécifications en sous-spécifications (ex : séparer l’API 2D canvas, les événements serveurs, postMessage, etc.), et pendant un temps nous avons essayé de reproduire cela de notre côté au WHATWG. Le résultat a été l’augmentation de la confusion des versions de ces spécifications, alors nous avons fini par revenir à une seule spécification du côté du WHATWG qui contient tout ce sur quoi nous travaillons, que nous appelons désormais « HTML Living Standard ». Au fil des années, ce document et les documents du côté du W3C ont doucement bifurqués, comme documenté en haut des spécifications du WHATWG.

Plus récemment, les objectifs du W3C et du WHATWG sur le front HTML ont divergé également. Les efforts du WHATWG se sont concentrés sur le développement de la description canonique de HTML et des technologies associées, ce qui inclut la correction des bugs dès qu’on les trouve, l’ajout de nouvelles fonctionnalités dès qu’elles deviennent nécessaires et viables, et plus généralement le suivi des implémentations. Les efforts du W3C, pendant ce temps, sont maintenant concentrés sur la création d’un instantané développé selon le vénérable processus du W3C. Cela a poussé les présidents du groupe de travail HTML du W3C et moi même à décider de diviser le travail en deux, avec une personne responsable de l’édition des spécifications de HTML5, canvas et des microdata pour le W3C différente de celle qui édite les spécifications du WHATWG (moi).

En réalité, deux versions de HTML5 cohabitent déjà depuis plusieurs années. Comme le précise Ian Hickson, les différences sont particulièrement bien détaillées dans l’entête des spécifications HTML du WHATWG. A titre d’exemple, le W3C tolère l’utilisation de <table> pour faire de la mise en page (en utilisant l’attribut role="presentation"), alors que le WHATWG l’interdit strictement. Autre exemple : le WHATWG a introduit un nouvel attribut download, pour l’instant totalement ignoré par le W3C, mais déjà implémenté dans Chrome.

L’objectif de Ian Hickson, et du WHATWG, est donc désormais de faire de HTML un standard vivant, en constante évolution, et adapté au rythme de mise à jour des navigateurs comme Chrome et Firefox. Cela peut sembler nouveau et effrayant, mais comme le précise Ian Hickson dans un message sur Google+ :

Notez que nous savons que ce système marche. HTML a été développé en modèle de « standard vivant » (appelé « working draft » et « editor’s draft » par le W3C) depuis maintenant 7 ans et demi. Au cours de cette période, l’intéropérabilité sur le web est devenue incroyablement meilleure qu’elle ne l’a jamais été sur l’ancien système « instantané ».

Une autre crainte ressentie dans certains articles ou commentaires, serait que cette nouvelle spécification vienne remettre en cause des spécifications validées par le W3C et déjà implémentées par les navigateurs. Là encore, Hickson se veut rassurant :

Avec un standard vivant, on ne peut pas changer des choses arbitrairement. Les seuls changements possibles sont l’ajout de nouvelles fonctionnalités, le changement de fonctionnalités pas encore implémentées ou qui n’ont eu qu’une implémentation expérimentale, et des changements pour amener la spécification encore plus en accord avec ce qui est nécessaire pour une communication infaillible, c’est à dire la correction de bugs dans la spécification.

Dans la pratique, je pense qu’il n’y a pas grand chose à craindre sur l’état des spécifications de HTML5 telles qu’elles existent aujourd’hui. Par contre, j’ai quand même quelques réserves sur ce qui arrivera après : HTML.next (« l’après HTML5 » dixit le W3C). Dans le meilleur scénario, le W3C continuera de s’inspirer des spécifications établies par le WHATWG, et les navigateurs pourront implémenter la version de leur choix, selon leur rythme de mise à jour.

Dans le pire des scénarios, les spécifications HTML du W3C et du WHATWG finissent par totalement différer dans quelques années, et les navigateurs choisissent d’implémenter seulement une version. En sachant que le WHATWG ne compte aujourd’hui aucun membre de chez Microsoft, ce ne serait pas totalement improbable de voir une version d’Internet Explorer supporter uniquement les spécifications HTML du W3C.

Mais pour l’heure, ces deux scénarios ne sont que des suppositions, et il ne reste donc qu’à suivre l’adage habituel : wait and see.

Après un premier et un deuxième trimestre exceptionnels, Apple a présenté hier ses résultats pour le troisième trimestre 2012.

La société a publié un chiffre d’affaires pour le trimestre de 35 milliards de dollars et un bénéfice de 8,8 milliards de dollars. […]

La société a vendu 26 millions d’iPhones au cours du trimestre, représentant une hausse de 28% par rapport au même trimestre l’année précédente. Apple a vendu 17 millions d’iPad au cours du trimestre, soit une hausse de 84% par rapport au même trimestre l’année précédente. La société a vendu 4 millions de Mac au cours du trimestre, soit une hausse de 2% par rapport au même trimestre l’année précédente. Apple a vendu 6,8 millions d’iPod, soit une baisse de 2% par rapport au même trimestre l’année précédente.

Des résultats en baisse par rapport aux deux précédents trimestres, mais toujours en hausse par rapport aux années précédentes. Quelques chiffres en vrac, annoncés au cours de ces 6 derniers mois :

• Apple écoule la totalité de son inventaire en 5 jours, là où il en faut 45 pour une société typique de production, 21 pour Samsung, et 10 pour Dell. (source)
• Chaque seconde, il se vend plus d’iPhone qu’il n’y a de bébés qui naissent dans le monde (source)
• Apple a vendu ce trimestre 1,3 millions d’Apple TV. Même si la comparaison n’est pas tout à fait pertinente, c’est plus que ce qu’a vendu Microsoft de Xbox ce trimestre. (source)
• Ces 3 derniers mois, Apple a fait 97 777 777$ de bénéfices, chaque jour. (via)

Encore une fois, que vous aimiez ou détestiez Apple, ces chiffres sont hallucinants. Je racontais il y a quelques semaines que Google est le nouveau Microsoft. Apple est là où aucune autre société informatique n’a jamais été.

En début d’année, kangax mesurait la performance des propriétés CSS3 (box-shadow, border-radius, transform, …). Résultat : ces propriétés sont gourmandes en temps de calcul. Cependant, je suis convaincu qu’en comparant tous les critères de qualité d’une intégration, l’utilisation de ces propriétés CSS3 reste une meilleure solution que l’utilisation d’images, de JavaScript ou de Flash.

Parce que sur le web, en intégration, tout a un coût. Je ne parle pas d’argent, mais de l’impact sur le poids, le temps de chargement, le temps de rendu, l’interopérabilité, et la facilité de maintenance d’une page web. La moindre ligne de code que vous ajoutez a un coût. Le moindre effet visuel a un coût. La moindre fonctionnalité a un coût.

Au fil du temps, j’ai fini par me construire le modèle mental suivant.

C’est une estimation personnelle du coût de l’utilisation de CSS3, d’images, de JavaScript ou de Flash. C’est une estimation allant de 0 à n, sans unité, valable quasiment aussi bien en Ko de poids de téléchargement, en millisecondes de temps de rendu de page, ou en difficulté de maintenance. Le premier échelon, représente le code HTML et CSS le plus petit possible pour représenter une page avec toutes ses fonctionnalités. La répartition du coût d’utilisation de CSS3, d’images ou de JavaScript peut varier selon les cas, mais restera la plupart du temps dans cet ordre.

Prenons un exemple : vous devez utiliser une police non web. Vous avez le choix. Vous pouvez utiliser des images, mais vous réduirez considérablement la maintenabilité de votre site, nécessitant une retouche d’image pour la moindre retouche de texte. Vous pouvez utiliser les déclarations font-face de CSS3, mais qui imposent d’emblée un lourd surpoids et un énorme surcoût de rendu. Vous pouvez utiliser des librairies JavaScript, comme Cufón, mais vous ne rajoutez qu’une couche supplémentaire côté client très coûteuse. Et dans le pire des cas, vous pouvez utiliser une solution en Flash, comme sIFR. Dans cet exemple, la répartition de CSS3, des images et de JavaScript se ferait clairement dans la zone orange/rouge du modèle ci-dessus. Quelque soit la technologie utilisée, le coût de l’utilisation d’une police non web est très important. Mais CSS3 reste la moins pire des solutions.

Autre exemple : vous devez faire des bords arrondis. Vous pouvez utiliser 1 ligne de CSS3. Cette ligne sera relativement lourde à exécuter par le navigateur, mais rapide à télécharger et facile à maintenir. Si vous devez supporter des navigateurs plus anciens, vous pouvez ajouter quelques balises supplémentaires puis utiliser des images de fond pour chaque coin. Même en utilisant des sprites et en simplifiant au mieux votre code, vous alourdissez quand même votre page HTML et le nombre de requêtes pour faire ça. Vous pouvez alors utiliser un fichier JavaScript qui exécutera des bords arrondis uniquement pour les navigateurs nécessiteux (comme border-radius.htc). Mais en faisant cela, vous alourdissez de manière considérable le poids et le temps de rendu de votre page.

Si les intégrateurs ont parfois l’air de rechigner à intégrer certains éléments graphiques (comme une liste déroulante personnalisée), ce n’est pas probablement par fainéantise, mais plus par conscience du coût engendré sur la page web.

Si les intégrateurs sont enthousiastes de l’arrivée de CSS3, ce n’est pas par esprit de revanche, mais parce que les propriétés CSS3 diminuent considérablement le coût des choses. Mais elles ne font que le diminuer.

Que vous soyez chef de projet, graphiste, ou développeur, il est impératif de garder toujours en tête que quoi que vous fassiez, ça aura un coût sur le web. Si de plus en plus de sites adoptent un design minimaliste, ce n’est pas forcément par style, mais bien parce que sur le web, c’est une nécessité.

L’excellent Jeff Atwood (de Stack Overflow) a rassemblé sur son blog quelques exemples de jargon de développeurs, ces expressions inventées qui collent parfaitement à une situation souvent rencontrée en développement. J’avais déjà twitté un article basé sur le même sujet il y a 2 ans, et j’aime bien découvrir de nouvelles expressions de ce type.

Voici mes cinq préférées.

1) Les conditions de Yoda

Utiliser if(constant == variable) au lieu de if(variable == constant), comme par exemple if(4 == foo). C’est comme dire « si bleu est le ciel » ou « si grand est le monsieur ».

2) Les accolades égyptiennes

Désignent des accolades écrites avec l’accolade ouvrante sur la même ligne que le bloc d’instruction, comme ceci :
if (a == b) {
alert("hello");
}


3) Bugfoot

Un bug qu’une seule personne a vu, et qui n’a jamais été revu depuis.

4) Moustache

Vu chez apgwoz, la moustache est tout simplement un petit nom pour désigner une accolade.

5) Bébé ours, Maman ours et Papa ours

Vu chez CSS-Tricks, c’est une autre façon de nommer les versions responsives d’un site.

// Papa ours
@media (max-width: 1600px) { }
// Maman ours
@media (max-width: 1250px) { }
// Bébé ours
@media (max-width: 650px) { }

Le week-end dernier, le Wall Street Journal annonçait que Digg allait être racheté par le groupe betaworks pour 500 000$. À peine 2 ou 3 ans plus tôt, le site était estimé à plus de 160 millions de dollars.

Avant cette annonce, j’avais complètement oublié Digg. Pourtant, entre 2006 et 2010, j’étais un gros visiteur de Digg. Je ne postais pas, mais j’adorais venir sur le site tous les jours et découvrir du nouveau contenu. C’était probablement le premier réseau social pour lequel j’avais un réel engouement. Avec cette annonce, des tas de souvenirs me sont remontés d’un seul coup.

Son fondateur, Kevin Rose, et ses shows à l’Américaine. MrBabyMan, le membre du site le plus actif dont le moindre post atteignait la page d’accueil. L’histoire de 09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0. Et puis en 2010, il y a eu la V4, ses plantages fréquents, son algorithme modifié pour pousser davantage de contenus promotionnels, la DiggBar, et la fuite d’une très grande partie de ses utilisateurs vers Reddit.

Et puis des souvenirs encore plus anciens me sont remontés. En 2003, j’avais regardé la première « émission » de Kevin Rose sur le hacking et le social engineering : The Broken. Et je me souvenais particulièrement de la séquence Hacking with Ramzi :

http://www.youtube.com/watch?v=fDFXaqDf8kk

Le rachat de Digg aurait pu me laisser totalement indifférent. Sauf qu’hier, la nouvelle équipe du site chez betaworks a présenté son projet : Rethink Digg.

Comme l’ont annoncé betaworks et Digg sur leurs blogs, nous allons prendre le contrôle de Digg et en refaire à nouveau une startup. Ce qu’ils n’ont pas mentionné, c’est que nous allons le reconstruire de zéro. En six semaines.

Le 1er août, après six semaines pleines de caféine et d’adrénaline, nous allons sortir une nouvelle v1.

Je suis sceptique, mais j’ai hâte de voir ce que ça va donner.