Produits Entr'ouvert » Combo

On a deux tickets qui parle de tri. Après rapide discussion avec ThomasJ il en ressort que:

• on ne veut pas toujours trier les tableaux (par exemple si c'est basé sur un tri défini dans une vue c'est très bien)
• en mode mobile on a plus d'entête de colonne donc on ne pourra pas trier du tout

La conclusion est que l'on peut combiner les deux tickets pour avoir une UI identique pour tous les modes d'affichage:

• en backoffice, on peut sélectionner des champs du modèle de fiche sur lesquels autoriser le tri
• en front on se retrouve avec une ligne d'entete (un peu comme les filtres) indiquant "trier sur: <champ 1> <champ 2>"

Il faudra pouvoir cliquer plusieurs fois sur un champ pour au premier clic trier sur ce champ et au deuxième inverser le tri sur ce même champ.

en backoffice, on peut sélectionner des champs du modèle de fiche sur lesquels autoriser le tri

Je ne comprends pas le raisonnement pour cette option; pour moi on peut faire sans et juste permettre le tri sur toutes les colonnes.

Frédéric Péters a écrit :

en backoffice, on peut sélectionner des champs du modèle de fiche sur lesquels autoriser le tri

Je ne comprends pas le raisonnement pour cette option; pour moi on peut faire sans et juste permettre le tri sur toutes les colonnes.

Ceci n'est vrai qu'en mode tableau (et je suis d'accord que cette demande concerne spécifiquement ce mode).
Pour les deux autres mode d'affichage il est impossible de deviner les champs qu'on aimerait trier (cf le ticket lié #100790)

L'idée est donc d'avoir quelque chose d'uniforme pour tous les modes. Que ce soit en back ou en front.

C'est tout à fait discutable et c'est même pour ça que j'ai commenté ici

Ceci n'est vrai qu'en mode tableau

Mais le titre de ce ticket commence par "cellule fiche mode tableau".

(je ne comprends pas comment vient #100790, le ticket toodego ne parle pas de tri)

Frédéric Péters a écrit :

(je ne comprends pas comment vient #100790, le ticket toodego ne parle pas de tri)

Il y a "tri" dans le titre et "trier" dans le corps :) Mais peut-être que je comprends de travers. Je verrai avec Line ce qu'elle voulait dire exactement. Pas très clair pour moi.

Je reviens à la charge avec une proposition étayée qui coûtera guère plus cher. Si ce n'est en test/risque mais j'ai l'intention d'ajouter des tests fonctionnels pour ça, entre autre

Donc, pour tous type de cellules:

• en backoffice, on peut sélectionner des champs du modèle de fiche sur lesquels autoriser le tri
• en front on se retrouve avec une ligne d’entête (un peu comme les filtres) indiquant "trier sur: <champ 1> <champ 2>"

Pour les cellules en mode tableau:

• si aucun champs n'est sélectionné en BO, on peut trier sur tous les champs possible (il me faudra définir plus finement "possible"). sinon on ne peut trier que sur les champs sélectionné
• en front, sur un desktop on peut trier en cliquant sur les entêtes de colonnes. sur un mobile, on a pas les entête donc on affiche "trier sur: <champ 1> <champ 2>" (l'idée est de jouer avec pk-desktop-only/pk-mobile-only)

Avantage: on peut trier tous les modes d'affichages que ce soit sur mobile ou desktop. Inconvénients: ça rajoute du code et de l'UI en BO

Pas de soucis à me faire refouler la dessus. Si il faut prendre en compte uniquement le mode tableau via les entêtes de colonnes àlà wcs (pas visible en mobile), je fais ça.

(Côté toodego, en regardant les wireframes, c'est vrai que je ne vois rien qui necessite une option de tri.)

Ici le client attend un tri par colonne de tableau, genre flèches à côté du chaque header de colonne. Mais ce que attend avant tout le client est de pouvoir trier, comment, cela nous appartient encore de choisir la meilleure option.

Quelques points pour alimenter la reflexion.

• Côté accessibilié, l'information de tri sur pose sur le header de la colonne :
  https://www.w3.org/WAI/ARIA/apg/patterns/table/examples/sortable-table/.
• en mobile, avec la décision de passer les tableaux en responsive en masquant la ligne de header, si le tri se fait via les headers, le tri ne sera pas possible. avec ce choix d'UI on limite donc le tri sur desktop only (ou on decide de proposer une autre UI, qui ne se fait pas via les headers)
• L'option de tri doit être optionnelle, il y a une majorité de tableaux qui sont composés de peu de lignes et ne nécessite nullement d'être triés.
• Quid du tri des colonnes "gabarits", (Lauréline m'avait dit que ce ne serait pas possible) ?

Je ne suis pas forcément fermé à partir sur une UI différente que des "boutons th".
Ce que je note de l'UI d'un formulaire au-dessus du tableau :

• avantage: fonctionnalité de tri possible sur mobile
• avantage: Certainement plus simple côté UI clavier et tactile
• avantage: Peut proposer des tris plus complexe (multiples critères)
• avantage: fonctionne avec le mode d'affichage des fiches en carte.
• avantage, plus simple côté CSS portail, on a pas à créer des "boutons th" pour les tableaux
• avantage: plus simple côté HTML avec les conditions
• avantage: possibilité de trier sans headers, (même en desktop, l'affichage des headers d'un tableau est optionnel)
• Avantage: on a déjà une zone de form de filtrage pour la cell fiche, on peut y ajouter les options de tris
• inconvenient: est peut-être moins standard côté UI et n'est pas ce qu'on attend
• inconvenient: nécessite plus de clics en desktop et interface moins visuel ou moins instinctive.

Au vu des avantages, je me demande si dev le tri du tableau par 'boutons th' vaut la peine.

(écrit avant d'avoir vu le dernier message de Gael)

Thomas Jund (tjund) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

• URL : https://git.entrouvert.org/entrouvert/combo/pulls/429

Thomas Jund (tjund) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

• URL : https://git.entrouvert.org/entrouvert/combo/pulls/429