Arquitectura de Informacin / 1

diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
Aclaracin de ideas errneas sobre AI
El arquitecto de informacin es un miembro vital de los equipos de desarrollo Web,
y juega un papel esencial en la organizacin del contenido de los sitios. El objetivo de
ste artculo es aclarar algunas ideas errneas sobre la arquitectura de informacin y
ayudar a denir el papel que juega el arquitecto de informacin en el desarrollo de
los sitios Web.
Por Thomas Myer. tom@myerman.com
Traducido por Jorge Arango. http://www.jarango.com/es/
Qu es exactamente la arquitectura de informacin? Es lo mismo que diseo?
Algunas descripciones laborales parecen sugerir que la profesin incluye desde admin-
istradores de bases de datos, hasta diseadores visuales y escritores tcnicos.
En la prctica, el arquitecto de informacin prepara una gran parte de los cimien-
tos para la organizacin del contenido de un sitio, sin importar dnde resida el con-
tenido -- ya sea en archivos planos, multimedia, o campos en una base de datos. Y en
sitios complejos y portales, el arquitecto de informacin ayuda a evitar que la falta de
organizacin convierta la experiencia del usuario en una pesadilla.
En ste artculo voy a contestar algunas de las preguntas planteadas en la intro-
duccin -- aclarando algo de la confusin existente -- y voy a proveer algunos recursos
para lectura adicional.
Piensa arquitecto, no diseador
La mejor manera de comprender la diferencia entre un arquitecto de informacin y
un diseador es comparar la diferencia entre un arquitecto de edicios y un diseador
de interiores.
Al arquitecto le interesa principalmente la estructura, ujo, y otros aspectos fun-
damentales del edicio, como lo son la localizacin de los sistemas de plomera y
electricidad. Si el arquitecto no hace su trabajo, el edicio puede caerse, o -- en un
caso menos extremo -- no satisfacer las necesidades de las personas que lo habitan. Por
ejemplo, puede resultar que el edicio no tenga sucientes recmaras.
Por su parte, los diseadores de interiores estn interesados en el color, la local-
izacin, y el estilo de los muebles, las texturas, y las supercies -- en otras palabras, el
atractivo sensorial del edicio. Pueden estar tratando de impartir un aspecto espec-
co a las recmaras (por ejemplo, Mediterrneo o Espaol), o asegurarse que ciertos
colores y estilos estn presentes consistentemente a travs de toda la estructura.
sto no quiere decir que uno u otro de estos trabajos sea ms fcil o ms difcil. Sim-
plemente son diferentes. Obviamente, siempre van a solaparse un poco (por ejemplo,
el arquitecto esta interesado en el atractivo visual, y el diseador esta interesado en
el ujo y acceso del edicio), pero por lo general las dos disciplinas se complementan.
Usted no le pedira a un diseador de interiores que le diseara la estructura de una
casa, y probablemente no le pedira a un arquitecto que opinara sobre el esquema de
colores de las paredes de su residencia.
Existen paralelos en el campo de desarrollo Web. El arquitecto de informacin por
lo general no es experto en diseo de identidades, colores, composicin, y ciertas
formas de comunicacin visual. stos campos son la especialidad del diseador. Sin
embargo, el arquitecto de informacin conoce de categorizacin, XML, creacin y or-
ganizacin de contenido, diseo de interactividad, y diseo de navegacin. Su experi-
encia radica en las estructuras informticas. El resto de ste artculo presenta cundo,
dnde, y cmo se puede aplicar sta experiencia.
Cundo y dnde trabajan los arquitectos de informacin
El mejor momento para involucrar a un arquitecto de informacin es al inicio del
Arquitectura de Informacin / 2
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
desarrollo del proyecto. Al igual que uno no llamara a un arquitecto tradicional a una
construccin en el momento de techar conjunto de paredes inestables, es preferible
llamar a un experto antes de afrontar problemas con un sitio Web.
Sin tener en cuenta en qu parte del proceso se involucre a un arquitecto de infor-
macin, l va a querer comprender los siguientes parmetros del proyecto:
- Metas y necesidades de los usuarios
- Metas del negocio u organizacin
- Limitaciones tecnolgicas
- Limitaciones del contenido
- Limitaciones del proyecto
El concepto de entender los objetivos y necesidades de los usuarios no debe sor-
prender a los profesionales de usabilidad que lean ste artculo. Sin embrago, algunas
de las otras ideas pueden ser nuevas para el grupo que sigue a Jakob Nielsen. El princi-
pal objetivo de un arquitecto de informacin es construir estructuras informticas que
sean fciles de entender y utilizar. Para poder lograrlo, debe alinear las metas del ne-
gocio con los objetivos de los usuarios, mientras trabaja dentro de las limitaciones del
proyecto (fechas de entrega, recursos, presupuesto, etc.), asunto tcnicos (lenguaje
de desarrollo, base de datos, etc.), y produccin del contenido (personal disponible,
conocimientos del talento interno o subcontratado, etc.).
Por ejemplo, la seleccin de un lenguaje de programacin por encima de otro
puede afectar la manera en que se maneja el estado de sesin en un portal de con-
tenido, lo cual puede afectar la interaccin bsica entre los usuarios y el contenido.
Especcamente, puede causar que el contenido sea desplegado en una pgina larga
nica en vez de dividirse en varias pginas ms pequeas. Otro buen ejemplo de lim-
itaciones del contenido puede ser el caso de un pequeo grupo interno de escritores
con poca (o ninguna) experiencia sobre el tema abarcado por el sitio. sta limitacin
puede contradecir la principal meta del negocio: crear un sitio con profundidad edito-
rial sobre se tema particular. En ste caso, el negocio puede considerar contratar ms
escritores o incrementar el presupuesto para escritores subcontratados.
Aunque ambos asuntos parecieran no tener mucho que ver con la organizacin y
despliegue de informacin en el sitio, la interaccin bsica del usuario con el conte-
nido puede verse profundamente afectada.
El contenido de un sitio Web no es un objeto esttico: puede cambiar no solo de
estructura y medio de despliegue, sino tambin de un da a otro. Para lograr una ar-
quitectura de informacin efectiva, es esencial recordar la estrategia de contenido y
mantenerlo alineado con los objetivos del negocio.
Cmo trabajan los arquitectos de informacin
El proceso de la arquitectura de informacin ocurre usualmente en dos pasos:
primero, usando una metodologa de arriba a abajo, seguido por una de abajo a ar-
riba.
La investigacin de arriba a abajo usualmente ocurre primero. Como sugiere su
nombre, ste mtodo ayuda al arquitecto de informacin a comprender todo lo que
abarca el proyecto, y le permite elaborar los detalles del despliegue, ujo, y estructu-
racin del contenido.
Es posible comprender las metas de los usuarios y la organizacin, pero es necesario
tambin traducir stas metas en una imagen general de la estructura de contenido del
sitio. Por ejemplo, si el sitio va a ser un portal para la venta de equipo de nieve e infor-
macin al respecto, el arquitecto de informacin debe comprender cmo piensan los
compradores y usuarios de stos equipos acerca de ste contenido. En pocas palabras,
debe comprender el espacio conceptual del usuario. Por ejemplo, los snowboards
y esques pueden constar de diferentes categoras de productos e informacin. Y el
Arquitectura de Informacin / 2 Arquitectura de Informacin / 3
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
esqu puede contar con diversas sub-categoras, como el esqu montas y competi-
tivo. La forma que toma la estructura del sitio de arriba a abajo ayuda a hacer ms
navegable el contenido.
A continuacin presentamos el mtodo de abajo a arriba. ste mtodo ayuda al
arquitecto de informacin a comprender los pedazos pequeos que hacen que todo
encaje, como la metadata y todos los asuntos relacionados a la metadata: qu debe
hacer, dnde debe estar almacenada, cmo utilizarla, y cmo interactan los difer-
entes tipos de metadata.
La metadata es esencial para gran parte de la actividad en el sitio, desde la bsque-
da, hasta la personalizacin y organizacin del contenido. Qu es la metadata? Como
sugiere su nombre, es literalmente data acerca de la data. Por ejemplo, cuando hab-
lamos, las palabras que salen de nuestra boca pueden considerarse como data. El tono
de nuestra voz, nuestro lenguaje corporal, e inclusive la personalidad y actitud de
nuestro interlocutor pueden considerarse metadata. La metadata enriquece nuestra
comprensin de la data.
Para seguir con el ejemplo anterior del sitio de venta de equipo de nieve, digamos
que los dueos del sitio quieren que cualquiera que lea un articulo sobre esqu com-
petitivo puedan ver en un recuadro productos relacionados en la tienda virtual del si-
tio. Una manera de crear ste efecto es crear una taxonoma de metadata -- un tipo de
jerarqua de trminos y conceptos que pueden ser asignados tanto al contenido como
a los productos. Por ejemplo, una taxonoma parcial para el sitio puede verse as:
Snowboards
Esques
Esqu competitivo
Esqu montas
Esqu slalom
Botas de nieve
Etc.
Si se crea y usa una taxonoma centralizada, no es necesario adivinar cul es la
relacin entre los productos y el contenido al momento de hacer vnculos entre los
mismos. Si todos los productos y el contenido estn localizados en el lugar correcto en
la taxonoma, los usuarios que ven un artculo marcado como esqu competitivo van a
ver productos de esqu competitivo en el recuadro.
Adems, si un ao despus los dueos del sitio deciden implementar un sistema de
personalizacin, la misma taxonoma puede ser utilizada. Los usuarios pueden crear
cuentas y escoger qu tipo de contenido y productos quieren ver o enfatizar den-
tro de la lista ofrecida por la taxonoma. Los problemas se reducen debido a que la
misma taxonoma se est utilizando para la personalizacin, los productos, y el conte-
nido. Los usuarios que muestran anidad por el contenido y productos relacionados al
snowboarding pueden recibir todos los artculos marcados como tal.
Cmo reciben su informacin
Los arquitectos de informacin deben recopilar mucha informacin dentro de
perodos de tiempo cortos. Para lograrlo, utilizan mtodos como stos:
1. Solicitando listas prioritarias de funcionalidad deseada, ya sea por medio de
email, en persona (uno-a-uno), o en sesiones de grupo. stas listas son efectivas
porque permiten a los usuarios tener sesiones creativas sin obstculos o limitaciones.
Dar prioridad a las funciones deseadas ayuda a administrar el ltrado de los requisitos
y deseos. Una lista sintetizada, visible a todos los participantes, ayuda a dar una idea
general de la escala del proyecto y permite asignar responsabilidad del proceso al
grupo entero.
Arquitectura de Informacin / 4
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
2. Conduciendo sesiones en el tablero con grupos pequeos que permiten a los
partcipes explorar diferentes reas conceptuales. stas sesiones pueden utilizarse
para hacer creatividad pura, dar seguimiento al ejercicio anterior (las listas), o com-
poner los componentes y el ujo de las pginas. Si es cierto que una imagen vale por
mil palabras, ver el proceso de creacin de la imagen (en sentido literal y gurativo)
vale varios miles de palabras.
3. Elaborando un anlisis competitivo de 3-5 sitios similares al del cliente, y pre-
sentando los resultados de dicho anlisis. ste ejercicio no solo puede ayudar a de-
senterrar requisitos y deseos adicionales, sino que tambin puede ayudar a identicar
la funcionalidad base para la organizacin. Por ejemplo, si el sitio de un competidor
cuenta con 500 artculos, la administracin de su compaa puede determinar exceder
esa cantidad al nal del trimestre siguiente. Desde el punto de vista del usuario, el
incluir funcionalidad popular en el sitio -- aquellas cosas que han llegado a esperar
como funcionalidad base de los otros sitios -- podra ser til. Y por supuesto, evitar el
mal diseo y decisiones arquitectnicas hechas en otros sitios puede mejorar el sitio
que su equipo est construyendo.
4. Los anlisis de tareas y audiencias son mtodos clsicos para averiguar quin
es la audiencia, y qu esperan lograr los usuarios del sitio. El anlisis de audiencia
puede comprender desde la investigacin demogrca y psicogrca, hasta estudios
etnogrcos de usuarios reales. El resultado nal de ste trabajo por lo general con-
siste de casos que denen usuarios especcos (tambin conocidos como actores) y sus
tareas. Por ejemplo:
Pedro administra un equipo de desarrolladores de software en una corporacin
global. Tiene 30 empleados en su departamento, y necesita las noticias ms recientes
sobre lenguajes de programacin. No est interesado en los aspectos tcnicos de los
mismos, sino en el impacto que tienen las decisiones tecnolgicas sobre las prcticas
del negocio, particularmente en la disminucin del tiempo que toma llevar el pro-
ducto al mercado.
5. Los grupos focales de usuarios son una buena manera de obtener comentarios
y reacciones acerca de los prototipos o diseos del sitio. Si quiere usar sta tcnica,
asegrese de usar un moderador con experiencia, alguien que pueda obtener buena
informacin sin inuenciar a los usuarios. Tambin asegrese de estar al tanto (formal
o informalmente) de las pruebas que se hacen al grupo focal. Las observaciones y gra-
baciones usualmente se hacen fuera de vista del grupo, con buena razn. Cualquiera
que sabe que est siendo observado naturalmente cambia sus reacciones y compor-
tamiento.
6. Por ltimo, las pruebas uno-a-uno pueden ayudar al arquitecto de informa-
cin a investigar casos especcos ms profundamente. Por ejemplo, una bsqueda de
informacin bien planicada (y orquestada) es una buena prueba de cuan intuitiva es
la organizacin del sitio.
Otro mtodo interesante es la clasicacin de tarjetas (vea la seccin de Recursos
ms adelante en ste artculo). sta tcnica requiere que los participantes junten con-
ceptos parecidos (cada uno en una tarjeta individual). El resultado parece un esquema
de organizacin crudo. En conjunto, el grupo de stos resultados pueden conformar
las bases de un prototipo de la arquitectura de informacin del sitio.
El arquitecto de informacin debe evitar introducir prejuicios durante las pruebas
uno-a-uno. No debe discutir sus acciones ni tampoco debe corregir u ofrecer asist-
encia a los partcipes; de hecho, debe seguir un guin. Sin embargo, se le recomienda
alentar a los interesados a expresar sus opiniones claramente mientras hacen la prue-
ba; sta informacin puede dar un buen vistazo de cmo navegan su propio espacio
conceptual tras bastidores.
Obviamente, el trabajo del arquitecto de informacin no consiste nicamente en
obtener informacin; debe tambin analizar sta informacin, sintetizarla, y proba-
blemente descartar algunos datos o enfocarse en ciertas partes especcas. Entonces,
debe hacer algunas buenas conjeturas al azar -- ste no es un campo guiado por es-
Arquitectura de Informacin / 4 Arquitectura de Informacin / 5
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
trictos lineamientos cientcos. Jesse James Garrett, un prominente arquitecto de in-
formacin, dice que la clave de su xito es adivinar correctamente.
La arquitectura de informacin es un proceso, no un resultado nal. Muchos sitios
han sido lanzados con arquitecturas preliminares, estructuras y organizaciones que
son sucientemente buenas por el momento. An si el arquitecto fuese a desarrol-
lar la organizacin perfecta para un sitio, la misma no durara seis meses, debido a
que en ese tiempo seguramente algo va a cambiar (las necesidades de los usuarios,
objetivos del negocio, etc.) Estos cambios debilitaran la arquitectura de informacin.
La mejor herramienta que trae a su labor el arquitecto de informacin es una
mente abierta. El arquitecto de informacin no trata con catlogos de partes fciles
de organizar. Por lo contrario, el campo comprende algo mucho ms abstracto -- espa-
cios conceptuales -- y sto requiere conocer psicologa, los fundamentos de la comu-
nicacin, y el lenguaje (en particular, la semntica y la pragmtica). Adems, debido
a que el proceso se orienta hacia el contenido, son un factor las abstracciones de la
bsqueda, creacin, edicin, produccin, y mantenimiento del contenido.
Dado que el arquitecto de informacin es el amo del dominio anteriormente men-
cionado, su responsabilidad es proveer conocimiento -- ser un lder intelectual. Sus
decisiones y recomendaciones no solo impactan el desarrollo tcnico del sitio, sino
tambin las prcticas del negocio. Si los usuarios no pueden encontrar el contenido
que buscan, o si el sitio los confunde, no van a regresar. stas fallas podran afectar los
ingresos de la compaa y su prestigio en el mercado.
Software y herramientas
Existen muchas aplicaciones de software que prometen suplir mucho del trabajo
que hacen los arquitectos de informacin -- eso es, comprender el contenido y cmo
es categorizado, publicado, y administrado. Muchas de stas herramientas son muy
primitivas aun, y no hacen todo lo que prometen. stas faltas se deben principalmente
al tipo del campos que abarca la arquitectura de informacin: los lenguajes humanos
(y los espacios conceptuales de los seres humanos) son difciles de analizar, y an ms
difciles de sistematizar en procesos repetibles.
Las herramientas de administracin de contenido intentan facilitar el trabajo de
la administracin del contenido. En esencia, permiten a los equipos de creadores del
contenido publicarlo y administrarlo, ya sea en archivos planos, tablas de bases de
datos, o ambos.
Desafortunadamente, muchas de stas herramientas estn diseadas desde un
punto de vista supercial del proceso que atraviesa cada unidad de contenido durante
toda su existencia. sto puede ser debido a que los diseadores de dichos sistemas
tienden a no pedir una descripcin de su trabajo a los profesionales de contenido.
La mayora de los sistemas de administracin de contenido le permiten crear una
unidad de contenido y procesarla mediante un ujo de trabajo. Dependiendo del
sistema, los ujos de trabajo pueden ser fciles o difciles de congurar y ajustar a las
necesidades de los ujos departamentales establecidos en la organizacin. An los
mejores sistemas de administracin de contenido tienden a ignorar asuntos vitales
para la creacin del contenido, como lo son la investigacin, la creacin de bosquejos,
el almacenaje de materiales originales, etc. o inclusive el manejo eciente del conte-
nido despus de su publicacin.
Sin embargo, dada la cantidad de proveedores de sistemas de administracin de
contenido que hay en el mercado, puede ser que la competencia eventualmente
produzca una herramienta que valga la pena. Hasta ahora, mi experiencia sugiere que
las herramientas basadas en software libre (open source) entalladas para las necesi-
dades de un grupo de personas especcos son mejores que las herramientas comer-
ciales en todas las instancias.
Las herramientas de categorizacin automtica pretenden aliviar la onerosa tarea
de categorizar (asignar metadata a) grandes cantidades de contenido, como los repos-
itorios de archivos, tablas de bases de datos, e inclusive archivos de correo electrnico.
Arquitectura de Informacin / 6
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
Algunas de stas herramientas no ofrecen una forma fcil de manejar archivos de
multimedia, imgenes, e inclusive documentos complejos como los ujogramas de
Visio. Adems, todava no entienden signicados -- por ejemplo, no distinguen entre
el sustantivo amo y la conjugacin amo del verbo amar, ni pueden clasicar docu-
mentos diferentes que tratan de Java (la isla), Java (el caf), y Java (el lenguaje de
programacin).
Las mejores herramientas de categorizacin automtica permiten a los operadores
humanos intervenir de forma juiciosa en el proceso. Por ejemplo, yo ayud a disear
una herramienta que ofrece una lista de categoras disponibles para ser aplicadas a
una unidad de contenido en base a las sugerencias del operador humano. En ste
sistema, es responsabilidad del operador humano escoger las categoras ms apropia-
das de la lista pre-ltrada que ofrece el sistema, y en caso de que no existan, escoger
categoras de la lista completa.
Otro enfoque ha sido crear herramientas que implementan y mantienen diccion-
arios ideolgicos. Un diccionario ideolgico es una herramienta que emula las refer-
encias de escritorio usadas por los escritores. Para cada trmino disponible en una lista
de trminos, el diccionario puede hacer evidentes las relaciones jerrquicas, y sealar
trminos alternos (sinnimos) y trminos relacionados (conceptos aledaos al signi-
cado del trmino). Un diccionario ideolgico bien construido puede aliviar mucha de
la frustracin que sufren los usuarios al buscar informacin.
Por ejemplo, si se est desarrollando un sitio de comercio electrnico que se espe-
cializa en la venta de ropa, un diccionario ideolgico puede evitar la frustracin de los
usuarios al buscar blazers, cuando el sistema les llama chaquetas. Con un diccion-
ario ideolgico, es posible denir el trmino blazer como sinnimo de chaqueta
y desplegar los trminos correctos en los resultados de la bsqueda. De la misma man-
era, cuando el usuario est viendo una chaqueta especca, una columna en la pgina
puede mostrar pantalones que complementan la chaqueta debido a que hay una rel-
acin denida entre ambos artculos en el diccionario ideolgico.
Muchos de stos diccionarios son efectivos debido a que combinan lo mejor de
ambos mundos. Al operador humano se le permite hacer lo que mejor hace: utilizar su
cerebro poderoso y su conocimiento tcito sobre un campo particular. Al computador
tambin se le permite a hacer lo que mejor hace: utilizar sus vastos recursos computa-
cionales para el procesamiento rpido de grandes cantidades de data.
Recursos
- La lista de recursos de arquitectura de informacin de Jesse James Garrett es un
excelente sitio para comenzar.
- El artculo de Jesse James Garrett sobre el estado actual de la arquitectura de in-
formacin es inteligente e interesante. Es lectura requerida para cualquiera que est
contemplando un cambio de carrera.
- El Glosario de Arquitectura de Informacin de Kat Hagedorn es una lista til de
trminos importantes utilizados en el campo, denidos y entrelazados.
- El artculo Evaluando la Arquitectura de Informacin de Steve Toub presenta
las posibles consecuencias de no tener una organizacin efectiva en un sitio. Tambin
incluye algunos mtodos para estructurar el contenido.
- Keith Instone administra un sitio til llamado Usable Web. Est lleno de temas
sobre usabilidad y arquitectura de informacin, e incluye vnculos a recursos en el
Web.
- El Centro Argus para la Arquitectura de Informacin era un sitio muy conocido
hasta que fue cerrado hace un ao. Sin embargo, todava contiene muchos artculos
tiles y un glosario de trminos.
- El sitio de Benjamin Fry contiene artculos interesantes sobre la visualizacin de
data. Su tesis de MIT sobre el diseo orgnico de informacin es esencial para cualqui-
era que desee hacer trabajo serio en ste campo.
Arquitectura de Informacin / 6 Arquitectura de Informacin / 7
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
- El libro Arquitectura de Informacin Para el World Wide Web de Louis Rosen-
feld y Peter Morville es considerado un clsico en ste campo.
- La Clasicacin de tarjetas y anlisis de grupos (developerWorks, Enero 2002)
de Thomas Myer ofrece una introduccin completa a sta tcnica para obtener infor-
macin sobre los usuarios.
- El artculo Usabilidad de contenido web (developerWorks, Mayo 2002) de Tho-
mas Myer presenta guas para hacer el contenido ms usable.
- Lea La experiencia del usuario (developerWorks, Octubre 2000) de Dick Berry
para ver por qu son importantes los modelos de usuarios.
Acerca del autor: Thomas Myer ha sido escritor, desarrollador de multimedia, de-
sarrollador Web, y arquitecto de informacin. Ha escrito y diseado proyectos inter-
activos para compaas como Cisco Systems y Vignette, y actualmente es un consultor
independiente y escritor.
Original en Espaol: Aclaracin de Ideas Errneas Sobre la Arquitectura de Infor-
macin. Traducido por Jorge Arango
Original en Ingls: Information Architecture Concepts - Miscoceptions Explained
Un vocabulario visual
para describir arquitectura de informacin y diseo de
interaccin
Jesse James Garrett
Tabla de Contenidos
1. Resumen
2. Historia de versiones
3. Consideraciones iniciales
4. Trasfondo conceptual
5. Elementos simples: paginas, documentos y pilas de stos
6. Creando relaciones: conectores y echas
7. Todo de una vez: conjuntos concurrentes
8. Separndolo: puntos de continuacin
9. Elementos comunes: reas y reas iterativas
10. Componentes re-utilizables: reas de ujo y referencias
11. Conceptos bsicos para elementos condicionales
12. Haciendo elecciones: puntos de decisin
13. Buscando camino: conectores y echas condicionales
14. Eleccin mltiple: ramas condicionales
15. Elige uno o ms: selectores condicionales
16. Una decisin, muchos caminos: racimos
17. Algunas restricciones pueden aplicar: reas condicionales
18. Conclusin
19. Libreras descargbles de formas
Resumen
Los diagramas son una herramienta esencial para comunicar arquitectura de informacin y
diseo de interaccin en equipos de desarrollo Web. Este documento trata las consideraciones
en el desarrollo de tales diagramas, delinea una simbologa bsica para diagramar conceptos de
arquitectura de informacin y diseo de interaccin, y entrega guas para el uso de estos elementos.
Historia de versiones
Arquitectura de Informacin / 8
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
1.1b (6 Mar 2002)
Informacin sobre soporte incorporado en OmniGrafe 2.0
Nueva librera de formas para iGrafx Flowcharter
1.1a (17 Sep 2001)
Nueva libreras de formas para Macromedia FreeHand
Publicada hoja de trucos y template de formas PDF
1.1 (31 Ene 2001)
Agregado el elemento pila de archivos
Agregado el elemento selector condicional
Modicado el elemento echa para permitir mltiples puntas de echa
Modicado el comportamiento del elemento racimo de tal forma que ahora slo aparece
ujo abajo desde un selector o rama condicional
Modicado el comportamiento del elemento rama condicional para permitir un resultado
nulo
Numerosas mejoras a las libreras de formas
Nueva librera de formas para Adobe InDesign
1.0 (17 Oct 2000)
Publicacin inicial
Consideraciones iniciales
Un vocabulario visual es un conjunto de smbolos usado para describir algo (usualmente un
sistema, estructura o proceso). El vocabulario descrito aqu puede ser usado por un arquitecto de
informacin o diseador de interaccin para describir, en un nivel alto, la estructura y/o ujo de la
experiencia de usuario de un sitio Web.
Estas descripciones, o diagramas son usados por cinco audiencias primarias:
Inversionistas y gerentes de proyecto, los utilizan para obtener un sentido general del
alcance y forma del proyecto.
Productores de Contenido, los usan para derivar los requerimientos de contenido.
Diseadores visuales y de interfaces, los utilizan para derivar una cuenta de cuntos diseos
de pagina nicos deben ser producidos y obtener un sentido inicial de los requerimientos de
navegacin e interfaz para estos diseos.
Tecnolgos, los utilizan para derivar requerimientos funcionales.
Arquitectos de informacin y diseadores de interfaz los usan para desarrollar
requerimientos detallados de navegacin e interfaz para cada pgina.
Cada una de estas audiencias (exceptuando los inversionistas) necesita gran cantidad de detalle para
hacer su trabajo. El problema es que el detalle que cada audiencia requiere vara en gran manera
del detalle requerido por los otros, y la mayora de este detalle es irrelevante para las necesidades
de otras audiencias.
El enfoque sensible es limitar el detalle en el diagrama a lo que puede ser tilmente aplicado por
todas las audiencias. El diagrama por lo tanto sirve como un documento hito para el desarrollo de
documentos ms detallados, especcos a las necesidades de cada audiencia.
Otros requerimientos clave de un vocabulario visual para arquitectura de informacin y diseo de
interaccin incluyen:
Compatible con pizarra blanca: El vocabulario debera ser tan simple que los diagramas
puedan ser dibujados rpidamente a mano. Los elementos del vocabulario debieran ser
sucientemente distintos entre s para que un dibujo medianamente malo no comprometa
la claridad del diagrama.
Independiente de herramienta: El vocabulario debiera estar diseado de forma que no
requiera de software especializado para construir diagramas. El vocabulario no debiera
Arquitectura de Informacin / 8 Arquitectura de Informacin / 9
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
favorecer el uso de una herramienta particular de software, sino permitir a los arquitectos
utilizar las herramientas ms cmodas a ellos.
Pequeo y auto-contenido: Porque estos diagramas son usados por una amplia gama
de audiencias con diferentes niveles de conocimiento (o incluso inters) en sistemas de
diagramas usados en otras reas de desarrollo tcnico, el vocabulario no debiera requerir
tal conocimiento o inters. El total de los elementos debe ser mantenido al mnimo posible,
manteniendo una estricta relacin uno-a-uno entre conceptos y smbolos, para que el
vocabulario pueda ser aprendido y aplicado en forma rpida. Los conceptos expresados por
el diagrama pueden ser arbitrariamente complejos; el medio de su expresin no debe serlo.
Trasfondo conceptual
Arquitectura de informacin y diseo de interaccin son dos caras de la misma moneda. (Ver Los
Elementos de la Experiencia de Usuario para deniciones de los trminos como son usados aqu.)
Los diagramas de sitios contemporneos inevitablemente involucran ambas caras. Pero para cada
una, los objetivos del diagrama son levemente diferentes.
En ambos casos, el diagrama se enfoca en lo que llamamos la macro-estructura, entregando
slo detalle suciente para permitir a los miembros del equipo ver la gran foto. La tarea del
arquitecto es determinar el nivel apropiado de detalle para lograr este objetivo. El detalle especco
a nivel de pgina o micro-estructura, es detallado en otros documentos de los cuales el arquitecto
puede no ser directamente responsable de desarrollar.
Cuando describimos arquitectura de informacin, el diagrama debiera enfatizar la estructura
conceptual y organizacin del contenido. Ntese que la estructura conceptual no es lo mismo
que la organizacin de navegacin. El objetivo del diagrama de arquitectura de informacin no
es entregar una especicacin de navegacin completa; este detalle es mejor puesto en otros
documentos, donde cauce menos riesgo de confundir y distraer.
Cuando describimos diseo de interaccin, el diagrama debiera enfatizar cmo el usuario uye
a travs de tareas denidas, y lo que son los pasos discretos en estas tareas. Tal como con la
navegacin, los detalles de interfaz no debieran aparecer en el diagrama - si te encuentras
dibujando botones y campos, probablemente ests cargando el diagrama con un exceso de detalle.
Este vocabulario est basado en un modelo conceptual simple abarcando tanto arquitectura de
informacin como diseo de interaccin:
Al sistema presenta al usuario caminos.
El usuario se mueve a travs de estos caminos mediante acciones.
Estas acciones entonces causan al sistema a generar resultados.
Elementos simples: paginas, documentos y pilas de stos
La unidad bsica de la experiencia de usuario en la Web es por supuesto, la pagina, la cual
representamos con un simple rectngulo. Ntese que la pagina es una unidad de presentacin, no
(necesariamente) una unidad de implementacin -- una pagina en tu diagrama puede representar
mltiples archivos HTML (como en una interfaz con frames) o unidades mltiples de cdigo (como
en includes en el servidor -- SSI -- o una implementacin manejada por bases de datos).
Adems de paginas, tambin hay archivos, parcelas de datos sin propiedades de navegacin. Estos
archivos son entregados al usuario para su uso fuera de un ambiente de navegador Web, browser
(tales como archivos de video, archivos independientes como PDFs ejecutables). Para estos, usamos
nuestro viejo amigo el icono con oreja de perro.
Arquitectura de Informacin / 10
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s

