HTeuMeuLeu

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.

Le dernier spectacle de Louis C.K., Oh My God, est vente en ligne sur son site pour cinq dollars. J’ai un amour inconditionnel pour Louis C.K. et ce spectacle est excellent. En particulier ce sketch, « Of course, but maybe… ».

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

Tout le monde a une rivalité dans son cerveau entre des pensées positives et négatives. Idéalement les pensées positives l’emportent. Moi, j’ai toujours les deux. Il y a le truc auquel je crois, le bon truc, et puis il y a ce truc. Je n’y crois pas forcément, mais c’est quand même là. C’est toujours ce truc, et ce truc. C’est devenu une catégorie dans mon esprit que j’appelle « Bien sûr, mais peut-être… ». Je vais vous donner un exemple.

Bien sûr, bien sûr, les enfants allergiques aux noix doivent être protégés. Bien sûr ! Nous devons isoler leur nourriture des noix, avoir leurs médicaments disponibles à tout moment. Et n’importe qui fabrique ou sert de la nourriture doit être au courant des allergies aux noix mortelles. Bien sûr ! Mais peut-être… peut-être que si toucher une noix vous tue, vous êtes censés mourir.

Bien sûr que non, bien sûr que non ! J’ai un neveu qui a ce problème. Je serais dévasté si quoi que ce soit lui arrivait. Mais peut-être… peut-être que si on ferme tous les yeux pendant un an, on en aura fini avec les allergies aux noix pour toujours… Non, bien sûr que non !

Bien sûr, si vous allez combattre dans un autre pays et que vous vous faites tirer dessus, c’est une horrible tragédie. Bien sûr, bien sûr ! Mais peut-être… peut-être que si vous prenez un arme et que vous allez dans un autre pays, et que vous vous faites tirer dessus, ce n’est pas si bizarre. Peut-être que si vous vous faites tirer dessus par le type sur qui vous étiez juste en train de tirer, c’est un tout petit peu votre faute.

Bien sûr, bien sûr, l’esclavage est la pire chose qui ait jamais existé. Bien sûr ! À chaque fois que c’est arrivé ! Les noirs en Amérique, les juifs en Égypte, à chaque fois que c’est arrivé, c’était quelque chose d’horrible. Bien sûr ! Mais peut-être… peut-être que n’importe quel accomplissement incroyable humain dans toute l’Histoire a été fait par des esclaves. Le moindre truc où vous vous dites « Mais comment ont-ils construit ces pyramides ? ». Ils ont juste balancé de la mort et de la souffrance humaine jusqu’à ce que ce soit fini.  Comment avons-nous traversé le pays avec des voies ferrées aussi rapidement ? On a juste balancé des chinois dans des caves et tout fait sauter sans se préoccuper de ce qui allait leur arriver. Il n’y a aucune limite à ce que vous pouvez faire quand vous n’avez rien à secouer d’un certain groupe de personnes. Vous pouvez faire tout ce que vous voulez ! C’est de là que vient la grandeur de l’espèce humaine, nous sommes des personnes merdiques.

Même aujourd’hui [en sortant son smartphone], comment avons nous ces merveilleuses technologies miniatures ? Parce que dans les entreprises où ils font ça les employés sautent du putain de toit parce que c’est un cauchemar là-bas. Vous avez le choix pourtant. Vous pouvez avoir des bougies et être un peu plus gentil les uns avec les autres. Ou alors laissez quelqu’un souffrir incommensurablement très loin d’ici pour que vous puissiez laisser un commentaire méchant sur Youtube pendant que vous faites caca.

Ça dépend.
(Marche aussi comme résumé des trois jours de conférences et ateliers de Paris Web 2013)

