Jesse James Garrett: Visual Vocabulary for Information Architecture (Spanish)

Looking for more? My book The Elements of User Experience puts information architecture and interaction design in context for beginners and experts alike. You can now order the book from Amazon.com.

Un vocabulario visual
para describir arquitectura de informaci�n y dise�o de interacci�n

versi�n 1.1b (6 de marzo 2002)

Jesse James Garrett
(contact)

Versi�n original en ingl�s
Traducci�n al castellano por Javier Velasco


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 flechas
  7. Todo de una vez: conjuntos concurrentes
  8. Separ�ndolo: puntos de continuaci�n
  9. Elementos comunes: �reas y �reas iterativas
  10. Componentes re-utilizables: �reas de flujo y referencias
  11. Conceptos b�sicos para elementos condicionales
  12. Haciendo elecciones: puntos de decisi�n
  13. Buscando camino: conectores y flechas condicionales
  14. Elecci�n m�ltiple: ramas condicionales
  15. Elige uno o m�s: selectores condicionales
  16. Una decisi�n, muchos caminos: racimos
  17. Algunas restricciones pueden aplicar: �reas condicionales
  18. Conclusi�n
  19. Librer�as descargbles de formas

Resumen

Los diagramas son una herramienta esencial para comunicar arquitectura de informaci�n y dise�o de interacci�n en equipos de desarrollo Web. Este documento trata las consideraciones en el desarrollo de tales diagramas, delinea una simbolog�a b�sica para diagramar conceptos de arquitectura de informaci�n y dise�o de interacci�n, y entrega gu�as para el uso de estos elementos.

Historia de versiones

1.1b (6 Mar 2002)
Informaci�n sobre soporte incorporado en OmniGraffle 2.0
Nueva librer�a de formas para iGrafx Flowcharter
1.1a (17 Sep 2001)
Nueva librer�as 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
Modificado el elemento flecha para permitir m�ltiples puntas de flecha
Modificado el comportamiento del elemento racimo de tal forma que ahora s�lo aparece flujo abajo desde un selector o rama condicional
Modificado el comportamiento del elemento rama condicional para permitir un resultado nulo
Numerosas mejoras a las librer�as de formas
Nueva librer�a de formas para Adobe InDesign
1.0 (17 Oct 2000)
Publicaci�n inicial

Consideraciones iniciales

Un vocabulario visual es un conjunto de s�mbolos usado para describir algo (usualmente un sistema, estructura o proceso). El vocabulario descrito aqu� puede ser usado por un arquitecto de informaci�n o dise�ador de interacci�n para describir, en un nivel alto, la estructura y/o flujo 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.
  • Dise�adores visuales y de interfaces, los utilizan para derivar una cuenta de cu�ntos dise�os de pagina �nicos deben ser producidos y obtener un sentido inicial de los requerimientos de navegaci�n e interfaz para estos dise�os.
  • Tecnol�gos, los utilizan para derivar requerimientos funcionales.
  • Arquitectos de informaci�n y dise�adores de interfaz los usan para desarrollar requerimientos detallados de navegaci�n e interfaz para cada p�gina.

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 var�a en gran manera del detalle requerido por los otros, y la mayor�a 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 m�s detallados, espec�ficos a las necesidades de cada audiencia.

Otros requerimientos clave de un vocabulario visual para arquitectura de informaci�n y dise�o de interacci�n incluyen:

  • Compatible con pizarra blanca: El vocabulario deber�a ser tan simple que los diagramas puedan ser dibujados r�pidamente a mano. Los elementos del vocabulario debieran ser suficientemente distintos entre s� para que un dibujo medianamente malo no comprometa la claridad del diagrama.
  • Independiente de herramienta: El vocabulario debiera estar dise�ado de forma que no requiera de software especializado para construir diagramas. El vocabulario no debiera favorecer el uso de una herramienta particular de software, sino permitir a los arquitectos utilizar las herramientas m�s c�modas a ellos.
  • Peque�o y auto-contenido: Porque estos diagramas son usados por una amplia gama de audiencias con diferentes niveles de conocimiento (o incluso inter�s) en sistemas de diagramas usados en otras �reas de desarrollo t�cnico, el vocabulario no debiera requerir tal conocimiento o inter�s. El total de los elementos debe ser mantenido al m�nimo posible, manteniendo una estricta relaci�n uno-a-uno entre conceptos y s�mbolos, para que el vocabulario pueda ser aprendido y aplicado en forma r�pida. Los conceptos expresados por el diagrama pueden ser arbitrariamente complejos; el medio de su expresi�n no debe serlo.

Trasfondo conceptual

Arquitectura de informaci�n y dise�o de interacci�n son dos caras de la misma moneda. (Ver "Los Elementos de la Experiencia de Usuario" para definiciones de los t�rminos como son usados aqu�.) Los diagramas de sitios contempor�neos 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 s�lo detalle suficiente 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 espec�fico a nivel de p�gina o micro-estructura, es detallado en otros documentos de los cuales el arquitecto puede no ser directamente responsable de desarrollar.

Cuando describimos arquitectura de informaci�n, el diagrama debiera enfatizar la estructura conceptual y organizaci�n del contenido. N�tese que la estructura conceptual no es lo mismo que la organizaci�n de navegaci�n. El objetivo del diagrama de arquitectura de informaci�n no es entregar una especificaci�n de navegaci�n completa; este detalle es mejor puesto en otros documentos, donde cauce menos riesgo de confundir y distraer.

Cuando describimos dise�o de interacci�n, el diagrama debiera enfatizar c�mo el usuario fluye a trav�s de tareas definidas, y lo que son los pasos discretos en estas tareas. Tal como con la navegaci�n, los detalles de interfaz no debieran aparecer en el diagrama - si te encuentras dibujando botones y campos, probablemente est�s cargando el diagrama con un exceso de detalle.

Este vocabulario est� basado en un modelo conceptual simple abarcando tanto arquitectura de informaci�n como dise�o de interacci�n:

  • Al sistema presenta al usuario caminos.
  • El usuario se mueve a trav�s de estos caminos mediante acciones.
  • Estas acciones entonces causan al sistema a generar resultados.

Elementos simples: paginas, documentos y pilas de �stos

La unidad b�sica de la experiencia de usuario en la Web es por supuesto, la pagina, la cual representamos con un simple rect�ngulo. N�tese que la pagina es una unidad de presentaci�n, no (necesariamente) una unidad de implementaci�n -- una pagina en tu diagrama puede representar m�ltiples archivos HTML (como en una interfaz con frames) o unidades m�ltiples de c�digo (como en includes en el servidor -- SSI -- o una implementaci�n manejada por bases de datos).

Adem�s de paginas, tambi�n hay archivos, parcelas de datos sin propiedades de navegaci�n. 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.

illustration of these concepts
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 id�nticas cuyas propiedades de navegaci�n son inmateriales a la macro-estructura del sitio. Similarmente, una pila de documentos representa un grupo de documentos que reciben tratamiento de navegaci�n id�ntico y pueden ser clasificadas como una entidad �nica (tal como una colecci�n de juegos descargables o una librer�a de manuales de instrucciones en PDF).

Usamos etiquetas en paginas y archivos para identificarlos. �stas no tienen la necesidad de ser una correlaci�n con designaciones como el elemento <TITLE> HTML o nombres de documentos, pero deben ser �nicos para cada p�gina o documento en el diagrama. Identificadores num�ricos �nicos y designaciones de tipo tambi�n entregan una buena forma de llevar el rastro todas las paginas y documentos en tu diagrama.

Creando relaciones: conectores y flechas

Las relaciones entre los elementos son ilustradas mediante l�neas simples o conectores. Estas relaciones conceptuales se traducir�n inevitablemente en relaciones de navegaci�n -- pero no todas las relaciones de navegaci�n aparecer�n en el diagrama.

En el caso de la arquitectura de informaci�n, �stas relaciones est�n com�nmente reflejadas a trav�s de la organizaci�n jer�rquica de paginas en �rboles. Sin embargo, esto de ninguna manera es obligatorio ni (en algunos casos) recomendable.

illustration of these concepts
Figura 2a: [izquierda] Una estructura simple de �rbol
Figura 2b: [derecha] La misma estructura diagramada de forma diferente

Cuando diagramamos dise�o de interacci�n, nuestras l�neas tambi�n deben indicar direcci�n para indicar c�mo el usuario se mover� a trav�s del sistema por una tarea particular. Transformando nuestros conectores en flechas har� el truco de forma limpia. Usamos los t�rminos corriente abajo y corriente arriba para referirnos a la posici�n de los elementos relativa a este movimiento hacia adelante.

