Posts etiquetados con ‘Infodiseño’

Maestrías en Diseño de Información en México

Escrito por Tzek el 28/07/08
Clasificado en: Desde la web, Diseño de Información, Tertulias

Recién acabo de notar que existe una Maestría en el Diseño de la Información en la Universidad Anahuac, además de la Maestría en Diseño de Información de la Universidad de las Américas Puebla (UDLAP).

Según leo, en la versión de la Anahuac:

…Desde esta perspectiva, este programa propone el concepto diseño de la información en una acepción que contiene y es contenida por el concepto diseño editorial. Contiene al ámbito del diseño editorial porque su alcance es más amplio: toda la variedad de medios y códigos en los que se materializa la información. Por otro lado, el diseño de la información está implicado en el diseño editorial porque en él se resuelven los elementos básicos del espacio, el texto y la imagen a través de los cuales se reformulan los datos en información y en conocimiento.

Sobre esta base conceptual, este programa ofrece un renovado enfoque pragmático que propone como ejes de la acción del diseño el usuario, la tecnología y la diversidad de los contextos de lectura…

Lo cuál según entiendo va muy pegada con diseño editorial. Por otro lado, la UDLAP presenta su maestría como:

…La función principal del diseño de información consiste en reducir la complejidad cognoscitiva en la masa de informaciones producidas y distribuidas en la sociedad actual, sobre todo en el ámbito de los medios digitales.

Utilizando los recursos visuales y auditivos, el diseñador de información contribuye para transformar datos en información asimilable, comprensible e interpretable.

La tarea profesional del diseñador de información consiste en estructurar, organizar, jerarquizar datos transformándolos en la información visual y auditiva que permite la interactividad entre las personas…

Interesante en ambos casos. Lo bueno es que ahora hay dos opciones y enfoques de cómo tomar el diseño de información en un estudio de posgrado en la república mexicana.

En mi caso, como ya había comentado, me gusta un enfoque plural del diseño de información, que se enfoque en la construcción de mensajes usables y en particular, cuando existe un traslape con el diseño de interacción.

Tutorial de Arquitectura de Información en Webmonkey

Escrito por Tzek el 28/07/08
Clasificado en: Desde la web, Diseño Web, Diseño de Información, Diseño de Interacción, Diseño de Interfaces, Métodos y proceso de diseño, Profesión, tutoriales

A principios de la década, a mi juicio, uno de los mejores recursos para los interesados en el diseño y desarrollo web era Webmonkey, gracias a sus buenos tutoriales y otros artículos. Entre los primeros se encuentra el “Tutorial de Arquitectura de Información Web“.

Si necesitas conocer qué es y cómo se aplica este concepto en un sitio web, te recomiendo echarle un vistazo a este tutorial; su contenido es presentado con claridad, cubriendo los puntos necesarios en forma concisa.

Liga:
http://www.webmonkey.com/tutorial/Information_Architecture_Tutorial

¡Qué bien que Webmonkey está de vuelta! Un portal dónde se aplicaba bien el concepto de que el contenido es el rey. Espero que en esta versión se repita la historia.

Legibilidad de código y documentación

Escrito por Tzek el 26/07/08
Clasificado en: Diseño de Información, Diseño de Interacción, Métodos y proceso de diseño, Profesión, Reflexión, Tertulias, XML/CSS, tutoriales

Justo que vi un comentario de Ixmael en el post sobre mis experiencias en rediseño de logos, me hizo recordar sobre la indentación y documentación al momento de escribir código. 

Con respecto a la indentación, el primer pensamiento que he notado en chavos que aprenden XHTML es Who cares!! Sin embargo, no importa si es XML, CSS, C++, JavaScript o lo que sea, indentar es definitivamente una buena práctica. En mi opinión:

  1. Te permite identificar fácilmente la estructura del código: bloques de procesos y sus sub-procesos internos o estructuración semántica del contenido (en XML o XHTML); lo cual,
  2. fomenta una construcción mental ordenada de lo que estás codificando/escribiendo. Este orden te permite extraer y concentrarte en solo un bloque particular, a groso modo si es el proceso grande o detallado si es un sub-proceso.
  3. Ayuda a descansar al lector en el proceso cognitivo de lectura-entendimiento (cuando no es el autor quien lee).

Con respecto a al punto 3, y esto de descansar o descargar cognitivamente al lector (usuario), pues ¿qué no es válido que exista un “diseño” en el código mismo? Diseñadores: si nos preocupamos en diseño editorial y de información por dar una estructura jerárquica a los textos, ¿por qué no hacerlo en códigos?

Quizá no haya tanta importancia entre

<head>

</head>

<body>

<body>

con

<head>

  </head>

  <body>

  </body>

Pero cuando las cosas comienzan a aumentar como en

<head>

     <title></title>

     <meta ...>

     <meta ...>

     <link ...>

     <script>

         bla bla bla...

     </script>

</head>

<body>

  <div id="hdr">

    <ul id="menu-principal">

        <li></li>

        <li></li>

        <li></li>

    </ul>

  </div>
  <div id="content">

    <div id="col-izq">

        <p> ... </p> 

        <p> ... </p> 

    </div>

    <div id="col-der">

        <p> ... </p> 

        <p> ... </p> 

    </div>

    </div>

    <div id="ftr">

        <p> ... </p>

        <p> ... </p>

    </div>

  </div>

</body>

pues no hay duda que indentar nos da una buena “ayudadita”.

Ya en lenguajes completos (de aplicaciones) o de guiones (scripts), esto de la indentación es un must, sobretodo con esto de que no necesariamente seremos nosotros quienes lean nuestro código. Nunca está demás dejar la sangría necesaria, al menos para marcar cuándo empieza y termina un bloque de código y así:

  • diferenciar entre los grandes chunks de información (clases, métodos y funciones),
  • marcar bien los procesos repetitivos (ciclos for, while y repeat until), o bien, 
  • reconocer qué decisiones se tomarán a partir de ciertas condiciones (por ejemplo en if-then, switch-case o “ifs” anidados).

También está el asunto de estandarizar el cómo codificamos. Es algo bueno de aplicar en la mayor medida de lo posible por la misma razón del párrafo anterior, aunque también nos puede beneficiar a nosotros mismos: en algunos casos si dejamos las cosas enfríar un rato para luego retomar el trabajo, puede ser que ya ni nos acordemos qué es lo que escribimos o dónde nos queamos.

Por ejemplo, si tenemos muchas especificaciones en CSS, pues un

/*Footer*/

nos ayudaría a identificar que de ahí para abajo (hasta otra marca) son cosas que tienen que ver con el contenedor footer. Se que parece tonto, pero en mi caso cuando tengo una hoja de estilo con muchas cosas, ya ni ganas me dan de leerla.

Se ve con mayor claridad este asunto en las rutinas de programación. Por ejemplo, una cabecera ayuda a recordar qué estamos haciendo, o bien, si alguien más nos lee, al menos puede tener una idea de qué hay en el archivo aunque no lea detalladamente nuestro código.

/*****************************************************************

  Nombre: imprime_datos_usuario
  Fecha de creacion: 26-julio-2008
  Autor: Omar Sosa Tzec
  Entradas: strNombreUsr - Nombre del usuario.
            strDireccionUsr - Direccion del usuario.
  Salidas: intStatus - Verificador de que se imprimieron bien los datos en documento.
          1 si estuvo todo bien. 0 si hubo algun error.
  Descripcion: Recibe datos del usuario y entonces verifica que tienen validez consultando la tabla de usuarios validos y de ahi incrustarlos en el documento-mensaje de salida con la variable de estatus.
/*****************************************************************/

También en el manejo de variables, muchas veces resulta conveniente empezar éstas con algún identificador que de antemano nos diga de qué tipo es: un int para las variables enteras, un str para las cadenas, un flt para las flotantes o punto decimal, etc.

A partir de este punto, podemos hacer combinaciones de mayúsculas con minúsculas para nombrar las variables. Por ejemplo, fltResultadoDivision. Para otras palabras reservadas también podemos definir nuestros estándares. Por ejemplo, Persona para la clase persona y Pepe para nombrar un objeto de esta clase.

En CSS por otro lado, si son cosas que tienen que ver con un ID llamado header, por ejemplo, un estándar práctico es quizá ponerle fondo-hdr.gif a su imagen de fondo o en las especificaciones poner .deocor-hdr para llamar a una clase que aplica sólo en este ID.

Sí, ya se: puede ser un verdadero fastidio estar haciendo esto. Tampoco hay que exagerar, y dependiendo de qué estemos haciendo, tomar lo que se nos acomode mejor. Pero sin duda, un poco de estandarización y limpieza de código cae bien, sobretodo cuando se trabaja en equipo.

Tabla periódica de métodos de visualización

Escrito por Tzek el 30/05/08
Clasificado en: Diseño de Información

Encontré está recopilación de métodos de visualización diseñada en forma de tabla periódica de elementos.

Una manera rápida y presentada en forma entretenida para tomar referencias de cómo hacer explicaciones visuales.

 

Observaciones en señales aeroportuarias

Escrito por Tzek el 12/05/08
Clasificado en: Diseño de Información, Diseño y Sociedad, Métodos y proceso de diseño, Profesión

El buen diseño de señales para la navegación en espacios físicos (wayfinding) resulta relevante en lugares con mucho tráfico (de usuarios). El Aeropuerto Internacional de la Ciudad de México (AICM) es un buen ejemplo. Estas son algunas observaciones sobre las señales de este lugar las cuales podrían servir como referencias para cualquier sistema.

Tipografía legible y con buen cuerpo

En el caso del AICM parece ser Helvética en una versión bold (o al menos, seguro del peso 55 de la fuente). De cualquier forma, la tipografía parece tener dos ventajas aparentemente contradictorias: 1. por un lado, es gruesa de forma que se identifica claramente el rectángulo-manchón blanco asociado al texto (obviamente apoyado por el contraste) y 2. Tiene buen diseño de “espacio negativo” con lo cual se puede identificar considerablemente las letras relevantes para armar las frases en nuestra mente, no muy lejos pero sí con mucha anticipación.

Jerarquías visuales y Taxonomías

Una tarea importante de cualquier proyecto de señalización tiene que ver con la elaboración de taxonomías. En sí, es un trabajo involucrado con arquitectura de información, sólo que en espacios físicos. En el AICM lo más básico es derivar el concepto sala, aunque también pueden tenerse otros como salidas y puertas.

Cuando llega el momento de concretar estas taxonomías en o dentro de una señal, claramente hay elementos que son más importantes que otros. En lugares como el AICM esto tiene que ver con la tarea: resulta más relevante para alguien que va apresurado identificar cuál es su sala de espera que saber dónde está el extintor (sobretodo si no hay peligro de fuego). 

Aunque es cierto que una imagen dice más que mil palabras, el texto escrito, tiene un carácter más monosémico, es decir, no hay pierde. Por eso para las salas son empleadas letras como A, B, C, etc. y para cosas “más largas de decir” pero cuya tarea no involucra acciones rápidas (como en el caso del extintor) suelen transformarse en pictogramas.

Además, dentro de todo lo textual, lo más importante, en síntesis, va “más grande”. Por cierto, aquí es donde entra la decisión de cómo casarnos con cierta familia o familias tipográficas; en el caso del AICM, parece que todo está en romana y con el mismo peso, por lo que la jerarquía tiene que ver el tamaño.

Códigos de color y consistencia en layout

Las señales son congruentes en tamaños. Esto da, cual mensaje subliminal, un ancla al usuario de que pre-identifica que está viendo. Por ejemplo, en el AICM las señales “grandotas y pegadas a la pared” tienen que ver con puertas y/o accesos, mientras que las “rectangulares” tienen que ver con la dirección (dar información para moverse hacia un lugar específico). Esta consistencia, no sólo está relacionada con los tamaños sino también con el layout  de la señal misma. La regla básica en el AICM, y en general para la mayoría de los sistemas de señalización, es “información” a la izquierda y “flecha” a la derecha. 

Sin embargo, el proceso de diseño involucra mucho más. Anteriormente me habían pasado la fórmula del tamaño adecuado de una señal. Sería interesante comprobar si las del AICM cumplen con la norma mexicana. Por otro lado, está el manejo del aire o espacio negativo para aumentar o garantizar una buena legibilidad en la señal; las señales del AICM muestran siempre un margen el cual se convierte en una especie de marco, delimitando así la lectura individual de cada elemento. 

Como sucede en muchas señales, las del AICM manejan código de color. Parece una tarea trivial pero es dónde más rápido se pueden cometer errores. En el caso del AICM, el azul marino es el que más problema de contraste tiene sobre las señales de fondo negro pero se apega al estándar de señal para personas con capacidades especiales, sin embargo, la señal no es tan frecuente como las “amarillas” o “verdes” y se apoya de formas blancas causando así un alto contraste para lo importante (lo “de adentro”).

Las señales del AICM como parte de su layout manejan un filete arriba y abajo, estableciendo bloques de señales. Se respeta para cada unidad del bloque el “marco” antes mencionado. Los únicos elementos que no tienen filetes arriba y abajo son las flechas, las cuales en vez de marco, emplean un círculo blanco para romper visualmente con cualquier otro elemento dentro de la señal. Parece no importante, pero el que las fechas no tengan estos filetes hace se vayan a un primer plano, el cual es más notable en las señales “horizontales” y cuando uno está considerablemente lejos; el propósito de la señal en este sentido, es dar una escaneada rápida (sobretodo por los pictogramas) y luego anclar la vista en la flecha, muy útil  cuando se sabe lo que se está buscando y que se encuentra en esa área (por ejemplo, un baño).

Buena implementación

Las señales pueden estar muy bien diseñadas, sin embargo, en la implementación juegan otros factores que contribuyen al éxito de navegación de los usuarios, tales como la forma física de la señal misma, su posición e iluminación.

En cuanto a color, un poco contraste y mayor elegancia, parecen suceder sólo cuando el tamaño lo permite, tal y como sucede en las señales exteriores de la nueva terminal. En el caso de la señal de arriba, de 4×2 metros aproximadamente, el gris no resulta perjudicial como fondo. En la noche, la posición de la señal juega un papel importante ya que si el vinilo no resulta reflejante, ésta debe estar colocada de tal forma que sea iluminada por los carros que pasarán por ella a lo lejos.

En el caso de las señales interiores del AICM, el detalle está en dar a los usuarios (de baja estatura) un confort con el simple hecho de mostrarse inclinadas.

También está la contraparte de cuidar los “oops, no lo había planeado”. Si cuidamos los estándares de tamaño y dónde ponerlos, también hay que tener en cuenta que las señales tienen que ser flexibles porque dar información es más importante. Quizá los espacios cambien o información nueva aparezca, de forma que rompe con lo planeado en el sistema. En el AICM, se me hizo muy curioso notar la señal de la imagen de arriba para luego ir a otra puerta y ver la imagen de abajo.

¿Que habrá sido? Falta de planeación o un exagerado apego a las normas documentadas de forma que a los que implementan no les interesa o bien, no se les da la facultad de tomar decisiones que son necesarias.

Patrones de Diseño de Información

Escrito por Tzek el 11/05/08
Clasificado en: Desde la web, Diseño de Información, Profesión

Gracias a NOlo de los Alquimistas del Diseño por darnos a conocer esta joyita. El resultado de una tesis de maestría, el cual te explica y muestra ejemplos sobre patrones de diseño de información. Si alguna vez, te has puesto a pensar cómo visualizar datos o dar representación fácil de entender a tu información, éste es un buen recurso en línea.

Acceder en: http://niceone.org/infodesign.

Ironman, HCI y algo de infodiseño

Escrito por Tzek el 06/05/08
Clasificado en: Diseño de Información, Diseño de Interacción, Diseño de Interfaces, HCI, Reflexión

Ironman tiene todo para ser una gran película para sentarse a disfrutar con meeeedio kilo de palomitas y un mega vaso de coca-cola. La película está bien fantaseosa pero bueno, de Marvel en la pantalla grande, es una de las que más me ha gustado, incluso más que los X-Men.

Bajita la mano, esta película es una muestra informal de conceptos de diseño de información en interfaces gráficas de usuario (GUI) y su intersección con la disciplina Interacción Humano-Computadora (HCI, por sus siglas en inglés). Para comenzar está Jarvis, parece ser un agente inteligente, capaz de ser ordenado a cumplir tareas específicas tal como decidir qué elementos pintar de rojo en el traje de Ironman. Sin duda, sería el sueño de algunos expertos en la materia poder programar un agente tan complejo por dentro.

En realidad Jarvis no es sólo un agente, ya que no resuelve un problema a la vez, es un sistema multi-agente y más aún, es una especie de servicio ubicuo cuando está “activo” en el traje, que por cierto, éste último puede considerarse toda una wearable computer.

Jarvis posee una característica que lo hace “deseable”… su interfaz. ¡Ah, qué chulada! Para empezar es una interfaz de manipulación directa, lo cual quiere decir que el sistema le da retroalimentación a Stark sobre lo que “mueve”, tal y como sucede en bajo la metáfora de escritorio de Windows.

Sin embargo, con todo el dinero que tiene Ironman, este concepto es llevado a otro nivel, en un concepto estudiado en HCI: la realidad aumentada. En la película, Tony Stark toma su pluma-lapicero y sobre una proyección holográfica va señalando en el aire lo que desea tirar al “bote de basura” en su escritorio 3D.

En cuanto a la “parte visual” de Jarvis, ahí aplican principios de Edward Tufte en el diseño de información que aparecen en su libro Envisioning Information. Este Jarvis presenta a Stark mucha información, no sólo del funcionamiento general del traje sino también del clima y otros… En lo mostrado, existen information chunks que le permiten a Ironman ir viendo por pedacitos varias cosas que le importan, y más aún, el diseño de estos chunks tiene que ver con algo que Tufte llama micro-macro lecturas: Ironman no puede leer todo detalladamente porque tiene pocos segundos, por lo que para cada chunk, debería fijar su vista en lo más importante y por lo cual, su valor visual sería más grande, derivando en un mayor contraste (de forma, color y tipográfico).

También aparece en la película el concepto tufteano de capas y separación, como cuando Popps (interpretada por Gwyneth Paltrow) va navegando la computadora del villano y descubre el prototipo de traje-robot que está haciendo. En general, la película tiene mucho de este concepto con un buen manejo de color para identificar la información.

Un ejemplo, de las narrativas de espacio y tiempo que menciona Tufte, es cuando Ironman va “marcando” de un grupo de personas (villanos que están amenazando con matar a los rehenes que tienen en sus brazos) para luego disparar “balas autodirigidas”.

Pues bien, podría resultar algo muy geek, pero también interesante como “alimento visual” estarse fijando en esos “detallitos” que apoyan a la fantasía de la película. Parece que una GUI que impacta visualmente es sinónimo de avance tecnológico. La ventaja del cine, es que el salto hacia algo tecnológico superior es factible, pero eso no implica que en la vida real no hayan sucedido cambios, sino basta con mirar las interfaces de los aparatos del pasado (radios, automóviles, televisores, licuadoras y demás). Mientras tanto, y en forma continúa, disciplinas como la HCI siguen trazando el camino para alcanzar a la magia del cine.

PD. ¿Y qué dicen del diseño del traje? Super.