Comment géreriez-vous les utilisateurs qui ne lisent pas les boîtes de dialogue? [fermé]
https://stackoverflow.com/questions/125269
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Un article récent sur Ars Technica présente une étude récente réalisée par le département de psychologie de la North Carolina State University, qui montre que les utilisateurs ont tendance à faire tout ce qui est nécessaire pour se débarrasser d'une boîte de dialogue et se remettre au travail. La plupart d'entre eux cliquent sur OK ou sur Oui, réduisent la boîte de dialogue ou la ferment, quel que soit le message affiché. Certaines des boîtes de dialogue affichées étaient réelles et d'autres fausses (comme ces fenêtres contextuelles affichées par des pages Web se présentant comme un avertissement antivirus). Les temps de réponse indiqueraient que ces utilisateurs ne lisent pas vraiment ces boîtes de dialogue.
Alors, sachant cela, comment cela affecterait-il votre conception et que tenteriez-vous d’y remédier (le cas échéant)?
La solution
J'essaie de concevoir des applications robustes face aux accidents, qu'il s'agisse de glissades (opérations involontaires, telles que cliquer à un mauvais endroit) ou d'erreurs (erreurs cognitives, telles que cliquer sur Ok ou Annuler dans une boîte de dialogue). Voici quelques façons de le faire:
- undo / redo infini (ou au moins plusieurs étapes)
- intégrer la documentation à l'interface, via des info-bulles dynamiques et d'autres moyens de communication sensibles au contexte (un document particulièrement pertinent concerne 'Surprise, expliquer, récompenser' (lien direct: SER ) - en utilisant des réponses psychologiques typiques à un comportement inattendu pour informer les utilisateurs)
- Incorporer l’état du système dans ladite documentation (utilisez les données de l’utilisateur actuel comme exemple et concrétisez la documentation en utilisant des données visibles maintenant )
- Expect erreur de l'utilisateur. S'il y a un risque que quelqu'un essaie d'écrire dans un: \ lorsqu'il n'y a pas de disque en place, implémentez un délai d'attente afin que le système puisse échouer normalement et invitez un autre emplacement. Enregistrez les données en mémoire jusqu'à ce qu'elles soient sécurisées sur le disque, etc.
Cela se résume à deux choses essentielles: (1) programmez de manière défensive, et (2) tenez l'utilisateur le plus informé possible. Si l'interface du système est facile à utiliser et se comporte selon leurs attentes, ils sont plus susceptibles de savoir sur quel bouton cliquer lorsqu'une boîte de dialogue gênante apparaît.
J'essaie aussi très, très difficilement d'éviter tout ce qui est modal, pour que les utilisateurs puissent ignorer la plupart des dialogues que je dois utiliser, du moins pendant un certain temps (et lorsqu'ils doivent vraiment y prêter attention, ils ont suffisamment d’informations pour savoir quoi en faire).
Il est impossible de rendre un système totalement infaillible, mais j’ai constaté que les techniques décrites ci-dessus vont très loin dans la bonne direction. (et ils ont été intégrés aux systèmes utilisés pour développer Surprise Explain Reward et d’autres outils qui ont été validés par de nombreuses études sur les utilisateurs.)
Autres conseils
Premièrement, l'utilisation de couleurs et d'icônes devrait aider l'utilisateur à avoir une idée de la gravité du problème: rouge pour indiquer un problème, jaune pour signaler un avertissement et blanc pour transmettre des informations.
Deuxièmement, l'utilisation de Les verbes sur les boutons de votre dialogue donnent aux utilisateurs une idée de ce qu’ils demandent au système, même s’ils ne lisent pas le texte du dialogue.
Enfin, si vous souhaitez explorer un paradigme de notification complètement différent, consultez la barre d'informations ou la barre de notifications implémentée dans Firefox et Internet Explorer. StackOverflow utilise le même type de mécanisme pour avertir les utilisateurs quand ils ont reçu un nouveau badge.
La barre d’information n’est pas gênante et reste en haut de l’écran en attendant l’attention de l’utilisateur. Je pense que c'est une belle métaphore de la conception.
Voici quelques tutoriels sur la mise en œuvre:
Voici le Conseils de Microsoft sur la conception des dialogues , il aborde les Le concept de barre d’information également.
Immédiatement, le livre de Steve Krug, ne me faites pas penser , vient à l'esprit.
Dans la conception des boîtes de dialogue, les messages d’état à l’utilisateur, etc., il est bon d’utiliser une iconographie et des nuances de couleur pour indiquer le contenu des mots.
Mettez en surbrillance les messages d'erreur en rouge, les avertissements en jaune, etc.
L’interface humaine, de Jef Raskin mérite d’être lue. Une boîte de dialogue est le dernier recours et un signe de mauvaise conception. La plupart sont inutiles et, comme vous l'avez découvert, tous sont ignorés par les utilisateurs.
Pourquoi y a-t-il une boîte de dialogue? Résolvez ce problème - ne demandez pas aux utilisateurs de confirmer une opération mais facilitez l'annulation de l'opération. Ne faites pas apparaître une boîte de dialogue annonçant une erreur - effectuez le type de récupération que vous allez effectuer (ou tout ce qui est possible). N'affichez pas les boîtes de dialogue qui n'ont qu'un seul résultat (seules les cases "OK" sont le diable), présentez les informations dans l'application de manière discrète.
Quelques suggestions
- N'utilisez les boîtes qu'en cas d'absolue nécessité.
- Toujours définir l'option par défaut sur l'option la moins dangereuse
Un épisode .NET Rocks vient à l’esprit (je crois épisode 338," Mark Miller sur la science de la bonne interface utilisateur ") aborde ce sujet. Je pense que la clé de toute cette discussion est qu'il s'agit d'une conception d'interface utilisateur trop poussée. Alors que le modal était autrefois un moyen de communication acceptable, nous constatons à présent qu’il est devenu de la programmation faux pas. Les utilisateurs comprennent que 6 fois sur 10, l’information n’est pas suffisamment pertinente pour qu’ils s’inquiètent. En conséquence, ils traitent tous les modaux de la même manière - l’impuissance acquise. Si un modal se présente et m'indique qu'une erreur d'application X s'est produite et que je ne peux que cliquer sur "OK". --même quand je ne pense pas que ce soit "OK" J'apprends un comportement particulier. J'assosciate modals avec l'idée que je ne peux probablement pas faire grand chose à leur sujet, mais si je clique sur OK / Oui alors je peux revenir à ce dont j'ai besoin.
Alors, pourquoi est-il encore utilisé? Les développeurs ont peut-être essayé d'éviter que le développement d'applications devienne plus qu'une interface de base, et les utilisateurs ont besoin d'une interface utilisateur fluide - il est difficile d'abandonner les anciennes normes de veille ...
Je pense que la clé ici est de comprendre que la bonne conception de l'interface utilisateur indique désormais que les interruptions (même pour les utilisateurs les plus novices) sont des ennuis et que nous devons nous efforcer de créer une expérience utilisateur transparente, centrée sur l'application. - pas les besoins de l'application via les invites et les rapports d'erreur - ne laissez pas un utilisateur se mettre dans des situations où il ne s'en soucie pas.
Les développeurs utilisent souvent des boîtes de dialogue modales simplement parce qu'il est facile de les coder.
Toutefois, les notifications non modales sont souvent plus pratiques pour l'utilisateur.
Une suggestion:
- N'utilisez pas de boîtes de dialogue. Boîtes de dialogue OK / Annuler particulièrement modales.
Parfois, c'est difficile ... comment gérez-vous l'ouverture d'un fichier? Parfois, c'est facile ... avez-vous vraiment besoin d'avertir l'utilisateur qu'il va écraser un fichier? Si je clique aveuglément sur "OK", il y a de fortes chances que je ne tienne compte d'aucun avertissement.
Si vous devez utiliser une boîte de dialogue, placez des légendes descriptives sur les boutons de celle-ci.
Par exemple, au lieu des boutons OK et Annuler, faites-leur dire "Envoyer la facture". et "Go Back", ou tout ce qui est approprié dans le contexte de votre dialogue.
De cette façon, le texte se trouve juste sous leur curseur et ils ont de bonnes chances de comprendre.
Mac OS X le fait la plupart du temps. Voici un exemple d'image.
Modifier:
Ceci est une meilleure image , et Je l'ai trouvé sur le site Apple Human Interface Guideline, qui est une excellente référence et très lisible. Ce document sur ce site traite uniquement de dialogues.
Mauvaise question. "Comment géreriez-vous les utilisateurs" commence au mauvais bout.
La bonne question est "Etant donné que les dialogues distraient les utilisateurs de la tâche à accomplir, quelles sont les meilleures alternatives?".
Lorsque vous travaillez pour atteindre un objectif ou pour terminer une tâche, nous pouvons distinguer trois situations:
(1) L’application en arrive à la conclusion qu’aucune action ne peut être entreprise pour que l’utilisateur atteigne son objectif. Pop-up un message, avec un bouton pour le rejeter. Peu importe que le lecteur comprenne, car le résultat importe peu.
(2) Vous ne pouvez effectuer qu'une seule action, ou les solutions de remplacement ne sont pas pertinentes pour l'utilisateur. Ne le dérange pas du tout.
(3) Il y a deux façons ou plus d'atteindre le but. Laissez l'utilisateur choisir entre ceux-ci. Ne formulez pas ceci comme une question oui / non. (Vista propose cela comme un dialogue commun, pour remplacer la boîte de message.) Dans la mesure du possible, n’en faites pas un choix irréversible.
L'exception à cette règle est la situation où l'utilisateur s'attendrait à une question de type oui / non. Mais vraiment, si tel est le cas, alors pourquoi la question ne fait-elle pas partie du flux de travail normal? Les boîtes de dialogue ne font pas partie du flux de travail normal.
Je pense que vous voudrez probablement lire ce document: " Impact des interruptions à haute intensité négociées dans le style négocié sur la fin Débogage utilisateur & ; TJ Robertson, Joseph Lawrance et Margaret Burnett, Journal of Visual Languages ??and Computing 17 (2), 187-202, avril 2006.
Il a posé une question similaire. Le résultat était que l'utilisateur savait que vous souhaitiez attirer son attention, puis attendez que l'utilisateur réponde. N'interrompez pas l'utilisateur, ce n'est pas ce qu'il veut.
La [Lightbox] ( http://fr.wikipedia.org/wiki/ Le dialogue modal Lightbox_ (JavaScript)) semble être une technique efficace dans certains cas (dérivation Web 2.0, mais peut être implémenté dans d’autres contextes).
Un autre point: si vous pouvez oublier une boîte de dialogue pour une fonction Annuler (Gmail pour ceux qui défendaient ce concept en tant que comportement Webapp standard), il faut en tenir compte.
Si vous devez utiliser un dialogue, récompensez-le avec un texte explicatif amusant, voire satirique et très court . Si vous distribuez de temps en temps quelque chose d'hilarement scandaleux, ils liront tout .
L'utilisateur tourne dangereusement bas bon sens. S'il vous plaît supprimer cet utilisateur et en insérer un autre.
Je n'ai que peu de patience avec les utilisateurs qui ne lisent pas ce qui m'a pris beaucoup de temps et d'efforts pour développer: 1) l'application 2) les instructions prend " tu es seul. Je le dis à l’avance. Je conçois mes applications de manière à être aussi intuitives que possible et il y a encore des personnes qui passeront des coups de fil téléphonique, comme un enfant qui sort en classe alors qu'il ne devrait pas l'être. Je n'ai aucune tolérance pour ça. Lisez le manuel, lisez les boîtes de dialogue - les réponses à 99% des problèmes sont là.
Beaucoup de bons conseils ci-dessus. Je souhaite simplement ajouter aux recommandations du livre - la "conception d'interface utilisateur pour les programmeurs" de Joel Splosky " livre vaut la peine d'être lu:
Une chose que vous pouvez faire est d’avoir le bouton OK désactivé pendant 3 secondes.
Firefox le fait lorsque vous installez une extension.
Modifier: D'accord, certaines personnes trouvent cela agaçant. Je pense toujours qu’environ 1 seconde serait acceptable. Cela supprimerait l'instinct de clic OK des gens (y compris moi-même) et forcerait une double prise. Bien sûr, même cela va énerver les gens si votre dialogue n’est pas quelque chose qu’ils ont réellement besoin de lire.
Tout d’abord, être stupide devrait faire mal, mais d’habitude cela ne le fait pas ...
La meilleure chose à faire est d’inclure une icône qui tente de signaler la gravité du problème. Un certain pourcentage de ceux qui ne liront pas pourront changer d'habitude si l'icône de la boîte de dialogue semble inquiétante. Un pourcentage ne le lira pas malgré tout.
Incluez un questionnaire à choix multiples à la fin de la boîte de dialogue, dans lequel l'utilisateur doit sélectionner la réponse indiquant qu'il a vraiment lu et compris le texte. Basculez de manière aléatoire sur l'ordre des choix afin qu'ils ne puissent pas toujours cliquer sur le même choix.
Changer la formulation et le fonctionnement de la boîte de dialogue aide. Par exemple, les boutons OK / Annuler ont tendance à laisser les utilisateurs ignorer la plupart des dialogues. Si vous supprimez les boutons normaux et les remplacez par des liens de commandes plus volumineux, les utilisateurs sont plus enclins à lire chaque bouton, car l'option "rapide, disparaître" n'est pas disponible.
J'appelle cela le "pilote automatique". problème.
- N'utilisez pas les boutons OK, Annuler en bas de l'écran. Regardez comment Vista essaie de forcer les utilisateurs à prendre une vraie décision.
- Désactivez les boutons pendant quelques secondes, affichez un "Temps de réflexion". minuterie / barre de progression. Donc, l'utilisateur ne peut pas cliquer sur le pilote automatique. Les utilisateurs ont tendance à trouver cela très agaçant.
N'utilisez pas la confirmation (êtes-vous sûr? Oui / Non), mais utilisez l'option Annuler.
Ne pas afficher les avertissements qui bloquent le blocage , car les utilisateurs essaieront de se remettre au travail le plus rapidement possible, en ignorant le message et en cliquant simplement dessus. Utilisez quelque chose comme la barre d’information d’Internet Explorer, qui ne bloque pas.
Vous pouvez éviter d’utiliser toutes les boîtes de dialogue! Dans certains programmes, il existe un mini-tampon qui affiche les erreurs et les avertissements. Parallèlement à cela, il peut également vous demander une chose, où vous devez taper ce que vous voulez faire. C'est une solution assez propre et agréable, j'ai tendance à le préférer à une barre de menu.
Mais si vous devez vraiment utiliser des boîtes de dialogue, essayez ceci:
- Une phrase par dialogue uniquement
- Au plus deux ou trois boutons
- Rendre le texte lisible dans la boîte de dialogue (plus grand, noir sur blanc)
- Utilisez plutôt une boîte de dialogue que de nombreuses petites répétitions (astuce: listbox)
Qu'est-ce que je pense des boîtes de dialogue? En bref: ce sont des choses stupides et stupides. Les programmes qui les utilisent me gênent et me ralentissent avec leurs questions stupides et sans signification. De plus, les programmes qui utilisent des boîtes de dialogue sont plutôt stupides.
