HTeuMeuLeu

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.

Habituellement, quand j’intègre un formulaire et que je prévois des styles pour les champs erronés, j’ajoute (côté client et côté serveur) une classe .field--error sur l’élément parent du champ concerné. Hier, j’ai voulu faire le malin et styler des champs de formulaires erronés avec le pseudo-sélecteur CSS :invalid. Et je me suis rendu compte que ça ne correspondait pas du tout à ce à quoi je m’attendais.

Le problème, c’est qu’un simple input:invalid { border:1px solid red; } s’applique tout le temps, dès le chargement de la page, sans la moindre action de la part d’un utilisateur. Pour comprendre le pourquoi du comment, je me suis tourné vers les spécifications des sélecteurs CSS niveau 4 du W3C.

E:valid, E:invalid
Un élément de saisie utilisateur qui

Je dois être maudit. La seule partie qui m’intéresse sur une spécification de 17 000 mots est incomplète. Je suppose qu’il y a un nom de loi pour ça.

Mais ce n’était que la version Editor’s Draft de la spécification. Je me tourne donc vers la version Working Draft.

Un élément est :valid ou :invalid quand son contenu ou sa valeur est, respectivement, valide ou invalide en respect avec la sémantique de validité des données définie par le langage du document (par exemple [XFORMS11] ou [HTML5]). Un élément qui n’a pas de sémantique de validité de donnée n’est ni :valid ni :invalid.

Un champ de formulaire est donc toujours valide ou invalide, et ne dépend absolument pas de l’interaction utilisateur Peter-Paul Koch suggère que les champs devraient être :indeterminate. Mais ce sélecteur ne correspond qu’à l’état indéterminé d’une checkbox.

J’ai donc cherché un peu plus s’il n’existait pas un sélecteur correspondant  à ce que je cherche à faire (à savoir styler un champ erroné après saisie ou après validation du formulaire). Et il se trouve que Mozilla (la fondation qui défend le web ouvert et les standards) a un sélecteur propriétaire et non standardisé, :-moz-ui-invalid, qui sert exactement à ça. Un message datant de décembre 2010 de Ian Hickson indique l’intérêt du W3C pour cette fonctionnalité. Et puis plus rien.

En creusant alors un peu plus les spécifications des sélecteurs CSS niveau 4, j’ai fini par trouver mon bonheur avec le sélecteur :user-error.

La pseudo-classe :user-error représente un champ de saisie avec une entrée incorrecte, mais seulement après que l’utilisateur ait interagit de manière significative avec lui.

Mais forcément, c’est du « CSS 4 » et ce n’est donc supporté dans aucun navigateur à l’heure actuelle.

En résumé, en 2013, on peut faire les Simpsons en full CSS, mais pas styler un champ de formulaire erroné.

C’est idiot. Et pourtant ce modèle de conception est particulièrement courant sur le web. CDiscount le fait, Vente Privée le fait, Les 3 Suisses le fait, Auchan le fait, Carrefour le fait, Leclerc le fait, La Redoute le fait…

C’est bien simple, j’ai pris la liste des vingt premiers e-commerçants de France sur JournalDuNet, et sur ces vingt sites, seuls deux (Sarenza et Éveil et jeux) ne demandent pas de saisir deux fois le mot de passe lors de la création d’un compte. Il se trouve que j’ai aussi pêché par le passé en faisant exactement la même chose. Et puis j’ai eu l’occasion de réaliser à quel point c’était idiot il y a quelques années en travaillant sur la refonte d’un gros site e-commerce.

Pour se rendre compte à quel point c’est idiot, il faut se poser une question simple mais récurrente dans la conception web : quel problème est-ce que j’essaie de résoudre ?

À la base, l’origine du besoin de ce deuxième champ est totalement saine d’esprit. Ce champ est là pour s’assurer que l’utilisateur n’a pas fait d’erreur en tapant son mot de passe. Ça arrive de faire des erreurs. Et encore plus quand on ne voit pas ce qu’on écrit, comme dans un champ de mot de passe.

Mais du coup, le fait de taper deux fois son mot de passe dans des champs où l’on ne voit pas ce qu’on écrit ne résout pas du tout le problème. L’utilisateur a désormais deux fois plus de chances de faire des erreurs. Et corriger son erreur devient désormais deux fois plus long, puisque sans voir ce qu’il a écrit ni où se trouve l’erreur, l’utilisateur sera obligé de retaper ses deux mots de passe.

Alors comment résoudre ce problème ? Plusieurs solutions existent :

