HTeuMeuLeu

Récemment j’ai enfin mis le doigt sur quelque chose qui me dérangeait depuis pas mal de temps, mais sans trop savoir pourquoi.

Il y a d’abord eu ce tweet de Charles de UXUI, dénonçant le site d’une agence qui publie sur son blog des traductions d’articles anglophones, mais sans jamais mentionner qu’il s’agit de traduction, en cachant discrètement l’article original sous un vulgaire lien « source », et en indiquant à la fin « article rédigé par [membre de leur équipe] ». Je trouve ça particulièrement malhonnête. C’est essayer de s’attribuer les mérites du travail d’un autre. Quelques échanges plus tard, la mention « article rédigé par » a été changée par « article mis en ligne par », ce qui est déjà un peu mieux. Mais il reste toujours ce vilain lien source.

Quand vous mettez un lien derrière un simple « via » ou « source », vous vous assurez que ce lien n’aura quasiment aucune valeur pour l’auteur, alors que ça aurait été l’occasion d’offrir à l’auteur à l’origine de votre propre publication un joli backlink.

Il n’y a rien de dévalorisant à citer quelqu’un. Si je lis quelqu’un que j’apprécie, et qu’en plus cette personne me fait découvrir de nouveaux auteurs à suivre, je n’en serais que plus reconnaissant. J’ai l’impression que les gens qui ne citent pas ou cachent leurs sources ont peur de perdre une partie de leur lectorat. Mais si c’est vraiment le cas, ça veut alors dire que votre article n’apporte strictement rien par rapport à l’article d’origine, et qu’il faut donc peut-être se remettre en question…

Et puis cette semaine, il y a eu ce classement des « développeurs francophones les plus suivis sur Twitter ». Je passe sur la pertinence de ce « concours de celui qui a la plus grosse », sur le fait que sur 50 développeurs, 36 ont des bios en anglais, ou sur la promotion spamesque faite pour cette page sur Twitter. Par contre, je suis plus dérangé par le fait que la raison principale de l’existence de cette page, c’est de faire la publicité des formations organisées par la société qui l’a créé. C’est certes discret, tout en bas de page, mais c’est bien là.

C’est en me tournant vers mon astrophysicien préféré que j’ai réussi à éclairer ce qui me dérangeait dans tout ça. Lors d’une rencontre avec Neil deGrasse Tyson dans son université, Anna H. a eu la chance de lui poser une question sur l’importance de la sensibilisation du grand public sur son métier.

Anna H : Vous parlez beaucoup du changement de la perception publique de la science. Je me demandais si vous pouviez nous parler des changements de la perception des scientifiques de la sensibilisation de leur métier — dans quelle mesure la sensibilisation est valorisée dans la communauté scientifique.

Neil deGrasse Tyson : Ah, excellente question, et une qui me tient particulièrement à coeur.

Carl Sagan a fait des erreurs, mais il était le premier a faire de la sensibilisation publique très visible, à grande échelle, donc il avait le droit de faire des erreurs. Mais je ne suis pas le premier, donc j’ai pu apprendre de ses erreurs. Carl ne donnait souvent pas crédit quand il décrivait des résultats de recherche astronomique. Beaucoup de gens regardant son programme ont pensé que c’était lui qui faisait toutes ces découvertes. Après son décès, des journaux ont écrit des choses comme « la seule récompense à lui avoir échappé était le prix Nobel ! », ce qu’ils n’auraient pu écrire que s’ils avaient pensé que toutes ces découvertes dont il parlait étaient ses découvertes. C’étaient des travaux sur lesquels d’autres scientifiques avaient peut-être passé des décennies, et Carl recevait toute la reconnaissance. Ça a rendu plein de gens amers.

Quand je décrit des recherches scientifiques, je fais toujours attention à les attribuer au groupe qui a travaillé sur le projet. Quand un journal m’appelle et me demande des commentaires, je les redirige toujours vers le groupe qui a fait le travail.

Aussi, je ne parle jamais de mes propres recherches. Je n’utilise pas ma plate-forme comme une opportunité pour faire la publicité de mes résultats personnels. Ma spécialité ce sont les galaxies, mais presque personne ne le sait. Je parle de ce qui selon moi va captiver le plus le public, et j’appelle des collègues si je n’y connais pas grand chose.

Je n’ai jamais ressenti d’antagonisme de la communauté professionnelle d’astronomie, et je pense que c’est parce que je leur donne toujours crédit pour leur travail.

Toujours donner crédit à ses sources, et ne jamais faire son auto-promo. Ce sont deux règles que j’essaye de suivre sans m’en rendre compte depuis des années.

La Poste, Orange, SFR et Voila ont la particularité d’être basé sur une même plate-forme de webmail, développée par Atos Wordline. C’est plutôt pratique, sauf que ça signifie qu’ils partagent aussi les mêmes bugs de cette plate-forme. Et en l’occurrence certains plutôt rigolos.

La plupart des webmails qui ne suppriment pas les balises <style> préfixent les règles CSS afin d’éviter tout conflit avec le reste de la page. C’est le cas de ces quatre webmails, qui préfixeront systématiquement les règles CSS par #message. Donc si vous écrivez une règle .toto, elle sera transformée en #message .toto.

