Evitar que se introduzca información incorrecta en un sistema es uno de los requisitos exigidos a la informática desde sus inicios y se ha convertido en una de las funciones mejor implementada por la sencilla razón de que la fiabilidad de un sistema informático depende de la información que contiene. Por ello, la validación constituye una función imprescindible en cualquier aplicación informática.

Lamentablemente, a menudo, la extrema importancia que lógicamente se otorga a impedir que el sistema se alimente con datos incorrectos acaba deteriorando la usabilidad del sistema ya que los programadores se centran sólo en controlar en lugar de guiar. En este artículo se analizan las características de los procesos de validación de datos de entrada y se proporcionan algunos consejos para mejorar la usabilidad del sistema.

Tipos de validaciones

Las verificaciones a aplicar sobre la información a introducir en un sistema pueden analizarse aplicando diferentes puntos de vista.

A. Según el momento en el que se realicen

Una misma validación, como comprobar que el valor introducido en un campo de fecha es correcto, puede llevarse a cabo en dos momentos distintos:

1. justo al acabar de informar el campo con lo cual estaremos ante una validación a nivel de campo, o bien
2. al solicitar que se introduzca toda la información del formulario de entrada, es decir, al darle al “OK”, con lo cual estaremos ante una validación a nivel de formulario.

Elegir entre estos dos momentos para efectuar una validación concreta entabla un debate entre dos puntos de vista antagónicos: por un lado, el que defiende que el sistema debe controlar al usuario, y por el otro, el que opina que es el usuario quien debe tener el control sobre el sistema. Bruce Tognazzini considera esta segunda perspectiva como una característica necesaria para lograr una interfaz de usuario efectiva. Por este motivo, se recomienda que, como norma general, las validaciones se apliquen a nivel de formulario ya que ello permite que el usuario “navegue” libremente por los campos del formulario sin que el sistema le interrumpa constantemente mostrándole mensajes de error por no superar una validación a nivel de campo. Seguir esta recomendación permitirá conocer, entre otras informaciones, el contenido de los valores de las combo-boxes y favorecerá que el usuario se forme un mejor modelo mental de la aplicación.

Además, conviene indicar que, si bien el contenido de un campo puede verificarse tanto a nivel de campo como a nivel de formulario, determinados tipos de validaciones sólo pueden efectuarse a nivel de formulario. Entre otras, aquellas que comprueban:

• información que no se encuentra explícitamente en ningún campo del formulario, como, por ejemplo, el nivel de autorización del usuario que está precisamente introduciendo datos en el formulario;
• estados que sólo se producen al dar “OK” al formulario de entrada, como, por ejemplo, verificar, en un proceso de búsqueda, que el usuario ha informado un número mínimo de filtros a aplicar.

B. Según el objeto sobre el que se apliquen

Atendiendo al objeto a verificar, una validación puede ser:

• Simple: cuando analiza el contenido de un solo campo, o bien
• Compuesta: cuando analiza el contenido de un campo en relación al contenido de otro u otros campos ya informados en el formulario.

En el caso de validaciones compuestas resulta todavía más recomendable, si cabe, realizarlas a nivel de formulario para permitir que el usuario esté al tanto de las diversas combinaciones de valores disponibles antes de darle al “OK”. Para ello, la habilitación/deshabilitación dinámica de campos y controles resulta de gran ayuda.

C. Según el tipo de característica que validen

Cualquiera de las informaciones que gestiona todo sistema se inscribe en una de estas dos categorías:

1. Aquello que forma parte del conocimiento del usuario, bien sea porque pertenece al mundo real, como, por ejemplo, que las personas se clasifican en mujeres y hombres; bien sea porque se encuentra en su cabeza, como, por ejemplo, que una persona se identifica por su nombre y apellidos.
2. Aquello que el usuario desconoce. Y que, a menudo, forma parte de la particular lógica de la aplicación, como, por ejemplo, que las fechas deben informarse con 4 dígitos para el año o que para dar de alta un nuevo cliente el usuario debe poseer un nivel de autorización superior a X.

Aunque es cierto que, a medida que el usuario va interaccionando con el sistema, su modelo mental del mismo será mas completo y, en consecuencia, determinados componentes de la lógica de la aplicación pasarán a formar parte del conocimiento del usuario; resulta evidente que el tipo de conocimiento al que pertenezca la característica a validar afectará directamente a la facilidad de comprensión del usuario. No es lo mismo comprobar que en un campo de importe se introducen sólo números, que validar que en un servicio de reserva de entradas a espectáculos no se soliciten más de 6 entradas o que la compra se realice con una antelación mínima de 3 días sobre la fecha celebración. En este caso, resulta imprescindible un tratamiento excelente de los mensajes del sistema tanto en su redacción como en escoger el tipo de mensaje adecuado para que el usuario llegue a conocer las peculiaridades del sistema que está usando y logre su objetivo.

Validaciones sobre el formato de un dato

Son las típicas comprobaciones sobre la conformación y el tamaño del valor introducido en un campo, como, por ejemplo, que sólo sean números o mayúsculas, o que una fecha siga el patrón “DD-MM-AA”. Manteniendo la preferencia por las validaciones a nivel de formulario, en estos casos, resulta un poco más aceptable aplicar una validación a nivel de campo. A pesar de ello; la mejor solución consiste en que sea el propio sistema quien, proactivamente y de forma automática, realice las acciones necesarias para dejar el valor en el formato correcto, como, por ejemplo, introduciéndolo en mayúsculas aunque el usuario esté tecleando minúsculas o formateando los separadores de las fechas con el carácter previsto por el sistema al abandonar el campo correspondiente.

Orden de las validaciones

Otro factor que afecta a la usabilidad es el orden con que se aplican las validaciones a nivel de formulario. Por ejemplo, resulta muy molesto que:

• al darle al “OK” a un formulario la primera validación genere un mensaje de error indicando que el campo A es obligatorio y que no se ha informado;
• que el usuario informe el campo A y al darle otra vez al “OK” el sistema le indique que el valor con que se ha informado el campo A no es correcto;
• que el usuario modifique el contenido del campo A y al darle otra vez al “OK” el sistema le informe, justo ahora, que no posee el nivel de autorización necesario para emplear este formulario de entrada.

La sensación de frustración y de pérdida de tiempo que provoca en el usuario es del todo innecesaria y puede resolverse muy fácilmente si las validaciones se ejecutan siguiendo un orden lógico como, por ejemplo el siguiente:

1. Confirmar que la aplicación está disponible ya que si no está operativa no tiene sentido comprobar ningún dato del formulario de entrada.
2. Verificar que el usuario está autorizado utilizar el formulario de entrada.
3. Comprobar, uno a uno, que están informados todos los campos obligatorios. Estas validaciones se realizarán considerando, para cada campo, las verificaciones A y B que se detallan a continuación:
   1. Si el formulario de entrada sirve para crear una nueva ocurrencia de un objeto, asegurar que esta ocurrencia efectivamente no existe en la base de datos. Si, por el contrario, el formulario de entrada sirve para consultar, modificar o eliminar una ocurrencia; confirmar que ésta sí existe en la base de datos. Esta validación hay que ejecutarla inmediatamente después de haberse superado el paso número 2 sobre el campo que contiene el valor de la ocurrencia.
   2. Ejecutar las validaciones compuestas, aquellas que analizan el contenido de un campo en relación al contenido de otro u otros campos ya informados en el formulario.
4. Validar el resto de campos

Además, en el orden de ejecución de las validaciones hay que seguir la secuencia de izquierda a derecha y de arriba abajo respetando las agrupaciones de campos que tenga el formulario. Es decir, seguir el mismo orden que se aplique al desplazamiento del foco de teclado entre campos que explica Josep Casanovas en su artículo “Diseño de formularios - Campos (II).

Implementar las menos validaciones posibles

Nadie discute la necesidad de controlar el contenido de un formulario de entrada, pero un diseño inteligente puede reducir mucho el número de validaciones a aplicar y esto, además de favorecer la usabilidad porque el usuario va a padecer menos interrupciones, también puede favorecer un menor coste de desarrollo, pruebas y mantenimiento.

A continuación se indican varios recursos, algunos de los cuales ya menciona Josep Casanovas en su artículo, para reducir el número de validaciones a realizar:

• Usar campos con listas de valores asociadas o combo-boxes que facilitan que el usuario informe el campo con un valor correcto.
• Informar los campos con un valor por defecto. Éste debe ser el más probable. En caso que no convenga informar con un valor por defecto, indicar dentro del propio campo las características de los valores correctos.
• Añadir un pequeño texto explicando el formato y/o rango de valores correcto.
• Habilitar/deshabilitar dinámicamente campos y/o botones según el estado del formulario, el perfil del usuario o cualquier otra circunstancia.
• Convertir automáticamente el contenido de un campo al formato correcto.
• Añadir acciones específicas para asignar valor a un campo, como, por ejemplo, añadir un calendario para introducir una fecha.

Aunque es totalmente imprescindible comprobar la información a introducir en un sistema, cuando las validaciones se aplican con un orden lógico y se reducen al máximo, el usuario las percibirá como una ayuda en lugar de cómo un obstáculo, mejorando la usabilidad del sistema.