Des problèmes potentiels avec l'utilisation d'un «menu fixe de démonstration automatique»?
Lors d'une récente mise à jour de mon Nexus 4, une nouvelle fonctionnalité est présente dans mon navigateur: lorsque je fais défiler vers le bas, la barre d'adresse disparaît et la page Web est en plein écran, c'est seulement lorsque vous faites défiler que vous obtenez la barre d'adresse et les options retour.
Ceci est également présent sur le site Web de LinkedIn lorsque vous êtes connecté, le fait de faire défiler vers le bas fait disparaître la "barre de navigation", puis de remonter un peu pour la faire réapparaître.
Quels sont les avantages et les inconvénients de l'implémentation d'une fonctionnalité comme celle-ci sur un site Web?
Quelques-uns auxquels je peux penser:
Avantages:
- Plus d'espace pour le contenu
Les inconvénients:
Confondre les utilisateurs
Difficile à mettre en œuvre de manière cohérente sur tous les appareils
En fait, je pense que c'est un modèle plutôt intelligent.
Juste pour clarifier la terminologie (j'utilise Twitter Bootstrap comme référence):
- Menu statique - un menu qui défile avec le reste de la vue (c'est-à-dire, ne sera pas visible après le défilement).
- Menu fixe - un menu qui est constamment affiché, indépendamment du défilement.
- Autoshow Fixed Men - un menu qui se cache lors du défilement vers le bas et se montre lors du défilement vers le haut.
Considérons maintenant le cas d'un menu statique: - Lorsque vous faites défiler vers le bas, il disparaît. - Vous devez faire défiler vers le haut pour l'afficher à nouveau. - Particulièrement ennuyeux avec les appareils mobiles, où le contenu est étroit et long.
En comparaison, le menu fixe du salon automatique évite à l'utilisateur d'avoir à faire défiler vers le haut (ce qui pourrait être quelques gestes de la main). L'hypothèse est que le contenu est lu de haut en bas et qu'une interaction avec le menu est nécessaire après un nombre X de défilement vers le bas.
Comme vous l'avez mentionné, cela permet de voir plus de contenu à l'écran, ce qui est plus important avec les appareils mobiles.
Maintenant, il est difficile de trouver un flux sérieux dans ce comportement, car les utilisateurs sont habitués à faire défiler vers le haut pour voir le menu. De plus, les utilisateurs devraient facilement conclure que si le menu disparaît lors du défilement vers le bas, il s'affichera lors du défilement vers le haut (action opposée).
Mon point est que, quelle que soit la façon dont vous le regardez, l'apprentissage du comportement de ce modèle devrait être facile et instantané.
Ce modèle est bon lorsque le modèle en question implique un contenu long, le défilement étant plus fréquent que l'interaction du menu.
Mon hypothèse est que vous allez voir de plus en plus de cela dans les applications riches en contenu. Un exemple extrême est Pinterest - en tant qu'application centrée sur le contenu, de nombreux contrôles d'interaction sont affichés après une action utilisateur supplémentaire (cliquez, par exemple, pour afficher diverses options d'interaction). Pinterest pour mobile affiche/masque non seulement le menu du haut, mais aussi celui du bas.
Je vous déconseille de comparer cette fonctionnalité dans le navigateur et cette fonctionnalité sur un site Web car les gens utilisent (généralement) le navigateur beaucoup plus que n'importe quel site Web, donc ont tendance à apprendre et à se familiariser avec le nouveau comportement du navigateur plus rapidement qu'ils ne le feraient. comportement dans un site Web. Un autre facteur déroutant est que différents sites Web mettent en œuvre ce comportement de différentes manières. Personnellement, je trouve presque toujours ce comportement gênant (dans les sites Web) - lorsque je fais défiler et que je vois un changement inattendu en haut, il attire mon attention et commence à enquêter, faire défiler vers le haut, faire défiler vers le bas pour essayer de le comprendre, mais que mon être un risque d'occupation de la mine.
Considérez également ce comportement sur un site Web affiché dans un navigateur avec ce comportement - cela pourrait devenir déroutant.
Cette fonctionnalité consistant à faire disparaître la barre d'adresse lorsque vous faites défiler vers le bas est une pratique que j'ai vue pour la première fois dans l'application Pinterest, et récemment dans l'une des dernières mises à jour de Chrome (les deux iOS). Dans le cas d'un appareil mobile, cela a beaucoup de sens car nous avons un espace réduit et cela nettoie l'écran en obtenant une expérience "plein écran" (dans le cas de Pinterest, le dock disparaît également).
Dans les deux cas, l'utilisateur fera défiler pendant un certain temps soit en naviguant sur une page Pinterest ou en lisant des articles dans le navigateur.
Dans le bureau, la pratique est un peu différente car ce n'est pas le navigateur qui change mais la page. De nos jours, il est courant de voir des sites avec un gros en-tête et un gros logo et lorsque vous faites défiler, il passe à la version lite, ce qui est assez pratique et utilise plus d'espace sur l'écran.
Dans le cas de LinkedIn, je suppose que c'est quelque chose de similaire, car les options de cette barre de menu ne sont pas vraiment nécessaires pour la navigation autour de la "chronologie". Dans ce cas, le menu apparaît lorsque vous faites défiler vers le haut ou survolez l'en-tête fixe.
Mais je dirais que ce genre de "têtes collantes" est bon pour les sites avec un "long scroll" comme Pinterest, LinkedIn, Facebook ou Twitter. Masquer/Afficher les menus Je le laisserais pour les appareils mobiles.