Les articles du mois de avril 2012

Le skeuomorphisme est le principe d’imiter dans un objet un détail de conception qui n’est plus nécessaire, mais qui était indispensable autrefois. On trouve de nombreux exemples dans la vraie vie, comme l’imitation de rainures de bois sur des meubles en plastique, ou l’imitation du son de fermeture de l’obturateur sur un appareil photo numérique compact ou bridge. En informatique, on rencontre chaque jour pleins d’exemples. Le plus classique est l’utilisation d’une disquette comme icône de sauvegarde de documents.

Cet article de aKa chez FramaBlog nous rappelle également de manière amusante pourquoi les touches de nos claviers sont disposées ainsi :

Un beau matin de 1868, alors que les États-Unis résonnent encore des canons de la guerre de sécession, un bricoleur du Wisconsin du nom de Sholes invente la première machine à écrire. Sans se poser trop de question, il place logiquement les touches par ordre alphabétique.

Chaque touche appuyant sur une barre métallique horizontale qui ne peut pas frotter contre ses voisines, Sholes se voit dans l’obligation de décaler les rangées de touches, décalage qui est encore présent, sans aucune raison autre qu’historique, sur votre clavier, voire même sur les claviers virtuels des tablettes et des écrans tactiles !

Les champions du skeuomorphisme ces dernières années, ce sont Apple, qui usent et abusent d’effets skeuomorphiques dans leurs logiciels.

L’année dernière, James Higgs exprimait son mépris pour cette nouvelle tendance :

Il va sans dire que ma préférence va pour le design sans décoration, certainement sans un soupçon de sentimentalisme, et que je déteste ces nouvelles applications. Pourquoi ?

Pour faire simple : parce que ce sont des mensonges. Elles tentent de nous réconforter en essayant de nous montrer comment elles sont liées aux objets physiques du monde réel alors qu’il n’y en a pas besoin. En quoi sommes nous aidés à comprendre ce que fait l’application Localiser mes amis en y ajoutant des décorations en cuir ? Et à quel point ça peut être difficile pour quelqu’un, même un nouveau venu dans le numérique, de comprendre une liste de livres ? Est-ce que c’est si difficile, que la seule façon de le faire comprendre est de les présenter sous forme d’une bibliothèque en bois ?

Sur Snow Leopard, Photo Booth ressemblait à ça :

Puis est arrivé Lion, et son mode plein écran. Et voici venir le train du skeumorphisme :

Boom ! Des rideaux. Des panneaux en bois. Des boutons en métal. Vraiment, Apple ?

Encore une fois, regardons l’utilité de Photo Booth : prendre des photos, enregistrer des vidéos, et leur appliquer des filtres. La première version de Photo Booth rendait tout cela très facile et accessible. Par contre, elle ne communiquait pas le but de Photo Booth : faire l’idiot et s’amuser. Laissez-moi vous présenter un exemple :

Photo Booth est un jouet numérique. La première version de Photo Booth, bien que très propre et fonctionnelle, ne ressemblait pas à un jouet. Ce n’était pas amusant, et ça ne vous encourageait pas à jouer avec. Avec le nouveau mode plein écran, Apple utilise le skeuomorphisme pour inviter ses utilisateurs à s’amuser.

Le skeuomorphisme sert à communiquer et à renforcer des sentiments, à aider une application à devenir une expérience mémorable, et pas juste un outil. Ça aide à communiquer sur le but d’une Interface Utilisateur, et pas seulement sur les fonctionnalités qu’elle propose.

En février dernier, les différents fabricants de navigateurs (Mozilla, Opera et Microsoft) ont exprimé leur souhait d’interpréter certaines propriétés CSS3 avec le préfixe -webkit-. Le lendemain, Daniel Glazman (co-président du groupe de travail CSS du W3C) lançait un appel à tous les développeurs web pour éviter que cette situation ne se produise. Le message a été plutôt bien relayé par la communauté du développement web et du design web. Malheureusement hier, le magazine .NET rapportait qu’Opera s’apprêtait de manière imminente à implémenter et interpréter certaines propriétés avec le préfixe -webkit- :

