Dise̱o de formularios РCampos (I)

Todos sabemos lo que es un campo de un formulario pero: ¿Sabemos cuál es su longitud aconsejable? ¿Cuándo no utilizar tipografía proporcional? ¿Sabemos qué diferencia un campo protegido de uno no disponible? El objetivo de este artículo es aportar soluciones a aspectos de diseño de los campos y su interacción que a menudo suscitan dudas al diseñador. Por su extensión, el artículo se ha dividido en dos partes, ésta es la primera entrega.

¿Tipografía proporcional o monoespacio?

Me refiero no a la tipografía de las etiquetas si no a la de los valores que contengan los campos. Lo más frecuente suele ser utilizar la misma tipografía que las etiquetas y que normalmente será sin serifa y proporcional como, por ejemplo, arial, verdana o tahoma.

Sin embargo, en campos de entrada, la tipografía proporcional puede dar algún problema de feedback ya que no permite al usuario predecir el número exacto de caracteres que puede introducir. En la mayoría de las ocasiones esto no será realmente un problema y primaremos la coherencia de tipografías con el resto del formulario. Pero, cuando estemos diseñando para usuarios que deban utilizar el formulario con mucha frecuencia, deberemos primar la utilidad a la estética y utilizar las fuentes monoespacio no proporcionales, como la courier, si es necesario.

Por ejemplo, para un campo en donde el usuario deba introducir el nombre de una empresa u organización podríamos reservarle un espacio de 30 caracteres, suficiente par la mayoría de los casos. Veamos lo que pasa con los nombres siguientes:

El primer nombre contiene 30 caracteres y el segundo 32. Cuando el usuario introduzca el primero, no tendrá ningún problema puesto que hemos reservado 30 caracteres, pero cuando introduzca el segundo no podrá introducir los dos últimos, el sistema se lo impedirá. Sin embargo, el usuario percibirá espacio en blanco sobrante a la derecha y, probablemente intentará introducir los 2 caracteres restantes con el lógico resultado de frustración. Lo peor será que el usuario no tiene manera de saber en qué casos podrá introducir toda la información y en cuales no, con lo que no podrá evitar errores futuros.

Esto, evidentemente, no tiene importancia si se trata de formularios o aplicaciones de uso poco frecuente. Pero si nos ponemos en el lugar de un responsable de compras que para cada pedido deba introducir el nombre de un proveedor, le será mucho más práctico que el formulario utilice una fuente no proporcional, tal y como se muestra en el ejemplo siguiente.

En este caso, a medida que introduce la información, el usuario puede predecir el espacio restante y abreviar, si lo precisa, el contenido. En el ejemplo anterior, el usuario ha optado por eliminar los puntos del acrónimo "S.A.".

¿Longitud igual o diferente?

En un formulario es conveniente hacer agrupaciones lógicas de campos (ver artículo "Composición visual de formularios") e igualarlos en longitud ayuda al orden visual y a mejorar la comprensión de los grupos. Sin embargo, esto puede a veces dar también problemas de feedback puesto que el usuario no podrá predecir con facilidad la cantidad de caracteres que admite cada campo.

Veamos un ejemplo:

En la imagen anterior se puede observar que los campos que han de contener la población, la provincia y el país tienen la misma longitud que el campo "calle". Los primeros tienen una longitud que podemos estimar adecuada pero el campo calle es excesivamente corto para la información que ha de contener. Si estamos diseñando un formulario de alta de contacto para una agenda personal, seguramente esto es correcto ya que primamos el orden visual (los contactos son más frecuentemente consultados que actualizados). Pero si estamos diseñando una aplicación que deba servir para una entrada de datos intensiva, lo mejor es diseñar los campos con su longitud exacta y así ayudamos al usuario a introducir la información en el formato correcto.

Cómo mostrar los estados

Podemos distinguir tres posibles estados de un campo: editable, protegido y no disponible.

Campo editable:

En él el usuario puede introducir y modificar información. El diseño gráfico dependerá muchas veces de la plataforma de inplementación. En interfaces GUI el más utilizado es un rectángulo con un contorno con aspecto 3D y el fondo blanco con el texto en negro. En entorno web, PDA y móviles el contorno no acostumbra a tener aspecto 3D.

Los campos editables captan la atención del usuario con mucha facilidad, cuando respetan estas características gráficas.

Campo protegido:

En él el usuario no puede introducir ni modificar el contenido. Se utiliza para mostrar información en respuesta a una petición del usuario.

Aunque el usuario no puede modificar su contenido, es conveniente que pueda seleccionarlo y copiarlo en el portapapeles.

Campo no disponible:

En él, como en el caso anterior, el usuario no puede introducir ni modificar su contenido. En la mayor parte de las plataformas estos campos se muestran gráficamente disminuidos, en color gris.

Por lo general, la etiqueta del campo también quedará en gris. Esto no se puede apreciar en el ejemplo puesto que la etiqueta es a su vez parte de un botón radial activo.

¿Qué diferencia un campo protegido de uno no disponible?

Un campo no disponible es aquel que no siendo editable puede llegar a serlo si en algún momento se da la circunstancia apropiada. Este cambio puede ser debido a la selección de alguna opción por parte del usuario o incluso a un cambio de la configuración del propio sistema ajeno al usuario.

En la imagen siguiente podemos ver como el campo del ejemplo anterior pasa a ser editable por el hecho de haberse seleccionado una opción de impresión diferente.