Relevés en cours relevés vs non synchronisés #78
Comments
|
Je n'ai pas le même comportement. Par ailleurs on nous a demandé d'avoir aussi une liste des relevés terminés pour pouvoir aussi les modifier et supprimer |
|
L'idée est de pouvoir revenir en édition sur un relevé qui n'a pas encore été synchronisé (expédié sur GeoNature-web). Proposition d'interface (non basé sur la dernière version d'OccTax-Mobile): 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). Qu'en pensez-vous ? |
|
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. 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". |
|
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 :) |
|
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é... Je reviens également sur l'aspect édition d'un relevé en attente de synchro. 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. |
|
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. |
|
OK en discutant avec @PNPyrenees, il y a quand même un cas sur lequel porter attention :
|
|
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. |
A voir, j'aurai préféré éviter cela. |
|
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 ? |
|
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é). |
|
Ce qui est retenu suite à notre point du jour :
|
|
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é. |
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é.
The text was updated successfully, but these errors were encountered: