search

PnX-SI / GeoNature

Application de saisie et de synthèse des observations faune et flore
GNU General Public License v3.0
99 stars 101 forks source link

Refonte formulaire Occtax #758

Closed jbrieuclp closed 3 years ago

jbrieuclp commented 4 years ago

J'ouvre ce ticket pour proposer deux modifications au niveau du formulaire occtax :

Pour l'ergonomie voici quelques screen d'une maquette :

Pour saisir une occurrence, le bouton "ajouter une taxon sur ce relevé" ne déroule pas le form, mais l'ouvre en modal pour ne pas surcharger la page principale : Image6 Image7

Pour revenir sur l'édition des infos relevé localisation plusieurs possibilités :

Perso cette 3eme solution est pour moi la plus logique : placer les boutons dans une zone neutre en lien avec le relevé et la localisation. Leur usage/compréhension est, je pense, plus logique.

Ces réarrangements permettent au passage d'optimiser l'interaction avec l'API en fractionnant l'enregistrement. Plus proche d'une API Rest, il y aurait alors une requête pour chacune de ces actions :

Les données sont alors enregistrées au fur et à mesure, ajoutant du coup plus de sécurité.

gildeluermoz commented 4 years ago

Il y a probablement des choses à retenir mais il faut avoir conscience que ce principe va générer des relevés sans occurrence dont il faut au préalable évaluer les conséquences (fonctionnement de l'interface, de la recherche par filtre, triggers, synthèse, validation, historisation) Plus accessoirement, je n'aime pas les saisies en popup et je ne vois pas bien l'intérêt. cela génère des manipulations supplémentaires et des niveaux de saisie emboités que je ne trouve pas plus ergonomique. Mais ce n'est qu'un avis personnel. Par contre de pouvoir replier le relevé (sur le coté ou en accordéon) pourquoi pas. Ca gagne de la place pour la suite mais cela retire de la lisibilité globale à la saisie (on a plus tout sous les yeux). A creuser.

camillemonchicourt commented 4 years ago

Oui je trouve aussi qu'il y a là de bonnes idées mais aussi des choses moins claires et ergonomiques, notamment la modale. Un autre ticket évoquait le fait de donner une meilleure place à la liste des taxons d'un relevé. Une première réflexion a été initiée et c'est en cours sur le module Occhab.

DonovanMaillard commented 4 years ago

Salut,

En effet j'avais ouvert un autre ticket, ou je proposais une révision du même type : #635

Quand j'ai saisi mes infos de relevé et qe j'attaque la saisie des occurrences, on diminue la carte qui prend la moitié de l'écran et ne sert plus à rien. Et ca offre une meilleure visibilité sur ce qui a été saisi dans le relevé. Dans ma tête (mais je peux pas aller plus loin que dans ma tête en termes de développement, mea culpa) j'allais même encore plus loin, puisque je détailais pour chaque espèce le nombre / sexe / stade :

DonovanMaillard commented 4 years ago

En revanche je suis pas très emballé par la pop-up non plus. Pas très cohérent je trouve d'avoir une partie de la saisie sur la page, et une partie en pop up.

jbdesbas commented 4 years ago

Salut, Le gros point positif pour la pop-up, c'est que ca focalise temporairement l'attention de l'utilisateur sur la description de son observation, en laissant de côté les histoires de JDD, dates, lieux, etc. Je trouve donc cette approche beaucoup plus intuitive.

L'approche "enregistrement des relevés et occurrence au fur et à mesure" est très intéressante pour l'utilisateur, quoique effectivement potentiellement lourde de conséquence coté backend. C'est une approche que nous avons en fonctionnement sur Clicnat, et qui est très appréciée des utilisateurs : en plus du côté sécuritaire en cas de plantage/déconnexion, elle permet aussi d’arrêter et reprendre une saisie en cours n'importe quand. Inversement, j'ai déjà eu des retours d'utilisateurs qui rageaient contre la base de nos voisins à cause d'une session expirée en cours d'une grosse saisie.. Peut-être pourrait-on simplement stocker les saisies en cours au sein du module occtax, et ne faire remonter les infos dans la synthèse que quand le relevé est validé ? On limiterai ainsi les conséquences sur le reste de la base.

jbrieuclp commented 4 years ago

Ouai, moi non plus je ne suis pas très fan des popup/modal, mais là on est confronté à manque de place évident lié à la quantité d'info qui doit être affichée et surtout lié à la taille du formulaire d'occurrence :

Avec ces ratios on voit que ça peut passer mais aussi déborder.

J'ai refait quelques maquettes en montrant la taille d'un écran et en ajoutant le sens de lecture des éléments de la page (les flèches bleus en trait plein = déplacement pour la saisie ; en pointillé : déplacement de la lecture). Pour ces maquettes je suis resté sur le principe de la saisie découpée.

Perso je trouve cohérent d'avoir un sens de saisie vertical, donc d'aligner le formulaire de relevé avec celui d'occurrence et d'éviter d'avoir un cheminement croisé saisie d'un concept à droite, d'un second à gauche ou inversement. La liste des taxons avec le formulaire occurrence peut aussi être inversée, mais je trouve que ça fait un sens de lecture inverse, droite->gauche peu logique. ("je saisie à droite pour placer des données à gauche, avant")

Enfin sur la questions des enregistrement au fur et à mesure, côté backend cela demande d'avoir 1 route spécifique, mais spécialisée (donc plus simple niveau code), pour l'enregistrement du relevé ou de l'occurrence.

j'ai déjà eu des retours d'utilisateurs qui rageaient contre la base de nos voisins à cause d'une session expirée en cours d'une grosse saisie.

Comme les transactions sont multipliées avec le serveur s'il y a déconnexion on s'en rend compte rapidement, contrairement à la transaction unique qui va chercher à enregistrer une saisie de 50 taxons en one shot où si ça plante, ben ça plante, il ne faut pas que le navigateur freeze... En fait ce fonctionnement se rapproche d'une API Rest qui multiplie les transactions avec le serveur pour récupérer des petits morceaux de page au fur et à mesure.

DonovanMaillard commented 4 years ago

Pourquoi ne pas laisser toute la saisie à droite et simplement un dataframe pour consulter ce qui est saisi, à gauche, sous la carte qui du coup peut passer un à tiers de la hauteur ?

Ca permet d'avoir à droite la saisie, et à gauche la localisation + les occurences, c'est à dire une vision globale de ce qui a été saisi. Ca me semble plus simple et avec une lecture intuitive.

camillemonchicourt commented 4 years ago

Ce qu'on avait prévu était de garder le formulaire de saisie linéaire à droite mais que la liste des taxons soient intégrées en bas à gauche, dans un bloc prenant sur la carte.

jbrieuclp commented 4 years ago

Ok

TheoLechemia commented 4 years ago

Pour aperçu, voilà à quoi ressemble la proposition de Donovan sur le module OccHab: occhab

jbrieuclp commented 4 years ago

Ouai, c'est bien plus cohérent d'avoir une partie visu, une partie formulaire. Et c'est encore plus cohérent d'avoir une cohérence (:D) sur l'ensemble des modules. Là le formulaire habitat est beaucoup moins gros que celui d'occurrence, donc tout rentre dans la fenêtre c'est top. Occurrence est plus petit si le bloc données avancées n'est pas ouvert.. Et s'il est ouvert on peut se permettre d'avoir l'ascenseur. Comme c'est le cas pour ce screen occ_hab il peut y avoir un gain de place pour le relevé en exploitant la partie laissée vide de la liste des taxons, permettant de remonter le reste.

camillemonchicourt commented 4 years ago

Oui du coup, on converge sur cette proposition ?

Concernant le fait d'enregistrer le relevé et de faire des envois en BDD réguliers, ça semble une bonne chose aussi pour les raisons évoquées. Mais c'est peut-être un autre sujet. Et il ne faut pas que cela complexe l'interface. Je pense pas qu'il faille ajouter un autre niveau d'enregistrement. Cela va complexifier pour l'utilisateur qui s'y perd un peu sur ce qu'il enregistre quand et ça peut créer de l'incertitude. On peut imaginer envoyer des POST dans la BDD (du relevé et des occurrences) de manière transparent à chaque fois que l'on clique sur "Ajouter un taxon". Et refaire un gros update de tout ça lors de l'Enregistrement final, au cas où l'utilisateur ait modifié quelque chose au niveau du relevé, de la localisation ou autre.

jbdesbas commented 4 years ago

On peut imaginer envoyer des POST dans la BDD (du relevé et des occurrences) de manière transparent à chaque fois que l'on clique sur "Ajouter un taxon". Et refaire un gros update de tout ça lors de l'Enregistrement final, au cas où l'utilisateur ait modifié quelque chose au niveau du relevé, de la localisation ou autre.

Si je comprend bien, tu veux que les occurrences sortent du module occtax alors même que l'utilisateur n'a pas fait "l'enregistrement final" ? Il faut être vigilant sur le fait que, tant que l'utilisateur n'a pas l'impression d'avoir valider l'ensemble de son relevé, il peut avoir l'impression d'être en "brouillon" (a nuancer selon comment est présenter l'interface). Même si tu n'es pas trop pour l'idée d'avoir plusieurs niveaux d'enregistrements, je trouve ça plutôt clair (du pt de vue de l'utilisateur) d'avoir un (plusieurs ?) relevé "En cours de saisie" qu'il peut compléter, annuler ou envoyer. Inversement je ne trouve pas plutôt confusant (coté admin et utilisateur) de commencer à faire remonter les infos dans la synthèse (et validation, etc..) alors que l'ensemble des taxons du relevé n'a pas encore été saisie.

Sinon OK pour l'idée de réduire la taille de la carte une fois la localisation effectuée.

jbrieuclp commented 4 years ago

L'idée principale était surtout d'apporter une sécurité quant à l'enregistrement d'un relevé complet et des données de manière globale. Donovan à fait remonter un bug #751 dont l'origine serait des chargements multiples de données taxref (?), j'ai moi même eu des retours d'utilisateurs ayant eu des enregistrements de relevés qui plantent après un moulinage du serveur.. (j'en connais pas la cause malgré l'exploitation des logs)

De fait découper les éléments évitent de tout charger/tout écraser (cad les infos de relevé, d'observateur, d'occurrences et de counting) à la moindre modification d'un élément.

Pour l'utilisateur c'est plutôt transparent, il suffirait de lui fournir au départ la carte et le formulaire relevé avec un bouton "enregistrer le relevé avant d'ajouter un taxon". La données de relevé est créée dans la BD (sans occurrence) mais rien ne rentre dans la synthèse tant qu'aucun dénombrement n'est enregistré. Le serveur renvoi la ressource du relevé créé et l'appli active le formulaire de saisie taxonomique (occurrence + dénombrement) Ensuite à chaque taxon ajouté la donnée est enregistrée en BD et restituée pour être placée dans la liste des taxons (si jamais ça plante pour une raison ou une autre l'utilisateur le sait de suite) Là la donnée d'occurrence est inscrite dans la synthèse.