Opera, aux côtés de Microsoft et Mozilla, ont annoncé lors d’une réunion du CSS Working Group qu’ils supporteraient certaines propriétés avec le préfixe WebKit. C’est parce que trop d’auteurs de sites mobile utilisent uniquement les propriétés avec un préfixe -webkit-, et même pas la version standard, sans préfixe, lorsqu’elle est disponible. Cela mène à une expérience utilisateur réduite sur Opera, Firefox Mobile et IE Mobile, qui n’affichent pas les mêmes effets à la mode, comme des transitions, des dégradés, même s’ils supportent ces effets.

Il y a trois mois, je résumais le ridicule de la situation, auquel j’ajoute aujourd’hui cette représentation Tarantino-esque de l’état du web.

Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Je l’ai dit hier et je le redis aujourd’hui : c’est une honte. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs favorisent leurs propres intérêts personnels au détriment du Web Ouvert. C’est particulièrement honteux de la part d’Opera et surtout Mozilla qui se vantent sans cesse de défendre le Web Ouvert.

Qu’on soit bien clair : l’origine de tout ce débat, l’origine du problème, ce n’est pas le W3C, ce ne sont pas les navigateurs. Ce sont nous, petits intégrateurs, qui sommes la cause de ce problème. Ou plutôt, les intégrateurs peu consciencieux ou peu avertis, qui utilisent uniquement des préfixes -webkit- sans se préoccuper des autres navigateurs.

Je me considère comme un intégrateur un minimum averti. Je travaille en agence depuis 6 ans, et je fait de la veille que je partage quotidiennement sur Twitter ou sur ce blog. J’estime être relativement au courant des nouveautés du web et en particulier en intégration. Au fil des années, de ma part mon travail et également via Twitter, j’ai rencontré et discuté avec des dizaines voire une centaine d’intégrateurs. Des intégrateurs freelance, des intégrateurs en agence, des intégrateurs chez l’annonceur pour de plus ou moins grands comptes. En dehors de la sphère Twitter et de la petite famille francophone de développeurs web, j’ai très souvent constaté qu’une bonne partie d’intégrateurs sont souvent mal renseignés sur leur métier. Dans certains cas, c’est parce qu’ils considèrent l’intégration comme un simple métier, et qu’ils n’éprouvent pas l’intérêt de faire une veille quotidienne. Dans d’autres cas, c’est par manque de temps et par épuisement. Par exemple, j’ai rencontré un jour une intégratrice qui travaillait dans une agence où elle devait intégrer chaque jour un site complet (de 10 à 20 pages). Difficile de trouver le temps de faire de la veille dans de telles agences.

L’origine du problème, c’est donc le manque de formation et de connaissances détaillées dans le web pour une grosse partie des intégrateurs, développeurs web ou webdesigners. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs ne vont pas résoudre l’origine du problème. Ils vont l’aggraver. Ces intégrateurs vont continuer à utiliser des propriétés avec le préfixe -webkit- uniquement, en se satisfaisant que ça fonctionne désormais partout. Mais ils ne se remettront pas en question, et ils n’aideront pas à rendre le web meilleur.

Alors quelle est la solution ?

Beaucoup d’intégrateurs souhaiteraient tout simplement l’abandon des préfixes navigateurs. Mais ces préfixes sont utiles et nécessaires. Ils permettent aux navigateurs d’implémenter des fonctionnalités en cours de définition par le W3C, et aux développeurs de les tester. Mais à tout moment, ces propriétés sont susceptibles de changer, pour être améliorées voire supprimer. C’est ce qui est arrivé avec les définitions des dégradés en background. La première syntaxe proposée par le W3C a été revue et adoptée par les autres navigateurs suite à la proposition d’une meilleure syntaxe par Mozilla.

Alors quelle est la solution ?

