Probar la estética

La funcionalidad y la estética se interrelacionan, pero deben poder
desarrollarse y probarse en forma paralela.
(la imagen que muestra aspectos de estética y funcionalidad en un
vehículo eléctrico esta tomada de checkeredflag.com)

La semana pasada comentábamos que la frase de que todo lo que se construye cuando se realiza una solución de gestión de información debe probarse incluye no sólo lo meramente funcional y los aspectos más informáticos como la estructura de información y la seguridad, sino también características que tradicionalmente no se consideraban objetos de pruebas sistemáticas como la navegación y la estética. Dedicamos en esa oportunidad nuestro post a las pruebas de la navegación, por lo que hoy nos centraremos en la conversación sobre las pruebas de la estética.

Sobre el papel de la imagen y la estética ya hemos hablado en otras oportunidades (Ver por ejemplo: ¿Por qué considerar la estética?, Imagen y estética: la quinta dimensión en Arquitectura de Información, El diseño de la imagen y la estética y La imagen y la Estética deben ser paralelas).

Es para todos claro que la estética trasmite y representa la imagen institucional, pero su rol va más allá de la institucionalidad ya que según como se implemente puede hacer más usable o menos usable una aplicación. Por ejemplo, un encabezado institucional grande en la pantalla puede hacer la salida muy elegante y bonita, pero quizás quita demasiado espacio útil y obliga al usuario a desplazarse abajo y arriba para ver contenidos, enlaces o botones, dificultando con ello el uso. Todo esto aunque la funcionalidad esté correcta.

Al igual que ocurre con aspectos como la navegación, es importante que las personas que construyen la estética puedan moverse y hacer cambios con independencia de quienes implementan la funcionalidad. Esto hace el desarrollo de una solución de gestión de información más eficiente y versátil. También tiene impacto en el mantenimiento y las modificaciones que se pueden hacer más adelante para acoplar, por ejemplo, una aplicación a un cambio de imagen institucional o a una campaña circunstancial. Es muy diferente en esos casos el poder tener o no la confianza de que la tarea puede realizarse y probarse sin el concurso de los constructores de la funcionalidad, pero estando seguros de que lo que se hizo no trae implicaciones indeseadas.

Hay, por supuesto, una prueba final que debe hacerse presentado la estética a quienes deben aprobar la imagen institucional. Pero mientras se construye la aplicación hay elementos ligados a la estética que deben tomarse en cuenta: la separación de contenidos y estilos, por ejemplo.

La fase de construcción exige el respeto a la disciplina en los nombres que se dan a cada cosa. Los Arquitectos de información saben que durante la fase de diseño deben definir los campos, los objetos de información, sus códigos y sus nombres. También el uso de bases de datos requiere de una normalización de los nombres de tablas y campos. Así, los encargados profesionalmente de la estética deben saber que estilos de presentación de la información (en la práctica presente especificados en lenguaje CSS) deben ser normalizados para facilitar el trabajo de desarrollo de hoy, así como el de los cambios que vendrán mañana.

Poder atender sugerencias de cambios sin tener que temer a implicaciones que impactan la funcionalidad es una capacidad de las aplicaciones con una buena Arquitectura de información que, entre otras cosas, requiere que se tenga siempre a la mano la posibilidad de validar el funcionamiento correcto de todos los servicios después de un cambio de imagen y estética y no trabajar sólo con la presunción de inocencia de estos cambios.