¿Cuánta información sobre un error debe mostrarse al usuario?


38

Las aplicaciones siempre pueden arrojar errores. Si se produce un error de este tipo, se debe notificar al usuario, porque lo que le pidió a la aplicación no ha tenido éxito.

Sin embargo, ¿cuánta información se le debe dar al usuario? Creo que la mayoría de nosotros estamos de acuerdo en no mostrar un seguimiento de la pila ( ¿Debería haber un seguimiento de la pila en el mensaje de error presentado al usuario? ), Pero no puedo encontrar una pregunta sobre el resto del contenido del error o qué mostrarle al usuario.

Por ejemplo, un idioma que admite excepciones (.net, java) tiene el tipo de excepción para compartir, dónde se produjo la excepción, y un mensaje un tanto clarificador para acompañar la excepción. ¿Debería esto también estar oculto para el usuario? ¿O deberíamos mostrar esto de todos modos? ¿O deberíamos mostrar un mensaje genérico? ¿o deberíamos mostrar uno de varios mensajes en función de cuál es la excepción subyacente?

Respuestas:


34

Qué mostrar al usuario. ¿Debería esto también estar oculto para el usuario?

Le muestra al usuario lo que es accionable para ellos.

Por ejemplo, si tiene un error causado por alguna excepción de puntero nulo y más error que error de usuario, no desea una explicación completa porque no pueden hacer nada diferente.

¿O deberíamos mostrar esto de todos modos? ¿O deberíamos mostrar un mensaje genérico?

Mostrar la excepción como el contenido del mensaje de error primario no tiene sentido para la mayoría de los usuarios . Quizás si su base de usuarios objetivo es desarrolladores, podría mostrar la información como el error completo todo el tiempo (tal vez tenga una aplicación interna para pruebas automatizadas). Pero, en general, los usuarios no pueden hacer nada diferente incluso con ese conocimiento.

¿deberíamos mostrar uno de varios mensajes en función de cuál es la excepción subyacente?

La mejor estrategia es hacer lo siguiente:

  • Interprete el error en texto que sea significativo para el usuario.
    • Parte de esto es "¿qué puede hacer el usuario de manera diferente?"
    • Si no pueden hacer nada diferente, diga algo como "se ha producido un error inesperado".
  • Agregue una descripción de error detallada "opcional"
  • Permitir a los usuarios enviar el informe de errores (o hacerlo automáticamente, según la base de usuarios)

Ejemplo

ingrese la descripción de la imagen aquí

  1. Muestra "esto es lo que sucedió" (error inesperado)
  2. Le dice al usuario qué hacer (reabrir correo, incluso incluye un acceso directo para hacerlo)
  3. También tiene "ver detalles" si alguien siente curiosidad por ver el error técnico completo
  4. Proporciona notificación de que se archiva un informe de error (ver abajo)

Tenga en cuenta que, en algunos casos, es posible que desee que el informe de errores sea manual o automático.


20
Estoy en desacuerdo. No hay nada tan molesto como una aplicación que imprime "se ha producido un error". a la pantalla y luego sale. Cuando eso sucede, siempre me pregunto por qué el desarrollador fue tan flojo como para imprimir un mensaje tan poco informativo. Explique algo al usuario para que pueda entender lo que salió mal en un sentido general, incluso si no hay nada que pueda hacer al respecto. En el mejor de los casos, pueden buscar en Google el mensaje de error y quizás encontrar una solución que alguien más haya descrito, lo cual es casi imposible si cada error diferente imprime el mismo mensaje genérico.
Jon Bentley

3
@ JonBentley Lo estás viendo como un desarrollador, que quiere entender estas cosas. El usuario promedio simplemente se preocupará de que debe entenderlo, lo cual no necesita.
deworde

12
@deworde Por el contrario, lo estoy considerando como usuario . Como usuario, no quiero entenderlo en términos técnicos, pero quiero suficiente información como para no sentir que la persona que escribió el software es incompetente ("se ha producido un error" da la impresión de que el desarrollador no No sé lo que estaban haciendo), y así puedo buscar respuestas. Si cada falla dice "ha ocurrido un error", entonces una búsqueda en Google no me ayudará. Es mucho más probable que un mensaje único para cada situación me lleve a un foro en el que otra persona tuvo el mismo problema y tal vez lo resolvió.
Jon Bentley

3
@JonBentley algunos puntos para su consideración. Primero, el punto principal de esta respuesta es que le das al usuario información procesable. Si se trata de un error, pueden solucionarlo y deben proporcionarles información para resolverlo. Esto cae en You show the user what is actionable for them. Si conoce la causa del problema, se lo muestra al usuario en la descripción. Pero, en general, si conoce el motivo de un error, sabrá la resolución del problema para informar al usuario adecuadamente.
enderland

2
En segundo lugar, sobrestima enormemente la capacidad promedio del usuario para resolver sus problemas. La gran mayoría de la población es lo que la mayoría de los desarrolladores / programadores / personas de Stack Exchange llamarían analfabetos informáticos. Francamente, la mayoría de estas personas no están equipadas para diagnosticar, solucionar problemas y resolver problemas. Detalle de hecho puede hacer las cosas peor porque la gente puede malinterpretar las cosas que harían sentido completo a los desarrolladores. Los programadores y las personas expertas en tecnología no son casi universalmente el objetivo demográfico para la mayoría de las aplicaciones, para decepción de todos aquí ... :)
enderland

12

Depende de quién sea el usuario y qué puede hacer con la información.

En general, trate de mostrarles solo información útil sobre cosas que puedan resolver por sí mismos. Una traza de 40 líneas con un error de expresión regular en la parte superior no es muy útil. Mucho mejor sería un mensaje que diga Fecha debe estar formateado como "aaaa-mm-dd" . Cualquier otra cosa, y el usuario puede no saber cómo responder al error, y luego puede que no quiera usar su aplicación, por temor a que cause más errores crípticos y aterradores (y sí, los usuarios no técnicos a veces se asustan por la pila rastros). Y eso podría ser malo para los negocios.

Para las aplicaciones internas utilizadas por otros desarrolladores, estoy un poco más relajado acerca de mostrar un seguimiento de pila, además de algo más útil , porque sé que el usuario puede manejar ver un seguimiento de pila y probablemente sepa qué hacer al respecto.

Para los usuarios no técnicos, la única vez que creo que estaría bien mostrarles un seguimiento de la pila es en una situación de error crítico donde lo necesitan para resolver el problema, y ​​se les pide que copien y peguen el seguimiento de la pila y lo envíen para usted, aunque realmente una forma mucho mejor de hacerlo es pedirles que envíen un archivo de registro, o mejor aún, que la aplicación envíe un archivo de registro al desarrollador, después de pedirle al usuario permiso para compartir el archivo.


55
No estaría de acuerdo con una aplicación que envíe registros a cualquier lugar sin preguntarme. En cambio, el cuadro de diálogo de mensaje de error debería proporcionar una opción para informar el error. El usuario debe poder revisar cualquier información, incluida la traza de la pila, antes de enviar el informe.
piedar

1
@piedar: Ese es un buen punto.
FrustratedWithFormsDesigner

44
@piedar: Tener un botón "Ver más detalles" en el diálogo de error, o un enlace al archivo de registro de la aplicación es probablemente una buena manera de presentar todos los detalles sangrientos a los usuarios avanzados que desean esa información. Incluso una casilla de verificación "mostrar detalles por defecto", si quiere tomarse la molestia de codificarlo. Pero no todos los usuarios querrán ver eso, y algunos usuarios se verán desactivados por eso.
FrustratedWithFormsDesigner

2
@ Paddy: Tienes razón, pero: 1) Es un ejemplo. : P 2) Tal vez he estado arreglando y limpiando ese código, por lo que está fresco en mi mente ...
FrustratedWithFormsDesigner

2
@NateKerkhofs "Y si él es el desarrollador, puede replicar el error" .. - oh, si eso fuera cierto :(
Blorgbeard

1

Los mensajes a los usuarios deben tratarse de la misma manera que crear una nueva excepción para lanzar: usted proporciona la información que necesitarán para decidir qué hacer.

Por supuesto, esto dependerá de su aplicación y base de usuarios, pero debe ser su director rector; su intención debe ser proporcionar la información necesaria para que la "persona que llama" determine qué puede hacer, si es que puede hacer algo, para realizar con éxito la acción deseada. . Si es algo simple como un error de acceso a un archivo, le da una ruta de acceso al archivo y el mensaje de que no puede acceder a él. Si se trata de una excepción de puntero nulo, solo envíe un mensaje de error genérico.

Por supuesto, habrá más mensajes de "incapaz de realizar la acción deseada" que mensajes que el usuario pueda corregir, pero así es la vida: la mayoría de las excepciones se deben a que cometimos un error, no porque el usuario configuró el entorno incorrectamente.


1

Este es un tema común:

¿Cómo puede ayudar a los analfabetos desinformados / informáticos al mismo tiempo que muestra información que pueden usar los usuarios más avanzados, como programadores, desarrolladores, evaluadores, etc.

¡Creo que la respuesta es que haces las dos cosas!

Sin embargo, el orden es importante y le recomiendo que tenga:

  • Que pasó.
  • Qué hacer ahora
  • Detalles técnicos

Detalles técnicos es la parte que tiene información para pedidos avanzados o para usuarios habituales cuando se informa un problema


0

Lo que quieres mostrar depende de lo avergonzado que estés por arruinarlo.

El punto es obtener los detalles de la falla al soporte técnico de la manera más rápida y fluida posible. Eso puede significar que envía el archivo de registro, incluido el seguimiento de la pila del error de terminación, de vuelta a casa automáticamente o le pide al usuario que haga clic en un botón que iniciará la transferencia. Tal vez a través de una memoria USB si no hay conexión a Internet.


0

Me gusta la razón detrás de la respuesta aceptada, pero debo discrepar respetuosamente al menos con mi interpretación de limitar la información a lo que es "procesable" . Quiero saber un poco más que eso como usuario que "error inesperado" .

Y admito que soy un poco experto en informática y tengo ese sesgo, pero no creo que esta sea una visión particularmente sesgada. Porque puedo hacer todo lo posible para eliminar ese sesgo aplicando esta mentalidad a dominios para los que tengo poca experiencia, como la aviación.

Si bien sé poco sobre la aviación, digamos que mi vuelo se retrasa o cancela y lo único que el personal me dice es: "Tuvimos un error inesperado. Espere 3 horas para un vuelo posterior". Al menos me encontrará un poco más de un cliente descontento en esos casos porque, aunque en realidad no afecta mi curso de acción de ninguna manera, solo quiero saber un poco más sobre por qué estoy siendo incomodado de esta manera como cliente que paga.

Si simplemente dijeron: "Estamos experimentando un clima turbulento", o "Tuvimos una emergencia médica en nuestro vuelo anterior", o un mal funcionamiento del equipo o lo que sea, eso es suficiente para que comparta mucho más que un "error inesperado" y estar un poco más contento sentado y esperando 3 horas para el próximo vuelo. En realidad, incluso podría preferir un poco de tecnobabble que se me pasa por la cabeza a un "error inesperado" como, "Está bien, las palabras que salen de tu boca van a mi oído pero no llegan al procesador central. Pero ahora entiendo que hay algún tipo de problema allí y voy a tomar un café y sentarme allí. ¡Espero que resuelvan ese problema con esa cosa increíble! "

Y a menudo en términos de manejo de excepciones, creo que generalmente tiene suficiente información básica sobre lo que sucedió en el catchsitio, incluso si desea ocultar los detalles más técnicos de la excepción, como:

try
{
     load_file(file_name);
}
catch (const exception& ex)
{
     exception_dialog("Failed to load file: '{1}'.", file_name);
}

Y eso ni siquiera muestra lo que podría ser la información muy técnica adjunta a la excepción, pero al menos nos dice mucho más que un "error inesperado". Al menos proporciona un "qué / dónde / cuándo" contextual, incluso si no dice "por qué / cómo". Creo que al menos el deseo de este nivel básico de información no está particularmente sesgado por mi conocimiento de la computadora.

El resto probablemente sea muy específico para sus clientes y necesidades particulares. Pero mi atractivo es al menos para algo un poco más que "error inesperado".


Bueno, es una vista sesgada. Al usuario promedio no le importa por qué no pueden hacer lo que no pueden hacer. Solo les importa si y cómo pueden solucionar su problema.
gnasher729

"Al usuario promedio no le importa por qué no pueden hacer lo que no pueden hacer. Solo les importa si pueden solucionar su problema y cómo lo hacen". Si el usuario promedio ni siquiera entiende qué es un archivo o servidor, tal vez sí, pero eso podría estar vinculado a lo que es "accionable", porque podrían tocarlo en el hombro y decir: "Hola , esta aplicación dice que no puede encontrar este archivo de configuración requerido ", o algo por el estilo, donde podría buscar el problema y solucionarlo rápidamente, por ejemplo
Dragon Energy
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.