No sobre-validarásArtículos
Con la popularización de los frameworks, código encapsulado y scripts pre-hechos que hacen la tarea de programar un poco menos tediosa, llegó también un efecto inesperado: la sobre-validación. Permítanme explicar qué es esto.
En el desarrollo web, una de las tareas más talacheras es la de validar el input que hacen los usuarios a través de formularios. Tienes que asegurarte de que el usuario haya escrito bien su correo por ejemplo, sin caracteres especiales, con sólo una arroba y muchos otros detalles que aseguran que sea un correo válido. En el caso de un código postal puedes validar que sólo haya escrito números, y que un teléfono tenga cierto número de dígitos. El código bien escrito abstrae la programación a tal punto que es suficiente especificar que un campo es de tipo email para que haga toda la validación tras las cortinas sin que te tengas que preocupar por meterle mano al código. Con la facilidad de validar tan estrictamente todos los campos, ahora hasta mi abuela puede hacer un formulario a prueba de balas.
El problema es que el mundo es muy heterogéneo. Algunos scripts validan que un nombre no contenga números. Así que si al Papa Benedicto XVI se le ocurre escribir su nombre como Benedicto 16 le rechazaríamos su solicitud. Otras mentes débiles diseñan sus bases de datos como en los tiempos donde el espacio en disco duro valía su peso en oro. Créanme, llamándome Mark John Cuauhtémoc MacKay Ávila me lo tomo muy personal cuando un estúpido formulario me dice que mi ridículo nombre es demasiado largo —sé que lo es— pero no por eso lo tengo que mutilar.
Pero aún más débiles son las mentes que diseñan código pensando que sólo en EEUU existe eso a lo que llaman la supercarretera de la información. Seguramente más de uno de ustedes ha tenido que decir que vive en Hawaii o Texas para pasar por un formulario, o dejar un teléfono incompleto porque el diseñador/desarrollador no consideró que podrían necesitar la clave de tu país para comunicarse contigo.
Algunos errores comunes en la sobre-validación de formularios:
- Tratar de convertir el teléfono en un número entero: la mayoría del código para validar un número telefónico intenta quitar los caracteres alfanuméricos para dejar un número entero en la base de datos. Esto es completamente innecesario a menos que uses una máquina para llamar automáticamente a tus clientes. "+052 (555) 555-5555 Ext. 302" es mucho más útil para la persona que va a hacer la llamada.
- Asumir que un código postal sólo se puede componer de números: en Argentina, Canada, Holanda, Inglaterra y Venezuela, entre otros; los códigos postales contienen letras y números. En Irlanda, Hong Kong, Panamá y Vietnam ni siquiera existen. Así que si requieres un código postal le estarás cerrando la puerta a usuarios de estos países.
- Sobre-validar un formulario de contacto: un formulario de contacto generalmente llega a un correo. Normalmente, si tratas de meter un un dato inválido a una base de datos (digamos una cadena demasiado larga), la base de datos va a tronar. En el correo electrónico no existe esta limitación, además hay una persona que que puede interpretar mucho mejor lo que el usuario escribió (como en el ejemplo donde se incluye la extensión en el campo de teléfono).
- Pedir al usuario que escriba las cosas como a la base de datos le gusta: hace unos días traté de consultar mi CURP pero el formulario me lo rechazó porque no le gustaron mis acentos. Lo que el programador debió de haber hecho es remplazar los caracteres acentuados por no-acentuados. Lo mismo sucede con las fechas, frecuentemente se nos pide escribir las fechas con formato mm/dd/yy (formato anglo), pero un calendario que escriba la fecha por ti es más sensible.
Pero lo más importante de todo es: no trates de educar al usuario cómo debe de introducir los datos, el servidor deberá primero tratar de interpretar los datos, y si no encuentra qué hacer con ellos, amablemente deberá disculpar su estupidez y pedirle al usuario que lo introduzca de nuevo en un formato que sí entienda.
Estoy de acuerdo en cierta manera en lo que comentas de las sobrevalidación más no estoy de acuerdo en el último parrafo.
La mayoria de las veces las validacion de datos suelen ser triviales si se adoptan de antemano convenciones sobre como debe entrar la informacion. Mi politica siempre va en el sentido de solicitar solo la informacion indispensable (nombre, email, comentarios) y respecto a los demas si lo quieren llenar bien...
No me imagino tratando de interpretar que es lo quizo escribir el usuario para lograr que la entrada valide ya que desde mi punto de vista no todas las cosas se deben de arreglar mediante codigo si desde un principio viene mal.
Muy buen articulo y muy en acuerdo, me gusto por que ha hecho razonar sobre estos detalles que no habia tomado en cuenta para el desarrollo de mis aplicaciones.
Muchas gracias :)
Interesante el post, aunque considero que fuiste algo tajante.
Aunque si es cierto que puede ser una joda cuando suceden estas cosas de validación y tu como usuario quedas a veces hasta encabritado, también debiste considerar la responsabilidad del diseñador de información para incrementar la usabilidad de los formularios desde el "frente".
Ejemplo, este mismo formulario en su campo sitio web. Quizá al aplicar en el campo se valida si contiene "http" o si no existen espacios en blanco, que se yo, pero primera mano, no tienes idea de como se "llena" adecuadamente. El opcional no induce a este adecuado llenado del campo. Una plantilla, un globito pop-up, o algo que oriente mejor al usuario podría permitir establecer convenciones locales, y estoy seguro que la gente no se molestará o sentirá estúpida, al contrario, sentirá y creerá que ha aprendido a hacer las cosas en forma correcta; sobretodo los usuarios principiantes.
Si pasa este post. Es que no validan los cambios. Disculpa, tenía que probar si funciaban.
Omi: de hecho, poner http:// como guía en el campo de sitio web sería una guía para usuarios más avanzados. Estamos acostumbrados a que los formularios nos boten los datos si no los metemos como el programador quiso, por eso causa incertidumbre si no lo especificas.
Si escribo mi dirección física, no me preocupo por detalles como escribir "Blvd." en lugar de "Boluevard" o "Int." en lugar de "Interior". Como lo escriba de cualquier forma va a llegar. Si los formularios en web no te rechazaran los datos tan seguido, no existiría ese miedo a llenar los datos mal.
Si creo que sea una guia para los usuarios avanzados eso del http, cuando éstos saben que a lo mejor eso hace que funcione bien la liga cuando se incruste automáticamente el contenido en un href. El usuario novato no tiene porque saber esto. Lo que quería expresar, es que tu como infodiseñador deberías de proponer estrategias, no de de educación, pero si de soporte al usuario en cuanto a esto de la llenada de campos. De ahí la idea de una plantilla, pop-ups de dudas o que se yo.
Lo que quise expresar, era que si tu brindas al usuario un poco de apoyo de como sería óptimo llenar un formulario a la primera, antes de que suceda un rebote por manejo errores, la gente podría inferir el cómo en otros formularios y campos similares. O que opinas?
Saludos
Bueno, un formulario bien diseñado es material para otro post (muy complejo por cierto), hay casos en los que vale la pena mostarle al usuario la manera óptima de llenar un campo, pero sólo para ahorrarle tiempo. Supongamos que estoy buscando un dominio. El usuario lo puede meter como:
http://www.duopixel.com
www.duopixel.com
duopixel.com
El formulario debe de aceptar las tres posibilidades (pues son válidas, después de todo). Pero para ahorrarle tiempo al usuario, deberá de presentar como ejemplo duopixel.com.
Muy buen post como siempre Mark.
Una cosa que hay que tomar en cuenta es el alcance de nuestro sitio o aplicación: ¿Vale la pena que nuestro directorio regional considere a los Tailandeses? Si te va a requerir mucho más codigo hacerlo, entonces no vale la pena.
Por otra parte, si creo que le toca al backend "adivinar" lo que el usuario "quiso decir" en la medida de lo posible. Siempre me gusta citar "remember the milk"(http://rememberthemilk.com) como un ejemplo de validación amigable, al permitirte introducir fechas en la forma de "tomorrow" o "next week".
Para el programador es tedioso? Si que lo es. Pero el valor añadido a la experiencia de usuario vale la pena.
Tienes la boca llena de verdad Mark. Eso de diseñar formularios BIEN HECHOS está muy cabrón. Cualquiera puede poner campos de INPUT y manejo de errores chafa que van a volver loco a cualquier usuario normal.
Hey, es una buena idea para un startup, vender formularios ya listos, jajaja.
Saludos!
Atte.
German
holaestachido esto
Creo que todo trata de seleccionar la herramienta de programación adecuada para la labor que deseas ejecutar.
Hay herramientas más poderosas para cierto tipo de trabajo que otras y todo dependerá de la selección que realices a la hora de ejecutar el trabajo.
Es importante, de todos modos, realizar un filtro adecuado de lo que los usuarios introducen a los sistemas, recuerden que basura entra, basura sale. Y mientras mejor depurada sea la data mejor será la información que sale del sistema.
Ernesto.
Estoy de acuerdo con lo que escribiste, es algo muy importante para tener en cuenta.
El futuro se entiende analizando el pasado y el presente, asi que esta informacion vale oro!