Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OccTax : saisir un taxon en plusieurs points #475

Closed
Amegilla opened this issue Oct 16, 2018 · 19 comments
Closed

OccTax : saisir un taxon en plusieurs points #475

Amegilla opened this issue Oct 16, 2018 · 19 comments

Comments

@Amegilla
Copy link
Contributor

Je ne sais pas si le sujet a déjà été abordé mais cette approche serait très pratique dans certains cas.
On peut imaginer un mode de fonctionnement d'occtax où au lieu de saisir une localité et une liste d'espèces, on pourrait saisir une espèce en plusieurs points.
C'est une demande que des collègues naturalistes m'ont faite plusieurs fois car il leur arrive très souvent de noter le long d'un trajet plusieurs fois la même espèce (au chant en particulier). Cela permet de "remplir des mailles" efficacement mais peut être fastidieux à saisir. Et ce n'est pas vraiment un protocole.
Vous en pensez quoi ?

@gildeluermoz
Copy link
Contributor

C'est une idée à étudier car il peut y avoir des effets de bord et cela créé de la complexité.
Actuellement si tu crées un point et que tu cliques ailleurs, le point existant est supprimé et un nouveau point est créé à l'emplacement du click. Ça évite plein d'erreur de saisie. Notamment

  • créer involontairement deux points très éloignés car tu n'as pas vu que tu en avais déjà un ailleurs sur la carte
  • créer involontairement 2 points sans le vouloir (au même endroit sur un double click)
  • si l'utilisateur voit plusieurs taxons sur un relevé avec plusieurs points, tous les taxons sont présents sur tous les points et ce ne sera pas forcement l'intention.

Question :

  • Comment enregistrer les points (une geom multipoint ou dupliquer le relevé) pour chacun des points ?

Ce que tu proposes doit impérativement être une option permettant d'activer ou non ce comportement.
Dans l'absolu ce n'est probablement pas une énorme modif mais nous ne la développerons probablement nous mêmes (pas le besoin interne).
Si qq'un se sent de la développer, il faut impérativement une mise en paramètre pour que le comportement soit désactivable, et discuter de l'impact des modifs à envisager au delà de occtax (trigger, synthèse, etc...) Le module map est générique à tous les modules. C'est donc à discuter.

@DonovanMaillard
Copy link
Contributor

J'ai eu une demande relativement semblable, si ce n'est qu'elle est encore plus compliquée.

Il m'a été demandé si on pouvait :

  • Renseigner une date et son nom
  • Faire un relevé avec les 3 ou 4 espèces qu'on a vu.
  • Faire un second point avec ses 3 ou 4 espèces
  • Faire un 3eme avec ses espèces, etc etc

En fait c'est, dans ce cas, plusieurs relevés distincts, mais niveau interface, on ne valide pas et recommence pas des relevés à chaque fois, juste on les enchaine en conservant la date et le nom de l'observateur quand il veut saisir précisément et à la chaine ce qu'il a observé le long d'un sentier.

@camillemonchicourt
Copy link
Member

Oui je me demandais si ça devrait être intégré dans Occtax comme autre possibilité de saisie ou si il faudrait mieux en faire un module proche à côté.
Mais si le modèle de données est le même autant le mettre dans le même module.

Mais pas évident à saisir correctement.

Dans ce cas il faudrait carrément basculer sur un autre type de saisie dans le module pour éviter les confusions qu'evoque Gil et ne permettre qu'un taxon.

Par contre je pense que ça ferait plusieurs relevés
Je ferai pas un relevé multipoint

@camillemonchicourt
Copy link
Member

@DonovanMaillard, Tout ça juste pour pas renseigner 2 fois son nom et la date ?

@DonovanMaillard
Copy link
Contributor

et pas repointer un peu au pif un second point, puisque tu as le premier sous le nez et que tu peux retracer ta série de relevés. C'est un retour que j'ai eu, il semble que serena ait une fonction de ce type, qui soit appréciée

@gildeluermoz
Copy link
Contributor

Et un bouton enregistrer et dupliquer, ça le ferait pas ?
Le pb de la duplication c'est que tu ne sais pas ce que l'observateur veut réellement dupliquer. Donc tu duplique tout et à lui de modifier ce qui change (taxon, date, geom, etc...).
Mais il faut interdire l'enregistrement si rien n'a changé pour ne pas générer bêtement des doublons...

@Amegilla
Copy link
Contributor Author

Amegilla commented Oct 16, 2018

Pas mal cette idée de dupliquer, puisque dans mon cas le but c'est qu'il n'y ai que le point qui change. (même date, même observateur etc...).

@camillemonchicourt
Copy link
Member

Ouais faut voir.
A creuser plus tard car il faut avant tout que ça reste simple.

@Amegilla
Copy link
Contributor Author

Dupliquer est vraiment la meilleure solution sur tout les points, cela ne complexifie pas l'interface (1 bouton), c'est relativement facile à implémenter, et plus largement c'est une option qui permet d'accélérer la saisie de données. Je pense que c'est indispensable dans occtax :)

@laurentbarthe
Copy link

J'en rajoute une couche pour dire que je rejoins l'intérêt de l'outil et l'option proposée par @gildeluermoz de dupliquer la saisie précédente est parfaite. C'est cette solution qui avait été trouvée dans un outil similaire à Géonature.

@camillemonchicourt
Copy link
Member

Oui OK. A l'utilisateur de bien modifier tout ce qui est différent.

Si on fait une fonction Dupliquer alors on la mettra plutot au niveau de la liste des relevés Occtax et non pas au niveau de l'enregistrement d'un relevé.

@laurentbarthe
Copy link

Super. Hâte de tester cette option !

@camillemonchicourt
Copy link
Member

Il faut que quelqu'un la developpe d'abord. ☺

@gildeluermoz
Copy link
Contributor

Les deux, formulaire relevé + liste.

Côté formulaire c'est simple je pense.
Au click sur le bouton

  • Tu postes le formulaire
  • Au lieu de le fermer tu le conserves tel que
  • Tu désactives les 2 boutons d'enregistrement tant que rien ne change
    Côté liste
  • Tu charges le formulaire comme en edit mais sans les id
  • Puis même comportement que ci-dessus

Éventuellement une couleur ou un visuel spécial pour ne pas confondre avec l'édit classique.
Un paramètre pour désactiver tout ça au cas où. Car au final, les utilisateurs vont se jeter dessus et le taux d'erreur de saisie va exploser.
C'est trop facile de s'en servir pour enchaîner des saisies très différentes mais qui partagent seulement qq points communs, en oubliant de modifier qq points divergents.
Si tu veux des données propres tu désactives ça !

C'est kikissicol ?

@camillemonchicourt
Copy link
Member

Je suis pas pour du tout faire les 2. Uniquement au niveau de la liste. Ça laisse le plus de possibilités et ça reste léger.
Pas le mettre au niveau du formulaire car je trouve vraiment pas bien d'ajouter des boutons et des nouvelles options d'enregistrement qui compliquent la vie et la compréhension à tous au moment d'enregistrer leur relevé pour même pas 1% des cas.
Et ça alourdit les interfaces.
Là c'est pour dupliquer, ensuite ça sera pour ceci puis cela etc etc...
Et c'est important aussi d'avoir une fonctionnalité = une méthode d'accès à celle-ci.

Donc pour moi c'est important que ça soit juste au niveau de la liste avec l'icone COPY (https://fontawesome.com/icons/copy?style=regular)

C'est pamoikimicol :-)

Et on a beaucoup de choses à voir avant ça.

@DonovanMaillard
Copy link
Contributor

et le taux d'erreur de saisie va exploser.
Si tu veux des données propres tu désactives ça !

Je trouve vraiment pas ça pertinent de proposer la fonctionnalité si elle risque de fausser les données, ou de "perdre" l'utilisateur, qui ne saura pas s'il modifie une donnée, en crée une nouvelle, ou qu'il crée des choses qu'il ne veut pas créer e la sorte. Désactiver une fonctionnalité pour que les données soient propres, c'est un comble!

Je sais pas vraiment comment ce genre d'option peut se mettre en place,niveau interface... mais il doit y avoir une solution qui induit pas en erreur :)

@camillemonchicourt
Copy link
Member

Oui : un bouton Dupliquer depuis la liste uniquement.

@gildeluermoz
Copy link
Contributor

Ce que dis Donovan n'est pas en lien avec l'emplacement du bouton mais avec la pertinence de la fonctionnalité de duplication.

Je trouve que de mettre le bouton uniquement dans la liste des relevés n'est pas une bonne idée pour pls raisons :

  • le but de la fonctionnalité étant d'accélérer la saisie, ça t'oblige à un retour à la liste + s'assurer que tu choisis le bon relevé
  • le contexte principal de cet usage n'est pas de revenir sur un relevé enregistré par le passé mais d’enchaîner des relevés quasi équivalents
  • Tu peux te tromper de bouton lorsque tu veux éditer un relevé depuis la liste et dupliquer en croyant modifier.
  • S'il ne faut pas "alourdir" l'interface, un bouton de plus dans la liste ou dans le formulaire, c'est pareil.
  • Dupliquer depuis la liste peut permettre de dupliquer des obs anciennes et même si ça peut sembler pratique, c'est là que tu crée des risques d'erreurs (et ce besoin est marginal)
  • Avoir plusieurs entrées pour faire la même chose n'est pas un argument. Ca existe partout, y compris dans GeoNature. Il faut juste que ce soit clair pour l'utilisateur et facile d'accès (placé au bon endroit).

Au final je mettrais au contraire le bouton seulement coté formulaire. Le bouton peut en effet être très petit, bcp moins mis en avant et assorti d'un message toast de warning lorsque tu retombes dans le formulaire et que tu t'apprêtes à saisir le nouveau relevé dupliqué. Valeur par défaut : désactivé.

Donovan,
De mon point de vue, le but du paramètre permettant l'activation ou pas de la fonctionnalité c'est justement que chacun assume ses choix et la cohérence de son instance. Et la valeur par défaut (activé ou désactivé est importante). Toute option ou fonctionnalité supplémentaire a forcement des impacts sur l'ergonomie et la qualité des données. Effectivement il faut renoncer à celles qui seraient trop marginales, trop spécifiques ou de nature à créer des erreurs trop facilement. On veille à garder de la cohérence mais on ne peut pas rendre toutes les saisies totalement cohérentes si l'utilisateur y met du sien pour faire n'importe quoi.
Mais s'il y a un besoin partagé, il faut trouver ensemble la meilleure manière d'y répondre.
Cette discussion est là pour que chacun donne son avis en ayant un maximum d'info.

Mais effectivement la meilleure solution sera peut-être d'y renoncer et chacun comprendra pourquoi.

@camillemonchicourt
Copy link
Member

Pour répondre à ce besoin, pour le moment, la solution qui a été retenue, est de pouvoir enchaîner les relevés sans repasser par la liste et de récupérer une partie des infos du relevé précédent : #633

Intégré dans la 2.1.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants