Dois-je seulement autoriser l'utilisateur à taper un "Oui" ou dois-je autoriser tout sauf un "Non"
Dans quelque chose comme une application console, est-il préférable, en demandant à l'utilisateur s'il veut réessayer, ou ajouter un autre objet, etc., d'accepter lequel des éléments suivants: (après avoir pris uniquement la première lettre sortie en minuscules)
- N'acceptez "y" que pour continuer
- Acceptez tout sauf "n" pour continuer
Veuillez demander si vous avez besoin d'un peu plus de précisions sur ce que je demande.
Questions ouvertes ou fermées
Les enfants
Voici un conseil que vous trouverez parfois avec l'éducation des enfants:
Il est préférable de fournir à un enfant un ensemble d'options spécifiques, plutôt que de lui laisser le soin d'élaborer les options lui-même.
Par exemple, au lieu de demander à votre enfant "Que voudriez-vous manger?" lui demander "Voulez-vous une omelette ou du riz?".
L'argument est que les enfants n'ont pas encore développé une capacité de rappel cognitif répétée - donc des questions ouvertes peuvent les dérouter et éventuellement les rendre timides.
(Cela dit, en même temps, les questions ouvertes sont encouragées dans de nombreuses situations avec les enfants car elles favorisent la pensée créative et les compétences de résolution de problèmes: - "Maman, que fait ce bouton?" - "Eh bien, que pensez-vous qu'il pourrait faire ? "et à partir de là, vous les guidez vers la réponse.)
Adultes
Les adultes, bien que beaucoup mieux et répétés pour se rappeler des choses, ont également un problème avec les questions ouvertes par loi de Hick .
Supposons que vous souhaitiez organiser une réunion avec un ami, lequel des éléments suivants est susceptible de permettre une prise de décision plus rapide:
- Quand souhaitez-vous vous rencontrer?
- Devons-nous nous rencontrer à 17h, 18h ou 19h?
- Devons-nous nous rencontrer à 18 heures?
J'espère que vous pensez que le dernier le fera. Vous pourriez constater que certaines personnes connaissent bien ce concept et l'utilisent comme technique pour pousser les autres.
Dans les interfaces
Donc, lorsque vous posez une question à un utilisateur sans clarifier les réponses possibles, c'est un peu comme poser à un enfant une question ouverte, à laquelle la réponse (peut-être inconsciente) pourrait être: "Comment suis-je supposé savoir quoi répondre à cela? Quelles sont mes options? ".
Fournir les réponses possibles avec la question résout ce problème:
Voulez-vous continuer [o/n]?
Principes de conception
Il existe une multitude de principes de conception et de techniques d'évaluation qui suggèrent aux concepteurs de poser les questions suivantes (par exemple, Procédure cognitive ):
L'utilisateur peut-il dire quelles mesures doivent être prises pour progresser dans la tâche?
Et aussi:
Ces actions sont-elles visibles pour l'utilisateur?
"Voulez-vous continuer?" signifie que la réponse aux deux questions sera "non".
"Voulez-vous continuer [o/n]?" signifie que la réponse aux deux questions sera "oui".
Contraintes
Un autre problème qui vient à l'esprit est celui des contraintes , qui sont souvent mises en place pour éviter les erreurs de l'utilisateur.
Si vous ne listez pas les options possibles [y/n], il appartient aux utilisateurs de deviner quelles pourraient être les réponses; et ils peuvent avoir tort! Vous devez vous attendre à une multitude d'erreurs, sauf si vous limitez réellement l'entrée à un ensemble limité de valeurs.
Bien entendu, en plus de y et n, vous pouvez également accepter yes et no même si je pense plutôt à un garde-erreur et n'épellera pas les options sur l'interface.
Je dirais généralement que cela dépend si lequel des éléments suivants est le plus important:
- Facilitez/accélérez la procédure
- Arrêtez l'utilisateur de procéder accidentellement
Si 1, optez pour votre deuxième option, si 2, optez pour votre première option.
Quel que soit celui que vous choisissez, à condition de vous en tenir à tout au long de votre application, je dirais que cela n'a pas d'importance. Cependant, je choisis généralement "y" pour continuer et "n" pour arrêter/annuler et tout le reste est ignoré (peut-être avec un message).
Si possible, je suppose qu'il serait probablement convivial de donner au moins une suggestion des réponses attendues/acceptées. Cela pourrait être aussi petit que [o/n].
Sinon, après mon avis, vous courriez probablement le risque que les utilisateurs ne répondent pas du tout, car nous sommes tellement habitués à cliquer sur les boutons. Mais cela pourrait bien sûr dépendre du contexte, du type d'application et du public cible associé.
Généralement, ce type de workflows basés sur du texte (ligne de commande) aura des invites, à la (y/n)?, ce qui rend assez clair ce que l'application attend. Je dirais de m'en tenir à ce schéma familier.
Sous le capot, vous pourriez expliquer les différences de casse ou l'orthographe complète de Yes ou No (il suffit de regarder la première lettre), mais je n'irais pas trop loin (Affirmative ne devrait probablement pas être une entrée acceptable =) Assurez-vous également de fournir une option par défaut si ce n'est pas quelque chose qui a vraiment besoin de mur de briques l'utilisateur avec une entrée. Habituellement, si je connais une application de ligne de commande fiable qui fournit de bonnes valeurs par défaut, je suis OK en appuyant sur enter tout au long.