Tri - Besoin de testeurs

#1

Bonjour à tous,

La fonctionnalité de tri est prête à être testée !

  1. Aller sur Camptocamp.org
  2. Dans le bandeau du haut, cliquez sur et choississez demo => c’est les données de la base de demo, donc vieilles.
  3. Allez sur la liste des sorties, itinéraire, point de passages etc, et choississez le mode liste
  4. Et voila

image.png1196×522 131 KB

Que faut-il tester ?

Uniquement le fait que les résultats sont cohérent. L’interface est temporaire, et ne fonctionne pas sur mobile (à terme, on fera un truc qui fonctionnera pour les cards et pour les listes et sur les mobiles).

Merci d’avance !

PS : vous pouvez adressez vos remerciements à @momomaniac :thumbsup:

#3

Sur mobile (firefox 68.1.1) j’ai pas de bandeau du haut. Donc pas de pile de princedelu

#5

Hello,
j’ai pas encore testé mais ca a l’air super cool :slight_smile:
Un grand merci à @momomaniac pour cette précieuse contribution !

#6

Bonjour

Bravo et merci pour le boulot !

Pour les itineraires, j’ai besoin d’eclaircissements quant aux resultats des tris par Activites (apres avoir fait un choix dans l’onglet General). Je pensais que ce serait d’abord les itineraires mono-activite, ou d’abord les itineraires multi-activite. Puis j’ai eu un doute…
Kesako ?

#7

Pour ce qui est du tri par activités, je n’ai pas implémenté de logique particulière, j’ai juste corrigé ce qui me semblait louche tout de suite. C’est le bon sens d’elastic search qui fait le tri et je n’ai pas cherché la logique pour la colonne « activités ».

La question est bonne: quel est le sens attendu de tri de multi-activités (les mono-activités d’abord ??) et quel en est le tri inverse, l’inverse exact ?

Et je regarderai ce qu’on peut faire pour la vue non tabulaire (celle avec les petits aperçus rectangulaires) pour que la fonction soit aussi dispo sur mobile.

Merci pour ces premiers retours.

1 Like
#8

Bonne idée!

J’ai fait un premier essai.

  • Le tri sur le titre ne fait rien
  • Le tri semble ne se faire que sur la page courante, pas sur l’ensemble des données
  • Avec le jeu de données, je n’ai pas pu me rendre compte si l’on pouvait faire un tri multi colonnes ordonnées
#9

Merci @momomaniac !

Test sur PC, sur Firefox 72.0b7, avec uBlock, avec les itinéraires.

Quand je trie par cotation libre/obligatoire, j’ai sur quasi chaque page quelques résultats sans cotation, et la fin avec une cotation croissante, je suis pas certain que ça soit normal.

Il manque le tri alphabétique des régions.

Le reste marche bien, y compris tri par titre. Et se fait sur l’ensemble des données, et non la page courante (@papidelyon)

J’en profite pour reparler du manque de certains champs en haut : photos, traces gps pour les sorties, en fait il faudrait avoir un tri pour chaque colonne présente, autre que dans les « recherches multi critère ».

#10

Ce n’est pas ce que je vois. Par exemple, si je trie par hauteur, chaque page est bien triée mais conserve les mêmes titres. Un tri général change les titres de pages.

#11

Le tri par activités donne des résultats parfois bizarres.
Exemple ici avec notamment un itinéraire neige/glace/mixte au milieu de la liste des itinéraires rando+ski :

Capture2.JPG1468×837 277 KB

J’avais vu un exemple plus flagrant avec un itinéraire via Ferrata je crois, au milieu d’itinéraires rando seule.

Sinon le multi activités pose problème de toute façon pour le tri et je ne sais pas quelle solution on pourrait trouver (mais c’est un autre problème)

#12
#13

Oui mais ça ne concerne pas que le multi activités.qui est un problème à part comme je l’ai précisé.

#14

@papidelyon:
tu as bien sélectionné la base de données demo et pas prod avec la manip n.2 décrite par Charles ? Car la fonctionalité API n’est implémentée qu’en démo et la nouvelle version trie bien au sein d’une page mais ne reçoit pas les données triées de l’API.

#15

En effet, il manque certaines colonnes, qui ne sont pas indexées dans ElasticSearch. Pour l’instant, le choix a été de les désactiver (au moins on voit tout de suite que le tri ne marchera pas, y compris les images et traces GPS.

Pour le tri correct par activité, cela demande un peu de réflexion, j’ai l’impression. Donc déjà que toutes les combinaisons identiques (par ex. rando+ ski vs. neige/mixte) soient bien regroupées. Le tri entre les différentes combinaisons risque d’être une question de gout.
Le plus logique me semble un genre de tri alphabétique généralisé:

  • l’orde de base est celui du filtre d’activités: ski -> neige -> alpi -> grimpe -> glace -> rando -> raquettes -> PP -> VTT -> viaF -> slack
  • d’abord ski seul, puis ski + neige
  • ski + neige avant ski + alpi
  • neige seul juste après ski + slack (pas sur que cela ait un sens, mais on parle juste de l’algo)
  • ??? question : est-ce qu’il y a une différence entre ski + rando et rando + ski (genre, est-ce que l’ordre a une importance) ?
#16

c’est noté pour le comportement bizarre avec la carte, merci. Je n’avais pas du tout testé avec un filtre spatial, je regarderai ce qui se passe.

#17

Aucune différence : il n’y a pas de notion d’ordre des activités quand on crée une sortie ou un itinéraire.
Par contre je ne sais pas si la chaîne UI > API > BD conserve l’ordre de sélection ou non. Mais dans la définition du champ activités, il n’y a pas d’ordre.
A la lecture, l’UI peut donc imposer l’ordre qu’elle veut, ça ne modifie pas une info du contributeur.
Par exemple, quand on filtre sur une activité, ça peut l’afficher en 1er, suivi des autres activités pour les docs multiactivites (ça fonctionne peut être déjà comme cela).

En tout cas bravo pour le dev !

#18

Après, le tri par activités, ca ne me semble pas être le plus utile… Et c’est sur qu’avec le multiactivité, ca fera toujours un truc bizarre à un moment. No big deal pour moi.

#19

Bingo, j’ai sauté l’étape 2 de la procédure!
Donc tout ce que j’ai écrit doit être ignoré.

#20

Chez moi ça marche. problème peut-être déjà réglé par @momomaniac du coup?
Par contre, un peu du détail mais un truc bizarre pour les itinéraires dont l’altitude max n’est pas renseignée ils pourraient donc se trouver regroupés soit en début soit en fin de fin de liste. Là ils sont pour partie en fin de liste effectivement, mais il y en a aussi quelques-uns qui se baladent un peu avant. Notamment, en général, j’ai l’impression, en début d’avant dernière page.
Exemple : Camptocamp.org

Sinon pour le tri par activités effectivement c’est peut-être pas très utile comme fonction (il paraît plus simple de sélectionner l’activité recherchée) et compliqué à ordonner à cause des multiactivités.

#21

hmmm, j’ai regardé un peu. Le pb dans la version actuelle est qu’il y a 3 niveaux où l’ordre d’affichage se joue:

  1. requete elasticsearch
  2. requete SQL pour les détails des documents dont elasticsearch a fourni les ids
  3. affichage UI dans le tableau

En gros elasticsearch met les altitudes vides à la fin de la liste, puis le tableau les met au début, résultat: un ordre un peu bordélique.

#23

Déjà je comprends pas ce mot :wink: