HTeuMeuLeu

« Regarde toutes les minorités »

Le mois dernier, je suis tombé via Twitter sur cette excellente conférence TED de Maysoon Zayid, une comédienne atteinte de paralysie cérébrale qui raconte son parcours face au ressenti de son handicap. C'est vraiment l'une des meilleures conférences TED que j'ai regardé ces dernières années. Voici quelques morceaux choisis :

S'il y avait des Jeux Olympiques de l'Oppression, je gagnerais la médaille d'or. Je suis Palestinienne, Musulmane, je suis une femme, je suis invalide, et je vis dans le New Jersey. […]

J'ai eu une bourse pour l'Université d'État d'Arizona, parce que je remplissais chacun des quotas. […]

Les gens avec des handicaps constituent la plus grande minorité au monde, et nous sommes les plus sous-représentés dans le spectacle. […]

En l'écoutant, ça m'a rappelé un sketch de Louis C.K. (qui avait fait le tour du web en image) :

J'ai lu quelque chose dans le journal qui m'a vraiment embrouillé l'autre jour. Ça disait que 80 % des habitants de New York sont des minorités…

Est-ce qu'on ne devrait pas arrêter de les appeler « minorités » quand elles représentent 80 % de la population ? C'est vraiment une attitude de blanc, vous voyez. Vous pourriez emmener un homme blanc en Afrique, et il vous dirait « Regarde toutes les minorités qu'ils ont ici ! ».

Cela m'amène à un projet qui m'occupe actuellement. J'ai commencé à travailler sur le lancement d'un nouveau site pour un client. J'ai regardé les statistiques d'un autre site du même client, et voici ce que j'ai vu :

Position Navigateurs Pages vues
1. Microsoft Internet Explorer 11 12,8%
2. Mobile Safari 7.0 10,3%
3. Microsoft Internet Explorer 9 8,2%
4. Microsoft Internet Explorer 10 6,6%
5. Google Chrome 36.0 5,4%
6. Microsoft Internet Explorer 8 5,3%
7. None 4,4%
8. Android Browser 4.0 3,7%
9. Google Chrome 37.0 3,3%
10. Mozilla Firefox 31.0 2,9%
11. Google Chrome 32.0 2,0%
12. Google Chrome 35.0 2,0%
13. Safari (unknown version) 2,0%
14. Google Chrome 31.0 1,7%
15. Mozilla Firefox 30.0 1,6%
16. Google Chrome 33.0 1,5%
17. Mobile Safari 6.0 1,5%
18. Mozilla Firefox 26.0 1,4%
19. Mozilla Firefox 32.0 1,4%
20. Google Chrome 34.0 1,0%

Regardez toutes ces minorités ! Aucune version de navigateur ne dépasse les 13 % d'utilisation. Même constat avec les différentes résolutions d'écran, où la plus courante (1024x768) ne représente que 14,3 % d'utilisation. Et tout ça, c'est sur près de deux millions de pages vues le mois dernier.

Je me suis toujours intéressé de près aux statistiques des navigateurs. Et ça me fascine toujours autant de voir à quel point, en à peine dix ans, nous sommes passés d'un marché monopolistique composé majoritairement d'utilisateurs d'Internet Explorer 6 sous Windows XP en 1024x768, à un marché composé d'un ensemble de minorités.

En juin dernier, Fiona Taylor Gorringe soulevait une question intéressante sur son blog : « 3 % des utilisateurs naviguent avec IE9 et 14 % des utilisateurs ont un handicap. Pourquoi on ne se préoccupe seulement que des premiers ? ». Je ne dirais pas qu'on se préoccupe « seulement » des vieux navigateurs et jamais des utilisateurs avec un handicap. Mais j'ai clairement bien plus de demande explicite pour ces premiers que ces derniers. C'est un peu une « attitude de blanc » appliquée au web. Mais les minorités sur le web ne sont plus forcément celles qu'on croit.

Retour sur ma conférence à Paris Web 2014

