Option "autre" pour le suggester

[Grafikart]

Description

Dans le cas de certains formulaire il faut pouvoir entrer une valeur arbitraire pour un champs de type suggester. Cette issue présente les différentes solutions possible techniquement avec leur avantage / inconvénient.

Solutions

• Valeur arbitraire
• Valeur "autre"
• Valeur "autre" dans le composant ✅ (option retenue)

Valeur arbitraire

Cette solution consiste à permettre à l'utilisateur de taper une valeur arbitraire dans le champs qui sert actuellement de recherche.

La valeur (texte) se retrouve dans la réponse.

Avantages :

• Nécessite que peu de changement niveau JSON

Inconvénients

• Complexe à mettre en place
• Pas clair au niveau de l'interface (une recherche qui devient une valeur)
• Une analyse est nécessaire pour savoir si la valeur est dans la liste ou non
• Impossible de mettre une condition pour savoir si l'utilisateur a choisi un élément dans la liste

Valeur "autre"

Cette solution consiste à ajouter une option supplémentaire dans les suggestions qui permet à l'utilisateur d'indiquer que la valeur de la liste ne lui convient pas.

Cette option serait toujours visible en dernier et sauvegarderais dans la réponse "OTHER". Il serait ensuite possible d'utiliser cette valeur pour conditionner l'affichage d'un autre chammps via un condition filter.

{
    "componentType": "Suggester",
    "response": {
        "name": "PAYS"
    },
+       "arbitrary": {
+             "value": "OTHER",
+            "label": "Autre valeur",
+       },
    "storeName": "L_PAYS-1-2-0",
    "id": "lt4fjoev",
    "page": "2",
    "label": {
        "type": "VTL|MD",
        "value": "\"Pays de résidence :\""
    }
},
+{
+   "componentType": "Input",
+   "response": {
+       "name": "PAYS_AUTRE"
+   },
+       "conditionFilter": {
+          "type": "VTL",
+          "value": "PAYS = \'OTHER\'"
+    },
+   "id": "lt4fjoec",
+   "page": "2",
+   "label": {
+       "type": "VTL|MD",
+       "value": "\"Autre pays : \""
+   }
},

Une option supplémentaire pour

Avantages :

• Simple à mettre en place (réutilise l'existant)

Inconvénients

• Nécessité de rajouter un champs sur la même page que le suggester avec la condition.
• 2 champs dans le traitement des données (peut être un avantage pour différencier autre / non autre)

Valeur "autre" dans le composant

Cette solution consiste à ajouter une option supplémentaire dans les suggestions qui permet à l'utilisateur d'indiquer que la valeur de la liste ne lui convient pas. Mais la gestion du champs supplémentaire se ferait dans le composant suggester

Cette option serait toujours visible en dernier.

{
    "componentType": "Suggester",
    "response": {
        "name": "PAYS"
    },
+        "arbitrary": {
+           "response": {"name": "PAYS_AUTRE"},
+           "label": "Mon pays n'est pas dans la liste",
+           "inputLabel": "Entrez votre pays de résidence"
+        }
    "storeName": "L_PAYS-1-2-0",
    "id": "lt4fjoev",
    "page": "2",
    "label": {
        "type": "VTL|MD",
        "value": "\"Pays de résidence\""
    }
},

Avantages :

• Modification du model plus simple que la solution précédente

Inconvénients

• Modification plus importante du composant suggester
• 2 champs dans le traitement des données
• 2 champs dans le traitement des données (peut être un avantage pour différencier autre / non autre)

@Grafikart : merci beaucoup pour ces explications : on est d'accord que l'ajout de ce Autre (que ce soit dans la solution 2 ou 3) n'est pas une option mais est systématique et que la différence (coté métier stat) entre 2 et 3 est "juste" sur le fait que la demande de précision est au choix du concepteur (cas 2) ou systématique (choix 3) ?

[Grafikart]

@AnneHuSKa Ce n'est pas systématique, ce "autre" ne sera ajouté que si il y a un "arbitrary" de précisé. En l'absence d'arbitrary cette option ne sera pas présente.

Pour le second point, c'est exactement ça. Le cas 2 permettrait au concepteur de demander des précisions avec plusieurs champs par exemple.

[romaintailhurat]

Option 3 est la bonne !

[romaintailhurat]

On souhaiterait plutôt partir sur la proposition de @jdirand

On garde le principe d'activer ou non la captation de la saisie arbitraire avec le paramètre ad hoc mais dans le cas où cette saisie est permise, l'UX est différente (cf. colonnes 5 et 6, ligne 2).

NB on enregistre toujours la saisie arbitraire dans la variable précisée dans arbitrary > response

[AnneHuSKa]

@Grafikart : échanges avec @jdirand pour nouvelle proposition si possible

[laurentC35]

Ajouter la notion arbitrary dans Eno

[AnneHuSKa]

Trop cher donc repartir sur un nouveau champ @Grafikart