Ponemos a su disposición un conjunto de consideraciones a la hora de plantear la creación de cualquier tipo de formulario en línea.
1. Utilizar valores predeterminados siempre que sea posible.
El calendario usado en este sitio le permite al usuario seleccionar una fecha en el formato correcto, tal y como lo requiere el sistema.
Cuando los datos a ingresar por el usuario son críticos para la aprobación de una aplicación (fechas de expiración, opciones de selección única, fechas), es más conveniente ofrecerlos en un campo con valores fijos seleccionables, como una etiqueta <SELECT> u otras alternativas como calendarios en Javascript, pues el dejar estos campos como simples campos de texto a ser llenados por el cliente puede prestarse a errores involuntarios por parte del mismo, que pueden denigrar la experiencia del usuario.
2. Demostrar con ejemplos siempre que sea necesario.
Para reducir las instancias de rechazo de formularios por errores involuntarios, es recomendable poner al lado del campo a llenar un ejemplo.
Muchas veces, los usuarios no tienen una idea exacta de cómo llenar un campo determinado de forma correcta. Cuando descubren que el sistema no pudo procesar el formulario, se quedan pensando qué fue lo que hicieron mal.
Muchas veces el problema es de simple falta de comunicación. Para reducir las instancias de rechazo de formularios por errores involuntarios, es recomendable poner al lado del campo a llenar un ejemplo de cómo debería ser una forma correcta de hacerlo.
Así como la falta de ejemplos puede ser contraproducente para la eficacia de un formulario, también lo es el exceso de validación. Un formulario que procure validar (y requerir) cada campo puede ser tomado como hostil e imposible de llenar por muchos usuarios. A menos que el sistema lo requiera en forma absoluta, es necesario ejercer un poco de sentido común y utilizar ejemplos solamente en los casos donde sea evidente que puede haber confusión o dudas entre los usuarios.
3. Distinguir claramente los campos requeridos.
Muchos formularios precisan de campos indispensables para ser procesados por el sistema del sitio web. El problema es que muchas veces no se especifica ni se indica cuáles son esos campos requeridos. Una forma de solucionar esta situación es la de utilizar la convención de un asterisco en rojo, ya sea al lado de la descripción del campo o inmediatamente después del campo en cuestión del formulario, e indicar al principio del formulario que dichos campos son requeridos.
También se puede recurrir al uso del color, o sea, coloreando la descripción del campo a llenar de rojo, o indicar con un borde rojo alrededor del campo de texto, etc. Lo importante es que se vea claramente que dicho campo es requerido, sin dar lugar a dudas.
4. Contar con un sistema de validación.
El formulario de contacto de metodus.com, el cual está basado en Java Server Pages (JSP).
Evidentemente, no basta con las medidas descritas anteriormente para crear un formulario a prueba de errores; para un sistema verdaderamente infalible, es preciso contar con un sistema de validación de campos, ya sea por medio de Javascript o, mejor aún, un sistema basado en soluciones backend como PHP o Java. La ventaja de un sistema basado en backend es el poder crear mensajes de error coherentes, en armonía estética con el sitio y con aspecto profesional, contribuyendo a mejorar la experiencia de usuario. El ejemplo abajo corresponde al formulario de contacto de metodus.com, el cual está basado en Java Server Pages (JSP).
Idealmente se pueden combinar un sistema de validación basado en Javascript (para validación inmediata de campos antes de enviar el formulario) y backend basado en PHP, Java, etc (Para la validación final).
5. Utilice un lenguaje claro, sencillo y útil.
¿Qué se supone que debo entender por “el convenio no está registrado”?
Los formularios y sus correspondientes mensajes de error no son el espacio para “experimentar” con explicaciones rimbombantes de lenguaje confuso o, en el otro extremo, mensajes crípticos y parcos que son esencialmente inútiles.
Este mensaje fue la respuesta del web del Banco Nacional a la verificación de un recibo pendiente de pago. ¿Qué se supone que debo entender por “el convenio no está registrado”? ¿Que el Banco no respalda la entidad a la que pretendo pagar? ¿Qué yo cometí algún error al enviar el formulario? ¿Qué se “cayó el sistema”?
Usuarios que han visto este tema también han visto...
- Como montar una pequeña red con seguridad
- La accesibilidad como parte de la optimizacion para la promocion web en buscadores.
- Principales ideas del Diseño
- Diseño de campos de formularios (II)
- Con google no todo es PageRank
- Versión imprimible de este documento
- Enviar por e-mail este documento
