¿Cómo mejoro y consulto mi apariencia?

enero 19, 2011
By

Datos visuales, un tema controversial, aún con soluciones empíricas y artesanales, desdeñado por unos y requerido por casi todos.

El concepto

¿Qué entender por dato visual? El término nos trae a la mente fotos que asociamos a entidades, imágenes de banderas que representan culturas, algún video asociado quizás a información de una película, etc. De acuerdo, estos son datos visuales, dicho así todos los datos que mostremos en pantalla pueden considerarse datos visuales, incluso el propio texto, pero también se consideran como tal a toda la información adicional que ayude a visualizar tales datos texto, como por ejemplo un formato para una fecha, una unidad monetaria, algún tipo de simbología como usar los * para camuflar una contraseña.

La rutina

Hasta ahora hemos asumido como regla general que los datos reales, concretos, es decir  aquellos que nos interesan desde el punto de vista de la lógica del negocio, los almacenamos en una base de datos. Los datos visuales (también denominados como cosméticos, de adorno o más despectivamente: la pacotilla) pueden ir separados de los reales, o peor embebidos dentro del código que constituye la capa de presentación.

En los últimos tiempos se ha puesto de moda (y no por gusto) emplear el patrón MVC para separar todo lo que incumbe a la capa de presentación e interacción con el usuario de las  capas subyacentes que se ocupan entre otras tareas, de manejar los tales datos reales según la lógica del negocio (bussiness logic), de la comunicación, etc. ASP.NET MVC, Silverlight y WPF son tres buenos productos para aproximarnos  al ideal MVC.

¿Pero qué pasa cuando se pretende que la propia capa de presentación sea más dinámica, es decir que pueda ser administrable e incluso personalizable? O también, cómo combinar las partes de una presentación en sistemas que se componen dinámicamente como los pluggins y que pueden tener apariencias no conciliadas de antemano? En casos como estos el problema principal es que el resultado visual o bien es muy limitado o es simplemente feo, porque muchas de las opciones de visualización si son dinámicas no pueden estar rígidamente incrustadas en el código de la presentación, o son muy complejos de representar en una base de datos convencional.

Pongamos algún ejemplo que ilustre un tal escenario.

Símbolos y Leyendas

¿Cómo visualizaría usted el género de las películas que se estén mostrando en cines de  una zona de la ciudad? Usando algunos controles de la biblioteca estándar y los que pueda encontrar en algún paquete comercial una posible visualización sin mucha pericia en diseño pudiera ser:

Sin embargo, se podría tener una visualización diferente:

Acá se han representado los géneros Ciencia ficción y Terror con símbolos que sugieren el género o recuerdan filmes representativos:

Este es un caso en que se usan recursos gráficos que agrupan los datos de forma que el usuario pueda detectar mejor tales grupos. Los recursos comunes en leyendas, tanto para mapas como para charts son los símbolos, colores y figuras.

Los conocedores de ASP.NET MVC, Silverlight o WPF fácilmente se podrán percatar que para ello pueden usar las plantillas de datos (DataTemplate en WPF) y los selectores de plantillas (DataTemplateSelector). Estos se ocupan de indicar en cada caso de qué modo se visualizan los datos.

El dilema es a la hora de decidir dónde se almacenan y cómo se organizan datos como estos símbolos. Las variantes más comunes pueden ser:

  1. El símbolo está incluido dentro del propio código que muestra la parte visual. En WPF y Silverlight  puede estar declarativamente “dibujado” en XAML.
  2. El símbolo es una imagen en disco que está referenciada desde un campo de una tabla en una BD que indica la dirección de la imagen.
  3. La propia imagen está almacenada en la BD en forma de un campo binario (BLOB).

Los desarrolladores no se han puesto de acuerdo sobre cuál de estas es la forma más recomendable de almacenar esta información. Lo cierto es que hay una diferencia clara entre la primera opción y las otras dos, lo que  nos puede ayudar a tomar una decisión según qué es lo que más nos importe desde el punto de vista visual: Si tomar recursos visuales como las imágenes y almacenarlos como datos externos, o construirlos por código[1].

La primera de las variantes es muy estática, si el recurso visual está formando parte  del código (aun cuando sea declarativo como XAML) luego de compilado se hace engorroso y en ocasiones imposible hacer cambios o enriquecer estos recursos. Suponga para el ejemplo cinéfilo anterior que luego de desplegado y distribuido el software se desee agregar un nuevo género de cine con su correspondiente simbología.

Sin embargo, con las otras dos variantes que almacenan los datos visuales en algún repositorio externo las posibilidades de transformar luego tales datos están limitadas, pues no ofrecen facilidades para  trabajar la imagen y así brindar más datos visuales.  Ejemplo, suponga que además de mostrar el género del film que se exhibe se quiere mostrar, usando una escala de colores, la disponibilidad de lunetas

Datos Interactivos

El dilema puede complicarse cuando estos datos se tornan interactivos y comienzan a formar parte de la funcionalidad del propio software, por ejemplo si las entradas se venden por la web y por tanto la capacidad de lunetas disponibles va variando.

Consideremos también el ejemplo siguiente:

Supóngase una aplicación que admite cambiar interactivamente la cultura y que dicha aplicación esté diseñada para ejecutar en un entorno puramente Touch-screen, es decir sin mouse ni teclado, pero que la aplicación puede requerir la entrada de algún texto. Como el dispositivo no tiene teclado hay que ofrecer un teclado Touch-screen pero queremos que este teclado cambie la distribución de sus teclas según sea la cultura seleccionada por el usuario:

Teclado en inglés:

Teclado en español:

Estamos en este caso ante un ejemplo de un dato visual que además es sensible a cultura. Si esto estuviera implementado con la variante 1 usando WPF o Silverlight el valor a cambiar sería nada más y nada menos que la plantilla (ControlTemplate) de un tal control ScreenKeyboard.

Conclusiones

En resumen no existe consenso aún sobre cómo manejar y organizar los datos visuales. Sobre todo, en tiempos en que el desarrollo en las plataformas visuales es tan dinámico que cada avance nos remueve la alfombra que algunos se han atrevido a tejer. Esperamos vuestros comentarios a partir de vuestras propias experiencias e ideas.


[1] Es una disyuntiva parecida a la que enfrentamos al definir algunas propiedades en las que tenemos que decidir entre calcular el dato devuelto por la parte get o si tener el dato almacenado en una variable de instancia.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*