Figura 1a: [izquierda] La pagina y el documento
Figura 1b: [derecha] La pila de paginas y la pila de documentos
Usa una pila de paginas para indicar un grupo de paginas funcionalmente idnticas cuyas
propiedades de navegacin son inmateriales a la macro-estructura del sitio. Similarmente, una
pila de documentos representa un grupo de documentos que reciben tratamiento de navegacin
idntico y pueden ser clasicadas como una entidad nica (tal como una coleccin de juegos
descargables o una librera de manuales de instrucciones en PDF).
Usamos etiquetas en paginas y archivos para identicarlos. stas no tienen la necesidad de ser una
correlacin con designaciones como el elemento <TITLE> HTML o nombres de documentos, pero
deben ser nicos para cada pgina o documento en el diagrama. Identicadores numricos nicos
y designaciones de tipo tambin entregan una buena forma de llevar el rastro todas las paginas y
documentos en tu diagrama.
Creando relaciones: conectores y echas
Las relaciones entre los elementos son ilustradas mediante lneas simples o conectores. Estas
relaciones conceptuales se traducirn inevitablemente en relaciones de navegacin -- pero no todas
las relaciones de navegacin aparecern en el diagrama.
En el caso de la arquitectura de informacin, stas relaciones estn comnmente reejadas a travs
de la organizacin jerrquica de paginas en rboles. Sin embargo, esto de ninguna manera es
obligatorio ni (en algunos casos) recomendable.

Figura 2a: [izquierda] Una estructura simple de rbol
Figura 2b: [derecha] La misma estructura diagramada de forma diferente
Cuando diagramamos diseo de interaccin, nuestras lneas tambin deben indicar direccin para
indicar cmo el usuario se mover a travs del sistema por una tarea particular. Transformando
nuestros conectores en echas har el truco de forma limpia. Usamos los trminos corriente abajo
y corriente arriba para referirnos a la posicin de los elementos relativa a este movimiento hacia
adelante.
Ntese que estas echas no son como las echas que indican una calle de un solo sentido, ms
bien son como las echas que indican el camino hacia el patio de comida en el centro comercial. El
usuario no est impedido de moverse en direccin opuesta; la echa indica solamente la direccin
en la cual el usuario probablemente querr ir.
Arquitectura de Informacin / 10 Arquitectura de Informacin / 11
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s

Figura 3a: [arriba izquierda] Flecha indica movimiento corriente abajo hacia el n de la tarea
Figura 3b: [abajo izquierda] Barra cruzada indica que el movimiento corriente arriba no est
permitido
Figura 3c: [derecha] Flechas mltiples clarican la direccin
Si por alguna razn queremos prohibir el movimiento corriente arriba (como en los casos donde
alguna accin irreversible como eliminar un registro ha tomado lugar), usamos una barra cruzada
(slo una corta lnea perpendicular) en el extremo opuesto a la punta de la echa para indicar esto.
En algunos casos, puede ser necesario agregar una punta de echa adicional cerca de la pgina
corriente arriba para claricar la direccin del ujo en una arquitectura ms compleja. (Una nota
prctica: muchas aplicaciones de diagramacin no permiten al usuario encadenar dos echas de
esta manera. Para solucionar esto, las libreras de formas incluyen un elemento punto de goma,
un elemento invisible que consiste en un punto nico de conexin. Usa este elemento para unir dos
echas.)
Los conectores y echas tambin pueden ser etiquetados, pero el uso de stas debe ser limitado a
casos en los cuales la accin tomada por el usuario necesita ser claricada. Si las etiquetas se tornan
largas, son muchas y comienzan a sobrecargar el diagrama, apunta al lector hacia una nota al pie o
una referencia en un anexo.
En los ejemplos dados en este documento, referencias al pie de pagina y en anexos aparecern
como una combinacin de nmero y letra entre parntesis. Los nmeros se reeren a la pagina de
diagrama en la cual la referencia aparece; las letras se reeren a la nota especca. Por ejemplo, la
primera nota en la pgina 3 de un diagrama debera ser referida como (3a), la segunda (3b) y as en
adelante.

