Combien d'informations sur une erreur doivent être montrées à l'utilisateur?


38

Les applications peuvent toujours générer des erreurs. Si une telle erreur se produit, l'utilisateur doit en être averti, car ce qu'il a demandé à l'application de faire n'a pas abouti.

Cependant, quelle quantité d'informations l'utilisateur devrait-il recevoir? Je pense que la plupart d’entre nous sont d’accord pour ne pas afficher de trace de pile ( une trace de pile doit-elle figurer dans le message d’erreur présenté à l’utilisateur? ), Mais je ne trouve pas de question sur le reste du contenu de l’erreur ni sur les éléments à afficher. utilisateur.

Par exemple, une langue prenant en charge les exceptions (.net, java) a le type d’exception à partager, où l’exception s’est produite, et un message un peu plus explicite à accompagner l’exception. Est-ce que cela devrait aussi être caché à l'utilisateur? Ou devrions-nous montrer cela quand même? Ou devrions-nous montrer un message générique? ou devrions-nous afficher l'un des nombreux messages en fonction de l'exception sous-jacente?

Réponses:


34

quoi montrer à l'utilisateur. Est-ce que cela devrait aussi être caché à l'utilisateur?

Vous montrez à l'utilisateur ce qui peut être fait pour lui.

Par exemple, si vous rencontrez une erreur due à une exception de pointeur null et à un bogue plus important qu'une erreur d'utilisateur, vous ne souhaitez pas une explication complète, car ils ne peuvent rien faire de différent.

Ou devrions-nous montrer cela quand même? Ou devrions-nous montrer un message générique?

Afficher l’exception en tant que contenu principal du message d’erreur est inutile pour la plupart des utilisateurs . Peut-être que si votre base d'utilisateurs cible est constituée de développeurs, vous pourriez afficher les informations comme une erreur complète tout le temps (peut-être avez-vous une application interne pour les tests automatisés). Mais généralement, les utilisateurs ne peuvent rien faire de différent, même avec cette connaissance.

devrions-nous afficher l'un des nombreux messages en fonction de l'exception sous-jacente?

La meilleure stratégie consiste à:

  • Interprétez l'erreur en un texte qui a du sens pour l'utilisateur.
    • Une partie de ceci est "qu'est-ce que l'utilisateur peut faire différemment?"
    • S'ils ne peuvent rien faire de différent, dites quelque chose du type "une erreur inattendue s'est produite".
  • Ajouter une description d'erreur "optionnelle" détaillée
  • Autoriser les utilisateurs à soumettre le rapport d'erreur (ou à le faire automatiquement, en fonction de la base d'utilisateurs)

Exemple

entrez la description de l'image ici

  1. Il montre le "voici ce qui s'est passé" (erreur inattendue)
  2. Indique à l'utilisateur ce qu'il doit faire (rouvrir Mail, y compris même un raccourci pour le faire)
  3. Possède également un "afficher les détails" si quelqu'un est curieux de voir l'erreur technique complète
  4. Fournit une notification lorsqu'un rapport d'erreur est déposé (voir ci-dessous)

Notez que dans certains cas, vous pouvez souhaiter que le rapport d’erreur soit manuel ou automatique.


20
Je ne suis pas d'accord. Il n’ya rien de plus aussi énervant qu’une application qui affiche "une erreur est survenue". à l'écran, puis quitte. Chaque fois que cela se produit, je me demande toujours pourquoi le développeur était si paresseux qu'il a imprimé un message aussi peu informatif. Expliquez quelque chose à l'utilisateur afin qu'il puisse comprendre ce qui s'est mal passé, même s'il ne peut rien y faire. Dans le meilleur des cas, ils peuvent rechercher le message d'erreur sur Google et éventuellement trouver une solution décrite par quelqu'un d'autre, ce qui est presque impossible si toutes les erreurs différentes impriment le même message générique.
Jon Bentley

3
@JonBentley Vous le considérez en tant que développeur, qui veut comprendre ce genre de choses. L'utilisateur moyen s'inquiétera simplement de ce qu'il devrait comprendre, ce dont il n'a pas besoin.
deworde

12
@deworde Au contraire, je le considère comme un utilisateur . En tant qu'utilisateur, je ne veux pas le comprendre d'un point de vue technique, mais je veux assez d'informations pour ne pas avoir l'impression que l'auteur du logiciel est incompétent ("une erreur s'est produite" donne l'impression que le développeur n'a pas Je ne sais pas ce qu’ils faisaient) et pour pouvoir chercher des réponses. Si chaque incident dit "une erreur s'est produite", une recherche Google ne m'aidera pas. Un message unique pour chaque situation est beaucoup plus susceptible de m'amener à un forum où quelqu'un d'autre a eu le même problème, et l'a peut-être résolu.
Jon Bentley

3
@JonBentley quelques points à considérer. Tout d’abord, le point principal de cette réponse est que vous fournissez à l’utilisateur des informations exploitables. Si c'est une erreur, ils peuvent corriger le besoin de leur dire des informations pour la résoudre. Cela tombe dans You show the user what is actionable for them. Si vous connaissez la cause du problème, montrez-le à l'utilisateur dans la description. Mais généralement, si vous connaissez la raison d'une erreur, vous connaîtrez la résolution du problème pour informer l'utilisateur de manière appropriée.
Enderland

2
Deuxièmement, vous surestimez grossièrement la capacité moyenne des utilisateurs à résoudre eux-mêmes leurs problèmes. La majorité écrasante de la population est ce que la plupart des développeurs / programmeurs / spécialistes de Stack Exchange appellent analphabète en informatique. Franchement, la plupart de ces personnes ne sont pas équipées pour diagnostiquer, dépanner et résoudre les problèmes. Détail peut effectivement faire des choses pire parce que les gens peuvent mal interpréter les choses qui auraient du sens complet pour les développeurs. Les programmeurs et les férus de technologie ne sont presque universellement pas la cible démographique pour la plupart des applications, à la grande déception de tout le monde ici ... :)
enderland

12

Cela dépend de qui est l'utilisateur et de ce qu'il peut faire avec l'information.

En règle générale, essayez de ne leur montrer que des informations utiles sur les problèmes qu'ils peuvent résoudre eux-mêmes. Une trace de pile de 40 lignes avec une erreur d'expression régulière en haut n'est pas très utile. Il serait bien mieux d'envoyer un message indiquant que la date doit être au format "aaaa-mm-jj" . Tout le reste, et l'utilisateur peut ne pas savoir comment réagir à l'erreur, puis ne pas vouloir utiliser votre application, de peur que cela ne provoque des erreurs plus énigmatiques et effrayantes (et oui, les utilisateurs non techniques sont parfois effrayés par la pile traces). Et cela pourrait être mauvais pour les affaires.

Pour les applications internes utilisées par d'autres développeurs, je suis un peu plus serein quant à l'affichage d'une trace de pile, en plus de quelque chose de plus utile , car je sais que l'utilisateur peut gérer la visualisation d'une trace de pile et saura probablement quoi faire à ce sujet.

Pour les utilisateurs non techniques, la seule fois où je pense qu'il serait correct de leur montrer une trace de pile est dans une situation d'erreur critique où vous en avez besoin pour résoudre le problème, et on leur demande de copier et coller la trace de pile et de l'envoyer. pour vous, bien que le meilleur moyen de le faire est de leur demander d'envoyer un fichier journal ou, mieux encore, de faire en sorte que l'application envoie un fichier journal au développeur, après avoir demandé à l'utilisateur l'autorisation de partager le fichier.


5
Je ne serais pas d'accord avec une application qui envoie des journaux n'importe où sans me le demander. Au lieu de cela, la boîte de dialogue de message d'erreur devrait fournir une option pour signaler l'erreur. L'utilisateur doit pouvoir consulter toutes les informations, y compris le suivi de la pile, avant d'envoyer le rapport.
jeudi

1
@piedar: C'est un bon point.
FrustratedWithFormsDesigner

4
@piedar: Avoir un bouton "Voir plus de détails" dans la boîte de dialogue d'erreur ou un lien vers le fichier journal de l'application est probablement un bon moyen de présenter tous les détails sanglants aux utilisateurs critiques qui souhaitent obtenir ces informations. Même une case à cocher "afficher les détails par défaut", si vous souhaitez vous résoudre à le coder. Mais tous les utilisateurs ne voudront pas le voir et certains utilisateurs en seront excités.
FrustratedWithFormsDesigner

2
@ Paddy: Vous avez raison, mais: 1) C'est un exemple. : P 2) Peut-être que j'ai corrigé et nettoyé un tel code, c'est pourquoi il est frais dans mon esprit ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "Et s'il est le développeur, il peut reproduire le bogue" .. - oh, si seulement c'était vrai :(
Blorgbeard

1

Les messages destinés aux utilisateurs doivent être traités de la même manière que lors de la création d'une nouvelle exception à lancer: vous fournissez les informations dont ils auront besoin pour décider quoi faire.

Cela dépendra bien sûr de votre application et de votre base utilisateur, mais ce devrait être votre principe directeur: votre objectif devrait être de fournir les informations nécessaires à "l'appelant" afin de déterminer ce qu'il peut éventuellement faire pour mener à bien l'action souhaitée. . Si c'est quelque chose de simple, comme une erreur d'accès à un fichier, vous indiquez un chemin d'accès au fichier et le message auquel vous ne pouvez pas y accéder. S'il s'agit d'une exception de pointeur nul, donnez simplement un message d'erreur générique.