La semaine dernière se sont déroulées les conférences de Paris Web. Cet événement tient une place toute particulière dans mon coeur parce que c'est là-bas, il y a à peine deux ans, que j'ai donné mon tout premier lightning talk en public. Depuis, j'ai poursuivi mon petit bonhomme de chemin en tant qu'orateur, de la Kiwi Party l'an dernier à Sud Web en mai dernier. Cette année, j'ai eu l'immense honneur d'être retenu pour donner une conférence de cinquante minutes sur l'intégration d'e-mails à Paris Web. C'était à la fois la conférence la plus importante que j'ai pu donner, mais aussi celle qui m'a le plus déçu. Voici mon retour d'expérience sur ma conférence à Paris Web 2014.

On me traite souvent de masochiste parce que je parle d'intégration d'e-mails. J'ai même ouvert un blog sur le sujet. Mais l'intégration d'e-mails est au coeur de presque chaque projet web (de newsletters commerciales à un e-mail de mot de passe oublié pour l'admin d'un blog). Et pourtant, l'intégration d'e-mails est considérée comme un sujet anecdotique, presque tabou, et que personne ne prend réellement au sérieux. J'avais déjà proposé une conférence sur le sujet à Paris Web en 2013, en vain. N'ayant pas particulièrement d'autre sujet en tête ou me tenant à coeur cette année, j'ai re-proposé la même chose. Et j'ai été retenu.

J'étais alors particulièrement enthousiaste. « Ça y est », me suis-je dit, je vais enfin pouvoir mettre au grand jour tous les problèmes qui entourent l'intégration d'e-mails. Et avec un public comme celui de Paris Web, composé de représentants de tous horizons (W3C, fabricants de navigateurs, grosses boîtes en tout genre), c'est l'occasion idéale pour tenter de faire prendre conscience du problème, et quitte à rêver encore un peu plus, pour initialiser un changement. J'étais d'autant plus ravi quand lors de l'annonce du programme des conférences Paris Web, j'ai découvert que j'aurais l'honneur d'être dans la plus grande salle. C'est le coup de projecteur rêvé pour tenter de faire quelque chose.

J'ai donc commencé petit à petit en juin dernier à rassembler mes notes, mes idées, les horreurs que je peux rencontrer parfois en intégrant ou en recevant des e-mails. Et puis je me suis réellement lancé dans la préparation de ma présentation en septembre dernier. Et c'est à partir de là que ça s'est gâté. Fin septembre, j'ai reçu un e-mail d'un membre de l'équipe de Paris Web m'informant que l'oratrice prévue en même temps que moi ne pouvait plus venir. Ils ont réussi à trouver un remplaçant, mais comme il est anglophone, il faudra qu'il occupe la plus grande salle, qui est équipée pour une traduction audio simultanée. « Crotte », me suis-je dit. Et comme si ça ne suffisait pas, l'orateur en question n'est autre que Vitaly Friedman, le papa de Smashing Magazine, qui venait parler de bonnes pratiques du responsive. « Double crotte », me suis-je dit. Non seulement j'étais relégué dans la plus petite salle. Mais en plus j'allais avoir en face de moi une immense star internationale pour parler d'un sujet autrement plus attrayant que l'intégration d'e-mails.

J'ai poursuivi la préparation de ma présentation, en restant sur mon idée principale de faire une conférence pas trop technique, visant surtout à sensibiliser sur le sujet et toutes ses problématiques. J'ai aussi essayé de rendre ça un minimum divertissant, en y ajoutant des extraits d'un de mes films préférés (j'ai dépensé sans compter). Je me dit toujours que quitte à prendre cinquante minutes à des gens, autant essayer de leur faire passer un moment agréable. Au moins, même s'ils n'apprennent rien, ils ne trouveront pas ça complètement nul.

La première répétition devant mes collègues lundi dernier fut pénible. Je n'étais clairement pas prêt. Et surtout, je tenais tout juste une trentaine de minutes. J'ai passé les deux jours qu'il me restait à retravailler tout ça. Au total, j'ai dû passer l'équivalent de six jours (soit une bonne quarantaine d'heures) à préparer cette conférence.

