Quand la pagination sans fin est-elle appropriée?
Quand est-il approprié d'utiliser la pagination sans fin dans une application Web (par exemple, chargement automatique ou lien "voir plus")?
Exemples
- Google Reader
Cela crée également quelques problèmes pour l'utilisateur:
- Retour aux éléments de navigation ou haut de page
- Utilisation des boutons Précédent et Suivant du navigateur
Quels sont les avantages et les inconvénients de cette approche et comment atténuer les problèmes?
En bref - il convient lorsque le cas d'utilisation principal de la page est une "navigation légère", comme dans Flickriver , lorsque le partage (e-mail, etc.) une seule chose sur la page n'est pas pertinente et lorsque le référencement importe moins.
Quand je dis "navigation légère", je veux dire que l'utilisateur fait simplement défiler, à la recherche de choses intéressantes, sans avoir besoin de valider ou de revenir à un élément spécifique (ce que la plupart des gens font sur Flickriver).
Avantages:
- Expérience "fluide" ou "fluide" en parcourant la page
- Toutes les informations sont sur la même page.
Cela raccourcit le temps de chargement lorsque vous accédez à une autre page, ne force pas la séparation des éléments hautement liés simplement parce qu'il n'y a plus de place et vous permet également de rechercher une certaine œuvre ou phrase dans cette page.
Inconvénients:
- Revenir aux éléments est inconfortable, car vous ne pouvez pas marquer l'emplacement sur la page.
- Si vous souhaitez partager les informations avec quelqu'un, vous aurez du mal à spécifier la chose que vous souhaitez partager et serez obligé de partager la page entière et de dire "allez vers le bas pour ou recherchez ..."
- D'un point de vue SEO, moins de pages vues sont généralement pires pour votre référencement, sans oublier que les robots de recherche ne téléchargent qu'une partie de la page, de sorte que les informations ci-dessous ne seront pas indexées.
Atténuation:
Il semble qu'un bon ajustement pour une telle page n'aurait pas besoin d'atténuer les inconvénients, car ils n'interfèrent pas avec les cas d'utilisation courants. Si vous avez toujours une vraie raison et que vous souhaitez un tel modèle, vous pouvez par exemple fournir une navigation alternative qui permet à l'utilisateur de "marquer" des emplacements sur la page, puis de sauter entre eux, essayez de détourner le bouton de retour pour faire défiler vers le haut autant etc.
L'utilisation des boutons Précédent/Suivant ne devrait pas être un problème pour une bonne implémentation du défilement continu. Il est possible d'atténuer le problème en mettant à jour le fragment d'URL au fur et à mesure. Par exemple, lorsque je fais défiler vers le bas sur forrst.com, je passe de:
à
donnant des URL qui fonctionnent avec les boutons de retour.
Je crois que nous avons besoin d'une alternative à la pagination pour des listes d'éléments sans fin ou pratiquement sans fin, et je crois qu'une telle alternative devrait avoir tous les avantages du défilement et tirer parti des conventions d'interaction de la barre de défilement normale. Cependant, le défilement sans fin que j'ai vu ne l'est pas. C'est presque toujours pire que la pagination pour à peu près toutes les applications probables que vous pourriez rencontrer. Les désavantages:
Brise les attentes de la barre de défilement. Le plus gros problème est que le défilement sans fin ressemble à une barre de défilement normale, mais ne fonctionne pas comme ça. Une prolifération de barres de défilement de ruines de défilement sans fin pour une utilisation normale. Par exemple, les utilisateurs ne savent pas quand ils peuvent et ne peuvent pas estimer le contenu total à partir de l'apparence de la barre de défilement.
Interrompt l'estimation de la position. Si les utilisateurs veulent revenir à un élément précédemment vu, il est difficile de savoir à quelle distance remonter le défilement, car la position correspondante du curseur de la barre de défilement change à mesure que le nouveau contenu est chargé. Avec les barres de défilement normales, les choses défilaient ¼ du haut restent ¼ du haut. Avec la pagination, les choses à la page 4 restent à la page 4.
L'utilisateur est limité au déplacement d'un bloc de liste vers l'avant. Si l'utilisateur sait approximativement où se trouve l'élément de liste souhaité (par exemple, se souvient d'une visite précédente), l'utilisateur est néanmoins obligé d'y accéder en incrémentalement et en ralentissant en ajoutant de nouveaux éléments au bas de la liste par défilement continu - bas. Le défilement normal permet à l'utilisateur d'accéder instantanément à n'importe quel point de la liste. La pagination permet généralement un accès plus large et plus flexible (par exemple, aller à la fin) que le défilement sans fin.
Contenu perdu lors de la navigation. Lorsque l'utilisateur revient à une page de défilement sans fin, le contenu se recharge généralement depuis le début, ce qui fait que les utilisateurs perdent leur place dans la liste. Quand on revient à une liste paginée ou à une liste qui défile normalement, ils sont renvoyés au point de la liste où ils sont partis.
Jusqu'à ce qu'il existe une conception qui résout tous ces problèmes tout en surmontant les problèmes de pagination, je m'en tiendrai à la pagination. Ou mieux: ne présentez pas une liste pratiquement infinie. À quelques exceptions près (les cartes viennent à l'esprit), la pagination/défilement sans fin est le signe d'une mauvaise conception. Si vous avez tellement de contenu que vous ne pouvez pas le charger en une seule fois dans une liste à défilement normal d'une seule page, vous donnez peut-être trop de contenu à l'utilisateur. Vous attendez d'eux trop de travail pour faire défiler et parcourir tout cela. Vous avez besoin d'un moyen de mieux organiser ou filtrer le contenu que de simplement le vider dans une liste gigantesque et de laisser l'utilisateur passer au crible manuellement et fastidieusement tout cela.
Par exemple, pour les utilisateurs qui effectuent une recherche suffisante, vous pouvez afficher un échantillon d'un grand nombre d'éléments (par exemple, 500 miniatures de photos) sur une seule page de défilement. L'échantillon pourrait être:
Votre meilleure image de ce que recherche l'utilisateur. Complétez l'échantillon avec des liens pour des interprétations alternatives de ce que l'utilisateur pourrait rechercher, qui présentent chacune un échantillon différent d'éléments.
Une tentative de capturer la diversité de ce que l'utilisateur pourrait rechercher. Chaque élément pourrait alors inclure un lien pour "plus comme ça" que chacun montrerait un autre échantillon basé sur la similitude avec cet élément.
Presque jamais , les utilisateurs peuvent avoir plus de mal à s'orienter mais cela est facilement résolu avec des repères horizontaux indiquant quelle page.
En ce qui concerne le référencement, c'est une évidence - si vous comptez sur des robots suite à votre pagination et n'utilisez pas de plans de site XML, vous ne faites pas le bon référencement. Si quoi que ce soit, cela devrait augmenter l'interaction de l'utilisateur - tout l'intérêt du référencement.
Il convient que la pagination soit plus ennuyeuse.
L'argument que j'utilise est la fréquence à laquelle les gens doivent revenir en arrière de plus de 2 ou 3 pages? Si ce n'est pas souvent, pourquoi ne pas simplement leur montrer ces enregistrements sur une seule page. Si cela est plus souvent, je dirais que la pagination n'aide pas beaucoup de toute façon. À ce stade, peut-être qu'une option de recherche ou de filtrage aurait plus de sens.
J'aime et n'aime pas la recherche d'images sans page de Google. Je trouve très utile que je puisse simplement faire défiler et voir les images, et que je puisse comparer très rapidement deux images qui pourraient normalement être séparées par des pages. La pagination m'obligerait à parcourir constamment les onglets de mon navigateur.
Je n'aime pas ça parce qu'il semble mâcher une cargaison de bande passante, quelque chose que la société où je travaille essaie de conserver (trois acclamations pour les coûts de bande passante coûteux!)