En ce moment la communauté des concepteurs est en ébullition à propos des interfaces mobiles. Nous pensions avoir trouvé une solution à la multiplication des formats d’écran (ordinateur + smartphone + tablette) avec les mises en page en responsive design, mais c’était sans compter l’imagination des constructeurs. Pour éviter la concurrence directe avec l’iPhone et l’iPad, les constructeurs ont commencé à sortir des formats intermédiaires (phablets de 5 pouces, mini-tablettes de 7 pouces…). En conséquence de quoi les concepteurs doivent maintenant jongler avec un éventail très large d’écrans et de terminaux.

Si la question de la mise en page est à peu près réglée avec les techniques de responsive design, cette multiplication des formats est problématique pour les systèmes de navigation (lire à ce sujet : Les tablettes méritent des interfaces dédiées). La façon dont l’utilisateur tient son terminal a un impact sur la facilité d’accéder aux menus de navigation qui ne doivent pas nécessairement se trouver en haut de page, comme c’est de rigueur avec une page web affichée sur un ordinateur. Les smartphones tout comme les tablettes sont ainsi généralement tenus par le bas, les pouces étant alors les seuls doigts disponibles pour manipuler l’interface.

Partant de ce constat, Luke Wroblewsky et Jason Weaver se sont penchés sur le problème et proposent une solution tout à fait convaincante : Responsive Navigation: Optimizing for Touch Across Devices. Leur idée est de proposer un système de navigation adaptatif qui se positionne en bas de l’écran pour les smartphones et qui est même divisé en deux pour les tablettes.

Je vous invite à constater le résultat sur ces pages : Off Canvas with Navigation Fixed Bottom et Off Canvas with Split Navigation Fixed Bottom.

Le résultat est très convaincant et apporte un plus indéniable en confort d’usage, l’auteur donne un peu plus de détails ici : Exploring Touch Navigation.

Signalons que ce n’est pas la première fois que ces deux personnes collaborent, car elles avaient déjà proposé une solution de mise en page adaptative : Off Canvas Multi-Device Layouts et A Multi-Device Web Layout Pattern. Cette technique permet ainsi d’afficher une mise en page et un menu de navigation différents en fonction du terminal :

Vous pourriez me dire que tout ceci est un peu complexe à maintenir, mais je vos répondrait qu’avec des techniques avancées comme RESS vous pouvez vous simplifier la vie : Améliorez la performance de vos interfaces mobiles avec RESS.

Je pense ne pas me tromper en disant que plus nous avançons dans le temps et plus la situation se complique avec la multiplication des formats de terminaux. Heureusement les techniques de développement gagnent en sophistication tous les ans et permettent de contourner ces difficultés. Reste encore à gérer LE gros point faible des ces astuces : les systèmes de gestion de contenu dont les gabarits de page ne facilitent pas la travail d’intégration.

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…

Je ne sais pas pour vous, mais j’ai comme l’impression que les sites à défilement horizontal sont à la mode en ce moment : 40 of the Best Horizontal Scrolling Websites et 38 Websites Using Horizontal Scrolling. Déjà l’année dernière le précurseur Smashing Magazing avait soulevé la question : Will Horizontal Layouts Return?.

Bon, autant le dire tout de suite sans faire durer le suspens : le défilement horizontal est une aberration d’un point de vue ergonomique, mais elle peut s’avérer utile d’un point de vue artistique. Autrement dit : ça peut aider si vous éditez un site expérimental à vocation artistique.

Illustration avec le portfolio du designer suédois Eric Johansson :

Ici le défilement se fait à l’aide d’une… barre de défilement horizontale (vous vous en doutiez) et le rendu graphique est plutôt sympa. Ceci n’est pas gênant dans la mesure où il n’y a que très peu de contenu sur ce site et que l’auteur souhaite se démarquer.

Autre exemple expérimental avec Google Fast Flip :

J’imagine que l’idée était de reproduire la dynamique des lectures des journaux avec un défilement latérale des pages… c’est raté. Je préfère encore largement les applications de catalogues électroniques (avec les pages qui tournent) comme FluidBook.

