Quels choix de navigation en responsive design ?

Quels choix de navigation en responsive design ?

Faire le bon choix dans la navigation sur un site est primordial et depuis l’arrivée du responsive design, les choses se compliquent. Il faut garder un accès à l’information sans pour autant gâcher l’expérience utilisateur. Heureusement, Brad Frost a rédigé un excellent article sur son blog à ce sujet que je retranscris ici en français.

 

Si d’emblée, le terme de responsive design vous est étranger, je vous recommande de lire cet article paru il y a quelques temps sur le blog : Responsive design : définition, fonctionnement, ressources et tutoriels

Cet article (tout ce qui va suivre) est une traduction de l’article « Responsive Navigation Patterns » rédigé par Brad Frost, consultant et intégrateur pour mobiles, rédigé avec son approbation, et même avec ses encouragements. Je vous conseille chaudement de suivre son blog qui est une mine d’or pour le design sur mobiles. Merci pour le partage Brad ! 😉

 

Introduction

 

Les navigations en haut et à gauche sont communes sur écrans large mais le manque d’espace sur les petits écrans devient un challenge. Comme le responsive design devient de plus en plus populaire, c’est l’occasion de regarder comment gérer la navigation sur les écrans de petite taille. La navigation sur mobiles doit trouver un équilibre entre accès rapide à l’information et discrétion.

Voici quelques unes des techniques les plus populaires pour gérer la navigation en responsive design :

 

Il y a bien entendu des avantages et des inconvénients à chaque méthode et certains points qu’il faut prendre en compte lorsque vous choisissez laquelle est la meilleure pour votre projet.

 

 

L’approche du menu en haut ou « ne rien faire »

Responsive design navigation menu

L’une des solutions les plus faciles à mettre en place est de simplement garder la navigation en haut. A cause de sa facilité d’implémentation, on la trouve sur beaucoup (peut-être même la majorité) des sites responsives en ce moment.

Pour

  • Facile à mettre en place – vous pouvez implémenter votre site depuis écrans larges quasiment tel quel.
  • Pas de dépendance à Javascript – assure un maximum de compatibilité
  • Pas de dégradation de CSS à mettre en place
  • Pas besoin de changer l’ordre du code source – pas besoin de se prendre la tête pour déplacer le menu de navigation dans le code source. Il se place naturellement en suivant le flux du squelette HTML.

 

Contre

  • Problèmes de hauteur La hauteur compte sur mobile. Comme le livre de Luke l’explique, le concept de « contenu d’abord et navigation ensuite » est privilégié pour les expériences web sur mobiles. Vous voulez que les utilisateurs accèdent au cœur de l’information le plus vite possible. Cela signifie retirer du chemin de l’utilisateur la navigation afin qu’ils se concentrent sur l’information centrale de la page. Ça peut aussi être confusant lorsque tout le cœur du contenu n’est pas visible :
    Responsive design navigation menu
  • Pas extensible – Que se passe-t-il lorsque vous voulez ajouter une section sur votre site ? Alors que maintenant la navigation rentre parfaitement sur une seule ligne, que se passera-t-il si le client vous demande d’ajouter « produits et services » au menu ? Ou si vous avez besoin de traduire le menu en Allemand ?
  • Gros doigts – Trop rapprocher des liens peut aisément donner lieu à des clics de proximité non voulus
  • Problèmes de compatibilité –Pendant que le texte s’affiche parfaitement sur un iPhone, d’autres appareils peuvent donner des rendus de typographies différents. Les sites peuvent être bien sur iPhone et se casser lorsqu’ils sont visionnés depuis d’autres plateformes :

Responsive design navigation menu

Menus de navigation responsive qui passent involontairement sur plusieurs lignes sur de petits écrans

 

Démonstrations

Ressources

 

 

L’ancre vers le footer

Responsive design navigation menu

Cette solution astucieuse garde le menu de navigation dans le footer du site, tandis que le header ne contient qu’un simple lien (une ancre) qui pointe vers le menu du footer. Cette approche libère de l’espace pour le contenu important tout en apportant toujours un accès rapide vers la navigation.

Pour

  • Facile à mettre en place – Une simple ancre placée en haut. Le menu de navigation en bas. C’est carrément simple.
  • Pas de dépendance à Javascript – assure un maximum de compatibilité
  • Peu de CSS nécessaire pour replacer le menu sur grande résolution – Grâce au positionnement « absolute » ou « fixed », déplacer le menu du footer vers le haut pour les écrans large est du gâteau.
  • Un seul bouton dans le header – Une simple icône de menu ou un lien prend très peu d’espace dans le header, ce qui libère beaucoup de place pour le reste du contenu.

Contre

  • Le saut de l’ancre peut désorienter ou gêner – Sauter rapidement vers le footer peut désorienter l’utilisateur.
  • Pas très élégant– Cela peut sembler étrange, mais d’autres méthodes comme la  méthode « toggle » sont un peu plus sexy. Un saut brusque, bien qu’incroyablement pratique, n’est pas l’interaction élégante auxquelles les utilisateurs de mobiles sont habitués en utilisant leurs applications natives.

Démonstrations

Ressources

 

 

 

Le menu en liste déroulante <select>

Responsive design navigation menu

Une manière d’apprivoiser les liens fous est de transformer la liste de liens en liste déroulante avec l’élément HTML <select> pour les petits écrans. Cela évite les problèmes que présente le menu en haut (approche du menu en haut) et c’est une façon intelligente de conserver de l’espace.

Pour

  • Libère beaucoup d’espace – un menu en <select> prend significativement moins de place qu’un menu horizontal ou une liste de liens verticale.
  • Garde les interactions dans le header – au lieu d’une navigation dans le footer, le menu déroulant garde les fonctionnalités de navigation dans le header, où les utilisateurs ont l’habitude de la trouver.
  • Facilement reconnaissable – un menu en <select> avec un intitulé clair comme « navigation » ou « menu » est très reconnaissable pour les utilisateurs.
  • Utilise les  fonctionnalités natives – chaque navigateur mobile va interpréter le menu <select> à sa façon. Les terminaux tactiles vont transformer la navigation en une liste optimisée pour le tactile tandis que les appareils avec trackballs/d-pad/pearl vont favoriser un menu select plus adapté à leur méthode d’entrée particulière.

Contre

  • Manque de personnalisation – Les menus <select> sont une horreur à styliser. Chaque navigateur les interprète à sa façon, souvent bancale. Oubliez la personnalisation graphique identique sur chaque navigateur et ressemblant à peu près à quelque chose. Le résultat risque même de gâcher un design qui était à la base regardable.
  • Peut être confusant – Les utilisateurs sont habitués à croiser des menus <select> dans le cadre de formulaire, mais je ne suis pas sûr qu’ils l’utiliseraient dans un autre contexte. Ce n’est qu’une intuition, il serait intéressant de tester.
  • Gérer différents niveaux de navigation – Des listes imbriquées dans un menu déroulant <select> peuvent être bizarre. Les catégories enfants sont en général traitées par indentation avec des tirets, et bien que cela puisse faire passer le message, je trouve cela potentiellement confusant et un peu moche.
  • Dépendance à Javascript – Cela ne requiert pas beaucoup de Javascript de transformer la liste en menu <select>, mais ça vaut toujours la peine de le faire remarquer car les navigateurs mobiles aiment compliquer les choses. Mais encore une fois, la technique est vraiment simple donc il ne devrait pas y avoir d’imprévu en utilisant cette méthode.

Ressources

Démonstrations

 

 

Le « Toggle » (déploiement)

Responsive design navigation menu

Le déploiement est similaire à l’approche de l’ancre du footer, mais au lieu de descendre jusqu’à une ancre au bas de la page, le menu se déploie (en animation) dans le header. C’est une approche esthétique et relativement simple à implémenter.

Pour

  • Garde l’utilisateur là où il se trouve – Contrairement au saut rapide vers l’ancre du footer, le menu en déploiement apparaît simplement à sa place, ce qui ne désoriente pas l’utilisateur.
  • Elégant– C’est définitivement une des approche les plus classes. Pas de formulaire ou de saut de page gênant, juste une animation déroulante fluide ou un basique affiché/caché.
  • Facile à adapter sur grandes résolutions – Tout ce que vous avez besoin de faire est de cacher le bouton déclencheur et d’afficher le menu lorsque la limite de largeur est atteinte et vous obtenez un menu de navigation normal sur écrans larges. Tout cela peut être fait avec du CSS.

Contre

  • Performance d’animation – Votre expérience variera lorsque vous réaliserez des animations pour terminaux mobiles. Android est particulièrement mauvais avec les animations CSS et les choses risquent de ne pas être aussi fluides que ce que vous espérez.  Aussi pour ce que ça vaut, j’ai récemment animé « max-height« qui semblait marcher plutôt bien.
  • Dépendance à Javascript – Cette approche repose sur un peu de Javascript pour déclencher le déploiement, mais il y en a très peu. J’ai testé un Blackberry qui refusait d’écouter ce type d’évènement, mais la plupart des navigateurs, y compris les navigateurs proxy comme Opera Mini et Dolphin Mini, s’en chargent très bien.

Démonstrations

Ressources

 

 

 

Le menu déroulant par la gauche

Responsive design navigation menu

Facebook a popularisé une navigation pour mobiles qui est plutôt unique. On accède au menu par une icône le représentant, qui révèle un bloc qui glisse de la gauche et déplace le contenu principal vers la droite.

Pour

  • Plein de place – Tandis que d’autres techniques de navigation ne marchent pas très bien si vous avez une liste avec beaucoup de liens, cette approche offre énormément de place disponible. Je pense que c’est pour quoi Facebook l’a choisi.
  • Beau – Ce menu est très sophistiqué et avancé, donc il a un effet « wow ».
  • Convention de Facebook – Les utilisateurs mobiles de Facebook sont habitués à cette méthode de navigation depuis que l’application et la page web mobile de Facebook utilisent ce système de « tiroir » par la gauche.

Contre

  • Avancé – Alors que les autres méthodes modifient des éléments simples, celle-ci demande de lourdes modifications. Comme Stephanie Rieger le signale, la navigation sur le site d’Obama est cassée partout sauf sur les appareils mobiles les plus récents. Si votre projet cible une audience large, il faut faire très attention avec cette méthode.
  • Se redimensionne mal – Cette méthode est plutôt réservée uniquement aux mobiles et ne s’adaptera pas facilement sur écrans large. Vous pouvez prendre le risque de garder 2 navigations séparées pour les petits et grands écrans.
  • Peut être confusant – Lorsque j’ai vu la navigation de Facebook pour la première fois, j’ai pensé que c’était cassé. Garder une petite portion du contenu sur la droite me semble un peu étrange, mais c’est une préférence tout à fait personnelle.

Démonstration

Ressource

 

 

 

Responsive design navigation menu

La navigation uniquement dans le footer est similaire à la technique de l’ancre vers le footer, excepté qu’il n’y a pas d’ancre dans le header. Cela suit le modèle « contenu d’abord, navigation ensuite », en revanche il oblige les utilisateurs à scroller systématiquement jusqu’au bas de page pour naviguer sur le site.

Pour

  • Libère de l’espace dans le header – Cela suit le modèle « contenu d’abord, navigation ensuite », mais…

Contre

  • Difficile à découvrir – Les utilisateurs (autant sur petits que sur grands écrans) risquent de ne pas découvrir qu’il y a un menu posé dans le footer.
  • Difficile d’y accéder – Les internautes sur mobiles doivent scroller toute la page (ce qui peut être très long) juste pour se déplacer dans le site.

Démonstrations

 

 

Le « Cache et pleure »

Responsive design navigation menu

Suivez cette règle : Ne pénalisez pas les utilisateurs qui visitent votre site sur de petits appareils. C’est un mythe (PDF) que les visiteurs sur mobiles ne veulent pas ou n’ont pas besoin de certaines informations. Ils font tout ce qu’un utilisateur sur ordinateur ferait, mais présenté d’une façon adaptée.

Pour

  • Libère plein de place – En supprimant la navigation pour les petits écrans, vous libérez énormément de place ! Mais cela a un prix…