Jusque là, c’est plutôt simple. Mais ça se complique quand on commence à utiliser des media queries. Dans une media query, le préfixe #message est toujours appliqué, sauf pour la première règle contenue à l’intérieur de cette media query. Ainsi l’exemple suivant…

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	.tutu { background:black; }
}

… sera transformé en…

#message .toto { background:red; }
#message .tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white; }
	#message .tutu { background:black; }
}

Cela signifie que la première règle .toto à l’intérieure de cette media query ne sera jamais interprétée, car elle est moins spécifique que la règle préfixée par #message au dessus. Pour palier à ça, il est alors impératif d’utiliser une règle !important à la fin de la première règle surchargée dans une media query. Dans l’exemple précédent, ça donnerait :

.toto { background:red; }
.tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white !important; }
	.tutu { background:black; }
}

Là où ça devient rigolo, c’est quand on teste ça sur mobile. Parmi ces quatre webmails, La Poste est le seul à bénéficier d’une version optimisée pour mobile. Le comportement décrit précédemment est sensiblement le même, sauf que c’est une classe comportant un identifiant dynamique qui est utilisée, par exemple .wrapper_h8ufTw, au lieu de l’identifiant #message. Mais la particularité qui prête à sourire, c’est qu’à l’intérieure d’une media query, la dernière ligne correspondant à l’accolade de fermeture de cette media query est également préfixée. Dans des navigateurs modernes, ça n’a pas d’incidence sur le bon fonctionnement des règles. Mais ça donne le joli code transformé par le webmail suivant :

.wrapper_h8ufTw .toto { background:red; }
.wrapper_h8ufTw .tutu { background:blue; }

@media only screen and (max-width:600px) {
	.toto { background:white !important; }
	.wrapper_h8ufTw .tutu { background:black; }
.wrapper_h8ufTw }

L’application Outlook.com sur Android affiche un extrait de l’e-mail dans les vues de liste d’e-mails. C’est plutôt pratique, sauf que contrairement aux autres applications qui font ça, le contenu affiché vient toujours de la version texte de l’e-mail (même si l’application est elle-même configurée par défaut pour afficher les e-mails en HTML).

Il faut donc bien veiller, lors du routage, à avoir le contenu souhaité en tout premier dans la version texte de l’e-mail.

Bonjour à tous ! J’ai le sentiment que l’intégration d’e-mails est une tâche conspuée, traitée comme un sous-domaine de l’intégration.  Et pour cause : les applications mails et les webmails n’ont pas beaucoup évolué depuis le début des années 2000. Ou pire : ils ont évolué dans le mauvais sens.

Mais ce n’est pas une raison pour mal intégrer ses e-mails. Ce blog est une tentative d’expliquer le savoir-faire nécessaire à l’intégration d’e-mails, les horreurs obligatoires, les atrocités imposées par les webmails, … Mais aussi les choses qui m’amusent.

Jeremy Keith, sur son blog :

Cette idée d’un web comme une plate-forme, je la comprends d’un point de vue marketing. On aimerait utiliser cette phrase, parce qu’elle place le web à un pied d’égalité avec des véritables plate-formes.

Je dirais que Flash est une plate-forme, et native : iOS et Android et toutes ces choses. Ce sont des plate-formes, dans le sens où tout n’est qu’un gros paquet. Mais le web n’est pas comme ça.

Si vous utilisez la plate-forme Flash, n’importe qui ayant le plug-in Flash pourra accéder à votre contenu. C’est tout ou rien. C’est un ou zéro. C’est binaire. Soit ils ont la plate-forme, soit ils ne l’ont pas. Soit ils ont tout votre contenu, ou aucun de vos contenus.

Et c’est similaire avec les applications natives. Si vous avez le bon téléphone, vous pouvez avoir mon application. Toute mon application. Vous n’accédez pas à des morceaux de mon application, vous avez toute mon application. Ou vous n’avez rien du tout parce que vous n’avez pas ce téléphone spécifique que je supporte.

Le web n’est pas comme ça. Le web n’est pas binaire, un ou zéro, tout ou rien. Ce n’est pas une plate-forme où vous avez cent pour cent ou zéro pour cent. C’est un continuum.

La semaine dernière, le site Twitch a lancé Twitch Plays Pokemon. C’est grosso modo une version modifiée des jeux Pokémon Rouge et Bleu sur Game Boy contrôlée par les joueurs indiquant leurs commandes dans le chat. Ça donne un joyeux bordel où des milliers de joueurs indiquent toutes les commandes possibles et leurs contraires. Et aussi incroyable que ça puisse paraître, ils arrivent à progresser dans le jeu.

Le blog Minimaxir a publié un excellent compte-rendu de cette partie. Et plus particulièrement de certaines difficultés rencontrées :

HM 01 est un objet qui permet de donner la capacité de Couper à un Pokémon, ce qui est nécessaire pour couper des arbres bloquant le passage. En l’occurrence ici, l’arbre en face du gymnase de Vermilion City. Afin d’apprendre à un Pokémon à couper, le joueur doit :

1. Faire apparaître le menu Start.
2. Sélectionner « Objets. »
3. Sélectionner HM 01.
4. Confirmer que HM 01 doit être utilisé.
5. Choisir un Pokémon à qui apprendre à couper.
6. Confirmer que le Pokémon choisi doit apprendre à couper.
7. Choisir une capacité à remplacer par « couper ».

La partie marrante ? Appuyer sur le bouton B ou choisir la mauvaise option durant n’importe laquelle de ces sept étapes fait revenir le processus un pas en arrière.

À ce stade dans le flux, l’audience avait atteint 30 000 spectateurs. L’activité augmentée causait un délai d’entrée d’environ vingt secondes entre le moment où un utilisateur de Twitch avait saisi sa commande dans le chat et le moment où la commande était reconnue dans le jeu. Ça peut rendre la navigation dans les menus difficile quand une commande « Haut » ou « Bas » est appliquée à un menu qui n’est même pas encore visible.

En plus de ça, alors que le nombre de spectateurs augmentait, le nombre de trolls aussi. Et ces trolls adoraient spammer le bouton B.

Grâce à tous ces facteurs, la chaîne a passé plus de 4 heures sans parvenir à apprendre à un Pokémon à couper. Le chat était devenu un véritable bain se sang de reproches.

Et puis ça a fini par arriver. Le Canarticho a appris à couper. Personne ne sait comment, mais c’est arrivé. Mais ce n’était qu’un pas vers la progression.

La seconde étape était d’effectivement couper l’arbre en question. Afin de couper, il fallait

1. Faire face à l’arbre.
2. Faire apparaître le menu Start.
3. Choisir « Pokémon ».
4. Choisir le Pokémon avec qui couper.
5. Choisir « Couper ».

Même problèmes qu’auparavant. Et faire face à l’arbre est encore plus difficile puisque les commandes Haut/Bas pour naviguer dans le menu peuvent éloigner le personnage de l’arbre.

Il a fallu à nouveau 4 heures pour couper cet arbre. Et plus tard, quand le personnage a été vaincu dans le gymnase, l’arbre avait réapparu. Oui.

HM 01 est un dur rappel que plus il y a de personnes présentes, plus il y a de chances que votre tâche échoue. Pas forcément à cause d’incompétence ou de manque d’organisation, mais simplement à cause de personnes mal intentionnées.

Cette avant dernière phrase s’applique particulièrement bien aux réunions en entreprise.

Un paragraphe dans l’introduction de l’article m’a particulièrement marqué :

Au final, la communauté des joueurs se bat contre son plus grand ennemi : soi même. Le but de Twitch Plays Pokémon n’est pas de gagner. C’est de ne pas échouer de manière spectaculaire. Et ils échouent quand même quoi qu’il en soit. C’est une irrésistible collision ferroviaire qu’il est difficile de s’arrêter de regarder.

Je trouve que ça fait une bonne analogie pour parler du web. Parce que quand j’y pense, c’est quand même incroyable que le web existe toujours et qu’on arrive à aller de l’avant dans cette plate-forme ouverte et collaborative. Parce que dans ce joyeux bordel, tout le monde aussi veut avoir le contrôle.

Entre les opérateurs (qui rêvent d’un web fermé où ils pourront facturer votre navigation par forfait de sites comme les abonnements TV), les fabricants de navigateurs (qui rêvent d’avoir un monopole absolu et d’imposer leurs technologies propriétaires), les États (qui rêvent d’avoir un contrôle sur tout ce qui peut transiter sur le réseau), et puis nous autres petits concepteurs web (qui rêvons d’avoir un contrôle sur le rendu et le fonctionnement de nos pages), c’est tout bonnement incroyable qu’on arrive à faire le moindre progrès.

Et pourtant.

J’aime bien les histoires de plagiat. Je me délecte toujours quand je lis des histoires comme celles de Marc Maggiori, des « Simpalas », de Layervault contre Flat UI, les documents internes de Samsung expliquant tout ce qu’il faut recopier d’iOS, ou des développeurs de Candy Crush Saga. Récemment, deux histoires m’ont particulièrement intéressé.

Tout d’abord, il y a l’histoire de Casey Neistat, un vidéaste américain, qui fin 2012 a eu l’idée de rendre une visite surprise à sa copine à l’autre bout du monde, et de filmer tout son périple au passage. Ça donne une vidéo sympathique bien qu’un peu longuette de son aventure très personnelle. Fin 2013, un français (cocorico) du nom de Maxime Barbier décide de reprendre le même concept, d’en faire sa vidéo, et de la vendre au passage à Coca-Cola. Maxime ne s’est pas caché d’être un fan de Casey Neistat et de s’être « inspiré » de sa vidéo, mais l’inspiration allait ici jusqu’à reprendre mot pour mot certaines répliques de la vidéo originale. Casey Neistat a donc publié un article sur son blog pour dénoncer tout ça, et la vidéo copiée a rapidement été retirée. Il explique ce qui le dérange le plus dans toute cette histoire :

