ETQ utilisateur je peux filtrer la liste de jeux de données selon les champs communs (aka Recherche avancée schéma commun)

[johanricher]

User Story

ETQ je veux filtrer le catalogue selon certains critères,
afin de pouvoir trouver un jeu de données plus précisément que par une recherche plein texte.

Parcours

Proposition par @florimondmanca

• J'accède à la page de recherche : la liste "par défaut" est affichée
• Je tape une requête dans la barre de recherche puis appuie sur Enter ou clique sur le bouton "Rechercher" : la liste se met à jour avec les jeux de données correspondants.
• J'applique un filtre, par exemple sur les formats : je clique sur le menu déroulant, je sélectionne un format. Le menu déroulant se referme et le format choisi apparaît comme option courante. La liste se met à jour avec les jeux de données correspondants.

Critères d'acceptation

Proposition @florimondmanca

• (Must have) Filtrage "mono-valeur" (sélection d'une seule valeur parmi une liste) pour ces champs :
  • Format
  • Couverture géographique
  • Service
  • SI source (technical_source)
  • Mots-clés
  • Ouverture (Bloqué - En attente de Définir un statut d'ouverture ne tenant pas compte de la présence d'un lien ou non #265 et Champ "licence" #287, cf ETQ utilisateur je peux filtrer la liste de jeux de données selon les champs communs (aka Recherche avancée schéma commun) #126 (comment))

Maquettes

https://www.figma.com/file/42KOPuvkD1jpubEe2mMtXr/DATALOGUE-maquettes?node-id=1854%3A33412

Implémentation

Back

• Backend des filtres de recherche #270

[DaFrenchFrog]

@johanricher @florimondmanca @Volubyl J'ai ajouté une proposition de maquette au ticket.

[florimondmanca]

@Volubyl Pour cette epic je suis partisan d'ajouter le back au fur et à mesure, de sorte à ce que le front se "branche" réellement dessus à mesure que les différents filtres sont dispo.

En revanche il faut bien noter que le fonctionnel côté UI détermine aussi les query params côté back. Ex : si on ne veut filtrer que 1 tag à la fois, on attendra ?tag=... et non ?tags=[...]. Pour ça j'ai mis qq commentaires / questions sur la maquette. Mais on devrait peut-être les avoir ici...

@DaFrenchFrog Je recopie ici mes commentaires que j'avais précédemment mis sur la maquette:

• Question générale : quand on sélectionne une nouvelle valeur pour un filtre, est-ce que a) elle remplace l'ancienne, càd le "tag DSFR sous le champ" est remplacé, ou b) elle s'y ajoute, càd le "tag DSFR sous le champ" est complété par un autre, et les tags DSFR peuvent être supprimés ?
• Filtre tags : est-ce qu'on peut filtrer avec plusieurs tags, ou un seul à la fois ? (Détermine si le back doit s'attendre à recevoir une liste ou 1 seul item)
• Même question pour les "Formats" : filtre-t-on un seul format à la fois, ou plusieurs ? (Même enjeu côté back)
• Champs "service" et "SI source" : intuitivement, ils ne sont pas de même nature que les champs "Couverture géo" par ex, car "service" et "SI source" sont des textes libres. Comment se présente le filtre pour un texte libre ? Je me dis qu'on ne peut pas faire un simple dropdown, car sa cardinalité sera virtuellement N = le nombre de datasets.

[DaFrenchFrog]

@florimondmanca Merci pour les commentaires sur les maquettes (je valide !) je réponds ici du coup car j'imagine que c'est plus simple pour vous.

• Question générale : quand on sélectionne une nouvelle valeur pour un filtre, est-ce que a) elle remplace l'ancienne, càd le "tag DSFR sous le champ" est remplacé, ou b) elle s'y ajoute, càd le "tag DSFR sous le champ" est complété par un autre, et les tags DSFR peuvent être supprimés ?

Réponse B. Lorsqu’une option est sélectionnée, un tag est ajouté sous la recherche (voir le "cas fermé avec filtres" pour leur positionnement. 
Le champs revient à son état initial."

• Filtre tags : est-ce qu'on peut filtrer avec plusieurs tags, ou un seul à la fois ? (Détermine si le back doit s'attendre à recevoir une liste ou 1 seul item)

