Closed Volubyl closed 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
@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 ?
J'ai modifié le ticket suite à la question qui m'était posée.
@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".
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 ?
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 :
@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.
Ce ticket sera fermé quand la PR #213 sera mergée.
@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 :
Mon intention initiale est de favoriser l'utilisation de balises html 5 pour implémenter des fonctionalités UI.
J'y vois plusieurs avantages :
Au niveau implémentation je suis donc parti sur l'utilisation des datalist
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
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.
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.
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 :
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
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 ?
@johanricher que penses tu de la propal de @DaFrenchFrog ?
@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 ?
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.
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
Implémentation
Fonctionnel :
Tag
)Itération 1
Résumé : gestion des mots-clés d'une fiche, recherche/autocomplétion basique
DB :
Dataset 0:n --- 0:n Tag
(M2M)Dataset (id) --> DatasetTag (dataset_id, tag_id) <-- Tag (id)
API :
GET /tags/
qui renvoie uneList[{id, name}]
POST /datasets/
: accepter un champtags: List[ID]
PUT /datasets/:id/
: accepter un champtags: List[ID]
(utilisé pour remplacer la liste entière, pas de système de diff ajouts/suppressions)Front :
Itération 2
Résumé : tri de mots-clés par popularité, recherche/autocomplétion en DB (plus robuste, plus scalable)
API :
count
des datasets qui ont ce tagGET /tags/
parcount DESC
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étionFutures améliorations