Bien sûr, il y aura plus de messages "incapables d'exécuter l'action souhaitée" que de messages pouvant être résolus par l'utilisateur, mais c'est la vie - la plupart des exceptions sont dues à une erreur, pas au fait que l'utilisateur a configuré l'environnement incorrectement.


1

C'est un thème commun:

Comment aider les illettrés non informés / informaticiens en même temps qu’afficher des informations pouvant être utilisées par des utilisateurs plus avancés, tels que programmeurs, développeurs, testeurs, etc.

Je pense que la réponse est que vous faites les deux!

L'ordre est important cependant et je vous recommande d'avoir:

  • Qu'est-il arrivé.
  • Que faire maintenant
  • Détails techniques

Les détails techniques sont la partie qui contient des informations pour les commandes avancées ou pour les utilisateurs réguliers lors du signalement d'un problème.


0

Ce que vous voulez montrer dépend de votre honte d'avoir gâché.

Le but est d'obtenir les détails de l'échec du support technique le plus rapidement et le plus harmonieusement possible. Cela peut signifier que vous envoyez automatiquement le fichier journal, y compris le suivi de la pile de l'erreur de terminaison, ou demandez à l'utilisateur de cliquer sur un bouton qui initiera le transfert. Peut-être par clé USB s'il n'y a pas de connexion internet.


0

J'aime les raisons qui sous-tendent la réponse acceptée, mais je dois respectueusement désapprouver au moins mon interprétation de limiter les informations à ce qui est "passible de poursuites" . Je veux en savoir un peu plus que cela en tant qu'utilisateur "d'erreur inattendue" .

Et certes, je suis un peu féru d’ordinateur et j’ai ce parti pris, mais je ne pense pas que ce soit une opinion particulièrement partiale. Parce que je peux faire de mon mieux pour éliminer ce biais en appliquant cet état d'esprit à des domaines pour lesquels j'ai peu de compétences, comme l'aviation.

Bien que je sache peu de choses sur l’aviation, disons que mon vol est retardé ou annulé et que le personnel ne me dit que: "Nous avons eu une erreur inattendue. Veuillez attendre 3 heures pour un vol ultérieur." Vous me trouverez au moins un peu plus mécontent dans ces cas car, même si cela n’affecte pas vraiment mon plan d’action, je veux juste en savoir un peu plus sur les raisons pour lesquelles je suis gêné de cette façon en tant que client payant.

S'ils se contentent de dire: "Nous sommes confrontés à un temps agité" ou "Nous avions une urgence médicale lors de notre vol précédent", ou un dysfonctionnement de l'équipement ou autre chose, cela me suffit amplement pour sympathiser davantage qu'une "erreur inattendue". soyez un peu plus content assis et attendez 3 heures pour le prochain vol. En fait, je pourrais peut-être même préférer un technobable qui me donne "erreur inattendue", comme: "D'accord, les mots sortent de ta bouche me parviennent à l'oreille mais n'atteignent pas le processeur central. Mais je comprends maintenant qu'il y Je vais prendre un café et m'asseoir là-bas! J'espère que vous résolvez ce problème avec ce trucamajig! "

Et souvent en termes de gestion des exceptions, je pense que vous avez généralement assez d'informations de base sur ce qui s'est passé sur le catchsite, même si vous voulez cacher les détails plus techniques de l'exception, comme:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

Et cela n’affiche même pas ce qui pourrait être potentiellement les informations très techniques attachées à l’exception, mais nous dit au moins beaucoup plus que "une erreur inattendue". Il fournit au moins un contexte "quoi / où / quand" même s'il ne dit pas "pourquoi / comment". Je pense au moins que le désir de ce niveau élémentaire d’informations n’est pas particulièrement biaisé par ma maîtrise de l’ordinateur.

Le reste est probablement très spécifique à vos clients et à vos besoins particuliers. Mais mon appel concerne au moins quelque chose de plus qu'une "erreur inattendue".


Eh bien, il est une vue biaisée. L'utilisateur moyen ne se soucie pas de savoir pourquoi il ne peut pas faire ce qu'il ne peut pas faire. Ils se soucient seulement de savoir si et comment ils peuvent résoudre leur problème.
gnasher729

"L'utilisateur moyen ne se soucie pas de savoir pourquoi il ne peut pas faire ce qu'il ne peut pas faire. Il ne se soucie que de savoir s'il peut résoudre son problème et comment." Si l'utilisateur moyen ne comprend même pas ce qu'est un fichier ou un serveur, peut-être, mais cela pourrait quand même se rattacher à ce qui est "passible de poursuites", car il pourrait peut-être vous taper sur l'épaule et dire: "Hé , cette application dit ne pas trouver ce fichier de configuration requis ", ou quelque chose de similaire, où vous pourrez peut-être ensuite rechercher le problème et le résoudre rapidement, par exemple
Dragon Energy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.