Le jour J arriva. En parcourant mes slides tout seul dans ma chambre d'hôtel le matin même, je me suis senti prêt. Je tenais la conférence que j'avais envie de donner. J'étais planifié pour passer en deuxième l'après-midi. J'ai choisi d'assister à la conférence me précédant dans la même salle. Autant dire que je n'ai rien suivi. Je repassais mes slides en boucle dans ma tête. Et puis je commençais petit à petit à stresser. La plus petite salle dans laquelle je me trouvais n'était finalement pas si petite. En regardant le public autour de moi, ça faisait quand même beaucoup de monde. « Est-ce que ces gens resterons pour ma conférence ? », me demandais-je. J'ai rapidement eu la réponse. Une fois la conférence terminée, la salle s'est vidée. Je suis monté sur scène pour tout préparer et vérifier que tout fonctionne bien. Et je contemplais la salle désespérément vide. « On attends encore une minute et tu peux commencer », m'a lancé un membre de l'équipe de Paris Web. « Ah ? Mais on attends pas qu'il y ait plus de monde ? En une minute il n'y aura pas beaucoup plus de monde ! » ai-je pensé naïvement. J'ai compté, et on devait à peine être une soixantaine. Je m'attendais à ce que Paris Web soit l'événement où je parle devant le plus de spectateur. C'est en fait devenu l'événement où j'ai parlé avec le moins de spectateur. Je ne me suis pas laissé décourager pour autant, et j'ai lancé mon premier slide. (Non sans ironie, j'avais prévu de démarrer ma conférence en expliquant que l'intégration d'e-mails est un sujet qui fait fuir les intégrateurs.)

Finalement, tout s'est bien passé. J'ai avalé mes 188 slides les uns après les autres. J'ai entendu les gens rire. Je pense en avoir entendu d'autres pleurer en découvrant certaines horreurs. Je n'ai pas eu l'impression de trop bafouiller. Je n'ai pas eu de trou de mémoire. Tout s'est bien passé.

Et puis est arrivée l'obligatoire séance de questions-réponses. Et c'est là qu'est intervenu Daniel Glazman, co-président du groupe de travail sur CSS au W3C. Secrètement, j'espérais qu'il soit présent. À la fin de ma conférence, j'évoquais une réunion de travail du W3C sur l'intégration d'e-mails qu'il avait dirigé en 2007. J'espérais qu'il puisse partager son expérience, et pourquoi pas raviver la flamme pour tenter de relancer quelque chose sur le sujet. Sauf que le discours qu'il a tenu m'a littéralement refroidi. Il a expliqué que les équipes de Microsoft qui travaillent sur le moteur de rendu d'Outlook sont totalement distinctes de celles qui travaillent sur le moteur de rendu d'Internet Explorer. Et les équipes d'Outlook n'ont strictement rien à cirer de la qualité de leur moteur de rendu HTML. Et le W3C n'a aucune légitimité à débattre sur des spécifications liées aux e-mails. Aussi, je suis bien gentil avec ma conférence et mon petit blog sur l'intégration d'e-mails, mais si je veux que les choses changent, il faut absolument que j'écrive en anglais et que je participe au groupe communautaire du W3C. « Soit », ai-je pensé. Je ne suis pas convaincu que les équipes du webmail de La Poste lisent souvent ce genre de ressources… « Merci d'avoir passé six jours pour rien à préparer tout ça. Tu peux rentrer chez toi avec l'assurance que rien ne bougera dans les dix prochaines années » ai-je retranscrit dans ma tête.

Une salle presque vide. Une ambition réduite au néant. Voilà comment ça s'est terminé. Peut-être que je m'étais un peu trop monté la tête, peut-être que je m'étais mis trop de pression, en m'imaginant que j'arriverais faire à bouger les choses… Ou peut-être pas.

Les vidéos de toutes les conférences de Paris Web ont été rendues disponibles en ligne dès le jour même. (Au passage j'en profite pour féliciter toute l'équipe de Paris Web qui réalise un travail colossal et profondément utile, tout ça bénévolement.) À ma grande surprise, ma conférence est en train de vivre une deuxième vie sur le web. Sur le site de Livestream, elle affiche déjà 1891 vues (soit la troisième plus vue après les lightning talks et l'excellente conférence de Christophe Porteneuve sur JavaScript). Et puis surtout, sur Twitter ou ailleurs, j'ai reçu des commentaires très positifs. Et notamment des remarques inattendues comme celle de PinGoo sur mon blog dédié à l'intégration d'e-mails :

Pour info, [ta conférence] a fait pas mal réfléchir nos chefs de projets sur le temps que l’on passait à vouloir faire du pixel perfect sur nos newsletters. Merci !

Il ne m'était même pas venu à l'esprit que des chefs de projet puissent être intéressés par ma conférence (et aussi que des boîtes vendent encore du pixel perfect, mais ça c'est une autre histoire).

Et puis pas plus tard que ce matin, j'ai vu passé ce tweet de David Rousset, évangéliste HTML5 chez Microsoft :

Grâce à l'excellente conf à Paris Web de HTeuMeuLeu, nous allons peut-être enfin améliorer nos newsletters Microsoft !

Bon, à choisir, je préférerais que Microsoft améliore le moteur de rendu HTML d'Outlook. Mais c'est déjà un bon début. Et peut-être que finalement je n'aurais pas fait tout ça pour rien…

Faire un lien sur toute une zone en CSS

On m'a récemment rappelé sur Twitter une pratique qui m'exaspère au plus haut point ces derniers temps. Sur certains sites, le clic secondaire sur des liens est rendu inutilisable. C'est le cas par exemple sur Factornews (j'aime beaucoup Factornews, notamment quand ils font des jeux de mots comme à la fin de cet article).

Factornews

Dans la première zone d'actualités du site, chaque encart d'actualité est entièrement cliquable. Mais si j'utilise le clic de la molette de ma souris (pour ouvrir le lien dans un nouvel onglet), il ne se passe strictement rien. Si je maintiens appuyé la touche majuscule de mon clavier (pour ouvrir le lien dans une nouvelle fenêtre), mon raccourci sera ignoré et le lien sera ouvert dans la fenêtre courante.

Si le clic se comporte comme ça, c'est parce que ce n'est pas un vrai lien HTML. Ici, pour chaque actualité, seul le titre de l'actualité est dans une balise <a>. Le clic sur le reste de la zone est géré via JavaScript. La volonté de rendre toute la zone cliquable est fortement louable, mais l'annulation du comportement natif d'un navigateur engendrée nuit fortement à l'utilisabilité. Je rencontre ce genre de problèmes régulièrement sur d'autres sites comme Le Bon Coin ou LEGO Ideas.

Ce problème d'intégration est vieux comme le monde. Prenons par exemple le code HTML suivant.

<article class="item">
	<h1><a href="/faire-un-lien-sur-toute-une-zone-en-css">Faire un lien sur toute une zone en CSS</a></h1>
	<p>On m'a récemment rappelé sur Twitter une pratique qui m'exaspère au plus haut point ces derniers temps…</p>
</article>

En XHTML ou en HTML4, une balise <a> ne pouvait contenir que des éléments inline. Du coup, l'utilisation de JavaScript (voire de jQuery) était fortement recommandée pour résoudre ce problème. Aujourd'hui, les quelques lignes suivantes suffiraient à rendre toute la zone cliquable pour tous les éléments .item sur notre page.

document.addEventListener('DOMContentLoaded', function() {
	var items = document.querySelectorAll('.item');
	for(var i=0; i < items.length; i++) {
		var item = items[i];
		item.addEventListener('click', function() {
			var url = this.getElementsByTagName('a');
			if(url.length > 0)
				url = url[0];
			window.location = url;
		});
	}
});

Mais cette solution est à l'origine des problèmes d'utilisabilité qui m'exaspèrent tant.

La spécification HTML5 a changé la donne, et on peut désormais englober dans un <a> n'importe quel élément. On pourrait alors simplement englober tout notre .item d'une balise <a>. Mais ce n'est pas forcément une bonne idée, en particulier pour le référencement où il serait préférable de conserver un contenu texte court et pertinent.

Heureusement, une solution est possible en CSS. En utilisant un pseudo-élément ::before ou ::after, on peut le positionner en absolu par rapport au conteneur principal parent et faire en sorte qu'il occupe tout l'espace. Il faudra bien s'assurer que le conteneur parent en question (.item) ait lui aussi un positionnement non statique afin de restreindre le pseudo-élément du lien. Le code suivant fait alors l'affaire.

.item {
	position:relative;
}

.item a:before {
	content:'';
	position:absolute;
	left:0;
	right:0;
	top:0;
	bottom:0;
	background-color:rgba(0,0,0,0);
}

Ça fonctionne bien dans Chrome, Firefox, Safari et Opera. Pour Internet Explorer (9 et plus), il est nécessaire d'ajouter un fond transparent afin que la zone soit cliquable même au-dessus des autres éléments.

L'inconvénient de cette solution est qu'elle ne s'applique pas sur IE8. Même si le pseudo-élément est bien créé, celui-ci restera non cliquable sous les autres éléments de la zone. Mais si vous pouvez vous permettre d'avoir un fonctionnement dégradé gracieusement sur IE8, cette solution me semble assez élégante.

Mario Kart 8 2.0 et le bouton « Course suivante »

La première mise à jour avec du contenu téléchargeable de Mario Kart 8 est sortie aujourd'hui. La meilleure partie de cette mise à jour pour moi est la suivante, annoncée en début de mois :

L’ordre du menu suivant chaque course sera modifié en "Course suivante, suivi par "Voir les temps forts".

« Course suivante »

Non seulement ils ont corrigé ce problème, mais surtout ils choisissent de le mettre en avant comme l'une des « fonctionnalités conçues pour améliorer l’expérience de conduite des joueurs ».

Le bon design, c'est aussi apprendre et corriger ses erreurs.

L’attribut srcset pour des images responsive

L'attribut srcset est un nouvel attribut pour les balises images décrit dans la spécification de HTML 5.1. Il permet de résoudre en partie l'une des plus grosses problématiques de l'intégration de sites responsive : les images.

Venant en complément de l'attribut src habituel d'une balise <img>, l'attribut srcset permet de spécifier une liste d'images à afficher selon des critères particuliers. L'immense avantage, c'est que c'est le navigateur qui décide quelle image afficher, et que seule cette image sera téléchargée.

Son implémentation a déjà commencé depuis février dernier dans la version 34 de Chrome, mais limitée à la sélection d'image selon la densité de pixels de l'écran d'un appareil. Ainsi dans le code suivant, je peux préciser le chemin d'une image optimisée pour des appareils avec une densité de pixels à l'écran d'au moins 2 (aussi vulgairement appelés « écrans rétina »).

<img src="default.jpg" srcset="hidpi.jpg 2x" />

C'est déjà un bon début. Mais ce qui est vraiment bien, c'est que les navigateurs commencent maintenant à implémenter la suite, à savoir la sélection d'images selon le viewport. C'est en cours d'implémentation dans Chrome, Opera, et dans Firefox derrière un flag. Et surtout, ce sera activé par défaut dans Safari 8 sur iOS 8 et OS X Yosemite. Cela signifie que d'ici la fin de l'année, la majorité des navigateurs supporteront srcset. (Pour Internet Explorer, c'est pour l'instant « en considération ».)(On me fait signe que la version beta actuelle de Safari 8 ne supporte que la première partie de la spécification, et pas la sélection d'images selon le viewport).

Il y a donc de quoi être tout excité par cette nouveauté. J'ai fait mumuse avec srcset ces derniers jours, et voici que j'ai appris et compris.

Tout d'abord, pour tester tout ça, il va falloir installer ou configurer les navigateurs compatibles. Pour avoir Safari 8 sur iOS, vous pouvez télécharger la beta de Xcode 6 dans laquelle vous aurez la dernière version du Simulateur iOS. Pour avoir Safari 8 sur OS X, vous pouvez télécharger la bêta publique de OS X Yosemite.
Pour Chrome, vous pouvez télécharger Chrome Canary (actuellement en version 38).
Pour Firefox, vous pouvez télécharger Firefox Nightly (actuellement en version 34). Puis il faudra activer le support de srcset à la main. Pour ça, il faut aller à l'adresse about:config, chercher les préférences dom.image.srcset.enabled et dom.image.picture.enabled, et les passer toutes les deux à la valeur true.

Nous sommes prêts pour tester. Pour commencer, nous allons préciser dans srcset une liste de quatre images : small.png (320x240), medium.png (640x480), large.png (1024x768) et xl.png (1920x1080). Si le navigateur ne supporte pas srcset, c'est l'attribut src qui prendra le relais avec l'image default.png (1024x768). Voici le résultat de ce premier exemple avec le code suivant :