Figura 4a: [izquierda] Una etiqueta superua
Figura 4b: [centro] Una etiqueta til
Figura 4c: [derecha] Una referencia al pie o anexo
Todo de una vez: conjuntos concurrentes
Un conjunto concurrente (representado por el semi-crculo) es usado en casos cuando una accin
del usuario genera resultados mltiples simultneos (tal como abrir una ventana pop-up mientras
una pgina se carga en la ventana principal, o mostrar una pagina mientras un documento es
descargado).
Arquitectura de Informacin / 12
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s

Figura 5: Un conjunto concurrente
Como las echas, los conjuntos concurrentes tienen direccin. Elementos corriente arriba se
conectan al lado curvo; elementos corriente abajo se conectan al lado plano.
Separndolo: puntos de continuacin
Los arquitectos de informacin se encuentran a menudo deseando hojas de papel ms grandes
para diagramar su trabajo. Pero aun si dispositivos de salida de gran formato como plotters
fueran ampliamente disponibles, algunas arquitecturas son simplemente muy complejas para ser
capturadas en un diagrama nico que lo incluya todo.
Para permitirnos separar nuestros diagramas en secciones fciles de digerir, usamos puntos de
continuacin (parntesis cuadrado) para unir los vacos entre las pginas.

Figura 6a: [izquierda] Un punto contina hacia referencia al lector hacia otro diagrama
Figura 6b: [derecha] Un punto contina desde, retomando desde donde salimos de 6a
Un punto de continuacin nico puede listar una o ms fuentes o destinos segn se necesite. La
orientacin de los corchetes (horizontal y vertical) no tiene signicado particular; la eleccin de
orientacin es problema del juicio esttico del arquitecto.
Elementos comunes: reas y reas iterativas
El elemento rea (un rectngulo de esquinas redondeadas) es usado para identicar un grupo de
paginas que comparten uno o ms atributos comunes (tales como aparecer en una ventana pop-up,
o tener un tratamiento nico de diseo). Usa etiquetas para identicar estos atributos o (como con
los conectores), haz referencias a notas fuera del documento si tienes mucho que decir.

