Bug #100937
openCellules fiche, la pagination fonctionne mal sur un mobile
0%
Description
En travaillant sur #100932 j'ai rajouté des tests sur la pagination avec un mobile:
cat /home/gawel/envs/functests/lib/python3.11/site-packages/playwright/driver/package/lib/server/deviceDescriptorsSource.json|jq '.["Galaxy S5"]'
{
"userAgent": "Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.6778.33 Mobile Safari/537.36",
"viewport": {
"width": 360,
"height": 640
},
"deviceScaleFactor": 3,
"isMobile": true,
"hasTouch": true,
"defaultBrowserType": "chromium"
}
Le test échoue. La vidéo semble montrer que le bouton suivant n'est pas clickable
On a plusieurs moyen de solutionner ça:
- cacher les numéros de page clickable en css (de toute façon j'ai peur qu'avec de gros doigts on ne fasse pas trop ce qu'on souhaite)
- cacher l'abbr qui affiche le status (1-1/1) en css. Ou l'afficher ailleurs en plus petit. ça ferai gagner suffisamment de place si il n'était pas sur la ligne
- afficher moins de numéro de page. ca demanderai de passer un paramètre à l'url indiquant la largeur de l'écran et potentiellement augmenterai la taille du cache http
Perso je voterai plutôt pour cacher les numéros de page en css pour éviter de frustrer les gros doigts musclés (pensée pour ma maraîchère). De plus sur un mobile c'est bien plus simple de clicker 15 fois au même endroit que de chercher à viser.
Files
Updated by Thomas Jund (congés jusqu'au 23 fev) about 1 year ago
- afficher moins de numéro de page. ca demanderai de passer un paramètre à l'url indiquant la largeur de l'écran et potentiellement augmenterai la taille du cache http
J'ai calculé un affichage correcte en mobile pour une pagination composée de 7 éléments maximum. Soit
1 … 5 6 7 … 11
Le comportement de la pagination est étonnant. Elle commence avec un ellipsis et le perd :
1 2 3 … 11
pour arriver à
1 2 3 4 5 6 7 8 9 10 11
Sans ellipsis du tout et c'est là dejà qu'il y a un bug.
On a besoin de maitriser le nombre maximum d'élements affichés
Updated by Gael Pasgrimaud about 1 year ago
Thomas Jund a écrit :
- afficher moins de numéro de page. ca demanderai de passer un paramètre à l'url indiquant la largeur de l'écran et potentiellement augmenterai la taille du cache http
J'ai calculé un affichage correcte en mobile pour une pagination composée de 7 éléments maximum. Soit
1 … 5 6 7 … 11
Ici ça n'apporte rien une fois qu'on a dépassé la page 5. Ca serait plus propre d'avoir 4 boutons compatible gros doigts: "première page, page précédente, page suivante et dernière page". Avec l'abbr qui indique ou on est.
Peut-être que c'est une autre option a laquelle je n'avais pas pensé
En mode desktop, ca me semble important d'avoir plus de numéro de pages affichées (j'ai imité wcs mais je trouve déjà que 3 pages avant/après ce n'est pas beaucoup)
Le comportement de la pagination est étonnant. Elle commence avec un ellipsis et le perd :
1 2 3 … 11
pour arriver à
1 2 3 4 5 6 7 8 9 10 11
Sans ellipsis du tout et c'est là dejà qu'il y a un bug.
On a besoin de maitriser le nombre maximum d'élements affichés
C'est une fausse maîtrise. Ici il y a 739 pages. Un numéro de page "734" prends trois fois plus de place qu'une page "1" (sur le principe, hein). https://agents-demarches-recette.cr-reunion.fr/tableau-de-bord-ct/bons-a-valider/ Ca me parait donc compliqué de prévoir une solution ajustée au millimètre qui satisfasse tous les cas de figure. Non ?
Pour le comportement actuel de la pagination, je suis d'accord. Ca m'avait surpris aussi. Mais je penses que c'est un choix. L'algo vient de django https://docs.djangoproject.com/en/5.1/ref/paginator/#django.core.paginator.Paginator.get_elided_page_range
Il est peut-être trop basique. J'ai le souvenir d'un paquet django-pagination qui faisait mieux que django. J'avais bon espoir que django ai progressé depuis. Peut-être à tord.
Note que, avec 11 pages, quand on est sur la page 6, on est dans le cas unique avec le max de boutons. La page courante, 3 pages avant et après, la première et la dernière. Et on comble les trous quand il y a un écart de 1 parce que pourquoi mettre un ellipsis quand le trou est de 1 ? C'est peut-être pas si con pour un algo simpliste.
Updated by Thomas Jund (congés jusqu'au 23 fev) about 1 year ago
3 pages avant et après
ok, donc est plus sur un truc genre
1 … 8 9 10 11 12 13 14 … 678
ce qui fait un max de 11 eléments.
Je pointe aussi que cette reflexion ne doit pas de limiter au mobile. Le problème peut très bien se produire avec une cellule dans une colonne étroite en desktop, par exemple en config 2 colonnes sidebar.
Updated by Frédéric Péters (de retour le 10/3) 7 months ago
- Priority changed from Bas to Normal
C'est assez gênant ça déforme les layouts. (vu sur toodego)
Updated by Line David (absente > 24 fev) 3 months ago
- Assignee set to EO Dev Front
Bonjour les dev front, j'ai besoin de relancer ce ticket afin de pouvoir répondre au ticket lié #112336. Est-ce que Joachim et Gaël vous auriez un avis sur le sujet ?
Updated by Joachim Robert 3 months ago
À première vue j’afficherais le bloc d’état (balise abbr.cell-cards--items-pagination-state) sur une ligne séparée, et le lien vers la première / dernière page, ainsi que les ellipses :
(31-40/101)
< 1 … 4 … 11 >
C’est un endroit où une Container Query prend tout son sens (c’est la largeur du conteneur qui prime, pas celle de la fenêtre, étant donné qu’on peut avoir un conteneur étroit sur du desktop en colonnes).
D'où :
- une CSS Grid pour le layout du bloc cell-cards--items-pagination (gestion plus fine que flex)
- une container query qui gère le masquage de certains boutons selon la largeur du bloc (et non de la fenêtre), en cas de non-support (Safari < 16) affichage de l’option la plus simple pour éviter les débordements
Suppléments accessibilité :
- avoir les boutons dans une liste non-ordonnée
- enrichir l’aria-label du bouton courant ("Page 4 : page courante")
- ne plus utiliser la balise abbr pour le statut, mais un span classique avec l’alternative textuelle ("résultats 31 à 40 sur 101") lisible uniquement par les lecteurs d’écrans (la balise abbr est peu supportée par les technos d’assistance, à confirmer)
Updated by Thomas Jund (congés jusqu'au 23 fev) 2 months ago
- Tags set to gt-front
Updated by Line David (absente > 24 fev) 2 months ago
- Due date set to 31 January 2026
Updated by Joachim Robert 2 months ago
Line David a écrit (#note-8):
Bonjour les dev front, j'ai besoin de relancer ce ticket afin de pouvoir répondre au ticket lié #112336. Est-ce que Joachim et Gaël vous auriez un avis sur le sujet ?
Pour le ticket lié, j’ai une solution, spécifiquement pour la pagination des services Toodego, qui correspond à ce que la maquette demandait (avec extrapolation de ce qui n’était pas dans la maquette) :
Elle implique:
- un petit ajout dans Combo, sur le .py qui gère les paginations
- un ajout dans Publik Base Theme sur le template et les styles CSS
C’est une solution qui est possible (elle fonctionne actuellement) et généralisable sur toutes les paginations mobile.
La raison pour laquelle la solution est complexe, c’est qu’on ne peut pas faire deux générations différentes de pagination avec des prérequis différents pour écran large et écran mobile.
Les règles sont les suivantes (uniquement pour le mobile) :
< (1) 2 … 30 >
< 1 (2) 3 … 30 >
< … 2 (3) 4 … 30 >
< … 26 (27) 28 … 30 >
< … 27 (28) 29 30 >
< … 28 (29) 30 >
< … 29 (30) >
L’abbr est masquée et au maximum on a 8 éléments dans la liste. Si les pages ont 3 chiffres ça posera des problèmes d’encombrement, mais comme il s’agit d’une liste de services on peut être un peu confiants.
On n’est pas sur l’option "4 boutons pour les gros doigts" suggérée par Gawel plus haut, et il faut voir si les tests passent mieux avec cette approche.
Mes questions :
- est-ce que cette approche paraît satisfaisante pour Toodego ?
- est-ce que vous souhaitez généraliser l’approche à toutes les paginations mobiles ?
Updated by Thomas Jund (congés jusqu'au 23 fev) about 1 month ago
- Assignee changed from EO Dev Front to Joachim Robert
Updated by Gael Poupard about 1 month ago
- Tant qu’on laisse apparaître les numéros, le risque de débordement existe, peu importent les règles d’affichage — donc la piste de Gawel me semble vraiment très intéressante comme base.
- Si on veut enrichir en fonction de l’espace disponible pour la cellule, on peut jouer en CSS sur des choses relativement avancées : afficher les boutons de base (premier, précédent, actif, suivant, dernier) puis afficher progressivement les n premiers / derniers (un exemple sur Boosted, pour ceux qui lisent le CSS : https://boosted.orange.com/docs/5.3/components/pagination/#responsive-behavior).
Quelques éléments à challenger :
1. les boutons premier / dernier sont-ils indispensables ? Je ne me rends pas compte des cas d’usages mais à mon avis, le strict minimum est surtout précédent + suivant.
2. Même question pour les ellipses : elles induisent que la liste est élidée mais prennent littéralement la place d’un lien vers une page. Si on souhaite absolument les garder, on peut envisager de les réduire visuellement pour libérer un peu de place, non ?
JE n’ai pas d’avis tranché sur la question, mais je dirai que simple et homogène c’est bien.