Formularios web
A la hora de plantear un formulario para solicitar información a un usuario hay que considerar más cosas de las que a primera vista pueden observarse. Hay que ver si hay campos que condicionan la aparición o validez de otros campos y como plantearlo (p.ej. se pedirá la provincia sólo si el pais es “España”), como representar ciertos campos que pueden dar un cierto juego (p.ej. un campo de fecha, o campos con valores conocidos), como plantear los errores, los ejemplos de formato, el orden, las agrupaciones, validaciones de los campos, etc…
Vamos, que en teoría exigiría al menos una pensada, cosa que no siempre ocurre.
Aquí me voy a centrar únicamente en como pondría las etiquetas, los botones y las marcas de “campo obligatorio” en un formulario.
Campos obligatorios
Hace tiempo que el asterisco (*) se usa de forma convencional para indicar una nota al pie y, en caso de formularios, un campo obligatorio. Generalmente se suele poner al principio del formulario junto con una frase del estilo Los campos marcados con * indican campos obligatorios
. Muchas veces el * se enfatiza usando un color de advertencia rojo, naranja o similar.
En los campos, el asterisco se colocaría al final de la etiqueta, i.e.
Nombre*:
Con este asterisco, creo que es máss que suficiente para indicar la obligatoriedad del campo.
Disposición de las etiquetas
Generalmente un formulario se suele disponer dentro de una tabla, aunque no es obligatorio y ni siquiera hay acuerdo de que sea semanticamente correcto, sin embargo es una disposición habitual.
Lo que no es tan habitual es usar la etiqueta LABEL para asociar la etiqueta con el campo asociado.
Una de las ventajas de LABEL es que facilita el posicionamiento del foco en el campo que vamos a rellenar.
Y una desventaja de LABEL es que no se puede utilizar dentro de tablas si el control asociado está en otra celda, que es el caso que estamos considerando.
Note that this technique cannot be used when a table is being used for layout, with the label in one cell and its associated control in another cell.
Por lo tanto úsala si es posible y no te complica demasiado la vida y el código.
Como decía, si disponemos el formulario dentro de una tabla, tenemos la columna izquierda para las etiquetas y la columna derecha para los campos de entrada y las ayudas (formatos, indicaciones breves, etc.).
A mi me gusta alinear las etiquetas a la derecha de la columna, lo más próximos posible a los campos de entrada del formulario. Con ello mantenemos la relación visual entre los dos y evitamos que etiquetas demasiado largas hagan que el usuario pierda la referencia entre la etiqueta y su campo de entrada correspondiente.
Por ejemplo:
| Datos personales | |
|---|---|
| Nombre*: | |
| Apellidos*: | |
| N.I.F.*: | DDDDDDDD-L (p.ej. 12345678-Z) |
| Dirección: | |
| Otros datos de interés | |
| Comentarios: | |
Es un formulario bastante feo, pero creo que se entiende el concepto.
Resumiendo…
- Etiquetas: Alineadas a la derecha, pegadas al campo correspondiente. Con asterisco indicando si el campo es obligatorio.
- Campos: Su tamaño debe indicar cuanta información esperamos que introduzca el usuario. Estarán alineados a la izquierda, junto a su campo asociado.
- Ayudas: Las indicaciones sobre formatos, ejemplos, etc. las colocamos a la derecha del
input. - Botones: Alineados a la izquierda en la columna de los
inputs. Evita problemas a la hora de asociar los botones de acción con el formulario correspondiente. También puede ayudar el rodear el formulario con un borde, aunque dependerá del diseño.
Y si se puede, utiliza etiquetas LABEL.
Puf, si la entrada me ha quedado larga, su génesis ha sido eterna, a si que creo que la cierro aquí.
Actualización 2006.07.04. Justo acabo de ver un artículo en A list apart en el que se menciona como adecentar un formulario sin usar tablas: Prettier Accessible Forms. Eso si, a cambio de un poco de Javascript.
Actualización 2006.07.26. Acabo de probar a poner LABEL en los campos de los comentarios y funcionan tal y como debiera… incluso estando en tabla.
- En diseño, usabilidad
- Tags: usabilidad,
0 comentarios