PnX-SI / gn_mobile_occtax

Application mobile pour la saisie dans le module Occtax de GeoNature
GNU General Public License v3.0
13 stars 5 forks source link

Relevés en cours relevés vs non synchronisés #78

Closed amandine-sahl closed 1 year ago

amandine-sahl commented 3 years ago

A partir du moment ou un dénombrement est ajouté, le relevé apparait dans relevé non synchronisé et plus dans relevés en cours. Je ne sais pas si cela est voulu, mais j'aurai eu tendance à penser que tant qu'un relevé n'est pas synchronisé il s'affiche dans relevé en cours (ce qui permettrai de rajouter un taxon ou un dénombrement) et qu'il disparaisse de relevé en cours une fois synchronisé.

camillemonchicourt commented 3 years ago

Je n'ai pas le même comportement. Tant que le relevé n'est pas terminé, il est bien dans les relevés en cours.

Par ailleurs on nous a demandé d'avoir aussi une liste des relevés terminés pour pouvoir aussi les modifier et supprimer

PNPyrenees commented 2 years ago

L'idée est de pouvoir revenir en édition sur un relevé qui n'a pas encore été synchronisé (expédié sur GeoNature-web). L'affichage en deux onglets pourrait permettre de facilement identifier les relevés en cours de saisie de ceux en attente de synchronisation.

Proposition d'interface (non basé sur la dernière version d'OccTax-Mobile): image

Appuyer sur un élément de la liste des relevés en attente de synchro ouvrirait le formulaire de saisie tel que c'est le cas actuellement pour les relevés en attente de synchro.

Par contre, j'imagine un système d'alerte dans le cas de l'édition d'un relevé en "attente de synchro" qui ne serait pas menée jusqu'au bout. Plutôt que de le passer en "relevé en cours", je pencherais pour un message d'alerte informant l'utilisateur que l'édition n'est pas arrivé au terme et que les modifications ne seront pas sauvegardées (confirmer? oui/non). Si je fais cette proposition c'est pour éviter de se perdre avec des relevés "en attente" qui passerait à "en cours" à cause d'une erreur de manipulation. De plus si l’utilisateur souhaite annuler l’édition en cours, il ne faut pas que les modifications soient conservées.

Qu'en pensez-vous ?

camillemonchicourt commented 2 years ago

Voici ce qui est prévu :

Permettre de lister et filtrer les relevés listés en page d’accueil selon leur statut (en cours ou à synchroniser) de façon à pouvoir modifier un relevé terminé et prêt à être synchronisé


Pour l'affichage, je privilégierait plutôt 2 listes, l'un sous l'autre, plutôt que des onglets, pas toujours évidents en mobile. J'ajouterai un compteur indiquant le nombre de relevés en cours et le nombre de relevés terminés, au niveau du titre de chaque bloc :

Relevés en cours (3)

Relevés terminés, à synchroniser (2)


Je ne suis pas certain que l'on doive complexifier avec la possibilité d'annuler ou de devoir terminer une modification. Dès que je rentre dans un relevé terminé, tout ce que je modifie est directement enregistré, que j'aille au bout ou non. Comme c'est le cas d'une nouvelle saisie, tout s'enregistre au fur et à mesure. Un relevé terminé, ne repasserait donc jamais en "En cours".

DonovanMaillard commented 2 years ago

Merci à vous deux,

est ce qu'il faut forcément expliciter/écrire le statut sur l'interface ? Est-ce qu'une pastille (verte/orange) en fonction du statut du relevé ne pourrait pas suffire , je pense que ça serait très vite compris.

Ca permettrait aussi de conserver les relevés dans l'ordre de création, pour faciliter le fait de retrouver le relevé qu'on veut venir éditer, et donc on ne se souvient pas forcément du statut

Si non, en effet la proposition de Camille nous évitera bien des soucis d'affichage selon les tailles d'écrans :)

PNPyrenees commented 2 years ago

J'ai du mal à savoir ce qui serait le mieux... Si les onglets sur appli mobile ne sont pas pratique alors il nous faut autre chose, pas de souci... Pour moi, l'idée de la pastille, tant que ce n'est pas expliqué on peut se demander à quoi ça correspond. Pour les listes, l'une à la suite de l'autre, j'ai peur que ça fasse tassé... Il me semble qu'il nous faudrait un avis/proposition développeur qui prend en compte le volet technique et ergonomique.


Je reviens également sur l'aspect édition d'un relevé en attente de synchro. Je me suis posé la question de comment va réagir la synchro si on lui envoi un relevé en attente de synchro qu'on a commencé à éditer ? Par exemple en ajoutant un taxon mais sans y inscrire de dénombrement associé.

