[admin] ETQ Admin je peux déplacer les champs dans le formulaire n'importe ou dans la page

[lisa-durand]

Suite à #9603 on n'a plus la possibilité de créer un champ tout en bas sans scroller toute la page. Plus on a eu des retours d'usager qui souhaitent pouvoir déplacer plus facilement les champs pour un gros formulaire.

On propose de mettre un champ "déplacer après". Pour des raisons de perf, il faut surement utiliser un datalist ou un champ autocomplete pour ne charger qu'une fois la liste dans le DOM.

à avoir en tête :

• Il faudra surement faire évoluer l'autocomplete
• il faut pouvoir mettre en evidence les sections pour les champs qui ont le mm nom
• rajouter un margin entre les blocs pour qu'on comprenne bien que le bouton est rattaché au bloc du dessus

Lien des Figma sur le sujet : https://www.figma.com/file/EIpX2ADKqh6lRj4IB2xQia/%237047-Logique-conditionnelle-DS?type=design&node-id=2530%3A22560&mode=design&t=Rt1AhlMpRYid421J-1

[colinux]

Une autre solution qui avait été envisagée à la place des nouvelles flèches, c'est un bouton Déplacer après le champ…, on choisit le champ dans un select, comme pour le choix des champs du conditionnel. Le challenge c'est que pour les grosses démarches, on multiplie X gros selects par (X-1) champs et c'est très lourd.

Les solutions dont on avait parlé :

• de n'avoir qu'un seul select dans le DOM, qu'on déplace/affiche opportunément en JS
• ou (beaucoup mieux à mon avis, et sans JS) explorer l'élément html datalist qui permet d'avoir une seule liste dans le dom référencée par l'input qui permet la sélection, avec autocomplete embarqué.

[lisa-durand]

Une autre solution qui avait été envisagée à la place des nouvelles flèches, c'est un bouton Déplacer après le champ…, on choisit le champ dans un select, comme pour le choix des champs du conditionnel. Le challenge c'est que pour les grosses démarches, on multiplie X gros selects par (X-1) champs et c'est très lourd.

Les solutions dont on avait parlé :

* de n'avoir qu'un seul select dans le DOM, qu'on déplace/affiche opportunément en JS

* ou (beaucoup mieux à mon avis, et sans JS) explorer l'élément html [datalist](https://developer.mozilla.org/fr/docs/Web/HTML/Element/datalist) qui permet d'avoir une seule liste dans le dom référencée par l'input qui permet la sélection, avec autocomplete embarqué.

C'est une bonne idée en effet - il y a des maquettes de ce que ça pourrait donner pour faciliter l'implementation ? Je me permets de décaler ce ticket dans priorisé non cadré en attendant.

[colinux]

il me semble qu' @Olivier-Marcellin avait exploré des évolutions sur cette page, et ça en faisait partie, (peut-être quelque part dans le figma?)

[lisa-durand]

Dans ce que j'ai retrouvé dans les Figma j'ai l'impression que la piste était plutot d'ameliorer le drag and drop.

[colinux]

OK, on en avait juste parlé alors. Selon moi le drag & drop n'est pas adapté ici. Ce type de problème est surtout un problème sur les gros formulaires, qui ont par définition beaucoup de champs, et sont peu maniables si on veut remonter un champ de 10 ou 20 champs. Si c'est que pour 2 champs, les flèches font l'affaire.

[Olivier-Marcellin]

Bonjour, en effet, j'ai fait des propositions pour le drag and drop que vous pouvez voir sur une page qui s'intitule 'Planche de recherches sur le configurateur de champs' dans le dossier 'Amélioration vue usagers‘ (j'essaye de tout rassembler dans ce dossier plutôt que d'éclater les sujets de conception dans différents dossiers, cela aide à avoir une vue d'ensemble du parcours admin pour configurer un formulaire et le versant usager pour remplir le formulaire).

