Votre avis pour les champs de formulaires Bazar : cacher les identifiants de champ?

Développement Général
#1

Bonjour,
Suite au sprint de développement des Landes début juin, @Seballot a entamé une refonte des champs de formulaires pour facilement mettre des champs avancés cachés par défaut.

@gatienbataille et @furax37 , en tant que product-owner , m’ont fait part de l’idée de cacher par défaut le champ identifiant qui n’est pas très intuitif pour les profanes.

Je voulais vous sonder sur 3 options possibles, avec mes commentaires subjectifs (n’hésitez pas a compléter dans la discussion) :

  1. cacher le champ identifiant dans les paramètres avancés :
  • avantages : moins de champs a remplir, moins d’identifiants exotiques car pas compris, facile a mettre en place
  • désavantages : les champs n’auraient pas beaucoup de sens sémantique s’il ne sont pas modifiés dans les paramètres avancés (les champs textes s’appelleraient bf_texte, bf_texte2,… bf_date, bf_date2, etc…)
  1. cacher le champ identifiant dans les paramètres avancés, mais générer automatiquement des identifiants en se basant sur le label :
  • avantages : moins de champs a remplir, moins d’identifiants exotiques car pas compris, les identifiants feraient sens
  • désavantages : difficile a programmer (il faut gérer des cas, par exemple lors du changement de label)
  1. laisser le champ identifiant visible :
  • avantages : rien a programmer
  • désavantages : la confusion et le nombre important de champs à saisir restent

Qu’en pensez vous?

    1. on cache les identifiants dans les paramètres avancés, c’est déja mieux
    1. on génère les identifiants automatiquement, quitte a y passer du temps
    1. on reste avec les identifiants visibles

0 votant

Merci d’avance!

2 « J'aime »
#2

cachés mais accessible pour ceux qui veulent des identifiants plus « concrets » ou « adaptés » aux templates, (ça reste possible de modifier dans param avancés), pour les autres ça évite les boulettes

#3

Du mal à répondre (ou alors la 3ème option) parce que je n’ai pas rencontré ce frein pédagogique. j’aime bien expliquer qu’il y a le « nom pour le robot » / « le nom pour les humain·es » : pour l’ID du formulaire / son nom, pareil pour les listes, pareil pour les valeurs dans les listes … Mais peut-être compliqué pour découverte en autonomie.

#4

De même que Louise, je ne rencontre pas de problème pédagogique à expliquer la différence entre le nom pour la machine (identifiant unique) et le libellé destiné aux humains normaux. Cela est encore plus vrai depuis l’amélioration des libellés des paramètres :+1:

J’ai même constaté que laisser voir aux utilisateurs ce qui se passe dans ce paramètre identifiant unique les met en capacité de mieux comprendre ce que fait YesWiki et surtout leur permet d’aller plus loin (pour des query par exemple) plus facilement. On peut faire un parallèle avec le fait de montrer le code dans l’édition des pages YesWiki.

La solution consistant à générer les identifiants sur la base du libellé me semble être une Fausse Bonne Idée (FBI) : compliqué à développer, à maintenir pour un résultat qui sera toujours discutable :wink:

#5

C’est pas parce que ce sera caché dans les options avancées qu’il n’y aura plus a l’expliquer en formation, hein!
C’est plus un travail sur l’expérience utilisateurice : limiter le nombre de chose à remplir pour soulager l’interface et la charge mentale associée a l’apprentissage de tous les concepts liés.

#6

Je suis assez d’accord avec Louise et Sylvain. Leur explications lors de la formation Gare Centrale étaient claires pour moi et il est vrai que cela me permet de comprendre un peu (n’ayant aucune expérience de programmation) ce qui se passe en coulisses. Parfois cela m’a aidé aussi de pouvoir distinguer entre deux champs similaires en regardant les identifiants de champ, mais je vois bien que cette option sera toujours disponible en mode avancée, même si vous choissisez de les cacher. Donc « ne sais pas » vraiment et j’ai voté laissé tel quel, mais les 2 autres options me vont aussi!

#7

Bonjour, je ferme ce sondage après 2 semaines, ya pas eu foule de vote, mais on va prendre en compte le résultat pour la version 4.5 de yeswiki, sachant que rien n’est gravé dans le marbre: si a l’usage ca trouble plus que cela ne facilite, on fera marche arrière!
Merci d’avoir pris le temps de voter et d’en discuter!