Je me suis dit qu'il y avait un risque potentiel de bug. Si on synchronise pas les relevés en cours de saisie je me suis dit qu'il devait y avoir une raison.

camillemonchicourt commented 2 years ago

Je trouve que 2 blocs l'un sous l'autre est simple, clair et y en aura jamais 200, donc je vois pas pourquoi ça serait "tassé" ? Ca sera une liste scrollable, pas différente de l'actuelle, mais avec 2 listes.


Le cas que tu indiques ne se posera pas. Les relevés en cours actuels ne changent pas. Un relevé ayant un taxon sans dénombrement, ne peut pas être terminé, et donc restera toujours "RELEVÉS EN COURS" tant qu'il n'a pas été saisi complètement.

camillemonchicourt commented 2 years ago

OK en discutant avec @PNPyrenees, il y a quand même un cas sur lequel porter attention :

DonovanMaillard commented 2 years ago

Pour moi,un relevé dont la saisie n'est pas terminé ne doit pas être terminé. Dans l'exemple que tu cites il revient donc "en cours".

A mon avis, il faut un mécanisme qui dit "j'appuie sur terminer, mon relevé est terminé. Si je le ré-ouvre, il repasse en mode édition, et je dois cliquer sur terminer à nouveau".

Les 2 blocs sont très bien niveau ergonomie, je me demandais juste s'il fallait être si explicite... mais vu que ca conditionne si un relevé peut être synchronisé ou non, Camille a sans doute raison de privilégier 2 blocs.

Le seul truc qui me pose soucis (mais c'est déjà le cas actuellement), c'est quand on a 5 ou 6 relevés et qu'on veut en modifier un fait quelques heures plus tôt par exemple. Il est difficile de retrouver celui qu'on veut modifier. Ca sera possible avec l'affichage carte, mais il faudrait réussir aussi à le faire au niveau de la liste, soit en indiquant l'horaire par exemple, soit le nombre de taxons... mais c'est un sujet un peu différent qui sera discuté à part pour ne pas avoir 5 points sur un ticket.

camillemonchicourt commented 2 years ago

A mon avis, il faut un mécanisme qui dit "j'appuie sur terminer, mon relevé est terminé. Si je le ré-ouvre, il repasse en mode édition, et je dois cliquer sur terminer à nouveau".

A voir, j'aurai préféré éviter cela. Si je modifie un relevé terminé, je change une nomenclature, ou ajoute un commentaire par exemple, et que je reviens en arrière, dommage que ce relevé passe en statut "EN COURS", non ? Mais pourquoi pas, si c'est le plus simple et cohérent pour l'utilisateur.

PNPyrenees commented 2 years ago

Et si par erreur de manipulation, j'entre en édition dans un relevé en "attende de synchro", il faudrait éviter qu'il bascule en "En cours".

J'ai du mal à y voir autre chose qu'un détecteur de changement avec message d'alerte "attention, vous aller perdre vos modif !" si l'utilisateur sort du relevé en faisant des précédents. Mais sous condition de faisabilité dans le temps estimé.


L'ajout de l'heure me semble intéressante pour faciliter l'identification des relevés saisies. Pour le nombre de taxon, c'est le cas sur ma version 2.0.1, c'est plus le cas dans les nouvelles ?

DonovanMaillard commented 2 years ago

L'inconvénient de votre proposition, c'est que l'utilisateur n'aura pas réellement la main sur le statut de son relevé... une fois terminé une fois, il sera terminé même s'il retourne modifier plusieurs fois et donc il est synchronisable à la prochaine synchro.

Une fois que les utilisateurs sauront qu'ils peuvent modifier tous les relevés même terminés, ils sont susceptibles de quitter, revenir, quitter plusieurs fois. Et ne pas comprendre pourquoi d'un coup le relevé est parti alors qu'ils auraient voulu le garder en cours ?

Qu'on fasse comme ça ou non - il faut un truc qui permette de trouver rapidement les saisies pas terminées. Si on a 20 taxons, c'est difficile actuellement d'aller voir le quel n'a pas de dénombrement par exemple, et donc de savoir ce qui bloque l'enregistrement (et il faut d'ailleurs savoir que l'absence de dénombrement bloque le relevé).

DonovanMaillard commented 2 years ago

Ce qui est retenu suite à notre point du jour :

DonovanMaillard commented 1 year ago

La version 2.5.0 publiée permet désormais de reprendre et modifier des relevés "terminés", jusqu'à ce qu'ils soient synchronisés.

Par conséquent, tout relevé présent sur l'application mobile reste modifiable jusqu'à ce qu'il soit posté.