HTeuMeuLeu

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.

Vous connaissez cette sensation lorsque vous répétez un mot tellement de fois à la suite qu’il finit par perdre tout son sens et devenir incompréhensible ? C’est une sentation qu’on appelle la satiété sémantique :

La satiété sémantique arrive brusquement, quand votre langue trébuche sur chaque syllabe, le mot n’étant plus qu’un assemblage hétéroclite de lettres dénué de toute signification. Il faut alors quelques secondes – parfois même quelques minutes – pour désinhiber notre cerveau et lui faire admettre à nouveau que « placard » n’est pas un néologisme ! À lui seul, le terme de satiété sémantique explique parfaitement le concept : on n’a littéralement « plus faim du sens », notre cerveau est rassasié du contenu.

Récemment, j’ai eu le même sentiment en travaillant sur l’intégration d’un champs de recherche, et en regardant l’icône de loupe utilisée. La maquette ne présente pas de problèmes en elle-même. Mais au bout d’un certain temps, mon cerveau a complètement perdu le sens de la loupe.

« C’est bizarre », me suis-je dit. « Je n’ai jamais utilisé de loupe de ma vie pour chercher quelque chose. Une loupe, ça permets de voir des détails. C’est l’icône idéale pour un bouton de zoom. Mais pas pour une recherche. C’est quand même bizarre d’utiliser exactement le même symbole, la même icône, la même métaphore, pour deux fonctions totalement différentes. »

Totalement écervelé, je suis allé bêtement poser la question sur StackExchange, en cherchant à retrouver l’origine de l’utilisation d’une icône de loupe comme symbole de recherche. Il se trouve que ça tient principalement à deux clichés.

Le détective cherche des indices avec sa loupe. Le scientifique cherche des détails microscopiques avec sa loupe. Et c’est tout. C’est une sacrément bonne métaphore quand vous n’avez jamais fait ça de votre vie, mais que c’est pourtant bien ancré dans votre inconscient via des lectures, films et séries de votre jeunesse.

D’après les réponses sur StackExchange, un des premiers logiciels à utiliser la loupe comme icône de recherche fut le système d’exploitation NeXT (la boîte lancée par Steve Jobs après son éviction d’Apple), à la fin des années 80.

L’icône fut ensuite reprise dans des produits plus grands publics, comme le Newton d’Apple , les premiers Palm Pilot, puis démocratisée dans Windows 95. Alternativement, la recherche était de temps en temps représentée par des jumelles (comme dans Word), une lampe torche (comme dans Netscape), ou illustrée par un chien (comme dans Windows XP, ou chez Lycos).

Mon cerveau est désormais rassasié, et je peux continuer à travailler tranquillement.

J’ai le sentiment qu’il existe chez certains webdesigners la conviction d’être des artistes, et que les designs de sites web se doivent d’être des chefs d’oeuvres représentatifs de leur art. C’est complètement faux.

Le webdesign n’est pas un art.

Et c’est même tout sauf ça. En mars dernier, Christopher Butler expliquait ça très bien dans son article « Your ego is a bad designer » :

La différence fondamentale entre le design et l’art réside dans ceux pour qui chacun est au service. L’art est au service de l’artiste; c’est un véhicule d’expression de soi. A partir de là, il est au service des autres simplement en existant, en donnant de l’inspiration, en montrant ce qui est possible. Le design, à l’opposé, ne devrait jamais servir le graphiste en premier. Le graphiste rend toujours un service à quelqu’un d’autre. Le design est au service du client, et le processus de servir le client sert au graphiste. Contrairement à l’art, le design n’est pas un véhicule d’expression de soi. (Les designers peuvent s’exprimer à travers leur travail; le bon design n’en a pas besoin.) En d’autres mots, le design ce n’est pas totalement à propos de vous.

