Texte du message d'erreur - Meilleures pratiques

Question

Nous sommes en train de modifier une partie du texte pour nos anciens messages d'erreur mal écrits. Quelles sont quelques ressources pour les meilleures pratiques pour la rédaction de bons messages d’erreur (spécialement pour Windows XP / Vista).

Answer 1

Pour ce qui est de la formulation de vos messages d'erreur, je vous recommande de vous reporter aux guides de style suivants pour les applications Windows:

• Consignes relatives à l'expérience utilisateur Windows , et plus particulièrement à la section relative aux erreurs messages ici .
• Manuel de style Microsoft

Answer 2

La meilleure pratique consiste à empêcher l'utilisateur de provoquer des erreurs.

Ne rien dire aux utilisateurs; le code d'erreur 5064 ne veut rien dire à personne. Ne leur dites pas qu'ils ont fait quelque chose de mal; le refuser en premier lieu. Ne les blâmez pas, surtout pas pour les erreurs de votre logiciel. Surtout, en cas de problème, dites-leur comment résoudre ce problème afin qu’ils puissent passer à autre chose et que certains travaux soient terminés.

Answer 3

Un bon message d'erreur devrait:

• Soyez discret (pas d'écran bleu ou d'écran jaune de la mort)
• Indiquez à l'utilisateur comment corriger le problème (si possible seul ou avec qui contacter pour obtenir de l'aide)
• Cachez les absurdités du programmeur ésotérique et inutiles (ne dites pas, "une exception de référence nulle s'est produite à la ligne 45")
• Soyez descriptif sans être bavard. Juste assez d'informations pour dire à l'utilisateur ce qu'il doit savoir et rien de plus.

Une chose que j'ai commencé à faire est de générer un numéro unique que j'affiche dans le message d'erreur et que j'écris dans le fichier journal afin que je puisse trouver l'erreur dans le journal lorsque l'utilisateur m'envoie une capture d'écran ou appelle et dit: "J'ai une erreur. Il est indiqué que mon numéro de référence est le 0988-7634 "

Answer 4

Pour des raisons de sécurité, ne fournissez pas d'informations système internes inutiles à l'utilisateur.
Exemple trivial: en cas d'échec de la connexion, n'indiquez pas à l'utilisateur si le nom d'utilisateur est incorrect ou si le mot de passe est incorrect; cela ne fera qu'aider l'attaquant à forcer le système. Dites plutôt: " La combinaison nom d'utilisateur / mot de passe n'est pas valide " ou quelque chose comme ça.

Answer 5

Toujours inclure des suggestions pour remédier à l'erreur.

Answer 6

Essayez de trouver un moyen d'écrire votre logiciel pour qu'il corrige le problème.

Answer 7

Pour toute entrée utilisateur (chaînes, noms de fichiers, valeurs, etc.), affichez toujours la valeur erronée avec des délimiteurs (guillemets, crochets, etc.). par exemple

Le nom de fichier que vous avez entré est introuvable: "quelquefichier.txt"

.

Cela permet d'afficher tous les retours à la ligne ou les espaces qui pourraient s'être introduits et réduit considérablement le dépannage et la frustration.

Answer 8

1. Évitez les messages d'erreur identiques provenant de différents endroits; paramétrez avec file: line si possible, ou utilisez un autre contexte qui vous permette, en tant que développeur, d’identifier de manière unique l’emplacement de l’erreur.
2. Concevez le mécanisme pour permettre une localisation facile, en particulier s'il s'agit d'un produit commercial.
3. Si les messages d'erreur sont visibles de l'utilisateur, transformez-les en phrases complètes et significatives n'impliquant pas une connaissance intime du code; rappelez-vous que vous êtes toujours trop près du problème - l'utilisateur ne l'est pas. Si possible, indiquez à l'utilisateur comment procéder, qui contacter, etc.
4. Chaque erreur devrait avoir un message si possible; Si ce n'est pas le cas, essayez de vous assurer que tous les chemins d'erreurs d'erreurs atteignent un message d'erreur qui éclaire la situation.
   
   Je suis sûr qu'il y aura d'autres bonnes réponses ici ...

Answer 9

Les messages plus courts peuvent en réalité être lus.

Plus votre message d'erreur est long, moins l'utilisateur lira. Cela étant dit, essayez de reformuler le code afin d'éliminer les exceptions en cas de réponse évidente. Essayez d’avoir uniquement des exceptions basées sur des choses indépendantes de la volonté de votre utilisateur ou de votre code.

Le meilleur message d'exception est celui que vous ne devez jamais afficher.

Answer 10

La gestion des erreurs est toujours préférable à une signalisation , mais comme vous adaptez les messages d'erreur et pas nécessairement le code, voici quelques suggestions:

Les utilisateurs veulent des solutions, pas des problèmes. Aidez-les à savoir quoi faire après une erreur, même si le message est aussi simple que: "Fermez la fenêtre en cours et réessayez."

Je suis également un grand partisan de la consignation centralisée des erreurs. Assurez-vous que le journal est à la fois humain et numérisable. Les utilisateurs ne vous informent pas toujours des problèmes qu’ils rencontrent, en particulier s’ils peuvent être contournés. Le journal peut donc vous aider à déterminer les problèmes à résoudre.

Si vous pouvez contrôler facilement la boîte de dialogue d’erreur, le fait d’avoir une boîte de dialogue contenant un message lisible avec un bouton "Détails" pour indiquer le numéro de l’erreur, la trace, etc. peut être d’une grande aide pour la résolution de problèmes en temps réel. bien.

Answer 11

La prise en charge du multilingue s'applique à tous les types de messages, mais a tendance à être oubliée dans le cas des messages d'erreur.

Answer 12

Je voudrais en second lieu ne pas dire à l'utilisateur des informations ésotériques inutiles telles que des codes d'erreur numériques. Cependant, je ferais un suivi en disant que les personnes plus avisées sur le plan technique doivent absolument consigner ces informations dans un journal pour qu'elles soient résolues.