Arquitectura de Informacin / 12 Arquitectura de Informacin / 13
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
Figura 7: Un ejemplo de uso de un rea para representar una ventana pop-up
Muchas arquitecturas incluyen repetir la misma estructura bsica tal como es aplicada a un nmero
de elementos de informacin funcionalmente idnticos. Por ejemplo, puedes tener un catlogo de
productos en el cual cada producto tiene varias pginas asociadas a l. Podras dibujar una instancia
de esta estructura para cada producto, pero, por qu perder el tiempo? Simplemente usa un rea
iterativa -- una pila de rectngulos con esquinas redondeadas -- en vez.

Figura 8: Un ejemplo de uso de un rea iterativa para representar una estructura repetida en un
catlogo de productos
Ntese que conectores y echas no apuntan a las reas mismas. Los elementos de rea slo
sirven para encerrar las paginas. Las reas deben ser aplicadas con cuidado, es muy fcil pillarse
capturando toda clase de detalles con elementos de rea que no se maniestan en la experiencia de
usuario (tal como qu pginas son alojadas en cules servidores) o de otra manera intereren con el
objetivo general del diagrama de comunicar la macro-estructura.
Componentes re-utilizables: reas de ujo y referencias
Algunos diseos de interaccin requieren que una secuencia de pasos (como por ejemplo, un
procedimiento de login) aparezca repetidamente en diferentes contextos a travs del diseo. A
menudo estas secuencias son meramente un componente de una o ms tareas que el usuario est
tratando de lograr. (Esto es anlogo al concepto de sub-rutina en programacin de ordenadores).
Tal rea re-utilizable es llamada un ujo, y es representada en el diagrama mediante dos elementos:
el rea de ujo, que encierra el ujo mismo; y la referencia de ujo, que sirve como marcador para
el ujo en cada contexto en el cual se repite. Ambos elementos tienen la misma forma bsica, un
rectngulo con las esquinas cortadas (o, si preeres, un octgono desgurado).

Figura 9a: [izquierda] Una referencia de ujo sirve tanto como punto contina hasta, como punto
contina desde
Figura 9b: [derecha] El rea de ujo referida en 9a
Las reas de ujo tambin requieren el uso de dos tipos de puntos de continuacin especiales:
puntos de entrada y puntos de salida. stos son ubicados fuera del rea de ujo, mientras los
Arquitectura de Informacin / 14
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
puntos de continuacin, dentro del rea de ujo, indican que el ujo abarca mltiples diagramas.
Las referencias de ujo en s mismas funcionan de manera muy similar a los puntos de continuacin.
El objetivo de ambos tipos de elementos es el mismo: permitir al arquitecto cortar el diagrama
en pginas. La diferencia es que una referencia de ujo puede ser usada en ambas modalidades;
continua desde y continua hasta, mientras que un punto de continuacin puede slo ser uno
otro. Si no necesitas un elemento que tenga ambos roles, probablemente no necesitas usar un ujo.
Conceptos bsicos para elementos condicionales
Con cada vez mayor frecuencia, las arquitecturas de informacin y diseos de interaccin son
reformados de manera dinmica por el sistema mientras el usuario se mueve a travs del sitio. Esta
reformacin es lograda mediante lgica condicional, y los elementos restantes de este vocabulario
son especcos a estructuras de lgica condicional. He aqu un modelo conceptual bsico para la
aplicacin de elementos condicionales:
El sistema sigue la pista a uno o ms atributos, estos atributos pueden ser particulares a:
o el usuario (tal como el tipo de usuario)
o la sesin (tal como el estado del login)
o el contenido siendo accedido (tal como materia temtica)
o o pueden existir en el mundo (tal como la hora y fecha).
Los atributos tienen valores (3 p.m. es un valor posible para hora del da).
La asociacin de un atributo con un valor particular es llamada una condicin.
Las condiciones son evaluadas por el sistema para determinar si son verdaderas.
En una arquitectura esttica, cada camino es presentado a todos los usuarios bajo toda
circunstancia, y cada camino conduce al mismo resultado. En una estructura dinmica, el sistema
decide cules caminos o resultados son presentados al usuario basado en la evaluacin de una o ms
condiciones.
Para minimizar la sobrecarga en nuestros diagramas, estas condiciones son tpicamente descritas en
una nota al pie o anexo que acompaa al diagrama.
Haciendo elecciones: puntos de decisin
Cuando una accin de un usuario puede generar uno de un numero de resultados, el sistema debe
tomar una decisin acerca de cul resultado debe presentar. (Probablemente el ejemplo ms comn
de esto es manejo de errores en el envi de formularios.) Llamamos a esto un punto de decisin, y
como en diagramas de ujo tradicionales, es representado por un diamante.

Figura 10: Un ejemplo de uso de un punto de decisin en una secuencia de login
Arquitectura de Informacin / 14 Arquitectura de Informacin / 15
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s
Ntese que las fechas deben ser usadas en conjunto con los puntos de decisin, para claricar si los
elementos asociados se encuentra corriente arriba o corriente abajo desde el punto de decisin.
Buscando camino: conectores y echas condicionales
Un conector condicional (representado por una lnea cortada) es usado cuando un camino puede ser
o no ser presentado al usuario dependiendo de si una o ms condiciones son cumplidas.

Figura 11a: [izquierda] Un conector condicional
Figura 11b: [derecha] Una echa condicional
Por ejemplo, puede haber una pgina que contenga informacin sensible que slo puede ser vista
por empleados de la compaa. La condicin en este caso sera el tipo de usuario (empleado); si la
condicin se cumple, el camino se hace disponible. Si no, no existe camino.
Eleccin mltiple: ramas condicionales
Cuando un sistema debe seleccionar un camino entre un numero de opciones mutuamente
exclusivas a ser presentadas al usuario, usamos una rama condicional (tringulo). Los elementos
corriente arriba se conectan a un punto del tringulo; los elementos corriente abajo se conectan al
lado opuesto.

Figura 12: Una rama condicional
El ejemplo mostrado en la gura 12 se ve muy parecido al ejemplo del punto de decisin arriba en
la gura 10, pero el comportamiento descrito aqu es bastante diferente. En el ejemplo del punto
de decisin, slo un camino (o elemento de navegacin) era presentado al usuario; dnde conduca
al usuario ese elemento dependa de ciertas condiciones.
En la gura 12, el sistema est tomando una decisin similar, pero sucede antes que la accin del
usuario. La rama condicional indica que el sistema est decidiendo cul camino ser presentado al
usuario. Los caminos desde la pagina A hacia las pginas B, C y D son mutuamente exclusivos; por
ejemplo si existe un camino hacia B, los caminos hacia C y D no existen.
Tal como con los conectores y echas condicionales, una rama condicional puede entregar al
usuario ningn camino (un resultado nulo). La diferencia aqu es que con una rama condicional un
resultado nulo est prohibido; y de estar permitido, es uno de tres o ms resultados posibles. Indica
si una rama permite un resultado nulo en una nota al pie de pgina o indicacin en un anexo.
Elige uno o ms: selectores condicionales
El elemento selector condicional (representado por un trapezoide) funciona de manera muy similar
a la rama condicional, con una diferencia importante: con el selector, los varios caminos corriente
abajo no son mutuamente exclusivos, cualquier nmero de caminos que satisfagan las condiciones
pueden ser presentados al usuario.
Arquitectura de Informacin / 16
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s

