viernes, 30 de marzo de 2012

Tipos de salida y tipos de registros

Salida a una consulta con múltiples tipos de registros
(de tipo lista de salida resumida) presentando en cada línea
iconos que permiten apreciar de qué tipo es cada registro
Las últimas semanas hemos estado trabajando con el concepto de tipo de salida. Hemos trabajado dos criterios de clasificación: la clasificación de las salidas atendiendo a la cantidad de información que se presenta de cada registro y la clasificación de las salidas de acuerdo al número de registros. Examinaremos hoy un tercer criterio de clasificación: los tipos de salida según los tipos de registros involucrados. ¿Para qué esta clasificación de los tipos de salida? Como los Arquitectos de información saben y los Gerentes de Información descubren, esta taxonomía ayuda a diseñar las soluciones y proporciona un lenguaje que sirve en la interacción de los equipos que se esfuerzan en desarrollar buenos servicios de información.

Registros y tipos de registro
Recordemos una vez más que un registro lo consideramos como una unidad básica de información concreta y un tipo de registro o de objeto de información se refiere a lo que distingue, como cualidad abstracta, a un conjunto de registros de otro conjunto, cualitativamente distinto. Por ejemplo, cuando hablamos de autos, trámites o obras de arte, hablamos de tipos de registros, entidades genéricas. Cuando hablamos de un cierto auto, un trámite en particular ocurrido en un momento dado,  o una obra de arte específica, estamos hablando de registros. Los contenidos de información que representan a una persona dada son registros. El registro de Juan Martínez es distinto del de Pedro Rodríguez, aunque ambos son del mismo tipo: "Persona". En otras palabras, lo que tienen en común las personas entre si, los autos entre si y los trámites entre si, son los tipos de registro: persona, auto, trámite.

Aclaramos el punto porque este concepto abstracto de tipo de registro (o tipo de objeto de información) es central hoy. Lo necesitamos para clasificar los tipos de salidas según los tipos de registros involucrados. Según este criterio, podemos clasificar los tipos de salidas en dos: Salidas de un único tipo de registro y Salidas de múltiples tipos de registros.

Salidas de un único tipo de registros
Es una secuencia de cero a múltiples registros en los que todos los registros presentes son de un mismo tipo. El hecho que por definición se incluyan sólo registros de un cierto tipo permite hacer consideraciones especiales en la salida. Incluso, en un sistema bien sintonizado, es típico que la salida de cero registros de un tipo sea diferente de la salida de cero registros de otro tipo. El mensaje será diferente, la navegación será diferente. (Ejemplo de una salida con un único tipo de registro en Amazon)

Salidas de múltiples tipos de registros
Es una secuencia de registros de múltiples tipos. El que se incluyan múltiples tipos de registros obliga a hacer consideraciones que sean universalmente adecuadas a varios tipos, imponiendo restricciones en la salida. Por ejemplo, no pueden usarse salidas de tipo tabla o éstas deben hacerse en forma muy genérica y simple, con campos muy básicos. También puede requerirse, eventualmente, indicar de qué se trata el registro, vale decir, a que tipo de objeto de información pertenece. (Ejemplo de salida con múltiples tipos de registros en Amazon)

Como expresábamos en las anteriores oportunidades, considerar esta taxonomía de tipos de salidas es importante porque cuando no se hace en forma consciente, los diseñadores de sistemas se pierden un poco en sus propios diseños, tienden a crear soluciones con poca flexibilidad y poca extensibilidad, confundiendo las consideraciones estéticas, de implementación o de seguridad con las consideraciones de información y las propiedades de los contenidos. Carecen incluso del lenguaje para especificar adecuadamente las soluciones que desean implementar a los profesionales que al final deben hacerlo, usando herramientas informáticas.

Con el de hoy completamos tres criterios de clasificación que podemos usar a la hora de especificar diseños y entendernos con las personas del equipo que trabajan en su implantación. Es sumamente importante mantener estos criterios presentes en las tareas de diseño en que participemos. Pero esto lo ampliaremos mejor en un próximo post, oportunidad para hablar in extenso acerca de diseño (funcional) de salidas.

viernes, 23 de marzo de 2012

Salidas de múltiples registros

Ejemplo de una salida de múltiples registros en http://redparacrecer.org
La semana pasada conversamos sobre el concepto de tipo de salida, presentando como, aunque no es una observación trivial que el común de las personas haga, las salidas de todos los sistemas de información se parecen, en el sentido de que pueden ser clasificadas en tipos que los Arquitectos y Gerentes de información aprenden a reconocer rápidamente. Mencionamos tres criterios de clasificación: por la cantidad de información que se presenta en un único registro, por la cantidad de registros que las integran y por los tipos de registros presentados. La semana pasada sólo entramos en el detalle de la primera de estas clasificaciones, la más simple, la salida de un único registro. Por ello, esta semana veremos la siguiente de las dos clasificaciones restantes. Manejando los tres tipos de clasificaciones podremos comprender por qué estas taxonomías resultan útiles para los que trabajan gestionando servicios de información.

Recordemos, continuando con el hilo de la semana pasada, el concepto de registro como unidad básica de contenido de información. Un registro es siempre específico. Los datos de Carlos Giménez, el acta de matrimonio de Ernesto Vargas y María Pérez, la inscripción de Juan García en Ingeniería Mecánica, son todos ejemplos de registros. Es importante la observación de que, por otro lado, cada uno de estos ejemplos lo es de un tipo de registro diferente: de una persona, de un documento civil, de un trámite universitario.

Clasificación de tipos de salidas según la cantidad de registros
Cuando se usa un sistema (se consulta, se explora, se busca), este puede proporcionar distintos tipos de salidas según la cantidad de registros presente en la respuesta: Salidas de cero registros, salidas de un registro, salidas de múltiples registros.

Salidas de cero registros:
Estas son salidas donde no se presentan registros. Aunque sorprenda a las personas de poca experiencia en Arquitectura de información, estas salidas son muy importantes y muchas veces plantean retos de navegación o de usabilidad. No es lo mismo una pantalla (o ventana) en blanco o con un mensaje inadecuado por lo general o lo impropio, que una pantalla (o ventana) con un mensaje adecuado y enlaces naturales. Por ejemplo: “No hay ninguna solicitud a su nombre, ¿desea hacer una ahora?” (Ver ejemplo).

Salidas de un registro
Son las salidas que presentan la información de un único registro. Pueden ser resumidas o abreviadas, con un enlace para obtener más detalles acerca del registro, pero más típicamente (y con más sentido) se presentan directamente como salidas detalladas. La distinción entre ellas la presentamos en nuestro post anterior (Ver post). Los detalles pueden proporcionarse, como mencionamos la semana pasada, con metadatos explícitos (donde se señalan la etiqueta y el contenido, Ver ejemplo) o con metadatos implícitos, donde factores como la presentación, el tamaño de las letras y la diagramación se usan para separar y distinguir los metadatos (Ver ejemplo).

Salidas de múltiples registros
Son las salidas donde se presenta la información de varios registros. Estas pueden ser muy variadas, ya que hay de múltiples subtipos clasificables dentro del mismo grupo: 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 y salidas de diagramación particular (Ver ejemplo).

Como podemos apreciar en lo expuesto, esta clasificación de las salidas por la cantidad de registros la podemos aplicar siempre, independiente del tipo del sistema del que estemos hablando, del área de aplicación, de la estética, de lo útil. Es interesante adicionalmente adquirir consciencia con esta observación de que, de las 5 dimensiones de la Arquitectura de información, nos estamos moviendo en esta conversación de tipos de salida dentro de una sola: La funcionalidad.

viernes, 16 de marzo de 2012

En los tipos de salida, todos los sistemas se parecen

Los felinos tienen parecidos y diferencias. Los biólogos aprenden a distinguirlas.
Las salidas de los sistemas de información también tienen parecidos y diferencias.
Los Arquitectos de información aprenden a encontrar estos parecidos
y diferencias (foto tomada de http://www.documentalesfantasticos.com)

Funcionalmente hablando y por sorprendente que parezca la afirmación, a pesar de la enorme gama de sistemas que hay en el mundo, a pesar de la variedad de herramientas con que estos se hacen, al final, las salidas que se le presentan al usuario son, por lo general, de unos pocos tipos. Muy pocos además. De allí la afirmación del título de este post: En los tipos de salida, todos los sistemas se parecen. Esto lo sabe el Arquitecto de Información, por vocación dispuesto a levantar la información pertinente para conocer cuáles son las salidas que debe, idóneamente, incorporar en un sistema. Ahora bien… ¿Cuáles son esos tipos de salidas que hacen parecerse a todos los sistemas?

Primero hay que saber que no hablamos de estética ni de usabilidad, sino de contenidos de información. Por eso, para contestar la pregunta de arriba necesitamos definir el concepto de registro que usamos en Arquitectura de Información (AI) como unidad de contenido de información. Llamamos registro a una instancia de información, los datos de una persona, de un libro, de un documento, de un edificio, de un trámite, es decir, la representación interna de un conjunto de datos estructurados, de una unidad de un determinado tipo de información. El conjunto de datos estructurados de un objeto de información específico, es un registro.

El concepto de registro como unidad básica de información es fundamental: Los sistemas se alimentan con registros y sus salidas están integradas por registros. El registro es además importante para entender lo que es un tipo de salida en AI. Con él podemos hacer tres clasificaciones de los tipos de salida de un sistema.

Como los registros de información son siempre de un tipo (persona, documento, etc.), las salidas de un sistema pueden ser de un único tipo de registro (todos registros de personas, todos registros de documentos, etc.) o, alternativamente, de varios tipos de registro. En forma paralela, en decir, usando un criterio completamente independientemente del tipo de registro, la cantidad de registros en la salida, en una página de salida puede haber un único registro o múltiples registros. Finalmente, cuando nos detenemos en un registro en específico, la salida puede variar también por la cantidad de información que se presenta. Esto conforma el panorama de tipos de salidas que pueden concurrir en un sistema, cualquier sistema.

En lo que sigue analizamos el último caso de clasificación, y el caso más sencillo, el que trata de la salida de un único registro. Dejamos los restantes casos, con múltiples registros, para trabajarlos en un siguiente post.

Por la cantidad de información que se presenta una salida de un único registro, las salidas de un sistema pueden ser resumidas, detalladas o abreviadas.

Salidas resumidas
Están conformadas por un conjunto simple de datos que representan lo fundamental de un registro. Puede ser tan pequeña como el título. Normalmente incluye un enlace para obtener la salida detallada del registro en cuestión (Ver un ejemplo).

Salidas detalladas
Son las que presentan la totalidad o una porción significativa de la totalidad de un registro. En ellas los metadatos se proporcionan en forma explicita o en forma implícita a través de una diagramación del contenido (Ver un ejemplo).

Salidas abreviadas
Unos pocos datos de los integrantes de un registro. Normalmente más de lo que se consideraría una salida resumida, pero menos de lo que se considera una salida detallada (Ver un ejemplo).

Considerar esta taxonomía de tipos de salidas es importante porque cuando no se hace en forma consciente, los diseñadores de sistemas se pierden un poco en sus propias creaciones y tienden a diseñar con poca flexibilidad y poca extensibilidad, confundiendo las consideraciones estéticas, de implementación o de seguridad con las consideraciones ligadas a las propiedades de los contenidos de información. Pero esto lo ampliaremos mejor en una próxima oportunidad…

viernes, 9 de marzo de 2012

Funcionalidad: La segunda dimensión

Cuando diseñamos la Funcionalidad nos ocupamos de
que todos los casos de uso esté contemplados
Después de haber definido la Arquitectura de Información como un trabajo que se realiza manejándose en 5 dimensiones, Estructura, Funcionalidad, Navegación, Comunidades e Imagen, nos concentramos hace algunas semanas en la primera de estas dimensiones: La Estructura de Información. Vimos que con independencia del tipo de problema de gestión de información a resolver, el primer paso para lograr una solución con criterios de Arquitectura era hacer la lista de los tipos de objetos de información con los que se trabajará. Luego se definían las propiedades de estos objetos y las asociaciones entre ellos. Queremos en este post entrar en la segunda dimensión: La Funcionalidad. Un área crucial porque, después de todo, los sistemas se hacen siempre para que cumplan una función. Ahora bien, ¿qué es lo que un Arquitecto de Información considera como Funcionalidad?

En la práctica, se comprende que todos los aspectos que se integran en un sistema de información son importantes, una adecuada representación que maneje todo lo necesario, la navegación que haga fácil y estimule el uso, la calidad de la presentación que resulte agradable al usuario, la seguridad que protege los contenidos críticos, las distinción de las comunidades que interactúan con el sistema, etc. Sin embargo, en cierta forma, podemos decir que es esencial en el diseño de un sistema de información la especificación de su funcionalidad, porque ésta está ligada a la razón por la que el sistema se hace.

La definición de la funcionalidad incluye varios aspectos ligados al manejo de la información. ¿Cómo debe introducirse la data?, ¿qué validaciones hay que realizar?, ¿cuáles son las salidas que se requieren?, ¿qué transformaciones de los componentes de la información son necesarios? También cómo buscaremos la información, cuáles son las situaciones de necesidad de exploración que tendremos que resolver, eventuales reportes, servicios de alerta o mensajes que hay que producir, pasos dentro de un flujo de trabajo, etc.

Para definir la funcionalidad normalmente se parte de las situaciones de uso más frecuentes, si bien siempre hay que repasar el análisis realizado para asegurarse que todos los casos de gestión necesarios fueron tomados en cuenta. Arquitectos e Ingenieros coinciden en el empleo del término de "casos de uso", que no es más que cada una de las especificaciones de las situaciones que un sistema de información tiene que contemplar, expresados en un lenguaje que los usuarios finales y todo el equipo involucrado en el proyecto pueda entender.

En esta dimensión de funcionalidad nos enfocamos entonces en lo que el sistema o aplicación debe hacer, dejando de lado otras consideraciones como la representación de información, la seguridad, la estética, etc.

Lo que nos interesa asegurar cuando trabamos en la dimensión de funcionalidad es que especificamos en detalle todo lo que un sistema debe hacer. Que estén contemplados todos los casos de uso. La omisiones aquí pueden significar que un sistema diseñado en su casi totalidad no entre en producción porque alguien de mentalidad pragmática, con toda razón o sin ella, argumente que falta un caso que debe tomarse en cuenta en forma imprescindible, ya que sin él el sistema carece de sentido.

viernes, 2 de marzo de 2012

Asociaciones entre objetos de información

Las asociaciones entre objetos de información permiten construir
modelos de información que trabajan mejor
En las últimas semanas hemos estado conversando sobre las 5 dimensiones de la Arquitectura de Información, y, en particular, sobre la primera: Estructura de información. Por allí llegamos al concepto de Objeto de información y sus propiedades básicas. Pero hay otro tipo de elemento que se requiere para caracterizar estructuras de información: las asociaciones entre objetos. Éstas son relaciones que se establecen entre objetos o entre partes internas de objetos de información. En este post trataremos de explicar estas asociaciones, un tema que es importante para los interesados en entender lo que significa modelar información y que, como siempre, intentaremos abordar en un lenguaje comprensible y con ejemplos sencillos.

La necesidad de asociar objetos de información la encontramos a cada momento cuando diseñamos estructuras de información. Por ejemplo, un contenido que tiene una cita o una relación de aclaración o complementariedad como “Véase” o “Véase también”, muy típica en el medio académico, está asociando dos objetos de información, el contenido inicial y el referenciado. Un matrimonio en un registro civil asocia a dos personas en el matrimonio, pero también a la autoridad civil y los testigos con el acto realizado, cada quien en su rol. Un registro de un profesional en un curso de Postgrado es también un ejemplo simple.

Pensemos, para describir en detalles la idea, un caso muy común en todo tipo de ambientes laborales. En todas las oficinas se lleva un directorio de personas. Incluso en un ejemplo sencillo como éste puede apreciarse lo que significa modelar estructuras de información. Así, pensemos que en el directorio de personas existe la posibilidad de especificar el lugar de trabajo de las personas que registramos en el directorio. Por ejemplo: Carlos González trabaja en el Ministerio de Agricultura.

Puede considerarse que la institución de trabajo, en el ejemplo, el Ministerio de Agricultura, es simplemente un dato de la persona (una propiedad clasificadora en el sentido en que lo explicamos recientemente (Ver Propiedades de Objetos de información) que nos es útil para seleccionar a todas las personas que trabajan allí. Pero si nos detenemos un poco podemos caer en cuenta que, frecuentemente, la institución donde se trabaja no es un campo de la persona sino una relación de ésta con otro objeto de información: la institución. La institución no debe ser tratada como un dato, un nombre clasificatorio, sino como una información (un conjunto de datos con estructura). El punto es que la institución, como objeto de información, tiene una semántica asociada (Ver Semántica de Información) y varios campos de datos que son completamente independientes de las personas que trabajan en ellas, por ejemplo, direcciones físicas y electrónicas, teléfonos institucionales, sitio Web, etc.

La distinción es esencial para el Arquitecto de Información. Si asumimos que la institución es un mero atributo de descripción de una persona, después, por ejemplo, la dirección del trabajo será igualmente un atributo de la persona. No hay relación estructural entre el nombre de la institución donde se trabaja y la dirección del trabajo. En cambio si lo que establecemos es una relación entre la persona y la institución, la dirección será un atributo de la institución. Examinamos los datos de la persona y vemos que trabaja en una institución y examinando la institución podemos ver cual es la dirección (de la institución y por ende del trabajo de la persona). En el caso del primer modelo decimos Carlos González trabaja en el Ministerio de Agricultura y la dirección del trabajo de Carlos es Avenida Bolívar, Nro 1027. En el otro caso decimos Carlos González trabaja en el Ministerio de Agricultura y éste queda en la Avenida Bolívar Nro 1027. En el segundo modelo se maneja el concepto de asociación. En el primero no.

Cuando añadimos más instancias, por ejemplo, más personas que trabajan en el Ministerio de Agricultura, nos damos cuenta que, en efecto, con asociaciones entre objetos de información se modela mejor la Estructura de información.