Accélérer la saisie en permettant de mémoriser les dernières nomenclatures saisies

[DonovanMaillard]

Type d'amélioration Ergonomie - gain de temps

Proposition Lors des sessions de terrain, l'utilisateur enchaine souvent des observations similaires (même méthode de prospection, même groupes taxonomiques recherches, même stades de vie observés, mêmes méthodes de comptage etc...). Il devient alors souvent redondant de saisir les mêmes nomenclatures durant toute la session de terrain.

Il est proposé de mettre en place un mécanisme (activable ou non) permettant de stocker dans la mémoire cache la dernière nomenclature utilisée et la pré-charger automatiquement sur la saisie suivante.

• L'utilisateur peut choisir les champs à garder en mémoire ou non
• Ce fonctionnement s'applique exclusivement aux champs de nomenclature
• L'information est stockée temporairement dans la mémoire locale du terminal, et est perdue à chaque redémarrage de l'application
• Si la dernière nomenclature ne peut pas être chargée (changement de taxon etc), c'est la nomenclature par défaut de geonature qui est chargée comme aujourd'hui.

Pour sélectionner les champs à conserver, l'utilisateur dispose d'une icone en haut à droite des pages de formulaires (masquée ou non selon la configuration centralisée). Cette icone ouvre une modale qui liste les champs de nomenclature affichés dans le formulaire avec une checkbox pour sélectionner les champs à conserver entre deux saisies consécutives.

[gildeluermoz]

Plutôt qu'une modale à ouvrir et compléter, sans tjs avoir en mémoire le détail et le contenu de chacune des nomenclatures, je verrais plutôt un petit cadenas ouvert/fermé à côté de chacun des champs de nomenclature. Tu le verrouilles si tu penses que cette nomenclature va être répétée, tu le déverrouilles si besoin de changer le contenu rappelé par un précédent verrouillage. Ça me semblerait plus lisible et plus souple.

[DonovanMaillard]

Pas certain que ca soit le plus simple, car c'est une fonctionnalité qui n'est pas voulue par tout le monde et qui pourra être désactivée. par un paramètre. Devoir faire un composant material custom, qu'on utilise ou non selon la configuration, avec des inputs affichés différemment selon la conf risque de poser soucis.

Ca pose aussi la question de la taille des boutons sur le formulaire. On a déjà des composants plus petits et plus condensés sur la page que ce qu'on avait dans les versions antérieures à la 2.2 , si on doit rajouter une icone dans la largeur de l'écran j'ai peur des soucis d'affichage et des libellés tronqués sur les appareils les plus petits (comme on avait avec les boutons dont le libellé était trop long).

[cen-cgeier]

C'est également un retour que j'ai eu de nombreuses fois, surtout concernant la saisie des taxons. Je trouve l'idée très bonne.

Proposition taxon

• Garder en mémoire les derniers taxons saisies (une dizaine).
• Donner la possibilité de créer une liste de taxons restreintes dans la partie paramètre.

Si une liste est créée dans la partie paramètre, celle-ci s'affiche par défaut. Dans le cas contraire, la liste des 10 derniers taxons saisies est proposée. Dans tous les cas, la saisie d'un taxon dans la barre de recherche permet de filtrer la totalité de la liste affiliée à l'application.

Proposition nomenclature

• Ajouter un cadenas ouvrant/fermant à droite de l'intitulé de nomenclature.
• Un appuie long sur un champs de nomenclature verrouille/déverrouille la valeur affichée.
• Un appuie court sur un champs de nomenclature ouvre une modale et propose la liste des nomenclatures (si le champs est en position déverrouillé).
• Tous verrouillages s'annulent à la fermeture de l'application.

[DonovanMaillard]

Bonjour,

Pour la partie nomenclature l'appui long n'est pas toujours connu et compris par les utilisateurs (on le voit avec les suppressions), avoir quelque chose de visible a été préféré pour le moment.

Pour la partie taxon, garder les x derniers est une idée que j'ai deja entendue aussi oui. Mais ca n'est pas forcement pertinent/justifié sur tous les groupes taxonomique (arbres, pas mal d'oiseaux etc visibles toute l'année) et surtout nous souhaitons déjà mettre en place des listes paramétrées en fonction du jeu de données comme c'est le cas sur occtax Web. Gerer en parallèle des listes "custom" demanderait à être bien réfléchi, car ça viendrait interférer avec les listes par jdd.

Par exemple si un administrateur décide qu'on ne peut saisir que des poissons dans un jeu de donnees en particulier et que l'utilisateur vient charger une liste custom avec des plantes, ca n'est pas cohérent. Ca demanderait d'être bien défini en anticipant tous les cas de figures et les comportements des utilisateurs.

[DonovanMaillard]

Fait pour la partie "taxons" dans la version 2.4.0.

Sera implémenté dans la partie "dénombrement" (pour les nomenclatures de stade de vie, sexe, type de dénombrement...) en même temps que l'ajout des médias, dans une version à paraitre.

[DonovanMaillard]

Fait dans la version 2.5.0 publiée hier, au niveau des formulaires d'occurrences et de relevés. Fonctionnalité activable ou non par un paramètre dédié dans settings.ini (voir le fichier readme).

[camillemonchicourt]

Aperçu de la fonctionnalité :

Activable en ajoutant dans la config :

  "nomenclature": {
    "save_default_values": true
  },

Voir la doc dédiée : https://github.com/PnX-SI/gn_mobile_occtax#nomenclature-settings