<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" alt="Test" />

Comme vous pouvez le constater, chaque image est accompagnée d'un « descripteur w » (dixit la spécification, en opposition au « descripteur x » utilisé lui pour la sélection selon la densité de pixels d'écran). J'ai eu beaucoup de mal à comprendre la signification de ce descripteur, notamment à cause d'article comme celui publié chez Alsacréations (désolé Geoffrey) qui confondent descripteur w et largeur de viewport. À ce stade, il faut bien comprendre qu'il n'y a aucun lien entre les deux. Le descripteur w est une indication laissée au navigateur sur la largeur en pixels de l'image correspondante.

Là où la spécification de srcset est surprenante, c'est dans la façon de décrire comment un navigateur va choisir l'image à afficher :

L'agent utilisateur va calculer la densité de pixel réelle de chaque image à partir du descripteur w spécifié et des tailles de rendus spécifiées dans l'attribut sizes. Il peut ensuite choisir n'importe quelle ressource en fonction de la densité de pixels de l'écran de l'utilisateur, de son niveau de zoom, ou peut-être d'autres facteurs comme les conditions de réseau de l'utilisateur.

En gros : le navigateur fait ce qu'il veut. Cela signifie que Chrome pourrait décider de choisir l'image la plus petite si la connexion est un peu lente, alors que Safari pourrait au contraire décider de systématiquement choisir l'image la plus grande. Bienvenue dans un futur nouvel enfer du responsive !

À noter qu'actuellement, Firefox ne va charger une image qu'au chargement initial de la page, mais ne rafraîchira pas son affichage au redimensionnement de la fenêtre. La dernière version de Chrome Canary gère très bien ça au redimensionnement (et au passage, la nouvelle vue device mode des outils de développement de Chrome est vraiment bien foutue).

Les choses sérieuses vont commencer en introduisant l'attribut sizes. Celui-ci permet de spécifier la largeur d'affichage de l'image selon des points de rupture. Dans l'exemple ci-dessus, les images vont toujours par défaut prendre 100% de la largeur du viewport. La spécification explique clairement que la valeur par défaut de l'attribut sizes est de 100vw et que dans ce cas, l'attribut peut-être omis. Malheureusement les développeurs de chez Mozilla ont du s'arrêter de lire la spécification juste avant ce paragraphe car dans l'implémentation actuelle, il faut impérativement préciser l'attribut sizes, même pour une valeur de 100vw. (J'ai remonté le problème, et il a déjà été affecté, donc on peut espérer une correction en moins de douze ans.)

Là où sizes est bien pratique, c'est qu'il va permettre de spécifier différentes largeurs d'affichage pour notre image selon le reste du gabarit de notre page. Si par exemple je suis sur un viewport de 800px de large, mais que j'affiche mon image à seulement 400px de large, je peux le préciser dans l'attribut sizes et le navigateur tentera de charger l'image qu'il juge la plus appropriée. En reprenant le premier exemple et en y appliquant cette condition, ça donnerait ce deuxième exemple et le code suivant :

<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" sizes="(width:800px) 400px" alt="Test" />

Ici, l'image est toujours affichée à une largeur correspondant à 100% du viewport, sauf si celui-ci vaut exactement 800px, auquel cas l'image est fixée à une largeur de 400px. Cet exemple est totalement stupide dans la vraie vie.  On pourra alors plutôt écrire ce genre de code un peu verbeux pour ce troisième exemple :

<img src="default.png" srcset="small.png 320w, medium.png 640w, large.png 1024w, xl.png 1920w" sizes="(min-width:20em) and (max-width:50em) 20em, (min-width:50em) and (max-width:80em) 40em, (min-width:40em) 10em" alt="Test" />

J'ai défini ici trois points de rupture précisant des tailles d'images respectivement de 20em, 40em et 10em. Si aucune des conditions des points de rupture n'est remplie, alors le navigateur appliquera à l'image sa valeur par défaut de 100vw.

Là où ça peut devenir un joyeux bazar, c'est qu'on peut combiner les descripteurs w et x. Et tout ça peut être combiné à la balise <picture> qui elle aussi commence à être supportée. Opera a récemment publié un article pour donner des cas pratiques d'utilisation d'images responsive. L'article d'Eric Portis sur « srcset et sizes » est magnifiquement illustré et très complet sur le sujet et m'a aidé à comprendre un tas de trucs.

L’écran de la Moto 360 n’est pas rond

J'avais lu cette information il y a déjà plus d'un mois, mais de nouvelles photos destinées à la presse sorties ce week-end en sont un malheureux rappel. L'écran de la Moto 360 n'est pas rond. Il y a une coupure droite en bas sur toute la longueur.

L'écran de la Moto 360 n'est pas rond

Depuis que je sais ça, je ne vois plus rien d'autre. D'après un responsable de Google répondant à The Verge, c'est une « inévitable étrangeté de conception ». Personne ne sait si Apple travaille sur un projet similaire, mais si c'est le cas, et si je devais répondre à ce tweet, je donnerais la réponse C.

Les statistiques des navigateurs de juillet 2014

J'ai toujours été fasciné par les statistiques globales de parts de marché ou d'utilisation des navigateurs, même si c'est toujours à prendre avec de grosses pincettes. En 2011, je suivais attentivement l'adoption d'IE9 et de Firefox 4. Je m'interrogeais même sur l'avenir que pourrait avoir le marché des navigateurs, en me disant que ce serait chouette d'arriver à un marché sain avec trois concurrents à parts égales.

Ce doux rêve ne dura pas longtemps. L'année dernière, je constatais le passage de la domination d'IE à la domination de Chrome. Ce constat m'a été rappelé cette semaine sur Reddit avec cette carte des navigateurs les plus utilisés par pays (d'après les données de StatCounter).

La carte mondiale des navigateurs les plus utilisés par pays

Ça en devient presque effrayant. Si on compare avec la même carte un an plus tôt, Chrome a réussi à devenir le principal dans de nombreux pays, ne laissant plus qu'à IE que le Japon et la Corée. Firefox s'est aussi bien fait devancer un peu partout dans le monde, et surtout en Afrique, par Opera. L'explosion du web mobile en Afrique que j'évoquais à la sortie de Firefox OS se fait sentir.

