user interface - examples - Texto del mensaje de error: mejores prácticas
error messages best practices (12)
- 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 manera única el lugar donde ocurrió el error.
- Diseñe el mecanismo para permitir una localización fácil, especialmente si se trata de un producto comercial.
- Si los mensajes de error son visibles para el usuario, hágalos oraciones completas y significativas que no asuman un conocimiento íntimo del código; recuerde, siempre está demasiado cerca del problema, el usuario no. Si es posible, brinde al usuario orientación sobre cómo proceder, a quién contactar, etc.
- Cada error debería tener un mensaje si es posible; de lo contrario, intente y asegúrese de que todas las rutas de desenredo de errores finalmente lleguen a un mensaje de error que arroja luz sobre lo que sucedió.
Estoy seguro de que habrá otras buenas respuestas aquí ...
Estamos cambiando algunos de los textos de nuestros antiguos mensajes de error mal escritos. Cuáles son algunos recursos para las mejores prácticas en la escritura de buenos mensajes de error (específicamente para Windows XP / Vista).
El manejo de errores siempre es mejor que la generación de informes de errores, pero ya que está adaptando los mensajes de error y no necesariamente el código, aquí hay algunas 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 su acción".
También soy un gran admirador de la registración centralizada de errores. Asegúrese de que el registro sea escaneable tanto para humanos como para computadoras. Los usuarios no siempre le permiten saber qué problemas están teniendo, especialmente si se pueden ''solucionar'', por lo que el registro puede ayudarlo a saber qué cosas necesitan reparación.
Si puede controlar el cuadro de diálogo de error fácilmente, tener 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, rastreo, etc. también puede ser una gran ayuda para resolver problemas en tiempo real.
El soporte para multilenguaje se aplica a todo tipo de mensajes, pero tiende a olvidarse en el caso de los mensajes de error.
En segundo lugar, no le diría al usuario información esotérica inútil, como códigos de error numéricos. Sin embargo, me gustaría seguir diciendo que definitivamente registrar esa información para la solución de problemas por personas más conocedores de la tecnología.
En términos de redacción de sus mensajes de error, le recomiendo referirse a las siguientes guías de estilo para aplicaciones de Windows:
- Directrices de experiencia de usuario de Windows , y específicamente la sección sobre mensajes de error aquí .
- Manual de estilo de Microsoft
Intente encontrar una forma de escribir su software para que corrija el problema.
La mejor práctica es evitar que el usuario cause errores en primer lugar.
No le digas a los usuarios nada que no les importe; 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 cometidos por su software. Sobre todo, cuando hay un problema, dígales cómo solucionarlo para que puedan seguir adelante y realizar un trabajo.
Los mensajes más cortos pueden leerse.
Cuanto más largo sea su mensaje de error, menos leerá el usuario. Una vez dicho esto, intente refactorizar el código para que pueda eliminar las excepciones si hay una respuesta obvia. Intente solo tener excepciones que sucedan en función de cosas que estén más allá de su usuario o del control de su código.
El mejor mensaje de excepción es el que nunca debe mostrar.
Para cualquier entrada de usuario (cadenas, nombres de archivos, valores, etc.), siempre muestre el valor erróneo con delimitadores a su alrededor (comillas, corchetes, etc.). p.ej
El nombre de archivo que ingresó no se pudo encontrar: "somefile.txt"
Esto ayuda a mostrar los retornos de espacio en blanco / carro que pueden haberse infiltrado y reduce enormemente la resolución de problemas y la frustración.
Por razones de seguridad, no proporcione información interna del sistema que el usuario no necesite.
Ejemplo trivial: cuando no puede iniciar sesión, no le diga al usuario si el nombre de usuario es incorrecto o si la contraseña es incorrecta; esto solo ayudará al atacante a forzar la fuerza bruta del sistema. En su lugar, solo diga "La combinación nombre de usuario / contraseña no es válida" o algo así.
Siempre incluya sugerencias para Reparar el error.
Un buen mensaje de error debería:
- Sea discreto (sin pantalla azul o pantalla amarilla de la muerte)
- Indique al usuario la dirección para corregir el problema (si es posible, o con quién contactar para obtener ayuda)
- Esconda tonterías inservibles y esotéricas (no diga, "se produjo una excepción de referencia nula en la línea 45")
- Sé descriptivo sin ser detallado. Solo la información suficiente para decirle al usuario lo que necesita saber y nada más.
Una cosa que he empezado a hacer es generar un número único que muestre en el mensaje de error y escribir en el archivo de registro para poder encontrar el error en el registro cuando el usuario me envía una captura de pantalla o llamadas y dice: "Yo Obtuve un error. Dice que mi número de referencia es 0988-7634 "