Vous pouvez détester autant que voulez les peintures de Picasso, les films de Tarantino ou la musique de Sufjan Stevens, ça n’enlève rien au fait que ce sont des artistes. Leurs oeuvres sont imprégnées de leur personnalité. Vous aimez ou vous n’aimez pas. Vous comprenez ou vous ne comprenez pas. Ça marche bien commercialement ou ça ne marche pas. Peu importe.

Par contre, si vos internautes ne comprennent pas comment fonctionne votre site, s’impatientent devant un formulaire super long à charger parce que vous avez cru bon d’utiliser des listes déroulantes personnalisées, ou bloquent devant des ombres physiquement improbables, ils sont tout à fait en droit de vous haïr personnellement.

Il y a déjà presque 5 ans, Jeffrey Zeldman (le papa de « A List Apart » et des livres « A Book Apart ») expliquait comment « Comprendre le webdesign » :

Le webdesign ce n’est pas le design de livres, ce n’est pas le design de poster, ce n’est pas l’illustration, et les plus grands accomplissements de ces disciplines ne sont pas le but recherché par le webdesign. Bien que certains sites web peuvent être des moyens pour diffuser des jeux et des vidéos, et bien que ces moyens de diffusions peuvent être agréables à regarder, de tels sites sont des exemples du design de jeux et du storytelling vidéo, pas du webdesign. Alors qu’est-ce que le webdesign ?

Le webdesign est la création d’environnements numériques qui facilitent et encouragent l’activité humaine; qui reflètent ou s’adaptent à des voix et des contenus individuels; et changent gracieusement au cours du temps tout en maintenant leur identité.

Répétez ça, en mettant l’accent :

Le webdesign est la création d’environnements numériques qui facilitent et encouragent l’activité humaine; qui reflètent ou s’adaptent à des voix et des contenus individuels; et changent gracieusement au cours du temps tout en maintenant leur identité. 

En juin dernier, l’excellent Benoït Meunier détaillait sur son blog le travail d’un (web) designer :

Votre travail n’est pas toujours aussi cool et amusant que vous pouvez le croire. Il est très souvent clérical. C’est aussi un travail scientifique de recherche, d’analyse. Vous êtes aussi un psychologue qui cherche l’écoute et non le prochain pitch. Vous connaissez aussi tous les recoins du projet par coeur. Vous en connaissez aussi les implications fiscales et l’évolution d’affaires ne vous est pas étrangère.

Votre travail demande aussi de regarder les statistiques, d’évaluer le comportement, de synthétiser des montagnes de données pour permettre une meilleure décision et par la suite, proposer d’enlever un lien, de modifier un titre, de faire des tests sur le meilleur adverbe d’un appel à l’action.

Votre travail c’est aussi ça.

Vous n’êtes pas Don Draper. Vous devez travailler fort, sur quelques pixels parfois pas très sexy mais cruciaux à une bonne expérience.

Vous êtes payé pour cela. Faites-le bien.

J’ai le sentiment qu’en France, la vue du webdesign comme un art est particulièrement accentuée  à cause du titre de « Directeur artistique ». Dans certaines agences web, vous pourrez rencontrer toute une bande de directeur et directrice artistique. Certains sont effectivement des directeurs artistiques, et suivent et dirigent des shoots photos, des conceptions vidéos, etc… Mais certains sont en réalité des webdesigners. Cette simple mention sémantique joue dans l’inconscient des clients et des webdesigners eux-mêmes que le webdesign a un rôle artistique.

Si vous êtes dans ce cas-là, arrêtez de vous appelez directeur artistique. Vous êtes peut être un designer d’Interface Utilisateur, ou alors un Architecte de l’Information. Mais sur le web, vous n’êtes pas un directeur artistique.

Le webdesign n’est pas un art.

De temps en temps, je reçois une maquette avec un formulaire à intégrer qui contient quelque chose comme ça :

Ceci est une liste déroulante personnalisée. C’est vachement pratique pour repérer les webdesigners débutants, les graphistes print qui font du web, ou encore les webdesigners qui pensent que le design est la finalité d’une page web (indice : ce n’est pas le cas).

