ZAN - Modification des procédures

[celine-m-s]

Nécessaire avant :

• Objet de la procédure (champ commentaire) : déplacement dans un champ dédié et migration de données. cf Structuration de la donnée du champ "objet" de procédure #1754
• Nom de la procédure : distinguer le nom automatique (colonne nom) du complément (nouvelle colonne complementNom). Migration de données. Idéalement, ne plus stocker le nom dans une colonne mais à voir si c'est possible.
• Bouton de procédure en haut à droite
• Périmètre non modifiable
• [à valider] Ajout bouton Signaler un problème sur page d'ajout de procédure.
• [à valider] Page création de procédure : champ disabled.
• Supprimer le champ permettant de modifier le nom de la procédure. Quel message ?

Ensuite :

• Nouvelle page : comme le formulaire de création actuel.
• Ne pas modifier le périmètre (affichage des champs grisés)
• Pour modifier le périmètre : contactez-nous via le formulaire "signaler un problème", selon l'effort dev que ça implique il faudrait avoir idéalement le bouton "signaler un problème" sur la page de modification des paramètres des proc donc. (on en avait déjà parlé pour avoir le bouton sur la fenetre d'ajout de proc. mais ça n'avait pas été priorisé)
• Au lieu d'information générale => modifier la procédure.
• Utilisateurs pouvant modifier la procédure : type DDT ou compte créateur de la procédure : ajout de la règle user.canEditProcedure.
• Problème : les utilisateurs ne savent pas comment le champs Complément du nom sera affiché. Prévisualisation du titre de la procédure : ticket à créer.
• Afficher un champ « Modifié le XX par XX » sur la feuille de route.
• Suppression des colonnes inutiles de la table procedures : testing, doublon current_perimetre & initial_perimetre.

https://www.figma.com/design/4W463mFBKoDzf4mgJAhW9y/Docurba-(V2)?node-id=6440-149848&t=Ywpw6n4sPJJ1pgYt-0

[celine-m-s]

@HermanceGauth @CeliaVermicelli J'ai deux petites améliorations à proposer pour la page de création de procédure :

• Ajout bouton Signaler un problème sur page d'ajout de procédure (idée de Célia) : c'est du XS. Ça me prendra moins de 30 minutes si vous me dites exactement où vous le voulez.
• Page création de procédure : champ disabled (grisé) au lieu du champ actuel. J'ai fait un essai avec le formulaire de modification de procédure (voir le rendu sur la capture d'écran ci-dessus). Si le rendu vous plaît, je peux l'appliquer sur le formulaire de création. Pareil, c'est du super XS (moins de 30 minutes) tant que je suis sur le sujet.

[celine-m-s]

Je ne suis pas persuadée que ce soit un gain d'afficher le périmètre. J'ai commencé à regarder comment le rendre modifiable mais ce sera pour plus tard.

[Octaviedebs]

C'est top ! Sur le bouton Signaler un problème en lien avec la modification du périmètre: je me dis que ce serait peut être mieux que visuellement il apparaisse proche à droite de l'encadré informatif (pour signaler un chgt de périmètre) ; et je mettrai du coup un peu plus bas le bouton Modifier la procédure.

Pour l'affichage du périmètre : peut être plutôt les cacher dans un menu qui s'ouvre pour que ça prenne moins de places ? et reprendre'UX actuel en le grisant ?

[HermanceGauth]

Ajout bouton Signaler un problème sur page d'ajout de procédure (idée de Célia) : c'est du XS. Ça me prendra moins de 30 minutes si vous me dites exactement où vous le voulez.

Oui je pense que c'est une bonne idée. Je l'aurai mis en haut à droite comme c'est le cas sur la page collectivité et FRP

Page création de procédure : champ disabled (grisé) au lieu du champ actuel. J'ai fait un essai avec le formulaire de modification de procédure (voir le rendu sur la capture d'écran ci-dessus). Si le rendu vous plaît, je peux l'appliquer sur le formulaire de création. Pareil, c'est du super XS (moins de 30 minutes) tant que je suis sur le sujet.

On parle bien du champ "Nom" de la procédure grisé pour montrer que ce n'est pas modifiable et que c'est un aperçu? J'ai l'impression que pour le côté non modifiable ça marche bien, mais pour le côté aperçu un peu moins bien. J'ai le sentiment que cette preview était déjà peu remarquée par les utilisateurs et qu'en grisant ça risque d'être pire? Pour moi l'idée était de faire davantage ressortir la preview du nom pendant qu'ils renseignent les éléments pour qu'ils se trompent moins. Après comme ils auront à présent la main pour modifier, c'est moins grave.

Je ne suis pas persuadée que ce soit un gain d'afficher le périmètre

Si on ne l'affiche pas lors de la modification de procédure, alors on ne peut pas renvoyer les utilisateurs vers le formulaire signaler un problème. Donc pour moi deux options, qui sont toutes les deux ok dans une première version :

• on n'affiche pas le périmètre et pas le bouton signaler un problème
• on affiche le périmètre avec un système qui prend moins de place (menu qui s'ouvre, colonnes, ...) et on met le bouton signaler un problème à côté de "Périmètre de la procédure". Et à voir si le wording est assez explicite, pour dire qu'il ne vont pas pouvoir faire l'action directement mais juste nous signaler l'erreur.

Voilà mon avis sur ces questions. Le plus simple selon moi serait de faire un échange directement sur ces points avec @cami-na qui est de retour aujourd'hui.

[CeliaVermicelli]

Je suis raccord avec :

• menu dépliant pour afficher le périmètre + bouton signaler un problème pas loin et idéalement sur la droite (comme son amplacement actuel sur /mesCT et /frise,
• griser le champ du nom ne va pas les aider à mieux se rendre compte qu'il est généré automatiquement pour éventuellement adapter.

Mes questionnements :

• (à voir si c'est dans une "Version nºX") prévoit-on d'afficher aussi un bouton "modifier la procédure" depuis la page des collectivités ? je ne dis pas que la disposition ci dessous est idéale - et peut-être qu'on a envie de proposer cette option quand cette page sera aussi revisitée ?

• et donc le point ci-dessus m'amène à penser que le wording "modifier la procédure" n'est peut-être pas l'idéal, je me projette dans les contenus d'aide ou lors d'explications à l'oral ;
  Car "modifier la procédure" peut aussi vouloir dire la mettre à jour avec des événements (et donc similaire aux boutons "feuille de route" et "ajouter un event". je pense que ça peut valoir le coup d'avoir un wording pérenne sur cette fonctionnalité, même si on ne se penche pas pour l'instant sur le fait de proposer ce nouveau bouton depuis les pages CT.

Je suppose que le point avec Camille servira aussi à checker ces éléments

[Octaviedebs]

Concernant le terme Modifier la procédure :
Je suis d'accord - je me dis que Modifier les caractéristiques de la procédure serait mieux (mais long).
Ou Modifier les paramètres de la procédure
Ou sinon, garder ce terme mais ajouter un "i' avec l'explication de ce qu'ils pourront modifier.

Concernant l'emplacement du bouton "modifier la procédure" depuis la page des collectivités
De mon côté je ne trouve pas cela forcément très intuitif - rester juste sur l'option de rentrer sur la FRP pour accéder à la suppression / modification me parait plus logique. Mais effectivement à Camille de voir !

[celine-m-s]

Vu avec Camille :

• ok pour le champ disabled sur formulaire de création et modification.
• bouton signaler un problème : en haut à droite
• Périmètre : on réutilise ce qui existe sur la page de la collectivité.

[celine-m-s]

Voici une seconde proposition en fonction de vos retours et de ma discussion avec Camille ce matin :

• J'ai ajouté le boutons pour signaler un problème à deux endroits (en haut à droite et dans la modale du périmètre).
• J'ai affiché le périmètre dans une modale.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.2% Duplication on New Code

See analysis details on SonarQube Cloud

[celine-m-s]

On parle bien du champ "Nom" de la procédure grisé pour montrer que ce n'est pas modifiable et que c'est un aperçu? J'ai l'impression que pour le côté non modifiable ça marche bien, mais pour le côté aperçu un peu moins bien. J'ai le sentiment que cette preview était déjà peu remarquée par les utilisateurs et qu'en grisant ça risque d'être pire? Pour moi l'idée était de faire davantage ressortir la preview du nom pendant qu'ils renseignent les éléments pour qu'ils se trompent moins. Après comme ils auront à présent la main pour modifier, c'est moins grave.

Oui, on parle bien de ce champ là.

Rendre le champ grisé permet à l'utilisateur de bien comprendre qu'il ne peut pas le modifier. Actuellement, on peut penser qu'il est interactif car il est blanc. Mais je suis complètement d'accord sur le fait qu'il ne permet pas de bien comprendre la manière dont sera affiché le nom final.
Camille et moi proposons de transformer le champ en grisé le temps qu'elle puisse travailler la logique de ce composant de manière un peu plus pérenne.