ETQ contributeur je peux ajouter des mots clés (tags) à la création de la fiche

Volubyl commented 2 years ago

Fait partie de l'epic #125

User Story

A la création d'une fiche, ETQ que contributeur je peux ajouter des mots-clés qui permettrons de faciliter la recherche d'un jeu de donnée lié à une thématique

Exemples de mots-clés : forêt, arbre, agriculture, ...

Design

Maquette : https://www.figma.com/file/42KOPuvkD1jpubEe2mMtXr/DATALOGUE-maquettes?node-id=843%3A22535

Réutiliser l'élément UI "Tag" du DSFR : https://gouvfr.atlassian.net/wiki/spaces/DB/pages/310706305/Tag

Thésaurus

Ensemble des mots-clés déjà utilisés dans le catalogue.

Critères d'acceptation

Must have : voir les mot-clés du thésaurus, ajouter un mot-clé sur la fiche à partir du thésaurus, supprimer un mot-clé de la fiche
Nice to have : autocomplétion
Nice to have : trier les mot-clés du thésaurus par popularité (nombre d'utilisation)
On ne fait pas : créer un nouveau mot-clé (le thésaurus est fermé)

Implémentation

Fonctionnel :

Import de tags pour former le thesaurus (= contenu d'une table Tag)
Ajout de tags dans formulaire de contribution
Modification des tags dans page d'édition

Itération 1

Résumé : gestion des mots-clés d'une fiche, recherche/autocomplétion basique

DB :

Relation logique : Dataset 0:n --- 0:n Tag (M2M)
Relation physique : Dataset (id) --> DatasetTag (dataset_id, tag_id) <-- Tag (id)

API :

Endpoint GET /tags/ qui renvoie une List[{id, name}]
Mise à jour POST /datasets/ : accepter un champ tags: List[ID]
Mise à jour PUT /datasets/:id/ : accepter un champ tags: List[ID] (utilisé pour remplacer la liste entière, pas de système de diff ajouts/suppressions)

Front :

Cliquer sur un tag permet de l'ajouter aux tags sélectionnés (le tag dans la liste est désactivé/grisé)
Cliquer sur un tag sélectionné le supprime
Recherche tag dans le front à partir de la liste complète
Autocomplétion basique : tag.startWith(searchTerm)

Itération 2

Résumé : tri de mots-clés par popularité, recherche/autocomplétion en DB (plus robuste, plus scalable)

API :

Rajouter à chaque tag le count des datasets qui ont ce tag
Trier les résultats de GET /tags/ par count DESC
Endpoint GET /tags/search/?q=.... pour rechercher un tag via la DB (passage à l'échelle : obligatoire quand il y aura des milliers de tags) et améliorer l'autocomplétion

Futures améliorations

Bouton "Charger plus de mots-clés" (pagination des suggestions) (pertinence par rapport au champ de recherche ?)

johanricher commented 2 years ago

Est-ce qu'il faut un ticket dédié à la gestion des tags lors de l'édition d'une fiche (pour distinguer de la création) ou on peut factoriser ce ticket ? @Volubyl @florimondmanca

florimondmanca commented 2 years ago

@johanricher Pas de préférence, je dirais qu'en effet les deux vont ensemble puisqu'a priori le composant sera réutilisé entre création et édition. @Volubyl Qu'en penses-tu ?

DaFrenchFrog commented 2 years ago

J'ai modifié le ticket suite à la question qui m'était posée.

florimondmanca commented 2 years ago

@DaFrenchFrog Petite question : sur la maquette il y a l'astérisque rouge sur le champ "Mot-clés", qui indiquerait que ce champs soit "obligatoire".

Est-ce que ça veut dire qu'un utilisateur doive obligatoirement choisir au moins un tag ?
Que faire alors, en tant qu'utilisateur, si aucun tag du thésaurus ne correspond au jeu de données ? À ce stade le thesaurus est fixe. Mais quand il sera (il me semble) géré par un admin, la question se posera aussi. Est-ce qu'on s'attend à ce qu'un admin demande la création de tags ? Le plus probable je crois est que ça incitera à mettre un tag bateau.

Je me demande s'il ne vaut pas mieux autoriser de ne mettre aucun tag.

Est-ce que datagouv a une quelconque contrainte de ce type sur le nb de tags d'un jeu de données ?

johanricher commented 2 years ago

Est-ce que datagouv a une quelconque contrainte de ce type sur le nb de tags d'un jeu de données ?

J'ai testé pour vous, pas de contraintes dans le formulaire de création d'une fiche jeu de données. Au choix (1) saisie libre d'un nouveau mot-clé ou (2) autocomplétion qui permet de choisir dans l'équivalent de notre "thésaurus" qui semble être constitué de tous les mots-clés déjà utilisés :

Les mots-clés apparaissent ensuite sur la fiche publique du jeu de données :

DaFrenchFrog commented 2 years ago

@florimondmanca Tu as raison il ne vaut peut-être pas mieux le mettre en obligatoire je modifie la maquette. J'ai mis à jour la maquette pour avoir les tags sur la fiche de données.

johanricher commented 2 years ago

Ce ticket sera fermé quand la PR #213 sera mergée.

Volubyl commented 2 years ago

@johanricher @DaFrenchFrog

Par rapport à cette issue, je me sens un peu "bloqué" parce que j'ai conscience que l'implémentation actuelle de l'ajout des mots clés ne correspond pas vraiment aux attentes.

Pour le contexte j'ai vu plusieures apprcohes possibles du problème :

Une approche basée sur des élements HTML standards

Mon intention initiale est de favoriser l'utilisation de balises html 5 pour implémenter des fonctionalités UI.

J'y vois plusieurs avantages :

réduire (parfois) le nombre de ligne de code utile pour la réalisation d'une fonctionnalité
profiter du travail des personnes travaillant dans les équipes se chargant de standarisisant le web et/ou qui travaillent aux devs des navigateurs. Ces équipes (à mon sens) ont plus d'expertise en terme de compatibilité navigateur, d'accessibilité, de .... que nous en avons et ce pour une raison simple: pour certains d'entre eux c'est leur travail à plein temps
profiter du fait qu'il y a plus de chance que des élements standards couvrent des egde cases auxquels nous ne penserions pas en développement des élements customs
réduire la quantité de JS de l'application
réduire la quantité de code "custom" et donc augementer la maintenabilité (il est plus facile de maintenir du code qui n'existe pas ^^)
....

Au niveau implémentation je suis donc parti sur l'utilisation des datalist

Limitations de cette approche

Le problème majeur de cette approche c'est que l'on dépend de la manière dont les navigateurs implémente ces standards et du comportement lié à cette implem.

Exemple : pour afficher le menu déroulant il faut un click sur chrome tandis que sur Firefox c'est deux

Approche basée sur du code custom

C'est une approche utilisée par l'implem React du DSFR

Voir démo https://dataesr.github.io/react-dsfr/#/Composants/%C3%89lements%20d'interface/Select (Le select avec recherche)

Mon soucis avec cette approche c'est que je trouve le code nécessaire à la réalisation assez compliqué (notion subjective, j'en conviens) et que je ne peux pas garantir qu'il couvre tous les edges cases

Cepandant, l'avantage de cette approche c'est qu'elle permet de coller le plus possible aux besoins UX.

Réflexion à ce stade

Je me demande si mon approche initiale voulant utiliser les standards étaient la bonne. Cela fait plusieures fois que j'ai des retours par rapport à l'utilisation du composant de création de tag parce que cela ne correspond pas aux attentes en terme de UX.

J'ai l'impression qu'il va falloir aussi partir sur une implémentation custom.

Le truc c'est que avec une estimation macro et très approximative, j'ai l'impression que réaliser une implem custom qui soit accessible, couvre un maximum de edge case, ... va prendre du temps (quelques jours).

J'aurai donc besoin d'un arbitrage par rapport à ça.

Mes besoins

A l'heure actuelle, j'aurai besoin d'avoir une description textuelle la plus exhaustive possible de comment devrait fonctionner le composant de création de tag.

Quelque chose comme :

Quand je clique sur ..., je vois ....
Quand j'appuie sur ..., un mot-clé apparait ....

Eventuellement, j'aurai besoin d'avoir des exemples de composants déja existant (sur un site, dans une doc, ...) pour que je puisse essayer d'imiter le fonctionnement

DaFrenchFrog commented 2 years ago

Hello,

Je comprends toutes ces problématiques. Au vu des difficultés potentielles que cela impose je propose que dans un premier temps que l'on utilise un dropdown natif et non-éditable. Le nombre de mot-clés n'étant pas si conséquent ce n'est pas la peine de mettre trop d'efforts sur ce sujet.

En conséquence :

Lorsque je clique sur le champ je vois la liste des mot-clés apparaitre. Si je clique sur un item, un tag apparait sous le champ. Ce tag peut être supprimé au clic. On ne peut pas ajouter deux fois le même tag. On peut faire défiler la sélection des items de la liste au clavier comme on le fait avec le dropdown natif.

Nice to have : on pourrait faire en sorte de "griser" un item déjà sélectionné, et un clic sur ce dernier supprime le tag et remet l'item dans son état standard.

Est-ce que cela simplifierait les choses ?

Volubyl commented 2 years ago

@johanricher que penses tu de la propal de @DaFrenchFrog ?

florimondmanca commented 2 years ago

@Volubyl Johan est en vacances cette semaine. Si je peux me permettre de proposer mon avis, je dirais +1 à la proposition de Romain, à savoir un select standard pour l'instant si j'ai bien compris.

Je rajouterais probablement aux attentes d'afficher la liste des tags dans l'ordre alphabétique par exemple, pour faciliter la "recherche visuelle en déroulant le select". Non, @DaFrenchFrog ?

DaFrenchFrog commented 2 years ago

Je rajouterais probablement aux attentes d'afficher la liste des tags dans l'ordre alphabétique par exemple, pour faciliter la "recherche visuelle en déroulant le select". Non, @DaFrenchFrog ?

Oui je confirme. On a quand même une centaine de mot-clés distincts donc il faut au moins un tri par ordre alphabétique.

etalab / catalogage-donnees