C’est difficile de pointer du doigt pourquoi ça m’énerve autant. Copier fait partie du jeu. Ce n’est pas la première, et certainement pas la dernière, fois que quelque chose comme ça se produit. Peut-être que c’est parce que mon film était fait entièrement d’amour et de bonheur. Je ne faisais pas expressément un film, ce n’était pas la motivation pour surprendre ma copine. Je me suis juste retrouvé coincé dans des avions pendant 27 heures et j’ai décidé de tout filmer. Ce n’était que quelques semaines après le voyage que mon ami Max Joseph m’a aidé à monter le tout en un film après lui avoir montré les scènes de ma copine en train de crier quand elle m’a vu à sa porte à 12 000 Km de chez moi. Ou peut-être que c’est parce que je n’ai jamais gagné le moindre centime avec ma vidéo, que je n’avais même pas monétisée sur Youtube. C’est une histoire qui m’a rendu tellement heureux de la revivre encore et encore en regardant mon film que de regarder la copie merdique pour Coca-Cola de cet intrus a tout gâché pour moi.

Comme si cette expérience qui était si intime et centrale dans ma vie pouvait être reproduite et vendue en canettes rouges de trente-trois centilitres.

Plus récemment, Dong Nguyen, un développeur vietnamien, a connu un succès foudroyant avec un jeu sur iOS et Android : Flappy Bird. Sorti en milieu d’année dernière, le jeu était passé inaperçu. Mais après un mystérieux effet boule de neige et la mention sur une chaîne Youtube aux vingt millions d’abonnés, les téléchargements du jeu ont explosé. Le jeu rapporterait alors 50 000 dollars par jour en publicités à son créateur. Et c’est alors qu’entre en scène Kek, un autre français (cocorico), auteur habituellement de sympathiques bande-dessinées. D’après lui, Flappy Bird serait une copie pure et simple d’un de ses jeux, Piou Piou contre les cactus. Il contacte Dong Nguyen, qui nie avoir déjà entendu parlé de son jeu. Kek tente alors de faire la démonstration du plagiat sur Twitter en publiant l’image suivante :

Et c’est là où ça commence à me déranger. Contrairement aux histoires de plagiat évidentes et avérées, ici Kek n’a aucun autre argument qu’une ressemblance entre les deux oiseaux. En réponse à certains détracteurs sur Twitter ou dans un article sur le Huffington Post, Kek estime être le créateur original du « petit oiseau jaune aux grosses lèvres ». Permettez-moi d’en douter. Au niveau du gameplay et de la réalisation, les deux jeux n’ont strictement rien à voir. Mais les deux jeux sont très inspirés de l’univers de Nintendo (les tuyaux pour Flappy Bird, les cactus et le désert pour Piou Piou). Mais ça suffit pour que le 8 février dernier, Dong Nguyen retire Flappy Bird de l’App Store et de Google Play, avec pour seul motif qu’il ne supporte plus le succès de son jeu. Et du coup, je ne peux pas m’empêcher de me poser la question : qu’attendait Kek en publiant cette image ? Est-ce que secrètement il espérait que l’auteur reconnaisse un plagiat, et lui verse un chèque ? Ou alors que l’auteur retire Flappy Bird pour que tout le monde se mette à jouer à Piou Piou (et tant pis si les deux jeux n’ont rien à voir, ludiquement parlant) ? Contrairement à la copie avérée de la vidéo de Casey Neistat, j’ai l’impression que la seule motivation du hurlement au plagiat ici est l’argent (ce qui ressent tout au long de la lecture de l’article de Kek, sobrement intitulé « Comment j’ai failli être millionnaire »).

Ça m’arrive aussi d’être copié. Parfois ce sont de simples tweets que je retrouve mots pour mots. Il y a quelques années, j’étais tombé sur un article ressemblant très fortement au mien sur l’e-mail le plus réussi au monde. Même sujet (pourtant assez spécifique et dont j’avais parlé pour des raisons personnelles évoquées en tout début d’article), et surtout, le « copieur » avait repris mot pour mot ma traduction de l’e-mail en question. Surpris mais amusé, j’avais posté les deux liens sur Twitter avec un message du genre « Copié / collé ». Ce que je n’avais pas prévu, c’est qu’en quelques minutes, le blog du copieur a été inondé de commentaires d’insultes, probablement de la part de certains de mes followers pas très malins. En voyant ça j’ai aussitôt supprimé mon tweet pour éviter d’autres commentaires nauséabonds. Mais le mal était fait. Plus tard, le copieur supprima son article. Je n’attendais rien de particulier en pointant du doigt cette copie. Mais au final, tout le monde a perdu : les lecteurs du blog copieur perdent un article intéressant, l’auteur du blog s’est fait insulté sans raison valable, et moi je me suis senti mal que tout ça arrive alors que je n’avais aucune attente particulière.

Et je crois que c’est ce qui me dérange dans l’histoire de Flappy Bird. Au final, tout le monde a perdu : les joueurs sont privés d’un jeu original, l’auteur a du retirer sa création personnelle, et Kek passe pour le méchant français avare de service.

La meilleure solution reste de prendre les plagiats comme des flatteries. Ou sinon, de ne plus rien créer du tout.

Je l’ai posté sur Twitter cette semaine, mais je le redis ici. Je trouve ce comparateur de portefeuille absolument génial.

Cette semaine, je suis tombé sur le site de Wired UK et cet article sur Tim Berners-Lee qui fait la une du numéro de mars. Et je suis resté jouer un petit moment avec la fonctionnalité d’agrandissement de l’image accompagnant l’article.

 

Quiz : à votre avis, en cliquant sur ce bouton « Enlarge« , que va-t-il se passer ?

1. L’image va s’agrandir à partir de son emplacement actuel
2. La page va scroller pour revenir tout en haut et afficher l’image

Évidemment, c’est la réponse 2. Si c’est comme ça, c’est parce que sur des petites résolutions, l’image en question se trouve en haut de l’article. Sauf que sur mobile, l’agrandissement de l’image ne sert à rien puisque l’image prend déjà toute la largeur de l’écran.

Ou comment une fonctionnalité mal conçue en mobile first vient pourrir l’expérience desktop.

J’aime bien les casse-tête. Et quand je dis j’aime bien, je veux en fait dire que ça a le don de m’énerver et de me rendre complètement fou. Il y a quelques temps j’avais posté un joli casse-tête en intégration. Raphaël Goetter avait aussi publié sur son blog trois défi « T’es pas cap ! » (un, deux, trois). Hier soir, je suis tombé sur un nouveau problème bien casse-tête en intégration. Je l’ai posté sur Twitter afin de m’assurer que je n’étais pas passé à côté d’une solution évidente. En voyant ce matin le titre d’une solution inachevée proposée par Kaelig ou certains tweets nocturnes, j’ai ma confirmation que c’est bien un nouveau joli casse-tête.

Voici le casse-tête en question :

1. Les éléments (ici en orange) ont une largeur fixe de 200px.
2. La grille est fluide et contient 4 éléments par ligne.
3. Les « cellules » de la grille (ici en gris) ont une marge de 10px à gauche et à droite, sauf :
   • La première cellule de chaque ligne, qui n’a pas de marge à gauche
   • La dernière cellule de chaque ligne, qui n’a pas de marge à droite
4. Les éléments sont centrés horizontalement dans leur cellule, sauf :
   • Le premier élément de chaque ligne, qui est aligné à gauche
   • Le dernier élément de chaque ligne, qui est aligné à droite
5. Les éléments sont répartis équitablement sur chaque ligne. Les rectangles gris sont de la même largeur partout.
6. Le premier élément et le dernier élément de chaque ligne sont collés respectivement à gauche et à droite de la grille.
7. Toutes les cellules ont le même parent direct. Le code HTML doit donc ressembler à quelque chose comme : .grille > .cellule > .element. Vous pouvez ajouter des classes spécifiques en plus si besoin.
8. Pas de JavaScript, que du HTML et CSS.
9. La solution doit fonctionner à partir d’IE9 (et se dégrader gracieusement pour les plus vieux navigateurs).

Pour vous aider à démarrer, j’ai mis à votre disposition un exemple de code HTML et CSS sur CodePen. Vous êtes libre de modifier le code HTML et CSS, tant que vous respectez les règles ci-dessus.

Je vous invite à partager vos réalisations dans les commentaires. Je publierais la solution que j’ai trouvé dans le courant de la semaine. Amusez-vous bien !

Même pas deux ans après le rachat effectif de Motorola Mobility par Google pour 12,5 milliards de dollars, Google annonce la revente de Motorola Mobility à Lenovo pour 2,91 milliards de dollars. Ce sont 9,59 milliards de dollars partis en fumée en moins de vingt-quatre mois. Google conserve les brevets de Motorola, brevets qui s’étaient révélés devant un tribunal valoir deux fois moins que ce que Motorola estimait.

J’aime bien le commentaire de John Gruber sur ce rachat :

Je parie que ça prendrait littéralement plus de temps pour jeter 9,5 milliards de dollars en petites coupures par les fenêtres qu’il n’en a fallu à Google pour faire ça au sens figuré avec l’acquisition de Motorola.

La semaine dernière, Apple fêtait les 30 ans du Mac avec une page dédiée. Je suis tombé sur cette page via John Gruber, qui s’extasiait qu’elle soit responsive. Ça m’a tout de suite surpris, car j’ai tendance à penser qu’Apple n’aime pas trop le responsive design (même s’ils ont fait quelques tentatives sur certains e-mails).

Aussitôt les 11,3 Mo de la page chargée sur mon ordinateur (sans commentaire), je me suis empressé d’assouvir mon TOC d’intégrateur et de redimensionner la page. Et là, surprise, il se passe bien quelque chose (les textes sont redimensionnés), mais la page n’est clairement pas responsive.

Je vais donc visiter la page sur mon iPhone, curieux de voir le rendu de cette page. Après tout, le gabarit du site d’Apple n’est pas responsive. Alors comment est-ce qu’Apple aurait pu rendre une page responsive sur un site non responsive ?

La réponse est simple : en trichant.

Comme le dirait Cyril Lignac, « c’est très astucieux ». Plutôt que de rendre leur gabarit responsive (avec l’enfer que ça peut engendrer), les intégrateurs d’Apple ont préféré simplement mettre à l’échelle le header et le footer du site. Pour ça, ils utilisent simplement la propriété transform:scale(0.3125); (où 0.3125 est une valeur calculée en JavaScript le ratio calculé entre la taille du site, 1024px, et la largeur de l’écran d’un iPhone, 320px).

La propriété transform étant ce qu’elle est, Cyril Lignac s’exclamerait surement aussi « c’est très gourmand ».

Si ce n’est clairement pas une solution optimale (la navigation reste difficilement utilisable dans cet état), je trouve l’idée quand même très originale. À noter que la même chose avait été utilisé par Apple pour la page du Mac Pro.

Je suis tombé sur cet article de Braden Kowitz, designer chez Google Ventures (publié initialement dans Wired en novembre 2013). Et je suis bien content, parce qu’il y a ce genre d’exemple que j’affectionne tant :

L’un de mes premiers projets chez Google était de concevoir le bouton « Google Checkout », qui allait prochainement aider les gens à rapidement acheter des produits et services sur le web. Créer un bouton est habituellement facile, mais celui-ci avait une exigence unique : les clients pouvaient choisir entre plusieurs méthodes d’encaissement, donc notre bouton devait attirer leur attention sur une page chargée.

À chaque vague de retour de design, par contre, on me demandait de rendre le bouton plus gras, plus large, plus accrocheur, et même « plus cliquable » (peu importe ce que ça signifie). Le design proposé devenait tout doucement plus criard et au final, franchement moche.

Afin de démontrer quelque chose, un de mes collègues s’est présenté avec une proposition inattendue. Il a créé le bouton le plus accrocheur qu’il était possible de créer : des flammes qui sortent des côtés, un énorme biseau ciselé 3D, et un libellé tout en majuscule (« iPOD GRATUIT !!! ») avec en mineur « Commandez pour avoir une chance de gagner ».

Cette proposition a complètement remis à zéro toute la conversation. Il était clair pour l’équipe à ce moment que nous nous soucions de plus que juste des clics. Nous avions d’autres objectifs pour ce design : il devait poser les attentes de ce qui se passerait ensuite, il devait communiquer la qualité, et nous voulions construire une familiarité et une confiance autour de notre marque.

Vu sur Twitter, ce lightning talk de Marcel Gordon qui explique pourquoi Google préfère le responsive. J’aime beaucoup cette métaphore :

Quand vous mettez en place des câbles dans votre maison, vous ne partez d’un point avec un seul câble pour vous rendre à un autre point, puis recommencez au premier point avec un autre câble pour retraverser la maison à nouveau. Vous prenez tout un tas de câbles, vous les attachez ensemble, vous traversez votre maison, et à l’autre bout vous les répartissez là où il faut. C’est plus facile à déployer comme ça, et c’est plus facile à maintenir comme ça. Et c’est une bonne analogie, à mon avis, avec ce qui se passe avec le responsive design.

Vous avez un ensemble de contenus, une base de données, un front-end, un serveur web. Et enfin quand ça arrive à l’utilisateur, vous avez trois, quatre différentes mises en page. Vous pouvez ajouter de nouvelles mises en page quand vous en avez besoin, mais vous n’avez pas plusieurs systèmes à maintenir entre deux. Vous avez un ensemble qui va jusqu’au navigateur, et c’est seulement lorsque vous êtes dans le navigateur que vous prenez des décisions sur la mise en page.

(Anecdote amusante d’il y a trois ans : Marcel Gordon était le chef de projet de Swiffy, le convertisseur de SWF en HTML5 de Google. Flash, Gordon, tout ça.)

Microsoft vient de publier ça sur le compte Facebook de la personnification manga (parfois limite hentai) d’Internet Explorer. (La ponctuation est d’origine.)

Retour à mon sixième anniversaire : j’étais au top de ma classe, en ayant étudié durement et en maîtrisant plein de nouvelles compétences comme les iframes et le redimensionnement automatique d’images, tout en améliorant grandement mes connaissances en CSS. Je suis vraiment fière de ce que j’ai accompli. Yessssssss ! (*≧▽≦)

J’ai dû devenir un peu présomptueuse, et j’ai arrêté d’étudier. Progressivement, mes camarades de classe ont commencé à devenir meilleurs que moi aussi bien à l’école qu’aux sports. Avec le temps, je suis devenue de plus en plus empotée et socialement gênante !!!!! En y repensant, c’était un épisode vraiment très embarrassant de ma vie ! Boohoo. (╯︵╰,)

Cependant, cinq ans plus tard, j’ai décidé de commencer à faire quelque chose pour y remédier… (•̀ᴗ•́)و

C’est incroyablement honnête, et un excellent résumé du début des années 2000.

En ce début d’année, j’ai pris la bonne résolution de me désinscrire des newsletters que je reçois et qui ne m’intéressent plus, plutôt que de les archiver à peine reçues (ou pire, les marquer comme spams). Et souvent, j’ai eu droit à un message du genre (ici sur le site d’Apple) :

