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:

• Lugar de inicio: En el momento de mostrar el formulario, se situará el foco del teclado en el primer campo editable, aunque le precedan elementos que admitan interacciones: botones, pestañas, enlaces, etc.
• Movimiento general: El movimiento del foco debe seguir el orden de lectura (de izquierda a derecha y de abajo arriba en occidente).
• Movimiento dentro de agrupaciones: Cuando en el formulario se hayan agrupado elementos, el movimiento del foco se hará dentro de ellos para luego saltar al primer elemento de la siguiente agrupación.

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:

• El comportamiento más generalizado es el de frenar el cursor al final del campo e impedir el salto automático. Por lo tanto, seremos consistentes con ello si es que no existe alguna razón que lo desaconseje.
• En entornos en los que la introducción de datos sea una tarea intensiva se preferirá el salto automático. Hemos de suponer que en estos casos el usuario adquiere experiencia en poco tiempo, con lo que el salto automático entre campos incrementará su rapidez de introducción de datos.
• En campos compuestos, es decir, aquellos en los que para expresar un valor se utilicen varios campos, por ejemplo: fechas, números de cuentas bancarias u otros; los saltos entre ellos serán automáticos.

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:

• Dejar que el usuario se mueva libremente por el formulario y no avasallarlo con continuos mensajes de error fruto de validaciones anticipadas de campos. Esto incluye no validar ningún campo en el que el usuario no haya introducido ningún valor hasta el momento en el que el usuario haya realizado la acción de aceptar o enviar.
• Guiar al usuario poniendo en los campos editables aquellos valores por defecto que nos sea posible.
• Cuando un campo sólo admita valores numéricos, impedir en tiempo de tecleo la introducción de otros caracteres.
• Los campos que contengan valores cuyas validaciones se puedan deducir de su propio tipo, por ejemplo las fechas, se validarán en el momento de pérdida del foco de teclado, nunca en el momento del tecleo.
• Utilizar campos no disponibles para guiar al usuario. Estos campos impiden entrar información innecesaria pero indican al usuario la posibilidad de hacerlo en caso que cambie algún otro parámetro (al respecto, consultar el artículo de Josep M. Junoy citado anteriormente).
• Realizar la validación de los campos una vez el usuario haya realizado la acción de aceptar o enviar. Si es posible, ofrecer al mismo tiempo todos los errores detectados, en lugar de sólo uno.