Contre

  • Supprime du contenu et des fonctionnalités pour les utilisateurs de mobiles – Cacher des liens et du contenu c’est mal. Les avocats du responsive design disent qu’il supprime la plupart des disparités de contenu et les cauchemars de l’expérience utilisateur qui peuvent provenir de différents sites mobiles, mais si un site responsive cache du contenu pour les utilisateurs mobiles, il n’y a pas d’amélioration.
  • Augmente inutilement le poids de la page – Ajouter display:none sur des éléments n’étant vraisemblablement pas nécessaires sur mobiles ne les fait pas disparaître. Le code/images/autre est toujours téléchargé par les appareils mobiles (qui bien sûr ont de grandes chances d’utiliser des connections lentes).
  • Plus dur à entretenir – Deux navigations distinctes pour petits et grands écrans deviennet vite une plaie pour la mise à jour du site.

Démonstrations

Ressources

 

 

Considérations

Finalement, la navigation sur mobile devrait être comme un bon ami : là lorsque vous en avez besoin, mais suffisamment cool pour vous laisser de l’espace. Un mauvais ami est une personne qui n’est pas là lorsque vous avez besoin de parler à quelqu’un (quand la navigation est absente ou dure à trouver), ou quelqu’un qui vous asphyxie car il est toujours autour de vous et prend de la place (mec, dégage de mon canap’). Trouver l’équilibre entre une navigation accessible et de l’espace sur un écran de mobile est un art que nous essayons tous de maîtriser. J’adorerais entendre vos avis.

 

Mise à jour

Peu de temps après avoir écrit cet article, il semble que d’autres articles intéressants discutent de la navigation responsive. Lisez :

  • A Responsive Design Approach for Navigation, Part 1 par @filamentgroup : Absolument superbe guide pas-à-pas pour implémenter l’approche « toggle »
  • Pull Down for Navigation par @inspectelement, une approche intelligente qui révèle la navigation lorsque l’utilisateur tire sur le haut de la page. Rapidement les pour et les contre :

    Pour

    • Super sexy
    • Très bon emploi de l’espace de l’écran
    • Prend avantage d’une convention déjà existante sur smartphone qui est de descendre le haut de la page pour révéler plus.

    Contre

    • Potentiellement confusant – Les utilisateurs de mobile sont habitués à tirer le haut de la page pour rafraichir une liste de contenu, pas pour afficher un menu.
    • Relativement avancé – Pour l’instant la démo ne marche entièrement que sur iOS. J’ai vérifié sur Chrome pour Android, le navigateur par défaut d’Android & Opera Mini et cela a marché à peu près partout, mais pas totalement. Je suis sûr que cette solution pourrait petit à petit s’adapter sur tous les navigateurs.
    • Instructions explicites nécessaires – Vous devez expliquer à votre utilisateur de tirer vers le bas pour révéler le menu, ce qui est bien mais peut être dérangeant dans votre header.

    Après tout, ce ne sont que des points mineurs, j’adorerais voir cela fonctionner sur plus de navigateurs !

 

 

Je rappelle que cet article est une traduction de « Responsive Navigation Patterns » rédigé par Brad Frost, consultant et intégrateur pour mobiles, rédigé avec son approbation. Je vous conseille chaudement de suivre son blog qui est une mine d’or pour le design sur mobiles. Je remercie encore Brad Frost pour son accord de traduction de cet article et pour tout ce qu’il partage sur son blog de grande qualité.

Auteur: Gaétan Weltzer, comme toujours en fait.

Articles qui pourraient vous plaire