N�tese que estas flechas no son como las flechas que indican una calle de un solo sentido, m�s bien son como las flechas que indican el camino hacia el patio de comida en el centro comercial. El usuario no est� impedido de moverse en direcci�n opuesta; la flecha indica solamente la direcci�n en la cual el usuario probablemente querr� ir.

illustration of these concepts
Figura 3a: [arriba izquierda] Flecha indica movimiento corriente abajo hacia el fin de la tarea
Figura 3b: [abajo izquierda] Barra cruzada indica que el movimiento corriente arriba no est� permitido
Figura 3c: [derecha] Flechas m�ltiples clarifican la direcci�n

Si por alguna raz�n queremos prohibir el movimiento corriente arriba (como en los casos donde alguna acci�n irreversible como eliminar un registro ha tomado lugar), usamos una barra cruzada (s�lo una corta l�nea perpendicular) en el extremo opuesto a la punta de la flecha para indicar esto.

En algunos casos, puede ser necesario agregar una punta de flecha adicional cerca de la p�gina corriente arriba para clarificar la direcci�n del flujo en una arquitectura m�s compleja. (Una nota pr�ctica: muchas aplicaciones de diagramaci�n no permiten al usuario encadenar dos flechas de esta manera. Para solucionar esto, las librer�as de formas incluyen un elemento "punto de goma", un elemento invisible que consiste en un punto �nico de conexi�n. Usa este elemento para unir dos flechas.)

Los conectores y flechas tambi�n pueden ser etiquetados, pero el uso de �stas debe ser limitado a casos en los cuales la acci�n tomada por el usuario necesita ser clarificada. 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 aparecer�n como una combinaci�n de n�mero y letra entre par�ntesis. Los n�meros se refieren a la pagina de diagrama en la cual la referencia aparece; las letras se refieren a la nota espec�fica. Por ejemplo, la primera nota en la p�gina 3 de un diagrama deber�a ser referida como (3a), la segunda (3b) y as� en adelante.

illustration of these concepts
Figura 4a: [izquierda] Una etiqueta superflua
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-c�rculo) es usado en casos cuando una acci�n del usuario genera resultados m�ltiples simult�neos (tal como abrir una ventana pop-up mientras una p�gina se carga en la ventana principal, o mostrar una pagina mientras un documento es descargado).

illustration of these concepts
Figura 5: Un conjunto concurrente

Como las flechas, los conjuntos concurrentes tienen direcci�n. Elementos corriente arriba se conectan al lado curvo; elementos corriente abajo se conectan al lado plano.

Separ�ndolo: puntos de continuaci�n

Los arquitectos de informaci�n se encuentran a menudo deseando hojas de papel m�s 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 f�ciles de digerir, usamos puntos de continuaci�n (par�ntesis cuadrado) para unir los vac�os entre las p�ginas.

illustration of these concepts
Figura 6a: [izquierda] Un punto "contin�a hacia" referencia al lector hacia otro diagrama
Figura 6b: [derecha] Un punto "contin�a desde", retomando desde donde salimos de 6a

Un punto de continuaci�n �nico puede listar una o m�s fuentes o destinos seg�n se necesite. La orientaci�n de los corchetes (horizontal y vertical) no tiene significado particular; la elecci�n de orientaci�n es problema del juicio est�tico del arquitecto.

Elementos comunes: �reas y �reas iterativas

El elemento �rea (un rect�ngulo de esquinas redondeadas) es usado para identificar un grupo de paginas que comparten uno o m�s atributos comunes (tales como aparecer en una ventana pop-up, o tener un tratamiento �nico de dise�o). Usa etiquetas para identificar estos atributos o (como con los conectores), haz referencias a notas fuera del documento si tienes mucho que decir.

illustration of these concepts
Figura 7: Un ejemplo de uso de un �rea para representar una ventana pop-up

Muchas arquitecturas incluyen repetir la misma estructura b�sica tal como es aplicada a un n�mero de elementos de informaci�n funcionalmente id�nticos. Por ejemplo, puedes tener un cat�logo de productos en el cual cada producto tiene varias p�ginas asociadas a �l. Podr�as dibujar una instancia de esta estructura para cada producto, pero, �por qu� perder el tiempo? Simplemente usa un �rea iterativa -- una pila de rect�ngulos con esquinas redondeadas -- en vez.

illustration of these concepts
Figura 8: Un ejemplo de uso de un �rea iterativa para representar una estructura repetida en un cat�logo de productos

N�tese que conectores y flechas no apuntan a las �reas mismas. Los elementos de �rea s�lo sirven para encerrar las paginas. Las �reas deben ser aplicadas con cuidado, es muy f�cil pillarse capturando toda clase de detalles con elementos de �rea que no se manifiestan en la experiencia de usuario (tal como qu� p�ginas son alojadas en cu�les servidores) o de otra manera interfieren con el objetivo general del diagrama de comunicar la macro-estructura.

Componentes re-utilizables: �reas de flujo y referencias

Algunos dise�os de interacci�n requieren que una secuencia de pasos (como por ejemplo, un procedimiento de login) aparezca repetidamente en diferentes contextos a trav�s del dise�o. A menudo estas secuencias son meramente un componente de una o m�s tareas que el usuario est� tratando de lograr. (Esto es an�logo al concepto de sub-rutina en programaci�n de ordenadores).

Tal �rea re-utilizable es llamada un flujo, y es representada en el diagrama mediante dos elementos: el �rea de flujo, que encierra el flujo mismo; y la referencia de flujo, que sirve como marcador para el flujo en cada contexto en el cual se repite. Ambos elementos tienen la misma forma b�sica, un rect�ngulo con las esquinas cortadas (o, si prefieres, un oct�gono desfigurado).

illustration of these concepts
Figura 9a: [izquierda] Una referencia de flujo sirve tanto como punto "contin�a hasta", como punto "contin�a desde"
Figura 9b: [derecha] El �rea de flujo referida en 9a

Las �reas de flujo tambi�n requieren el uso de dos tipos de puntos de continuaci�n especiales: puntos de entrada y puntos de salida. �stos son ubicados fuera del �rea de flujo, mientras los puntos de continuaci�n, dentro del �rea de flujo, indican que el flujo abarca m�ltiples diagramas.

Las referencias de flujo en s� mismas funcionan de manera muy similar a los puntos de continuaci�n. El objetivo de ambos tipos de elementos es el mismo: permitir al arquitecto cortar el diagrama en p�ginas. La diferencia es que una referencia de flujo puede ser usada en ambas modalidades; "continua desde" y "continua hasta", mientras que un punto de continuaci�n puede s�lo ser uno � otro. Si no necesitas un elemento que tenga ambos roles, probablemente no necesitas usar un flujo.


Conceptos b�sicos para elementos condicionales

Con cada vez mayor frecuencia, las arquitecturas de informaci�n y dise�os de interacci�n son reformados de manera din�mica por el sistema mientras el usuario se mueve a trav�s del sitio. Esta reformaci�n es lograda mediante l�gica condicional, y los elementos restantes de este vocabulario son espec�ficos a estructuras de l�gica condicional. He aqu� un modelo conceptual b�sico para la aplicaci�n de elementos condicionales:

  • El sistema sigue la pista a uno o m�s atributos, estos atributos pueden ser particulares a:
    • el usuario (tal como el tipo de usuario)
    • la sesi�n (tal como el estado del login)
    • el contenido siendo accedido (tal como materia tem�tica)
    • 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 d�a").
  • La asociaci�n de un atributo con un valor particular es llamada una condici�n.
  • Las condiciones son evaluadas por el sistema para determinar si son verdaderas.

En una arquitectura est�tica, cada camino es presentado a todos los usuarios bajo toda circunstancia, y cada camino conduce al mismo resultado. En una estructura din�mica, el sistema decide cu�les caminos o resultados son presentados al usuario basado en la evaluaci�n de una o m�s condiciones.

Para minimizar la sobrecarga en nuestros diagramas, estas condiciones son t�picamente descritas en una nota al pie o anexo que acompa�a al diagrama.

Haciendo elecciones: puntos de decisi�n

Cuando una acci�n de un usuario puede generar uno de un numero de resultados, el sistema debe tomar una decisi�n acerca de cu�l resultado debe presentar. (Probablemente el ejemplo m�s com�n de esto es manejo de errores en el envi� de formularios.) Llamamos a esto un punto de decisi�n, y como en diagramas de flujo tradicionales, es representado por un diamante.

illustration of these concepts
Figura 10: Un ejemplo de uso de un punto de decisi�n en una secuencia de login