Je n’ai pas la prétention d’avoir une solution miracle. Mais par expérience, je sais une chose : si à un moment donné, un navigateur affiche un message alarmant à l’internaute sur un site donné, alors toute la hiérarchie d’une boîte va se réveiller pour que ce soit corrigé au plus vite. J’ai souvent rencontré le cas sur IE6. Sur IE6, quand vous êtes sur une page en HTTPS et que vous appelez une ressource en HTTP, le navigateur affichera une alerte à l’internaute lui demandant s’il souhaite afficher ou pas les contenus non sécurisés. A chaque fois que j’ai aidé des clients à résoudre ce problème sur leurs sites, croyez moi, toute la hiérarchie était sur le coup : des remontées du service téléphonique client au département marketing jusqu’à la direction générale. L’origine du problème vient également d’une mauvaise pratique de la part du développeur web, qui n’a pas pris le soin d’appeler des contenus sécurisés partout. Mais en corrigeant ce problème, le développeur web apprends quelque chose. Et s’il tient à sa survie, il y a de grandes chances qu’il retienne la leçon.

On pourrait alors imaginer un message d’alerte similaire, laissant entendre que le site a été mal conçu, et lui proposant d’améliorer le rendu du site. Si l’internaute accepte, le navigateur pourra interpréter les préfixes -webkit-. Sinon, la page s’affichera normalement.

Avec une telle solution, tout le monde est gagnant. L’internaute peut afficher une version optimale du site. Le navigateur peut démontrer ses capacités. Et le développeur web et les concepteurs du sites seront invités à revoir leurs pratiques.

J’espère vraiment que la décision d’Opera et de Mozilla n’est pas figée, et qu’ils essaieront de travailler avec des développeurs web pour trouver la meilleure solution, plutôt que d’imposer au monde entier leurs mauvaises décisions.

Après un premier trimestre 2012 exceptionnel, Apple a annoncé hier ses résultats du deuxième trimestre 2012. Encore une fois, et comme le résume MG Siegler, les chiffres sont exceptionnels :

• 39,2 milliards de dollars de chiffre d’affaires
• 11,6 milliards de dollars de bénéfices
• 47,4% de marge brute
• 35,1 millions d’iPhones vendus
• 11,8 millions d’iPad vendus
• 4 millions de Mac vendus
• 7,7 millions d’iPod vendus

Mais ce qui me marque le plus, c’est qu’Apple fait désormais sa deuxième entrée dans le Top 20 des entreprises ayant réalisé le plus de chiffre d’affaires en un trimestre. Apple occupe désormais la 4ème et la 6ème place de ce classement grâce aux deux derniers trimestres. Les 18 autres places sont occupées par des compagnies pétrolières, dont la plus récente date du 3ème trimestre 2011 à la 18ème place pour ExxonMobil.

Quand j’y réfléchis, je suis époustouflé.

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.

Des étudiants de l’Université de Stanford (en Californie) ont présenté la semaine dernière à Lyon les résultats de leur recherche intitulée « Qui a tué ma batterie : analyser la consommation d’énergie des navigateurs mobiles« . Le rapport de l’étude de 10 pages est particulièrement complet et détaillé, et sa lecture s’avère très intéressante. C’est à ma connaissance un des premières lectures du genre aussi complète sur ce sujet. Si la lecture en anglais vous effraie, voici un petit résumé et une traduction des points les plus importants.

Les mesures ont été effectuées sur un téléphone Android ADP2 avec une connexion 3G. Un multimètre relié à la batterie enregistrait les mesures matérielles. Une version modifiée du navigateur par défaut d’Android a été utilisée pour mesurer précisément l’impact énergétique de chaque fichier chargé, et permettre d’automatiser la mesure de consommation pour des pages avec et sans cache.

Les tests ont été effectués sur 25 sites connus représentatifs du paysage du web. Les premiers résultats des mesures sont assez marquants. S’il faut compter au minimum une dizaine de joules pour établir une connexion 3G, la différence de consommation d’un site à l’autre peut aller de quelques joules à plus de 40.

Voici quelques exemples et quelques points qui m’ont particulièrement marqué dans cette étude.

• Certains sites comme Youtube passent près d’un quart de leur énergie de rendu sur des images.
• Le code JavaScript de Yahoo est inclus dans les pages HTML. La quantité de code JavaScript est très petite mais le code est exécuté à chaque chargement de la page. Ainsi l’exécution JavaScript prends seulement 6,79% du total de l’énergie utilisée pour le rendu.
• AOL et Picasa contiennent tous les deux de grandes images, but la consommation d’énergie des CSS d’AOL est beaucoup plus faible que celle de Picasa. La raison est qu’AOL utilise des tableaux HTML pour positionner ses images alors que Picasa utilise CSS pour positionner ses images. Ceci illustre parfaitement comment le positionnement en CSS est moins efficace en énergie que le positionnement utilisant des balises HTML.
•  Réduire JavaScript sur une page web mobile aux seules fonctions utilisées sur une page réduit grandement la consommation d’énergie. Utiliser des librairies JavaScript génériques (comme jQuery) simplifie le développement, mais augmente la consommation d’énergie des pages résultantes.
• Comme JavaScript, un fichier CSS doit être spécifique à la page et contenir seulement les règles requises par les éléments présents.
• JPEG est le format le plus efficace en énergie sur les téléphones Android, quelque soit la taille des images. Pour démontrer ce point, nous avons utilisé Mogrify pour convertir toutes les images des pages d’Amazon et de Facebook en JPEG avec une compression à 92% de qualité. Les deux sites ont alors constaté un gain de consommation d’énergie, à hauteur de 20% pour Amazon et 30% pour Facebook. La raison de ce gain est que le format JPEG compresse mieux les images et est plus rapide à décompresser que du PNG ou du GIF.

Et voici la traduction de leur conclusion apportant des conseils pour concevoir des sites efficaces en énergie.

• Nos expériences démontrent que le format JPG est le meilleur format pour le navigateur d’Android, et ce pour toutes les tailles d’images.
• Gmail, le plus « vert » des sites mobiles que nous ayons trouvé, utilise des liens HTML pour ouvrir les messages sur lesquels l’utilisateur clique. La version bureau de Gmail utilise JavaScript à la place. Nos expériences suggèrent qu’utiliser des liens plutôt que JavaScript réduit grandement la consommation d’énergie pour le rendu d’une page. Ainsi, en concevant la version mobile du site différemment de la version bureau, Gmail a été capable de sauver de l’énergie sur le téléphone.
• Nous avons trouvé un certain nombre de pages qui auraient pu être mises en cache localement et affichées sans aucun accès réseau. Malheureusement, ces sites utilisent Google Analytics, un outil qui aide le suivi de l’utilisation du site. Le JavaScript utilisé par Google Analytics force une requête réseau dynamique qui ne peut pas être mise en cache. Ainsi, bien que le site aurait pu être affiché à partir du cache, le téléphone doit payer le coût important de démarrer une session 3G. Nous espérons que ce document aidera les sites web à comprendre le coût de l’utilisation de ces outils tiers. Alternativement, si les navigateurs exposaient le statut de leur connexion à JavaScript, Google Analytics pourrait choisir de ne pas reporter d’informations si la connexion 3G est faible.
• AOL est capable de gagner de l’énergie lors de son rendu en utilisant de simples tableaux HTML pour positionner des éléments sur la page. D’autres sites qui positionnent des éléments en CSS demandent beaucoup plus d’énergies pour le rendu.
• Sur tous les sites mobiles que nous avons testé, les publicités étaient de petits fichiers JPEG et avaient peu d’impact sur la consommation totale d’énergie.
• Des sites comme apple.com sont particulièrement énergivores. Nous espérons que ce document démontre l’importance de construire un site mobile optimisé pour les appareils mobiles. Les sites qui ne le sont pas finissent par vider la batterie des téléphones des visiteurs. Ceci peut potentiellement réduire le traffic du site.

