Le NY Times innove avec Snow Fall, mais illustre les limites de la narration multimédia

Je vous parlais en début de mois dernier des bienfaits du multimédia pour mieux accrocher l’attention des lecteurs (Dopez votre narration interactive avec HTML5). Les esprits se rencontrent, car le NY Times publiait la semaine suivante un superbe article multimédia racontant les mésaventures d’un groupe de skieurs pris dans une avalanche : Snow Fall, The Avalanche at Tunnel Creek.

La première page de Snow Fall

Oui je sais, “article multimédia” fait résonner en vous les bons vieux CD-Rom des années 90. Même si le terme est un peu désuet (euphémisme), il reste néanmoins parfaitement valide pour décrire l’objet éditorial publié par le journal : un mélange de textes, images, vidéos et animations interactives. Le résultat final est un modèle d’élégance et de storytelling, il a d’ailleurs remporté un franc succès : More than 3.5 Million Page Views for New Yorl Times’ ‘Snow Fall’ Feature.

Ce sont ainsi près de 3 millions de visiteurs qui sont venus s’immerger dans ce récit passionnant et dans les nombreuses vidéos et infographies :

Exemple d’infographie dans Snow Fall

Le succès remporté par cet article soulève néanmoins de nombreux questionnements au sein de la profession. Si certains journalistes sont très enthousiastes (What the New York Times’s ‘Snow Fall’ Means to Online Journalism’s Future), d’autres sont plus mitigés (The good — and the bad — about the NYT’s Snow Fall feature et Avec “Snow Fall”, le New York Times cristallise les défis de la presse en ligne). Sont en cause dans cette histoire les coûts de production (visiblement très élevés) et les leviers de monétisation (de vulgaires bannières insérées à l’arrache dans l’article qui défigurent la mise ne page).

Melange de vidéo et d’animation dans Snow Fall

Je ne suis pas un expert de la production multimédia, loin de là, mais je constate que les outils à disposition pour produire et distribuer ce type d’article enrichi (notamment HTML5) permettent de limiter les investissements. La grande question est ensuite de savoir si vous vous positionnez comme un média qui produit de l’information brute (de l’information chaude au format texte) ou une expérience de lecture différenciante (des contenus tièdes ou froids avec une mise en page valorisante).

Améliorez la performance de vos interfaces mobiles avec RESS

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 :

  • Un site unique en responsive design (qui n’utilise pas la détection, mais qui ne règle pas le problème de performances) ;
  • Un site en RESS (bien optimisé, mais qui repose la détection) ;
  • Une version mobile du site (très bien optimisé, mais qui repose également sur la détection).

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.