Il y a quelque temps, je vous parlais de ces sites où le haut et le pied de page vous suivent. Si je croise de plus en plus de pieds de page flottants, par exemple sur le site de American Eagle, les header flottants sont beaucoup plus rares à trouver. Pourtant l’idée est bonne, car cela permet de conserver le contexte quand l’utilisateur descend vers le bas de la page. Cette technique est particulièrement intéressante si le site affiche de pages très longues : lorsque l’internaute arrive en bas de page, il a été exposé à tellement d’unités d’information différentes qu’il a oublié le sujet principal de la page, c’est ce que j’appelle le “contexte”.

Premier exemple avec l’édition suisse de 20Minutes où une version miniaturisée du menu de navigation vient s’ancrer en haut de page dès que vous avez descendu l’équivalent de deux écrans :

Ce menu intègre également un moteur de recherche, un bouton de retour en haut de page, ainsi qu’un bouton pour le faire disparaitre. Si ce header flottant est parfaitement bien exécuté sur le plan technique, je me demande s’il apporte vraiment quelque chose d’un point de vue purement ergonomique, à savoir s’il permet de resituer le contexte. Idéalement, le titre de l’article devrait être rappelé dans ce header flottant.

Deuxième exemple avec Tripadvisor où un header flottant est affiché sur les pages des hôtels pour vérifier la disponibilité :

Le fait de n’afficher que le moteur de réservation est ici bien plus intéressant, car il correspond à la façon dont les internautes utilisent le site : ils sélectionnent un hôtel en fonction de son score, regardent quelques photos et vont parcourir les avis avant de prendre leur décision et de passer à l’acte. C’est pour faciliter cette dernière étape et transformer les clients au moment où ils prennent leur décision (juste après avoir lu quelques avis) que ce header flottant prend tout son intérêt. Idéalement, j’y aurais ajouté un bouton pour revenir en haut de page ainsi que pour lancer une nouvelle recherche.

Voici donc deux exemples particulièrement instructifs, car ils illustrent bien l’intérêt des headers flottants, surtout lorsqu’ils respectent les modalités d’utilisation. Bon par contre, l’utilisation combinée d’un header ET d’un footer flottant réduit la surface d’affichage, ce qui ne pose pas de problème sur un ordinateur de bureau, mais peut être très pénalisant sur une tablette. Sauf en mode portrait, mais cela fera sûrement l’objet d’un prochain article…

En ce moment, je lis énormément de choses sur la “révolution du HTML5″ et la façon dont le HTML4 est supplanté par cette nouvelle itération pensée pour les applications en ligne. Je ne sais pas trop d’où sort cet adage que l’HTML5 est LE langage des applications en ligne, toujours est-il que je ressens comme une ambigüité persistante à ce niveau.

Pour schématiser, un site est un ensemble de pages qui forme un tout cohérent (comme un magazine). Une application est un outil offrant de fonctionnalités. Selon cette définition, dire que HTML5 est le langage des applications en ligne et qu’à l’avenir tout sera application est un non-sens.  Je vois plutôt HTML comme un langage versatile permettant de faire tout un tas de choses, plutôt que de réduire ça à la notion d’application. Pour mémoire, le W3C a essayé pendant des années d’imposer XHTML2 et de faire accepter l’idée que toutes les pages sont des applications, nous savons tous comment cela s’est terminé. Pour être certain qu’il n’y ai pas d’ambigüité, je précise que HTML5 n’est pas remplaçant de XHTML2.

Mais revenons à nos moutons : les applications en ligne sont donc des outils offrant des fonctionnalités aux internautes. Dans la cadre d’une application de gestion de projet ou d’édition de document, tout est limpide. Mais si cette fameuse fonctionnalité est d’afficher du contenu, tout se complique. Pourquoi donc un éditeur de sites voudrait utiliser une application pour afficher du contenu ? Tout simplement pour améliorer l’expérience utilisateur. Deux des sites les plus populaires au monde sont ainsi des applications en ligne permettant d’accéder à des contenus : Facebook et Twitter.

En fait, tout a commencé avec Gmail qui a été le premier site avec une très large audience à utiliser Ajax pour faire des rafraichissements silencieux des pages. Cette technologie n’est plus toute jeune (elle existait déjà au siècle dernier), mais très peu de sites l’utilisent dans le cadre de contenus textuels. Cette réflexion est initialement venue d’une discussion très intéressante que j’ai eue avec Alexandre Malsch, le fondateur de Melty.fr. Pour celles et ceux qui ne connaissent pas, il s’agit d’un des portails les plus populaires auprès des jeunes.

Si vous visiter Melty.fr, vous aurez une expérience de visite assez similaire à n’importe quel portail, pourtant  lorsque que vous arriverez sur le site pour la première fois, c’est le moteur d’affichage qui sera téléchargé en premier, car c’est lui qui gère l’affichage des contenus ainsi que les interactions. Ce moteur, développé en javascript, se positionne ainsi entre le navigateur et l’utilisateur et va intercepter les clics et défilements de la souris pour les interpréter à sa façon et proposer une navigation avec des rafraichissements silencieux qui évitent de recharger à chaque clic des éléments qui ne changent pas.

Les bénéfices de ce moteur d’affichage sont les suivants :

• des temps de chargement plus courts ;
• plus de faciliter dans les fonctions de partage ;
• un meilleur contrôle de l’expérience de lecture ;
• une analyse beaucoup plus fine des parcours et interactions des utilisateurs.

Dans l’absolu, maintenant qu’ils disposent d’une application de lecture pour les ordinateurs, ils peuvent proposer une expérience de lecture très cohérente sur les autres terminaux en proposant des moteurs optimisés pour les tablettes, les smartphones, les TV connectées… Une hypothèse tout à fait intéressante au vu du phénomène de fragmentation des terminaux mobiles, et surtout une réponse tout à fait viable aux problèmes de connexion et de stockage des contenus hors-ligne.

Les premiers utilisateurs de PDAs seraient alors tentés de me faire remarquer que ce n’est ni plus ni moins qu’une reformulation des lecteurs de news du siècle dernier comme AvantGo. Certes, il y a un peu de ça, mais je préfère plutôt saluer la volonté des équipes de Melty de proposer une expérience de lecture maitrisée de bout en bout sans avoir à se reposer sur des applications comme Instapaper ou Pocket.

Je vous rassure : moi aussi j’ai été très perturbé à l’idée d’utiliser un moteur d’affichage pour remplacer celui du navigateur, car c’est toute ça raison d’être ! Toujours est-il que ce site apporte des solutions là où d’autres sont dans une impasse (expérience de lecture maitrisée quel que soit le terminal, gestion des contenus hors ligne, analyse détaillée…). Je serais bien incapable de vous dire si au final cette solution est mieux que de se reposer sur le moteur de rendu natif des navigateurs, car “mieux” est une notion subjective. La discussion reste donc entièrement ouverte…