La question est sur où placer les boutons de pagination sur une page de catalogue. Nous avons ici quelques choix de base.
L'argument évident pour le placer niquement en bas de la page est de forcer votre utilisateur à voir tout votre catalogue en premier, puis à passer à la page suivante. Vous voyez également les principaux sites Web, comme Amazon, ebay et autres similaires, ils ont placé la pagination uniquement en bas de la page.
Mais dans les principaux sites de l'année précédente placez la pagination sur les deux, en haut et en bas.
L'argument pour le placer également en haut du catalogue page est d'aider l'utilisateur, après le défilement vers le bas, à faire défiler à nouveau vers le haut, voir la deuxième fois une ligne qui a gardé le mien, puis se déplacer à la page suivante sans avoir besoin de faire défiler à nouveau vers le bas.
La question est - c'est mieux pour l'utilisateur de l'avoir aux deux endroits ou non. Peut-être que certains sites doivent forcer l'utilisateur à faire défiler vers le haut et vers le haut et c'est leur objectif, voir autant que possible, mais c'est bon pour un utilisateur ou le faire quitter le site si vous le rendez frustré de haut en bas.
Une alternative à laquelle j'ai pensé est d'avoir les boutons de pagination supérieurs cachés, lorsque l'utilisateur fait défiler vers le bas, vous le rendez visible, et si l'utilisateur revient à nouveau comme indiqué, de cette façon vous forcez votre utilisateur à voir le catalogue entier avant passez à la page suivante, mais conservez-la sur les deux.
Il y a plusieurs avantages à placer le contrôle de pagination à la fois en haut et en bas, et un seul inconvénient, à savoir l'espace d'écran supplémentaire dont il a besoin.
Vous mentionnez que vous, en tant que propriétaire du site, souhaitez que l'utilisateur affiche tout le contenu de chaque page, mais vous fournissez toujours la possibilité de passer aux pages (en affichant les numéros de pagination), permettant ainsi à l'utilisateur de sauter des pages, de sorte que cet argument est un peu contradictoire. Si vous activez des fonctionnalités utiles pour la navigation, l'utilisateur vous aimera pour cela, et passera probablement plus de temps sur votre site plutôt que si vous ne l'avez pas fourni.
Un autre avantage que vous n'avez pas évoqué est que l'utilisateur obtient un aperçu instantané du nombre de pages du catalogue avec le contrôle de pagination en haut. Si la vue est un résultat de recherche et que le contrôle de pagination affiche plus de 10 pages, l'utilisateur peut peut-être affiner sa recherche. Dans ce cas, l'utilisateur apprécierait d'en être informé immédiatement.
Une autre option consiste à avoir une barre de menu (ou un concept similaire) qui est toujours visible, peu importe où vous vous trouvez sur la page. Que cela soit approprié dépend de votre application et de vos objectifs.
C'est évidemment ce qui est utilisé dans la plupart des applications de bureau, où les barres de menus et les barres d'outils sont toujours (ou presque toujours) visibles. Sur le Web, Gmail en est un exemple facilement accessible. Lorsque vous faites défiler un message électronique dans Gmail, une petite barre d'outils est toujours visible, quelle que soit la distance parcourue dans le message. Cette petite barre d'outils contient des actions très utilisées telles que "supprimer" et "ajouter une étiquette". De même, dans la liste des messages, les boutons "plus récents" et "plus anciens" sont toujours accessibles, même si vous avez fait défiler vers le bas. Vous perdez une partie de l'écran sur cette barre d'outils, c'est donc un choix de conception si cette approche est suffisamment utile et répond à vos objectifs pour justifier l'utilisation de l'écran pour elle. Google semble avoir décidé qu'il était utile dans le courrier mais pas dans la recherche sur le Web.
Si votre contenu est tel qu'il est peu probable qu'un utilisateur ait besoin de sauter à un endroit spécifique de votre contenu, alors vous pourriez faire un bon argument pour ne placer des boutons de pagination qu'à la fin. La recherche Google en est un bon exemple. Cependant, même ici, une fois que quelqu'un est à la page 2, il peut vouloir revenir facilement à la première page sans avoir à faire défiler jusqu'à la fin. Cela donne un bon argument pour les avoir au début et à la fin sur toutes les pages sauf la première. Cela peut être atténué en ayant des pages plus courtes, mais cela soulève d'autres préoccupations.
Dans les situations où il est probable que les utilisateurs devront pouvoir accéder à une place dans votre contenu, il est alors logique de les donner au début, et pour faciliter la navigation, vous en aurez probablement besoin à la fin également.
Mais il y a aussi une considération de conception pour contrebalancer le placement de boutons de pagination en haut et en bas du contenu. Ce compromis ainsi que d'autres moyens ne constituent pas une bonne réponse pour toutes les applications.
En remarque, dans certaines situations, le défilement infini a plus de sens que la pagination, il peut donc être utile de l'examiner en premier, auquel cas vous n'aurez pas besoin de placer des boutons de pagination.
Cela dépend de l'objectif principal de votre page. Afin de persuader l'utilisateur de voir l'intégralité du contenu de la page, il est bien sûr préférable d'afficher les boutons uniquement en bas de la page. Cela est logique dans les sites Web de commerce électronique avec une liste limitée d'articles.
La Wayne State University a utilisé une approche intéressante pour visualiser le bouton "Back to Top" et forcer les utilisateurs à faire défiler vers le bas. Vous pouvez voir une démo sur ce lien http://blogs.wayne.edu/web/2012/03/16/a-better-return-to-top-experience/
Vous pouvez utiliser une technique similaire pour vos boutons supérieurs en utilisant un javascript pour détecter jusqu'où le visiteur a fait défiler et afficher les boutons supérieurs hors de la zone de contenu.
J'espère que cela a aidé