Pour la synthèse ce n'est qu'une question de minutes (de temps de saisie) pour que toutes les données du relevé soient visibles.

La question de la modification des données du relevé après l'enregistrement initial est la plus délicate pour l'utilisateur. Mais il peut être possible de garder le formulaire de relevé et la carto en mode édition, tout en surveillant les données qui y sont : tant que rien n'est modifié rien ne se passe -simple. Par contre que faire si une modif intervient, il peut être possible de faire apparaître un bouton "enregistrer les modification apportées au relevé" tout en avertissant l'utilisateur qui changerait de page si ses modifications n'ont pas été sauvegardées.

Et refaire un gros update de tout ça lors de l'Enregistrement final, au cas où l'utilisateur ait modifié quelque chose au niveau du relevé, de la localisation ou autre.

Ce serait contre productif et on retomberait dans les problèmes initiaux. Plus il y a de données modifiées d'un coup, plus la BD va exécuter des triggers de mise à jour de la synthèse de manière simultanée (ou quasi) et niveau perf c'est pas ce qui est le mieux et on multiplie les sources de problèmes. Par contre seules les données relevé pourraient être (re)transmises dans ce cas, si modification il y a eu.

Pour info, par rapport au problème de stabilité, j'ai des utilisateurs qui créent un relevés avec quelques taxons qui enregistrent la donnée, qui reviennent dessus pour la compléter, réenregistrent, etc. Car ils ont déjà eu l'expérience de la grosse saisie perdue à cause un enregistrement mort. Un peu comme avec QGis dans sa grande époque "Pensez à enregistrer votre projet régulièrement. On sait jamais..."

