Si bien esto es más un problema de lenguaje escrito que uno de codificación, es algo que los programadores deben hacer en circunstancias en las que un cliente u otra persona no proporcionen la copia. Todos los ejemplos de mensajes de error, buenos o malos, son bienvenidos para aclarar el punto.¿Cómo se escriben los buenos mensajes de error?
Busqué brevemente y no pude encontrar un hilo de engaño. Ok, hazlo. Gracias a todos.
¿Quiere decir orientado al usuario o en un archivo de registro para el personal de administración/desarrollo?
Creo que estos son importantes, en general: "¿Es necesario tomar medidas"
creo que todos estos son importantes, pero la prominencia cambiará dependiendo de la audiencia (como dmckee puntos fuera). Otro consejo (en general) es responder a las 5 W (quién, qué, ... etc)
Para usuarios finales: Indique al usuario qué hacer. Si el usuario cambia algún valor de entrada, vuelva a intentarlo en 5 minutos o llame al servicio de asistencia técnica.
Ejemplo:
"En este momento, el archivo no se puede abrir favor, compruebe que el archivo no está ya abierto por otro programa y vuelva a intentarlo."
Si hay detalles adicionales que podrían asustar al usuario, como un número de error u otra cosa que solo un desarrollador entendería, no los muestre. Escríbalas en un archivo de registro o tenga un botón de detalles que pueda presionar para llegar a ellas.
Supongo que está hablando de mostrar mensajes de error a los usuarios en cuadros de mensaje o en la pantalla.
No se exceda en la obsequiosidad. ¿Cómo verifica un usuario que un archivo no haya sido abierto por otro programa? De verdad odio los mensajes de alerta que me obligan a presionar "OK" cuando no está bien, desde mi punto de vista. –
Estás retomando mi ejemplo específico. Creo que los puntos que he planteado se aplican en general. Para este ejemplo específico, si tiene una mejor redacción, por favor compártalo. Si esto ocurrió al intentar abrir un archivo, ¿no puede simplemente colapsar el programa o no hacer nada en silencio? –
Aprendí estos puntos en un curso uni sobre diseño de interfaz de usuario, y recuerdo que se basaron en investigaciones sólidas. –
Trabajo en una empresa de seguridad de software, por lo que mi respuesta puede ser significativamente diferente de algunas de las respuestas anteriores.
Un buen usuario frente mensaje de error es:
equilibrado entre ser genérico y específico - Usted quiere dar al usuario información suficiente para que puedan corregir su error y seguir adelante, pero tenga en cuenta que un atacante podría utilizar estos mismos mensajes de error para atacar su sitio.Un buen ejemplo de esto es un control de inicio de sesión en el que se devuelve un mensaje de error "contraseña incorrecta para el usuario joe" o "el usuario joe no existe en este sistema" le dice al atacante que están en la ruta de descubrir usuarios correctos. Que cuando no tienes un nombre de usuario o una contraseña es la mitad de la batalla.
Indica al usuario qué fue lo que salió mal. De nuevo, esto se equilibra entre genérico y específico. Un usuario nunca necesita ver un mensaje de error de ODBC, pero podría serle útil saber que el error fue su culpa y que debería volver a intentarlo en unos minutos. Indique al usuario qué pueden hacer para ayudar: si tiene un sistema de registro de back-end (que debería), registre todo lo que crea útil, luego genere una ID que pueda proporcionar al usuario para que pueda llamar o enviar un correo electrónico usted y le diga los pasos exa exactos. También puede automatizar esto al exponer un formulario de envío de errores cuando ocurre un error.
Sea consistente: use una tabla de búsqueda de errores para asegurarse de que todos sus errores sean los mismos (para el mismo problema) y de que estén bien escritos. Typos, errores ortográficos y errores gramaticales no pueden ser tolerados en el software de producción.
Realmente odio los mensajes de error que son genéricos, pero puedo entender la implicancia de seguridad de tener mensajes de error específicos, así que si es posible, registre todos los detalles importantes en el subsistema de registro en su servidor o bien dónde. – Pharaun
Para lo que ya se dijo que yo añadiría:
Recuerda por encima de todo que al usuario final no le importa el nitty-gritty tecnológico. Solo si funciona Cuando no funciona, solo se preocupa por su efecto sobre lo que están tratando de hacer. Un mensaje de error útil debe centrarse en el qué, no el por qué. Mensajes
error debe:
Desde un punto de voz de soporte técnico, también es importante que los mensajes de error sean únicos. Si un usuario puede generar el mismo error de "archivo no se puede abrir" de seis maneras diferentes, dificulta que las personas de soporte técnico averigüen exactamente qué está haciendo el usuario. Por lo tanto, los mensajes de error deben ser únicos para cada tipo diferente de error y, si es posible, proporcione un código o número de error para que las personas de soporte sepan dónde buscar el problema.
Hemos encontrado que cuando los mensajes de error incluyen un código de error, ayuda con el soporte técnico. Cuando los usuarios informan los mensajes de error a las personas de apoyo, a menudo mezclan o informan mal los mensajes de error verbales. Pero, si el mensaje incluye un número de error, son muy buenos para informar el error exacto, como "Recibí un error 8512 cuando traté de imprimir un informe".
Cuando es posible, también ayuda a mantener un registro de errores. Muchas veces los usuarios reportarán errores cuando probaron una operación en particular, pero no recordarán exactamente cuál fue el error. Si hay un registro de errores que puede ser consultado por personal de soporte técnico, es mucho más fácil determinar el problema.
Para escribir buenos mensajes de error, debe pensar en cada audiencia. Una vez que comprenda a la audiencia, es mucho más fácil diseñar los mensajes de error.
En primer lugar, los requisitos para los mensajes de los usuarios finales:
A continuación, los requisitos para los mensajes técnico de soporte:
Por último, los requisitos para los mensajes de soporte de programador:
Un ejemplo de un mensaje de error que es muy malo para un usuario final, pero que podría ser razonable para un desarrollador, es "caché Latencia chocó con las cabeceras de salida." :-)
Por lo general, vale la pena apuntar hacia una razón común para el problema, ya que esto ayudará al usuario en el 99,9% de los casos de error.
Por ejemplo, tenemos dos direcciones para problemas de inicialización. Uno coge excepciones de configuración que establece:
"A excepción reconocida produjo Esto puede ser un problema con la configuración"
y otro para inesperado:
"Se ha producido un error inesperado."
Luego, dependiendo de la configuración (interruptor de activación o desactivación), podemos generar información de desarrollo o más información útil para el usuario final.
No puede haber unos contextos diferentes observar aquí (aunque estoy seguro de que esto se ha mencionado una y otra vez):
1) Si estamos hablando de un sitio web tener que dar una "Vaya, algo malo sucedió, "mensaje, entonces debería haber un lenguaje simple para decirle al usuario que ocurrió un error, intente de nuevo y si todavía hay problemas para ponerse en contacto con soporte en blah blah blah ...
2) Si estamos hablando sobre el registro de una excepción arrojada en el código para que los administradores de sistemas y los desarrolladores la lean, la cuestión pasa a tomar el mensaje de la excepción y el seguimiento de la pila para registrarlo en un archivo de registro, un correo electrónico o el visor de eventos para que pueda ser manejado de manera diferente dependiendo de cuán urgente es que alguien mire esto.
3) Si estamos hablando de escribir el mensaje para una excepción, mi sugerencia es señalar claramente qué tipo de error se cumplió, p. ¿hay una referencia nula donde no debería haber o hay algo peor, como que falta un archivo que debería existir, junto con la gravedad del error, p. ¿Puede la aplicación seguir ejecutándose o debería salir a una página de error en esta condición?
mensajes de error son para los usuarios finales y también para aquellos que tienen que mantener el código
En primer lugar para los usuarios finales, les diga qué hacer. Esto simplemente puede presionar enter para continuar, volver a intentar, cerrar y reiniciar, para reiniciar la PC.
En segundo lugar para los encargados de mantenimiento, incluya tanta información acerca del error como pueda. Nunca hay demasiado Personalmente prefiero un archivo de registro para esto en lugar de un mensaje de error. Aún mejor es incluir una forma para que el usuario final le envíe por correo electrónico el contenido del registro desde la aplicación.
Ese es un buen punto, lo estaba viendo desde el lado de los usuarios, pero los mensajes de error deben indicar lo que sucedió, o al menos dar un número de registro para que el error se pueda buscar en el archivo de registro/base de datos. – MrBoJangles
Desde la perspectiva de los usuarios.
Obviamente, la prevención de errores es lo mejor. Siempre proporcione al usuario suficientes pistas para completar con éxito las tareas (es decir, explique el formato requerido en los campos de entrada de datos). Sin embargo, "Errar es humano ..." y (aplicando los principios de usabilidad a los errores en una aplicación web) el objetivo es el perdón.
Hay tres funciones esenciales a mensajes de error:
1. Obtener la atención - en primer lugar, para garantizar la eficacia, el usuario debe verlo
2. Describir error - informar al usuario de lo que salió mal
3. Sugiera recuperación - dar sugerencias útiles para corregir el error y continuar
Dicho todo esto, me gustaría compilar algo con más detalle, y especialmente wi Ejemplos de mensajes de error buenos y malos.
Si puede decirle al usuario qué hacer, considere hacerlo por medio de un programa. En mi opinión, los mensajes de error solo deberían aparecer si el programa tiene dudas sobre qué hacer. Piense en por qué decidió simplemente fracasar: ¿tal vez no asumir la responsabilidad de tratar de recuperarse? Tal vez el usuario puede hacerlo mucho más fácil? ¿Tal vez el usuario tiene que decidir qué solución tomar? Tal vez pensó que nunca debería suceder (no se olvide de decirle al usuario que se comunique con el soporte o el programador en este caso).
Una cosa que puede dañar mi sistema nervioso es cuando un mensaje de error usa la palabra O. "Archivo no encontrado O ningún permiso O disco lleno O su perro tiene un fuerte dolor de cabeza O ..." Un usuario realmente necesita saber cuál de las posibles causas de error ocurrió. Los programadores evitan las RUP en los mensajes de error.
No copie los mensajes de error en diferentes lugares del código. Si un usuario ve el mensaje en su programa y envía comentarios, un caso más afortunado es cuando puede comprender lo que significa su mensaje de error. El caso menos afortunado es que al menos puede grep todo el código fuente y encontrar el lugar donde el programa se colgó. Si encuentra el mismo mensaje en varios lugares, no puede ayudarse a sí mismo.
Ah, y no olvide mencionar las posibles consecuencias: "El sistema de prevención de ardillas dejó de funcionar. Cualquier cosa almacenada en sus discos duros puede ser modificada aleatoriamente por las ardillas". "El Sistema de Prevención de Ardilla dejó de funcionar. En su lugar, las Ardillas serán prevenidas por el Marco General de Prevención". Hay una diferencia en la severidad.
Si no podemos erradicar la amenaza que representan las ardillas para nuestros sistemas, los terroristas ya habrán ganado. – MrBoJangles
Un buen mensaje de error tiene tres partes:
Si está escribiendo o revisando su mensaje de error, primero concéntrese en obtener estos tres puntos escritos. Incluso si el mensaje es terriblemente largo, no te preocupes por eso cuando escribas por primera vez. Siempre puede regresar y simplificarlo más tarde.
Pero lo contrario no es cierto. Es difícil dar forma a un mensaje pequeño en uno que explique claramente el problema, la causa y la solución del problema. Estará editando constantemente sus pensamientos para asegurarse de que el mensaje se quede pequeño, y en algún momento se bloqueará. Sí, he experimentado ese problema varias veces, por lo que sé lo difícil que se siente.
Después de asegurarse de que su mensaje contiene estas tres partes, es hora de revisarlo. Usted necesita editarlo para asegurarse de que:
Como puede ver, este marco es simple y no necesita mucha reflexión.
Fuentes:
+1 para incluir el tercer enlace a la página msdn Mensajes de error. Definitivamente vale la pena una buena lectura a fondo de eso. Una de las cosas que más me molestan es el signo de exclamación en los mensajes de error ... – ndurante
@ [Thohan]: acaba de crear una etiqueta del muchacho-scout ;-) –
Consulte esta [guía] (https : //msdn.microsoft.com/en-us/library/dn742471.aspx) de Microsoft, incluye ejemplos y mejores prácticas. –