Présentation des modèles de formulaires expérimentaux

Bonjour, communauté Discourse Meta !

Nous sommes ravis de vous présenter une nouvelle fonctionnalité expérimentale, les modèles de formulaire. Ils vous permettent d’imposer un formulaire structuré avec validation des données dans le flux de création de sujets.

multiple_form_templates

Activation de la fonctionnalité

La fonctionnalité est masquée derrière un indicateur expérimental global. Pour l’activer, il suffit d’activer le paramètre de site experimental_form_templates dans :wrench: Admin ▸ Paramètres.

Gestion des modèles

Les modèles de formulaire peuvent être créés, modifiés et supprimés dans :wrench: Admin ▸ Personnaliser ▸ Modèles (/admin/customize/form-templates/).

Vous y trouverez un tableau listant les modèles existants sur le forum. Vous pouvez modifier, supprimer et prévisualiser n’importe quel modèle existant, ou en créer de nouveaux. Le tableau indique également les catégories dans lesquelles chaque modèle est actuellement actif.

Les modèles sont définis dans une structure YAML. Vous pouvez les saisir manuellement, ou utiliser les boutons “Ajouter” en haut, qui ajouteront un extrait de code YAML à la fin, définissant un certain type d’entrée.

Voici un exemple YAML complet, avec tous les types de champs :

- type: input
  id: name
  attributes:
    label: "Nom complet"
    placeholder: "ex. Jean Dupont"
    description: "Quel est votre nom complet ?"
  validations:
    required: true
    minimum: 2
    maximum: 100
- type: textarea
  id: introduction
  attributes:
    label: "Introduction"
    placeholder: "Une courte introduction"
    description: "Écrivez une courte introduction sur vous-même"
  validations:
    required: true
    minimum: 10
    maximum: 500
- type: dropdown
  id: fav-animal
  attributes:
    label: "Animal préféré"
    description: "Sélectionnez votre animal préféré"
    none_label: "Sélectionnez une option"
  choices:
    - "Chien"
    - "Chat"
    - "Autre"
  validations:
    required: true
- type: multi-select
  id: comm-channel
  attributes:
    label: "Canaux de communication :"
    description: "Sélectionnez vos canaux de communication préférés :"
    none_label: "Sélectionnez une option"
  choices:
    - "Email"
    - "Téléphone"
    - "Messagerie"
- type: upload
  id: cat-photo
  attributes:
    label: "Photo de chat"
    description: "Envoyez une photo de votre chat (ou de n'importe quel chat)"
    file_types: ".jpg, .png"
    allow_multiple: false
- type: checkbox
  id: accept-terms
  attributes:
    label: "J'ai lu et j'accepte les conditions"
    description: "Vous devez accepter les conditions pour continuer"
  validations:
    required: true

Validations

Pour chaque champ, vous pouvez ajouter des options de validation qui doivent être satisfaites avant de pouvoir créer le formulaire. Pour une liste des validations disponibles, cliquez sur le bouton :kbd:Validations au-dessus de l’éditeur de code. Cela vous montrera la syntaxe de chaque option de validation et décrira son utilisation prévue.

Options de validation

Clé Type Description
required boolean Oblige à remplir le champ pour soumettre le formulaire
minimum integer Pour les champs de texte, spécifie le nombre minimum de caractères autorisés
maximum integer Pour les champs de texte, spécifie le nombre maximum de caractères autorisés
pattern regex string Pour les champs de texte, une expression régulière spécifiant l’entrée autorisée
type string Pour les champs de saisie, vous pouvez spécifier le type d’entrée attendu (text|email|date|number|url|tel|color)

Application d’un modèle à une catégorie

Une fois que vous avez créé un modèle de formulaire, vous voudrez l’appliquer à une catégorie. Pour ce faire, rendez-vous dans les paramètres de la catégorie à laquelle vous souhaitez appliquer le modèle.

Sélectionnez le menu :kbd:Modèle, puis sur la droite, utilisez le commutateur pour activer les modèles de formulaire. Une fois activé, vous pouvez utiliser le menu déroulant pour ajouter un ou plusieurs modèles à une catégorie.

