Enchaînement des écrans lors de la saisie

[sgrimault]

Actuellement, on a le cheminement suivant lors de l'édition d'un relevé :

flowchart TB
  subgraph step1 [Étape 1]
    direction TB
    obs("Observateurs")
    date("Date")
    comment("Commentaire")
  end
  obs_list("Choix des observateurs")
  obs -.-> obs_list
  subgraph step2 [Étape 2]
    geo_map("Carte")
  end
  subgraph step3 [Étape 3 : Choix du taxon]
    taxa_list("Liste des taxons")
  end
  taxa_filter("Filtres")
  taxa_list -.-> taxa_filter
  subgraph step4 [Étape 4]
    info("Informations")
  end
  subgraph step5 [Étape 5]
    counting_list("Dénombrements")
  end
  counting_edit("Ajout / édition\nd'un dénombrement")
  counting_list -.-> counting_edit
  subgraph step6 [Étape 6 : Bilan]
    taxa_added("Taxons ajoutés")
  end
  step1 ==>|Suivant|step2 ==>|Suivant|step3 ==>|Suivant|step4 ==>|Suivant|step5 ==>|Suivant|step6 ==>|Terminer|finish(("Retour à la\n page d'accueil"))

L'étape 3 est particulière car on ajoute un taxon qui va déterminer les étape 4 et 5 ("Informations" et "Dénombrement"). L'étape 5 est particulière aussi car on ajoute un dénombrement sur le taxon en cours de saisie (celui ajouté à l'étape 3). Ce point a fait l'objet de plusieurs demandes du fait qu'on rentre implicitement dans une imbrication dans le parcours de saisie (cf. #59, #114, #132).

Voici le "vrai" cheminement actuellement dans l'application si on devait le matérialiser, en tenant compte des spécificités des étapes 3 et 5 :

flowchart TB
  subgraph step1 [Étape 1]
    direction TB
    obs("Observateurs")
    date("Date")
    comment("Commentaire")
  end
  obs_list("Choix des observateurs")
  obs -.-> obs_list
  subgraph step2 [Étape 2]
    geo_map("Carte")
  end
  subgraph step3 [Étape 3 : Choix du taxon]
    taxa_list("Liste des taxons")
    taxa_filter("Filtres")
    taxa_list -.-> taxa_filter
    subgraph step3_1 [Étape 4]
      info("Informations")
    end
    taxa_list -->|Sélection du taxon|step3_1
    subgraph step3_2 [Étape 5]
      counting_list("Dénombrements")
      counting_edit("Ajout / édition\nd'un dénombrement")
      counting_list -.-> counting_edit
    end
    step3_1 ==>|Suivant|step3_2
  end
  subgraph step6 [Étape 6 : Bilan]
    taxa_added("Taxons ajoutés")
  end
  step1 ==>|Suivant|step2 ==>|Suivant|step3
  step3_2 ==>|Suivant|step6 ==>|Terminer|finish(("Retour à la\n page d'accueil"))

Suite aux demandes suivantes concernant diverses améliorations sur les étapes 5 et 6, je propose donc de scinder l'étape 6 pour distinguer les taxons ajoutés au relevés du bilan de la saisie, afin notamment de présenter à nouveau à l'utilisateur la date et le commentaire sur le relevé avant de le terminer. La liste des taxons ajoutés devient donc une étape à part entière qui permettra à l'utilisateur de savoir où il en est quand il reprend un relevé en cours (qui peut potentiellement avoir déjà plusieurs taxons ajoutés). Ce qui donne ce nouveau cheminement :

flowchart TB
  subgraph step1 [Étape 1]
    direction TB
    obs("Observateurs")
    date("Date")
    comment("Commentaire")
  end
  obs_list("Choix des observateurs")
  obs -.-> obs_list
  subgraph step2 [Étape 2]
    geo_map("Carte")
  end
  subgraph step3 [Étape 3 : Choix du taxon]
    taxa_list("Liste des taxons")
    taxa_filter("Filtres")
    taxa_list -.-> taxa_filter
    taxa_added("Taxons ajoutés")
    subgraph step3_1 [Étape 4]
      info("Informations")
    end
    taxa_list -->|Sélection d'un taxon|step3_1
    subgraph step3_2 [Étape 5]
      counting_list("Dénombrements")
      counting_edit("Ajout / édition\nd'un dénombrement")
      counting_list -.-> counting_edit
    end
    taxa_added -->|Ajout d'un taxon|taxa_list
    taxa_added -->|Sélection d'un taxon|step3_1
    step3_1 ==>|Suivant|step3_2 ==>|Suivant|taxa_added
  end
  step1 ==>|Suivant|step2 ==>|Si aucun taxon n'a été ajouté|taxa_list
  step2 ==>|Si au moins un taxon a été ajouté|taxa_added
  subgraph step6 [Étape 6 : Bilan]
    step_date("Date")
    step6_comment("Commentaire")
  end
  taxa_added ==>|Suivant|step6 ==>|Terminer|finish(("Retour à la\n page d'accueil"))

[DonovanMaillard]

Merci Sébastien pour ton regard et la réfléxion sur ce sujet qui mérite disccusion.

A mon sens, la priorité principale pour Occtax-mobile est de permettre une saisie rapide en conciliant des données rapides à entrer, mais complètes et avec une interface lisible/light pour l'utilisateur. D'une manière générale, je cherche donc plutôt comment supprimer des pages, ou comment retirer/condenser des informations sur les pages existantes, pour que l'utilisateur se concentre sur l'essentiel tout en pouvant saisir des données complètes et précises s'il le souhaite.

Ajouter une étape ou une interface en fin de saisie pour contrôler les infos saisies à l'étape 1 ne me convainc par du tout à ce stade, là où cette vérification reste pertinente pour les taxons car on fait des allers-retours dans la liste pour les ajouter un à un, et il faut rapidement pouvoir vérifier si la liste est complète. Pour moi, si on veut pouvoir revenir sur des infos saisies auparavant, pour les contrôler ou les modifier, il faut plutôt rendre plus facile la navigation entre les étapes (relevé, zonage, liste des taxons saisis etc) via un fil d'ariane ou un système de slide entre les étapes (déjà un peu en place mais peu intuitif et visible à ce stade).

[DonovanMaillard]

Après échanges de vive voix avec @sgrimault et @camillemonchicourt , nous avons pu clarifier la proposition de sébastien qui permet d'apporter un certain nombre de simplifications au niveau développements et maintenance, en améliorant l'expérience utilisateur. Nous allons donc mettre en oeuvre cette proposition, avec pour conséquence :

1. D'un point de vue "conceptuel", l'étape 6 (bilan de la saisie) n'est plus une étape de fin mais devient une étape "3a" qui s'interpose au début de la saisie, avant l'interface d'ajout d'un taxon. Comme les étapes 3 à 6 sont répétées de manière cyclique quand on saisit plusieurs taxons, le seul impact est que la boucle "commence à un endroit différent", c'est donc transparent pour l'utilisateur et n'ajoute pas d'étapes lors de la saisie.
2. Pour l'utilisateur, très peu de différences : lors de la saisie d'un premier taxon, il passe directement de la carte à l'ajout d'un taxon (le bilan - qui est intercalé - est sauté si aucun taxon n'est déjà saisi), puis au dénombrement, puis retombe sur le bilan qui propose d'ajouter un taxon et ainsi de suite. Rien ne change à ce stade.
3. En revanche si on vient modifier un relevé en cours, alors ça règle un soucis actuel pour l'utilisateur : après la carte, il est renvoyé directement sur le bilan de ce qui est déjà saisi, avant de pouvoir compléter son relevé (avant, il devait deviner ce qui était déjà saisi ou non), puisque le bilan est intercalé avant la saisie
4. En termes de développement, cela permet de factoriser plus facilement un certain nombre de composants, en enrichissant le bilan qui existe actuellement. Cela va notamment permettre de profiter du filtre des taxons (actuellement disponible pour la saisie d'un nouveau taxon) dès l'interface de bilan : on pourra donc filtrer les taxons saisis pour faciliter la vérification de ce qui a été enregistré. Ca va également permettre de faciliter l'ajout du nom vernaculaire, et de détailler davantage les dénombrements etc.

Un travail global est donc lancé désormais, pour intégrer la proposition ci-dessous tout en répondant aux tickets #153, #166 , #167 , #171

[AudreyEnGuyane]

Retour de terrain de mes gars (et suggestion): si les observations sont faites au cours d'un déplacement, le temps de passer le premier écran et d'arriver à la saisie carto, le point les passé. Suggestion: étape 1: pointage de carte, étape 2: observateurs/date/cadre/commentaire ?

[camillemonchicourt]

En effet, on pourrait faire plus comme sur Occtax-web, commencer par localiser l'observation sur la carte, ça me semble plus pertinent et logique en effet.

[DonovanMaillard]

Plus pertinent ou non j'ai pas d'avis, en soit ca marche bien dans les deux cas. Mais du coup aucun inconvénients à inverser les deux en effet :)