Si vous êtes intégrateur, vous savez déjà que vous allez devoir faire quelque chose de très sale pour arriver à ce résultat graphique. Les contrôles de formulaires sont par défauts très limités à modifier en CSS. Ceci est dû au fait que ce sont en fait des éléments remplacés par le navigateur par des contrôles propres au système d’exploitation. L’avantage, c’est que le formulaire pourra s’adapter au fonctionnement du système d’exploitation. Par exemple sur iOS, vous aurez droit à la roue du juste prix. L’inconvénient, c’est que vous êtes assez limité au niveau de la présentation.

CSS3 apporte quelques solutions (notamment avec la propriété appearance), mais on est loin d’une solution universelle. La moins pire des solutions à l’heure actuelle consiste à utiliser du JavaScript pour remplacer les contrôles de formulaire par de faux contrôles. La bibliothèque Uniform (en jQuery) fait ça plutôt bien.

Mais ça implique d’énormes compromis. Il y a quelques semaines, Aviv Ben-Yosef rappelait sur son blog pourquoi il faut éviter les faux contrôles de formulaires en HTML.

Voici une liste des pour et contre de l’utilisation de tels contrôles graphiques.

Pour : 

• C’est joli.

Contre :

• Ça alourdit le temps de téléchargement de la page, et donc aussi le nombre de requêtes.
• Ça ralentit le chargement de la page côté client. Vous devrez attendre que tous vos scripts soient chargés avant de pouvoir utiliser votre formulaire.
• Ça diminue l’ergonomie de votre site. Les contrôles de formulaires système ont l’avantage d’être familiers pour les internautes. Même si vous avez fait une charte de liste déroulante super jolie et ergonomique, ça demandera du temps de compréhension supplémentaire à vos visiteurs.
• Ç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. Mais rien ne vous garantit que ça ne fonctionnera encore sur les machines de demain.
• Ça détruit l’accessibilité de votre page. Les faux contrôles générés en HTML deviennent totalement inutilisables.
• Ça a un impact sur le temps d’intégration, et donc le coût de votre projet.

Par pitié, n’imposez pas ça à vos visiteurs.

Médiamétrie a publié aujourd’hui une étude sur la fréquentation des sites internet selon les systèmes d’exploitation mobiles :

Android, l’OS de Google, a dépassé le système d’exploitation mobile d’Apple – iOS – depuis le mois de mars 2012 et représente désormais plus d’un accès mobile sur deux en juin 2012. En nombre de visites, Android a progressé de 29 % entre les mois de janvier et juin.

En parallèle, iOS, passe de 52,5 % à 36 % entre les mois de janvier et juin, soit une baisse de 38 %.

J’ai un peu de mal à croire cette étude. En novembre dernier, je constatais que les vrais gens n’utilisent pas Android pour surfer. Depuis, le nombre d’appareils vendus sous Android a encore doublé, annoncé à 400 millions lors de la Google I/O la semaine dernière. Pourtant les statistiques n’ont pas l’air d’avoir beaucoup bougé.

D’après NetMarketShare, en novembre 2011, 16,70% des internautes mobiles mondiaux étaient sur Android, contre 54,05% sur iOS. En juin 2012, on est à 19,73% sur Android contre 65,27% sur iOS. D’après StatCounter, en novembre 2011, 29,33% des internautes mobiles français étaient sur Android, contre 58,31% sur iOS. En juin 2012, on est à 36,12% sur Android contre 53,8% sur iOS.

Et même sur mon petit blog, que je considère dédié à une cible particulièrement high-tech, je ne constate pas le changement annoncé par Médiamétrie. En novembre dernier, j’avais 2,8% de visiteurs sous Android contre 8% sur iOS. Le mois dernier, j’avais 3,8% de visiteurs sous Android contre 9,5% sur iOS.

Et c’est valable pour tous les sites clients que j’ai pu réalisé. Je constate bien une hausse des visites sur Android, tout comme sur iOS. Mais dans tous les cas iOS reste le système majoritaire devant Android.

Mais ne faisons pas de ces statistiques une généralité. Et il y a peut être bel et bien une exception culturelle française sur les plus gros sites. Le principal changement dans le paysage mobile français ces 6 derniers mois, c’est l’arrivée de Free Mobile. En mai dernier, Free annonçait avoir déjà plus de 2,6 millions d’abonnés mobile. On peut supposer qu’une partie des nouveaux clients chez Free ont opté pour un nouveau mobile lors de leur inscription. Au même moment, Free annonçait avoir vendu pour 11,5 millions d’euros de terminaux. Avec des téléphones vendus au prix fort entre 40€ et 785€, ça fait entre 15 000 et 288 000 téléphones vendus (iOS, Android et Blackberry confondus). Je ne pense pas que 300 000 téléphones suffisent à faire basculer le paysage mobile français sur Android.

Je suis intimement persuadé que les résultats de médiamétrie sont totalement faux. Et j’ai deux hypothèses pour expliquer les erreurs de leurs mesures.

La première, suggérée par TOMHTML, est que les mesures de l’étude concerneraient uniquement les réseaux cellulaires, et non les réseaux Wi-Fi. Les chiffres d’Akamai confirmeraient alors ceux de Médiamétrie. Mais l’étude ne fait absolument pas mention du type de réseau, et ça me semblerait assez saugrenu de faire une étude uniquement sur des réseaux cellulaires sans le mentionner.

Ma deuxième hypothèse est que les mesures de Médiamétrie sont tout simplement erronées. Cette étude se base sur les visites des plus gros sites des principaux groupes français, soit près de 250 sites au total : pagesjaunes.fr, skyrock.com, jeuxvideo.com, doctissimo.fr, clubic.com, premiere.fr, etc… Pour obtenir des statistiques, les sites doivent inclure le script eStat de Médiamétrie. A ma grande surprise, je suis tombé sur une grosse erreur dès mon premier essai.

Si vous visitez pagesjaunes.fr sur ordinateur (le site n°1 en juin d’après médiamétrie avec plus de 77 millions de visites), vous accédez au site classique, qui inclut correctement le tag eStat. Par contre, si vous visitez pagesjaunes.fr sur mobile, vous êtes redirigés automatiquement sur mobile.pagesjaunes.fr, qui lui n’inclut plus du tout le tag eStat, mais utilise à la place le concurrent de Médiamétrie, Xiti.

Même constat sur le site mobile de Doctissimo (n°4 avec 40 millions de visites), France 3 (n°7 avec 9,7 millions de visites), France 2 (n°8 avec 9,6 millions de visites), Elle.fr (n°14 avec 4,6 millions de visites), etc…

L’explication la plus rationnelle pour moi est que ces 6 derniers mois, de nombreuses marques ont lancé un site mobile dédié. Ces sites mobiles n’intègrent pas tous correctement le tag eStat de Médiamétrie. Les internautes mobiles sont quand même redirigés automatiquement vers ces sites, notamment « grâce » à du sniffing d’agent utilisateur. Si ce sniffing n’est pas fait correctement (laissant potentiellement de côté des vieilles versions d’Android, ou privilégiant systématiquement les iPhones), les utilisateurs d’Android peuvent alors se retrouver sur le site classique, et ainsi faire gonfler les chiffres de Médiamétrie.

CQFD.

Mise à jour du 05 juillet : contactés par mes soins sur Twitter, PagesJaunes confirme « que le résultat est surprenant. Il ne correspond pas à ce que l’on constate pour notre appli »

Cette semaine, Benjamin De Cock écrivait sur son blog un article contre les applications web, en faveur des applications natives.

J’ai pris mon actuel écran d’accueil [sur mon iPhone] comme exemple. Combien d’apps serais-je capable de recréer aujourd’hui en ciblant uniquement la dernière version de Safari Mobile et sans sacrifier aucune fonctionnalité ? Indice : aucune.

• Alarme: Oubliez la fonctionnalité la plus utile : l’alarme.
• Calendrier: Les alertes d’événements ne peuvent pas être implémentées.
• Photos: Vous ne pouvez pas stocker 1000 photos et vidéos en cache.
• Appareil photo: Forcément, non.
• Réglages: Vous ne pouvez pas modifier les réglages, évidemment.
• Rappels: Vous ne pouvez pas créer de vrais rappels.
• Reeder: Vous ne pouvez pas partager un article par SMS.

Je ne savais même pas qu’on pouvait partager un article par SMS dans Reeder. Et je ne pense pas qu’utiliser Safari Mobile comme référence de fonctionnalités HTML5 soit très pertinent (au contraire). En théorie, il existe des API HTML5 (en cours d’écriture ou déjà implémentées) pour quasiment toutes les fonctionnalités décrites.

Mais il marque un point : les applications web, on n’y est pas encore tout à fait.

La semaine dernière, Facebook a annoncé la sortie prochaine d’une nouvelle version beaucoup plus rapide de son application iOS, abandonnant HTML5 au profit d’Objective-C.

Mais d’un autre côté, on voit naître actuellement une tripotée de systèmes d’exploitation poussant les applications web : Google et Chrome OS, Mozilla et Firefox OS, Microsoft et l’interface Metro de Windows 8. Alors est-ce cela signifie qu’on va avoir des OS au rabais avec des applications web amputées ? C’est très certainement le cas aujourd’hui (cf. les tests des derniers Chromebooks sur Chrome OS), mais je pense qu’il faut ajouter d’autres arguments dans la balance.

Pour moi, les applications web résolvent deux problèmes de longue date dans l’informatique :

• L’universalité d’une application : En codant en HTML5, en respectant les standards, vous êtes à peu près certains de pouvoir faire tourner votre application sur n’importe quel navigateur et plate-forme compatible. Bien sûr, il y aura toujours des cas particuliers à gérer. Mais comparez ça avec le casse-tête actuel du développement mobile (iOS, Android, Windows Mobile), et ce n’est pas dur de voir l’avantage du web en tant que plate-forme. L’adage de Java se prête plutôt bien (« Write once, run everywhere »), même si sa parodie aussi (« Write once, debug everywhere »).
• La pérennité d’une application : En codant en HTML5 aujourd’hui, il y a de grandes chances que votre application fonctionne encore dans 10 ans sur des appareils et des navigateurs totalement différents. A l’inverse, il y a de grandes chances qu’en choisissant une application native aujourd’hui, la plate-forme sur laquelle elle tourne soit totalement désuète d’ici 10 ans. J’expliquais déjà tout ça il y a quelques semaines en parlant de la rétro-compatibilité.

Alors forcément, en tant qu’intégrateur, mon point de vue est certainement un peu biaisé. Mais je pense que nous sommes dans une période un peu bancale. HTML5 n’est pas encore assez mûr pour permettre de réaliser n’importe quel type d’application de manière aussi performante qu’une application native. Mais développer aujourd’hui une multitude d’applications sur tout autant de plate-formes me semble un choix farfelu.

La semaine dernière, je suis tombé sur une vidéo de Shaun Inman (le Shaun Inman de sIFR, également développeur du sympathique Last Rocket) présentant son analyse du comportement de la caméra de Super Mario World.

Voici quelques détails sur le comportement de la caméra :

• Elle suit le joueur de gauche à droite.
• Si on change de direction, la caméra reste fixe tant qu’on ne bouge pas plus de 16px à gauche ou à droite.
• Elle est collée au bas de l’écran, sauf quand Mario sort ses petits bras pour s’envoler et qu’il décolle, où la caméra le suit en hauteur.
• Dans les niveaux sous-terrains, la caméra va se coller en haut de l’écran quand on est sur des plate-formes en hauteur.
• Dans les niveaux qui s’étendent en hauteur, la caméra suit Mario en hauteur dès qu’il atterrit sur une nouvelle plate-forme (mais pas pendant son saut).
• Sous l’eau, la caméra se détache et suit Mario.

J’ai probablement joué des dizaines et des dizaines d’heures à Super Mario World sur Super NES et sur GameBoy Advance. Je ne m’étais jamais rendu compte à quel point la caméra du jeu était élaborée, tellement elle semblait naturelle dans le jeu.

En août 2011, Twitter lançait Bootstrap, une boîte à outils HTML, CSS et JavaScript destinés à simplifier la création d’applications web. Bootstrap inclut un système de grille, des styles par défaut pour les principaux types de contenus, mais aussi le code nécessaire pour faire fonctionner les composants les plus courants qu’on retrouve sur des sites web (popups modales, messages d’alertes, carrousel, etc…).

Depuis février dernier, Bootstrap est le projet le plus populaire sur GitHub. La NASA utilise Bootstrap. La chaîne MSNBC utilise Bootstrap. Même la maison blanche utilise Bootstrap.

Je ne suis pas tout à fait certain que l’utilisation de Bootstrap était très pertinente dans ces 2 derniers cas. Et je ne suis en général pas trop friand de toute surcouche CSS. Pourtant, je pense que Bootstrap marque un pas important sur le web.

En mars dernier, j’étais tombé sur cet article de Dave Winer qui partageait ce point de vue :

J’étais développeur logiciel avant qu’il n’y ait un Mac, et je me souviens de quelque chose dont peu de développeurs se souviennent. Je me souviens comment l’industrie high-tech avait réagi. Et pour une grande partie, c’était avec pas mal de scepticisme. Et le truc intéressant c’est que les points négatifs que les gens trouvent à Bootstrap aujourd’hui sont exactement les mêmes que les points négatifs que les gens trouvaient au Mac en 1984. Et dans les deux cas, les choses que les gens n’aimaient pas étaient ce qui les ont rendu important.

Ce dont le Mac s’est rendu compte, c’est qu’il y avait un ensemble de choses que tous les logiciels devaient faire, alors pourquoi ne pas les faire toujours de la même façon ? En le faisant, les logiciels seraient plus faciles à développer et à débugger, mais surtout, plus faciles à utiliser. S’il y avait une seule façon de faire des menus, alors une fois que l’utilisateur aurait appris à se servir d’un menu dans une application, il saurait déjà s’en servir dans toutes les autres. La même chose est valable pour les scrollbars, les fenêtres, le clavier, la souris, l’imprimante, le son.

La raison pour laquelle les développeurs n’aimaient pas ça, et j’en faisais parti, est qu’ils ont pris ce que l’on faisait, et l’ont banalisé. De plus, il y avait des limites avec cette approche à taille unique. Il y avait des applications qui ne correspondaient pas très bien aux standards de l’interface. Que faire pour elles ? Et bien, vous adaptiez, voilà ce que vous faisiez.

De mon point de vue, Bootstrap est important parce qu’il permets en un minimum de temps et un minimum de connaissances d’avoir une application web ou une interface d’administration propre et fonctionnelle.

A l’instar des développeurs Flash, des développeurs applicatifs découvrent le web grâce aux nouveautés HTML5. Sauf que ça ne les intéresse probablement pas de passer des heures à faire de la mise en page en CSS. Grâce à Bootstrap, ces développeurs peuvent se concentrer sur le fonctionnement de leur application.

Aussi, je me souviens, au lancement de Bootstrap, avoir lu un tweet anglophone qui disait quelque chose comme ça :

Si vos interfaces d’administration ne sont pas aussi propres que Bootstrap, vous devriez vous poser des questions, ou alors rembourser vos clients.

Je pense que Bootstrap est aujourd’hui aussi important pour le monde de l’intégration que l’a été WordPress pour le monde du développement. Il y a 10 ans, les clients payaient beaucoup d’argent pour avoir un simple module d’actualités administrable avec un système de commentaires. Aujourd’hui, simplement en installant WordPress, vous avez ça de base, et bien plus. Il faut bien entendu faire attention à ne pas tomber dans une utilisation systématique de ces outils. Il m’arrive encore de travailler sur des petits sites institutionnels où WordPress n’a pas sa place. Mais c’est de plus en plus rare.

Si vous choisissez aujourd’hui d’intégrer une administration de site sans Bootstrap, vous avez intérêt à avoir de sérieux arguments.

Cette semaine, Google a sorti une version de Chrome sur iOS. Cependant, le moteur de cette version n’est pas celui de Chrome. Le moteur de rendu n’est pas le WebKit de Chrome, et le moteur JavaScript n’est pas le V8 de Chrome.

Ceci est dû à l’article 3.3.2 de la license du programme de développement sur iOS :

3.3.2 — Une application ne doit pas elle-même installer ou lancer d’autre code exécutable sous aucune façon, incluant sans limite à travers l’utilisation d’une architecture de plug-in, l’appel à d’autres frameworks, d’autres APIs ou encore différemment. Aucun code interprété ne peut être téléchargé ou utilisé dans une application sauf pour du code qui est interprété et exécuté par les APIs documentées par Apple et interpréteurs intégrés.

Cette règle bloque ainsi tout émulateur de jeux (sauf s’ils ont été réécris en Objective-C, comme Commodore 64), mais elle empêche aussi presque tout navigateur.

Les deux solutions pour créer un navigateur sur iOS sont alors :

• Exécuter tout le rendu et tout JavaScript côté serveur. C’est ce que fait Opera Mini. Ça leur permets d’optimiser le rendu de la page, et de compresser un peu plus la page téléchargée. Mais ça implique que toute action faite en JavaScript sera exécutée côté serveur, ce qui peut rendre la navigation beaucoup plus longue.
• Utiliser les API d’iOS pour afficher une page web. Cela signifie que vous utiliserez le moteur de rendu et le moteur d’exécution JavaScript de Safari. C’est ce que font la plupart des navigateurs sur iOS, comme Dolphin, Atomic ou désormais Chrome.

Le problème en utilisant cette deuxième solution, c’est qu’Apple bride son moteur JavaScript lorsqu’une page web est appelée dans une application (ou en raccourci plein écran sur l’écran d’accueil). Le résultat (vu hier sur Hacker News), c’est que Chrome sur iOS est jusqu’à 3 fois plus lent que Safari.

Ce comportement propriétaire d’Apple est clairement un frein à l’évolution du web sur mobile et à un marché compétitif sain. Alors qu’attendent Google, Firefox et les autres pour se plaindre ? Dans les années 2000, Microsoft avait été accusé d’abus de position dominante, profitant de son monopole sur le marché des systèmes d’exploitation pour développer un monopole sur le marché des navigateurs. Et bien la différence c’est qu’Apple n’a pas une position dominante sur le marché mobile. Cette place est occupée par Android. Apple est donc dans la position particulièrement confortable de pouvoir faire tout et n’importe quoi, le meilleur comme le pire, sans avoir à se soucier de réglementations du marché.

Et le plus drôle dans tout ça, c’est qu’en imposant désormais Chrome comme navigateur par défaut dans Android 4 et plus, c’est Google qui pourrait être accusé d’abus de position dominante.

Le petite casse-tête de cette semaine m’a fait réaliser quelque chose que j’avais en tête depuis quelques mois. Un bon effet CSS c’est comme une bonne blague. Pour que ça marche, ça doit être court, bien écrit et explicite. Voici un exemple :

Avez vous déjà remarqué que les femmes qui sont contre l’avortement sont des femmes que vous n’auriez pas voulu baiser en premier lieu ?

Ça, mesdames et messieurs, c’est George Carlin au Carnegie Hall en 1984. Ce n’est pas une blague qu’il sort en plein milieu du spectacle, après un long moment de préparation du public. Non. Il arrive sur scène, il salue le public et le remercie. Et il sort cette blague. Sérieusement, si vous ne connaissez pas George Carlin, regardez-le.

