Simplifier Publik¶

On a ajouté pas mal de choses dans l'interface des différentes briques depuis 2 ou 3 ans, trop. Réfléchir à ce qu'on peut enlever est plus important que réfléchir à ce qu'on peut ajouter (pour avoir une application robuste, facile à comprendre, facile à maintenir, sur laquelle il ne devient pas impossible de faire du support).

Une partie de ces complexités, mais une partie seulement, vient de Publik Famille (une série de trucs dans chrono ou encore les cellules concernant les fiches). Il est logique que sur un projet émergent et pas généricisé on tâtonne, on produise des choses qui devront mûrir. Il est logique aussi qu'on accorde parfois trop d'importance aux demandes de l'unique client (parce qu'on ne peut pas les relativiser et les mettre en perspective avec les demandes contradictoires d'autres clients). Génériciser/simplifier le Publik Famille Vénissieux sera un gros travail sur lequel je compte m'investir si Stef veut bien de moi.

• les choses dont j'aimerais qu'elles n'apparaissent plus sur les nouveaux déploiements
• Les choses dont j'aimerais qu'elles soient affichées de façon plus claires

L'idée c'est de débattre ici de l'ampleur des pertes de fonctionnalités induites avant d'entamer un éventuel dialogue avec les devs.

L'objectif de ce débat c'est aussi que chacun s'oblige à discuter collectivement et à pointer explicitement les choses dont elle/il demande qu'elles soient ajoutées dans l'interface AVANT qu'elles le soient.

• les types de champs
• les actions de WF
• les cellules
• (ajoutez votre endroit préféré ici).

Les types de champs¶

On a trop de types de champs et une liste mal fichue.

• Faire disparaître les 3 types de champ tableau (blocs de champs + données calculées ça fait le job)
  • Ce qu'on y gagne : 3 entrées dans la liste, 3 types en moins à expliquer, le fait d'avoir des données toujours structurées
  • Ce qu'on y perd : la facilité de faire un total dans un tableau, pas bloquant on ajoutera une explication dans la doc sur la façon de le faire avec un bloc de champ
• Mot de passe et éléments classés, il y a vraiment des usages ? (demander des stats sur la prod)
• Réorganiser la liste avec des séparateurs https://dev.entrouvert.org/issues/11247#note-2

Les actions de WF¶

Il y a trop d'actions. On va pouvoir en diminuer significativement le nombre quitte à avoir parfois des actions un peu plus complexes. Il faut toutefois veiller à ne pas complexifier la compréhension du schéma avec des actions trop fourre-tout.

Modif la plus importante : virer les actions commentaire, fichier et saut à la soumission¶

C'est assez complexe à faire mais c'est aussi un sacré gain. Ça passe par :

• Supprimer les actions commentaire et fichier (tout faire avec "formulaire")
• Supprimer saut à la soumission
• Étoffer l'action formulaire
  • en permettant de choisir le libellé du bouton valider, un statut de destination et le fait d'enregistrer les fichiers et commentaires dans l'historique, cf capture : naXP61B.png (plus tard on pourra s'intéresser au texte d'aide backoffice, la demande de confirmation, le fait de poser un marqueur)
  • autre solution qui a ma préférence (si jamais elle est faisable, ça pose de vraies difficultés avec l'existant) ne plus avoir de bouton valider et utiliser systématiquement un saut manuel (les seuls devs alors c'est le fait de supprimer le bouton valider + l'option permettant d'enregistrer fichiers et commentaires dans l'historique)

• Ce qu'on y gagne
  • Plus de confusion entre les actions commentaire / fichier et l'action formulaire
  • Plus de comportements différents pour le stockage/envoi des fichiers
  • Plus d'explications compliquées à donner sur le saut à la soumission
  • On économise 3 actions dans les listes

Autres modifications¶

• Une action "fiche" unique https://dev.entrouvert.org/issues/59398 (ceci n'est pas une opération du planning familial chinois). Avec la précision dans le schéma concernant ce qu'elle fait
  • Ce qu'on y gagne :
    • 2 actions dans la liste
    • Le fait d'avoir tout ce qui concerne les fiches au même endroit
  • Ce qu'on y perd :
    • L'action devient un peu plus complexe à configurer (relativement marginal tout de même, peu d'éléments nouveaux dans l'interface).
• Une action "communication" unique pour notif / mail / sms (avec un onglets pour chaque type + "communication (notif, mail, sms)" ou encore "communication (notif, sms)" sur le schéma)
  • Gains/pertes comparables à l'action fiche unique
• Fusionner les actions "ajouter un rôle" / "Retirer un rôle" dans la partie "Agir sur le demandeur"
• Fusionner les actions "alerte" et "Message dans l'historique (avec un cercle d'option, et des options de styles utilisables que pour les alertes)
• Supprimer l'action "courriel récapitulatif quotidien"
  • demander si on peut avoir les stats sur la prod pour estimer l'intérêt de conserver ça
  • nous pouvons peut être couvrir ce cas avec un mail contenant des requêtes et une condition d'envoi

Les cellules¶

On a un peu trop de cellules, classées un peu n'importe comment dans la liste.

Supprimer des cellules¶

• Supprimer la cellule "Lien", "Liste de liens" faisant le job (on peut ajouter un unique lien avec la "Liste de liens" rebaptisée "Lien(s)")
• Supprimer "Tableau de bord"

Réorganiser la liste des cellules¶

• Contenu générique
  • Flux RSS/Atom
  • Galerie d'image
  • Lien(s) => (ex liste de liens)
  • Menu
  • Notification à l'usager
  • Recherche
  • Texte

• Démarches
  • Brouillon en cours
  • Catégorie de demandes
  • Code de suivi
  • Demandes de l'usager
  • Démarches d'une catégorie
  • Lien vers une catégorie
  • Lien vers une démarche

• Espace agents
  • Demandes à traiter
  • Saisie backoffice
  • Jauge

• Fiches
  • Contenu d'une fiche
  • Fiches

• Visualisation de données
  • Filtres
  • Graphes

• Paiement
  • Factures actives
  • Formulaire de paiement TIPI
  • Historique des factures
  • Lien vers le panier
  • Panier
  • Transactions récentes

• Autres
  • Carte
  • Dernières pages modifiées (base de connaissance)
  • Document récents
  • Identique à la page parente
  • Profil
  • Prototype JSON