Figura 13: Un selector condicional
La aplicacin ms comn del selector condicional es en resultados generados por un motor de
bsqueda. En este caso, la pagina de resultados de bsqueda aparecera corriente abajo desde el
selector; la condicin es el criterio de bsqueda ingresado por el usuario; los caminos corriente
abajo llevaran a las paginas de contenido indexadas por el motor de bsqueda. Tal como con una
rama condicional, el selector condicional puede generar un resultado nulo -- de hecho, es mucho
ms comn con un selector que con una rama.
Una decisin, muchos caminos: racimos
Algunas estructuras condicionales requieren que el sistema presente ms de un camino basado
en ciertas condiciones. Asociamos estos caminos en la estructura con un racimo (representado por
un circulo). El racimo puede aparecer corriente abajo desde una rama condicional o un selector
condicional.

Figura 14: Un racimo corriente abajo desde una rama
La estructura dibujada en la Figura 14 funciona de forma muy similar a una rama condicional, pero
por una condicin estamos presentando ms de un camino al usuario. Entonces, si el atributo siendo
evaluado tiene valor x, el usuario ve un camino hacia la pagina B; pero si el atributo tiene valor y, el
usuario ve caminos hacia ambas paginas C y D.
Algunas restricciones pueden aplicar: reas condicionales
Cuando una o ms condiciones aplican a un grupo de pginas, esas pginas son encerradas en
un rea condicional -- un rectngulo de esquinas redondeadas, pero con un tratamiento de lnea
cortada como el conector condicional.
Arquitectura de Informacin / 16 Arquitectura de Informacin / 17
diseo II // 007
u
n
i
v
e
r
s
i
d
a
d

m
a
i
m

n
i
d
e
s

Figura 15: Un ejemplo de uso de un rea condicional donde se requiere una conexin segura
Las reas condicionales se usan comnmente en situaciones que involucran permisos de acceso,
como cuando se requiere un login o conexin encriptada (SSL). A diferencia de otros tipos de
reas, las reas condicionales son asociadas con un resultado, el cual se genera en caso de que la(s)
condicin(es) no son satisfechas.
Conclusin
Si deseas ver cmo se arma el sistema completo, aqu hay un diagrama de muestra de la
arquitectura de informacin y diseo de interaccin de MetaFilter. (No estuve involucrado en el
desarrollo de este sitio; este diagrama fue desarrollado a partir del sitio.)
Scott Larson cre esta prctica hoja de trucos para una referencia rpida a los varios elementos
condicionales. Y para aquellos interesados en crear sus propias libreras de formas para usar en una
aplicacin diferente a las que aparecen abajo, aqu hay un PDF de todas las formas (gracias a Ross
Olson por la sugerencia).
El vocabulario necesariamente representa slo un primer paso. A medida que la arquitectura
de informacin y diseo de interaccin continan su evolucin, aparecern situaciones que este
vocabulario no abarca. Tu retroalimentacin y recomendaciones para la prxima versin de este
vocabulario son bienvenidas.
Libreras descargbles de formas
OmniGrafe 2.0 es la primera aplicacin en despacharse con soporte incorporado para el
vocabulario visual. OmniGrafe viene actualmente pre-instalado en todos los Apple Power Mac y
PowerBook. Tambien puede ser dascargado desde el sitio Omni.
Otras libreras de formas disponibles:
Archivo de patrn para Visio 2000
Archivo de patrn para Visio 5
Archivo de patrn para Visio 4
Archivo PowerPoint
Archivo de librera para Adobe InDesign
Archivo de librera para FreeHand 10 (gracias Andrew Crow)
Archivo de librera para FreeHand 9 (gracias Andrew Crow)
Archivo EPS Illustrator
Archivo de librera para iGrafx Flowcharter 2000 (gracias Andrew Robinson)
Coleccin de archivos SVG (1.9 MB)
Coleccin de archivos EPS que contienen un elemento por archivo, til para ser importado
en otras aplicaciones (1.1 MB)