Autre exemple plus embêtant avec le site de Lomotek Polymers :

Là c’est tout de suite beaucoup plus dommageable parce qu’il y a du contenu et parce que l’encrage de la barre de navigation par dessus le contenu qui défile provoque une drôle de sensation. Bref, rien de tel pour déstabiliser vos lecteurs…

Terminons avec le pire exemple, celui de Gucci :

Là nous sommes dans le grand n’importe quoi avec une navigation très compliquée à manipuler et à repérer (il faut cliquer sur les petites flèches). Non seulement cela perturbe l’internaute mais en plus ça n’apporte rien à l’image de marque ou au positionnement des produits (les marques de luxe doivent-elles se démarquer à ce point ?).

Au final, je ne voit qu’un intérêt artistique à ce système de défilement, et encore. Le meilleur exemple que je puisse vous donner est celui du site MoCo Loco où il est possible de basculer d’un défilement horizontal à vertical et qui propose une navigation par clavier :

J’espère vous avoir convaincu de ne pas utiliser cette technique.

Même si les statistiques prouvent que les internautes utilisent des écrans toujours plus grands, ils ne maximisent pas pour autant la taille de la fenêtre de leur navigateur. Résultat : la largeur de référence pour un site web est (et restera encore pour un certain temps) de 1024 pixels. Mais comme les éditeurs de sites ont de plus en plus de choses à dire / afficher il a bien fallu gagner de la place. D’où le recours aux menus de navigation déroulants (autrement appelés drop-down menu ou fly-out menu).

Je vous propose aujourd’hui de nous intéresser à 3 implémentations différentes de menus de navigation déroulants.

Minimaliste : FlickR

FlickR est un service de partage de photo très simple à utiliser. Simple et minimaliste, à l’image de son système de navigation :

Pas de traitement graphique complexe, ici tout est fait en texte. Une fine bordure est affichée au survol de la souris pour inviter l’utilisateur à s’intéresser à la petite flèche (l’item de navigation ressemblent alors à un onglet). Un clic sur l’intitulé mène à la tête de section alors qu’un clic sur la flèche déroule les items de sous-navigation.

Si l’épuration graphique est en cohérence avec le design du site, force est de constater que la lisibilité laisse à désirer du fait d’un cloisonnement trop faible : on a beaucoup de mal à voir la limite du menu (il manque peut-être une ombre portée).

Maximaliste : American Eagle

À l’opposé de FlickR nous trouvons American Eagle qui propose un menu gigantesque :

Première chose intéressante : le temps de latence. Le menu est déployé (et rangé) au bout d’1/2 seconde, une très bonne chose pour ne pas surprendre les utilisateurs qui laissent traîner leur souris, d’autant plus que le menu est gigantesque et qu’il couvre une bonne partie de la page.

Au niveau du traitement graphique, vous noterez un très bon cloisonnement des différentes sous-rubriques ainsi que des mises en avant (à gauche et en bas). Vous apprécierez également le léger débordement de l’onglet sélectionné. Par contre quel que les liens ne soient pas soulignés au survol de la souris !

Intermédiaire : Threadless

Finissons avec Threadless qui exploite les forces des deux précédents exemples :

Un menu qui est graphiquement très léger tout en apportant un peu de sophistication avec une typo en image. Une interaction très dynamique avec un déroulement immédiat en sans clic. Une très bonne exploitation de l’espace avec des sous-catégories bien cloisonnées et des raccourcis intéressants (cf. les liens “Sales”). Le liseré qui délimite le menu est également un bon dosage entre discrétion et visibilité.

Bref, c’est du très bon travail même si j’aurais tout de même souligné les liens au survol de la souris (je trouve le retour visuel encore trop timide) et si j’aurais ajouté une ombre portée sous le menu pour renforcer l’impression de survol.

Conclusion

Mes conseils pour bien concevoir votre menu de navigation déroulant :

