web-dev-qa-db-fra.com

Contrôle d'entrée et concept de valeurs par défaut

Je travaille sur une application dont le but est de modifier les données d'un domaine spécifique. Le domaine a un concept de valeurs par défaut/héritées.

Par exemple:

  • Disons que j'ai un contrôle avec une zone d'édition pour modifier la propriété d'un élément nommée Index qui est un entier.
  • Je peux sélectionner l'élément A et entrer 10
  • Je peux sélectionner l'élément B et saisir 15

C'est facile. Mais disons que le point B "hérite" du point A.

  • Lorsque je sélectionne l'élément B, la zone d'édition ne doit pas être vide et me montrer la valeur héritée du parent donc 10.
  • Je peux encore modifier la valeur et mettre 15

Ça va. Mais disons que je ne veux pas 15 dans l'élément B, mais la valeur de l'élément A

  • affiche la valeur héritée en texte gris et la valeur remplacée en texte noir. L'effacement de la valeur remplacée remet la valeur héritée en texte gris.

Ça m'a l'air bien! Peut-être que l'utilisateur verra le texte gris comme un contrôle désactivé, mais il devrait s'y habituer et c'est un modèle qui est fréquemment vu.

Mais ... quelle est la propriété de l'élément est spécifié avec une zone de liste déroulante ...

  • Le combo de l'article B montre la valeur de l'article A.
  • Sur le côté du combo, il y a un carré vide.
  • Si l'utilisateur remplace la valeur du parent, le carré apparaît en noir.
  • Lorsque vous cliquez sur le carré, le est un menu contextuel avec une commande pour réinitialiser à la valeur par défaut.

Je pense que Microsoft Blend utilise ce concept.

Il fonctionne également avec d'autres contrôles comme case à cocher, sélecteur de couleurs, etc.

Quelqu'un a une autre alternative?

Cordialement,

controlsinputselection
4
Nicolas

Vous devez fournir une option pour explicitement hériter de la valeur de l'élément A. Si l'élément A a une valeur de 15 et que l'élément B affiche cette valeur, tout va bien. Ensuite, l'utilisateur la remplace, définissant la valeur à 10 et rompant la connexion entre les éléments A et B. Si l'utilisateur décide alors de revenir à 15, ce n'est plus le même 15, et si je change la valeur de A, il gagne n'affecte pas l'élément B. L'utilisateur doit pouvoir dire "Valeur de A" lors de l'édition de B.

Vous pouvez essayer de le faire avec la syntaxe ("[Label_of_A]"), mais ce n'est bon que pour les utilisateurs très avancés qui ont également une connaissance approfondie du système.

Le moyen le plus simple est d'avoir un contrôle qui bascule l'élément B entre les états d'héritage d'une valeur de A et ayant sa propre valeur, probablement une case à cocher.

2
Vitaly Mijiritsky

Tout d'abord, assurez-vous que les champs contenant des valeurs héritées sont de style un peu différent (probablement pas aussi grisé, car cela peut signifier un champ désactivé). J'ai vu des formulaires qui utilisent du texte coloré ou un arrière-plan coloré pour signifier cela. Je pense qu'au moins un navigateur le fait, ou l'habitude, chaque fois qu'il remplit automatiquement des champs de formulaire. Vous pouvez également attacher l'étiquette "(par défaut)" comme le suggère Assaf.

Ensuite, faites en sorte que les champs hérités affichent la valeur héritée, mais une fois entrés, ils apparaissent vides (similaires au nombre de champs de recherche affichant le texte "rechercher" jusqu'à ce que vous y cliquiez).

Lorsque l'utilisateur quitte ensuite ce champ sans qu'aucun détail ne soit entré, le champ revient à afficher la valeur héritée.

De cette façon, l'utilisateur est montré (et, espérons-le, enseigné) qu'un "champ vide héritera des valeurs".

Cela suppose qu'une entrée vide n'est pas réellement une entrée valide. Pour les champs numériques, comme votre exemple, l'utilisateur peut au moins entrer "0" s'il ne veut pas de valeur réelle.

0
Erics

Que diriez-vous d'ajouter une étiquette à la valeur, comme:

Valeur: 14 (hérité)

ou

Valeur: 14 (par défaut)

0
Assaf Lavie