Les archives du mois de mai 2012

Les pratiques mobiles du Mal

De plus en plus, je rencontre des pratiques absolument horribles sur des sites soit disant optimisés pour mobile. Là où j'ai le sentiment que l'ergonomie et l'utilisabilité des sites desktop s'est améliorée, j'ai l'impression qu'on fait un retour 10 ans en arrière sur mobile. Des chefs de projet, graphistes, développeurs et intégrateurs se permettent tout et n'importe quoi sans aucune considération pour les utilisateurs de leurs sites.

Les redirections automatiques foireuses
C'est sympa de vouloir me rediriger d'un site normal vers votre site mobile. Mais si c'est pour me rediriger sur votre page d'accueil mobile, et pas sur la page où je souhaitais aller, ça ne sert à rien.  Cet XKCD décrivait bien ce problème.
Exemple : La Redoute

Les alertes pour télécharger une application mobile
Écoutez, si je viens sur votre site, c'est probablement pour une bonne raison. Peut être que je serais intéressé par votre application mobile, mais clairement pas maintenant, pas tout de suite.
Exemple : La Redoute (encore)

Empêcher de zoomer
Ça, ça me laisse complètement abasourdi. On est en 2012, on a des appareils tactiles absolument  incroyables, qui me permettent de totalement m'approprier le contenu affiché, en zoomant sur ce que je souhaite regarder ou lire. Et pourtant, de nombreux sites mobiles empêchent de zoomer. Il n'y a aucune raison valable pour ne pas laisser un utilisateur zoomer. Arrêtez de faire ça.
Exemple : Amazon

Masquer la barre d'adresse du navigateur
J'aimerais bien étriper celui qui a lancé cette idée. Oh, bien sur techniquement ce n'est pas compliqué, il suffit de faire un window.scrollTo(0,1). Sauf que cette solution est la pire au monde, car elle ne tient pas compte du fait que vous ayez déjà scrollé ou pas. Et surtout en masquant la barre d'adresse et votre propre URL, vous laissez la porte ouverte au phishing.
Exemple : Amazon (encore)

Empêcher d'afficher la barre d'adresse du navigateur
Encore pire que de simplement masquer la barre d'adresse, certains sites empêchent purement et simplement de remonter pour réafficher la barre d'adresse. Ces sites utilisent en général des barres de menu en position:fixed (le tout simulé en JavaScript bien entendu, tant qu'on y est, autant faire dégueulasse jusqu'au bout). Et puis voilà. C'est fini. Vous êtes bloqués sur ce site. Le seul moyen de changer de site, c'est de fermer l'onglet, et d'en rouvrir un autre. Oh, non bien sûr, sur iOS vous pouvez appuyer sur la barre système tout en haut de l'écran pour scroller tout en haut, mais j'ai un doute sur le nombre de vraies personnes qui connaissent ce raccourci, et qui auront la présence d'esprit de l'utiliser.
Exemple : Paper.li

Ce ne sont que quelques exemples que j'ai croisé récemment. Ce qui me dégoûte, c'est que toutes ces pratiques seraient facilement reconnues comme inacceptables sur PC. Sérieusement, vous empêchez aussi à vos utilisateurs de scroller ou de zoomer sur vos sites desktop ? Non. Alors, arrêtez de le faire sur mobile.

Les contraintes de l’intégration

En gestion de projets, il y a un modèle représenté en triangle qui lie les trois principales contraintes d'un projet (le temps, le coût, et la qualité). Cette théorie définit que pour n'importe quel projet, vous ne pourrez choisir que 2 des critères sur les 3.

Le triangle qualité, coût, délai

Dixit Wikipédia :

  • Vous pouvez concevoir quelque chose rapidement et de qualité, mais ça vous coûtera très cher.
  • Vous pouvez concevoir quelque chose rapidement à bas coût, mais ce ne sera pas de très bonne qualité.
  • Vous pouvez concevoir quelque chose de bonne qualité à bas coût, mais ça prendra beaucoup de temps.
Je pense que ce modèle s'applique particulièrement bien en intégration. Mais surtout, on peut le pousser encore plus loin en intégrant tous les critères qui définissent la qualité d'une intégration. On arriverait alors au modèle octogonal suivant.
Le modèle octogonal de l'intégration
Dans ce modèle, vous pouvez choisir deux critères principaux. Les autres critères pourront être affectés, négativement ou positivement. Par exemple :
  • Vous pouvez intégrer une page qui soit parfaitement fidèle au design maquetté, compatible avec l'ensemble des navigateurs, mais ça va surement vous demander beaucoup de temps, coûter cher, et détériorer la maintenabilité et la performance de la page.
  • Vous pouvez intégrer une page qui soit très performante et bien optimisée pour le référencement. Il y a des chances que ça améliore au passage l'accessibilité de votre page. Par contre, le design et la maintenabilité vont en pâtir.

L'intégration, c'est avant tout une histoire de balance. Vous n'aurez jamais le beurre, l'argent du beurre, et la crémière. Vous devez alors faire des choix, qui influeront directement sur le résultat final.

Il est assez courant d'entendre des graphistes râler parce qu'on n'a pas respecté au pixel près leur design. Mais si cet écart du design s'est fait au bénéfice de la performance, du référencement, de l'accessibilité et de la maintenabilité, alors on a quand même réalisé une intégration de meilleure qualité.

A l'opposé, il est particulièrement nocif sur un projet de laisser un critère prendre le dessus sur tous les autres. Quand vous cédez aux retours capricieux d'un graphiste, ou quand vous cédez à la pression d'un chef de projet qui veut son site pour dans une heure, vous devrez forcément négligez les autres critères, et votre intégration ne sera pas qualitative.

Merde à la pub

Ce week-end, je suis tombé via Twitter sur une intervention chez Mediapart de Daniel Schneidermann, fondateur/directeur d'Arrêt sur Images :

Internet nous offre le luxe incroyable de nous permettre au moins de tenter d'être financé uniquement par ceux pour qui on travaille, c'est à dire nos lecteurs. C'est le luxe incroyable de pouvoir dire d'emblée "Merde aux investisseurs" et "Merde à la pub".

J'aimais beaucoup Arrêt sur Images lors de leur diffusion sur France 5. Je n'ai pas vraiment suivi leur aventure sur le web, mais je suis ravi de voir qu'ils s'en sortent bien avec un modèle économique d'abonnement payant, et pas en se reposant sur des bannières publicitaires.

Je suis persuadé que le nombre de bannières publicitaires influe directement négativement sur la qualité journalistique d'un site internet. La semaine dernière, Kelly Stewart imaginait sur son blog comment naissait les rumeurs sur les produits Apple, et je pense qu'on ne doit pas être loin de la vérité :

1. Il est 16h49 un vendredi.
2. Ils sont à quelques dizaines/centaines/milliers de pages vues près pour faire leur mois.
3. Ils écrivent un paquet de mensonges sur un produit fictif et pour ajouter un peu de crédibilité ils ajoutent la fameuse ligne "des sources familières avec le sujet".

Le problème des sites qui vivent uniquement de la publicité, c'est que leurs revenus dépendent plus du volume de pages affichées que de la qualité de leurs articles. Bien sûr, en écrivant de bons articles, le volume de pages affichées devrait suivre. Mais pas forcément autant qu'en écrivant un article inventé de toute pièce, ou un bon vieux troll des familles. Et surtout, en dépendant de la publicité, ces journalistes ont tout intérêt à ce que vous quittiez rapidement leur site via une publicité. Pas vraiment de quoi les inciter à faire leur travail.

J'ai vraiment le sentiment que se baser sur des bannières publicitaires pour gagner de l'argent, c'est le modèle économique du pauvre. Non pas parce que ça ne rapporte rien. Mais parce que c'est la solution de facilité, qui ne demande pas vraiment de réflexion à mettre en place, et qui ne présente pas vraiment de risque. Mais la plupart du temps je suis convaincu que ce n'est pas la meilleure solution.

La semaine dernière, je suis tombé sur la conférence "Better Revenue Through UX" qui illustre parfaitement ça. Melissa Matross est responsable Expérience Utilisateur chez HotWire, site comparateur de réservations de vols et d'hotels. Elle raconte son travail au sein de l'entreprise, et comment elle a réussi à retirer les bannières publicitaires en faveur d'une fonctionnalité plus subtile.

J'ai eu de la chance, et mon chef m'a dit quelque chose qui a vraiment fait écho en moi, et qui je pense a changé la direction de ma carrière : "Si tu veux te débarrasser des publicités, trouve un moyen pour remplacer les revenus".

C'est une déclaration plutôt simple, non ? Ça devrait être évident. Mais ça ne l'était pas Alors je me suis mise à y réfléchir, beaucoup. Je vais vous présenter d'abord la solution, puis comment j'ai décortiqué le problème.

La solution pour remplacer de la publicité

Voici à quoi ressemble l'outil qui a remplacé la publicité. Dans le coin en haut à droite, il y a cette petite boîte grise. C'est assez subtil. Ça dit "Comparez avec d'autres sites". Et on y trouve quelques cases à cocher vers nos concurrents. Certaines sont pré-cochées, d'autres pas. Quelque chose de vraiment simple, et qui ne vous saute pas au visage. Mais c'est quelque chose que nos clients ont adoré.

Comment ça marche ?

  1. L'utilisateur fait une recherche pour un vol, un hotel ou une voiture.
  2. Il voit des prix intéressants, et se dit "Laissez moi voir si ce sont vraiment de bons prix".
  3. Il remarque la boîte "Comparez avec d'autres sites" judicieusement placée au dessus des résultats de recherche.
  4. Il pense : "Hey c'est trop facile. Hotwire doit vraiment avoir les meilleurs prix puisqu'ils me permettent de comparer avec d'autres sites. Mais je vais quand même aller vérifier de toutes façons..."
  5. L'utilisateur coche en moyenne 3 cases et va vérifier sur les autres sites.
  6. Hotwire est payé pour chaque recherche effectuée sur les autres sites.

Je vous laisse regarder la conférence (seulement 15 minutes), mais il se trouve que ça a plutôt bien marché pour eux.

Si vous avez un site, un produit, une application, et que vous souhaitez le monétiser, réfléchissez à toutes les solutions qui s'offre à vous avant de vous jeter sur des bannières publicitaires.

Un navigateur Facebook

Hier, le site Pocket-lint rapportait que Facebook serait en négociation pour racheter Opera. Il ne s'agit que d'une rumeur, mais certains signes semblent confirmer que des négociations pourraient bien être en cours. Mais surtout, cette rumeur relance l'idée d'un navigateur Facebook.

Un navigateur Facebook

Si l'idée n'est pas nouvelle, elle refait surface régulièrement ces derniers temps. Le mois dernier chez CNET, Ben Parr expliquait pourquoi Facebook devrait lancer son propre navigateur :

Pensez-y une minute. En une seule mise à jour, Google pourrait transformer Chrome en sa propre version de Rockmelt. Il s'agirait d'un navigateur social qui mettrait Google+ au premier plan pour ses utilisateurs avant qu'ils n'aient la moindre chance de taper Facebook.com dans la barre d'adresse.

Vous pensez que Google ne le fera pas ? Ils ont déjà commencé à sortir des extensions qui intègrent Google+ dans Chrome. Je soupçonne que ces extensions sont juste des précurseurs de leur intégration dans Chrome.

J'ai un doute sur le fait que Google+ représente aujourd'hui la moindre menace pour Facebook. Mais vu l'insistence de Google à forcer Google+ dans la bouche de ses utilisateurs dans tous ses services, Google+ pourrait devenir une menace.

Là où je pense que Facebook pourrait bénéficier de son propre navigateur, c'est dans la compréhension de ses utilisateurs et la création de nouveaux services. J'ai le sentiment que Facebook arrive un peu au bout du concept de réseau social tel qu'ils l'avaient imaginé. Facebook doit désormais comprendre ce que fait l'internaute en dehors de Facebook. Si les boutons J'aime et autres widgets parsemés sur de nombreux sites leur permettent déjà de nous suivre à la trace, un navigateur Facebook pourrait récolter encore plus d'infos (de la même manière que Google Chrome récolte nos infos pour "améliorer leurs services"). L'idée d'un navigateur social n'est pas nouvelle, et les navigateurs Rockmelt ou le décédé Flock sont déjà passés par là.

Maintenant, j'ai des doutes concernant le rachat d'Opera. D'un point de vue stratégique pour Facebook, ce serait une excellente chose. Opera Mobile/Mini est le navigateur le plus utilisé au monde sur mobile, plus particulièrement en Asie. Là où ça se complique, c'est qu'Opera n'est pas juste un navigateur. C'est un ensemble de solutions professionnelles pour embarquer leur navigateur (comme par exemple avec Nintendo sur Wii et DS). Si Facebook rachète Opera, ils devront aussi s'occuper de ça, et je ne vois pas vraiment l'intérêt.

Mais surtout, le rachat d'Opera risquerait d'atteindre des sommes astronomiques. Le mois dernier, Facebook a racheté Instagram pour 1 milliard de dollars. Instagram, c'est 13 employés, et 30 millions de comptes enregistrés, et zéro euros de bénéfices. Opera, c'est plus de 750 employés, plus de 200 millions d'utilisateurs à travers le monde, et 80 millions d'euros de bénéfices. Même si Facebook veut se lancer de manière sérieuse et stratégique sur le marché des navigateurs, je ne vois pas comment ils pourraient racheter Opera.

Maintenant, un point intéressant que j'ai découvert en rédigeant cet article, c'est que le décédé navigateur Flock n'est plus tout à fait décédé. Depuis début avril, la page d'accueil de leur site affiche une mystérieuse citation de Mark Twain ("The rumors of my death have been greatly exaggerated."), suivi d'un "Stay tuned". Vu les tumultes de la vie du navigateur, un retour sous la même forme semble assez improbable. Mais à l'heure actuelle, et ce depuis leur rachat en janvier 2011, Flock est la propriété de Zynga. Zynga, c'est la plus grosse société de jeux sur réseaux sociaux, et qui a elle seule a contribué à 11% du chiffre d'affaires de Facebook en 2011. Un rachat de Flock par Facebook me semble alors beaucoup plus réaliste.

Personnellement, je me demande souvent quelles sociétés pourraient faire leur entrée sur le marché des navigateurs. Si je me dit qu'Adobe pourrait trouver sa place avec un navigateur orienté conception/design/intégration, Facebook semble un prétendant vraiment bien trouvé. Et avec un navigateur de qualité, Facebook pourrait vraiment facilement attirer ses utilisateurs, là où des navigateurs comme IE, Firefox et Safari ont beaucoup de mal à inviter directement de nouveaux utilisateurs. Et dans un futur hypothétique où Facebook sortirait un navigateur, et où ce navigateur rencontrerait un minimum de succès, j'ai bien peur que le grand perdant sur le marché ne soit Firefox. Si vous utilisez beaucoup les services de Google, vous avez tout intérêt à utiliser Google Chrome. Dans une moindre mesure, c'est également vrai pour Microsoft et IE, et pour Apple et Safari. Si vous utilisez beaucoup Facebook, vous aurez tout intérêt à utiliser un navigateur Facebook.

 

La rétro-compatibilité

Je crois que le truc qui me plaît et me fascine le plus dans l'intégration, c'est de savoir que ce que je code aujourd'hui fonctionnera encore demain. Et quand je dis demain, je veux dire dans 10, 20 ou 30 ans.  Je me suis fait la réflexion récemment en revisitant 2 de mes tous premiers sites perso encore en ligne (ici ou ), créés il y a exactement 10 ans.

Ces sites ont été créés à l'époque d'IE6, Netscape et Firebird, sous Frontpage 98, avec une connexion ADSL 512k chez Wanadoo. Mais ils tournent parfaitement aujourd'hui sur Chrome 19, Firefox 14, ou même sur Safari sur mon iPhone en 3G.

En comparaison, si vous avez développé une application sous Mac OS 9 il y a 11 ans, il n'y a quasiment aucune chance pour qu'elle fonctionne encore sous Mac OS aujourd'hui. La même chose est surement valable pour Windows. Et je ne parle même pas du fait que si vous avez gravé à l'époque vos applications sur CD-R, ces derniers sont très certainement périmés et inutilisables.

Sur le web, la rétro-compatibilité est possible grâce aux standards qui essayent de l'assurer dans toutes les spécifications. Et ça souligne bien à mon avis l'importance de ces standards. Il y a quelques mois, Nicolas Hoffmann relatait de manière amusante une conversation qu'il a eu lors du passage à IE7 chez l'un de ses clients, dont voici un court extrait :

— (s'adressant à moi) Vous devez être sous perfusion de stress ces temps-ci !
— Heu non, pas en particulier, pourquoi me dites-vous cela ?
— Bin avec la migration, ça tourne à la catastrophe chez nous.
— Quelle migration ???
— Bin on va passer à Internet Explorer 7, et c'est pas triste avec nos intranets.
— (interloqué) Et pourquoi donc ? Ça fait un bout de temps qu'il est sorti, ça marche plutôt bien, et honnêtement ça a pas changé grand chose par rapport au 6.
— Vous plaisantez ? Les intranets avec ActiveX ne fonctionnent plus correctement, on a des bugs de rendu, ça fait des mois et des mois qu'on bosse à cette migration, et on a problèmes sur problèmes !
— Ah bon ???

Si vous ne vous conformez pas aux standards, vous ne bénéficierez probablement pas de cette rétro-compatibilité. Si vous avez un site qui dépends fortement de Flash, Silverlight ou Real Player, vous commencez surement à en faire les frais.

Ce qui me fait sourire, c'est qu'il y a 10 ans, je ne me serais jamais imaginé pouvoir consulter les sites que je concevais sur des terminaux mobiles tactiles connectés en permanence à Internet. Et alors que le marché des navigateurs était constitué principalement de Microsoft et Netscape/Mozilla, je n'aurais probablement jamais suspecté qu'Apple puis Google entrent aussi sur le marché. Cela me laisse rêveur quant aux façons dont je naviguerais dans 10 ans sur les sites que je crée aujourd'hui. Et surtout, ça m'inspire ce slogan d'Hipster Intégrateur :

I code for browsers that don't even exist yet