Une partie de mon travail consiste à gérer les retours de mes collègues ou clients lorsque j’ai mal fait mon travail, ou lorsqu’un cas auquel je n’avais pas pensé se produit. C’est quelque chose de tout à fait sain. Je suis d’ailleurs bien plus rassuré d’avoir des retours après des tests sur une intégration, plutôt qu’aucun retour du tout. Sauf que mon enthousiasme pour gérer un retour est directement proportionnel à la qualité des renseignements fournis par son expéditeur.

Et malheureusement, il m’arrive de recevoir ce genre d’e-mails.

Si vous envoyez ce genre de message, ou si vous pensez qu’il s’agit d’une façon appropriée de vous adresser à un autre être humain par courrier électronique, alors félicitations, vous venez de vous qualifier pour le titre de « La Pire Personne Au Monde », juste entre les prêtres pédophiles et les mamans qui congèlent leurs bébés.

Parce qu’un tel message n’aide personne. Il y a de grandes chances pour que le site ait été testé en bonne et due forme « SUR MAC » lors de son intégration. Et si la possibilité d’un bug sur une page en particulier n’est pas à exclure, « LE SITE NE MARCHE PAS » n’aide pas beaucoup à savoir ce qui cloche exactement. Et le « CORRIGEZ ASAP » ne m’incite pas vraiment à avoir de l’empathie pour ce problème qui vous semble si urgent.

Voici les informations que j’aime voir figurer lorsqu’on me remonte un bug en intégration.

1. Assurez-vous que le problème ne vienne pas de vous. Pensez à rafraîchir le cache de votre navigateur, et vérifiez que celui-ci est configuré avec le niveau de zoom par défaut. (S’il est important de prévoir que son site s’affiche correctement selon différents niveaux de zoom, vous obtiendrez bien plus de respect de la part de vos intégrateurs en leur précisant que le problème survient à un certain niveau de zoom).
2. Précisez de quoi vous parlez. S’il s’agit d’un problème sur une fiche produit, je veux savoir quel produit. Si c’est un problème lors d’un paiement, je veux savoir quel moyen de paiement. (Et si c’est un cheval, je veux savoir dans quelle course.) N’hésitez surtout pas à mettre une URL directement dans votre message de retour. C’est ça de temps en moins passé à rechercher où est le problème pour chercher comment résoudre le problème.
3. Précisez votre environnement de test : système d’exploitation, navigateur, appareil. Il n’est pas nécessaire de vérifier vous-même si le problème se produit sur plusieurs de ces critères. Dites-moi juste sur quoi vous avez testé, et je me charge du reste.
4. Faites une capture d’écran. Rien de mieux qu’une capture d’écran pour comprendre un problème, plutôt que d’essayer de décrire en cinq paragraphes avec un jargon différent du mien (« il y a un décalage sur le drop sous le calque dans le push FD »). Et ne m’envoyez pas simplement une capture du bout de la page qui saute. Une capture d’écran complète de tout votre système peut me permettre d’identifier certains éléments extérieurs qui ont pu déclencher ce bug (« Oh, un plugin Skype. »).
5. Précisez comment reproduire le bug. Si le bug n’apparaît qu’après une suite d’actions, précisez quelles actions vous avez effectué. Comme dans le cas précédent, une vidéo d’enregistrement de votre écran peut valoir mieux qu’un long discours pour des cas complexes.
6. Priorisez. Si vous insistez pour m’envoyer une liste de cinquante retours par e-mails, alors indiquez moi ce que vous souhaiteriez voir résolu en priorité. (Et, non, désolé, mais tout mettre en priorité haute, ce n’est pas prioriser).

Merci d’avance !

Google a lancé hier soir Google Web Designer, un logiciel Mac et Windows permettant de créer des « designs attirants et interactifs basés sur HTML5 et des animations qui peuvent tourner sur n’importe quels appareils« . La promesse de Google Web Designer est alléchante, mais c’est en ouvrant le logiciel pour la première fois ou en lisant le centre d’aide de Google que l’on comprend mieux à quoi est destiné exactement ce logiciel.

Google Web Designer est une application web avancée construite avec HTML5 qui vous permet de concevoir et construire des publicités en HTML5 et d’autres contenus web en utilisant une interface visuelle et une interface de code intégrés.

Google Web Designer n’est donc pas un outil conçu pour créer des sites web. (Comme le disait Hajim El Attab sur Twitter, Google Ad Designer aurait été un nom plus approprié.) Pourtant, Google Web Designer me laisse le même goût amer qu’à chaque nouvel outil soit disant pensé pour la conception web. Je pense évidemment au dégoûtant Adobe Muse, ou encore à iAd Producer d’Apple (qui a au moins le mérite d’avoir un nom explicite sur sa finalité), mais aussi aux dinosaures du genre (Dreamweaver, Frontpage, iWeb). Ces logiciels s’évertuent tous à perpétuer le mythe de l’éditeur magique pour le web, et je trouve ça assez malsain.

Intégrer une page web, c’est résoudre des problèmes. Ces problèmes concernent l’adaptation d’une création graphique, l’accessibilité et l’interoperabilité d’une page, la maintenabilité du code, et la performance. Et bien sûr tout cela doit être fait dans un temps raisonnable.

Les éditeurs WYSIWYG comme Google Web Designer ou Adobe Muse ne se préoccupent que d’un seul point : la création graphique. C’est une vocation louable, mais qui se fait au sacrifice de tous les autres aspects de la conception web. Google Web Designer n’a donc aucun scrupule à générer une bannière de près de 100 Ko, puisque le seul problème que Google essaye de résoudre c’est d’arriver à ressortir graphiquement la même chose que ce qui a été fait dans l’éditeur. Et tant pis si la même bannière codée à la main aurait été dix fois plus légère.

Quand j’intègre une page web, je vais me poser des centaines de questions. Par exemple, pour du texte dans une police exotique : est-ce que j’utilise une police CSS ? (et toutes les questions qui vont avec : est-ce que cette police est utilisée ailleurs sur le site ? est-ce que le poids de la page actuelle permet de s’engraisser de la lourdeur d’une police CSS ? est-ce qu’on a la licence de droit d’utilisation de cette police sur le web ? est-ce que les coûts de cette licence rentrent dans le budget du projet ?), ou est-ce que j’utilise une image ? (et dans ce cas : plutôt un GIF, un JPG, un PNG, du SVG ? quels navigateurs doivent être supportés ? que se passe-t-il pour les autres navigateurs ?). Et ça, c’est juste un petit éventail de questions qui me traversent l’esprit à chaque fois que je fais face à une police exotique. J’ai tout un tas de questions à me poser face à n’importe quel composant d’interface. Et ce à chaque nouveau projet, peu importe combien de fois j’ai déjà intégré un élément similaire auparavant, parce que le web évolue vite, et c’est tant mieux.

Je ne pense pas que créer une interface qui permette de résoudre ces problèmes soit impossible. Mais la complexité de ces problèmes rendrait une telle interface aussi complexe que les problèmes qu’on essaie de contourner. Et même si ça peut être difficile à avaler pour certains, je suis convaincu que la complexité de HTML et CSS est un bien nécessaire.

 

Il y a deux ans, j’ai organisé un concours sur ce blog. À l’époque, j’étais plein de bonne volonté et je m’imaginais refaire des concours régulièrement. Et puis en fait j’ai trouvé ça pas super amusant à organiser, et donc j’ai abandonné l’idée. Et puis j’ai réfléchi à comment rendre ce genre de concours un peu plus utile et moins futile. Et nous voilà.

En partenariat avec Eyrolles, voici un nouveau concours pour gagner un exemplaire du livre « Intégration Web : les bonnes pratiques » par Corinne Schillinger.

Pour gagner, il suffit de faire un don en ligne à l’Unicef, et de m’envoyer une copie du bon de commande reçu lors du don (exemple) à l’adresse concours@hteumeuleu.fr. Le don doit avoir été réalisé après le 30 septembre 2013 à 13h37. Le montant du don est totalement libre. C’est un concours de rapidité. Le premier justificatif que je reçois a gagné.

