L'utilisateur démarre une action et, par la suite, le système détermine qu'il existe une condition spéciale qui justifie une confirmation supplémentaire de l'utilisateur:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Dans l'exemple ci-dessus, "Non" ferait exactement la même chose que "Annuler". Le bouton "Annuler" doit-il toujours être présent?
Ma raison de ne pas l'inclure: ce serait redondant et les utilisateurs s'interrogeraient sur la différence entre "Non" et "Annuler".
Ma raison de l'inclure: cela permet une "sortie facile" pour l'utilisateur: "Je ne veux pas lire, penser et comprendre la boîte de message effrayante maléfique; veuillez simplement prétendre que je n'ai pas commencé l'action du tout . "
Remarque: j'apprécie les suggestions alternatives (comme une conception de boîte de message complètement différente), mais j'apprécierais également les commentaires sur laquelle de ces deux options est préférée (par exemple, dans les situations où le La bibliothèque d'interface utilisateur offre des options limitées).
N'utilisez pas Non avec Annuler. Ils font quelque peu la même fonctionnalité.
Je vous suggère d'aller de l'avant et d'être précis avec les options que vous fournissez. Nous cliquons plusieurs fois sur Oui/Non sans lire le message dans la boîte de dialogue modale - en particulier lorsque nous installons des applications ou que nous sommes confrontés à des fenêtres d'avertissement/alerte. En tant que concepteur/développeur responsable; vous voulez que vos utilisateurs prennent une décision éclairée.
Depuis, Non et Annuler exécutent quelque peu la même fonction. Utilisez annuler au lieu de non.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Ma lecture de cette invite indique la signification suivante (approximativement):
I see you are trying to [fizzbuzz the main Foo].
That isn't recommended because [the main foo has already been fizzbuzzed].
I suggest instead [frobnicate a secondary foo].
Quand je vois une invite formatée comme ça, mes attentes pour les boutons Oui, Non et Annuler sont:
En supposant que votre description de "Non et Annuler fait la même chose" signifie que les deux font ce que j'ai décrit pour Annuler, je dirais utiliser Yes
et Cancel
si la personnalisation du texte des boutons n'est pas ' t possible comme dans l'exemple de DPS, ou si la seule option à deux boutons est Yes/No
alors je préfère appeler clairement les effets de chaque bouton dans l'invite, comme "Le Foo principal a déjà été effleuré. Cliquez sur 'Oui' pour frobniquer un Foo secondaire, ou sur 'Non' pour annuler."
Si les actions font exactement la même chose, vous devez réduire les actions à une. L'ajout d'un autre libellé pour la même action déroute l'utilisateur, augmente le temps de réalisation car il relira très probablement la boîte de dialogue, réfléchira à ce qu'il a fait avant pour que le système lui propose les deux actions et, à la fin, suscitera de la frustration.
Je préfère définitivement la boîte de dialogue avec deux au lieu de trois options.
Oui, vous pouvez et devez offrir un moyen redondant d'annuler la boîte de dialogue, mais non, ce ne devrait pas être un bouton redondant avec du texte.
Je suis d'accord avec ça:
Il permet à l'utilisateur de "sortir facilement": "Je ne veux pas lire, penser et comprendre la boîte de message effrayante maléfique; veuillez simplement prétendre que je n'ai pas du tout commencé l'action."
Cependant, comme il est montré, l'utilisateur doit lire et réfléchir, car les 3 boutons sont présentés de manière égale et nécessitent une lecture/réflexion pour comprendre qui fait quoi (à quel point l'utilisateur serait confus par la différence entre non ou annuler, comme l'a souligné Pectoralis). Un rouge [x]
, cependant, est instantanément reconnaissable et ne nécessite aucune réflexion.
Vous devez toujours prendre en charge 3 façons d'annuler les boîtes de dialogue modales (dans une application Web ou de bureau):
[x]
(idéalement, natif du système d'exploitation)Esc
pour annulerComme @DPS l'a remarqué, j'opte également pour informer vos utilisateurs de l'action exacte du bouton et de la distinction visuelle entre les deux. Ceux-ci devraient être utiles (en particulier le premier lien):
Lors du choix entre les actions primaires et secondaires, les distinctions visuelles sont une méthode utile pour aider les gens à faire de bons choix.
Cette distinction devrait-elle être plus importante comme le bouton par rapport au lien dans l'option A ou un peu plus subtile comme les deux boutons de couleur différente dans l'option C? L'option A a un peu mieux résisté dans le temps jusqu'à l'achèvement, le nombre moyen de fixations et la durée totale moyenne des fixations indiquant que les personnes ont rempli le formulaire plus rapidement mais pas beaucoup.
Le besoin de ces distinctions devient sans objet, bien sûr, lorsqu'aucune action secondaire n'est présente. Assurez-vous que vous avez vraiment besoin de chaque action secondaire sur un formulaire et ne les ajoutez pas sans discernement.
https://uxplanet.org/primary-secondary-action-buttons-c16df9b3615http://uxmovement.com/buttons/visual-weight-of-primary-and-secondary- boutons d'action /https://www.smashingmagazine.com/2016/11/a-quick-guide-for-designing-better-buttons/
Étant donné la liberté de concevoir la boîte de dialogue comme vous le souhaitez, la réponse de @ DPS est excellente. Mais vous demandez également comment gérer cela dans les cas où la bibliothèque d'interface utilisateur fournit des options restreintes pour le choix des boutons de dialogue.
Dans ce cas, je suggérerais que plutôt que "Oui/Non" un meilleur choix serait une boîte de dialogue "OK/Annuler":
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Cela indique clairement que si vous appuyez sur Annuler, rien ne se passera, alors qu'avec une option Oui/Non, il est ambigu si Non ferait toujours quelque chose sans frobnicer le foo secondaire ou non. (Et avec Oui/Non/Annuler, il y a une implication incorrecte que "Non" et "Annuler" font des choses différentes, conduisant à la conclusion que "Non" doit vraisemblablement essayer de continuer avec le foo d'origine d'une certaine manière).
En termes de convivialité, vous ne devriez jamais avoir différents déclencheurs d'action qui produisent le même effet avec des étiquettes ou des descriptions différentes.
Envisagez d'afficher la notification de manière irrecevable, c'est-à-dire une boîte de dialogue modale ou une bannière de notification. De cette façon, vous pouvez utiliser un standard X bouton pour ignorer la notification, avec un bouton pour Frobnicate a Secondary Item dans la notification elle-même.
Trois options rendent les choses encore plus confuses, pas moins.
Si vous avez besoin d'un moyen simple de sortir, cette boîte de dialogue devrait peut-être être entièrement supprimée.
Faites apparaître une icône explicite évidente après une fabuleuse foo qui est facilement visible et utilisée par l'utilisateur plutôt que d'interrompre son flux de travail avec quelque chose dont il pourrait ne pas avoir besoin. Une animation attirerait l'attention.
Les boutons de dialogue "Standard" ont toujours été problématiques. Un problème est que leur sens est souvent ambigu, mais l'autre problème est qu'ils peuvent rendre les choix plus clairs qu'ils ne le sont réellement.
Sans doute, lorsqu'une circonstance exceptionnelle survient, l'utilisateur devrait être confus, jusqu'à ce qu'il ait compris la question. Rendre la boîte de dialogue plus simple et plus routinière revient à minimiser la quantité d'attention dont vous avez besoin de la part de l'utilisateur.
Si vous êtes limité à "oui", "non", "OK" et "annuler", je dirais que "oui"/"non" est le plus susceptible d'amener l'utilisateur à lire la question (qui doit être clairement formulée ). De nombreux utilisateurs, voyant une boîte de dialogue avec "annuler" comme une option, cliqueront par réflexe sur l'autre bouton pour continuer.
Idéalement, vous utiliseriez des boutons/hyperliens "verbeux" pour garantir que l'utilisateur fait un choix délibéré et informé. Bien sûr, l'autre morale ici n'est pas de sur-utiliser les boîtes de dialogue, car les utilisateurs cessent de faire attention.