Texto del mensaje de error: mejores prácticas

Question

Estamos cambiando parte del texto de nuestros mensajes de error antiguos y mal escritos.¿Cuáles son algunos recursos de mejores prácticas para escribir buenos mensajes de error (específicamente para Windows XP/Vista)?

Answer 1

En términos de redacción de sus mensajes de error, recomiendo consultar las siguientes guías de estilo para aplicaciones de Windows:

• Pautas de experiencia del usuario de Windows, y concretamente el apartado de mensajes de error aquí.
• Manual de estilo de Microsoft

Answer 2

La mejor práctica definitiva es evitar que el usuario cause errores en primer lugar.

No le digas a los usuarios nada que no les interese;El código de error 5064 no significa nada para nadie.No les digas que hicieron algo mal;no permitirlo en primer lugar.No los culpe, especialmente por los errores que cometió su software.Sobre todo, cuando hay un problema, diles como arreglarlo para que puedan seguir adelante y trabajar un poco.

Answer 3

Un buen mensaje de error debería:

• Sea discreto (sin pantalla azul ni pantalla amarilla de la muerte)
• Indique al usuario cómo corregir el problema (por su cuenta si es posible, o a quién contactar para obtener ayuda).
• Ocultar tonterías esotéricas e inútiles del programador (no diga "se produjo una excepción de referencia nula en la línea 45")
• Sea descriptivo sin ser detallado.Información suficiente para decirle al usuario lo que necesita saber y nada más.

Una cosa que comencé a hacer es generar un número único que muestro en el mensaje de error y escribirlo en el archivo de registro para poder encontrar el error en el registro cuando el usuario me envía una captura de pantalla o me llama y dice: "Yo Recibí un error.Dice que mi numero de referencia es 0988-7634"

Answer 4

Por razones de seguridad, no proporcione información interna del sistema que el usuario no necesite.
Ejemplo trivial:cuando no pueda iniciar sesión, no le diga al usuario si el nombre de usuario o la contraseña son incorrectos;Esto sólo ayudará al atacante a aplicar fuerza bruta al sistema.En su lugar, simplemente diga "La combinación de nombre de usuario y contraseña no es válida" o algo así.

Answer 5

Incluya siempre sugerencias para solucionar el error.

Answer 6

Intente encontrar una manera de escribir su software para que les corrija el problema.

Answer 7

Para cualquier entrada del usuario (cadenas, nombres de archivos, valores, etc.), muestre siempre el valor erróneo con delimitadores alrededor (comillas, corchetes, etc.).p.ej.

No se pudo encontrar el nombre de archivo que ingresó:"algún archivo.txt"

Esto ayuda a mostrar cualquier espacio en blanco/retorno de carro que pueda haberse colado y reduce en gran medida la resolución de problemas y la frustración.

Answer 8

1. Evite mensajes de error idénticos provenientes de diferentes lugares;parametrice con file:line si es posible, o use otro contexto que le permita a usted, el desarrollador, identificar de forma única dónde ocurrió el error.
2. Diseñe el mecanismo para permitir una fácil localización, especialmente si se trata de un producto comercial.
3. Si los mensajes de error son visibles para el usuario, conviértalos en oraciones completas y significativas que no supongan un conocimiento íntimo del código;Recuerde, usted siempre está demasiado cerca del problema; el usuario no.Si es posible, oriente al usuario sobre cómo proceder, a quién contactar, etc.
4. Cada error debe tener un mensaje si es posible;de lo contrario, intente asegurarse de que todas las rutas de resolución de errores lleguen finalmente a un mensaje de error que arroje luz sobre lo sucedido.
   
   Estoy seguro de que habrá otras buenas respuestas aquí...

Answer 9

De hecho, se pueden leer mensajes más cortos.

Cuanto más largo sea el mensaje de error, menos leerá el usuario.Dicho esto, intente refactorizar el código para poder eliminar las excepciones si hay una respuesta obvia.Intente tener solo excepciones que ocurran en función de cosas que escapan al control de su usuario o de su código.

El mejor mensaje de excepción es el que nunca tienes que mostrar.

Answer 10

Error manejo siempre es mejor que el error informar, pero como estás actualizando los mensajes de error y no necesariamente el código, aquí tienes un par de sugerencias:

Los usuarios quieren soluciones, no problemas.Ayúdelos a saber qué hacer después de un error, incluso si el mensaje es tan simple como "Cierre la ventana actual y vuelva a intentar realizar la acción".

También soy un gran admirador del registro centralizado de errores.Asegúrese de que el registro sea escaneable tanto por humanos como por computadora.Los usuarios no siempre le informan qué problemas tienen, especialmente si se pueden solucionar, por lo que el registro puede ayudarlo a saber qué cosas deben solucionarse.

Si puede controlar el cuadro de diálogo de error fácilmente, tenga un cuadro de diálogo que muestre un mensaje agradable y legible con un botón de "detalles" para mostrar el número de error, el seguimiento, etc.También puede ser de gran ayuda para la resolución de problemas en tiempo real.

Answer 11

El soporte multilenguaje se aplica a todo tipo de mensajes, pero tiende a olvidarse en el caso de mensajes de error.

Answer 12

En segundo lugar, no le diría al usuario información esotérica inútil, como códigos de error numéricos.Sin embargo, continuaría diciendo que definitivamente registre esa información para que personas con más conocimientos técnicos puedan solucionar problemas.