http://www.interfacesriches.fr Toute l'actualité des interfaces riches (Flash, HTML5, 3D...) Wed, 10 Jul 2013 08:17:25 +0000 fr-FR hourly 1 http://wordpress.org/?v=3.5.3-alpha Le Responsive Web Design n’est pas une solution, c’est un compromis http://www.interfacesriches.fr/2013/03/13/le-responsive-web-design-nest-pas-une-solution-cest-un-compromis/ http://www.interfacesriches.fr/2013/03/13/le-responsive-web-design-nest-pas-une-solution-cest-un-compromis/#comments Wed, 13 Mar 2013 06:40:23 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=5363 Voilà près de deux ans que je vous parle de Responsive Web Design. Largement plébiscité par la profession, le RWD est néanmoins petit à petit en train de se transformer en buzz word de l’année. Comprenez par là qu’au même titre que les Big Data ou qu’Ajax à son époque, on nous sort le Responsive Web Design en toutes circonstances comme LA solution miraculeuse à tous les problèmes liés à la mobilité. Or, la mobilité n’est pas un problème, c’est une évolution majeure dans les usages, une tendance forte que l’on peut subir ou exploiter. Bref, il est grand temps de démystifier ce terme et de faire preuve de réalisme.

Le Responsive Web Design est donc un terme générique qui désigne une façon de coder une page web pour qu’elle s’adapte à tous les écrans. Cette technique à largement été popularisée par des sites de journaux prestigieux comme le précurseur Boston Globe ou dernièrement le Time Magazine.

La page d'accueil du Time Magazine sur différents terminaux
La page d’accueil du Time Magazine sur différents terminaux

Le problème du Responsive Web Design est que c’est une technique permettant d’optimiser l’affichage d’un site web conçu pour ordinateurs sur des terminaux mobiles, mais pas de répondre aux besoins spécifiques des utilisateurs en situation de mobilité. Le passage d’un ordinateur avec un grand écran, une souris et clavier à un petit écran tactile n’est pas une mince affaire. Il ne suffit pas de masquer des éléments sur le page ou d’en revoir l’ordre pour satisfaire les mobinautes. C’est un peu comme si vous me disiez qu’il suffit de réduire le nombre de rayons d’un hypermarché pour en faire une supérette de centre-ville. Réduire leur nombre ne suffit pas, il faut tout revoir : les zones de circulation, l’achalandage, la signalétique… Pour un site web, c’est la même chose : si le RWD fonctionne très bien pour un blog et plutôt bien pour un site éditorial, cette technique est par contre perfectible pour un site institutionnel ou une boutique en ligne. La version mobile du site du Vertbaudet est pour moi un très bon exemple : ils ont créé deux versions séparées pour maximiser l’expérience.

La version mobile du site du Vertbaudet
La version mobile du site du Vertbaudet

Plusieurs voix commencent à s’élever pour remettre en question la pertinence de certaines implémentations du RWD : Not All Responsive Web Design Is Created Equal. Pour résumer les propos de cet article : l’étroitisation de la mise en page pose de gros problèmes ergonomiques que des astuces de code ne peuvent pas forcément gérer (cf. Des mises en page adaptives aux systèmes de navigation adaptatifs).

Outre les problèmes ergonomiques, le RWD pose également quelques soucis en terme de référencement : When Responsive Web Design Is Bad For SEO. Le point de départ de cet article est l’outil mis à disposition récemment par Google pour consolider les URLs de version mobiles. Cet outil met un terme à la pénalisation de l’éparpillement des versions d’un site par rapport à l’utilisation d’une URL unique. Plusieurs arguments particulièrement pertinents sont avancés par l’auteur de cet article pour remettre en cause le choix du RWD :

En résumé : le Responsive Web Design est un compromis très intéressant pour toucher un maximum de mobinautes en limitant les coûts de développement, mais ce n’est pas une solution universelle, loin de là. Vous noterez d’ailleurs que les grands acteurs ne se limitent pas à un site en RWD (Amazon, Ebay…), ils éditent différentes versions pour maximiser l’expérience. Les investissements sont certes plus élevés, mais l’excellence à un prix.

J’ai publié récemment un article sur la façon de remédier aux problèmes de temps de chargement (Améliorez la performance de vos interfaces mobiles avec RESS), aussi je vous propose une piste de réflexion pour maximiser le référencement : utiliser des landing pages mobiles pour répondre aux besoins des internautes en situation de mobilité. Ces landing pages  mobiles seraient spécifiquement référencées en fonction des recherches utilisées en situation de mobile, et proposeraient les contenus et/ou fonctionnalités les plus pertinentes pour les mobinautes.

Tout ceci renforce le besoin des marques avec un minimum d’ambitions de nommer un Chief Mobile Officer pour bien appréhender les besoins des mobinautes et définir une feuille de route cohérente (cf. Pourquoi lancer une application mobile ne sert à rien).

]]> http://www.interfacesriches.fr/2013/03/13/le-responsive-web-design-nest-pas-une-solution-cest-un-compromis/feed/ 19 Améliorez la performance de vos interfaces mobiles avec RESS http://www.interfacesriches.fr/2013/01/09/ameliorez-la-performance-de-vos-interfaces-mobiles-avec-ress/ http://www.interfacesriches.fr/2013/01/09/ameliorez-la-performance-de-vos-interfaces-mobiles-avec-ress/#comments Wed, 09 Jan 2013 09:14:32 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=5338 Voilà près de deux ans que l’on vous parle de responsive design, cette technique permettant d’adapter la mise en page d’un site web en fonction du terminal utilisé. Largement documenté et utilisé par des sites à très large audience (Microsoft, Vogue, Time, StarbucksZDnet…), le RWD semble avoir conquis les développeurs d’interfaces mobiles. Il existe à ce sujet de nombreux frameworks pour accélérer vos développements comme HTML5 Boilerplate, Boostrap, Foundation, Gumby ou encore Gravity (cf. Five awesome open-source front-end frameworks).

Mais le responsive design n’est pas la solution parfaite, car cette technique repose sur l’affichage ou non de certains éléments dans la page. Le problème est que tous les éléments chargés sont les mêmes, les images et fichiers javascript sont ainsi chargés, mais complètement sous-exploités par les smartphones. De même, les éléments tiers (bannières publicitaires ou plugins sociaux) sont chargés inutilement ou intégrés à l’arrache. Vous l’aurez compris, la performance de ces interfaces est donc un gros problème. Or, le temps d’affichage est un facteur-clé de succès de premier ordre.

Heureusement pour améliorer les performances il est possible de ne charger que les éléments dont vous avez besoin, voire de charger des éléments spécifiquement adaptés à un type de terminal. Cette technique a un nom, et c’est Luke Wroblewski qui l’a trouvé le premier : RESS = Responsive Design + Server Side Components. L’astuce consiste donc à détecter le type de terminal et à charger les éléments qui lui correspondent (images, fichiers HTML et javascript…). Dans l’exemple ci-dessous, il existe deux versions du header et du footer sur le serveur (pour desktop et pour mobiles), seule la version correspondant au terminal utilisé est chargée :

Deux versions distinctes du header et du footer sont utilisées

Cette technique est donc l’évolution logique du responsive design, car elle permet d’optimiser les temps de chargement, aussi bien pour les fichiers HTML et javascript que pour les images. Des explications plus détaillées sont disponibles ici : RESS, Server-Side Feature-Detection and the Evolution of Responsive Web Design.

Il existe également de nombreuses présentations didactiques sur le sujet, notamment ici :

Et ici :

Je vous invite à consulter également cette étude de cas sur le très beau site de l’université de Notre-Dame : Reinventing the Wheel, the Innovation Behind Notre Dame’s Unique New Homepage. Des sites à fort volume comme CNN ou WordPress ont déjà adopté RESS.

RESS est-il donc la solution ultime pour avoir des sites optimisés en fonction du terminal ? Oui, à condition que la détection fonctionne correctement. La détection du type de terminal est donc le talon d’Achille de cette technique. Pour en savoir plus, je vous recommande Server-Side Device Detection: History, Benefits And How-To.

Nous nous retrouvons donc avec trois options pour déployer du contenu ou un service en ligne :

Comme toujours, il n’y a pas de bon ou mauvais choix, uniquement des compromis à faire en fonction de vos ressources et compétences. Pour vous aider, je vous propose enfin ces deux articles qui étudient les avantages et inconvénients de ces trois solutions : Responsive Design, Device Experiences, or RESS? et A Comparison of Methods for Building Mobile-Optimized Websites.