Ce genre de blague, c’est ce qu’on appelle en anglais une « one-liner« . Une blague courte, parfaitement racontée, et qui demande une petite seconde de réflexion avant de bien comprendre toute sa subtilité (un peu comme une doublette). Dans ce domaine, Demetri Martin est mon dieu vivant :

Dire « Je suis désolé » c’est la même chose que « Je m’excuse ». Sauf à un enterrement.

C’est vraiment la même chose en CSS. Un bon effet CSS, ça doit être :

• court : s’il vous faut 36 balises et autant de règles CSS, vous allez passer pour le lourdingue de service. Je pense que la séparation de la forme et du contenu devient enfin possible. Profitez-en.
• bien raconté : si vous écrivez du CSS, alors écrivez du CSS. Par pitié ne venez pas utiliser d’autres pseudo-langages et des tonnes de JavaScript.
• explicite : votre code doit être suffisamment ingénieux et explicite à lui tout seul. En reprenant l’exemple de mon casse-tête, la solution trouvée n’est pas la plus intuitive ni la première qui vient à l’esprit. Mais une fois qu’on la connaît, elle paraît évidente. Vous devez dans tous les cas éviter la surréflexion.

Mes effets préférés en CSS, comme mes blagues préférées, sont des one-liners.

Ce mois-ci, le magazine Entrepreneur a publié un article expliquant comment Marissa Mayer, la Vice Présidente des services locaux de Google, tenait le coup avec ses équipes en travaillant 130 heures par semaine :

Quand Mayer soupçonne un employé de s’épuiser, elle leur demande de trouver leur rythme. Et ils reviennent avec une demande, « Je dois être à la maison pour les dîners tous les mardi », ou « Je dois être à l’heure pour être aux matches de football de ma fille ». Elle concède à ses demandes, sans exception.

« Vous ne pouvez pas avoir tout ce que vous voulez », avertit Marissa. « Mais vous pouvez avoir les choses qui comptent vraiment pour vous. Ça vous permets de travailler vraiment dur pendant une longue période sur quelque chose qui vous passionne. »

Initialement, j’avais réagi sur Twitter en faisant une bonne blague bien grasse. Mais cet article est complètement dingue, et ce n’est pas très drôle.

130 heures par semaine, ça fait plus de 18 heures par jour, 7 jours sur 7. 18 heures par jour, ça vous laisse 6 heures pour dormir, manger, vous laver, vous divertir, voir votre famille, voir vos amis, vous évader. 6 heures par jour pour vivre.

En travaillant 130 heures par semaine, même à un salaire de 7000€ par mois, vous gagnez moins qu’en travaillant 35 heures par semaine pour 2000€ par mois.

Je travaille en tant qu’intégrateur depuis 6 ans. Je suis entrepreneur depuis 4 ans. J’aime mon travail. J’aime ma boîte. Mais s’il y a bien quelque chose que j’ai appris, c’est qu’il y a un équilibre à trouver. Il faut travailler pour vivre. Pas l’inverse. Peu importe le projet sur lequel vous travaillez, peu importe la mission dont vous vous sentez investi.

J’ai déjà travaillé plus de 100 heures par semaine. J’ai déjà travaillé plus de 35 heures en 2 jours. Je n’en garde aucun bon souvenir ni aucun enrichissement personnel. Il m’arrive encore de travailler un peu plus le soir, voire le week-end, quand j’ai des projets qui me plaisent particulièrement. Mais quand ça arrive, je considère que c’est un échec. Je trouve ça choquant de se vanter ainsi, et qu’une revue vante ces pratiques de travail sans aucun commentaire.

Ce genre d’histoires n’est pas spécifique à Google ni à Apple. C’est une parfaite illustration de la théorie espagnole, dont je vous parlais il y a quelques mois. Ça m’attriste de voir que des journalistes s’acharnent à dénoncer les conditions de travail d’ouvriers chinois, alors les « ouvriers » occidentaux ne sont pas mieux lotis.