Dites moi : c'est censé représenter quoi *pour l'utilisateur humain* ?
De ce que je comprends (mais pas intuitivement), ce serait censé représenter le combientième résultat par lequel commence la "page" sur laquelle on va cliquer.
Sauf que c'est faux.
C'est juste le langage de programmation qui commence ces listes par "0".
Un humain commence à compter une liste à "1".
Donc m'est avis que cette pagination devrait être :
1 | 11 | 21 | 31…
Là au moins ça aurait un sens pour les humains qui cliquent : si je clique sur "11", ça m'affiche la liste à partir du 11ème résultat : tellement logique !
A noter que Google "recherche" ne met que 9 résultats sur la première page, ce qui ferait :
1 | 10 | 20 | 30…
+1 = c'est quelque part plus "régulier" et intellectuellement significatif
(bon, d'accord, introduire des #EVAL dans les critères d'une boucle,
(on n'y avait pas pensé ? ..... et bien voila une bonne raison !
J’ajouterais que si une pagination représente des pages et que l’humain commence par la 1ère, il devrait continuer par la 2ème puis la 3ème.
1 | 2 | 3 | 4 | 5
En recherchant “Pagination” sur Google image, on voit que c’est pratiqué.
la pagination par page existe déjà, c'est #PAGINATION{page} qui la produit. Peut-être ça devrait devenir la pagination par défaut ?
Pour la pagination par nombre, je serai d'avis de seulement faker le premier indice en mettant 1 au lieu de 0, car en effet on est humain, mais de laisser ensuite 10, 20, 30 etc..., sans rien toucher pour autant aux articles affichés (on affiche toujours 10 par page).
C'est techniquement inexact, mais humainement plus compréhensible.
Bah ça c'est autre chose, et SPIP a bien un modèle pour ça. Mais ce n'est pas celui par défaut.
Dans celui dont je parlais le "1" ne correspond pas à la première page, mais au "numéro" du premier résultat affiché sur la page en question.
Quand on clique sur "1" le tout premier affiché c'est le 1er résultat => quand on clique sur "11" le premier affiché c'est le 11ème résultat, etc.
Ce qui n'est pas le cas aujourd'hui avec 0 | 10 | 20 qui ne signifie rien, et surtout qui n'a pas de rapport avec ce qui s'affiche quand on clique : si tu cliques sur 10, bah le 10 ne correspond à rien sur la page sur laquelle tu arrives. Puisqu'elle commence au 11ème résultat.
(Et au-dela de ça, je n'ai jamais pigé pourquoi c'était cette pagination décalée chelou qui était celle par défaut : je ne connais aucun logiciel web ou pas qui utilise ça comme pagination par défaut. À chaque fois c'est les vraies numéros de page. C'est juste pour faire différent des autres ? :D)
la pagination par page existe déjà, c'est #PAGINATION{page} qui la
produit. Peut-être ça devrait devenir la pagination par défaut ?
Oui nos mails se sont croisés : comme dit dans l'autre, je suis assez d'accord avec ça, ça devrait sûrement devenir le modèle par défaut.
Pour la pagination par nombre, je serai d'avis de seulement faker le
premier indice en mettant 1 au lieu de 0, car en effet on est humain,
mais de laisser ensuite 10, 20, 30 etc..., sans rien toucher pour autant
aux articles affichés (on affiche toujours 10 par page).
C'est techniquement inexact, mais humainement plus compréhensible.
Ce serait déjà un peu mieux effectivement.
Mais c'est perturbant quand même pour ma tête
1 | 6 | 12 | 18
Si je clique sur "12", je tombe sur le 13ème résultat…
Mais tu as raison, c'est sûrement plus compréhensible que
1 | 7 | 13 | 19
Enfin je sais pas… en tout cas, même en changeant à "1" pour le tout premier, ça me conforte dans l'idée que cette navigation n'est pas super compréhensible du premier coup.
Mais, sur des sites un peu verbeux… (comme SPIP Contrib par exemple cela va devenir difficilement affichable ! Mais peut-etre suffit-il simplement de proposer (et de bien faire connaitre !) plusieurs modèles de pagination ; ainsi j’utilisais systématiquement #PAGINATION{prive} dans tous mes squelettes, P.-S. D’ailleurs peyt-etre faudrait-il amender la documentation : - le P.-S. gagnerait à expliciter sa référence à l’ancien plugin de pagination - dans le paragraphe d’au-dessus, mettre en évidence le
il faudrait que ce soit celle là non ? mes souvenirs perso : on était tellement content.e.s avec la 1.9 d'avoir un système simple de pagination qu'on pas pensé que le modèle par défaut était pourri…
En suivant ce fil sur la pagination il me semble (f)utile de vous signaler un cas particulier peu fréquent mais intéressant.
Sur un site, je regroupe les articles en utilisant le filtre |unique appliqué aux #SURTITRE.
Il arrive que l'ensemble des articles regroupés sous le même surtitre fasse partie de 2 dizaines consécutives. Le système de pagination s'en tenant à 10 objets dans sa liste, 10 étant le pas de pagination, le surtitre est repris sur la page suivante. Logique de l'algorithme , mais ça n'indique pas à la fin de la première dizaine que le groupement est incomplet ou ça laisse croire qu'il l'est, ça donne aussi l'impression d'un groupement supplémentaire à la page suivante. Dilemme !
Garder le pas de pagination avec ce léger désagrément
Forcer l'algorithme à tenir solidaires les enregistrements sous le même surtitre et fausser le pas de pagination ...
La solution qui ménage la chèvre et le chou serait que le filtre |unique rajoute des "..." à sa balise si le nombre d'objets qu'elle renvoie dépasse le pas de pagination pour signaler une suite à la page suivante.
Ce n'est certainement qu'un détail cosmétique mais c'était mas réflexion du soir. Qu'en pensez-vous ?
cela va devenir difficilement affichable ! Mais peut-etre suffit-il simplement de proposer (et de bien faire connaitre !) plusieurs modèles de pagination ; ainsi j’utilisais systématiquement 