• Permettre d’afficher le mot de passe en clair. C’est ce qui existe depuis un bail sous OS X, et plus récemment sur Windows 8 (et c’est la solution adoptée chez les deux bons élèves cités en début d’article). C’est extrêmement facile à mettre en place avec jQuery (ici un tutoriel en français chez Creative Juiz).
• Afficher les lettres en clair au fil de la saisie. C’est le comportement par défaut sous iOS et Android. C’est un peu plus lourd à mettre en place (ici un exemple chez CSS Tricks), et le comportement n’est peut-être pas du meilleur effet sur desktop.
• Afficher le mot de passe en clair. C’est ce que Jakob Nielsen implorait en 2009 dans son article Stop Password Masking. C’est radical, et à peser avec la sensibilité des informations accessibles derrière le compte. Mais rien n’empêche de combiner cette solution avec la première, en affichant par défaut le mot de passe en clair, et en permettant à l’utilisateur de le masquer si besoin.

Je vais conclure en casant cet XKCD.

Si vous êtes sur un site de vente en ligne et qu’on vous demande deux fois votre adresse e-mail et deux fois votre mot de passe, mais qu’une seule fois votre adresse postale, ça en dit surement beaucoup plus sur la volonté du vendeur à détenir vos informations personnelles plutôt que sa volonté de vous livrer à bon port.

Jeremy Keith a écrit une bafouille sur son blog à propos de Prerender (une bibliothèque pour faire du SEO avec AngularJS, Backbone.js ou Ember.js) :

Je désespère parfois.

Voici un moyen ridicule et alambiqué pour permettre au tout puissant Googlebot de lire les contenus web que vous avez construit avec les nouvelles bibliothèques côté client comme Angular, Ember, Backbone…

Voilà une autre idée : sortez votre HTML en HTML.

Cette solution marche pour les machines et pour les humains. Et en bonus, sortir votre HTML en HTML évite de transformer JavaScript en point de défaillance unique.

Vu chez The Verge, Microsoft Singapour a présenté un court métrage animé sur Internet Explorer 11 lors du Anime Festival Asia. C’est très bizarre, mais super classe (avec quelques illustrations super Kawaï en bonus sur leur page Facebook). En tout cas c’est bien mieux que Le JT du web d’Omar et Fred auquel on avait eu droit pour IE9, et bien meilleur que la pizza IE8 (toujours en vente, cela dit en passant).

J’aime vraiment beaucoup ces nouveaux courts animés de Disney sur Mickey Mouse. J’étais tombé dessus en juillet dernier, mais les épisodes sur la chaîne Youtube de Disney sont bloqués en dehors des États-Unis. Heureusement, la diffusion a commencé en France le mois dernier, et sept épisodes sont déjà disponibles (contre quatorze aux États-Unis, sur dix-neuf au total). Un nouvel épisode est diffusé chaque semaine. Je crois que mon préféré reste le premier pour le moment. Voici les liens vers chaque épisode, triés par saison.

Saison 1

1. Pique-Nique à la Plage
2. L’Alpiniste
3. Croissant de Triomphe
4. Un hot-dog à New York
5. Une journée à Tokyo
6. Coup de chaleur
7. De l’eau !
8. Souris, panda !
9. Au pied les oreilles !
10. Un Zombie Dingo
11. Concours canin
12. Mickey à Venise
13. Pomme-de-terre-land
14. Une nuit agitée !
15. Bobo à la papatte
16. Poids lourds contre poids souris
17. Dingo tient la chandelle
18. Le couple adorable

Saison 2

1. Panique dans le tramway
2. L’incendie
3. Le parfum de Minnie
4. Le match de football
5. Down the Hatch
6. La Visite
7. Le capitaine Donald Nouveau
8. Mickey en Inde
9. La Chaudière Hantée
10. Promenade dans l’espace Nouveau
11. Mickey et le singe
12. Des tulipes pour Minnie
13. Le coup de foudre de Dingo
14. Biscuits et surpoids Nouveau
15. L’entretien d’embauche Nouveau
16. Mickey voit rouge Nouveau
17. La course à la limonade Nouveau
18. A Flower for Minnie
19. Bronco Busted

Il y a aussi une courte vidéo « Behind the animation ». Lu chez Cartoon Brew, les trois principaux réalisateurs sont des anciens de chez Nickelodeon ayant travaillé sur Le laboratoire de Dexter ou Bob l’éponge. On reconnaît bien leur patte.

Dernière mise à jour le dimanche 28 juin 2015.
Les derniers épisodes ajoutés sont indiqués par la mention Nouveau.

Aujourd’hui, j’ai reçu une newsletter d’Apple. Jusque là, rien de bien intéressant. Sauf que l’affichage sur mon iPhone m’a troublé.

Mais… Mais… C’est un e-mail responsive ! Alléluia ! Apple montre enfin un léger signe d’intérêt pour le responsive design. Ni une ni deux, j’ai donc fait ce que n’importe qui aurait fait en recevant cet e-mail. Je l’ai marqué comme spam. J’ai inspecté son code source.

Et là déception, Apple fait ce que j’appelle du « responsive mais pas trop ». Un e-mail, deux intégrations totalement distinctes l’une à la suite de l’autre, et affichées selon la résolution. (Ça va vite à résumer, mais n’empêche que rien que ça dans un e-mail ça reste un joli casse-tête.)

Par contre, il y a une chose que j’aime énormément sur l’e-mail en version mobile : l’absence de header. Pas de logo de la marque, pas de navigation, on commence directement par le contenu.

Après vérification, Apple a commencé à faire des e-mails responsive avec l’e-mail de lancement des iPhone 5s et 5c le 20 septembre dernier.

Voici des liens vers les e-mails en question :

• E-mail responsive iPhone 5s et 5c (captures d’écran desktop et mobile)
• E-mail responsive Macbook Pro (captures d’écran desktop et mobile)

Trent Walton a écrit un article que j’aurais bien aimé écrire sur les sites avec d’horribles défilements :

Des sites comme Milwaukee Police News et les récentes pages produit tout en un d’Apple sont jolis, mais détourner la vitesse de défilement d’un utilisateur à des fins marketing doit être le truc que je préfère le moins dans le web design de nos jours. Peut-être qu’il y a un temps et un lieu pour des expériences intensément « immersives », mais ces expériences ne devraient pas radicalement changer comment des entrées de base sur des appareils se déroulent. Plutôt que de profiter de la page, je m’inquiète de savoir si j’ai cassé mon trackpad et je me fatigue vite du délai de plus de trois secondes pour passer d’une section à une autre.

Sa conclusion est à marquer au fer rouge sur les avant-bras de vos collègues print-qui-font-du-web :

Si le but est d’éliminer l’aptitude de quelqu’un à naviguer librement sur une page, alors peut-être que ça n’a finalement pas sa place dans un navigateur.

Mark Boulton, sur son blog, s’interroge sur la pertinence de CMS WYSIWYG dans un web agnostique de tout appareil et tout navigateur. De très bonnes réflexions qui rejoignent un peu les miennes sur le mythe de l’éditeur WYSIWYG, mais du point de vue d’un CMS. J’aime particulièrement son introduction :

Depuis qu’on utilise des ordinateurs pour faire des sites web, nous avons essayé de les faire comme du print. Bien sûr, au début, c’était de bonne guerre. C’était familier. On connaissait les règles et on essayait de faire du web comme ça. Même maintenant, en ayant réalisé que le web a changé. Ou du moins, on est plus modeste vis à vis de ce qu’est le web. Il n’a jamais vraiment changé, on essayait juste d’en faire quelque chose qu’il n’était pas. On s’impose toujours un modèle mental proche du print sur le web. Pas nécessairement nous les designers et développeurs, cependant. Cela vient des gens qui écrivent et gèrent les contenus. De la même manière qu’ils impriment un email avant de l’envoyer, ils veulent avoir un aperçu de ce à quoi ressemble un site.

Le problème est : la question que ces gens posent quand ils ont fini d’ajouter du contenu dans un CMS est « À quoi ça ressemble ? ». Et ce n’est pas une question à laquelle un CMS peut répondre, même avec un aperçu. La façon dont nous utilisons le web aujourd’hui pousse à ce que la réponse à cette question soit « Dans quoi ? ».

Lu hier soir sur le mur Facebook (oui bon ça va) d’Andy McKee :

J’ai vu cette vidéo il y a quelques années et puis soudainement elle a été posté sur ma page une dizaine de fois par des gens différents récemment. Donc plutôt que de répondre à tout ceux qui l’ont partagé individuellement, je pensais écrire ce message.

J’apprécie tout le travail qu’il a du falloir pour arranger et jouer « Drifting » sur deux guitares ! Mais en tant que compositeur de ce morceau, je suis honnêtement assez perplexe à me demander pourquoi quelqu’un prendrait la peine considérable de le jouer sur deux guitares quand c’est possible de le jouer sur une. Hormis le fait que je suppose que vous pourriez obtenir un son stéréo en enregistrant une guitare à droite et l’autre à gauche… ?

Ok, peut-être que c’est juste pour avoir l’air cool, ce qui est plutôt rock ‘n’ roll \m/

Je suppose que ça marche aussi pour certaines démos absurdes en full CSS.