[Minor] Improve event creation/edition

[mguihal]

Hello,

Je propose dans cette PR une amélioration de l'ergonomie de l'interface de création et d'édition des évènements.

Tensions :

• Actuellement via la double page du formulaire de création d'évènement, on peut créer un évènement sans date, qui est introuvable ensuite via l'interface.
• Il n'y a aucune contrainte dans les dates des évènements (ex: on peut mettre une date de fin antérieure à la date de début)
• Il est impossible de rajouter une image (ex: affiche) rattachée à un évènement
• L'ergonomie est trompeuse avec le formulaire de création : Les utilisateurs ne comprennent pas pourquoi indiquer le nom seul avant d'arriver à la suite du formulaire
• L'ergonomie est trompeuse avec le formulaire d'édition à deux onglets : Les utilisateurs ne voient pas naturellement le second onglet

Propositions de solutions :

• Fusion du formulaire de création/édition en une seule page et onglet. Création de catégories pour différencier les champs obligatoires et optionnels (Informations de base, Description, Autres informations)

• Guidage de l'utilisateur en ajoutant des textes de description sur les champs

• Ajout de contraintes sur les deux champs de date pour ne pas pouvoir saisir un évènement avec une date dans le passé, ni de mettre une date de fin antérieure à la date de début. La date de début est maintenant obligatoire.

• Ajout d'un champ d'upload d'image au formulaire

[GuillaumeAV]

Génial !! Merci beaucoup @mguihal !

[srosset81]

Ca fait un moment que @fluidlog poussait aussi pour ce changement, ça pourrait valoir la peine de le généraliser sur toutes les ressources. Par contre je m'interroge sur le fait qu'on perde la possibilité d'importer un événement externe... il y a peut-être un moyen de proposer un autre élément UX pour ça ?

[mguihal]

Je découvre aussi les nombreuses customisations faites sur le repo des cheminsdelatransition, dont le frontend semble grandement inspiré par Archipelago, sans suivre les dernières avancées mais en apportant beaucoup d'autres améliorations en plus qui n'ont jamais été rapatriées ici, je me pose la question (plus philosophique) du rôle et le but d'Archipelago dans tout ça...

Jusqu'à quel point devons-nous contribuer à ce repo pour l'améliorer ?
Les sites qui s'en servent devraient-il mieux :

• Forker le repo comme lescheminsdelatransitions, et continuer de personnaliser comme on a envie chacun de notre côté
• Surcharger le repo comme fait pour l'instance de l'AV ou Transiscope Nantes

Dans le premier cas, je ne perds pas plus de temps à remonter ici toutes les améliorations/customisations que nous développons pour notre instance, mais ce repo risque peut-être de progressivement tomber à l'abandon. Dans le second cas, alors nous devons penser ce repo comme entièrement personnalisable tant dans le contenu, les ressources, le design, etc. de façon à ce qu'il soit prêt clé-en-main à être déployé pour une nouvelle instance...

Je n'ai sans doute pas tout l'historique de pourquoi la création d'Archipelago, quelles sont ses utilisations en prod actuellement, etc., mais ça m'aiderait sûrement à savoir où m'arrêter dans les améliorations que je compte pousser dans ce repo ces prochaines semaines (basées notamment sur notre utilisation de notre instance Transiscope Nantes en conditions réelles).

Je prends pour exemple le contenu de cette PR :

• Est-ce que l'import d'évènement devrait être quelque chose de personnalisable selon les instances pour savoir si on doit l'afficher ou pas, si cette fonctionnalité est utile pour certaines instances mais pas pour d'autres ?
• Est-ce que si dans le futur on doit rajouter des nouvelles améliorations aux évènements qui peuvent être utiles pour tout le monde, mais qui ne sont pas forcément dans l'ontologie PAIR (exemples possibles au hasard : ajouter un lien vers les organisateurs des évènements, indiquer si l'évènement est en ligne ou pas, s'il est complet ou pas, les lier à une ressource Lieu plus complète qu'une simple adresse, etc.) Est-ce que ça a sa place sur ce repo ou pas ?

[srosset81]

Je découvre aussi les nombreuses customisations faites sur le repo des cheminsdelatransition, dont le frontend semble grandement inspiré par Archipelago, sans suivre les dernières avancées mais en apportant beaucoup d'autres améliorations en plus qui n'ont jamais été rapatriées ici, je me pose la question (plus philosophique) du rôle et le but d'Archipelago dans tout ça...

Je ne vois pas trop quelles fonctionnalités des CDLT te semblent manquer à Archipelago, tu as des exemples ? Pour moi l'instance des CDLT est très spécifique aux besoins de ce projet, alors qu'Archipelago a pour but de proposer une application qui peut être utilisé pour de nombreux projets et collectifs.

• Est-ce que l'import d'évènement devrait être quelque chose de personnalisable selon les instances pour savoir si on doit l'afficher ou pas, si cette fonctionnalité est utile pour certaines instances mais pas pour d'autres ?

Oui pourquoi pas. Mais si la fonctionnalité est discrète, y a-t-il vraiment le besoin de la désactiver ?

• Est-ce que si dans le futur on doit rajouter des nouvelles améliorations aux évènements qui peuvent être utiles pour tout le monde, mais qui ne sont pas forcément dans l'ontologie PAIR (exemples possibles au hasard : ajouter un lien vers les organisateurs des évènements, indiquer si l'évènement est en ligne ou pas, s'il est complet ou pas, les lier à une ressource Lieu plus complète qu'une simple adresse, etc.) Est-ce que ça a sa place sur ce repo ou pas ?

Le choix jusqu'à maintenant est de dire que Archipelago = ontologie PAIR. Il est tout à fait possible d'étendre l'ontologie PAIR s'il y a des choses qui manquent.

En tout cas ce sont des questions importantes pour lesquelles il n'y a pas de réponses simples. J'ai trop la tête dans ActivityPods en ce moment pour y répondre, mais je crois que @GuillaumeAV serait ravi d'en discuter.

[GuillaumeAV]

En effet ! J'ai d'ailleurs publié hier une isse pour sur le sujet ... chemins-de-la-transition/semapps#623

On va travailler également à une évolution de l'ontologie PAIR, avec l'objectif d'y intégrer certaines des évolutions qu'on a faites pour les chemins de la transition ..

On peut se faire une visio pour en parler un de ces 4 @mguihal ?

[mguihal]

Ici ça me paraîtrait plus logique de mettre "qui organisent l'évènement" ?
Mais la relation pair:involves ne semble pas cibler seulement les organisateurs, mais englober aussi les participants, intervenants, etc.
Existe-t'il une relation plus spécifique ?

[srosset81]

On peut utiliser une relation réifiée (involvementActivity/involvementActor). Voir le diagramme. Perso je pense que les relations réifiées sont trop complexes pour ce type de cas très courants, et je serai favorable à un pair:organizedBy.

[GuillaumeAV]

Yo !

On a un cdlt:organizedBy ... C'est typiquement le genre de choses qu'on devrait transférer du custom cdlt direction le générique pair !

On bosse dessus cette semaine et les suivantes avec Damien puis avec Thomas !

[fluidlog]

Merci @mguihal d'apporter ce débat très intéressant. Comme dit @srosset81, je suis passé par là il y a 6 mois, et j'ai fait le même chemin que toi. J'ai observé les CDLT pour m'inspirer et comprendre, et je me suis demandé comment on allait faire évoluer tout ça vers des "produits SemApps" facilement réutilisables... et c'est pas simple.
Pour info, j'en avais fait un PAD : https://pad.lescommuns.org/InstallationCheminsDeLaTransitionEnLocal

Depuis, je fais avec la structure que j'ai décrit dans le schéma ici : https://portal.carto4ch.huma-num.fr/assets/images/toolbox-semapps-48e77414612cbe9062d06f9b62980b56.png
Il y a une boite à outil SemApps avec un middleware, et pleins de frontend, et en fonction du projet, à nous d'aller piocher là où ça nous intéresse, en prenant petit bout par petit bout. Ce n'est en effet pas très efficace, mais c'est comme ça à l'heure actuelle.

Pour mon projet Carto4CH, j'utilise comme toi une base d'Archipelago (je n'ai pas besoin des fonctions supplémentaires de CDLT pour mon projet), et maintenant, je reste autonome dans mon fork d'Archipelago. Je jette régulièrement un oeil sur les nouveautés de archipelago AV, et si elles m'intéressent, je fais des C/C dans mon code, ça me permet de bien comprendre ce que je fais et comment ça fonctionne.

Pour mon futur projet Permalieux, j'hésites encore à partir de CDLT ou de Oasis, mais je verrai ça en 2024...

Pour les formulaires en une page, en effet, on est, semble-t-il, tous d'accord pour les utiliser, pour cela, j'ai commencé par m'inspirer de WTMP (Welcome to my place) :
https://pad.lescommuns.org/FormulaireDeCreationSurUneSeulePage

Puis, plus tard, Seb m'a orienté vers son dernier projet Oasis, et je me suis de nouveau inspiré du code pour faire le mien.
https://pad.lescommuns.org/InstallationAnalyseDuCodeOasis
Qui m'a permis de simplifier mon code en RA4 comme décrit ici : https://pad.lescommuns.org/SimplificationDuBoRa4

Je me suis aussi inspirer du projet "minicourse" pour faire une autre interface "My-competence".

Pour ce qui est de l'import de page externes, je n'en ai pas le besoin. Je suis OK si c'est paramétrable simplement.

@GuillaumeAV ; je suis intéressé par une réunion sur le sujet, même si je ne serai pas d'une grande aide pour prendre des choix d'architectures stratégiques pour le futur.

La situation actuelle me va bien, mais elle demande une lourde montée en compétence, pour connaitre tous les projets, et tous les codes à droite et à gauche.
Heureusement qu'on utilise des composants réutilisables qui sont bien documentés, ça permet d'avoir une boite de légos commune.