Les résultats seront annoncés demain.

Bonne chance !

VentureBeat rapporte des tests réalisés par la société Agawi sur la qualité des écrans tactiles :

Dans leur premier test de référence TouchMarks, l’iPhone 5 répond au toucher en une moyenne de 55 millisecondes, contre 85 millisecondes pour l’iPhone 4. L’appareil Android qui s’en approche le plus est le Samsung Galaxy S4, à 114 millisecondes.

« Apple écrase la concurrence », déclare Peter Relan, président de Agawi. « Il y a toute cette autre dimension de réactivité à laquelle Agawi fait attention. »

Agawi a étudié l’iPhone 5 et l’a comparé à des smartphones tactiles Android comme le Moto X de Google, le HTC One, et le Samsung Galaxy S4. Il a aussi été comparé au Nokia Lumia 928 sous Windows Phone, qui a été mesuré à 117 millisecondes.

L’iPhone 4, sorti en juin 2010, a un meilleur écran tactile que n’importe quel smartphone concurrent sorti en 2013. Ça explique surement pourquoi je trouve toujours Android lent, quelque soit l’appareil testé.

Jeffrey Zeldman et Mike Monteiro, dans le dernier épisode du podcast The Big Web Show (à 4′) :

Monteiro : J’adore le mot créativité. Je pense être quelqu’un de créatif. Je pense que tu es quelqu’un de créatif. Je pense que ma mère est quelqu’un de créatif. Je pense que la créativité est importante, quelque soit votre métier. Mais je ne suis pas un créatif. Je suis designer. C’est mon métier.
Zeldman : Si tu étais là où j’étais quand je bossais dans la publicité, on t’aurait appelé créatif. Parce que c’est ce qui te sépare des costards-cravates. Mais crois moi même les gens du marketing n’aimaient pas non plus être appelés « costards-cravates ».
Monteiro : Les deux titres sont méprisants. Ça suppose que les costards-cravates n’ont aucune créativité en eux, et ça suppose que les « créatifs » n’ont aucun sens des affaires. C’est doublement destructeur. Je veux que ces deux parties aient à la fois un sens des affaires et de la créativité. Et ils l’ont, et je pense que ça doit être reconnu. Les designers qui ont le plus de succès ont un très bon sens des affaires.

J’adore le mot créatif utilisé en tant qu’adjectif.
Je déteste le mot créatif utilisé en tant que nom commun.

Ce week-end, l’authenticité du million de fans de la page de soutien au bijoutier de nice a été largement remise en question, notamment sur le blog de Sébastien Musset ou même par l’AFP. Jusqu’à ce que l’agence KRDS contredise les contradicteurs en allant vérifier les données à leur source.

Ça m’a rappelé un passage de l’avant dernier podcast de John Gruber (vers 2h16), où il parle des rumeurs de la montre intelligente de Samsung :

VentureBeat a de soit-disant images de la montre intelligente de Samsung qui doit être annoncée dans trois jours. Je pense qu’ils se sont fait piégés. Et je ne plaisante pas. Je ne vais même pas en parler sur Daring Fireball. Je ne vais pas le faire.

Ça fait partie des choses dont j’ai peur : que quelqu’un d’autre se fasse piéger par une plaisanterie, que ça tombe pile dans mes cordes, que ça suive mes idées préconçues, et que je me jette dedans aussi, que j’en fasse une boutade, et puis qu’on se rende compte que toute l’histoire était fausse.

Je plaide coupable de beaucoup trop facilement de me jeter sur de fausses informations qui suivent mes idées préconçues (comme quand Yahoo Québec explique que les employés de Google ont droit à un petit coin spécial pour se masturber, sans préciser que « l’information » vient de The Daily Mash, site satirique). Mais ça me rend triste de me dire à quel point une information erronée circule facilement.

Dans les dernières vidéos officielles d’iOS 7, Apple présente quelques nouveautés de Safari. Rien de bien folichon. Mais j’ai été très surpris de voir qu’à chaque vidéo, à chaque capture d’écran, Apple présente volontairement des sites desktop affichés sur iPhone.

Apple présente quelques sites n’ayant pas de version mobile, comme Traveller, Outside Online, National Geographic. Mais surtout, Apple présente les versions desktop des sites du Washington Post, Pitchfork, Lonely Planet, Elle Decor, alors que chacun de ses sites dispose d’une version mobile sur laquelle on est automatiquement redirigée quand on s’y connecte depuis un iPhone.

Si c’était un argument fort pour le tout premier iPhone en 2007 (« ce n’est pas un bébé navigateur », dixit Steve Jobs), ça en devient presque ridicule alors que les nouvelles pages de l’iPhone 5c et 5s fonctionnent très mal sur iOS à cause de leur horrible défilement.

Ce soir, j’ai voulu consulter l’état de mon compte en banque personnel au Crédit Agricole. Je ne sais pas si c’est comme ça dans toutes les banques, mais le Crédit Agricole a cette bizarrerie d’être segmenté selon votre département, où chaque département est considéré comme une entité différente. Quand j’habitais en Picardie et que j’étais au Crédit Agricole Nord Est, je me rendais sur www.ca-nord-est.fr pour consulter mes comptes. Maintenant que j’habite dans le Nord, je suis au Crédit Agricole Nord de France, et je dois me rendre sur le site www.ca-norddefrance.fr (on remarquera que « norddefrance » n’est pas séparé par des tirets, contrairement à « nord-est »). Je trouverais ça plus simple de pouvoir me connecter directement sur le site www.credit-agricole.fr, mais ce site ne sert qu’à faire une redirection sur les sites annexes.

Or donc, en voulant aller consulter l’état de mon compte ce soir, je me suis rendu sur www.ca-norddefrance.fr. Et j’ai tout de suite été interpellé par un message bien mis en avant sur la page d’accueil.

Menace de sécurité
Un virus particulièrement agressif est actuellement actif sur internet. Il s’attaque aux ordinateurs personnels et aux téléphones mobiles. Il permet à des escrocs d’effectuer des virements à partir de vos comptes.

Malgré le titre de l’onglet pas vraiment bien rédigé (« Alerte sécurité virus »), le vocabulaire utilisé est particulièrement effrayant ! « Menace », « virus », « agressif », « escrocs » ! Je ne suis pas sûr que la police utilisée corresponde à la gravité du message. Mais je décide quand même de découvrir de quoi il s’agit en cliquant sur le très peu explicite « En savoir + ».

Pas de chance pour moi, la page a voulu ouvrir la fenêtre en pop-up, qui s’est retrouvée automatiquement bloquée par mon navigateur (Chrome, dans sa configuration par défaut vis-à-vis des pop-ups). La gravité annoncée de la situation ne vaut pas la pénibilité d’ouvrir une fenêtre en pop-up. Je décide alors de passer mon chemin pour le moment.

En cliquant sur le bouton « Accédez à vos comptes » sur la page d’accueil, je suis redirigé vers le domaine www.cr867-comete-g2-enligne.credit-agricole.fr, qui me permet de m’authentifier.

L’URL utilisée n’est franchement pas rassurante, et j’ai un peu de mal à repérer le domaine « credit-agricole.fr » pour m’assurer que je suis bien sur le site de ma banque. Le titre de la page HTML (« AUTH ») et l’absence de favicon dans l’onglet du navigateur n’aident pas à me rassurer. Mais avec l’habitude, je sais que je suis bien sur le site de ma banque. Je vais donc pouvoir me connecter pour consulter mes comptes. Sauf qu’un message rappelant l’alerte sécurité attire à nouveau mon attention.

