Pagination de la liste de jeux de données

florimondmanca commented 2 years ago

Problème

Actuellement la liste de jeux de données (en page d'accueil ou dans les résultats de recherche) n'est pas limitée en taille.

Or à mesure que des fiches de données seront ajoutées, la page deviendra de plus en plus longue. Cela occassionnera un ralentissement. Il n'est ni utile ni efficace de tout afficher.

On peut le constater sur l'instance MC #218, qui comporte près de 700 jeux de données.

Critères d'acceptation

La liste de données est paginée par paquets de 10 par défaut
Un menu déroulant permet de choisir le nombre d'éléments par page : 10, 25, 50
La pagination est affichée en bas de la liste en réutilisant le composant du DSFR : https://gouvfr.atlassian.net/wiki/spaces/DB/pages/223051980/Pagination+-+Pagination

Implémentation technique

Côté back :
- Implémenter une page number pagination : (page, page_size) -> (items, total_items, page_size).
- Pour l'API, utiliser un schéma commun, du type PaginatedResults(page: int, count: int, results: list). S'inspirer par ex de fastapi-pagination
Côté front : utiliser le composant de pagination du DSFR

PRs :

[x] Back #224
[ ] Front

florimondmanca commented 2 years ago

@DaFrenchFrog Comment verrais-tu la chose côté design ?

DaFrenchFrog commented 2 years ago

TLDR : on ne met rien et on limite pour l'instant à 10 lignes. Sinon on peut mettre une pagination mais il ne faut pas que cela prenne du temps (il y a un composant pagination dans le DSFR Figma donc j'imagine qu'il y en a un en dev aussi ?).

Il y a des tests utilisateurs prévus tout au long des 2 prochaines semaines qui devraient nous apporter des insights sur la direction à adopter concernant la gestion des catalogues, et par conséquent ce qu'il serait pertinent d'afficher sur l'accueil. Selon ce qui va ressortir il pourrait être plus pertinent de n'afficher que la liste de catalogues (auquel cas je pense que dans un premier temps on en aura très peu), ou bien juste des statistiques, ou bien seulement les 3 derniers jeux ajoutés et d'autres composants, etc. Toujours est-il qu'à l'heure actuelle je vais avoir du mal à être pertinent et il vaut mieux considérer cette page comme non prioritaire. A la place je m'occuperais peut-être de continuer l'implémentation du schéma standard car je pense que ça apporte de la valeur et on sait qu'il restera un bon moment. Mais je te laisse décider. ;)

florimondmanca commented 2 years ago

@DaFrenchFrog Dac, j'ai compris l'idée pour la "page d'accueil" au devenir incertain. Par contre indépendamment de ça, la pagination me semble tjr pertinente sur la page de recherche, où on gèrera potentiellement des centaines ou milliers d'entrées. Et en effet il y a des outils de pagination dans le DSFR ce qui va grandement faciliter la tâche. :)

DaFrenchFrog commented 2 years ago

Alors sur ce sujet cet article résume parfaitement l'ensemble des options (pagination, scroll infini, ou bouton load more) : https://uxdesign.cc/ui-cheat-sheet-pagination-infinite-scroll-and-the-load-more-button-e5c452e279a8

On peut mettre de côté le scroll infini, et j'aurais une préférence pour le bouton load more pour un soucis de modernité et de simplicité mais l'argument du repère de numéro de page se tient aussi et le composant existe déjà... Donc je te laisse décider. :)

En tout cas il faudra augmenter le nombre d'items par page à une trentaine je pense.

florimondmanca commented 2 years ago

Merci pour la référence, article très pratique. :)

Pour le "load more" : je suis d'accord avec l'article que je m'attendrais plutôt à le voir sur un outil type navigateur d'images qu'un outil de référencement métier comme celui-ci. Par ailleurs, d'un point de vue écoconception et accessibilité la pagination semble aussi préférable. On peut facilement partager le lien vers une page donnée à l'aide de boutons simples et clairs, et naviguer plus directement à une page qui nous intéresse, en chargeant moins de données inutiles.

Pour le nombre d'items : une option pour le rendre configurable ? "10, 25, 50, 100", etc. C'est un pattern courant il me semble, documenté dans l'article. D'un point de vue écoconception, une valeur de 10 est recommandée, encore une fois pour réduire la quantité de données et inciter l'utilisateur à affiner la recherche (ou utiliser choisir une taille de page plus grande grâce au selecteur si le besoin est réel).

DaFrenchFrog commented 2 years ago

OK ça me va. 👍

etalab / catalogage-donnees