Si vous avez des retours d’expérience, n’hésitez pas à les partager dans les commentaires.

]]> http://www.interfacesriches.fr/2013/01/09/ameliorez-la-performance-de-vos-interfaces-mobiles-avec-ress/feed/ 5 2013 sera l’année du tablet first http://www.interfacesriches.fr/2012/11/06/2013-sera-l-annee-du-tablet-first/ http://www.interfacesriches.fr/2012/11/06/2013-sera-l-annee-du-tablet-first/#comments Tue, 06 Nov 2012 06:01:22 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=5308 Avec l’avènement des connexions haut débit, nous pensions que le web allait supplanter la télévision en terme de contenus vidéos. Plus pratique, plus performant, mieux ciblé… les portails proposant des contenus vidéo ont commencé à fleurir et à petit à petit transformer nos moniteurs en écrans vidéo, à l’image du portail CNN. De même, les dernières techniques d’affichage permettaient aux designeurs de concrétiser leurs rêves les plus fous avec des mises ne page particulièrement audacieuses comme celle de WonderWall (MSN expérimente des nouveaux formats pour ses magazines en ligne).

Mais entre temps, l’iPhone est arrivé… puis l’iPad… et tous leurs concurrents. À partir de ce moment, il n’a plus été question de contenus vidéos (trop lourds pour le réseau de téléphonie), mais de contenus textuels monétisés (L’avenir des magazines numériques est-il à l’HTML5 ?). La multiplication des formats nous a alors replongé dans une période sombre que nous pensions révolue (4 feuilles de styles pour 4 expériences de lecture). Les tablettes sont maintenant définitivement rentrées dans le quotidien des internautes, et leur adoption ne va qu’accélérer avec la mise sur le marché de tablettes low-cost à moins de 200 €.

Nous sommes maintenant dans une configuration de marché où la dichotomie web / mobile n’est plus vraiment d’actualité, car le spectre des formats ne cesse de s’élargir : de 3,5″ à 5″ pur les smartphones, de 7″ à 11″ pour les tablettes, de 11″ à 15″ pour les ordinateurs portables (sans oublier les écrans en retina display d’Apple), de 17″ à 27″ pour les ordinateurs de bureau, à partir de 29″ pour les TV connectées…

Les différents formats de terminaux web

Pour accélérer le travail d’intégration et pour baisser les coûts, mais surtout parce que les formats publicitaires traditionnels ne fonctionnent plus réellement, certains sites comme Amazon et Ebay ont commencé à adopter des mises en page hybrides pour faciliter l’affichage sur les tablettes. Une approche audacieuse qui en a visiblement inspiré d’autres.

Un certain nombre de sites proposent maintenant non pas une mise en page hybride, mais une mise en page directement adaptée aux tablettes. La tendance semble donc s’être inversée avec une nouvelle vague de sites HTML5 tablet first (par analogie avec mobile first), à commencer par le journal USA Today avec sa navigation latérale et sa structure tout en hauteur :

La nouvelle mise en page du journal USA Today

Plus intéressant, les blogs ReadWrite et TheNextWeb qui proposent des barres de navigation minimalistes et une liste des articles sur la gauche de l’écran :

La nouvelle mise en page du blog The Next Web

Vous noterez que cette mise en page n’est pas sans rappeler les dynamic views de Blogger et notamment le mode Sidebar de Blogger. Un choix de conception radical qui privilégie avant tout le confort de lecture sur tablettes (nous ne nous en plaindrons pas) en laissant la part belle aux contenus, comme sur le magazine Quartz.

La mise en page optimisée pour les tablettes du magazine Quartz

Au final, est-ce qu’on y gagne ? Oui, indéniablement. Car si la lecture à l’écran est grandement améliorée grâce à une bien meilleure exploitation de la surface d’affichage (plus de distraction et de multi-colonage), la consultation sur grand écran est indiscutablement plus agréable, et l’adaptation sur smartphone en responsive design est forcément plus rapide. Il est amusant de constater que si les cinq années de croissance folle des smartphones ont laissé les concepteurs froids (l’approche mobile first est encore un débat très sensible), il n’aura fallu que deux ans aux tablettes pour s’imposer d’elles-mêmes comme le format de référence pour les mises en page : 2013 sera l’année du tablet first.

Toujours pas convaincu ? Allez donc faire un tour chez Nike pour changer d’avis.

]]> http://www.interfacesriches.fr/2012/11/06/2013-sera-l-annee-du-tablet-first/feed/ 5 Adobe lance une suite d’outils de développement HTML5 http://www.interfacesriches.fr/2012/10/08/adobe-lance-une-suite-doutils-de-developpement-html5/ http://www.interfacesriches.fr/2012/10/08/adobe-lance-une-suite-doutils-de-developpement-html5/#comments Mon, 08 Oct 2012 12:31:24 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=5299 Vous ne vous en rendez sans doute pas compte, mais le web est dans une étape de transformation cruciale en ce moment. Nous ne parlons pas ici des usages, mais plutôt des technologies, et plus particulièrement de HTML. La dernière évolution en date des standards (HTML5) devait mettre tout le monde d’accord et permettre à l’industrie d’appréhender cette nouvelle itération avec calme et sérénité. Sauf que le torchon brûle entre le W3C (l’organisme de normalisation des standards web) et le WHATWG (le consortium qui pousse pour faire évoluer plus rapidement les standards). Vous serez ainsi surpris d’apprendre que HTML5 n’existe pas, du moins que HTML5 n’existe pas en tant que standard web stabilisé et normalisé par le W3C. Ces derniers avaient initialement prévu de le stabiliser en 2022 (véridique), mais sous la pression des grands éditeurs ont ramené l’échéance à 2014 (W3C announces plan to deliver HTML 5 by 2014, HTML 5.1 in 2016). Trop tard pour le WHATWG, qui y travaille depuis 2007 et a décidé de reprendre en parallèle les travaux d’évolution de HTML (Relationship update on HTML Living Standard and W3C HTML5). Donc pour vous la faire simple : les éditeurs ont décidé de prendre leur distance face au W3C et la lenteur à laquelle ils font évoluer la norme HTML5 (W3C and WHATWG finalize split on HTML5 spec, forking unlikely).

Dans ce contexte, difficile de se lancer dans un chantier d’évolution pour passer de HTML4 à HTML5. Et pourtant, les changements de comportements induits par les terminaux mobiles forcent les éditeurs de contenus ou de services en ligne à évoluer : The New York Times Debuts An HTML5 Web App For iPad et Salesforce Launches HTML5 App For Sales Cloud. Est-ce qu’HTML5 est une technologie tellement révolutionnaire que personne ne peut se mettre d’accord ? Non, il s’agit plus d’une crise d’adolescence du web qu’autre chose. La cinquième version d’HTML apporte ainsi un certain nombre d’améliorations, mais elle ne change pas la face du web. La question de la mobilité est complexe à appréhender (En finir avec le débat application vs. site mobile), mais ne peut être tenue responsable d’un tel foutoir (et encore, je reste poli). À ce sujet, je vous recommande de lire la synthèse publiée par FaberNovel : HTML5, comment repenser votre stratégie web.

Bref, tout ça pour dire que la situation est plutôt instable. Heureusement, certains acteurs s’efforcent de calmer le débat et de proposer des solutions simplifiant la tâche des éditeurs de contenus ou de services en ligne. Adobe vient ainsi d’annoncer le lancement de toute une série d’outils de développement HTML5 : Adobe launches Web-focused Edge family: Animate, Reflow, Code, Inspect, Web Fonts and more. Cette nouvelle famille s’appelle donc Edge et regroupe les outils suivants :

D’autres produits sont associés à cette famille comme TypekitWeb Fonts (un équivalent gratuit, mais en plus limité), et PhoneGap Build (un environnement de déploiement d’applications mobiles multi-support dans les nuages : Adobe Reintroduces PhoneGap, Expanding Mobile App Options). C’est donc une famille d’outils particulièrement complète que nous propose Adobe, d’autant plus intéressante qu’une attention toute particulière a été portée aux terminaux mobiles. Cette famille apporte donc la caution de stabilité dont le marché à besoin, elle introduit également des nouveautés très attendues, surtout face à des outils comme Dreamweaver qui se sont empâtés avec le temps. Cette vidéo de Brackets (utilisé pour Edge Code) illustre bien cette volonté de réinventer les outils de développement HTML :

L’outil qui suscite le plus d’interrogations est incontestablement Edge Reflow qui est proposé pour le moment en Sneak Peek. Une Preview Realease devrait être proposée d’ici à la fin de l’année.

Ce lancement est donc une bonne nouvelle pour l’industrie, car c’est un message fort envoyé aux éditeurs de sites et annonceurs encore indécis et/ou perplexes face à ce débat d’expert au sujet de ce qu’est et doit devenir HTML. Le progrès est en marche, et je ne peux m’empêcher de rejoindre le “camp” du WHATWG : à la vitesse où évoluent les usages et terminaux, comment pourrait-on se contenter d’une seule version des spécifications HTML tous les 10 ans (3.665 jours !).

]]> http://www.interfacesriches.fr/2012/10/08/adobe-lance-une-suite-doutils-de-developpement-html5/feed/ 1 Le choix se complique entre application mobile et application HTML5 http://www.interfacesriches.fr/2011/12/09/le-choix-se-complique-entre-application-mobile-et-application-html5/ http://www.interfacesriches.fr/2011/12/09/le-choix-se-complique-entre-application-mobile-et-application-html5/#comments Fri, 09 Dec 2011 20:19:42 +0000 Frédéric Cavazza http://www.interfacesriches.fr/?p=1231 Le débat entre applications mobiles (natives) et application en ligne HTML5 est semble-t-il sans fin. J’en parlais déjà il y a 1 an 1/2 (Vous êtes plutôt application mobile ou site web optimisé pour les smartphones ?) et même plus récemment, car mes convictions penchaient en faveur de l’universalité (HTML5 s’impose petit à petit comme LA référence pour les applications mobiles). Oui mais voilà, le marché évolue et le dossier se complexifie avec de nouveaux facteurs à prendre en compte :

Bref, ça se complique, car les deux “clans” ont de solides arguments. Idéalement il faudrait pouvoir tout faire (comme la SCNF) avec des applications natives pour toutes les plateformes mobiles (iOS, Android, Blackberry, Windows Phone, Symbian, Bada) et un site mobile. Le problème c’est que cela représente un gros investissement et que les compétences sont dures à trouver. Nous sommes donc revenu au pont mort : HTML5 will kill mobile apps. No, it won’t.

Vous pourriez me dire que la solution réside peut-être dans les approches hybrides :

Nous voilà donc à nouveau au point de départ… Pour vous aider dans votre réflexion, j’ai réalisé un rapide benchmark de ce qui se fait de mieux entre applications HTML5 et applications natives.

Commençons avec la crème des applications HTML5 “sociales” comme celles proposées par Twitter ou LinkedIn :

Gmail et LinkedIn sur le navigateur de votre smartphone grâce à HTML5

Ces applications HTML5 sont rapides à charger, réactives et parfaitement adaptées à un usage centré sur la consommation de contenus en ligne. De même pour des applications de productivité comme Gmail ou Basecamp :

Gmail et Basecamp dans le navigateur de votre smartphone grâce à HTML5

Là encore, les versions HTML5 sont parfaitement adaptées, car il est avant tout question d’interactions autour de contenus “frais” et de collaboration. Le seul point noir que je puisse émettre est celui de l’authentification qui reste laborieuse (la saisie des identifiants / mots de passe est très pénible).

Du côté des applications natives, il faut bien reconnaitre qu’elles offrent un confort d’usage inégalé, comme le tout récent Flipboard :

L'application Flipboard pour iPhone

De même pour la dernière version de Path qui propose une interface de toute beauté, réellement différenciante :

La V.2 de Path sur l'iPhone

De même, je ne mentionne pas les jeux qui pour le moment sont quasi exclusivement développés en tant qu’applications natives, malgré l’enthousiasme de la profession pour une alternative (les mauvaises langues disent qu’il y a plus de conférences sur les jeux en HTML5 que de jeux en HTML5 !).

Comme précisé en début d’article, je n’ai plus de certitudes, si ce n’est qu’il n’existe pas de solution miracle : pour avoir une présence mobile performante, il faut investir (budget, ressources, énergie…) et se donner les moyens de réussir, car les utilisateurs ne se contenteront pas de compromis.

Ceci étant dit, je me dois d’élargir le débat et de préciser que de toute façon, le réel enjeu n’est pas de conquérir l’audience des utilisateurs en situation de mobilité, mais d’assurer une transition vers l’ère post-PC (Quel va être l’impact de la fin de l’ordinateur individuel ?). Ceci nécessite forcément une approche plus ambitieuse où vous allez être amené à repenser entièrement la diffusion de vos contenus et services. Un vaste chantier, mais ce n’est pas comme si vous aviez le choix.

]]> http://www.interfacesriches.fr/2011/12/09/le-choix-se-complique-entre-application-mobile-et-application-html5/feed/ 18