Remplissage du formulaire

Une fois qu’un modèle a été appliqué à une catégorie, le formulaire du modèle apparaîtra automatiquement lorsque vous créerez un sujet et sélectionnerez la catégorie qui a le modèle. Si la catégorie a plus d’un modèle attribué, vous verrez également un sélecteur pour basculer entre les modèles disponibles.

Lors du remplissage du formulaire, il respectera les validations spécifiées dans la définition du modèle de formulaire, et ce n’est qu’après qu’il sera valide que vous pourrez cliquer sur :heavy_plus_sign: Créer un sujet, et cela générera le contenu du sujet à partir de tous les champs saisis.

Enfin, après la soumission, le contenu du sujet est composé de tous les champs remplis :

Pré-remplissage des valeurs du formulaire

Vous pouvez également pré-remplir les valeurs du formulaire en appelant /new-topic avec des paramètres correspondant aux identifiants de champ définis dans le modèle de formulaire. Par exemple, pour le modèle utilisé précédemment comme exemple :

/new-topic?name=Jean%20Dupont&favorite-animal=Chat

Feuille de route

  • Stocker la sortie JSON dans les données du sujet lors de la création d’un sujet
  • Option pour pouvoir toujours sélectionner et utiliser le compositeur libre sur les catégories avec des modèles de formulaire

Comment vous pouvez nous aider

Nous aimerions connaître votre avis sur cette nouvelle fonctionnalité. Si vous êtes administrateur et que vous souhaitez l’essayer sur votre forum, vous pouvez activer le paramètre experimental_form_templates et commencer à les utiliser immédiatement !

Veuillez créer de nouveaux sujets tagués form-templates pour partager vos expériences, signaler tout bug ou faire des suggestions.

Merci de nous aider à améliorer Discourse !

84 « J'aime »

Cela semble très utile et je vais certainement l’activer pour expérimenter.

Une chose qui me serait utile est la possibilité de lier un champ de modèle à un champ personnalisé de l’utilisateur. Par exemple, dans une catégorie de support, les deux premières questions généralement posées par les agents de support sont « Modèle de l’équipement » et « URL du site Web » associé. Avec cette fonctionnalité de modèle, je peux maintenant demander ces informations à chaque création de nouveau sujet :smiley:

Ces deux informations sont également généralement d’intérêt pour les autres utilisateurs, elles sont donc définies comme des champs personnalisés de l’utilisateur, qui sont parfois remplis. Si les champs de modèle pouvaient être remplis à partir d’un champ personnalisé de l’utilisateur lié (s’il a une valeur), alors pour les utilisateurs fréquents, ils peuvent remplir leurs champs utilisateur et ne pas avoir à remplir les champs de modèle à chaque fois. Les utilisateurs occasionnels peuvent simplement remplir les champs de modèle au besoin pour obtenir de l’aide.

Comme suggestion supplémentaire, la cerise sur le gâteau serait que le lien fonctionne dans l’autre sens. Si quelqu’un saisit des données dans le modèle qui ne se trouvent pas dans le champ personnalisé lié, le champ personnalisé est mis à jour lors de la publication du sujet.

13 « J'aime »

Bonjour :wave:

C’est l’une des meilleures améliorations. Elle offre tellement d’opportunités. :heart_eyes:

Quelques remarques :

  1. Il semble que la chaîne form_templates.errors.valueMissing.number soit manquante.

  2. Il semble que la validation tel ne fonctionne pas.

  3. Sur mobile, le modèle de formulaire dans le compositeur n’est pas déroulable.

  4. Sur mobile, lorsque le modèle de formulaire est disponible, les boutons du pied de page ne font rien. Je pense qu’il serait bon de les masquer.
    Screenshot 2023-10-17 at 8.04.50

+ Il serait utile d’ajouter une validation pour empêcher les nombres négatifs au type number. Cas d’utilisation (prix) :slightly_smiling_face:

+ Il serait également utile d’ajouter une fonctionnalité de champs conditionnels dynamiques.


Merci :slight_smile:

15 « J'aime »