• Ne négligez pas les retours visuels pour attirer l’attention (au survol de l’item de navigation ou des liens dans les menus) ;
• Vous pouvez mettre un grand nombre de liens à condition de bien cloisonner les sous-rubriques ;
• Privilégiez un déroulement automatique du menu plutôt que sur clic de la souris ;
• Le temps de latence est un plus, surtout au niveau de la disparition du menu ;
• N’oubliez pas l’ombre portée pour bien marquer la différence entre menu et “fond de page”.

Si vous avez d’autres (bon) exemples, n’hésitez pas à les publier.

Pour faire suite aux articles de Frédéric “Tout savoir sur les chemins de navigation (breadcrumb)” et “Peut-on se passer des menus de navigation ?” voici une découverte très intéressante que je souhaite partager avec vous.

Il s’agit de l’article 37 Examples of Unique Navigation sur inspiredology.com.

J’ai particulièrement aimé ma visite sur les trois sites suivants :

Jaymeblackmon.com pour les rolovers du menu de navigation

Porsche.com pour les gros menus présentant les modèles de Porsches.

Salinas-rio.com.br pour l’ajout des illustrations dans le menu de navigation

Et vous, quels sont vos préférés ?

J’avais constaté il y a quelque temps la prolifération de menus de navigation au format XL (cf. Est-ce la mode des menus déroulants surdimensionnés ?) mais c’est un article de Jakob Nielsen qui me pousse à aborder à nouveau le sujet : Mega Drop-Down Navigation Menus Work Well.

L’auteur nous explique ainsi que les menus de navigation surdimensionnés peuvent mieux fonctionner qu’un menu traditionnel :

• Ils proposent une meilleur lisibilité avec un espace mieux exploiter et un guidage renforcé à l’aide de séparateurs et de pictos ;
• Ils permettent d’afficher la totalité de l’arborescence d’une section.

Ces menus doivent par contre respecter quelques  règles d’utilisabilité :

• Pas trop de choix à la fois ;
• Un temps de latence d’1/2 seconde à l’ouverture et à la fermeture du panneau ;
• Pas de contrôle trop complexes ;
• Une navigation au clavier pour assurer une meilleure utilisabilité.

Sur ce dernier point je suis ravi de la position adoptée par le Dr Nielsen : même si les menus de navigation surdimensionnés ne sont pas accessibles (ou peuvent difficilement l’être), il suffit d’assurer l’accès au rubrique de premier niveau.

Deux très bon exemples sont cités dans l’article : Food Network (avec une excellente hiérarchisation de l’information) et Action Envelopes (avec une utilisation astucieuse des pictos).

Dans le même esprit mais à l’autre bout de la page, j’avais également abordé il y a deux ans cette pratique élégante qui consistait à mettre le plan du site dans le pied de page (cf. Un plan du site dans votre pied de page). Et c’est un article publié sur Web Designer Wall qui me fait aborder le sujet à nouveau : Modern Sitemap and Footer.

L’auteur liste ainsi les avantages de mettre le plan du site dans le footer :

• Cela permet d’économiser un clic pour les utilisateurs et d’autoriser les sauts de section ;
• Cela donne plus d’espace à la promotion interne (pour mettre en valeur des fonctions ou contenus clés) ;
• Cela réchauffe le pied de page.

Un certain nombre d’exemples sont cités dont celui de Mozilla :

Mention spéciale au “site à Barak” (WhiteHouse.gov) qui cumule à la fois un menu de navigation surdimensionné et un plan du site en pied de page.

Lorsque vous êtes sur un site web et que vous souhaitez revenir sur la page d’accueil, il y a 99% de chances pour que vous cliquiez instinctivement sur le logo en haut à gauche. C’est ce que l’on appelle une convention, c’est comme une hypothèse communément admise.

Oui mais voilà : où est-il expliqué qu’un clic sur le logo permet de revenir sur la page d’accueil ? Dans le meilleur des cas, vous avez un item de navigation intitulé ‘Accueil‘ (éventuellement un chemin de navigation) mais que se passe-t-il pour le 1% d’internautes pour qui cette règle du clic sur le logo n’est pas assimilée ?

