El formulario de registro conten\u00eda campos para el nombre, direcci\u00f3n, tel\u00e9fono, fax, correo electr\u00f3nico y otros datos que son necesarios para solicitar el servicio. Eran entre 15 y 20 campos de informaci\u00f3n, la mayor\u00eda obligatorios (lo cu\u00e1l es comprensible por el tipo de servicio que da esta compa\u00f1\u00eda). Bien, lleno todos los datos, reviso que est\u00e9n correctos y presiono el bot\u00f3n de enviar<\/em>.<\/p>\n \u00a1Sorpresa!… una p\u00e1gina con un mensaje de error. El texto del mensaje de error era aproximadamente el siguiente:<\/p>\n DATOS ILEGALES. Usted ha introducido deliberadamente o accidentalmente combinaciones ilegales de caracteres en el formulario de registro. Por favor regrese a la p\u00e1gina previa e intente enviar la informaci\u00f3n de registro de nuevo. Nota: sus acciones, incluyendo su dominio y direcci\u00f3n IP est\u00e1n siendo monitorizadas y han sido registradas. Si pareciera que usted est\u00e1 deliberadamente intentando causar da\u00f1o a este sitio, el webmaster lo reportar\u00e1 con su proveedor de servicio de internet y podr\u00eda iniciar acciones legales. Comp\u00f3rtese apropiadamente.<\/em><\/p>\n Mmm, el mensaje dice que me comporte, que parezco criminal y que es mi culpa. Bueno, ignorar\u00e9 el tono agresivo por esta vez.<\/p>\n Despu\u00e9s de leer tal mensaje busqu\u00e9 entre el texto para ver si dec\u00eda d\u00f3nde estaba exactamente el error: no encontr\u00e9 referencia alguna. No encontr\u00e9 tampoco un bot\u00f3n para regresar al formulario. Bien, entonces usemos el bot\u00f3n de regresar del navegador, y adivinemos d\u00f3nde est\u00e1 el error.<\/p>\n \u00bfSer\u00e1 el gui\u00f3n en mi apellido? No, el error sigue apareciendo. \u00bfEl acento en mi apellido? No. \u00bfEl acento en el nombre del estado? Tampoco. \u00bfEl punto que abrevia mi segundo nombre? No. Quiz\u00e1s espera un \u00fanico nombre y no dos. No. \u00bfEl signo de m\u00e1s (+) del tel\u00e9fono? No. \u00bfLos par\u00e9ntesis? Tampoco. Quiz\u00e1s los espacios entre los n\u00fameros. No.<\/p>\n Bueno, el mensaje sigue diciendo que me comporte, que sigo pareciendo criminal y que a\u00fan es mi culpa. Cada vez me gusta menos ese tono agresivo.<\/p>\n Finalmente supe que se refer\u00eda a los guiones del tel\u00e9fono y as\u00ed pude completar el registro.<\/p>\n Quiero pensar que soy un usuario avanzado de internet. Podr\u00eda equivocarme, pero espero que mis 12 a\u00f1os navegando y mis 8 a\u00f1os creando sitios y aplicaciones web me respalden. Si esta es la experiencia que tuve yo, \u00bfqu\u00e9 experiencia podr\u00eda tener alguien con habilidades menos desarrolladas o con menos paciencia? \u00bfO alguien con m\u00e1s dinero que no le importe ir con otro proveedor m\u00e1s caro? (Recuerden que estoy interesado s\u00f3lamente por el precio). \u00bfCu\u00e1ntos clientes estar\u00e1n perdiendo?<\/p>\n Resumiendo, el resultado fue el siguiente:<\/p>\n En una frase: mi experiencia con la empresa fue mala<\/strong>.<\/p>\n Bueno, esto fue tan malo que sent\u00ed la necesidad de decirle a alguien de la empresa lo que pensaba de su proceso de registro. Busqu\u00e9 el formulario de contacto y despu\u00e9s de llenarlo… \u00a1sorpresa de nuevo! El mismo error apareci\u00f3. Ahora lo que pas\u00f3 es que tienen un l\u00edmite de 500 caracteres en el mensaje: tuve qu\u00e9 reducir mi mensaje original de 3000 caracteres a un telegrama de 500. (Quinientos caracteres suelen ser menos de 100 palabras en espa\u00f1ol). Y de nuevo, fue algo que tuve qu\u00e9 deducir yo mismo porque el mensaje de error no ayuda.<\/p>\n \u00bfRealmente sigo interesado en los servicios de la empresa? Pues, un poco. Pero ya no me entusiasma, no me inspiran confianza ni respeto. Y adem\u00e1s tengo muchas dudas sobre su capacidad t\u00e9cnica y gerencial. Originalmente iba a recomendar sus servicios a varios clientes, pero despu\u00e9s de esta experiencia he preferido recomendar otros proveedores.<\/p>\n Hay tres aspectos distinto que afectaron mi experiencia con la empresa: uno es la mala implementaci\u00f3n del formulario, otra es la forma in\u00fatil del mensaje de error y otro es el tono del lenguaje utilizado en el mensaje de error.<\/p>\n En este documento quiero comentar sobre los \u00faltimos dos aspectos, pero concentr\u00e1ndome en el tercero (el tono del lenguaje).<\/p>\n La validaci\u00f3n de datos<\/strong> es simplemente revisar que el formato de los datos sea correcta. En una forma extendida, tambi\u00e9n puede significar revisar que la informaci\u00f3n sea correcta (no s\u00f3lo el formato). Por ejemplo, validar que un correo electr\u00f3nico tenga el formato correcto consiste en revisar que tenga un nombre de usuario, una arroba (@) y un nombre de dominio; que el nombre y el dominio no contengan caracteres inv\u00e1lidos, que el dominio tenga por lo menos dos partes separadas por un punto, etc. Obviamente estamos validando s\u00f3lamente la forma (el formato) del dato, no sabemos si la direcci\u00f3n existe o no. Otro ejemplo: al revisar el c\u00f3digo postal, podr\u00edamos evaluar no s\u00f3lo su formato, sino la informaci\u00f3n que contiene; por ejemplo, podemos revisar que coincida con el campo de pa\u00eds. Etc.<\/p>\n Antes de validar un dato, es importante filtrarlo. El filtrado de datos<\/strong> consiste en eliminar partes indeseables del dato introducido. Por ejemplo, al introducir su tel\u00e9fono, un usuario puede usar “(206) 464-2001<\/em>“, “206-464-2001<\/em>“, “2064642001<\/em>“, “206 464 20 01<\/em>“, “+206 4642001<\/em>“, etc. El dato puede filtrarse eliminando todos los caracteres no num\u00e9ricos (incluyendo espacios) y entonces contando la cantidad de d\u00edgitos; para verificar si el formato parece ser correcto. Entonces puede almacenarse intacto<\/span> (tal como lo introdujo el usuario) o normalizarse<\/span> (por ejemplo, a\u00f1adiendo los guiones donde se considere apropiado). Esto (filtrar para validar, pero guardar sin filtrar) es sumamente importante cuando se tiene una audiencia internacional, porque el formateado de datos puede variar mucho entre regiones.<\/p>\n Uno de los usos del filtrado de datos es eliminar c\u00f3digo HTML, de Javascript (o de cualquier otro lenguaje de scripts) que un usuario con malas intenciones pueda introducir.<\/p>\n Lo importante aqu\u00ed es que el formateado y la seguridad no deben ser tareas del usuario<\/strong>. Esa carga debe ser trabajo del formulario.<\/p>\n Los errores en la introducci\u00f3n de datos deben clasificarse por su gravedad. En una escala simple podemos considerar errores leves, errores graves y errores cr\u00edticos. Los errores leves<\/strong> ser\u00edan aquellos que el c\u00f3digo de validaci\u00f3n puede ignorar, como un dato faltante que no se requiere para el proceso. Un ejemplo es que el n\u00famero de tel\u00e9fono parezca<\/em> incompleto, el c\u00f3digo de validaci\u00f3n puede simplemente ignorar este dato porque: 1) quiz\u00e1s es un n\u00famero v\u00e1lido de otra regi\u00f3n, 2) no es tan<\/em> importante, 3) el usuario quiz\u00e1s prefiere no darlo.<\/p>\n Los errores graves<\/strong> ser\u00edan aquellos que deben ser corregidos o el proceso no podr\u00eda ser completado. Por ejemplo, un n\u00famero de tarjeta de cr\u00e9dito incompleto podr\u00eda impedir todo el proceso en un formulario de compra, as\u00ed que debe ser corregido.<\/p>\n Los errores cr\u00edticos<\/strong> ser\u00edan aquellos que impiden el funcionamiento del formulario. Estos errores generalmente no son causados por la informaci\u00f3n que el usuario introduce sino por fallas t\u00e9cnicas del sitio web. Por ejemplo, cuando el c\u00f3digo del formulario no puede completar un registro porque no puede iniciar una conexi\u00f3n a la base de datos.<\/p>\n Antes de mencionar los pros o contras de cada soluci\u00f3n, yo prefiero usar ambas al mismo tiempo, si no es posible entonces en el servidor solamente, y si no es posible entonces mejor no uso un formulario.<\/p>\n Validar en el cliente<\/span> consiste en usar Javascript (o Java, o VBScript, o Flash, o controles ActiveX) para revisar los datos antes de que el usuario oprima el bot\u00f3n de env\u00edo. Las \u00fanicas ventaja son que la retroalimentaci\u00f3n puede ser inmediata y que el usuario no tiene qu\u00e9 esperar a que la p\u00e1gina se env\u00ede para enterarse del problema. La principal desventaja es que no es posible controlar la configuraci\u00f3n de los usuarios: podr\u00edan tener Javascript desactivado y entonces no ocurrir\u00eda la validaci\u00f3n. La pregunta que el desarrollador debe hacerse es: \u00bfconfiar\u00eda en una computadora que no controla de un usuario que no conoce para validar los que se guarda en su base de datos? La respuesta generalmente es NO<\/span>. (Incluso en intranets, e incluso usando Flash, Java o ActiveX, no es recomendable tomar tales riesgos).<\/p>\n Validar en el servidor<\/span> consiste en que el c\u00f3digo que hace la validaci\u00f3n est\u00e1 en el servidor, en la p\u00e1gina que recibe el formulario. Generalmente es c\u00f3digo que est\u00e1 en PHP, Perl, Java, VBScript, JScript, etc. El control de ese c\u00f3digo est\u00e1 a cargo del desarrollador (o de quienes mantienen el sitio) y por lo tanto pueden confiar en \u00e9l. La principal ventaja es la seguridad y confiabilidad. La principal desventaja es que la retroalimentaci\u00f3n no es inmediata, requiere enviar el formulario para recibir el mensaje de error.<\/p>\n Usar ambas validaciones tiene las ventajas combinadas sin sus desventajas. La validaci\u00f3n en el cliente debe ser ligera (por ejemplo, s\u00f3lamente revisar si hay datos faltantes) y la del servidor debe ser completa (es decir, debe revisar todo, incluyendo lo que se revisa del lado del cliente).<\/p>\n Los errores leves<\/strong>, ignorables, pueden simplemente… ignorarse. En algunos casos, cuando se sospeche que el usuario podr\u00eda estar cometiendo un error, se le puede informar qu\u00e9 sospechamos y c\u00f3mo arreglarlo m\u00e1s adelante. \u00a1Pero no impida completar el proceso!<\/p>\n Por ejemplo, si falta el tel\u00e9fono, al finalizar el registro se puede decir “No di\u00f3 un tel\u00e9fono para contactarle, as\u00ed que lo haremos por correo electr\u00f3nico. Si en el futuro desea que lo contactemos por tel\u00e9fono, visite la opci\u00f3n Mi Cuenta y agregue su tel\u00e9fono.”.<\/p>\n Los errores graves<\/strong>, no ignorables, se deben notificar al usuario. Esta notificaci\u00f3n debe ser lo m\u00e1s simple, precisa y clara para el usuario. No basta decir “hay un error<\/em>“, ni siquiera “hay un error en el n\u00famero de tarjeta<\/em>“. Lo mejor es decir exactamente porqu\u00e9 parece haber un error: “El n\u00famero de tarjeta tiene menos de 10 d\u00edgitos. Por favor introduzca todos los n\u00fameros que aparecen al frente de su tarjeta.<\/em>“.<\/p>\n Por ejemplo, si la direcci\u00f3n de correo est\u00e1 incompleta (un error muy com\u00fan es que los usuarios introducen solamente el nombre de usuario sin dominio), el usuario debe enterarse: “Parece que la direcci\u00f3n de correo est\u00e1 incompleta. Por favor revise que contenga la direcci\u00f3n completa (usuario @ dominio).”.<\/p>\n Otro detalle es, \u00bfd\u00f3nde mostrarle al usuario el mensaje de error? La forma m\u00e1s usable es mostrar el mensaje cerca del campo donde est\u00e1 el dato con problemas, marc\u00e1ndolo notoriamente para que el usuario sepa de inmediato que algo requiere su atenci\u00f3n.<\/p>\n Cuando ocurren errores cr\u00edticos<\/strong> el formulario simplemente no funciona o muestra un error muy cr\u00edptico que s\u00f3lo tendr\u00eda sentido para el desarrollador del formulario. Una forma de evitarlos es usar c\u00f3digo de manejo de excepciones en el c\u00f3digo de validaci\u00f3n, de modo que las fallas cr\u00edticas sean manejadas con gracia. Por ejemplo, si la conexi\u00f3n a la base de datos falla, interceptar la excepci\u00f3n y mostrar un mensaje de error amigable. Aquellos errores que impiden la ejecuci\u00f3n del c\u00f3digo del formulario se deben manejar a un nivel m\u00e1s bajo, generalmente usando p\u00e1ginas de error personalizadas del servidor web.<\/p>\n Si no se manejan los errores cr\u00edticos, el usuario no sabr\u00e1 si el proceso se complet\u00f3 total o parcialmente. Por ejemplo, el sitio de pagos por internet de cierta compa\u00f1\u00eda telef\u00f3nica de M\u00e9xico, ocasionalmente marcaba un error de VBScript en sus p\u00e1ginas ASP al momento de pagar. \u00bfSe completar\u00eda el pago? \u00bfLo intento de nuevo o no? Eso es poco elegante, habla mal de la compa\u00f1\u00eda y de su habilidad tecnol\u00f3gica. Incluso si no es posible determinar el estado del proceso (por ejemplo, no es posible saber si el pago se hizo o no), debe darle al usuario alguna forma de remedio; por ejemplo instrucciones precisas o un tel\u00e9fono para aclaraciones.<\/p>\n La mayor\u00eda de las aplicaciones web, incluyendo los formularios, son creados por personal que no est\u00e1 involucrado en las relaciones p\u00fablicas de la empresa u organizaci\u00f3n. Todas las comunicaciones de la empresa, incluyendo los mensajes de error de su sitio web, deben ser revisadas por personal de relaciones p\u00fablicas o alguien con la visi\u00f3n y sensibilidad adecuadas (como alguien de la gerencia). Si no, el lenguaje de los mensajes de error reflejar\u00e1 la mentalidad del desarrollador<\/strong> y no estar\u00e1 alineado (necesariamente) con los objetivos de la empresa.<\/p>\n Los mensajes de error deben ser:<\/p>\n Ya mencion\u00e9 que el tono del lenguaje del mensaje de error refleja la mentalidad del desarrollador que lo escribi\u00f3 o del personal de relaciones p\u00fablicas (o cualquier otra persona) que lo revis\u00f3. Lo que no debe perderse de vista es que esa mentalidad es un reflejo de la cultura de la empresa<\/strong>. En las empresas con estructuras jer\u00e1rquicas, la cultura es en parte impuesta por los ejecutivos de m\u00e1s alto nivel, quienes expl\u00edcita o t\u00e1citamente definen la percepci\u00f3n que tienen los trabajadores de los clientes.<\/p>\n Por ejempo, si una empresa no le da importancia a la atenci\u00f3n al cliente: entregan productos tarde, dejan a los clientes en espera, hacen publicidad irrespetuosa, etc., entonces los trabajadores de esa empresa se comportar\u00e1n de acuerdo a ese c\u00f3digo, escrito o no. Y el desarrollador no est\u00e1 exento de esta influencia.<\/p>\n As\u00ed mismo, una empresa con una cultura paranoide donde el cliente siempre es sospechoso, mostrar\u00e1 eso por todas partes en su sitio web.<\/p>\n A veces el tono depende solamente de la mentalidad del \u00e1rea de sistemas: “los usuarios son tontos<\/em>“, “todos quieren piratear nuestro software<\/em>” o “todos quieren destruir nuestro sitio<\/span>“. Y entonces crean formularios que tratan a los usuarios como tontos, como piratas o como crackers.<\/p>\n Lo m\u00e1s triste es que para el personal de la empresa (o de esa \u00e1rea particular) todo se ve muy normal. Por eso, a veces resolver el problema del lenguaje del sitio web requiere una soluci\u00f3n cultural<\/strong> en toda la empresa, no s\u00f3lamente un buen departamento de relaciones p\u00fablicas.<\/p>\n Si usted es un desarrollador web<\/strong> recuerde que al escribir una aplicaci\u00f3n web (o de cualquier tipo) estar\u00e1 tratando con personas. Esa aplicaci\u00f3n estar\u00e1 representando a la empresa u organizaci\u00f3n frente al resto del mundo, y debe por tanto seguir las pol\u00edticas de la empresa (escritas o no) sobre la atenci\u00f3n al cliente.<\/p>\n Si usted tiene un puesto gerencial<\/strong> (ya sea en el \u00e1rea de TI o en otra) recuerde que los desarrolladores crean aplicaciones siguiendo la cultura organizacional, y usted es la persona indicada para modificar, afinar y reforzar esa cultura. Revise que esa cultura vaya orientada realmente a los objetivos y la misi\u00f3n de la empresa, y evite que su sitio web se convierta en un sitio anticlientes.<\/p>\n Si usted es personal de relaciones p\u00fablicas<\/strong> o control de calidad<\/strong> de desarrollo (o alguien que revisa las aplicaciones o sitios web), recuerde que debe tener una gu\u00eda de est\u00e1ndares que incluya el lenguaje apropiado para todo el contenido, incluyendo los mensajes de error.<\/p>\n Si usted es un simple usuario (todos lo somos) y encuentra un sitio web con mensajes de error que lo impulsan a alejarse lo m\u00e1s pronto posible, av\u00edsele al webmaster y expr\u00e9sele que no le gusta el trato que le dan en su sitio web. Quiz\u00e1s hasta se sienta mejor.<\/p>\n Si quiere aprender m\u00e1s acerce de c\u00f3mo crear formularios web que no espanten a sus clientes, le recomiendo los siguientes sitios:<\/p>\n \u2020=Contiene informaci\u00f3n sobre validaci\u00f3n de datos y mensajes de error.<\/p>\n","protected":false},"excerpt":{"rendered":" Cuando el trato directo es substituido por un sitio web, es como si el personal de primer contacto fuera substituido por programadores web. Describimos el caso de un formulario de registro mal implementaros con mensajes de error que parecen dise\u00f1ados para ser anticlientes. Al final exponemos algunos consejos \u00fatiles para crear formularios web y mensajes de error amigables con los clientes.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,11,15],"tags":[],"class_list":["post-8","post","type-post","status-publish","format-standard","hentry","category-desarrollo-de-software","category-en-espanol","category-usabilidad-web"],"_links":{"self":[{"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/posts\/8","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":0,"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mariovaldez.net\/webapps\/blog\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\u00bfQu\u00e9 sali\u00f3 mal?<\/h3>\n
C\u00f3mo validar los datos del formulario.<\/h3>\n
Tipos de errores en el formulario.<\/h3>\n
![\"form_error_02.png\"](\"http:\/\/www.mariovaldez.net\/webapps\/blog\/wp-content\/uploads\/2006\/01\/form_error_02.png\")
\nEjemplo de un mensaje de error cr\u00edtico no manejado. Al usuario se le presenta un mensaje de error cr\u00edptico e in\u00fatil.<\/p>\nValidar en el cliente o en el servidor.<\/h3>\n
C\u00f3mo reportar los errores al usuario.<\/h3>\n
![\"form_error_01.png\"](\"http:\/\/www.mariovaldez.net\/webapps\/blog\/wp-content\/uploads\/2006\/01\/form_error_01.png\")
\nEste es un ejemplo de un mensaje de error apropiada (aunque no perfecto).<\/p>\nEl lenguaje de los mensajes de error.<\/h3>\n
\n
El mensaje corporativo de los mensajes de error.<\/h3>\n
Conclusiones.<\/h3>\n
Informaci\u00f3n adicional.<\/h3>\n
\n