camillemonchicourt commented 4 years ago

@jbdesbas, si on poste uniquement quand la personne clique sur VALIDER LE TAXON puis qu'on reposte tout à la fin, alors ça me semble coller. L'important selon moi est ne pas ajouter d'actions, de boutons, de complexification de l'interface qui offre déjà beaucoup d'actions.

camillemonchicourt commented 4 years ago

En effet, découper les enregistrements peut éviter certains problèmes et en régler d'autres. Mais certains bugs remontés ont d'autres causes. A creuser pour ne pas complexifier le module, avec des actions diverses et à différents niveaux. On souhaite garder le fait que l'application ne doive pas nécessiter de mode d'emploi. Et on est déjà proche de la limite.

Amegilla commented 4 years ago

Pour info, par rapport au problème de stabilité, j'ai des utilisateurs qui créent un relevés avec quelques taxons qui enregistrent la donnée, qui reviennent dessus pour la compléter, réenregistrent, etc. Car ils ont déjà eu l'expérience de la grosse saisie perdue à cause un enregistrement mort.

Pareil ici, j'ai eu bcp de retours négatifs de mes collègues qui ne pouvaient pas enregistrer leur relevé en cours car "déloggé" sans le savoir. J'avais pourtant réglé le timer du token à plusieurs heures. Donc +1 pour l'envoi en découpé :) , c'est d'ailleurs comme cela que fonctionnait notre précédent système.

TheoLechemia commented 4 years ago

Pour info, nous on a un token a 1 semaine...

DonovanMaillard commented 4 years ago

Merci théo pour cette proposition. Tu crois qu'il faut forcément une largeur fixe? Ou on peut imaginer des fenetres de taille flottante ? A l'usage, Yann dit que la carte ne sert à rien une fois le relevé localisé.

camillemonchicourt commented 4 years ago

A minima, on a prévu de reporter les évolutions ergonomiques d'Occhab dans Occtax, notamment la liste des taxons dans la partie de gauche (aperçu plus haut).

Si on veut vraiment séparer la partie RELEVE et la partie TAXONS, alors je ferai un système en 2 étapes, donc 2 onglets. Un pour RELEVE et un pour TAXONS. Quand on passe d'un onglet à l'autre, dans un sens ou dans l'autre, cela sauvegarde le RELEVE. Comme ça cela évite de devoir intégrer des actions de modifications et de garder une interface simple, encore plus simple même que l'actuelle. Car on aura une partie Carte/Relevé en plein écran et une partie Taxons/Denombrements en plein écran, sans perdre de place avec la carte etc quand on est sur l'onglet Taxons/Dénombrements.

Qu'en penses-tu @jbrieuclp ou as-tu des précisions sur ce que tu as prévu ?

jbrieuclp commented 4 years ago

Je trouve aussi le système à onglets ergonomique pour la saisie. Il permettrait de spécialiser l'interface (partie relevé et partie taxon) et d'alléger l'interface : plus de place pour moins de chose à l'écran. Nous étions parti sur ce principe pour l'interface de saisie du CBN et ça déroulait pour la saisie. Après la force d'angular fait qu'on va pouvoir modifier la position des différents composants les uns par rapport aux autres pour tester et trouver le meilleurs l'usage.

Actuellement il y a un unique service angular qui gère le formulaire occtax, j'ai prévu de scinder ce service et de créer un service par composant du formulaire (releve.service, occurrence.service...) ceci pour permettre de clarifier le code (!) et de rendre les différents components indépendants. Un form.service va gérer les paramètres commun au formulaire (digitiser, editionMode, valeur GET id_releve_occtax...)

jbrieuclp commented 4 years ago

J'ai pu avancer le travail sur la reprise de la saisie occtax, voici quelques photos d'écran : 2 onglets Saisie du relevé (peu de changement) P_20200225_121033

Au clique sur "Enregistrer" le relevé est créé en BD -> changement d'onglet automatique sur celui de la saisie des taxons : P_20200225_121001 P_20200225_121008 P_20200225_124914 P_20200225_124904

L'enregistrement en BD se fait à chaque creation/modification de taxon. Avec un retour au bloc de saisie du taxon à chaque fois

camillemonchicourt commented 4 years ago

OK super. Avec un système d'onglets comme ça en 2 étapes, la saisie est plus claire, on gagne beaucoup de place et donc de lisibilité et ça permet de fluidifier les enregistrements au fur et à mesure de la saisie.

jbrieuclp commented 4 years ago

Et on peut enchaîner les saisies à coup de TAB sans toucher à la souris

DonovanMaillard commented 4 years ago

Au top!! Pour pousser un peu plus loin encore, il serait utile que sous chaque espèce saisie on ait la possibilité de voir en 2 secondes les différents dénombrmeents inclus (x femelles adultes, y males juveniles" etc). Je vois des petits chevrons sur les onglets respectifs, c'est peut être déjà le cas?

Merci en tous cas pour cette proposition!

jbrieuclp commented 4 years ago

Yes ça permet de dérouler les infos du taxon. Le seul "prob" c'est qu'on réceptionne les ID des valeurs et non les libelles, donc il reste un petit travail à faire avec la mise en place un service qui permet de toper les libellés pour les afficher dans le détail à droite.

DonovanMaillard commented 4 years ago

Merci @jbrieuclp pour ce travail! S'il ne reste qu'à remplacer les id par les valeurs, c'est déjà top!

Amegilla commented 3 years ago

Hello,

Est-ce que ce serait envisageable de rajouter un champ de recherche pour le déroulant JDD, chez nous la liste devient très très longue :) ?

DonovanMaillard commented 3 years ago

au délà d'occtax, il y a des tickets pour améliorer le composant datasets de facon générale, sur tous les modules ;)

1049 notamment

Amegilla commented 3 years ago

merci Donovan, chouette tout ça !

camillemonchicourt commented 3 years ago

Refonte intégrée dans la version 2.5.0. Reste en suspens des questions et améliorations ergonomiques et fonctionnelles, concernant la possibilité d'annuler, les relevés sans taxons ou encore l'outil de paramétrage des valeurs de saisie, discutés dans la PR : https://github.com/PnX-SI/GeoNature/pull/860#issuecomment-680091992 et à traiter dans des points dédiés.