Seriez-vous prêt à prendre le risque de perdre ou à mettre en situation de frustration 1% de vos visiteurs ?

Voilà pourquoi certains on décidé que l’affichage du logo avec un lien ne suffisait pas pour faire comprendre aux internautes qu’en cliquant dessus ils pouvaient revenir à la page d’accueil. Ils ont ainsi ajouté un retour visuel au survol de la souris pour faciliter la compréhension de cette règle de navigation tacite.

Exemple avec Amazon US (un filet avec un lien ‘Homepage‘) et Facebook (un picto de maison) :

/!\ Billet initialement publié sur FredCavazza.net.

Question : que faites-vous quand vous avez une arborescence très large, que vous voulez un accès en un clic à vos sous-catégories et que vous ne souhaitez pas gaspiller trop de place avec un menu de navigation à rallonge ? Et bien vous utilisez un menu déroulant surdimensionné.

Démonstration avec le menu “All Product Categories” de Amazon (qui s’affiche au survol de la souris) :

Une solution élégante qui permet à ces nombreuses catégories et sous-catégories de respirer (et à vos yeux de se reposer).

Solution qui a d’ailleurs été reprise par Kelkoo dans sa nouvelle version (il faut cliquer sur la flèche) :

On en trouve aussi sur la page d’accueil de Target :

Et également dans certaines pages du site de Dodge :

Encore plus fort, je vous propose de découvrir cet autre menu (chez RarePlay) qui intègre également l’argumentation (un peu comme une page d’orientation) :

Une solution audacieuse, mais qui manque un peu de lisibilité à mon goût (les liens ne ressortent pas au premier coup d’oeil).

/!\ Article initialement publié sur FredCavazza.net.

Les menus de navigation sont ancrés dans les pratiques du web : ils apparaissent comme quasi-indispensables, notamment pour aider les utilisateurs à s’orienter et à se déplacer au sein d’un site. Par conséquent nous (les internautes) sommes habitués à trouver ces menus en haut des pages. De même, nous (les concepteurs de sites) ne nous posons même plus la question de savoir s’il faut un menu ou non.

Et pourtant… je viens de découvrir un site qui a fait le choix audacieux de substituer un menu de navigation permanent par un chemin de navigation : iLike. Dans les faits, ce site (qui possède une structure et une arborescence tout à fait classique) mise tout sur la navigation contextuelle. Illustration avec cette page dédiée à un album d’Enrique Iglesias :

Hé oui, pas de navigation, juste un “fil d’Ariane” accolé au logo (qui sert de retour à la page d’accueil). Je ne peux que reconnaitre la réussite de ce système de navigation minimaliste qui “fonctionne” parfaitement bien.

En fait les avantages de cette solution sont multiples :

1. cela dégage un maximum de place
2. cela permet de contextualiser les pages et de concentrer l’attention en allégeant la structure
3. cela facilite la compréhension de l’arborescence par les utilisateurs

Bref, une réussite sur toute la ligne. Mais attention, cette solution ne s’applique pas à tous les types de sites. Une arborescence large ou profonde peut par exemple être très problématique à gérer en l’absence de menu de navigation (difficulté à se repérer, problème pour basculer d’une section à une autre…).

Je trouve dans ce site l’illustration parfaite d’une recommandation faite à un client il y a quelques années : supprimer la barre de navigation principale au profit d’une navigation contextuelle (en coeur de page) afin de concentrer l’attention. Dédicace spéciale à Monica et GOB 

En tout cas je vous invite à réfléchir très sérieusement (en vous inspirant de cet exemple) sur l’intérêt réel du menu de navigation de votre site :

• Comment naviguent vos visiteurs : en cliquant sur les liens ou en utilisant le menu ?
• Votre site serait-il toujours utilisable sans la navigation ?
• Quel gain de place cela représenterait-il ?
• Comment pourriez-vous réexploiter l’espace ainsi gagné ?

/!\ Article initialement publié sur FredCavazza.net.