Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mieux distinguer réglementations temporaires et permanentes #1056

Open
2 tasks
MathieuFV opened this issue Nov 6, 2024 · 9 comments
Open
2 tasks

Mieux distinguer réglementations temporaires et permanentes #1056

MathieuFV opened this issue Nov 6, 2024 · 9 comments

Comments

@MathieuFV
Copy link
Collaborator

User story

J'ai fait un test UX/UI avec les experts qui ont travaillé sur les interfaces de BAC IDF. Pour rappel BAC IDF avait pour objectif de collecter l'ensemble des réglementations propres au transport de marchandises en IDF, qui sont des réglementations permanentes.

Le test a révélé de nombreux points d'amélioration de l'interface, qui a été pensée avant tout pour gérer la réglementation temporaire, afin de mieux prendre en charge la saisie de réglementations permanentes et notamment celles qui se rapportent au transport de marchandises.

Ce ticket rassemble ces différents points d'amélioration en vue de leur traitement (qui pourra être réalisé via des tickets séparés).

En prenant dans l'ordre du workflow de saisie d'un arrêté (à partir de "Ajouter un arrêté") :

1° Pour le champ "Identifiant" le sous-titre "Numéro ou nom de l'arrêté (identifiant unique)" devrait plutôt être restreint à "Numéro de l'arrêté (identifiant unique)" car le nom d'un arrêté ferait plutôt référence à ce que nous appelons "Description", et il serait préférable d'éviter une ambiguïté sur ce qui est attendu dans ce champ.

2° Il pourrait être judicieux de faire remonter le champ "Description" sous le champ "Identifiant", voire de renommer "Description" en "Intitulé" par exemple ?

3° La dropdown "Nature de l'arrêté" ne devrait proposer que trois possibilités : "Réglementation permanente", "Réglementation temporaire", "Réglementation exceptionnelle".

4° On pourrait placer à la suite de cette dropdown une autre dropdown "Objet de l'arrêté" permettant de qualifier son objet parmi des catégories comme celles déjà présentes (Travaux, Incident ou péril, évènement, et d'autres à compléter au fur et à mesure). Ce champ reste optionnel (il pourrait permettre de différencier les masques de saisie selon l'objet par la suite). L'important reste la séparation réglementation permanente/temporaire.

5° A l'étape suivante, on a "Dates à définir" qui s'affiche pour les dates de l'arrêté en fonction de celles qui seront saisie par la suite. Pour un arrêté permanent il faudrait plutôt avoir quelque chose comme "Entrée en vigueur à la signature de l'arrêté" ou quelque chose d'équivalent, signalant que l'arrêté est en vigueur dès la publication de l'acte.

6° De la même manière, dans les périodes d'applications, on ne devrait pas avoir de date/heure de début dans le cas d'un arrêté permanent. i.e si on a choisi une nature "Réglementation permanente" à l'étape précédent il faudrait uniquement pouvoir saisir des périodes "Jours concernés" qui sont récurrentes.

7° Il n'est pas assez claire que le bouton qui permet de "Définir les horaires" est cliquable et permet de saisir les horaires sur les jours concernés.

8° Dans les véhicules concernés par la restriction, le bouton "Poids lourds" pourrait être changé seulement par "Poids" afin d'être en cohérence avec le bouton voisin "Gabarit", et il ne devrait être possible de choisir que parmi une liste de poids proposés plutôt que de saisir manuellement le tonnage.

9° Il manque une catégorie "Véhicules de service" dans les exceptions

10° Dans la section des localisations la sémantique "Où est prévue la perturbation" fait écho aux réglementations temporaires mais n'est pas très adaptée au contexte de la réglementation permanente. On pourrait changer par "Où est prévue la restriction" pour éviter les problèmes de contextualisation.

11° Le nom du champ "Ville ou commune" devrait plutôt être "Ville ou code postal" (car Ville = commune)

12° Les réglementations permanentes devraient pouvoir être appliquées à toute la commune d'un coup

Nous avons aussi finalement évoqué deux idées qui nécessiteraient un travail plus approfondi :

  • La possibilité de saisir des voies sur une carte (on en avait déjà parlé)
  • Le fait de séparer les réglementations propres au transport de marchandises de celles qui sont propres au transport de personnes