On peut utiliser plusieurs tags

• Même question pour les "Formats" : filtre-t-on un seul format à la fois, ou plusieurs ? (Même enjeu côté back)

De la même façon on peut utiliser plusieurs filtres à la fois, d'où le système de tags qui s'ajoutent et peuvent être supprimés au fur et à mesure.

• Champs "service" et "SI source" : intuitivement, ils ne sont pas de même nature que les champs "Couverture géo" par ex, car "service" et "SI source" sont des textes libres. Comment se présente le filtre pour un texte libre ? Je me dis qu'on ne peut pas faire un simple dropdown, car sa cardinalité sera virtuellement N = le nombre de datasets.

Je l'imagine comme un champs sélect qui liste l'ensemble des saisies. Si une fiche a pour service "MTE" et une autre "Ministère de la transition écologique" alors on trouvera deux options. C'est clairement perfectible mais en attendant je pense que c'est le plus simple et cela permet de facilement trouver les failles en vue de leur correction.

N'hésite pas si tu as besoin d'autres informations.

[florimondmanca]

Réponse B. Lorsqu’une option est sélectionnée, un tag est ajouté sous la recherche (voir le "cas fermé avec filtres" pour leur positionnement. 
Le champs revient à son état initial."

Je ne suis pas sûr qu'on se soit compris. Est-ce que tu peux confirmer sur cet exemple ?

1. J'ouvre les filtres
2. Je clique sur le dropdown pour "Couverture géographique", je choisis "Régional" par exemple.

• Sous la recherche, un tag DSFR "Régional" apparaît.

4. Je clique à nouveau sur le dropdown, et je choisis cette fois "National".

• Conséquence : A/ un nouveau tag DSFR "National" apparaît sous la recherche ? Ou B/ le tag DSFR "Régional" devient "National" ?

Si c'est toujours B, alors ça veut dire que chaque dropdown permet d'ajouter un élément à une clause "OU" ('Régionale OU National OU ...').

Alors ma question est de cet ordre : ne pourrait-on pas afficher les tags DSFR afférents à chaque filtre sous le filtre lui-même ? En affichant les tags DSFR sous la recherche, on perd l'info de quel tag correspond à quelle donnée. Ça pose aussi la question de comment trier les tags DSFR lorsqu'on ajoute successivement des filtres différents. Exemple : je clique sur 'Régional' (couv géo), puis 'API' (Formats), puis 'National' (couv géo) -> Garde-t-on cet ordre ou groupe-t-on par champ concerné ? Avec un affichage sous chaque filtre, cette question ne se pose pas.

Je l'imagine comme un champs sélect qui liste l'ensemble des saisies. Si une fiche a pour service "MTE" et une autre "Ministère de la transition écologique" alors on trouvera deux options. C'est clairement perfectible mais en attendant je pense que c'est le plus simple et cela permet de facilement trouver les failles en vue de leur correction.

C'est vrai. Je note qu'il faut sûrement trier les valeurs possibles par ordre alphabétique pour s'y retrouver, partout où ça semble pertinent...

[florimondmanca]

@DaFrenchFrog @johanricher Sur la base de ces quelques discussions est-ce qu'on peut vous laisser remplir la partie "Périmètre fonctionnel" ? Ça ferait un bon complément (garde-fou ?) par rapport à la maquette pour la compréhension commune.

[DaFrenchFrog]

@florimondmanca c'est bien réponse A. Avoir un tag sous chaque dropdown va perturber la lisibilité de l'ensemble. L'idée d'avoir tous les tags au même endroit permet une fois le bloc filtres refermé de continuer à voir les filtres en action et si besoin d'en supprimer. Mon postulat est que le nom à du tag se suffit à lui-même pour comprendre de quelle catégorie il s'agit (d'autant qu'on l'a sélectionné quelques secondes auparavant). Cela me semble optimal car on prend les avantages de data.gouv sans les inconvénients (manque de lisibilité des items sélectionnés).

Mais si c'est trop complexe on peut aussi faire plus simple et enlever les tags de recherche. Dans ce cas on ne peut sélectionner qu'un seul filtre par catégorie, le dropdown conserve la sélection courante, et on ajoute simplement un "(x)" dans le bouton affiner la recherche pour indiquer combien de filtres sont en action. L'inconvénient c'est qu'on ne pourra chercher qu'un seul mot-clé ou région à la fois et une fois refermé on ne saura pas ce qui est filtré à moins de rouvrir le panneau.

Dis-moi ce que tu en penses.

[florimondmanca]

@DaFrenchFrog En fait, la chose qui me rend le plus perplexe c'est la non-localité (je ne sais pas quel terme employer) entre là où on paramètre le filtre (un champ dans le tiroir), là où on montre son état "actuel" (le tag), et là où on peut le réinitialiser (cliquer sur le tag).

Que penses-tu de cette problématique ? Je mets ma réflexion ci-dessous.

En tout cas, comme tout ceci impacte l'implémentation technique (j'y réfléchis côté back dans #271), je suis OK pour faire comme tu as proposé dans "l'option A" pour l'instant : tous champs sont multi-valeurs, et choisir une option dans un filtre l'ajoute à des "tags" au-dessus du tiroir à filtres. Curieux de ce que tu penses de la solution de Leboncoin cela dit.

---

J'ai remarqué que l'UI des filtres de DataGouv vient de changer : https://www.data.gouv.fr/fr/datasets/?format=json Qu'en penses-tu ? Ils utilisent désormais des dropdowns simples, soit ce que tu as écris dans ton 2e paragraphe : "ne sélectionner qu'un seul filtre par catégorie, le dropdown conserve la sélection courante". L'état "actuel" est montré par le fait que le dropdown (champ html <select>) prend la valeur choisie, tout simplement. Le principe de localité que je décris ci-dessus est respecté. Par contre, ces simples dropdowns ne permettent pas de choisir plusieurs valeurs de filtres. Or comme on l'a dit plus haut, il nous le faut à minima pour les tags. D'où l'idée d'afficher les valeurs sélectionnées sous forme de "tags" - je comprends.

(91 kB)

Je me souviens que @Volubyl avait mentionné l'exemple de Leboncoin, https://leboncoin.fr. Eux ont une solution 2-en-1 : afficher le filtre directement sous forme de tag sur lequel on peut cliquer pour paramétrer le filtre. Cela affiche un formulaire en popover, et une fois paramétré les valeurs choisies sont utilisées pour le texte du filtre à la place du nom du champ. En tant qu'utilisateur je trouve que c'est très bien fait, et ça respecte cette contrainte de localité. C'est aussi une solution très compacte, qui retire tout besoin de "tiroir déroulant". Mais il faut ce système de "popover" car le tag lui-même n'est pas un champ de formulaire. Ça nécessiterait aussi de sortir des clous du DSFR...

(67 kB)

[DaFrenchFrog]

@florimondmanca @Volubyl pour moi le problème de "localité" comme tu l'appelles est moins important que le fait de ne pas pouvoir sélectionner plusieurs options pour un même critère. Et on perd l'avantage de la visibilité permanente des filtres que l'on a sélectionné.

Pour le reste je pense qu'il vaut mieux en parler de vive voix parce que le sujet est complexe (sur le boncoin il n'y a qu'une dizaine d'items alors que pour nos tags il y en a bcp plus par exemple). Je te propose de rajouter le sujet recherche avancée au planning du workshop de Jeudi.

[florimondmanca]

@DaFrenchFrog @johanricher Juste pour confirmation écrite, que fait-on pour l'instant du filtre "Ouverture" présent dans la maquette ?

1. On le met en pause, et on y revient quand Régler le niveau d'accès d'une entrée dans le catalogue #289 est sec (critère du filtre précisé / redéfini).
2. On l'inclut dès maintenant, avec le critère "match s'il y a une URL open data (published_url)".

Si 2) alors je l'ajouterai à ma todo dans #270 (ou une issue séparée si je termine ce ticket avant).

[DaFrenchFrog]

@florimondmanca @Volubyl
On a vu qu'il pouvait y avoir des URLs vers des sites intranet ou des portails fermés, ce qui est un must have puisque les membres d'une organisation ont légitimement le besoin d'accéder à la page web de données qui ne sont pas open data. Par conséquent le simple fait de vérifier la présence ou non d'une URL pour savoir si les données sont open data ou non ne suffit plus.

Donc pour moi ce serait option 2, mais avec 2 sous-options :
2.1 : on a qu'un seul champ URL et on a un champ booléen "open data" qui permettra de savoir si l'url est publique ou non
2.2 : on a deux champs URL distincts (open data ou private) et on fait un match pour déterminer le statut (sachant que vu notre parcours seul un des deux ne devrait pouvoir être rempli).

Personnellement je trouve l'option 2.1 plus simple mais c'est un choix technique donc c'est comme vous voulez.

@johanricher qu'en penses-tu ?

[johanricher]

le simple fait de vérifier la présence ou non d'une URL pour savoir si les données sont open data ou non ne suffit plus

Tout à fait.

on revient au filtre "Ouverture" quand #289 est sec

Attention, le filtre "ouverture" était censé porter sur l'ouverture du jeu de données pas le niveau d'accès de la fiche. C'est donc plutôt les travaux sur le champ URL et sur le champ licence qui vont déterminer l'implémentation de ce filtre.

on a un champ booléen "open data"

Ce champ n'existe pas dans le schéma et est redondant avec le champ "licence".

Tant qu'un champ n'a pas été implémenté d'abord 1. côté contribution (formulaire) puis 2. côté consultation (fiche), on ne peut pas l'implémenter dans la recherche. Donc je suis favorable à la proposition de @florimondmanca de mettre en pause les travaux sur ce filtre côté recherche.

[DaFrenchFrog]

@johanricher Je ne vois pas bien ce qui est redondant entre la licence et le statut d'ouverture d'un jeu de données. Même si on peut déduire l'ouverture du jeu de données par la licence, il ne me semble pas raisonnable de demander au contributeur de savoir parmi les dizaines de licences qui existent celles qui sont open data et celles qui ne le sont pas. D'ailleurs il n'y a pas de champ licence dans le catalogue MC donc il faudra que ce champ puisse être vide.

Par ailleurs ce statut d'ouverture booléen est prévu dans le formulaire (maquette ici) à la question "Ce jeu de données est-il en open data ?" et il est implémenté dans la fiche (ici) donc à part le fait de devoir l'ajouter au schéma de données je ne vois pas de frein à l'ajouter à la recherche avancée.

On pourrait vérifier avec les prochains tests mais à mon avis le fait de pouvoir filtrer les fiche open data dans une recherche est clairement un must have...

[johanricher]

il ne me semble pas raisonnable de demander au contributeur de savoir (...)

On ne demande jamais au contributeur de donner une information qu'il n'a pas et encore moins de choisir une licence lui-même.

Si le jeu de données est en open data, ça veut dire que 1) le jeu de données a déjà été publié sur un site internet (donc il existe une page web pour ce jeu de données, accessible au public) et qu'une licence a déjà été choisie. Tout ce qu'il a à faire c'est donc de recopier l'information qui existe déjà. Par exemple dans le cas du MC depuis la page du jeu de données en question sur le portail Data Culture.

il faudra que ce champ puisse être vide

Oui le champ "licence" est optionnel (cf. https://lite.framacalc.org/0c5a3v0z3t-9th0) puisque un catalogue peut lister des "jeux de données" qui n'ont pas été ouverts (donc sans licence open data).

à part le fait de devoir l'ajouter au schéma de données je ne vois pas de frein à l'ajouter à la recherche avancée

Ajouter un champ il faut considérer que c'est demander de collecter une information en plus donc il faut éviter au maximum et que ce soit justifié par une raison valable. Quand il s'agit de demander une information redondante (en l'occurence avec le champ licence), la raison n'est pour moi pas valable.

le fait de pouvoir filtrer les fiche open data dans une recherche est clairement un must have

On est d'accord mais un utilisateur pourra filtrer les jeux de données par licence donc ça revient au même non ?