Refonte formulaire Occtax

[jbrieuclp]

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

• une modification de l'ergonomie
• une optimisation de son interaction avec l'API en fractionnant les enregistrements.

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

• Première étape saisie des info localisation et relevé uniquement. Le bouton enregistrer fait une transaction avec l'API pour enregistrer cette première info. l'ID du relevé est récupéré.
  

• 2eme étape la saisie des occurrences/dénombrements s'affiche, ici 2 taxons ont déjà été saisies :
  

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 :

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

• comme pour le compte utilisateur, les éléments (localisation/relevé) ne sont pas éditable un bouton "editer" permet de passer en mode édition, ce bouton switch alors en bouton annuler enregistrer
  

• La localisation et le relevé sont toujours éditable, le formulaire est analysé, s'il est modifié ces boutons s'affiche pour permettre l'enregistrement. Le texte du bouton devrait être plutôt "Enregistrer les modifications du relevé"
  

• même fonctionnement en les plaçant ici
  

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 :

• enregistrement du relevé/localisation .
• modification du relevé/localisation
• ajout d'une occurrence/dénombrement
• modification d'une occurrence/dénombrement
• suppression d'une occurrence/dénombrement

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

[gildeluermoz]

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]

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]

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 :

• Papilio machacon :
  3-5 males imagos 1-4 femelles imago 1 indéterminé chenille
  Par exemple.
  L'intérêt de ca c'est qu'actuellement on sait qu'on a saisi l'espece mais c'est pas toujours facile de s'y retruver dans un relevé complet quand on a plusieurs dénombrements.

[DonovanMaillard]

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]

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]

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 :

• Form Relevé : ¼ d'un écran
• Carte localisation : 1/2 d'un écran pour être agréable au mieux/pire ¼
• Form Occurrence (1/4 seul) ½ avec les infos avancées + dénombrement
• liste taxons saisies : ¼ qui peut dérouler.

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.

• Carto gauche ouvert relevé droite -> puis réduction de la carto et saisie des occurrences dessous à gauche.
  
  
  

• Relevé gauche carto droite ouverte -> puis réduction de la carto et saisie des occurrences dessous à gauche.
  
  
  

• Relevé gauche ou droite et carto gauche ou droite ouverte -> puis fusion de la carto dans le relevé et saisie des occurrences à droite : ça peut être fun, le déplacement de la carte façon manège enchanté
  

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]

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]

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]

Ok

[TheoLechemia]

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

[jbrieuclp]

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]

Oui du coup, on converge sur cette proposition ?

• Il semble pertinent de garder la carte à gauche car c'est la première action demandée.
• Ensuite ça semble bien que tout le formulaire soit à droite pour ne pas faire des allers-retours entre chaque côté, et/ou une module au milieu
• Une fois qu'on a localisé le relevé, on n'a plus besoin que la carte soit si grande et donc c'est bien adapté que de construire la liste des taxons en grappillant sur celle-ci (en se limitant à maximum 50% de la hauteur du bloc de gauche)
• Comme pour les habitats et comme propose Donovan, ça permet d'avoir un peu plus d'info sur chaque taxon.

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]

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]

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]

@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]

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]

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]

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

[DonovanMaillard]

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]

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]

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]

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)

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

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

[camillemonchicourt]

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]

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

[DonovanMaillard]

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]

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]

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

[Amegilla]

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]

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]

merci Donovan, chouette tout ça !

[camillemonchicourt]

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 : #860 (comment) et à traiter dans des points dédiés.