Critères d'acceptation

  • (Must have) Critère 1
  • (Nice to have) Critère 2

Design

Implémentation

Contexte supplémentaire

@florimondmanca
Copy link
Collaborator

8° Dans les véhicules concernés par la restriction, le bouton "Poids lourds" pourrait être changé seulement par "Poids" afin d'être en cohérence avec le bouton voisin "Gabarit", et il ne devrait être possible de choisir que parmi une liste de poids proposés plutôt que de saisir manuellement le tonnage.

Ça correspond à #611

@aureliebaton
Copy link
Collaborator

Merci pour ces retours @MathieuFV, il y a pas mal de petites choses qui me semblent pertinentes et seraient pas trop comliquées à mettre en place. A voir comment on peut prioriser.

@MathieuFV
Copy link
Collaborator Author

On regarde au prochain sprint planning comment on peut partir sur de nouvelles maquettes. Je crois qu'il faudrait traiter ça avant de nous lancer sur les histoires de viabilité hivernale car ça facilitera les choses ensuite.

@aureliebaton
Copy link
Collaborator

aureliebaton commented Nov 7, 2024

On regarde au prochain sprint planning comment on peut partir sur de nouvelles maquettes. Je crois qu'il faudrait traiter ça avant de nous lancer sur les histoires de viabilité hivernale car ça facilitera les choses ensuite.

J'ai l'impression que c'est plus des ajustements dans les maquettes que des nouvelles maquettes à proprement parler non ? C'est surtout des petites choses, j'avais pas l'impression que ça remettait tout en question, si ?

@MathieuFV
Copy link
Collaborator Author

Oui tout à fait, on est sur des améliorations :) J'aurais plutôt dû dire ajustements en effet

@MathieuFV
Copy link
Collaborator Author

Je pense qu'on peut ajouter à ces améliorations un point 13° : Permettre d'indiquer quand un seul sens est concerné par une restriction (avec les idées qu'on avait déjà eues sur Point A -> Point B etc.)

@mmarchois
Copy link
Collaborator

ℹ️ comme dit ce matin au daily, j'ai commencé à avancer sur certains points, en mode "quick win". Le 1, 2, 3 et 4.

@MathieuFV
Copy link
Collaborator Author

Point avec Aurélie :

  • 2° : On peut changer le nom du champ "Description" en "Intitulé", plus clair
  • 3° : Pas forcément utile d'avoir le type "Réglementation exceptionnelle" dont on ne sait pas si ça fait vraiment écho à un type d'arrêté. On peut appeler le champ : "Type d'arrêté" (à voir ailleurs sur DiaLog pour assurer la cohérence : type = permanent ou temporaire)
  • 4° : Créer un champ supplémentaire "Objet de l'arrêté" où mettre les catégories suivantes : Travaux, Evènement, Incident ou péril, et Autre (avec possibilité d'ajouter une catégorie personnalisée).
  • 5° : Pertinence de garder la mention "Dates à définir" dans les infos générales pendant l'édition d'un arrêté ? Si oui : On met les dates à jour à chaque validation d'une mesure de restriction. Si non : On enlève la mention et on affiche les dates à compter de la publication de l'arrêté dans DiaLog uniquement. On aurait tendance à l'enlever.
  • 6° : On peut enlever l'heure de début pour une réglementation permanente mais il faudrait garder le jour de début.
  • 7° : A tester en shadowing avec d'autres utilisateurs pour confirmer qu'il y a ambiguïté mais sinon on laisse tel quel.
  • 8° : A voir quel contenu on pourrait avoir dans la dropdown des tonnages, sinon OK mais pas hyper prioritaire.
  • 9° : OK
  • 10° : OK
  • 11° : OK
  • 12° : OK
  • 13° : On ajoute une dropdown pour les localisations sur voies nommées (communales) pour choisir un sens : A vers B, B vers A, ou Double sens. On laisserait double sens par défaut.

Autres améliorations :

  • Cocher par défaut la case "Voie entière" d'une localisation

@aureliebaton
Copy link
Collaborator

Autres améliorations :

* Cocher par défaut la case "Voie entière" d'une localisation

Voir issue #646

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: En développement
Development

No branches or pull requests

4 participants