Comme mentionné précédemment, cela sera très utile dans les contextes de support et j’apprécie particulièrement les suggestions de @packman concernant les champs utilisateur personnalisés.

L’ajout de modèles de formulaires aux groupes est-il également prévu (ou pourrait-il l’être) ? Lorsque la messagerie de groupe est utilisée pour le support privé, cela sera particulièrement utile pour pré-remplir les questions avant qu’un membre du personnel n’arrive.


Selon la visibilité du champ personnalisé, cela pourrait avoir des implications en matière de confidentialité. Par exemple, l’utilisateur pourrait choisir de partager les informations via un modèle de formulaire dans une catégorie privée, mais ne pas vouloir partager ces informations avec la communauté au sens large via son profil.

Selon la nature des informations, il pourrait également y avoir une valeur appropriée pour son profil et/ou la plupart des formulaires, mais il pourrait vouloir fournir une valeur différente dans un cas particulier.

J’aime l’idée de remplir le formulaire à partir de ces champs et de pouvoir mettre à jour les champs si les valeurs saisies diffèrent, mais peut-être que cela devrait être une invite. Ceci est une maquette très rapide et rudimentaire, mais peut-être quelque chose dans ce sens après la création du sujet (uniquement si une valeur diffère et éventuellement uniquement si elle n’est pas vide) :

8 « J'aime »

Ma demande de fonctionnalité pour cette excellente nouvelle fonctionnalité est, je crois, courante sur les forums de support logiciel.

Les gens négligent de spécifier leur version du logiciel. C’est tout. Simple, mais c’est la cause de nombreux, nombreux échanges inutiles qui sont lassants pour les personnes qui aident beaucoup de monde (et nous ne voulons pas fatiguer les personnes les plus importantes de la communauté).

Je voudrais donc un formulaire pour demander :

  • Votre version de FabulousApp est… (liste déroulante avec options)
  • Votre version de PHP est… (liste déroulante avec options)

Maintenant, supposons que quelqu’un publie fréquemment sur les forums. Ces informations ne changent pas fréquemment, bien qu’elles puissent changer, disons, une fois par mois.

Le formulaire doit conserver les valeurs que le même utilisateur a sélectionnées dans son message précédent, comme valeurs par défaut, c’est là ma demande de fonctionnalité. Qu’en pensez-vous ?

5 « J'aime »

Je pense que dans certains cas, un champ pré-rempli peut amener les utilisateurs à l’ignorer et à ne pas modifier la valeur lorsque c’est nécessaire. :thinking:

Purement spéculatif, cependant.

10 « J'aime »

Ces deux éléments combinés sont ce que j’aimerais voir pour mon cas d’utilisation. Avec plusieurs applications, je veux que l’utilisateur puisse sélectionner son application, puis sélectionner sa version dans une liste qui correspond à cette application.

C’est certainement mon expérience pour les choix. Avec une valeur par défaut sur un formulaire de contact par e-mail, la grande majorité des soumissions ont cette valeur par défaut, quelle que soit l’application ou la version qu’ils utilisent réellement.

3 « J'aime »

C’est probablement vrai pour les valeurs par défaut, mais dans ce que j’ai imaginé, les valeurs des champs seraient celles précédemment saisies par l’utilisateur dans ses champs personnalisés. Celles-ci pourraient être anciennes/obsolètes, mais je pense que dans mon cas d’utilisation, il y aurait beaucoup moins de valeurs erronées qu’il n’y a actuellement de valeurs nulles.

2 « J'aime »

Absolument. À mon avis, ce sont surtout deux catégories d’informations différentes : l’état à un instant T et la préférence/identité de l’utilisateur/etc. Ce à quoi je faisais référence avec mon expérience des valeurs par défaut concernait davantage le premier cas.

2 « J'aime »

Deux requêtes !

  1. Un champ de code qui encadre automatiquement le contenu avec ```
    • Il pourrait avoir un menu déroulant pour la langue, avec une valeur par défaut.
  2. Un attribut qui permet aux utilisateurs de dupliquer un champ (j’imagine un bouton + sous ce champ).
    • Imaginez si un utilisateur veut publier deux blocs de code, ou plusieurs images. Il peut en saisir un, cliquer sur le + et en ajouter un autre.
16 « J'aime »

C’est une nouvelle fonctionnalité intéressante, et potentiellement bien choisie pour un projet sur lequel je travaille.

Après l’avoir brièvement testée, j’ai deux questions :

  1. Actuellement, lorsque l’utilisateur modifie un article de sujet qu’il a créé via un modèle de formulaire, il affiche simplement l’éditeur d’article par défaut.
    Est-il prévu d’afficher également l’éditeur de modèle de formulaire lors de la modification d’un article ?

  2. Y aura-t-il une option pour ajouter des types d’entrée personnalisés ?
    Je pense à une carte où un utilisateur peut sélectionner son emplacement en plaçant une épingle sur la carte. Il serait donc bon d’avoir la possibilité de définir de tels types de champs personnalisés.

4 « J'aime »

C’est le moment idéal pour mon cas d’utilisation ! Je me demande s’il est prévu de permettre à terme la personnalisation de la façon dont un modèle de formulaire est rendu dans un sujet.

Par exemple, dans l’image suivante, le type de champ checkbox est rendu comme le texte on :

Quelqu’un pourrait-il à terme mapper les types de champs de formulaire à une sortie personnalisée ?

Par exemple, dans mon cas, je veux qu’une case à cocher cochée/on corresponde au formatage de la case à cocher, [x], et l’absence de coche/état désactivé à []

Je vais peut-être devoir commencer à apprendre le ruby et à bidouiller ce projet, cette mise à jour des formulaires m’a donné plein d’idées intéressantes. Merci pour l’excellent travail les gars !

3 « J'aime »

C’est une excellente façon d’imposer un comportement dans une catégorie particulière (mon point sensible était la publication d’offres d’emploi, où tout le monde publiait comme il l’entendait :smiley: ) !

Un ensemble de fonctionnalités supplémentaires serait apprécié :

  • la possibilité de « passer à aucun modèle » (facultatif). Ce serait bien de pouvoir le limiter par utilisateurs, par niveau, par groupe, etc. ; Une sorte de « fais-moi confiance, je sais ce que je fais ! »
  • plusieurs champs sur la même ligne (pensez prénom + nom). Une correction suffisamment bonne serait de permettre aux administrateurs de définir un nom de classe pour le modèle de formulaire ;
  • un répéteur (c’est-à-dire regrouper un ensemble de champs et permettre aux utilisateurs d’en ajouter d’autres) ;
7 « J'aime »

Il serait bon d’avoir la possibilité de :

  • Coller du contenu dans un champ de téléchargement[^1].
  • Ajouter un compositeur en plus de la zone de texte, où les utilisateurs ont accès à la suite normale des fonctionnalités[^2].

[^1] : La fonctionnalité de téléchargement dans les publications Discourse est excellente. Celle-ci est plus difficile à utiliser, nécessitant par exemple que les images soient déjà enregistrées sur le disque.
[^2] : Si je veux qu’un utilisateur sélectionne une liste déroulante en plus d’une publication, avec l’approche actuelle (une zone de texte), je diminue considérablement sa capacité à créer sa publication normalement ; pas de collage d’images, pas de barre d’édition, etc.

9 « J'aime »

J’ai essayé le formulaire ici pour signaler un bug concernant le thème. Voici mes commentaires :

  • Le formulaire en lui-même est une excellente idée :+1:
  • L’absence d’outil de mise en forme est un gros problème.
    • Même si la syntaxe markdown est basique, sélectionner et utiliser la barre d’outils est souvent plus facile/rapide. Cela aide à créer un message lisible.
    • Cela peut fonctionner si le rapport est un problème simple mais avancé ; vous pourriez avoir besoin de masquer les détails ou d’insérer un tableau.
  • L’absence de téléversement en ligne n’est pas pratique.
    • Par exemple, montrer un problème étape par étape, avant/après les résultats, etc.
    • En cas de captures d’écran multiples, vous devez expliquer quelles captures d’écran vous devez regarder.
  • Comme Thomas, coller une image serait apprécié. J’ai mis du temps à comprendre où mes captures d’écran étaient enregistrées. :smile:
  • Entrée conditionnelle – lors de la sélection de “autre”, il serait agréable qu’une entrée apparaisse pour cela.

Dans l’ensemble, très bien ! J’attends avec impatience les améliorations. :slight_smile:

9 « J'aime »

Si vous avez plusieurs formulaires activés pour une seule catégorie, il n’est pas intuitif qu’il y ait une liste déroulante pour sélectionner un formulaire. Lorsque vous créez un nouveau sujet, il remplit automatiquement le premier modèle de formulaire, ce qui, encore une fois, si vous ne savez pas ce que vous regardez, vous ne réaliserez pas qu’il pourrait y avoir d’autres formulaires.

Lorsque vous désélectionnez le formulaire, vous voyez le texte « Sélectionner des modèles de formulaire », ce qui me fait clairement comprendre qu’il y a une liste de formulaires parmi lesquels je peux choisir. Le compositeur affiche toujours le formulaire même si aucun n’est sélectionné. C’est là que je rejoindrais @iamntz sur la possibilité de passer à aucun modèle.

6 « J'aime »

Je tiens juste à ajouter à ma réponse précédente et à donner un peu plus de contexte à notre cas d’utilisation spécifique. Nous cherchons à implémenter cela dans notre catégorie de commentaires sur le site. Idéalement, nous voulons des modèles de formulaires pour des choses comme la demande d’étiquettes, et garder le compositeur par défaut (aucune option de modèle), si le formulaire n’existe pas ou ne fait pas le travail correctement.

Donc, ce que nous imaginons serait de créer un nouveau sujet dans la catégorie et de voir ceci :

À partir de là, voir « Sélectionner les modèles de formulaires », où vous pouvez soit composer normalement, soit voir que des formulaires existent dans cette catégorie pour des demandes/commentaires standardisés. :slight_smile:

Je peux comprendre l’argument selon lequel certains utilisateurs ne verront pas ou n’utiliseront pas le modèle de formulaire, s’ils peuvent composer, mais j’essayais de rester dans le style actuel avec le texte d’espace réservé à l’intérieur du champ au lieu d’une étiquette à l’extérieur du champ. Mais c’est pourquoi il pourrait s’agir d’une fonctionnalité facultative que les administrateurs activent/désactivent. :upside_down_face:

4 « J'aime »

Si le bouton de sélection était clairement mis en évidence, il serait beaucoup plus facile d’encourager les utilisateurs à cliquer dessus, à l’instar de votre bouton Créer un sujet.

3 « J'aime »

Après avoir expérimenté davantage avec les formulaires, nous avons découvert qu’une solution de contournement pour une option « aucun modèle » consisterait à créer un simple formulaire de « réponse libre » qui pourrait servir de « aucun modèle » (comme le montre la capture d’écran ci-dessous).

Pour ajouter à cette idée, si nous ne voulions pas changer la couleur pour mettre en évidence la liste déroulante, je pense qu’ajouter une flèche vers le bas serait un indicateur utile qu’il existe une sélection déroulante, tout comme la liste déroulante des catégories.

Nous avons découvert que les formulaires sont classés par ordre alphabétique. Ce serait formidable d’avoir la possibilité de réorganiser les formulaires ou l’option de sélectionner le formulaire par défaut qui devrait apparaître lors de la création d’un nouveau sujet.

Inutile de dire que nous aimons ce que cette fonctionnalité a à offrir et serions ravis de telles améliorations. :slight_smile:

6 « J'aime »

Peut-être que je l’ai manqué, mais y a-t-il un moyen d’avoir un hyperlien dans un formulaire ? Par exemple, disons que nous avions une case à cocher pour les termes et conditions. Dans la description, il serait utile d’avoir un hyperlien vers les termes et conditions réels.

Est-ce déjà possible ?

Y a-t-il également un moyen de pré-remplir automatiquement le champ titre lorsque l’utilisateur crée un nouveau message, par exemple avec son nom d’utilisateur, ou même juste un titre par défaut ?

8 « J'aime »