Quand un message d'exception est-il trop gros?
Je teste une application Web qui comporte un message d'exception encombrant pour tenter d'ajouter des factures non éligibles à un système de paiement, voir l'image ci-dessous. Le développeur ne voit aucun problème à cela, mais son aspect clairement maladroit. Existe-t-il une bonne référence pour les normes actuelles sur la façon dont un message comme celui-ci est conçu? Le bon sens vous suggère de créer un message générique qui n'inclut pas de balises de données réelles pour conserver la taille du message de manière prévisible.
tl; dr:
Certaines factures ne sont pas éligibles au paiement. Ils ont été exclus du traitement des paiements. [ détails ]
Les messages d'erreur doivent séparer deux choses:
- Informations pour l'utilisateur final (ce qu'ils peuvent faire pour "réparer les choses")
- Diagnostics pour le support et pour les développeurs
Bien sûr, le développeur est content car il voit ce que ils veulent. Mais cela n'est pas utile pour l'utilisateur et risque de créer des demandes d'assistance.
Dans des tests d'utilisateurs finaux très informels et statistiquement insignifiants, j'ai constaté que, pour de nombreux utilisateurs, la différence entre
Impossible d'ouvrir "doctorat", le fichier est en lecture seule
et
Erreur: impossible d'ouvrir "doctorat", le fichier est en lecture seule (code 5h)
est énorme: inclure tout ce qui semble "effrayant" ou technique peut déclencher une "cécité de message d'erreur", c'est-à-dire que l'utilisateur, en supposant que le message ne lui est pas destiné, ne parvient pas à enregistrer la partie qui indique ce qu'il pourrait faire lui-même pour résoudre le problème , et demande plutôt un soutien (ou abandonne simplement).
Le deuxième aspect où ce message échoue est de dire à l'utilisateur ce que cela signifie pour lui. [~ # ~] i [~ # ~] ne peut pas le dire en regardant votre capture d'écran: est-ce une information générale? Est-ce le résultat de mon opération précédente? A-t-il échoué complètement ou le logiciel a-t-il traité les autres factures?
Les messages d'erreur tels que ceux-ci font partie de la communication dans l'application qui incluent des erreurs, des avertissements, des informations, etc. le message ci-dessus est trop long, une meilleure approche serait d'avoir un titre court qui dit ce qui n'a pas fonctionné et un contenu corporel qui explique l'erreur en détail. Le contenu du corps doit être de 2 lignes maximum et une option à développer. De plus, les lignes sont trop longues, ce qui est contraire à critère d'accessibilité WCAG 1.4.8 signifie que les personnes ayant une déficience visuelle et des troubles de la lecture auront du mal à lire des textes de plus de 80 caractères (espace compris) en une seule ligne.
Je pense que vous devriez séparer vos erreurs en deux catégories:
Erreurs d'application:
Voici quand quelque chose ne va pas avec l'application, quelque chose comme une erreur dans le code, un dysfonctionnement de celui-ci ou quelque chose comme ça. Dans ce cas, il n'y a pas beaucoup d'informations pertinentes pour l'utilisateur, donc les codes d'erreur sont une bonne idée ici.
Avec le code d'erreur, l'utilisateur peut obtenir un soutien des développeurs d'applications et le signaler, de sorte que l'utilisateur a quelque chose de mieux qu'une simple information non sensée (je veux dire quelque chose comme --- trace de la pile ).
Est nécessaire pour informer l'utilisateur que l'application a échoué , et encourager l'utilisateur à contacter le support et signaler le problème. L'utilisateur sait donc qu'il ne peut rien faire et le développeur peut obtenir des informations de l'utilisateur:
L'application a rencontré un problème et nous ne pouvons pas traiter votre demande pour le moment, veuillez signaler le problème, afin que nous puissions vous aider à résoudre ce problème. Veuillez signaler le code d'erreur [00001] lorsque vous le signalez.
Erreurs logiques/Erreurs utilisateur:
Ces erreurs se produisent lorsque l'application fait ce qui est prévu de faire, mais l'erreur se produit, en raison d'un autre type d'erreur (erreur utilisateur, erreur de validation, etc.).
Dans ce cas, une bonne approche consiste à informer l'utilisateur qu'un problème est survenu (dans votre cas: certaines de vos factures n'ont pas pu être traitées). Dans ce cas particulier, il est nécessaire d'informer et de donner la plupart des informations que vous pouvez à l'utilisateur, afin qu'il puisse résoudre le problème.
Un exemple (basé sur la réponse @peterchen, il donne une très bonne réponse sur ce cas)
Certaines factures ne sont pas éligibles au paiement. Ils ont été exclus du traitement des paiements. Détails
Les détails pourraient ressembler à ceci:
+=========+=================================+=============================================================+
| Invoice | Problem | Possible solution |
+=========+=================================+=============================================================+
| 00001 | Date is outside permitted range | Review the dates of your invoice, so it matches this period |
+---------+---------------------------------+-------------------------------------------------------------+
| 00002 | Price includes decimals | Use only integers for your price |
+---------+---------------------------------+-------------------------------------------------------------+