Ergonomie de la configuration des traitements #113

Sur le site où j'utilise principalement formidable, j'ai 5 traitements différents (sic !)

Enregistre en base
Email
Inscription evenement
Inscription liste
Paiement

Lorsque je veux modifier la config de 1 traitement, je galère pas mal avec cette longue liste, surtout que bien souvent il s'agit d'une liste de champs qui permette de configure tel ou tel réglage.

Il faudrait sans doute rerflechir à la présentation.

Une piste que je verrais, comme cela c'est

Regrouper en haut la liste des traitements
Lorsqu'un traitement est cohée, il apparait
A ce moment là, on peut cliquer dessus pour afficher/masquer les paramètres du traitement.

OU BIEN on fait en multiétape.

+1

Même avec 2 traitements, si le 1er a plein de champs c'est galère.

Ou des onglets ? Ca évite de devoir défiler. Et avec une couleur ou quelque chose pour identifier s'ils sont activés ou pas. Une fois dans l'onglet, la 1ère case c'est pour l'activer.

Si onglet, alors il faut les faire verticaux, en tout cas il faut pas avoir à défiler

Pourquoi il "faut" pas avoir à défiler, comme si tu configurer 12 fois le même formulaire dans la même journée. Ce qu'il faut c'est ne pas scroller pour voir le menu des traitements choisie et pouvoir alterner entre chacun, quand t'as fini d'en configurer un, tu remontes au menu et tu en configures un autre. Mais quand t'es en haut tu peux voir tout et alterner entre les onglets sans devoir chercher chacun au milieu de la page. Bref il me semble que les onglets déjà actuels suffisent pour ce cas. Par contre je mettrais les cases à cocher pour choisir lesquels activer en haut avant, surtout pas dans chaque onglet, et ensuite ça ne doit faire apparaitre que les onglets de ceux qu'on a coché.

Je parlais du défilement horizontal des onglets comme on a actuellent dans les saisies si tu a plein d'onglet : pour les voir, faut défiler vers la droite. C'est en sens là que tu ne dois pas avoir à défiler
Indépendemment de cela en fait le fait voir d'un coup TOUT les traitements, si jamais tu dois modifier 1 traitement, bah c'est très vite galère de trouver la config de ce traitement, car tu a un liste longue comme un bras de traitements avec leurs options. Ex : ce matin j'ai ajouté un champ, qui avait des conséquences pour 3 des 5 traitements. Le fait d'avoir ainsi plein de chose visible d'un coup a fait que j'ai du repasser deux fois sur chacun des traiments pour m'assurer de n'en avoir oublié aucun. J'aurai pu avancer (d'une manière ou d'une autre) traitement par traitement, cela aurait été plus simple.
Par contre je mettrais les cases à cocher pour choisir lesquels activer en haut avant, surtout pas dans chaque onglet, et ensuite ça ne doit faire apparaitre que les onglets de ceux qu'on a coché.
-> moi j'ai toujours été pour ca, il me semblait même avoir mis une requete il y a quelque temps en ce sens, qui n'avait pas été chaudement accueillie. Mais ca me va bien de changer :)

j'ai demandé l'avis à une personne qui règle svt des formulaires chez nous

Maïeul : tiens j'en profite, on a une petite reflexion en cours sur l'ergonomie de la config des traitements de formulaire
si jamais tu as des choses à dire à ce sujet
Z
le scrolling qui peut etre assez long si t'as déjà param ton form
ptet faire des onglets plutôt que des rubriques

J'ai testé les onglets sauf qu'il y a des bugs :

Quand à un même niveau il y a des fieldsets onglets ET d'autres champs, alors le bloc conteneur .saisies-onglets qui entoure tous les onglets (la nav + les contenus), se place TOUJOURS avant tout, même si les autres champs sont avant ! Ça ne devrait pas, s'il y a d'autres champs avant, ça doit rester avant.
Quand on met des afficher_si sur des fieldsets qui sont en mode "onglet=oui", ça n'est pas pris en compte du tout dans la nav : les onglets à cliquer justement ne devraient apparaitre que quand le afficher_si est ok, donc ça veut dire qu'il faut détecter si le contenu afférent est visible et n'afficher l'onglet à cliquer seulement si c'est bien le cas, et inversement quand c'est caché. Qu'en gros le script de "détection" des onglets soit relancé/mis à jour à chaque fois que des fieldsets ayant data-saisies-onglet ont leur visibilité changée.

Pour le afficher_si : après l'application du test d'afficher_si, on a un trigger change qui est executé. On pourrait imaginer de mettre en plus un trigger afficher_si, ce qui permettrait d'ajuster les onglets à chaque afficher_si, mais pas à chaque change.

Cela étant, je continue de penser que les onglets, tels qu'ils sont actuellement, avec un defilé horizontal si on a des textes trop long, ne sont pas adaptés.

Par ailleurs, j'ai remarqués que formidable insère cela sur

<script type="text/javascript">/*<![CDATA[*/
if (window.jQuery){
function debloquer_prive(){ jQuery('input[required], textarea[required], select[required]').removeAttr('required'); }
jQuery('document').ready(debloquer_prive);
onAjaxLoad(debloquer_prive);
}
/*]]>*/</script>

Si on passe en afficher_si on pourrait s'en passer, car afficher_si s'occupe de cela, et saisies à son propre mecanisme lors de la config d'une saisie pour ne pas être bloqué par les required.

Intégré sous forme d'onglet verticaux en b84c08fd88.