« 5 jours ouvrables. » Ça fait beaucoup quand même, 5 jours, pour une simple requête SQL. Il n’est pas rare que je vois passer ce genre de railleries sur Twitter. Ou comme dans cet article lu ce matin expliquant comment se désabonner des newsletters Zalando :

Prendre plusieurs jours pour désabonner une adresse est une blague, c’est automatique et instantané avec un outil de routage professionnel. Et je ne doute pas une seconde que Zalando a un outil pro pour router ses messages.

Si je suis d’accord qu’en théorie la désinscription d’une newsletter devrait être immédiate, dans la pratique, c’est plus compliqué. Voici deux suppositions sur pourquoi c’est si long pour se désinscrire d’une newsletter.

• Les bases de données d’e-mails sont gérés par différents prestataires, en dehors de l’outil de routage. Certains prestataires s’occupent de l’inscription de nouvelles adresses, d’autres de la désinscription. La différence des bases de données n’est alors réalisée qu’à intervalles régulier (quotidiennement ou hebdomadairement), pour ensuite seulement être réinséré dans l’outil de routage.
• Les routages sont prévus longtemps à l’avance. Oui, ça arrive dans nos métiers d’avoir de l’avance. Un e-mail est intégré une semaine avant son routage, puis aussitôt préparé pour le routage avec l’import de la base d’e-mails à cet instant. L’import de la base d’e-mails a donc été fait avant même que vous ne vous soyez désinscrit.

Bon, la plupart des campagnes d’e-mails sont gérées à l’arrache, donc il y a surement d’autres facteurs dont je n’ai pas connaissance à prendre en compte. Mais c’est encore une fois un bon rappel que certaines tâches en apparence simples peuvent être bien plus compliquées, et qu’aucune tâche n’est jamais instantanée, en particulier dans des grands groupes.

Voici une partie du footer de Sarenza.com vue dans une résolution de 540px de large, actuellement en production.

Voici le header de 3suisses.be dans n’importe quelle résolution supérieure à 980px de large, actuellement en production.

Voici le header du site Time.com dans une résolution entre 500px et 700px de large, actuellement en production. C’est comme ça en production depuis au moins les six derniers mois où j’ai visité le site.

Et voici le header du site de la marque Tape à l’Oeil dans une résolution inférieure à 768px de large sur desktop. C’est comme ça en production depuis la refonte du site en septembre dernier.

Je n’essaie pas de jouer au petit malin en vous montrant ces exemples. Ces exemples sont des exemples de site responsive de marques renommées qui à un moment rencontrent un problème d’affichage plus ou moins grave. Je ne dis pas que ces sites sont mal conçus (je trouve le menu de 3suisses.be particulièrement bien intégré). Mais ces sites se heurtent à un problème que j’ai également rencontré l’an passé en travaillant sur des adaptations responsive de gros sites.

On assume depuis longtemps qu’il est indispensable de tester son site sur différents navigateurs, sur différentes versions de ces navigateurs, sous différents systèmes d’exploitation, sous différentes versions de ces systèmes d’exploitation. Avec un site responsive, il faut toujours faire ça, mais en plus tester toutes les largeurs et hauteurs de fenêtres possibles.

Bienvenue dans l’enfer du responsive.

Et c’est encore plus un enfer dans une équipe de grande taille, ou avec différents prestataires externes, ou sur un site faisant appel à des contenus extérieurs (ou réalisés en externe). Et ça l’est encore plus dans le contexte d’un site dont le contenu évolue constamment.

Je n’ai malheureusement pas encore trouvé de solution miraculeuse pour identifier ce genre de soucis, à part une vigilance manuelle accrue. J’ai bien essayé de faire des captures d’écran de sites dans différentes résolutions avec des navigateurs sans-tête comme PhantomJS, ou alors avec des services comme BrowserStack. Mais cela nécessite toujours une vérification manuelle des captures. Alors qu’on s’empresse de plus en plus à faire des sites responsive, il me semble important de commencer à instaurer des processus de monitoring des designs de sites. (Je crois avoir vu passé quelque chose dans ce sens l’année dernière du côté de la BBC ou du Guardian, mais je n’ai rien retrouvé. C’est la BBC qui a un outil pour ça, basé sur PhantomJS, merci Kenny.)

En attendant, en tant qu’intégrateur, je ne peux que de redoubler de prudence lors de la conception de mon code (le design atomique, ça aide), et m’assurer que tout le monde comprenne bien pourquoi ça prend un peu plus de temps pour changer un « s ». Et aussi inviter mes collaborateurs à mettre en pratique la maxime du métro New-Yorkais : « If you see something, say something ».

Jason Fried, sur le blog de 37signals :

Quand vous évaluez un redesign, vous devez savoir ce que vous cherchez, pas seulement ce que vous regardez. Comment le nouveau design est en comparaison avec l’ancien est peut-être la chose la moins importante à prendre en considération.

« Le calendrier de l’avent des gens qui font le web d’après », que j’avais lancé l’année dernière, est terminé pour cette année. Je vais pouvoir dormir, rejouer à GTA V et écrire sur ce blog. Si vous n’êtes pas encore tombé dessus, je vous invite vivement à y faire un tour. Et si vous avez apprécié le cru de cette année, je vous encourage fortement à faire un don pour l’association Handiparentalité soutenue cette année. (Et en plus, jusqu’à 31 décembre, vous recevrez un bundle d’e-books.)

Cette semaine, je me suis encore bien amusé sur de l’intégration d’e-mails. Et plus particulièrement sur quelques découvertes faites sur l’application Gmail sur Android. Je ne teste pas systématiquement sur cette application car elle ne fait pas parti des batteries de tests inclus dans des services comme Email on Acid ou Litmus. Et pourtant, cette application est un véritable concentré d’amusement.

Et quand je dis amusement, je veux en faire parler d’un véritable cauchemar. Je me suis rendu compte qu’un gabarit responsive que j’utilisais régulièrement ne s’affichais pas du tout correctement sur Gmail 4.6 sur une Nexus 7 de 2012. Alors que je m’attendais à avoir un affichage normal de la version desktop (Gmail ne supportant pas les media queries), je me suis retrouvé avec un e-mail tout cassé. Je suspectais l’application d’appliquer un redimensionnement sur des tailles de tableaux. Du coup, je me suis fait un e-mail de test avec une série de tableaux les uns en dessous des autres, chaque <table> ayant une largeur différente (640, 600, 550, …, 400, 350, 320).

<table border="0" cellpadding="0" cellspacing="0" width="640" bgcolor="red">
	<tr>
		<td>Lorem ipsum dolor sit amet…</td>
	</tr>
</table>

Voici le rendu que j’espérais obtenir.

Et voici le résultat obtenu.

OK. C’est le genre de moment où j’annule tous mes rendez-vous et je débranche le téléphone, parce que l’après-midi promet d’être longue.

Il s’avère qu’en fait, l’application Gmail sur Android supprime tous les attributs width précisés sur des <table>. Voilà, comme ça, c’est fait, merci Google. J’ai donc relancé un test similaire, mais en précisant cette fois-ci la largeur sur l’unique <td> de chacun de ces tableaux, et non plus sur les tableaux en eux-même.

<table border="0" cellpadding="0" cellspacing="0" bgcolor="red">
	<tr>
		<td width="640">Lorem ipsum dolor sit amet…</td>
	</tr>
</table>

Voici le résultat obtenu.

C’est déjà mieux. Mais Gmail ne semble pas tenir compte de la taille précisée sur les premiers tableaux (respectivement 640, 600, et 550 pixels de large). Mais ça c’était sur une tablette Nexus 7. En testant sur un téléphone Nexus 5, j’ai commencé à comprendre un peu plus précisément ce qu’il se passait. Voici le rendu obtenu avec le même code :

 

Sur Nexus 5, tous les tableaux sont forcés à la largeur de l’écran, sauf les deux derniers (de 320 pixels de large). En affinant un peu plus mes tests, j’ai fini par déterminer que sur Nexus 5, les tableaux seront affichés au maximum à 324 px de large, contre 525 px sur une Nexus 7.

En vérifiant avec d’autres e-mails, je me suis rendu compte que Gmail n’appliquait pourtant pas systématiquement ce redimensionnement forcé. Et il s’avère que c’est assez « facile » de le contourner (j’ai quand même bien mis deux heures pour comprendre ça tout seul).

Pour forcer Gmail à ne pas effectuer de redimensionnement automatiquement, il « suffit » d’avoir dans son e-mail au moins un tableau avec au minimum deux colonnes contenant des images dont la taille atteint la taille désirée. (Je vous laisse imaginer le nombre de tests qu’il m’a fallu pour arriver à cette conclusion, et maintenant vous comprenez pourquoi ça m’a pris deux heures.)

Autrement dit, si vous voulez forcer l’affichage de votre e-mail à 640 px de large, vous devez insérer un tableau avec deux cellules, contenant deux images de 320 px de large chacune.

<table border="0" cellpadding="0" cellspacing="0" class="mobileHide">
	<tr>
		<td><div style="font-size:1px; line-height:1px;"><img src="spacer.gif" width="320" height="1" alt="" border="0" style="display:block;" class="mobileHide" /></div></td>
		<td><div style="font-size:1px; line-height:1px;"><img src="spacer.gif" width="320" height="1" alt="" border="0" style="display:block;" class="mobileHide" /></div></td>
	</tr>
</table>

Le style suivant permettra ensuite de s’assurer que ce tableau ne s’affiche pas dans la version mobile de l’e-mail.

@media only screen and (max-width: 480px) {
	table[class="mobileHide"], img[class="mobileHide"] { display:none !important; }
}

C’est exactement le genre de fonctionnalité que je déteste dans un moteur de rendu HTML/CSS. Sur le papier, forcer les largeurs des tableaux ne contenant qu’une seule cellule à la taille de l’écran sonne comme une bonne idée pour les utilisateurs. En pratique, ça ne fonctionne pas vraiment, et ça rend le travail des intégrateurs un véritable enfer.