web-dev-qa-db-fra.com

Alternatives à la pagination?

Avec Google Appengine, nous pouvons passer à la page suivante d'une requête à l'aide d'un curseur et avec un peu d'effort, nous pouvons également aller à la page précédente. Mais il n'y a pas de bonne façon d'aller à la nième page, je crois pour des raisons d'évolutivité. Il peut être possible d'implémenter la "dernière" page si nous faisons une requête inverse et nous pourrions être en mesure d'aller à la n-ième page mais je ne sais pas si cela fonctionnera car je n'en ai jamais vu d'exemple, mais selon au manuel, il est censé être possible d'itérer sur la page que vous souhaitez:

Donc, si je ne peux pas implémenter une pagination complète, je pense à le faire de manière alternative:

1) Défilement infini, par ex. comme Facebook affiche des mises à jour de statut. Il n'y a pas de "pages", faites seulement défiler.

2) Juste un bouton en bas qui dit "afficher plus". J'ai vu des sites qui utilisent cela pour leurs catalogues de produits et c'était correct.

Quels sont les inconvénients de choisir l'une ou l'autre des solutions ci-dessus comme alternative à la pagination "classique" (First Previuos Next 1 2 3 4 .... 17 18 29 20 Last)

Spécifier mon cas consiste à répertorier les articles par heure (le plus récent en premier), 50 articles par page dans une application similaire à la liste des annonces classées de craigslist. Il peut donc y avoir des solutions de contournement que je peux utiliser pour mon problème spécifique car je répertorie les articles en fonction du temps et je peux passer à la page suivante à l'aide de curseurs, mais c'est aussi tout ce que je peux faire et je voudrais proposer une solution plus complète.

Références:

https://stackoverflow.com/questions/18697058/google-app-engine-search-api-set-cursor-at-a-specific-position

https://developers.google.com/appengine/docs/python/ndb/queries#cursors

5
Niklas

Questions que je me pose lors du choix de la bonne solution de pagination:

  1. Les utilisateurs s'adresseront-ils à une page particulière? Si non - alors ne faites pas de chiffres, faites juste défiler avant/suivant ou infini.
  2. Fréquence de publication des éléments dans le flux. Si souvent, alors si je donne le numéro de page à quelqu'un, cela deviendra incorrect dans une heure - il/elle ne trouvera pas l'élément sur cette page. C'est le cas de Twitter. Et ils n'utilisent pas de chiffres. Ils utilisent un défilement infini.
  3. Un article est-il réel/nécessaire uniquement pour une courte période (heures, jours)? si oui - alors pas besoin de numéros de page. Scénario de Facebook - défilement infini.
  4. L'utilisateur examine-t-il de nombreux éléments avant de choisir le bon? Si oui - alors les numéros de page sont nécessaires. Le cas de Google.
  5. Avez-vous besoin de montrer que vous avez de nombreux éléments pour convaincre les utilisateurs que vous êtes cool - puis utilisez des numéros de page.
5
Humanoit

Sauf en cas de problèmes de performances, laissez l'utilisateur choisir entre la pagination, le défilement infini, le filtrage et le tri du contenu. Une façon d'y penser est de laisser le serveur décider quoi livrer en fonction de la charge. À fort trafic, seuls 10 articles seront livrés à chaque demande délivrée par pagination/défilement infini et permettront le filtrage. Ce serait une sorte de "serveur réactif" au lieu d'essayer de tout faire du côté client de façon statique.

L'inconvénient est que le concepteur décide de la manière dont le contenu est diffusé, sans laisser l'utilisateur choisir parmi un ensemble d'options. Personnellement, je pense que les deux méthodes sont de mauvais UX, car elles ne permettent pas la recherche en ligne. Les utilisateurs qui consomment du contenu volumineux aimeraient pouvoir effectuer des recherches dans la page, ce qui n'est pas possible si vous paginez un contenu long. J'ai vu un utilisateur frapper ctrl + F puis a commencé à taper pour trouver exactement ce dont ils ont besoin - plus rapidement. La pagination ou le défilement infini rendent ce processus beaucoup plus difficile.

4
Benny Skogberg

eh bien, c'est délicat, car:

  • la numérotation des pages ne donne à l'utilisateur aucune information autre que le pourcentage (s'il fait un calcul) du nombre d'éléments qu'il a vus et du nombre d'éléments non vus restants. TOUT est meilleur que ces chiffres.

  • d'autre part, ce type de pagination des articles est extrêmement populaire. TOUT LE MONDE sait ce qu'il fait et comment l'utiliser.

L'inconvénient du "défilement infini" et de "charger plus" est que l'utilisateur n'a absolument aucune idée du nombre d'éléments supplémentaires. La signalisation est un principe UX très important.

2
Bobby Tables