Remplacer le "rapport d'erreur" par un "rapport de l'import" ?

[DonovanMaillard]

Actuellement, les rapports pour les imports terminés ne sont disponibles que pour les imports avec erreurs.

A terme il pourrait être intéressant d'avoir un rapport pour l'ensemble des imports effectués, avec notamment le rapport d'erreur, mais aussi un résumé plus global :

• bbox de l'import, nombre de taxons, nombre de données, date min/max des observations importées, jeu de données, date d'import, nom du fichier etc. Ces infos sont déjà calculées soit pour la prévisualisation soit pour l'historique des imports.

[DonovanMaillard]

Je confirme cette volonté d'améliorer le rapport d'erreur actuel, au profit d'un rapport plus complet de l'import, téléchargeable et diffusable éventuellment, sur le même principe que les fiches métadonnées.

On pourrait alors y lister date d'import, jeu de données, nombre de données au total, nombre d'erreurs, nombre de données importées, carte avec bbox, et bien entendu un tableau synthétique qui liste les erreurs et le nombre de lignes concernées.

Sur le navigateur, on pourrait cliquer sur chacune des erreurs pour connaitre le détail des lignes concernées.

@camillemonchicourt @TheoLechemia @bouttier si vous avez des remarques ou questions avant qu'on commence :)

[mvergez]

Bonjour Donovan,

J'ai commencé à travailler sur cette issue et j'en suis arrivé à ce résultat :

Liste d'imports

Dans la liste des imports, la colonne "Rapport d'erreur" a été renommée en "Rapport" et 2 icônes sont visibles : une icône info s'il n'y a pas d'erreur et une warning s'il y en a (comme avant). Comme montré ci-dessous :

Rapport

Si on clique sur l'icône de la deuxième ligne (en erreur), on arrive sur l'url suivant /import/report/4 avec ce rapport :

Toutes les sections peuvent se replier sur elle même.

Si on clique sur la troisième ligne (sans erreurs), on arrive sur un url semblable /import/report/3 avec un rapport du même type :

Pour l'instant, il n'y a que le nombre de taxons et la carte. Si j'ajoute plus d'infos ce serait dans un tableau je pense mais j'ai peur que ça fasse trop lourd s'il y a beaucoup de données importées.

Que penses-tu de tout ça ?

[DonovanMaillard]

Bonjour,
Merci pour ces premières avancées. Je propose ci-dessous une révision de l'aspect du tout pour se rapprocher et se mettre en cohérence avec les fiches métadonnées. Il y a certains boutons/cadres qui ne seront pas présents dans un premier temps (notamment le cadre correspondances je pense, et le bouton "exporter les correspondances" qui attendront. Mais pour le reste je pense que l'essentiel des infos est déjà présente et qu'on est surtout sur de l'interface.

Pour la carte, je ne pense pas qu'il faille afficher toutes les données (peut être long sur les grands imports). Soit afficher une bbox, soit avoir un paramètre dans la configuration du module pour switcher d'un affiche à l'autre selon la volumétrie de l'import ?
Dev_import-Rapport_Imports.pdf

Pour la partie liste d'imports, le petit i remplacé par le warning selon qu'il y ait des erreurs ou non me semble très bien. Un temps il était question de remettre le bouton de téléchargement des données invalides dans cette liste... je pense qu'une fois qu'on aura une page de rapport ça ne sera plus utile, autant aller consulter toutes les infos avant de récupérer les données invalides.

[mvergez]

Bonjour Donovan,

Merci beaucoup pour ton retour. J'ai tenté de suivre le plus possible le pdf et voilà une capture du rapport d'import :

Pour l'instant, les trois boutons en haut à droite ne sont pas fonctionnels et il reste le mapping de la nomenclature (beaucoup plus complexe que je ne le pensais si j'essaie de toucher le moins possible au backend).

Je me suis permis de modifier les données du graphique par un top 10 (nombre modifiable) des espèces importées, je trouve cela peut-être plus cohérent que le groupe d'espèces (ex: 1 groupe d'espèces dans l'import rend le graphique peu utile).

J'ai néanmoins plusieurs questions :

• Je n'ai pas bien compris pourquoi tu voulais masquer la dernière colonne du tableau d'erreurs ? J'ai peur que cela nuise à l'expérience utilisateur
• Dans l'encart "Jeu de données" faut-il créer un lien pointant vers le descriptif du jeu de données dans le module Metadonnées ?
• Au sujet du rapport pdf, quelles sont les données que tu veux y voir écrites ?

Merci d'avance pour ton retour et n'hésite pas à me contacter directement si tu as besoin de plus d'informations.

[DonovanMaillard]

Merci Maxime,

Effectivement ça change ;)

Concernant le mapping des nomenclatures ce n'est pas prioritaire, si trop complexe on pourra l'envisager dans un second temps.

Concernant le top 10 ce n'est souvent pas pertinent puisque des imports peuvent comporter plusieurs centaines d'espèces communes pour lesquelles on a beaucoup de donnees. Le groupe 2 inpn n'est pas pertinent quand on a qu'un groupe en effet mais ca reste des cas assez rares et en cohérence avec ce qui est présent dans le module mtd.

Enfin pour le masquage du dernier champs, la raison est que sur un import a 13.000 lignes si j'en ai 1200 qui comportent 3 erreurs, j'ai un tableau très long et peu lisible in fine

[Adrien-Pajot]

