viernes, 27 de abril de 2012

Diseño de sistemas usando las dimensiones de la Arquitectura de Información


Cuando se va a diseñar una obra civil que funcione y que
resalte,  los arquitectos deben tener herramientas y
estrategias. Cuando se diseñan servicios de información
también. En la imagen la Aqua Tower en Chicago, un edificio
que destaca en una ciudad llena de edificios (ref.)
Hemos estado explicando como el trabajo de Arquitectura de Información se realiza moviéndose entre dimensiones, aspectos cualitativos que se enfocan en propiedades muy diferentes de la información y los sistemas de información. Hablamos de cinco dimensiones en una aplicación diseñada con criterios de Arquitectura: 1) Estructura, 2) Funcionalidad, 3) Navegación, 4) Comunidades e 5) Imagen. Cada una de ellas es importante y aporta al resultado final, pero lo interesante realmente es su relativa independencia. Cuando eso se comprende bien, el diseño de sistemas de información se realiza mejor.

Lo interesante del manejo por dimensiones es, precisamente, que el diseñador puede concentrarse en una de ellas y eso le permite omitir los detalles de las otras, aún sabiendo que todas son necesarias y que inciden en el resultado final. Pero lo que ocurre es que la influencia de una dimensión en la solución que finalmente se logra suele resultar fácil de intuir y hasta de apreciar, pero la independencia relativa que caracteriza una dimensión es un tema menos intuitivo y más sutil.

Veámoslo con un ejemplo: Trabajamos con un objeto de información para realizar el manejo de referencias de Internet. Enlaces que le interesan al usuario involucrado en el tema que se está trabajando.

Cuando estamos definiendo la Estructura de información nos interesa pensar en cuáles son las variables o metadatos que debemos tener en cuenta para el manejo de éstas referencias, así como las relaciones estructurales de ellas con objetos. Por ejemplo, hay un texto o mensaje, hay un Url o dirección en la Web, hay quizá un tema que clasifica rápidamente de qué se trata, hay un comentario que eventualmente coloca el usuario que introduce la referencia. Podría haber una fecha si se considera que es importante colocar las referencias en un hilo temporal.

Pero cuando trabajamos en Funcionalidad lo que nos interesan son aspectos como, por ejemplo, cómo debemos cargar la data que se integra y articula en ese tipo de objeto de información. ¿Cómo debe ser la planilla para cargar una referencia de Internet, en el caso del ejemplo que planteamos arriba? Dentro de la Funcionalidad podemos definir también cómo queremos que se presenten en las salidas las referencias de Internet, las ayudas o explicaciones que debemos dar a los usuarios. En cambio podemos ignorar quiénes tendrán permiso para ejecutar estas tareas, ya que de eso nos ocuparemos en la dimensión de Comunidades y seguridad.

Cuando nos movemos en la dimensión de Funcionalidad lo que nos interesa de una planilla no es su imagen sino el orden en que se presentarán los campos de información, los botones que tendrá la planilla, pero no la definición de la estructura del objeto de información, la navegación que permite llegar y salir de la entrada de datos, los colores y demás componentes de la estética de la planilla. Tampoco es relevante la consideración de las personas que tendrán permiso para llenar la data o ver la información.

En la dimensión de Navegación nos concentramos en el examen de las situaciones en que exponemos las referencias al usuario, en qué sitio, con qué relevancia. Qué le permitimos hacer cuando le presentamos una lista de referencias. Qué opciones le damos cuando le presentamos una referencia: Permitimos que abandone el sitio, creamos otra ventana o usamos la misma. Todas esas son consideraciones de Navegación.

En el caso de la dimensión de Comunidades y seguridad nos ocupamos de quiénes tienen acceso a las referencias de Internet. Quiénes pueden agregar nuevas. Quiénes pueden editarlas.

En el caso de la Imagen y estética nos concentramos en los tipos de letra, colores, fondo y tamaños con los que presentamos estos enlaces. Como usamos la estética para resaltar la funcionalidad y para distinguir aspectos claves de la navegación. Los temas vinculados a la estética de las planillas para cargar la data de referencias, para presentarlas en listas o para colocar un enlace.

Como puede apreciarse, se requiere manejar los conceptos para aprender de las experiencias de diseño en las que nos involucramos. Si no los desarrollamos, podemos hacer muchos sitios, pero estaremos siempre en un punto de conocimiento muy cercano.

viernes, 20 de abril de 2012

Más detalles sobre patrones de salida

La "salida abreviada" con un título, un breve resumen o un
primer párrafo y una imagen de dimensiones pequeñas es
una salida típica en todo tipo de sistemas y tiene la ventaja de
adaptarse a múltiples tipos de objetos de información.
 Ejemplo tomado de http://redparacrecer.org

La semana pasada introducimos el concepto de “Patrones de salida” y explicamos como este concepto le permite a los Arquitectos de Información hacer distinciones que ayudan a especificar las salidas de los sistemas y la funcionalidad en el dominio de la información, con total independencia de especificaciones informáticas y de otro tipo de consideraciones como las estéticas, las de navegación, las de estructura de información, las de usuarios y seguridad, etc. También vinculamos el concepto de “Patrón de salida” con el de “Tipo de salida” sobre el que habíamos conversado unas semanas antes. En este post queremos añadir algunos elementos adicionales acerca de los patrones de salida, su especificación y su uso, que son importantes para terminar de entender el concepto.

Recordemos que un patrón de salida es, en principio, algo tan sencillo como una lista ordenada de campos de información que se usa para guiar lo que, como contenido, debe estar presente en un determinado tipo de salida en una determinada aplicación.

La semana pasada vimos que cada tipo de objeto de información tiene asociado un patrón de salida para cada tipo de salida. ¿Qué ocurre cuando en las salidas están presentes varios tipos de objetos de información? Esta es una situación que puede presentarse en muchos contextos. Así, cuando un usuario introduce una palabra, por ejemplo, basketball, en una tienda como Amazon, la respuesta puede venir con tipos de objetos de información diferentes: libros, juguetes, ropa, zapatos, etc. ¿Cómo se especifican estas salidas donde en la información recuperada hay distintos tipos de objetos de información? La respuesta es que en estos casos debe especificarse, además de los patrones de salida para cada tipo de objeto, un patrón general, que se usará cuando en la salida estén presentes múltiples tipos de objetos de información. Por esta razón al diseñar hay que tener presentes la lista de todos los distintos tipos de salidas del sistema en cuestión y para cada tipo de salida hay que especificar un patrón de información por cada tipo de objeto de información. Pero a éstos debe agregarse un patrón general para el caso en que no hay un único tipo de objeto de información presente.

Debe notarse que el orden de los campos en un patrón de salida es importante. No es lo mismo especificar Autor-Título que Título-Autor. En nuestra cultura leemos de izquierda a derecha y de arriba abajo y los dos patrones, aunque expliciten los mismos contenidos en la salida, pueden hacer que los usuarios se comporten en forma diferente ante la misma información. Por esta razón, un patrón de información es siempre una lista ordenada de campos.

Normalmente los campos de un patrón se activan sólo si existe un contenido para presentar. Así, si un registro de información recuperado no contiene fecha no se toma como un error, sino como un contenido que no puede ser presentado.

Finalmente, es importante resaltar que toda esta conversación ocurre en el dominio de la información. Que es allí donde están las especificaciones de las que hablamos tanto hoy como la semana pasada y que, por tanto, los patrones de salida son independientes de las consideraciones de estética, de navegación y de seguridad que se resuelven en otras dimensiones, completamente distintas de la funcionalidad (Ver Las 5 dimensiones de la Arquitectura de información).

No debe confundirse el concepto de patrón de salida con el concepto de formato de salida. El patrón es un tema de contenido, el formato es sólo de forma. Tampoco debe confundirse el patrón de salida con el concepto de estilo en la salida. Este último sólo afecta la estética.

Cómo vemos, la Arquitectura de Información es un área con gran cantidad de detalles de interés para las personas con esta vocación. Los buenos Arquitectos de la construcción civil diseñan edificaciones cómodas y bonitas y disfrutan con ello. Los buenos Arquitectos de información diseñan buenos espacios digitales, prácticos, eficientes y simpáticos, y como, sus amigos de la construcción civil, también disfrutan haciéndolo!

viernes, 13 de abril de 2012

Patrones de información de salida

En las respuesta a consultas que se realizan en Amazon puede apreciarse
que típicamente los resultados se presentan en un tipo de salida abreviada
con un patrón de salida adecuado para mostrar lo más relevante en un
 relativo poco espacio.
En oportunidades anteriores presentamos el concepto de “tipo de salida”. Vimos las ventajas que este concepto trae a Arquitectos y Gerentes de información y explicamos como el arquitecto realiza el diseño de tipos de salida. Es interesante notar que todo esto se hace en el dominio de la información, independiente del tipo de aplicación, del tipo de sistema, del tipo de solución. Como hemos señalado, cuando un Arquitecto de información o un Gerente de información se apropia de estos conceptos, la vida se le simplifica al especificar qué es lo que se desea que un sistema presente en un momento dado. Puede diseñar mejor. Puede explicarse mejor. Puede entenderse con los informáticos mejor. Pero en el diseño funcional de una salida, lo único que hay que especificar no es el tipo de salida. También debe detallarse el patrón de información de salida o simplemente patrón de salida. Este es un concepto complementario y el tema del post de hoy.

En general un patrón de información es una lista ordenada de campos de información (variables o metadatos) que se usa con algún fin específico. En particular un patrón de información que se usa cuando se va presentar una salida dada se llama patrón (de información) de salida. También puede hablarse de un patrón (de información) de entrada, cuando el patrón de información se usa para definir una entrada de datos.

Como un ejemplo, Titulo, Autor(es), Editorial, Ciudad y Fecha puede ser una lista de campos de un patrón de salida resumida de un libro. Es decir, la secuencia de metadatos que se escriben cada vez que, en forma resumida, se menciona un libro en la salida. Otro ejemplo: Título, Institución, Fecha, Hora, Ciudad y País puede ser la lista de campos del patrón de salida resumida de un evento.

Como las salidas son de diverso tipo, en la Arquitectura de Información de un sistema debe especificarse en forma explícita la lista de campos o patrón de ese tipo de salida. Así, habrá un patrón de salida para la salida detallada, un patrón de salida para la salida resumida, un patrón de salida para la salida abreviada (Para recordar la definición de estos tipos de salida puede verse: En los tipos de salida todos los sistemas se parecen).

Como cada tipo de objeto de información tiene propiedades específicas, cada tipo de objeto de información requiere de un conjunto de patrones de información para cada una de las salidas que permite. Por ejemplo, el tipo de objeto de información “Persona” tendrá un patrón de salida resumida, un patrón de salida para la salida detallada, un patrón de salida para la salida abreviada. Mientras que el tipo de objeto "Institución" tendrá sus patrones específicos y estos a su vez serán diferentes de los patrones de salida del tipo de objeto “Noticias”.

Como cada aplicación es particular, con cada aplicación debe revisarse la lista de patrones asociados a cada tipo de objeto de información, para que los campos estén adecuados al contexto (para recoprdar el concepto de Objeto de información puede verse Estructuras de información. Qué son y para qué se usan y La lista de objetos de información y el Arquitecto de Información). Es decir, el hecho de que el mismo tipo de objeto de información esté en dos aplicaciones diferentes no implica que se usará en ambas los mismos patrones de información, aunque las dos tengan los mismos tipos de salida.

Por ejemplo, el tipo de objeto "Eventos" tendrá un conjunto de patrones de salida en una aplicación de una institución que sólo tiene una sede, y un conjunto diferente en el sistema de información de una red donde los eventos se suceden en múltiples localidades. En el primer caso el campo "Ciudad" puede no estar presente en un determinado patrón, ya que no tiene sentido especificar que cada evento se realizará en la única ciudad posible para esa institución. Por esta misma razón,  incluso un patrón completo, la salida cartográfica, podría no existir. Mientras que en el segundo caso, el campo Ciudad es relevante y la salida cartográfica puede ser de interés si los eventos de la red suceden, en efecto, en distintas ciudades.

En el próximo post volveremos con más detalles sobre el uso de patrones de salidas por arquitectos de información.

viernes, 6 de abril de 2012

Diseño de tipos de salidas

Las salidas de tipo plano cartográfico son muy frecuentes actualmente y muy
útiles cuando se quiere relacionar contenidos con información geográfica.
Por ejemplo, la imagen muestra las ciudades desde donde se subieron fotografías
en una actividad internacional de http://www.RedParaCrecer.org
Recientemente hemos estado explicando el concepto de “Tipos de salida”. Hemos visto que a pesar de las enormes diferencias entre un sistema y otro, entre una aplicación y otra, entre un problema de gestión y otro, entre una solución y otra, las salidas de los diversos sistemas pueden catalogarse en tipos, en unos pocos tipos. Cuando un Arquitecto de información o un Gerente de información se apropia de este concepto, la vida se le simplifica al especificar qué es lo que se desea que un sistema presente en un momento dado. Puede diseñar mejor. Puede explicarse mejor. Puede entenderse con los informáticos mejor. Veamos el método con algo más de detalles.

El método del Arquitecto es algo como lo que sigue: Se identifica rápidamente de qué salida se está hablando, de una salida con un único tipo de registros o de una salida con múltiples tipos. La respuesta a esta pregunta simple permite asumir premisas que suelen tener implicaciones (Ver Tipos de salidas y tipos de registros).

Luego hay que saber qué tipo de salida (resumida, abreviada o de detalles) por la cantidad de información que se presenta de cada registro se usará en las respuestas (Ver En los tipos de salidas todos los sistemas se parecen). Muy especialmente debe decidirse qué tipo de salida de detalles (con metadatos explícitos o con metadatos implícitos se usará para presentar la información de un registro). Finalmente, también interesa especificar qué tipo de salida de múltiples registros (lista de registros resumidos, listas de registros en detalle, listas de registros abreviados, tablas, representación cartográfica, galerías o mosaicos, calendarios, gráficos, etc.) es natural cuando se presenten varios registros (Ver Salidas de múltiples registros).

Eventualmente pueden prepararse varios tipos de salidas de acuerdo a ciertos criterios de navegación con ciertos tipos de objetos de información. Es decir, se diseñan las salidas según el tipo de registro o tipo de objeto de información.

Por ejemplo, si se trata de información de eventos, un diseño posible es el siguiente: Como cada evento tiene una imagen de presentación, la salida de múltiples registros de eventos por defecto es la salida de tipo galería o de mosaico. Sin embargo, como los eventos tienen siempre una fecha asociada, se le deja al usuario la posibilidad de navegar a través de múltiples eventos en una salida de calendario y como los usuarios pueden requerir una lista de los últimos eventos registrados o de los próximos por realizarse, se proporciona también la posibilidad de una salida abreviada con una información suficiente para que el usuario tome la decisión de qué eventos despiertan su interés y sobre los cuales quiere obtener más información. Si los eventos están asociados a ciudades o regiones geográficas, es probable que resulte conveniente especificar en la funcionalidad una salida múltiple de tipo cartográfica como una opción. Por otra parte puede que no se requieran metadatos explícitos en las salidas de detalles.

Una combinación dinámica se diseña para cada solución. En el ejemplo, hablamos de eventos, pero las mismas consideraciones podrían hacerse por ejemplo para libros o para videos. Sin embargo, pueden notarse ejemplos de las diferencias. En el caso de los libros, es típico que se esté interesado en metadatos explícitos en las salidas detalladas, es decir, que se identifique claramente, sin equívocos, cuál es el título, cuál el autor o los autores, cuál es la editorial y la fecha de publicación, etc. Una suerte de ficha técnica como es la práctica usual para el trabajo con libros.

En el caso de los videos es típico que la salida de detalles incluya en primera instancia la ventana donde puede verse el video.

Cada tipo de objeto de información y cada aplicación tiene su especificidad, pero al Gerente de información y al Arquitecto, el aprender a manejar las taxonomías como las que hemos estado mencionando le resuelve y/o simplifica tareas de diseño o interacción con su equipo de desarrollo.