Plateforme de démo de l'API

[lpofredc]

Une démo de l'API documentée par swagger (via la lib python flasgger) est disponible ici:
http://v2327.phpnet.fr:5001/apidocs/

[lpofredc]

Et voici les premiers éléments de frontend en cours de dev:
http://v2327.phpnet.fr:4200

[lpofredc]

n.b., images des programmes aléatoires depuis une api le temps de développer l'outil d'intégration des médias pour les programmes.

[camillemonchicourt]

Merci, justement j'allai te demande.
Ca prend forme !

[lpofredc]

Nouvelle adresse pour la démo de frontend en cours de dev :
http://geonature-citizen-demo.dbwildlife.info/
A envisager: un rattachement au domaine geonature.fr (demo-citizen.geonature.fr) ?

[lpofredc]

Une première révision de la page d'accueuil ainsi que des formulaires de connexion et d'inscription a été réalisé par @patkap de @naturalsolutions.
Elle est visible sur le site de démo:
http://geonature-citizen-demo.dbwildlife.info/

[lpofredc]

Pour la suite, il faudra remplacer la librairie carto Google Maps par Leaflet.

[ghost]

Il s'agit, en fait, d'une l'intégration de la talentueuse @Naomi-Fischer

[samuelpriou]

Merci !
Ça donne envie de s'y mettre !

[camillemonchicourt]

Oui c'est joli, mais y a des points discutables, ou à adapter en fonction du contexte, voir #6 (comment)

• Au-delà des jolies photos, il est important d'avoir un espace avec un propos introductif.
• Quand on est sur la page d'un programme, il faut afficher en intro, le texte de présentation du programme, présent dans la BDD.
• Les blocs Espèces du moment et 7 dernières observations ne seront pas adaptés à tous les programmes (par exemple si on a très peu de données, si on est que sur une ou 2 espèces...)
• Quand on arrive sur un programme, il est surtout important de rapidement comprendre en quoi le programme consiste. Et de rapidement pouvoir consulter tous les données qui y sont présentes (filtrables par date, espèce...) pour ensuite proposer de contribuer. Comme sur https://urbangene.heig-vd.ch/

Il est important de commencer par se concentrer sur l'essentiel et le cœur du fonctionnement.

[lpofredc]

Bonjour,

Je rejoins les remarques de @camillemonchicourt.

• Concernant la présentation du programme, il y a deux champs dans la table programme en bdd, l'un est une description courte dont l'usage était de présenter succinctement le programme dans la liste des programmes, le second plus complet à afficher une fois sur le programme. J'imaginais bien un modal à l'ouverture du programme qui affiche la description du programme avec une option "ne plus afficher" dont le choix serait sauvegardé dans un localStorage. Aussi, il peut être intéressant d'avoir à la fermeture de ce modal les instructions de fonctionnement de la page en superposition (overlay) comme sur cette démo: chardin.js

• Blocs espèces > blocs optionnels?

• Bloc des dernières contributions, pour anticiper le module mares (plus généralement sites), produire une url d'api qui générera une union des différents types de données saisies (observations d'espèce mais aussi de sites).

[samuelpriou]

Bonjour,
Effectivement l'espace introductif est important. Les deux champs dans la table programme sont du coup bien pensés et le modal à l'ouverture du programme qui affiche la description du programme avec une option "ne plus afficher" est également à retenir.
Encore une bonne idée avec une explication du fonctionnement de la page comme expliqué par @lpofredc avec https://heelhook.github.io/chardin.js/.
Merci !

[camillemonchicourt]

RAPPEL DES BASES :

• Si j'ai plusieurs programmes, la HOME affiche les différents programmes (images, titre, description) puis j'arrive sur la page du PROGRAMME
• Si je n'ai qu'un programme, la HOME est directement la page du programme qui inclut : Titre, Image, Description, Carte et liste des observations existantes + Lien pour contribuer (avec ou sans authentification)

[Naomi-Fischer]

Bonjour,
Comme les descriptions des programmes n'ont pas été prévues sur les maquettes, nous avons fait quelques essais.
Pour ce qui est de la modale à l'ouverture du programme, cela risque de nuire à l’expérience utilisateur, le nombre de modales étant déjà assez élevé... à voir.
Faites nous savoir ce que vous pensez des propositions, qui ne sont bien sûr pas encore étoffées.
Merci d'avance

[samuelpriou]

Oui c'est bien comme cela. On distingue correctement les différents programmes (images, titre, description) puis lorsque l'on arrive sur la page du programme on peut en cliquant sur "En savoir plus" avoir davantage d'informations.

[camillemonchicourt]

Je crois qu'on se perd un peu.

Pour moi les dernières maquettes proposées correspondent à la maquette d'une page d'un programme.
Si je n'ai qu'un programme alors il s'agit directement de la page d'accueil.
Si j'ai plusieurs programmes, alors la page d'accueil propose en amont de choisir parmi les différents programmes.

Ici dans la deuxième maquette, il semble s'agir de la page d'accueil quand on a plusieurs programmes. Mais alors à quoi correspond la carte ? On ne peut pas proposer une carte regroupant les données des différents programmes. Ça n'a pas vraiment de sens me semble t-il.
On voit une carte avec des données, une fois qu'on est dans un programme.

Par contre quand on est dans un programme, ça me semblait bien d'avoir une approche un peu graphique et éditoriale comme proposé dans les maquettes précédentes, et pas seulement une carte avec un tooltip EN SAVOIR PLUS.

Concernant les modales et le module d'aide type chardin.js, je pense qu'on n'en est pas encore là en effet.

Donc pour revenir aux bases et au regard des différentes maquettes, voila ce que je proposerai :

PAGE D'UN PROGRAMME :

• BLOC 1 (si un seul programme uniquement) : Texte d'introduction présentant le portail de collecte citoyenne (Bienvenue sur le portail collaboratif du PnMercantour, blablabla...)
• BLOC 2 : Visuel et texte d'introduction présentant le programme
• BLOC 3 (optionnel, activable selon le type de programme) : Espèces du moment
• BLOC 4 : Carte-Liste filtrable des observations existantes dans le programme
• BLOC 5 (Optionnel) : Carte-Liste des dernières observations (à la place du bloc 4 ?)
• Bouton pour contribuer au programme >> Éventuelle authentification >> Formulaire de saisie d'une observation dans le programme

Si j'ai plusieurs programmes :

• Le texte de bienvenue se retrouve sur la page d'accueil et non plus sur la page du programme unique
• Titre, visuel et intro des différents programmes pour pouvoir en choisir un
• Faut-il avoir plutôt ici des données transversales à tous les programmes (Espèces du moment tous programmes confondus ? Dernières observations tous programmes confondus ?) plutôt que de les retrouver dans chaque programme. Ça se discute, mais ces aspects n'ont pas encore l'air bien clair.

[lpofredc]

Nouvelle mise à jour de la démo de développement suite au PR #29 proposé par l'équipe de @naturalsolutions.

https://geonature-citizen-demo.dbwildlife.info/

[camillemonchicourt]

Oui, du coup, je proposerai bien de commencer par le développement de la page d'un programme (Image et description du programme / Carte-liste des données du programme / Formulaire de contribution sans authentification).

On aurait ainsi le socle pour avancer sur la suite (Page d'accueil quand on a plusieurs programmes PUIS Contribution avec authentification PUIS Mon compte PUIS Badges)

[orovellotti]

Bonjour à tous

Est ce que tous le monde est ok là dessus?

Merci

[lpofredc]

Bonjour à tous,

Pour faire suite à cet échange, voici ce qui a été convenu cette semaine avec @naturalsolutions pour le phasage du développement.

PRIORITE 1 / Structure du coeur de la plateforme

Se concentrer sur les fonctionnalités pour ensuite travailler sur le maquettage.

Deux cas de figure:

• 1 seul programme > on zappe le home:
  • redirection auto (guard dans le router du frontend) avec:
    • intro de la plateforme sur la page (bloc 1),
    • intro du programme (bloc2, à la place du bloc espèces du moment)
    • carte/liste du programme pour voir et participer (bloc3).
• plus de 1 programme > fait office de home:
  • une page avec l'intro de la plateforme sur la page (bloc 1)
  • liste des programmes (bloc2) et la page programme contient donc:
    • intro du programme (bloc1, à la place du bloc espèces du moment)
    • carte/liste du programme pour voir et participer (bloc2).

Contenu

Contenu de la page programme

• un seul bloc image description du programme (chapeau) et en savoir plus.
• le bloc carte/liste des données avec filtrage sur commune (API de liste des communes d’un programme à écrire)/espèce (consulter l’api taxhub) par exemple avec TOUTES les obs & le bouton pour participer.
• Travail à mener sur le volet utilisateur enregistré ou pas.
• (bloc espèces du programme (d'après la liste taxhub? > non prioritaire, seulement si disponibilité de temps après les priorités 1,2,3).

A la saisie d’une observation

• RGPD oblige, on ne peut demander d’infos personnelles à l’observateur non enregistré > Donnée obligatoirement anonyme donc.
• Sur la carte, ajouter une géolocalisation de l’observateur (pour utilisation mobile notamment) > https://leafletjs.com/examples/mobile/
• Imposer un seuil mini de zoom pour localiser une observation.(doit être configurable dans le fichier de conf de la carte, par défaut 14).
• (note pour plus tard, sur de grands territoires, envisager l’utilisation de recherche de lieu par adresse avec nominatim par exemple).

page observateur

• enlever le classement
• bloc carte/liste avec les obs de l’observateur exportables (générer coté API une vue des observations tous types confondus (espèces ET sites), export généré côté backend ou frontend à creuser ? ).
• badges (affichage optionnel)
• boutons gestion rgpd (regarder ce qu’il se fait pour le BackEnd et la BDD)

Angular Universal et SEO

preuve de concept à faire

Multilingue

On intègre de base la fonction multilingue dans les composants, on change progressivement dans les templates et le fichier de langue (clé:valeur)).

PRIORITE 2 / Gestion des badges

(rappel du CCTP)

Un système automatique (paramétrable par les animateurs) qui attribue des badges aux utilisateurs en fonction de leurs statistiques:

• nombre de données (par exemple: or>5k données, argent>1k données, bronze>100 données),
• ancienneté du compte (par exemple: œuf=7j, chenille=6mois, papillon=1an),
• mission réussie (pour des journées spécifiques voir plus bas).

Un système manuel (paramétrable également par les animateurs) qui permet de regrouper les utilisateurs dans plusieurs catégories, par exemple: observateur fiable, observateur non fiable, scolaire, accompagnateurs en montagne (AEM), partenaires ... > implanté en bdd, cf. ici #22

Les animateurs doivent pouvoir créer de nouveaux badges automatiques en définissant les seuils de déclenchements de ces badges selon les éléments suivants :

• type de taxons (par exemple: les oiseaux, la faune, la flore, ou plus précisément : ex la vanesse des pariétaires),
• nombre d'observations à partir duquel ils se déclenchent (de une à n observations),
• définir des bornes de dates pendant laquelle l'obtention est possible pour créer des évènements
  (muguet le 01/05, marathon des oiseaux en période de migration etc…),
  Ils doivent pouvoir créer des badges manuels également qui sont gérés sous la forme de liste.

PRIORITE 3 / Back Office Animateurs

(de mémoire, on avait acté que pour commencer, on le gérait en bdd, sans backoffice)

• crud utilisateurs
• crud groupes utilisateurs
• crud données utilisateurs
• crud badges automatiques et manuels
• attribution/suppression des badges pour utilisateurs
• gestion de l’abonnement à la newsletter
• "[...] un outil d'extraction des utilisateurs par groupe et notamment une liste d'adresses mail utilisable dans la messagerie Zimbra."

PRIORITE 4 / Back Office Admin (de mémoire, on avait acté que pour commencer, on le gérait en bdd, sans backoffice)

• crud animateurs et droits animateurs
• gestion des programmes

[lpofredc]

Je suis favorable à la proposition #5 (comment) de @camillemonchicourt pour d'abord disposer d'un programme fonctionnel basique (sans authentification)

[samuelpriou]

@orovellotti,@lpofredc, @camillemonchicourt nous sommes d'accord sur le fait de disposer dans un premier temps d'un programme fonctionnel basique (priorités 1) puis nous basculerons sur les priorités 2 qui ont également toutes leur importance. Dans les priorités 2 n plus l'administration des badges, il faut également intégrer l'authentification et la gestion du compte.

En fonction du temps disponible nous finaliserons les requêtes à mettre en place pour les priorités 3/4

• crud utilisateurs
• crud groupes utilisateurs
• crud données utilisateurs
• crud badges automatiques et manuels
• attribution/suppression des badges pour utilisateurs
• crud animateurs et droits
• animateurs gestion des programmes
• gestion de l’abonnement à la newsletter "[...] un outil d'extraction des utilisateurs par groupe et notamment une liste d'adresses mail utilisable dans la messagerie Zimbra."

Merci

[orovellotti]

Merci @lpofredc @camillemonchicourt @samuelpriou

Nous faisons donc notre maximum pour les priorités 1 et 2 jusqu’au 1er mars (fin de notre prestation).

Et en fonction du temps disponible nous travaillerons sur les points restants.

[lpofredc]

Deux nouvelles démo disponibles, en fonction du nombre de programmes :

• Programme unique: http://geonature-citizen-demo.dbwildlife.info:4001
• Plusieurs programmes: http://geonature-citizen-demo.dbwildlife.info:4002

[lpofredc]

Ces démos sont en mode server-side-rendering (rendu côté serveur):

Deux nouvelles démo disponibles, en fonction du nombre de programmes :

* Programme unique: http://geonature-citizen-demo.dbwildlife.info:4001

* Plusieurs programmes: http://geonature-citizen-demo.dbwildlife.info:4002

La démo principale, en mode client-side-rendering vient également d'être mise à jour (avec une compilation de production ng build --prod plus légère que les versions précédentes) :

• http://geonature-citizen-demo.dbwildlife.info/

[samuelpriou]

Merci Fred !

[lpofredc]

Nouvelle mise à jour de la démo de développement suite au PR #83 proposé par @patkap de @naturalsolutions.

• en mode client-side-rendering : https://geonature-citizen-demo.dbwildlife.info/
• en mode server-side-rendering:
  • Programme unique: http://geonature-citizen-demo.dbwildlife.info:4001
  • Plusieurs programmes: http://geonature-citizen-demo.dbwildlife.info:4002

[ghost]

Un soucis de bundle/css sur la démo ssr à plusieurs programmes ?

[ghost]

@lpofredc , je viens de reproduire l’artefact css en oubliant de préciser le base-href.
@PnX-SI/gn-citizen-dev: déploiement pour tests avant la nouvelle PR ... si vous trouviez 5min pour éprouver ... https://geonature.demos.natural-solutions.eu/citizen/

[camillemonchicourt]

Est-ce que le swagger fonctionne toujours sur le projet si on veut accéder à la doc de l'API d'une instance ?

[ghost]

http://51.75.141.99:5002/apidocs/

[lpofredc]

Nouvelle issue à créer lorsqu'une instance de démo officielle sera mise en place