Le groupe 2 inpn n'est pas pertinent quand on a qu'un groupe en effet mais ca reste des cas assez rares et en cohérence avec ce qui est présent dans le module mtd.

De notre côté au PNE, un JDD = un fournisseur de données, hors ceux-ci sont généralement très spécialisés. De fait le groupe INPN n'a en effet pas trop d'intérêt. Toutefois un tableau des espèces avec le nombre d'obs par espèces pourrait-il être pertinent plutôt qu'un top 10 ?

[jpanijel]

Pour ma part, je trouve que calquer visuellement le rapport d'erreur sur la fiche PDF de la métadonnée n'est pas une bonne idée.
Elle risque d'apporter de la confusion aux utilisateurs.

[camillemonchicourt]

C'est bien quand même d'avoir de la cohérence entre les différentes fiches web et PDF.
Le titre et le contenu diffèrent.

[DonovanMaillard]

Il me semble au contraire important d'avoir une cohérence au sein de GeoNature et ses modules dans la manière de représenter tel ou tel type d'information (emprises, répartitions taxo etc). Les fiches des jeux de données et les fiches des imports ayant toutes deux pour objectif de décrire un lot de données. Elles ont nécessairement une partie de leur contenu en commun et pour lequel la même représentation est cohérente, mais aussi des informations qui sont propres à chacune et sur lesquelles on peut jouer pour casser cette confusion.

Après échange avec @mvergez on confirme/propose les points suivants :

• La notion d'import est répétée dans l'ensemble des en-têtes de blocs
• Le cadre "Jeu de données" (en pied de page à droite de mon PDF) ne sera pas ajouté à la fiche d'imports (seul le nom du JDD en haut de la page sera cliquable avec un petit i à coté)
• Les blocs correspondances et erreurs etc sont propres aux imports donc limitent la confusion
• On va rajouter le triangle rouge "!" devant le titre "Données non importées - erreurs", qui va davantage mettre en avant cette information propre aux imports
• Au besoin, je me demande s'il ne faut pas aussi passer les boutons (actuellement en haut à droite) vers le bas à droite de la page ? (comme sur la synthèse ou les modules de saisie : d'abord on consulte, ensuite on exporte). à voir...

A noter aussi que pour trouver cette fiche, il faut aller dans le module d'imports et cliquer sur une icone dans la liste des imports pour en voir le détail. Ce qui pose davantage question c'est le pont qu'on crée entre les deux fiches en cliquant sur le nom du jeu de données depuis une fiche d'imports...

Ensuite, pour les questions de @Adrien-Pajot sur le graphique, je crée une issue dédiée (on va garder cette issue pour l'aspect global) car elle soulève d'autres questions sur les API GeoNature

[jpanijel]

C'est bien quand même d'avoir de la cohérence entre les différentes fiches web et PDF.
Le titre et le contenu diffèrent.

J'entends bien cet argument qui défend une vision projet, néanmoins l'approche utilisateur ne doit pas être oubliée et doit même prévaloir. Il est important (selon mon humble avis) de pouvoir clairement identifier dans quel module on se trouve. Il n'y a probablement pas grand chose à reprendre, mais telle quelle est présentée ici, on ne fait pas vraiment la distinction entre la fiche récapitulative avant import et la fiche de métadonnée, ce qui apporte de la confusion.
Je ne remets pas en cause le contenu proposé.

[DonovanMaillard]

Pour précision, il s'agit de la fiche de compte-rendu après import, pas de la phase de prévisualisation. L'idée est donc d'avoir accès en permanence au détail d'un import déjà effectué, ou de pouvoir en exporter la fiche PDF (dans notre cas au niveau régional, l'idée est de pouvoir exporter la fiche comme "preuve" et synthèse d'intégration des données des fournisseurs).

Peux-tu nous préciser les changements auxquels tu penses, de manière à garder une cohérence tout en n'entrainant pas de confusion?
De même, peux-tu regarder les tickets qui sont dans le projet "Evolutions Flavia/Natural" pour nous faire des retours si besoin avant que les développements soient lancés? C'est ce qui va prioriser les développements des prochains jours.

[TheoLechemia]

Je suis d'accord sur l'homogénéisation des UX.
Dans le cas 1 on a des blocs déroulants (contenu caché) avec un design type "material" et dans le deuxième cas des "carte" type "bootstrap" avec du contenu directement visible.
Je pense que pour l’expérience utilisateur cette homogénéité est aussi importante. A nous de trouver d'autres clés pour bien différencier les fiches import des fiches métadonnées. Cela peut se faire assez simplement avec un code couleur différents entre les deux modules.

[mvergez]

Bonjour,

Effectivement, je trouve qu'une homogénéisation est importante pour retrouver facilement l'information.
Exemple : tous les services de Google se ressemblent et l'utilisateur sait quelque soit l'application comment accéder à un compte, comment créer un nouvel événement dans l'agenda qui est très similaire à créer un nouveau mail par exemple...

Pour ce qui est du rapport, j'ai pu intégrer : l'export pdf et l'affichage de la correspondance des nomenclatures. Pour l'instant l'export des correspondances (aujourd'hui n'exporte que le mapping des champs mais pas les nomenclatures) et des identifiants est laissé en suspens.

[DonovanMaillard]

Dans la même logique que pour le rapport en ligne, Maxime a mis en place un export PDF sur le format suivant.

[DonovanMaillard]

Fait dans la version 1.2.0