Ma réflexion en ergonomie sur ce drag and drop c'est que aujourd'hui il n'est pas optimal : on peut déplacer librement le bloc mais ça devient "périlleux" quand il s'agit de scroller la page avec cette opération en cours (faites le test sur google forms), c'est pourquoi j'ai proposé une autre approche : un drag and drop d'un bloc à un autre (en haut ou en bas) OU alors il faudrait proposer les deux fonctions (drag and drop libre et drag and drop d'un bloc).

Autre chose : j'ai aussi eu une réflexion sur l'emplacement de chaque bouton et sur des évolutions possibles (par exemple on a déplacé le bouton ajouter un champ entre deux et on pourrait à l'avenir y ajouter des raccourcis inspiration google forms). @colin j'ai déplacé le bouton logique conditionnelle pour lui trouver une meilleure place. J'ai aussi travaillé sur les couleurs et comportement quand un champ est activé, etc. et dans le mesure des disponibilités des équipes dsfr j'ai montré ce que je produit de façon à m'assurer que c'est possible (par ex. au début j'avais passé les picto en blanc ce qui est interdit côté dsfr couleur des pictos = bleu).

@lisa je te mets un poke sur remplace de la page de recherche.

[lisa-durand]

@Olivier-Marcellin Merci pour les infos supplémentaires et le poke sur Figma. Du coup j'ai l'impression qu'on est ok pour retirer le drag and drop pas vraiment utilisable en l'etat et pour mettre les fleches en haut à gauche du bloc. Mais j'ai l'impression que ça ne repond pas completement à ce ticket qui avait pour but d'ajouter la possibilité de déplacer "tout en haut" ou "tout en bas" un bloc pour éviter de faire seulement 1 par 1. Est-ce que tu penses que ce serait possible en utilisant 4 icones de fleches differentes par exemple ou trouver une autre solution ?

[Olivier-Marcellin]

'4 icones de fleches differentes par exemple ou trouver une autre solution" : des icônes pour spécifier tout en haut et tout en bas ça me semble difficile à représenter. Une autre solution se serait un select ou alors à côté de ajouter un champ inspiré de google forms avec un menu déroulant pour les sections on pourrait avoir le même principe pour déplacer

[lisa-durand]

@Olivier-Marcellin en effet c'est une bonne idée - pour les illustrations de fleches j'imaginais qqchose comme un principe de double fleche ou une fleche avec un trait sur le haut/ bas pour differencier. Qqchose comme ça mais dans l'autre sens 😅

|<<| |<| |>| |>>|

[colinux]

Pour les icônes la doc du dsfr indique qu'on peut aussi ajouter n'importe quel icone du remix set http://remixicon.com (ils en ont juste intégrées quelques unes). Par contre j'ai regardé vite fait, ça semble pas si trivial à ajouter proprement (car on ne passe pas le système de build du dsfr qui créé toutes les classes), mais on peut trouver d'autres façons de faire

[Olivier-Marcellin]

je vous ai partagé la planche de conception avec deux pistes pour déplacer un champ tout en haut/bas ou dessus/dessous, à discuter asap https://www.figma.com/file/6iUaraN3yfDoJIJoSSNZPn/Styles-et-comportement-d%C3%A9placer-un-champ-%239603?type=whiteboard&node-id=0%3A1&t=Wuq9BRzgtcA7ZfY8-1

[lisa-durand]

@Olivier-Marcellin top - j'ai fait des commentaires dessus plus une suggestion de variante.

[lisa-durand]

Voila le dernier visuel - je l'ajoute à la description du ticket.

[Olivier-Marcellin]

oui on peut cependant il y a des fonctions sur ce design aujourd'hui qui ne sont pas activées : comme la fonction dupliquer le champ (=bloc) en haut à droite, et en bas la fonction sélectionner le champ (pour pouvoir supprimer plusieurs champs par exemple) ainsi que le nommage par numéro, j'ai un coup d'avance pour faire en sorte de faire évoluer ce champ tout en s'assurant que l'ergonomie est satisfaisante

[colinux]

Désolé mais je ne comprends pas pourquoi cette solution est privilégiée (alors qu'elle ne répond qu'à une fraction du besoin si on considère une démarche de 100 champs), sachant qu'on avait évoquait dans une autre issue (et maquetté il me semble) une solution qui gère l'ensemble des cas, basée sur une liste des champs dans un select (ou autocomplete), de type "déplacer après le champ …". (solution re-proposée par la culture récemment).

Je dis ça car il faudra de toute façon gérer tous les cas "intermédiaires" (déplacement en milieu de page), et qu'on ne va pas garder à terme 5 moyens de déplacer les champs. Bref, on peut en rediscuter avant de lancer ce chantier ?

[lisa-durand]

@colinux - il me semble qu'on avait pas été au bout des maquettes pour cette partie. Mais ça me va de plutot partir sur cette solution. Qu'en penses-tu @kara22 ?

[mfo]

Je pense qu'on peut se fier à la culture sur ce sujet. Les raisons : ils sont équipés d'ux/a11y, ils ont la volumétrie (quantité de démarche), l'experience (depuis longtemps), et leurs feedback vont 90% du temps dans la bonne direction.

Aussi, c'est "l'utilisateur" parfait [cf les échanges lors du FAST, les power user]. Ce qu'on avait identifié c'est qu'une personne au sein de la culture a impulsée la migration de "toutes" les démarches de la culture sur DS. Donc ce qu'ils en disent, pour moi c'est du pain béni (p-e à tord).

Bref sur ce sujet ils ont un avis,

cf: https://mattermost.incubateur.net/betagouv/pl/fxat6h69stydp81xh6gzth4zqe

PS: mon avis est qu'on peut virer le drag & drop, le deplacer 1 cran au dessus, 1 cran au dessous, deplacer tout en haut, deplacer tout en bas. On garde une option, un <select> (moins de code, moins de bugs, moins de maintenance).

[lisa-durand]

Je pense qu'on peut se fier à la culture sur ce sujet. Les raisons : ils sont équipés d'ux/a11y, ils ont la volumétrie (quantité de démarche), l'experience (depuis longtemps), et leurs feedback vont 90% du temps dans la bonne direction.

Aussi, c'est "l'utilisateur" parfait [cf les échanges lors du FAST, les power user]. Ce qu'on avait identifié c'est qu'une personne au sein de la culture a impulsée la migration de "toutes" les démarches de la culture sur DS. Donc ce qu'ils en disent, pour moi c'est du pain béni (p-e à tord).

Bref sur ce sujet ils ont un avis,

cf: https://mattermost.incubateur.net/betagouv/pl/fxat6h69stydp81xh6gzth4zqe

PS: mon avis est qu'on peut virer le drag & drop, le deplacer 1 cran au dessus, 1 cran au dessous, deplacer tout en haut, deplacer tout en bas. On garde une option, un <select> (moins de code, moins de bugs, moins de maintenance).

On a eu une discussion avec Colin à la suite de son message et on est parti la-dessus. Il y a donc un nouveau titre et une nouvelle description à cette PR.

[colinux]

Comme exprimé dans le texte de l'issue remanié, le <select> en soi va renforcer des pb de perfs sur un ordi "moyen" (potentiellement 200*200 = 40 000 options en + , alors que ça mouline déjà grave à cause des ceux du conditionnel, types de champ etc… qui sont plus light)). D'où l'approche proposée , qui revient fonctionnellement au même, avec une seule liste partagée grâce à notre super autocomplete, ou un input type datalist (On a écarté à court terme l'hypothèse de champ replié car ça soulève plein de questions d'ergonomie qui seront à traiter quand on le fera).

Par contre je garderais dans un premier temps le +1/-1, qui reste le plus efficace si on veut juste décaler d'un champ ou 2. Quitte à monitorer son usage et le virer si on voit que ça devient trop peu utilisé

[mfo]

J'ai demandé à @LeSim de retrouver un cas de problème de perf sur les fonds vert, mais on retrouve pas (dans l'attente il a pingé patrick).

Bref sans plus creuser, je me dis que gzip fera le taff de compréssion qu'est le sien. Que le moteur de rendu html fera le sien (il rendra pas les options, pas de repaint rien..). Donc que l'un dans l'autre ça va glisser sans anticiper de problème.

Je vous propose donc de faire moi même un poc ac cette solution naïve, si ça marche pas, revoyons l'implem ac cette idée de data list (que je connais pas trop, je pousse juste un standard).

Qu'en pensez vous ?

[colinux]

Je suis chaud pour essayer (c'était mon idée première), mais je me dis que la page laggant/freezant déjà complètement dans certains cas, là ajouter des milliers d'éléments ne va qu'aggraver la situation (même sans repaint, c'est de la gestion de mémoire), alors qu'on se dit qu'il faut alléger cette page, donc je me dis autant partir de suite sur un autocomplete ou un élément datalist.

Par ex, sur la démarche 78125 qui n'est que "moyenne" en taille (140 champs, un peu de conditionnel), même sur mon M1 sous ff, parfois la page est blanche pendant 3 sec (quand j'ajoute un champ ou que je scroll , bref dès que le navigateur doit recalculer des positions ou chercher un id) avec le message "cette page ralentit firefox, arrêtez cette page pour accélérer l'ordinateur". Et la conso mémoire de ff grimpe à plusieurs Go. UPDATE: pour relativiser, les ralentissements sont surtout pendant que la page se charge, ce qui prend environ ~10s chez moi. Ça va mieux après, mais ça veut quand même dire qu'il faut déjà attendre plusieurs secondes pour utiliser la page, sur un ordi performant.