N�tese que las fechas deben ser usadas en conjunto con los puntos de decisi�n, para clarificar si los elementos asociados se encuentra corriente arriba o corriente abajo desde el punto de decisi�n.

Buscando camino: conectores y flechas condicionales

Un conector condicional (representado por una l�nea cortada) es usado cuando un camino puede ser o no ser presentado al usuario dependiendo de si una o m�s condiciones son cumplidas.

illustration of these concepts
Figura 11a: [izquierda] Un conector condicional
Figura 11b: [derecha] Una flecha condicional

Por ejemplo, puede haber una p�gina que contenga informaci�n sensible que s�lo puede ser vista por empleados de la compa��a. La condici�n en este caso ser�a el tipo de usuario (empleado); si la condici�n se cumple, el camino se hace disponible. Si no, no existe camino.

Elecci�n m�ltiple: 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 (tri�ngulo). Los elementos corriente arriba se conectan a un punto del tri�ngulo; los elementos corriente abajo se conectan al lado opuesto.

illustration of these concepts
Figura 12: Una rama condicional

El ejemplo mostrado en la figura 12 se ve muy parecido al ejemplo del punto de decisi�n arriba en la figura 10, pero el comportamiento descrito aqu� es bastante diferente. En el ejemplo del punto de decisi�n, s�lo un camino (o elemento de navegaci�n) era presentado al usuario; d�nde conduc�a al usuario ese elemento depend�a de ciertas condiciones.

En la figura 12, el sistema est� tomando una decisi�n similar, pero sucede antes que la acci�n del usuario. La rama condicional indica que el sistema est� decidiendo cu�l camino ser� presentado al usuario. Los caminos desde la pagina A hacia las p�ginas 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 flechas condicionales, una rama condicional puede entregar al usuario ning�n 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 m�s resultados posibles. Indica si una rama permite un resultado nulo en una nota al pie de p�gina o indicaci�n en un anexo.

Elige uno o m�s: 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 n�mero de caminos que satisfagan las condiciones pueden ser presentados al usuario.

illustration of these concepts
Figura 13: Un selector condicional

La aplicaci�n m�s com�n del selector condicional es en resultados generados por un motor de b�squeda. En este caso, la pagina de resultados de b�squeda aparecer�a corriente abajo desde el selector; la condici�n es el criterio de b�squeda ingresado por el usuario; los caminos corriente abajo llevar�an a las paginas de contenido indexadas por el motor de b�squeda. Tal como con una rama condicional, el selector condicional puede generar un resultado nulo -- de hecho, es mucho m�s com�n con un selector que con una rama.

Una decisi�n, muchos caminos: racimos

Algunas estructuras condicionales requieren que el sistema presente m�s 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.

illustration of these concepts
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 condici�n estamos presentando m�s 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 m�s condiciones aplican a un grupo de p�ginas, esas p�ginas son encerradas en un �rea condicional -- un rect�ngulo de esquinas redondeadas, pero con un tratamiento de l�nea cortada como el conector condicional.

illustration of these concepts
Figura 15: Un ejemplo de uso de un �rea condicional donde se requiere una conexi�n segura

Las �reas condicionales se usan com�nmente en situaciones que involucran permisos de acceso, como cuando se requiere un login o conexi�n 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) condici�n(es) no son satisfechas.


Conclusi�n

Si deseas ver c�mo se arma el sistema completo, aqu� hay un diagrama de muestra de la arquitectura de informaci�n y dise�o de interacci�n de MetaFilter. (No estuve involucrado en el desarrollo de este sitio; este diagrama fue desarrollado a partir del sitio.)

Scott Larson cre� esta pr�ctica hoja de trucos para una referencia r�pida a los varios elementos condicionales. Y para aquellos interesados en crear sus propias librer�as de formas para usar en una aplicaci�n 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 s�lo un primer paso. A medida que la arquitectura de informaci�n y dise�o de interacci�n contin�an su evoluci�n, aparecer�n situaciones que este vocabulario no abarca. Tu retroalimentaci�n y recomendaciones para la pr�xima versi�n de este vocabulario son bienvenidas.

Librer�as descargbles de formas

OmniGraffle 2.0 es la primera aplicaci�n en despacharse con soporte incorporado para el vocabulario visual. OmniGraffle viene actualmente pre-instalado en todos los Apple Power Mac y PowerBook. Tambien puede ser dascargado desde el sitio Omni.

Otras librer�as de formas disponibles: