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

38

Las aplicaciones siempre pueden lanzar errores. Si se produce un error de este tipo, se debe notificar al usuario, porque lo que le pidió a la aplicación que hiciera no tuvo é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 pila ( ¿Debería haber un seguimiento de pila en el mensaje de error presentado al usuario? ), pero no puedo encontrar una pregunta sobre el resto del contenido del error o qué mostrar al usuario usuario.

Por ejemplo, un idioma que admite excepciones (.net, java) tiene el tipo de excepción para compartir, donde ocurrió la excepción, y un mensaje un tanto clarificador para acompañar la excepción. ¿Debería también ocultarse esto al usuario? ¿O deberíamos mostrar esto de todos modos? ¿O deberíamos mostrar un mensaje genérico? ¿O deberíamos mostrar uno de una serie de mensajes basados en cuál es la excepción subyacente?

    
pregunta Nzall 17.06.2014 - 16:40

6 respuestas

34
  

qué mostrar al usuario.   ¿Debería también ocultarse esto al usuario?

Le muestra al usuario lo que es accionable para ellos.

Por ejemplo, si tiene un error debido a alguna excepción de puntero nulo y más un error que un 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 principal no tiene sentido para la mayoría de los usuarios . Tal vez si su base de usuarios objetivo son 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 una serie de 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 "ocurrió un error inesperado".
  • Agregue una descripción detallada del error "opcional"
  • Permitir que los usuarios envíen el informe de error (o hacerlo automáticamente, dependiendo de la base de usuarios)

Ejemplo

  1. Muestra"esto es lo que sucedió" (error inesperado)
  2. Le dice al usuario qué hacer (volver a abrir el correo, incluso incluye un acceso directo para hacer esto)
  3. También tiene un "ver detalles" si alguien tiene curiosidad por ver el error técnico completo
  4. Proporciona una notificación y se presenta un informe de error (ver más abajo)

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

    
respondido por el enderland 17.06.2014 - 16:52
12

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

En general, intente mostrarles solo información útil sobre cosas que puedan resolver por sí mismas. Un seguimiento de la pila 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 dice que La fecha debe tener el formato "aaaa-mm-dd" . Cualquier otra cosa, y es posible que el usuario no sepa cómo responder al error, y es posible que no quieran usar su aplicación, por temor a que se produzcan más errores crípticos y alarmantes (y sí, los usuarios no técnicos a veces se asustan por la pila huellas). Y eso podría ser malo para los negocios.

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

Para usuarios no técnicos, la única vez que creo que sería correcto mostrarles un seguimiento de la pila es en una situación de error crítica en la que la necesita para resolver el problema, y se les pregunta para copiar y pegar el seguimiento de la pila y enviárselo, 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 preguntar al usuario con permiso para compartir el archivo.

    
respondido por el FrustratedWithFormsDesigner 17.06.2014 - 16:48
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 de la base de usuarios, pero debe ser su principal guía: su intención debe ser proporcionar la información necesaria para que el "llamante" determine qué puede hacer, si es que hace algo, para cumplir con éxito. La acción deseada. Si es algo tan simple como un error de acceso a un archivo, le da una ruta de acceso al archivo y el mensaje de que no pudo acceder a él. Si se trata de una excepción de puntero nulo, simplemente envíe un mensaje de error genérico.

Por supuesto, habrá más mensajes de "incapacidad para realizar la acción deseada" que los que el usuario realmente pueda corregir, pero eso es solo vida. La mayoría de las excepciones son porque cometimos un error, no porque el usuario configura el entorno incorrectamente.

    
respondido por el jmoreno 17.06.2014 - 17:40
1

Este es un tema común:

¿Cómo puede ayudar a los no informados / analfabetos 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 hagas ambas cosas!

Sin embargo, el orden es importante y te recomiendo que tengas:

  • Lo que pasó.
  • Qué hacer ahora
  • Detalles técnicos

Detalles técnicos es la parte que contiene información para pedidos avanzados o para usuarios habituales al informar un problema

    
respondido por el Michael Durrant 14.07.2014 - 13:01
0

Lo que quieras mostrar depende de lo avergonzado que estés por joder.

El punto es obtener los detalles de la falta de asistencia técnica 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 regreso a casa automáticamente, o bien 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.

    
respondido por el Martin Maat 21.12.2018 - 16:52
0

Me gusta la razón detrás de la respuesta aceptada, pero respetuosamente estoy en desacuerdo 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 hay que admitir que soy un poco experto en computación 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 los dominios en los que tengo poca experiencia, como la aviación.

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

Si solo 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, es suficiente para simpatizar con mucho más que "lo inesperado error "y estar un poco más contento sentado y esperando 3 horas para el próximo vuelo. De hecho, es posible que prefiera un poco de tecnobabble que pasa por encima de mi cabeza a un "error inesperado" como, "De acuerdo, las palabras que salen de tu boca están entrando en mi oído pero no llegan al procesador central. Pero ahora entiendo que hay algún tipo del problema allí y voy a tomar un café y sentarme allí. ¡Espero que puedan resolver el problema con esa cosa! "

Y a menudo, en términos de manejo de excepciones, creo que normalmente tiene suficiente de ese tipo de información básica de lo que sucedió en el sitio catch , 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 potencialmente 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 influido por mi habilidad con la computadora.

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

    
respondido por el Dragon Energy 21.12.2018 - 16:37