Alzado.org

Diseño de formularios – Campos (II)

Señalizar los campos obligatorios: un lío

Lo cierto es que en esta cuestión nadie se ha puesto todavía de acuerdo. Incluso he llegado a leer en guías de estilo, como la de Windows, que es conveniente marcar los campos obligatorios, pero no da ninguna indicación de cómo hacerlo.

Lo cierto es que el usuario agradece mucho que se le indiquen los campos obligatorios. La solución que se ha adoptado mayoritariamente, y que podemos considerar que la mayor parte de usuarios entienden, consiste en el típico asterisco al lado de la etiqueta o del campo.

De todas maneras, existen otros muchos sistemas que pueden ser incluso más validos que el anterior en función del contexto de implantación del formulario.

Señalización de campos erróneos: otro lío

Cuando en tiempo de validación debamos indicar al usuario que ha introducido un valor erróneo, es importante que vea claramente cuál es el campo que contiene el error. Por ello lo mostraremos con un grafismo diferenciado y fácilmente localizable pero, como en el caso anterior, tampoco hay nada normalizado al respecto.

Un sistema que me gusta particularmente consiste en utilizar el color rojo para la etiqueta y para enmarcar el campo en cuestión.

¿Qué es el foco de teclado?

Diremos que un elemento de un formulario recibe el foco de teclado cuando sobre él recaiga la acción que el usuario vaya a hacer con dicho teclado. Por tanto se trata de un atributo temporal asociado a un único elemento en un momento dado. El foco de teclado puede recibirlo cualquier elemento con el que el usuario pueda realizar alguna interacción.

Cuando mostramos visualmente el foco de teclado, incrementamos considerablemente la facilidad de uso y la rapidez de interacción puesto que estamos indicando al usuario en qué lugar de la página o formulario está trabajando.

La señalización visual del foco de teclado es diferente según el tipo de elemento que lo recibe: campos, botones de acción o radiales, cuadros de selección, pestañas, enlaces, etc. Veamos algún ejemplo:

Desplazamiento del foco de teclado entre campos:

Como puede observarse en el ejemplo anterior, un campo con foco de teclado se indica visualmente ubicando el cursor parpadeante dentro de él. Sin embargo, cuando el campo contenga algún valor éste se mostrará completamente seleccionado.

A continuación, algunas recomendaciones sobre la ubicación i el desplazamiento del foco de teclado:

Cuándo debe hacerse un salto automático:

Ésta es otra de las cuestiones que a menudo genera dudas al diseñador de interacción y al programador. Cuando un usuario rellena hasta el último carácter de un campo editable ¿debe provocarse un salto automático del foco hacia el siguiente elemento? o por el contrario ¿debe quedarse el cursor frenado a la espera de que sea el mismo usuario quien provoque el salto?

Pues bien, la respuesta es: depende. Algunos de los siguientes criterios nos pueden ser de ayuda:

Validación del contenido:

Uno de los principios de usabilidad más ampliamente admitidos es el de "guiar en lugar de controlar", es decir, el usuario debe sentirse en todo momento guiado por la interfaz en contra de sentirse controlado. Sin embargo es evidente que los datos introducidos por el usuario en un formulario deben ser validados por el sistema, lo que introduce inevitablemente un cierto control.

El principio de "guiar y no controlar", como cualquier otro, debe ser entendido en su significado y aplicado en función de cada contexto evitando interpretaciones superficiales que se queden simplemente en la letra de dicho principio. Sobre este tema recomiendo leer el artículo de Josep M. Junoy: El principio de Visibilidad y el de Guiar y no Controlar ¿Son incompatibles?

Algunos consejos en esta línea:

Salir de la versión móvil