Commentaires (16)

  1. Très intéressant… Je suis tout à fait d’accord sur le fait qu’il est mieux d’éviter le javascript pour être compatible sur un maximum de navigateurs.

    Un autre exemple : mettre la navigation à droite de la page en grand écran et la passer sous le contenu en mode mobile avec les media querries comme sur Sitadapt.

    Nous trouverons d’autres solutions dans le future puisque le responsive design est une excellente source d’inspiration qui nous invite à concevoir des compromis entre l’expérience utilisateur mobile et celle du deskop.

  2. Merci pour ton commentaire Nicolas, finalement Sitadapt se rapproche fortement de la méthode de navigation dans le footer sans ancre comme décrite au-dessus avec ses avantages et ses inconvénients.

    Et je suis bien d’accord quant aux prochaines innovations que le responsive design nous réserve. C’est à suivre de près !

  3. Oui, cela s’en rapproche. Mais, c’est mieux en grand écran puisque la navigation reste classiquement en haut. On peux même mettre le menu à gauche, si on le souhaite, avec la même technique.
    A suivre…

  4. Merci pour la traduction, mais il y a un point qui m’échappe : en quoi une dépendance de javascript réduit la compatibilité ? js est un langage basé sur un standard (tout comme l’est HTML) qui est l’ECMA script. De ce fait, tout les navigateurs savent interpréter javascript. Je ne comprend donc pas pourquoi il faudrait éviter une solution à base de javascript ?

    Merci du boulot en tout cas, c’est cool de lire ce genre d’article

  5. Merci pour ton intervention Nicolas. Je ne sais pas si beaucoup de gens désactivent le Javascript, surtout sur smartphones, mais c’est une cause possible. La principale raison selon moi, et je peux demander directement l’avis de Brad Frost si vous voulez, est que le Javascript est loin de réagir partout de la même manière. Cela est dit explicitement dans l’article, certains appareils interprètent le Javascript totalement différemment de son voisin.
    Tout comme l’HTML et le CSS sont des standards et que nous nous battons pourtant aujourd’hui encore avec Internet Explorer à cause de ça, le Javascript est encore difficile à implémenter partout pour de lourdes fonctionnalités, comme pour la toute dernière présentée dans l’article (la technique du tirer-lâcher le haut de la page). Cela demande énormément de tests, sur beaucoup d’appareils différents, et bien souvent il faut tenter de débuguer un à un, ou du moins de limiter les dégâts. Heureusement l’arrivée de jQuery Mobile par exemple fait grandement avancer les choses mais pour le moment les différences d’un navigateur à l’autre sont encore très présentes.
    Voilà pourquoi le Javascript est un risque de casse-tête supplémentaire !

  6. Merci pour la traduction de l’article de Brad, très intéressant.

    Néanmoins, si le responsive design est une approche pertinente et utile pour des sites de « présentation de contenu », il est beaucoup plus difficile à mettre en oeuvre pour des sites applicatifs ou à l’architecture de l’information riche et profonde…

    Par ailleurs, compte tenu des résolutions écran des smartphones qui ne cessent d’augmenter, la détection via mediaqueries devient un peu compliquée et oblige à regarder également la densité de pixels…

    Bref, pour des sites un poil riches, j’ai plutôt tendance à préconiser de la jouer à l’ancienne (cad un template spécifique pour les mobiles) dont le rapport temps / coût / maintenabilité / performances / expérience utilisateur est bien meilleur.

    L’idéal étant d’adjoindre à ce template mobile une version webApp embarquant des fonctionnalités avancées (gestuelles tactiles, mise en cache, …) proposée uniquement si le navigateur le supporte.

    J’ai d’ailleurs développé la question dans un billet cette semaine => http://haikusages.fr/2012/04/02/design-web-mobile-quelques-pistes-de-reflexion-issues-de-mon-experience-freelance/

  7. L’article est intéressant. Juste une petite remarque; le mot « confusant » n’existe pas. Pourquoi ne pas le remplacer par l’expression « prête à confusion » ou bien par les mots « déroutant » ou « déconcertant »

  8. @Fabien Grenet : Je suis bien d’accord quant au choix du responsive design, quelque fois partir sur une version spécifique sur mobiles est plus justifiée, comme je l’évoque dans cet article, seulement ce n’est pas l’objectif de celui-ci. La question est en effet bien traitée dans ton article.

  9. J’ai trouvé une astuce en CSS3 (sans Javascript) pour que le menu soit :
    – en haut sur grand écran
    – à droite (ou à gauche) sur écran moyen
    – en bas sur petit écran (avec apparition de l’ancre vers le footer)

    A tester sur Sitadapt !
    De plus, le menu est animé en CSS3…

Laisser un commentaire

L’âme d’un artiste ? Inscris-toi sur DigitalPainting.school

Fermer