Cómo diseñar un buen formulario muchos a uno

Importancia del diseño de un buen formulario

El diseño de un buen formulario realmente va más allá de utilizar diferentes tipos de campos, lo que ocurre es que tenemos encasilladas determinadas asociaciones a asociarlas a unos campos.

Un ejemplo puede ser una asociación de muchos-a-uno, en la que parece que automáticamente tenemos que generar un campo desplegable, un select de HTML, pero no tiene por qué ser así.

Siempre hay que buscar maximizar la usabilidad y la experiencia de usuario, ya que pueden incrementar nuestra tasa de éxito.

En internet se habla de la historia de la web de Expedia, y de cómo quitando un campo en un formulario de pago, que no se entendía muy bien qué significaba, consiguieron aumentar sus ingresos en 12 millones de euros en un año.

Esto quiere decir que un formulario bien diseñado puede cambiar por completo una aplicación web, porque está claro que ningún usuario es feliz rellenando formularios, ni para comprar, ni para publicar en una red social, siempre lo quiero hacer todo de la manera más fácil posible.

Algunas buenas prácticas

Algunas pautas sobre buenas prácticas que se pueden aplicar a los formularios son las siguientes:

• Solo los datos indispensables

Los formularios mastodónticos siempre echan para atrás al usuario, con lo cual sería deseable que se incluyeran solamente los datos indispensables.

Esto requiere un esfuerzo en el diseño de nuestro formulario y en el modelo de datos, pero esto puede aumentar nuestra tasa de éxito.

• Una columna, con los títulos sobre el campo

También es bueno mostrar el formulario en una sola columna, aunque con esto nos toque lidiar con el diseño de nuestra aplicación.

Está demostrado que los formularios que están en varias columnas hacen que los usuarios tiendan a perderse.

• Secuencia lógica de campos

Hay que utilizar una secuencia lógica, de forma que el usuario pueda seguirla. Mejor si nos podemos el tabulador, siendo ideal tener un campo debajo del otro y que el usuario pueda ir pasando fácilmente de uno a otro.

El diseño de campos que esté más unidos solo se debe usar en contextos muy concretos. Por ejemplo, si estamos montando una fecha a partir de un campo día, un campo mes y un campo año, sí que podrían estar en una misma línea.

Salvo en esos casos, en general debemos tender a tratar de poner cada campo en una línea.

• Cada campo debe tener el tamaño necesario

Si hacemos un campo en el que vamos a escribir un texto muy largo y queda muy corto supondrá una mala experiencia de usuario. También hay que evitar crear un campo muy grande para un valor muy pequeño.

Hay que tratar siempre de ajustar los campos lo máximo posible.

• Ofrecer ayuda al usuario con las predicciones que podemos hacerle

Podemos ayudar al usuario diferenciando campos que son obligatorios de los que no, utilizar algún asistente o algún componente concreto a la hora de escribir un texto, etcétera.

Estas ayudas al usuario harán que la tasa de éxito del formulario aumentará.

• No usar botones de reset

Debemos huir de este tipo de botones que se utilizan para borrar los campos del formulario o para restablecerlos, ya que son una práctica del siglo pasado.

• Mensajes de error claros

Los mensajes de error que utilicemos no deben ser farragosos y siempre tienen que ser claros.

Si el usuario se ha equivocado al cumplimentar algo del formulario, tenemos que informarle, pero siempre de la manera más clara posible.

Tipos de campos relacionales

Cuando vamos a trabajar con campos relacionales, es decir, campos que asocian un objeto con otro, nos podemos encontrar con tres tipos de asociaciones entre datos:

• Muchos-a-uno (many-to-one)

• Uno-a-muchos (one-to-many)

• Muchos-a-muchos (many-to-many)

Asociaciones muchos-a-uno

Las asociaciones entre datos muchos-a-uno, son la asociación más frecuente y suelen tener diversas variantes, como una asociación normal, de agregación, de composición, etcétera.

Mediante esta asociación asociamos una instancia de una clase de una entidad, con varias instancias de otra.

Algunos ejemplos clásicos pueden ser:

• Producto y categoría: un producto suele pertenecer solamente una categoría, pero una categoría puede estar asociada a varios productos diferentes.

• Pedido y cliente: un pedido se asocia a un único cliente, pero un cliente puede realizar muchos pedidos.

• Población y provincia: una población pertenece a una provincia, pero una provincia tiene muchas poblaciones.

Cómo implementarlos visualmente

Lo más clásico para hacer un formulario en el cual tenemos que asociar, por ejemplo, un producto a una categoría, sería el del de un select, en el que lo asociaríamos de esta manera que vemos en la imagen:

En Thymeleaf no es complicado hacerlo, y se puede pintar fácilmente mediante un th:field dentro del campo select, y con th:each ir pintando las diferentes opciones, de esta forma:

Con una expresión condicional le podríamos añadir el atributo selected si fuera en un formulario de edición.

Además, tenemos otras posibilidades, por ejemplo, si el conjunto de valores con el cual queremos asociar no es muy grande, podríamos utilizar una lista de botones radio.

Por ejemplo, si quisiéramos asociar a un objeto determinado color de fondo, y solamente ofrecemos cuatro posibilidades (green, blue, yellow, white), podríamos hacerlo directamente como una serie de botones radio en lugar de con desplegable.

Estos botones radio podemos hacerlos más atractivos visualmente, porque los podríamos crear con algo más de estilo o también como botones toggle, en los que cuando pinchamos en una opción se deshabilita la contraria y viceversa.

Si el conjunto de opciones no es muy grande y lo queremos hacer más visual, pues podemos hacer estos campos radio con una serie de botones con imágenes, en los cuales claramente, con un tamaño mayor, pudiéramos invitar al usuario, de una manera mucho más visual, a elegir una opción.

Si el conjunto de valores fuese más grande o tendente incluso a ilimitado, es decir, que se gestionaran de una manera aparte, en lugar de utilizar un campo select, que se puede hacer enorme, como en un select de un país donde aparecen los más de 200 países que hay en el mundo y se vuelve totalmente insufrible, podríamos utilizar un input + datalist.

De esta manera, el input nos permite escribir, pero por detrás tiene una lista que nos va a ayudar, y en el momento en el vamos afinando un poco en lo que hemos escrito, nos va filtrando para después elegir valor correspondiente.