Le Crédit Agricole accorde une grande attention à la sécurité de ses sites Internet. En tant qu’utilisateur, vous avez également un rôle important et actif à jouer pour assurer la sécurité des informations qui vous concernent. Consultez ci-dessous les RECOMMANDATIONS de SECURITE à respect :

« En tant qu’utilisateur », j’ai un rôle important à jouer pour assurer ma propre sécurité ? Je suis tout ouïe ! Je clique donc sur Nos recommandations. Là, j’ai droit à une fenêtre qui s’ouvre en pop-up (qui n’a cette fois-ci pas été bloquée par mon navigateur), sur cette page. C’est « l’espace sécurité » du site du Crédit Agricole Nord de France, qui vise à m’éduquer sur de bonnes pratiques pour assurer ma sécurité. Sauf que je ne retrouve aucune mention sur cette page de l’alerte sécurité qui m’a fait si peur. Je décide donc de fermer la fenêtre.

En revenant sur la page pour m’identifier à mon compte, je décide de cliquer sur le premier bandeau jaune tout en haut de la page. Là, je suis redirigé vers une page du « Guide sécurité » sur le domaine www.credit-agricole.fr, à l’adresse www.credit-agricole.fr/guidesecurite/Attention-malware-s-installant-sur.html. Le nom de la page HTML attise particulièrement ma curiosité : « Attention-malware-s-installant-sur ». Sur quoi ? Vite ! Dites, moi ! Je commence donc la lecture de la page, et je souris en voyant le titre de la page.

Le design du site n’a clairement pas été prévu pour un titre aussi long. Résultat, le titre passe sur deux lignes, pour un rendu plus qu’amateur. Pour une page censée me rassurer sur la sécurité de mon compte, c’est raté. Je poursuis quand même la lecture des explications sur l’origine de la menace.

Et je commence à comprendre de quoi il s’agit en lisant les explications suivantes.

Les « escrocs » envoient de faux SMS invitant à installer une application au format « .apk », l’extension des applications sur Android. Cela signifie qu’en tant qu’utilisateur d’iOS, je n’ai pas du tout à me soucier de cette alerte. [Insérez ici une blague sur Android et la sécurité]. Le choix d’une capture d’écran du SMS sous iOS me semble alors particulièrement malvenu. Et surtout, nulle part dans l’article il n’est fait mention d’Android ou d’iOS. Le Crédit Agricole parle uniquement et vaguement de « smartphone », ne cherchant pas du tout à rassurer les clients non concernés.

J’ai donc finalement pu oublier tout ça pour consulter tranquillement mes comptes. Mais un message lu dans mes pérégrinations me trotte à l’esprit.

En tant qu’utilisateur, vous avez également un rôle important et actif à jouer pour assurer la sécurité des informations qui vous concernent.

C’est vrai. Et c’est très important d’éduquer ses clients sur la sécurité des informations transmises en ligne et hors ligne.

Mais je pense que l’éducation sur la sécurité, ça passe aussi par une conception de qualité. En ne montrant que peu d’attention pour le choix de ses textes sur le web (comme le « En savoir + » ou le « AUTH » en titre de page), des URL farfelues, des pratiques du web d’un autre siècle (comme l’ouverture de fenêtre en pop-ups), le Crédit Agricole éduque ses clients à s’attendre à un service médiocre. (Ne me lancez même pas sur l’application iOS du Crédit Agricole). Les clients du Crédit Agricole ne sont donc pas surpris de recevoir une demande d’installation d’application sur leur smartphone par SMS. Ils ne seront pas non plus surpris ni méfiants de voir que la dite application est mal fichue, et que sa charte graphique est clairement falsifiée. Parce que c’est ce que le Crédit Agricole conditionne ses utilisateurs à accepter.

Peut-être qu’en ayant des services de qualité irréprochable, ce que j’estime être en droit d’attendre d’un établissement bancaire, les utilisateurs seraient plus méfiants face à des applications d’escroquerie médiocres.