Si on regarde le chemin parcouru depuis juillet 2011 (d'après StatCounter), le constat n'en est que plus effrayant. Les statistiques des navigateurs, de juillet 2011 à juillet 2014

En trois ans, en seulement trois petites années, on est passé d'une utilisation de Firefox de 28 % à seulement 17 %. En trois ans, on est passé d'une utilisation d'Internet Explorer de 42 % à 21 %. Et en trois ans, on est passé d'un Chrome à 22 % à 45 %.

Ce qui m'inquiète, c'est que sans bouleversement majeur du marché de l'informatique personnelle, la dégringolade d'IE et Firefox au profit de Chrome ne risque que de s'accentuer. En trois ans, on est passé d'un marché où Windows représentait 85 % des OS utilisés sur le web, à seulement 55 %, suivi par une forte croissance d'Android et d'iOS représentant à eux deux 28 % des OS utilisés sur le web. L'insignifiance de Firefox et Internet Explorer sur le marché mobile ne va certainement pas arranger ça.

En étant pessimiste, dans trois ans, Chrome sera peut-être utilisé par au moins 75 % des internautes. En étant optimiste, dans trois ans, Internet Explorer et Firefox seront peut-être encore là pour voir ça.

A Blind Legend

A Blind Legend est un jeu d'action-aventure audio jouable sur mobile.

Il s'appuie sur les sons binauraux permettant de se repérer dans un environnement en 3 dimensions uniquement par le biais de l'audio, et l'écran tactile du mobile pour contrôler le héros.

Ce jeu est créé par les lyonnais de DOWiNO, et il est en financement participatif sur Ulule depuis un peu plus d'un mois. Il ne reste plus que deux jours pour les aider à financer 22 % du montant total.

Je trouve que c'est vraiment un beau projet, et j'ai participé à son financement sans hésitation. Les développeurs ont sorti une démo du concept de jeu audio (pour Windows ou OS X), et ça m'a conforté dans mon premier ressenti. Je suis fasciné par l'idée de jouer à des jeux à l'aveugle depuis que j'ai lu les histoires de ce canadien qui a fini Zelda : Ocarina Of Time ou cet américain qui a fini Oddworld : L'exode d'Abe.

J'espère que le financement arrivera à son but, et que peut-être vous aussi vous participerez à cette belle aventure.

 

Une interface utilisateur, c’est comme une blague

En mai dernier, j'avais retweeté cette comparaison que j'aime beaucoup (traduite par mes soins) :

Une interface utilisateur, c'est comme une blague. Si vous devez l'expliquer, c'est qu'elle n'est pas si bonne.

La citation a été reprise en français (sans mention de l'auteur original, tant pis), mais avec une légère déformation au passage :

Une interface utilisateur, c'est comme une blague, s'il faut l'expliquer c'est qu'elle n'est pas bonne.

Cette déperdition dans la traduction a généré quelques débats intéressants ici ou . Et si je suis le premier à détester les explications pour utiliser une porte et à préférer l'apprentissage par le design, je sais aussi reconnaître que la complexité est parfois nécessaire.

Prenons par exemple le tableau de bord d'un Airbus A380.

Tableau de bord d'un A380

Au premier abord, pour le néophyte que je suis, cette interface me paraît atrocement compliquée. Mais c'est peut-être parce que je n'y connais absolument rien en aviation. Et cette interface est destinée à être utilisée par des professionnels, ayant suivi des années de formations spécifiques. En soi, c'est plutôt rassurant de se dire que l'interface d'un appareil servant à transporter 800 personnes dans les airs est incompréhensible pour le premier venu.

Je pourrais en dire de même pour les interfaces des logiciels de traders ou même l'interface de World of Warcraft. Mais ces remarques sur les interfaces sont aussi valables pour les blagues.

Voici une de mes blagues préférées découverte ces dernières années (catégorisée dans les « blagues de papas »).

— Call me a taxi.
— OK. You're a taxi.

Au risque de passer pour un idiot, je n'avais pas compris cette blague à sa première lecture. Mais dès que je l'ai comprise, j'ai trouvé ça drôle. C'est une bonne blague. La même chose est valable pour la blague anglophone suivante, lue chez Bruce Lawson :

Jean-Pierre : Toc-toc.
Armand : Qui est là ?
Jean-Pierre : Loste.
Armand : Loste qui ?
Jean-Pierre : Oui, malheureusement.

J'ai dû chercher des explications pour comprendre cette blague. Ça ne signifie pas que c'est une mauvaise blague. Maintenant que je la comprends, je l'apprécie beaucoup.

Une interface utilisateur, c'est comme une blague. Certaines blagues sont compréhensibles instantanément. D'autres nécessitent des explications pour être comprises par des gens comme moi qui pourront ensuite la trouver drôle. Mais ça ne suffit pas pour déterminer si une interface est bonne ou pas.

Tim’s Vermeer

J'ai aussi regardé récemment Tim's Vermeer, un documentaire produit par Penn & Teller (les magiciens). Ils suivent un de leurs amis informaticiens, Tim Jenison, qui s'est mis en tête de reproduire La Leçon de musique de Vermeer.

Je ne connaissais pas Vermeer plus que ça, mais il est soupçonné d'utiliser un système de projection et d'optique afin de reproduire des scènes avec un rendu précis et réaliste.

Tim's Vermeer

Ça m'a fait bizarre, parce que ça m'a rappelé certaines techniques employées au début du millénaire pour reproduire des pages web au pixel près (rires), où l'on superposait une maquette en JPG au dessus d'une page web pour s'assurer de bien respecter le travail du gentil graphiste web (à la main ou avec des outils comme Pixel Perfect).

Tim's Vermeer est disponible en import chez Amazon.fr, et la bande-annonce est visible sur son site officiel ou sur Youtube.