Al usuario no le interesa el “mensaje de error” que mostramos

Hace unos días conversaba con unos amigos sobre la necesidad de contar con un experto para resolver los problemas y errores de una aplicación. Ojo que con esto me refiero a “qué hacer cuando se cae la página y sale un mensaje de ERROR HORRIBLE”.

Tan horribles son estos errores que en ASP.NET se les conoce como los de página amarilla de la muerte, vamos, seamos sinceros, la tienen que haber visto al menos un par de veces.

Si bien es cierto con esto me refiero a los errores en aplicaciones web, en el resto de aplicaciones también encontramos estos problemas. O es que acaso no les ha pasado que luego de un error horrible se han cerrado las ventanas y se han quedando mirando la pantalla pensando en un “y ahora que pasó?”

Un caso muy conocido es por ejemplo el de la pantalla azul de la muerte, pantalla que hace mucho tiempo era tristemente parte de la tradición de las primeras versiones de Windows.

Si bien es cierto hace mucho tiempo que no tengo ese problema (salvo ciertas excepciones del tipo “chicos no hagan esto en casa”), el problema no es único a Windows (ustedes también lo han pasado amiguitos así que no se rían), tanto así que aquí hay un enlace de wikipedia que explica a detalle lo que es conocido por muchos como las pantallas de la muerte.

Definitivamente no vamos conversar sobre quien tiene mas pantallas de la muerte o si es que existe alguna formula mágica que nos permita evitar estos errores, les adelanto que esto es algo que no podemos evitar por completo porque errar es humano y –salvo algunos amigos que tengo– todos somos humanos, pero lo que si debemos considerar es que las caídas o errores que tenga una aplicación no deberían llegar de esta forma al usuario (y con esta forma me refiero a la horrible pantalla amarilla con la que comenzamos este post)

Es por eso que cuando el usuario nos comunica sobre un error nos encontramos con este tipo de conversaciones:

(usuario) Hola, tengo un problema en <por ejemplo, aplicación de contabilidad>
(programador) Si, qué ha pasado?
(usuario) No se, salió un error y se cerró todo
(programador) Mas o menos que hiciste?
(usuario) Trabajar en la página de <por ejemplo, contabilización mensual>, como siempre.
(programador) Mas o menos que decía el error?
(usuario) No se. Error?

Estos diálogos muchas veces terminan con la genial idea de:

Pedir control remoto sobre la máquina del usuario (y para esto hay cientos de herramientas, la más básica y difundida por buen tiempo fue TeamViewer, no?)
Pedir un pantallazo del error (okey, un screenshot, un printscreen)
Pedir que se le avise al programador ni bien se repita el error (también podría aplicar cualquiera de las opciones anteriores)

Como habrán notado, desde que manejamos esas conversaciones ya estamos dependiendo del usuario y por que no admitirlo? de la virgencita del internet pues los errores se dan por muchas variantes (una de ellas, nosotros) y hay situaciones en las que simplemente no se pueden replicar (ahora me van a decir que no les ha pasado eso)

Sinceramente no saben cuantas veces he escuchado un “lo que pasa es que sigo estoy buscando la causa del error” y hay que admitirlo de una vez por todas, esa es una frase que seguirá escuchándose por buen tiempo en los desarrollos a medida, quizá no tanto como hace diez años, pero se sigue dando (lo que pasa es que cuando somos jóvenes pues cometemos errores y a veces no aprendemos de ellos)

(Ahora si) Lo que tiene que cambiar es la forma de como analizamos el error y para eso se necesita una base sólida que se forma con por lo menos un detalle técnico del error, este lo debemos tomar del stack trace arrojado por el framework con que estamos trabajando. En el caso de la pantalla amarilla lo que buscamos casi siempre es lo que estoy marcando con una línea roja.

Como podrán notar este tipo de información es demasiado técnica y a pesar de eso seguimos dejando que llegue al usuario, a veces por descuido y muchas otras por desconocimiento (esto pasa por lo general cuando creen que programar en .net es fácil).

Lo que seria genial es tener una conversación como esta:

(usuario) Hola, tengo un problema en <por ejemplo, aplicación de contabilidad>
(programador) Si, qué ha pasado?
(usuario) No se, salió un error
(programador) Mas o menos que hiciste?
(usuario) Trabajar en la página de <por ejemplo, contabilización mensual>, como siempre.
(programador) Por favor me puedes indicar el código de error que te salió?
(usuario) Claro, es el <por ejemplo, 666>
(programador) Anotado, por favor déjame revisar el caso y te estamos comentando.
(usuario) Gracias.
(programador) De nada, querido usuario, que nunca te equivocas

Okey lo siento, la ultima linea es una broma 😀 pero lo que si no es una broma es que si notan es que la conversación se basa en mensajes amigables y códigos de error, pues la idea es que no asustemos al usuario con mensajes de error sin sentido, menos aun, no debemos espantarlos con pantallas amarillas.

Entonces que es lo que tenemos que hacer?

Pues lo primero a tener en consideración es personalizar los mensaje de error, por lo menos tiene que ser una página de error amigable. Con esto evitas el terror que le puedas generar al usuario.

Mi sugerencia aquí es que puedes hacer que esta página sea, digamos… interesante.

Tener una página amigable no arregla los problemas del usuario pero estoy seguro que es mucho mejor a un mensaje que nadie más que el programador puede entender

Ahora, en términos técnicos el programador necesita la información del error que antes llegaba al usuario –que ahora debe estar feliz jugando pacman– y no le servía mas que para asustarlo.

Para esto lo que tenemos que hacer es registrar el detalle del error, sea en base de datos o en un archivo plano, no importa, la idea es registrar esta información, haciendo uso de:

Las facilidades del .net framework, aquí un ejemplo interesante.
Usando log4net, aquí un ejemplo muy interesante.
Usando Elmah, aquí un ejemplo muy pero muy interesante.

Se dieron cuenta que me gusta Elmah? Pues les comento que hasta la ultima vez que lo utilicé me dejó muy impresionado.

Si bien es cierto en todas las situaciones y ejemplos mostrados no hay ejemplos que generen y muestren el código de error (la verdad no he buscado pero deben haber :-D), pero créanme que con implementando mensajes personalizados y registros de error es un buen primer paso.

El segundo sería generar y mostrar el código de error y el tercero y no menos importante sería integrarlo a un esquema de mensajería usando cuadros de diálogo amigables (por lo menos diálogos en jQuery, no?)

Un abrazo

@jersson,