Pourquoi les sites Web basculent-ils la visibilité des en-têtes sur le défilement?
Certains sites Web ont un en-tête (généralement assez petit) qui se cache lorsque l'utilisateur fait défiler vers le bas.
Ce que je n'ai jamais compris, c'est pourquoi il s'affiche à nouveau lors du défilement vers le haut. Parfois, je veux faire défiler un peu pour lire le contenu un peu plus haut sur la page et cela devient vraiment ennuyeux. Ici est un exemple.
Pourquoi est-ce fait? Qu'est-ce que les concepteurs de sites Web essaient d'accomplir en implémentant cela? Cela semble vraiment ennuyeux.
Pourquoi le menu de navigation est-il visible lorsque vous faites défiler vers le haut?
Dans les sites et pages axés sur le contenu, les utilisateurs s'attendent à faire défiler vers le bas s'il y a un engagement. Si l'utilisateur ne fait pas défiler vers le bas mais vers le haut, il peut être accepté comme "utilisateur non engagé". Offrir d'autres options d'engagement est l'objectif principal de ce comportement.
Le même modèle peut également être vu dans l'application de safari mobile. Lorsque l'utilisateur fait défiler vers le haut, les autres fonctionnalités deviennent visibles. Si l'utilisateur fait défiler vers le bas, les éléments deviennent un format invisible pour agrandir la zone.
- Ce comportement transforme les éléments en invisibles pour réduire les éléments de distraction en cas d'engagement
- Ce comportement rend les éléments visibles pour augmenter les options lorsqu'il n'y a pas/moins d'engagement
Conception orientée mobile
Cela s'appelle parfois barre de défilement vers le haut et est un produit de conception orientée mobile. C'est un compromis entre avoir une barre de navigation fixe qui est toujours à l'écran et une barre de navigation fluide qui n'est qu'en haut de la page. La barre de navigation fixe a l'inconvénient de prendre une partie importante de l'écran mobile plus petit, tandis que la barre de navigation fluide a l'inconvénient de nécessiter beaucoup de défilement pour atteindre même des pages plutôt courtes.
Sur le bureau, aucun de ces problèmes n'est aussi important. Une barre de navigation fixe occupe une plus petite partie de la fenêtre d'affichage et peut être plus petite en raison de la précision plus élevée du contrôle de la souris. Et cela prend beaucoup moins de temps pour remonter en haut de la page - à la fois parce que la page est plus courte, nécessitant moins de défilement, et parce que l'utilisateur peut rapidement faire défiler vers le haut de la page en utilisant la barre de défilement et en faisant glisser le chevron .
C'est également une alternative au soi-disant "menu hamburger", qui cache les éléments de navigation derrière un bouton sur lequel l'utilisateur est censé appuyer. Masquer les options derrière un bouton les rend moins détectables et entraîne souvent une utilisation moindre des options. (Bien que les gens s'y habituent, c'est mieux qu'avant.)
En affichant les options de navigation en haut de la page, puis en tirant parti d'une action naturelle telle que le défilement vers le haut pour afficher à nouveau les options, les options de navigation sont plus détectables et donc plus utilisées.
Pourquoi seulement en faisant défiler vers le haut?
La barre de navigation est affichée lors du défilement vers le haut pour deux raisons: la première est que l'utilisateur qui fait défiler vers le haut est plus susceptible de ne plus interagir avec la page qu'un seul vers le bas. La seconde est qu'il s'agit d'une action naturelle: l'utilisateur a vu ces options de navigation lorsqu'il a ouvert la page, et va donc naturellement commencer à remonter en haut de la page pour essayer de les atteindre.
Quant à ceux qui font défiler vers le haut pour d'autres raisons, l'idée est que vous n'avez qu'à faire défiler un peu plus, puis recommencerez naturellement à défiler vers le bas pendant que vous continuez à lire, repoussant la barre de navigation hors de la page.
Cependant, comme indiqué dans les commentaires ici, cela agace souvent ces utilisateurs. Ma recommandation pour y remédier est double. Tout d'abord, ne faites pas apparaître la navigation tant que l'utilisateur n'a pas fait défiler plus d'un tout petit peu. Deuxièmement, notez la vitesse à laquelle l'utilisateur défile et réagissez différemment. Un défilement rapide ou un film sur mobile est plus susceptible d'essayer de revenir en haut de la page, tandis qu'un défilement lent est plus susceptible d'ajuster simplement le contenu.
Je recommande également personnellement de ne pas essayer de concevoir un chausse-pied mobile sur le bureau. Il existe des moyens de détecter qu'un utilisateur est sur le bureau (ou n'a pas de commandes tactiles) en plus de vérifier la largeur de la fenêtre d'affichage. Si l'utilisateur est sur le bureau, revenez à une barre de navigation fixe et conservez sa taille raisonnable pour une utilisation avec la souris.
Beaucoup de gens le font parce que d'autres le font et sans autre raison.
Leur prétendue raison pourrait être de donner un maximum d'espace à leur contenu tout en minimisant l'en-tête sur lequel ils ont lu quelque part. Je suis cependant d'accord avec vous. Il est ennuyeux de voir l'en-tête se développer lors du défilement. Cela ne me dérangerait pas s'il attendait que vous arriviez au sommet avant de le faire, sans couvrir le contenu, mais peu le font.
L'intention derrière cette fonctionnalité est de soutenir l'intention supposée de l'utilisateur:
- Si l'utilisateur fait défiler vers le bas, il doit lire le contenu - alors aidez-le en retirant l'en-tête.
- S'ils défilent vers le haut, ils doivent avoir fini de lire et tentent de revenir à la navigation en haut de la page - alors aidez-les en ramenant l'en-tête à la vue.
Voilà l'idéal. Lorsque cela devient un problème, c'est lorsque la tentative de l'interface utilisateur de deviner l'intention de l'utilisateur échoue, et enfonce l'en-tête de la manière lorsque l'utilisateur faisait juste défiler un peu pour relire la ligne précédente.
Souvent, c'est simplement une question de mauvaise mise en œuvre: il est facile de simplement déclencher l'en-tête pour revenir à la vue lors de tout événement de défilement vers le haut. De nombreux sites (y compris l'exemple auquel vous avez lié) font ce strict minimum et l'appellent un jour.
Une beaucoup meilleure implémentation attendrait que l'utilisateur ait fait défiler une distance significative - suffisamment loin pour avoir clairement signalé son intention de se diriger vers le haut de la page - avant de ramener l'en-tête dans vue. (Bien qu'il ne soit pas si long que l'utilisateur atteigne le haut de la page avant le déclenchement!) Ce n'est pas une difficulté de science de fusée, mais elle est beaucoup plus impliquée que la méthode naïve. Et même si cela est tenté, il y a un certain jugement impliqué dans le réglage de la bonne durée, pour des longueurs de contenu spécifiques, etc. Tout cela prend du temps, de l'attention, des tests utilisateur, une bonne communication entre les équipes de conception et de code, etc. tout cela s'ajoute à ce que cela ne se fait pas bien souvent et la méthode inférieure aux os nus est beaucoup plus courante dans la nature.
Eh bien, ils veulent que le menu de navigation soit toujours présent pour que les utilisateurs puissent rapidement parcourir les pages. Les concepteurs visent à augmenter les pages vues et le temps passé sur le site . C'est pourquoi ils ont mis la tête collante.
Cependant, j'ai trouvé 1 test A/B où les résultats n'étaient pas très impressionnants: seulement 11% de pages vues en plus sur les tablettes, les ordinateurs de bureau et les appareils mobiles, il n'y avait pas de gains significatifs.
Dans l'exemple de site Web que vous avez spécifié, les concepteurs l'ont mal fait parce que la barre supérieure est trop grande et cache le contenu principal.
Dans ce cas particulier, la conception présente des défauts pour deux raisons:
C'est trop sensible. Même un pas sur la molette de la souris pousse l'en-tête entier. Comme d'autres l'ont dit, il devrait y avoir un certain seuil/limite de vitesse pour afficher l'en-tête.
L'en-tête est inutilement énorme. Vous savez à quel site vous vous trouvez, le logo est donc complètement superflu. Si l'en-tête n'était que la barre d'une ligne, l'utilisateur obtiendrait tout le contenu nécessaire de l'en-tête.
Avec ces deux points combinés, tout défilement vers le haut entraînerait également le déplacement des fenêtres vers le haut dans toutes les circonstances, répondant ainsi aux deux types de souhaits qui déclenchent un déplacement vers le haut (afficher plus de contenu, afficher l'en-tête).
En fait (si je peux partager mon expérience personnelle), ce qui me distrait vraiment, c'est le "saut" de l'en-tête, plus que le fait qu'il couvre une partie de la page. Cela se produit à la fois en affichant l'en-tête et en le masquant.
Eh bien, je suppose que lorsque vous décidez de masquer la navigation (pour une raison quelconque), vous devez également trouver un moyen de l'afficher à nouveau. Ce concepteur a choisi de masquer la navigation sur plusieurs défilements vers le bas. Et puis je suppose qu'il semblait logique de le montrer à nouveau sur le défilement vers le haut. Mais cela aurait certainement pu être amélioré. Vous souhaitez laisser une sorte de navigation en haut mais la réduire. Et peut-être utiliser le mouvement de la souris pour déclencher à nouveau l'expansion de la navigation. Mais oui, ce n'est pas le moyen idéal de le faire.
Il s'agit de se concentrer sur le contenu, de concevoir UX pour améliorer l'engagement, l'expérience utilisateur.
- Lorsque les utilisateurs défilent vers le bas, il s'agit de lire.
- Lorsque les utilisateurs défilent vers le haut, il ne s'agit pas de lire.
Ce comportement est plus à discuter, certains sites affichent même des options supplémentaires en faisant défiler vers le haut. (Consultez la page de publication dans medium.com)
Actuellement, je travaille sur un projet qui est définitivement conçu de cette façon, nous masquons toute l'interface affichant uniquement le contenu lors de la lecture et affichant des options supplémentaires lors du défilement vers le haut (comme Nav, en-tête, boutons de partage, commentaire, liens sociaux, .. .etc)
Une autre chose que je n'ai vu personne mentionner, c'est que cela me rappelle le schéma contextuel "Oh, attendez avant de quitter" que les sites utilisaient lorsque vous faisiez un mouvement d'écran interprété comme un mouvement de sortie. Cette association est assez négative pour moi, mais je suppose que je m'adapterai ou éviterai simplement ces sites contextuels si possible.