Características de un buen formulario web

En este artículo o documento de trabajo voy a hablar de dos cosas: por un lado las características de debería tener el formulario web ideal (luego entraremos en las implicaciones del término) y por otro las diferentes problemáticas con que nos vamos a enfrentar a la hora de construirlo.

En definitiva… vamos a hablar ¡del superformulario!

Requisitos iniciales

Veamos una lista de requisitos un formulario web considerado ideal:

• Presentación. Debe tener un códio html limpio de forma que se pueda maquetar y estilizar desde CSS
• Validación: Completa validación en servidor. Más completa validación en cliente, pero en este caso no obstructiva (si funciona bien, siempre nos quedará la validación en servidor)
• Datos: código en servidor que actualice los campos al cargar la página y código asíncrono que ayude en la interacción con el usuario sin recargar página.

Presentación

• El código html debe ser mínimo y limpio. Nos valdremos de clases CSS para luego poder estructurarlo y estilizarlo fácilmente.
• Las hojas CSS estarán con código compacto y bien comentadas (sino es difícil mantener el código)
• Los estilos que conformen la presentación del formulario se dividirán como mínimo de dos hojas de estilos: una que establezca la estructura y localización (que se vean bien alineados y estructurados) y otra que se ocupe de los efectos de color y más personales (colores de letras, fondos, tipografía, etc.)
• Todos los tipos de campos (campos de edición de texto, checkbox -y grupos de-, botones radio -y grupos de-, controles texarea, etc. deben de estar correctamente alineados y colocados.

Carga de datos

Previa

Carga de datos inicial. Esto es necesario sobre todo en el caso de estar editando un registro (si estamos creando un registro nuevo los campos estarán vacíos). Aunque en ambos casos lo más probable es que igualmente haga falta carga de datos, pues lo más seguro que habrá valores predefinidos que deban cargarse previamente (y que provengan de la base de datos). El caso más común son listas que se alimentan de valores almacenados en la base de datos.

Interactiva

Mientras el usuario va interaccionando con el formulario. Esto se refiere a que normalmente hacen falta rellenar valores en campos dependiendo de otros valores que ya se han introducido. Lo mejor es hacerla con AJAX (javascript deberá estar disponible!). Un caso muy común es cuando se tienen varias listas relacionadas en cascada (los valores de la siguiente dependen del valor seleccionado en la anterior)

Validación

En cliente

En cliente es dónde se puede interactuar más con el usuario y dónde más podemos facilitar y al mismo tiempo restringirle la introducción de los valores.

Por otro lado y sin discutir que nunca ha de dejar de validarse en servidor (siempre ha de haber alternativa ya que en el cliente varían más las condiciones -pe. javascript puede estar desactivado-) realmente hoy en día es poco usual que se de el principal inconveniente: que javascript esté deshabilitado ya que normalmente sí lo está.

• Validaciones simples: cadenas de texto, números, DNI, correo electrónico, fechas
  Las validaciones simples solo implican a UN campo al mismo tiempo y es fácil validarlas en cliente o servidor mediante expresiones regulares
• Validación de un rango de fechas
  Una validación como ésta ya implica dos o más campos y habrá que aplicar funciones específicas que combinen la validación simple.