La page fait déjà presque 2 mo, a environ 30 000 éléments dont 6500 option dans le DOM, donc je me dis qu'en rajouter de (dizaines) de milliers ne peut qu'empirer les choses. (pour info lightouse génère une erreur au-delà de 1400 éléments) Faudrait essayer sur Edge sur un PC "moyen" avec 4 ou 8go de ram, ptet sous browserstack ou pc de prod ?

[mfo]

testé via browserstack, ca glisse le scroll/ajout d'element (on avait pris cette demarche justement ac lesim). C'est tjr d'actualité chez toi (j'ai en tête que le prob est p-e ailleurs) ?

suis pas un ouf de la perf, mais ffx me dit que la page pese ±70mo en mémoire

les options representant 4% de la conso mémoire

PS: on a les fonds vert qui vont utiliser l'editeur de manière intensive a partir du 18/12 (cf: https://mattermost.incubateur.net/betagouv/pl/t9zope9d8jfr5ejna9bngzga3a). jvais lui proposer de simuler ce qu'il a a faire... on aura p-e une piste de cmt la perf vient a être nul ?

[colinux]

Oui j'ai testé ce matin justement, la page est presqu'inutilisable les première secondes pendant l'ouverture, car j'ai un load entre 8 et 10s (temps de téléchargement inclus dans ma campagne). Le fait d'enlever les listeners du drag & drop peut ptet compenser ? Le truc qui me chiffonne un peu c'est qu'on essaie d'alléger cette page pour la rendre plus réactive, et là j'ai l'impression que le select va dans l'autre sens (même si fonctionnellement c'est surement la meilleure solution en regroupant les champs par section). En tout cas GO pour essayer et re-tester sur un navigateur plus réaliste pour voir l'impact réel.

[mfo]

trop optimiste cette histoire de gzip / select / options : on double le poid de la page ac un select classique avant:

ap:

et la memoire prends 30Mo av:

ap:

a noter, sur ma machine ça n'a pas l'air de poser de problème.

[mfo]

Le POC ac du datalist n'est pas convaincant pour des raisons d'UX (pas possible a styler) Le POC ac l'autocomplete actuel n'est pas non plus convaincant pour des raisons d'UX (la liste est vide).

J'en reviens au <select>, mais cette fois ci ac du lazyloading, p-e que ca va passer qui sait ? :D