Il est difficile de mesurer la qualité d’une intégration. Certains outils comme le validateur W3C ou des validateurs WCAG permettent de se faire une petite idée, mais ne sont en rien représentatifs de tous les critères concernés par l’intégration d’une page web (graphisme, référencement, développement, etc…).

En y réfléchissant, je pense que la qualité d’une intégration peut se mesurer sur 3 niveaux avec les questions suivantes :

1. Est-ce que c’est bien pour l’internaute ? 
2. Est-ce que c’est bien pour le projet ?
3. Est-ce que c’est bien pour moi ?

La première question, « Est-ce que c’est bien pour l’internaute ?« , fait directement écho à mon mantra. En se préoccupant d’abord de l’internaute, on va faire attention aux problématiques qui vont directement le toucher :

• La performance : la vitesse de chargement d’une page web est un des critères les plus importants vis-a-vis de l’internaute. Est-ce que mon code est bien optimisé ? Est-ce que mes images sont bien découpées et bien compressées ? Est-ce que le nombre de requêtes HTTP est bien optimisé ?
• La compatibilité : vu la multitude d’appareils, de navigateurs et de logiciels permettant d’accéder au contenu de votre site, il est indispensable de codez pour les autres. Est-ce que la propriété X fonctionne sur le navigateur Y ? Est-ce que ma page s’affichera bien sur de nouveaux appareils avec des résolutions d’écran 2 fois supérieures ?
• L’accessibilité : toute aussi importante, et pourtant souvent sous-évaluée. Est-ce que le code un peu filou que je suis en train d’écrire sera bien interprété par un navigateur vocal ?

La deuxième question, « Est-ce que c’est bien pour le projet ?« , s’attache aux particularités de votre projet.

• Le type de projet : on n’évalue pas la qualité d’une intégration d’un e-mail, d’une application Facebook et d’un site e-commerce de la même manière. Les bonnes pratiques de l’intégration d’e-mails sont à l’opposé des bonnes pratiques d’un site e-commerce. Différentes problématiques demandent donc différents regards d’évaluation.
• Le graphisme : trop souvent vu comme la finalité d’une page web, il n’en reste pas moins un critère important. Est-ce que votre intégration ressemble bien à la maquette ? Est-ce que vous avez du prendre certaines libertés ? (et si oui, est-ce vraiment parce que c’est mieux pour le projet ?)
• Le référencement : selon le type de projet, il est possible que vous ayez des impératifs forts en référencement. Certaines préconisations vous demanderont peut être d’aller à l’encontre de vos bonnes pratiques habituelles.
• La technologie utilisée : même en livrant une intégration HTML statique, vous n’obtiendrez jamais le même résultat selon le langage (PHP, .NET, Ruby, …) ou le CMS (WordPress, Magento, …) utilisés par votre projet.

La dernière question, « Est-ce que c’est bien pour moi ?« , est le moment de penser à vous, cher intégrateur, mais aussi à vos collègues intégrateurs. C’est le moment de vous posez des questions sur vos pratiques personnelles.

• La compréhension de votre code : est-ce que vous arriverez à comprendre ce que vous venez d’intégrer dans 1 an ? est-ce que vos collègues vont comprendre ce que vous venez de faire ?
• La pertinence de vos choix d’intégration : j’ai intégré toute ma page en « position:absolute ».  Est-ce que c’était vraiment la meilleure solution ? Et si jamais on doit changer ça dans 3 mois ?
• Les bonnes pratiques habituelles : si vous travaillez en agence, il est important de respecter les normes d’écriture et les bonnes pratiques habituelles. Si votre agence utilise toujours jQuery, est-ce bien raisonnable d’utiliser Mootools parce que « vous aviez envie d’essayer » ?

Ce ne sont ici que quelques exemples, et les tenants et aboutissants de l’évaluation de la qualité d’une intégration sont évidemment bien plus nombreux. Mais ces quelques critères permettent déjà de prendre un certain recul sur son propre travail, et surtout de relativiser sur son jugement du travail des autres.