Dois-je utiliser Oui / Non ou Ok / Annuler sur ma boîte de message?
Sémantiquement, les boutons Oui/Non sont à peu près équivalents aux boutons Ok/Annuler, mais en général que recommanderiez-vous d'utiliser? Dois-je toujours utiliser Oui/Non ou toujours Ok/Annuler? Ou cela dépend-il du cas?
N'utilisez jamais 'Oui' ou 'OK' quand vous pourriez utiliser un verbe à la place.
Et vous pouvez presque toujours utiliser un verbe au lieu de 'Oui' ou 'OK'.
Je suis d'accord avec la postulation de Lukas Mathis selon laquelle personne ne lit vos boîtes de dialogue . Utilisez un verbe dans la mesure du possible au lieu de "Oui" ou "OK" car vos boutons auront un sens hors contexte avec le texte explicatif ou le titre. C'est une vue qui est encore renforcée dans les directives d'interface utilisateur de Microsoft :
Si vous souhaitez vous assurer que les utilisateurs lisent un texte spécifique lié à une action, placez-le sur un contrôle interactif.
Acceptable:
Dans cet exemple, il est possible que les utilisateurs ne lisent pas le texte qui explique ce qu'ils confirment.
Mieux:
Dans cet exemple, vous pouvez être sûr qu'au moins les utilisateurs comprennent qu'ils sont sur le point de formater un disque.
Les directives d'interface humaine d'Apple développent cela encore plus, recommandant des verbes multi-mots au lieu des boutons "OK" ou "Oui", et définissant clairement les régions suggérées pour une boîte d'alerte:
Ils conseillent de n'utiliser une boîte d'alerte en premier lieu que si l'action n'est pas annulable. Au sujet des étiquettes de boutons, ils proposent ceci:
Assurez-vous que le nom du bouton par défaut correspond à l'action que vous décrivez. En particulier, c'est une bonne idée d'éviter d'utiliser OK pour le bouton par défaut. La signification de OK peut ne pas être claire même dans les alertes qui demandent si l'utilisateur est sûr de vouloir faire quelque chose. Par exemple, OK signifie-t-il "OK, je veux terminer l'action" ou "OK, je comprends maintenant les résultats négatifs que mon action aurait causés"?
L'utilisation d'un nom de bouton plus ciblé, comme Effacer, Convertir, Effacer ou Supprimer, permet de s'assurer que les utilisateurs comprennent l'action qu'ils entreprennent.
En bref, même s'il peut sembler que la seule option ou la plus logique consiste à proposer à l'utilisateur un bouton "Oui" ou "Non" (par exemple "Êtes-vous sûr de vouloir vous déconnecter?"), Vous pouvez presque toujours utiliser un verbe ou expression à la place.
"Voulez-vous vous déconnecter?"
[Déconnexion] -ou- [Annuler]
De cette façon, un utilisateur n'a pas besoin de lire le titre ou le texte explicatif pour comprendre comment procéder, et la signification de cliquer sur l'un ou l'autre bouton ne peut pas être mal interprétée.
Notez également que, étant donné le choix entre 'Non' et 'Annuler', 'Annuler' est presque toujours meilleur pour exactement les mêmes raisons que ci-dessus: la signification de 'Annuler' est claire même si l'utilisateur n'a pas lu le reste de la boîte de dialogue. La signification de "Non" est probablement clair, mais est moins logique lorsqu'il est associé à un verbe (par exemple, "Déconnexion" et "Annuler" ont plus de sens en lecture seule que "Déconnexion" et " Non').
L'utilisation de mots courts comme Oui/Non sur les boutons peut être source de confusion si l'utilisateur lit mal le message dans la boîte de dialogue, surtout si les messages sont mal écrits. (Donc, gardez les messages succincts et sans ambiguïté en premier lieu)
Avoir yes/nook/cancel en fait force l'utilisateur à doivent lire et comprendre le message avant de savoir à quoi s'appliquent les options. Pour les utilisateurs familiers avec un produit, ils préfèrent scanner les boutons eux-mêmes plutôt que de lire le message.
L'approche que je préfère donc est de rendre la confirmation de l'action un peu plus verbeuse qu'OK (ex. Save changes, Add user, Update password) pour que ce soit très clair ce que vous vous apprêtez à faire. Et puis gardez le Cancel tel quel - une voie d'échappement courte et familière , d'autant plus qu'il devrait alors être clair que c'est le ' Ne faites pas d'action.
Même une simple question telle que êtes-vous sûr de vouloir vous déconnecter , (si cela est nécessaire en premier lieu) devrait avoir les boutons Log out et Cancel plutôt que Yes/Cancel ou Yes/No.
De cette façon, l'utilisateur peut rapidement scanner les boutons et obtenir l'essentiel de ce dont ils ont besoin, même sans lire le message.
Edit - En référence aux commentaires ci-dessus sur la réponse de greengit, voici un exemple de Skype, de ce que pas à faire:
Une boîte de dialogue de confirmation (celle qui pose une question et n'implique aucune entrée) devrait avoir oui/non. Par exemple...
Voulez-vous annuler votre compte -
yesnoVoulez-vous vous déconnecter -
yesno
D'un autre côté, une boîte de dialogue qui représente une "action" et attend une entrée utilisateur, devrait avoir ok/cancel ou <action>/cancel. Par exemple...
Définir la date et l'heure de l'événement ...
okcancelAjouter un nouveau contact ...
addcancelMettez à jour votre mot de passe ...
updatecancelModifiez votre fuseau horaire ...
donecancel
Les boutons Ok/Annuler et Oui/Non ne sont acceptables que lorsque vous êtes trop paresseux pour penser à une meilleure étiquette pour l'action.
Un exemple de bonnes boîtes de dialogue de confirmation:
- Il s'agit de LibreOffice/OpenOffice lorsque vous avez tenté de fermer un document non enregistré:
l'étiquette du bouton doit refléter l'action qui sera effectuée.
De plus, n'appelez jamais aucune action, telle que "désinscrire"/"fermer" un compte, comme "annuler" pour éviter toute ambiguïté avec le bouton Annuler. Autrement dit, le bouton d'annulation est un havre de sécurité pour lequel l'utilisateur peut cliquer sur le réflexe sans que rien ne se passe mal, ne faites pas peur à l'utilisateur de cliquer sur un bouton "Annuler".
En prenant les exemples de greengit, voici ce que je suggérerais pour chacun d'eux:
Do you want to delete your account -- "Delete account" "Cancel"
Do you want to sign out -- don't even ask this since signing out
is a non-destructive action, if the user
has an unsaved work and signing out could
lead to loss of unsaved work, then you have
two options: ask whether they want to discard
the unsaved work, or automatically save the
work as a draft.
Set event date and time -- "Set time" "Cancel". Although since this is a
non-destructive action, you should probably not
need to ask confirmation and just apply the
action immediately with a "Revert" button.
Add a new contact -- Don't ask for confirmation to "Add", when the user
entered the "Add contact" form and doesn't quit
immediately, they already confirmed that they wanted
to add a contact; automatically save the contact's
information when the user finish entering the
contact's information. Also you might want to have a
"Revert" or "Discard" button.
Update your password -- "Update Password" "Cancel"
Change your timezone -- "Set Timezone" "Cancel". The same with setting
time, if this is non-destructive then don't ask for
confirmation.
Certaines directives de l'interface utilisateur recommandent toujours d'utiliser les boîtes de dialogue Ok/Annuler plutôt que Oui/Non.
Je pense cependant que c'est une énorme erreur. Par exemple, j'ai récemment vu une boîte de dialogue avec une question comme "Voulez-vous vraiment annuler votre compte?" et des boutons intitulés "Ok" et "Annuler". Dans ce cas, "Ok" signifie "Annuler" et "Cancel" signifie "ne pas annuler".
Au moins à mon avis, c'est assez proche de complètement fou. Bien sûr, il serait possible de reformuler la question comme quelque chose comme "Fermer votre compte". Même ainsi, certaines personnes penseront probablement que cela annule le compte, même si vous n'utilisez pas/ne proposez pas ce mot. Dans ces circonstances, un bouton intitulé "Annuler" est une mauvaise idée. Certaines personnes vont inévitablement penser que cela annule l'action de fermeture du compte, mais d'autres comme l'annulation du compte lui-même.
Je dois admettre que le parti pris contre "Oui"/"Non" a aussi un certain mérite. Dans ce cas, je pense qu'il serait préférable d'éviter les étiquettes "stock" et d'utiliser quelque chose comme "fermer le compte" et "garder le compte ouvert".
Il n'y a pas non plus de très bonnes solutions si vous cherchez à poser une question à vos utilisateurs et à leur donner des options pour répondre. Oui/Non fonctionne si vous êtes dans une enquête, mais c'est très minime pour une boîte de dialogue modale. OK/Cancel est comme un souvenir de l'ancien temps où les écrans avaient de faibles résolutions et les boutons devaient être concis pour s'adapter.
Le fait est que les étiquettes des boutons peuvent être considérées comme des microcopies et, en tant que telles, doivent être prises en compte, les autres éléments de l'interface utilisateur étant accordés. À quoi suis-je d'accord ou pas d'accord? Qu'est-ce que j'accepte ou annule? Pourquoi cette information n'est-elle pas sur le bouton?
Alors revenez en arrière et réfléchissez à la façon dont vous pourriez changer l'étiquette pour être plus clair. "Supprimer cette ligne? Oui/Non" serait beaucoup plus facile à scanner (d'autant plus que c'est une action destructrice) si les boutons disaient simplement "Supprimer cette ligne"/"Ne rien supprimer". Styliser l'action que vous souhaitez que l'utilisateur exécute comme un appel à l'action plus important et rendre le bouton d'annulation plus petit (et peut-être même pas un bouton) peut également aider beaucoup.
Parfois, OK/Annuler introduit deux boutons car une boîte de dialogue modale est impliquée. Demandez-vous si vous avez besoin d'une boîte de dialogue modale ou si vous pouvez la supprimer et simplifier l'expérience. Par exemple, si vous avez une boîte de dialogue de déconnexion d'un utilisateur, ne lui demandez pas "Souhaitez-vous vous déconnecter? OK/Annuler" dans une boîte de dialogue modale, mais disposez simplement d'un bouton disant "Déconnexion" et l'utilisateur peut décider de cliquez dessus ou non.
Questions pertinentes qui vous aideront dans votre décision:
En général, je suis d'accord avec @Nick mais il y a une autre chose qui mérite d'être mentionnée:
Évitez les dialogues si vous le pouvez - les dialogues sont juste ennuyeux la plupart du temps - vous demandez à l'utilisateur s'il est sûr. Je ne sais pas comment vous mais je n'aime vraiment pas ce genre de protestations - l'ordinateur est là pour me servir pas l'inverse!
Alors, qu'en est-il du bouton Supprimer? Il est logique de demander avant ce genre d'action, non? Eh bien, c'est certainement le cas, mais il existe également une bien meilleure solution - fournit une fonctionnalité d'annulation
Corbeille, annulation du lien dans les notifications de la barre d'état, "e-mail de sauvetage" envoyé après l'annulation du compte, plusieurs versions du même document, etc. Les utilisateurs méritent de pouvoir fonctionner rapidement et s'ils se trompent, vous devez simplement fournir une corde de sécurité - c'est tout. Ne les dérangez pas, sauf si c'est totalement nécessaire.
De plus, placer la suppression séparée des autres boutons et la rendre plus petite pourrait aider à minimiser ces erreurs. Les applications iPhone ont généralement un enregistrement/annulation (les deux potentiellement dangereux) en haut de l'écran - car il est plus difficile d'y toucher.
EDIT: Il y a aussi article sur "annuler les confirmations" de Aza Raskin
La plupart des utilisateurs ne recherchent que 3 m.
Un positif -
Yes,OK,Add,Retry,Wait..etc.Un négatif -
No,Abort,Quit,Exit
et le troisième est:
- "Échapper à cette boîte de message" -
Cancel
Ainsi, l'utilisation de Yes, NO et Cancel fait trois types différents de pensées.
Cela signifie que leur utilisation dépend du cas.
Cela dépend de la formulation. Je ne voudrais rien d'autre que Oui/Non pour une question qui attend une réponse Oui/Non. Je ne voudrais pas Oui/Non pour quelque chose qui n'est pas une question (ou une question formulée de telle manière que oui/non n'est pas une réponse valide).
Je n'ai pas de statistiques pour prouver l'affirmation suivante, mais pour moi, avoir un texte personnalisé sur les boutons n'est pas toujours mieux.
Ok/Annuler/Oui/Non sont si communs que nos cerveaux sont déjà formés pour les reconnaître et agir sur eux en une fraction de seconde, tandis que les étiquettes personnalisées demandent à un utilisateur d'arrêter et de traiter activement les informations, ce qui peut être ennuyeux s'il est utilisé sur des actions communes.
Tant que l'action attendue lancée par l'utilisateur et la boîte de dialogue suivent la même logique, simple Oui/Non est génial. Je sais déjà ce que je fais, je dois juste le confirmer. Toute explication supplémentaire n'est qu'une sorte de bruit.
Un exemple est l'action Vider la corbeille. Je veux être invité à chaque fois à éviter les clics accidentels, mais lorsque je clique dessus exprès, je veux en finir aussi vite que possible. Cliquez simplement - cliquez, je ne veux pas lire le texte de la boîte de dialogue, je m'attends déjà à ce qu'il demandera et je m'attends à répondre Oui ou Non (ou Ok/Annuler), car c'est l'ensemble de réponses habituel.
Une bonne solution à cette IMHO est d'utiliser les étiquettes des boutons sous la forme "Oui, faites quelque chose". De cette façon, il est toujours facile de simplement scanner le texte et d'en comprendre le sens, mais si vous êtes confus au sujet de la boîte de dialogue, vous pouvez tout lire et être sûr de ce que fait le bouton.
Je suis d'accord avec la plupart des autres réponses qu'il est presque toujours préférable d'afficher des réponses spécifiques plutôt que des boutons Oui/Non.
Cependant, le Microsoft Design Guidelines (daté de mai 2018) sur les boîtes de dialogue mentionne certains cas où Oui/Non peut être approprié:
- Pour faire des confirmations, il faut réfléchir
- Pour éviter les formulations longues ou maladroites
(Je ne sais pas si je suis d'accord, mais j'ai trouvé intéressant d'utiliser "Oui/Non" dans ces exemples était une décision de conception intentionnelle.)
- Faire des confirmations nécessite de la réflexion
Le section sur les confirmations dans les Microsoft Design Guidelines fait valoir que l'utilisation de Oui/Non peut être appropriée dans les confirmations avec des conséquences importantes.
N'utilisez pas de confirmations simplement parce qu'il est possible que les utilisateurs se trompent. Les confirmations sont plutôt plus efficaces lorsqu'elles sont utilisées pour confirmer des actions qui ont des conséquences importantes ou involontaires. [...]
Pour qu'une confirmation ait de la valeur, les utilisateurs doivent comprendre la raison de ne pas continuer. Parfois, la raison est évidente, comme lorsque les utilisateurs ferment un document avec des modifications qui n'ont pas été enregistrées:
Dans cet exemple, la raison de la confirmation est évidente.
Dans d'autres situations, la raison peut ne pas être aussi évidente.
Lorsque vous choisissez des étiquettes de bouton de validation pour les boîtes de dialogue, les instructions générales sont de choisir des étiquettes qui sont des réponses spécifiques à l'instruction principale. Cela conduit à une prise de décision efficace car les utilisateurs doivent lire un minimum de texte pour continuer. Cependant, cet objectif d'efficacité peut être contre-productif pour les confirmations. Considérez cet exemple:
Incorrect:
Dans cet exemple, la bonne réponse nécessite réflexion.
Si vous présentez cette confirmation immédiatement après que l'utilisateur a donné la commande Désinstaller, la réponse de l'utilisateur est probablement "Bien sûr, je veux désinstaller!" L'utilisateur cliquera sur Désinstaller sans y réfléchir.
Pour les confirmations, nous ne voulons pas que les utilisateurs prennent des décisions hâtives et émotionnelles. Pour encourager les utilisateurs à réfléchir à leur réponse, nous devons fournir un petit ralentisseur de prise de décision. Lorsque cela est pratique, il est généralement préférable de le faire en formulant soigneusement les boutons de validation. Par exemple, nous pouvons utiliser un langage supplémentaire pour indiquer qu'il y a une raison de ne pas continuer.
Mieux:
Dans cet exemple, "de toute façon" est ajouté à l'étiquette du bouton de validation pour indiquer que la confirmation donne une raison de ne pas continuer.
Si cette approche n'est pas pratique, nous pouvons utiliser des boutons de validation Oui/Non.
Aussi mieux:
Dans cet exemple, l'utilisation des boutons de validation Oui/Non oblige les utilisateurs à lire au moins l'instruction principale.
- Pour éviter un phrasé long ou gênant
Considérez la formulation de l'instruction principale comme une question oui ou non si les boutons de validation avec une formulation spécifique s'avèrent longs ou maladroits. Vous pouvez également utiliser des liens de commande pour des réponses plus longues (cinq mots ou plus) à l'instruction principale.
Incorrect:
Correct:
La formulation spécifique dans l'exemple incorrect est trop longue, donc l'exemple correct utilise Oui et Non.
J'utiliserais Oui/Non dans la boîte de dialogue si le flux de travail a besoin d'une descission dans quel sens continuer. OK/Annuler doit être utilisé dans le sens de "Continuer?" avec le traitement/workflow car normalement Annuler implique que quelque chose est arrêté ou interrompu si j'appuie sur Annuler. Je n'utiliserais pas une boîte de dialogue OK/Annuler en combinaison avec une question comme "Devrions-nous nous arrêter ici?" ... c'est une descente Oui/Non (voir workflow et descission). Le bon choix dépend donc toujours aussi de la question. Eh bien, il est possible de construire des questions qui irritent l'utilisateur ... mais pourquoi faire ça?
Je préfère utiliser Verb et annuler, comme décrit par @Nick, cela a plus de sens et de convivialité. Par exemple, si vous fermez une fenêtre et si vous demandez à l'utilisateur "Voulez-vous fermer la fenêtre?" Il existe deux types d'options, vous pouvez avoir "Oui/Non" et "Fermer/Rester" .. "Ok/Annuler" n'a aucun sens.
Donc, la première préférence va au verbe, puis oui/non.
L'époque des libellés des boutons Oui/Non et Ok/Annuler est révolue. Il est temps d'utiliser des étiquettes de bouton spécifiques à l'action sur vos boîtes de dialogue comme le suggère cet article.
Il aidera les utilisateurs expérimentés qui ne lisent pas le texte de la boîte de dialogue à cliquer sur le mauvais bouton. Ils ont tendance à se déplacer rapidement dans l'interface, donc en étiquetant vos boutons avec un mot spécifique à l'action, tout ce qu'ils ont à faire est de lire les étiquettes des boutons pour savoir lequel cliquer. "Ok" est vague et ne décrit pas l'action ou la tâche que l'utilisateur fait.