-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Ça correspond à #611 |
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. |
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 ? |
Oui tout à fait, on est sur des améliorations :) J'aurais plutôt dû dire ajustements en effet |
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.) |
ℹ️ comme dit ce matin au daily, j'ai commencé à avancer sur certains points, en mode "quick win". Le 1, 2, 3 et 4. |
Point avec Aurélie :
Autres améliorations :
|
Voir issue #646 |
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 :
Critères d'acceptation
Design
Implémentation
Contexte supplémentaire
The text was updated successfully, but these errors were encountered: