Tzek Blog de Diseño

Aunque el post que recién escribió Armando Sosa se llama “Cuando los estándares nos alcancen“, en sí puede tomarse como una reflexión, aunque personal, sobre la interacción, servicios y tecnología que tenemos hoy y sus implicaciones en el mañana. 

Muy ameno, espero puedan darse una vuelta para leerlo.

Por cierto, Sosa estará en un congreso llamado Mexico Web 2.0, donde vienen autoridades-practicantes del desarrollo web, estándares y servicios 2.0. 

Casi me voy de espaldas cuando leí el título que puso Elías en Isopixel: Razones por las que NO hacer un mockup con photoshop para un trabajo web. De la traducción libre que está en blog tomé los siguientes puntos:

1. Photoshop limita completamente el trabajo, no se pueden incluir enlaces, áreas “clicables” o menús. Con el papel pasa lo mismo. Lo ideal es [añadido por mi] primero hacer un planteamiento muy básico sobre el papel [/añadido por mi] y luego pasarlo a CSS/XHTML, donde representaremos lo que se hizo en papel más resto de funciones básicas como navegación, enlaces etc.

• Si estamos hablando de una maqueta o mockup, ya desde el papel y lápiz, es buena herramienta. La idea está en maquetar el sitio, hacer una disposición de los elementos, es el pensar cómo quedarían. Justo cómo ha mencionado un alumno de Javier Cañada dentro del programa Vostok. Lo que sí, viendo una maqueta como prototipo de baja fidelidad, en Photshop es posible concentrarse en los detalles visuales, esto es, enfocarse mucho en la forma. Aunque es tardado, su ventaja podría ser el dar una mayor calidad final en el prototipo a diferencia de tomar lápiz y papel. No hay que olvidar que en el prototipeo lo relevante es obtener, de ser posible, resultados sobre aspectos de usabilidad; ahí el photoshop es un arma de dos filos, es más fácil para este caso optar por lápiz y papel o un wireframe simple. No importa si se puede “cliquear”.

2. Photoshop proporciona muchas herramientas para conseguir detalles y justamente buscamos lo contrario, no queremos dar detalles concretos, solamente lo esencial. El programa nos distraerá en cosas que ahora no tocan hacer.

• Efectivamente, pero justo se repite mi apreciación en el primer punto. ¿Qué tipo de calidad se requiere en el prototipo y con qué propósito se está realizando? Un detalle curioso es que si el proyecto lo amerita, un prototipo simple con CSS no puede competir con uno visualmente más preciso (de preferencia con una versión más simple en papel o wireframe ya evaluada).

3. La fuente de un sitio forma parte imprescindible y es muy probable que necesites cambiarla varias veces. Photoshop hace más complicado este proceso: abrir el .psd, seleccionar la fuente del lugar concreto que queremos cambiar, cambiarla, exportar a .png .jpg para poder enseñar los cambios a, por ejemplo, un cliente etc. Además de queen photoshop las letras NUNCA se comportan igual que en la web, a pesar de darle la misma fuente con las mismas características en el programa se ve de una forma y en la web de otra [añadido por mi] (nunca entendí porque pasa esto) [/añadido por mi].

• Con respecto a la fuente, es claro que no todos los textos pueden ser arbitrarios, esto es, utilizar la fuente que quiera y luego pasarlo a imagen. Vale para ciertos encabezados y es obvio que hay que tomar en cuenta qué tanta sustitución con imagen habrá de hacerse en los textos y por qué sería conveniente tomar este tipo de decisiones. Para los textos “comunes”, esas cosas no se pueden probar mejor que con texto “en vivo”, que se está viendo en el browser y eso sí tiene que hacerse con CSS (referente a familia tipográfica, puntaje, interlineado y variantes).

4. Photoshop se enfoca en la producción y no en la productividad. En este primer paso se busca conseguir los puntos esenciales para crear un sitio accesible, claro etc. Luego nos preocuparemos de darle un aspecto “bonito”.

• Eso no lo voy a negar. Si se maqueta en photoshop, cuestiones accesibilidad, navegación y usabilidad tienen que tenerse en la cabeza “en segundo plano” (como en cómputo, un proceso corriendo ahí atrás) mientras se diseña. Esto implica que no importa tanto la herramienta (photoshop o lápiz de papel) sino la integración de los conocimientos sobre diseño visual, diseño web, diseño de información, arquitectura de información, accesibilidad y usabilidad. Insisto, ¿para qué va a servir el prototipo o maqueta en cuestión?

5. Perderemos tiempo en pasar el mockup de photoshop a css/html.

• Otra gran verdad. Llego a una conclusión rápida que este es un vicio, el cual tengo y esto casi seguro que tienen muchos que empezaron con esto de la web en los 90s cuando el ensamble de las interfaces venía en forma de tablas. Lo que creo que este punto puede ser evidente dependiendo de tu forma de “aprender web”; si desde el principio rompes con la maquetación en photoshop y te acostumbras a hacer “drafts” a partir de una lógica-de-ensamble vía CSS/HTML, entonces tu perspectiva/proceso sobre cómo ir diseñando, definitivamente cambia. La estructura mental para esta tarea cambia. Al comenzar a hacer la “integración” que menciono arriba con una maqueta hecha en photoshop, los tropiezos te enseñan a discernir cuáles áreas “no deben o tienen por qué tocarse”. Pero sí es interesante ver como el cambio en el paradigma de diseño web en cosas que a gente más reciente en estos rollos (post-liberación-de-las-tablas) hace que tengan soluciones creativas que pueden pasar por obvias para ellos.

6. Con html/css podremos seguir un flujo de trabajo mucho más productivo: Hacemos el cambio, guardamos y refrescamos.

• Esto está relacionado con el punto anterior. En ese sentido, estoy de acuerdo. Aunque una vez pasada la migración de photoshop, esas áreas “intocables” tienen que trabajarse siempre como se plantea en este punto.

7. Photoshop es poco práctico, aunque lo manejes desde hace mucho tiempo, es complicado hacer las cosas de forma simple.

• Si es el caso de un prototipo visualmente complejo, es tardado, pero no creo que ese sea el punto general de estos siete, sino identificar quién implica a quién, si photoshop luego CSS/XHTML o primero CSS/XHTML luego CSS. Sí son dos formas de pensar/diseñar diferentes. Y también hay que recordar el contexto, el usuario y el cliente. Mis comentarios van enfocados a sitios web “usables” por no decir cuasiplanos visualmente, no tanto a esos “interactivos” ganadores de premios y llenos de factores de diseño emocional y metáforas navegacionales rebuscadas. De una u otra forma, concuerdo en que hay que obtener un equilibrio.

Y la razón por la que casi me voy de espaldas, es porque, usualmente tengo que “concretar visualmente” una maqueta en photoshop, justo como estoy diseñando algo de web en estos días. Aunque, admito que en momentos de frustración, sobre todo por el trabajo “talachero” de pasar de PSD al ensamble CSS/XHTML donde a veces suele suceder que no queda justo como “habías pensado”. Un debate interesante el asunto.

PD. Ya está el foro de discusión en Isopixel al respecto.

Actualización.

CyberGus nos comparte también su opinión sobre este tema, con comentarios bien enfocados. 

En más de una ocasión he presenciado algo que estoy seguro que a muchos-muchos nos ha pasado, tener una mac y conectarla a un cañón y darte cuenta que no se ve lo mismo en tu monitor que en la “pantalla” (o donde estés proyectando la señal)… le mueves al F7 y nada. Le cambias la resolución y nada. ¿Qué hacer?

Arriba está la ventana que me sale en la parte de Displays en las Preferencias del Sistema. Mac muy inteligentemente y por qué no decirlo, usablemente, no te muestra más de lo necesario. Desafortunadamente no tengo un cañón a la mano, pero bendito Google, directo desde Synaptic Burn, hay una pantalla que muestra como queda cuando le conectas un cañón.

Por cierto, el post de Synaptic Burn, trata prácticamente de este tema. Entonces para que puedas ver “lo mismo” tanto en el cañón como en el monitor de tu mac, solo debes de activar la casilla que dice “Mirror Displays”. ¡Listo!

Mac es amigable. Ok, puede ser. ¿Usable? Pues sí, si es amigable debe ser usable, ¿no es así? Pero que sucede en la vida real, o al menos de lo que he visto en congresos, presentaciones de clase y exámenes de grado…

Nadie lee la interfaz. No ven lo de “Mirror Displays”.

Entonces, ¿no que Mac es usable/amigable? o ¿simplemente esto es un error de usuario? Ante este caso, no es complicado deducir que

1. La pantalla pierde consistencia en el aumento de opciones. Aunque parezca tonto, pasar de “Display-Color” a “Display-Arragement-Color-Options” te “cambia la jugada”.

Ya sea que seamos un usuario nuevo en mac o que estemos histéricos porque presentamos la tesis en 10 minutos, nunca he presenciado a alguien que diga: a ver, uno por uno, cómo le hago para ver mi monitor… mmm… según recuerdo en Windows tiene que ver con la resolución… a ver, a ver… resolución, dónde esta.

Y curioso, un efecto de labeling es la posible confusión sobre lo que significa “Options” cuando las otras tres también son opciones. Ante este problema, será que la solución está en las “Opciones”…??? Es un razonamiento válido.

2. No es lo mismo disponer de un diseño centrado en la meta que uno centrado en la tarea y además, pensar en un diseño centrado en el usuario.

¿Cuántas personas recurren de un técnico cuando se enfrentan al problema del cañón? Es más fácil decir: hey, tu, el que usa mac. Ven, ayúdame.

Por otro lado, no he visto que alguien le mueva al “Arragement”, al “Color” o a las “Options”. Parece que la meta es “enchufar la lap y que se vea lo mismo en ambas salidas”, la tarea particular es “que se vea lo mismo en las dos pantallas”… las demás tareas o cosas que haga la sección de “Displays” parecen no importar. Entonces ¿por qué no dar énfasis a este hecho, si realmente hay un diseño centrado en el usuario amigable/usable?

Sería práctico que ya que la Mac se encarga del auto-detect de nuevos displays o salidas de video como el cañón, saque de paso un mensaje de este tipo.

O más aún, que aproveche una de sus características de interfaz de las preferencias de sistema, como puede ser la iluminación sobre la opción buscada.

El ejemplo anterior es un claro ejemplo de lo que en diseño se llama Designing the Calm Technology. Pasar lo más importante al “centro” y dejar lo demás en la “perifieria”. Tan simple solución de diseño como un sombreado que de el efecto de iluminación sobre lo importante.

¿Es o no es usable la interfaz de la Mac?

El asunto no ese. Mac posee una interfaz altamente usable/amigable con aparentes eye-candys que cuando nos fijamos en otros sistemas operativos, podemos ver que son visual cues más que adornitos. Aquí la cuestión es que la visión de los diseñadores no se ajusta a los usuarios en contextos como los mencionados arriba.

No es un problema de usabilidad, es un problema de cómo el usuario recibe el mensaje que manda el diseñador sobre cómo interactuar con el sistema… esto es, un problema de comunicabilidad, el cual proviene de una nueva teoría de Interacción Humano-Computadora (HCI) llamada Ingeniería Semiótica y que se enfoca en la semiosis. El diseñador, posterior al entendimiento del usuario, tiene una idea de que necesita este último para cumplir su tarea con éxito, en este caso que se vea lo mismo cuando se enchufa el cañón, y aunque no se puede meter uno a la cabeza del usuario, sí existen técnicas para detectar rupturas en la comunicabilidad y así mejorar la interfaz, que en este ejemplo ya funciona bien de por sí pero causa conflictos graves.

Entonces… no todo es usabilidad.

Como diseñadores de información, interacción o de interfaces en general empleamos términos como usabilidad o accesibilidad. No dudo que demos importancia a estos aspectos y consideremos que sí los aplicamos como parte de nuestros diseños, ¿pero realmente son parte de nuestro proceso? ¿estamos sensibles a ellos? Por ejemplo, diseñamos sitios web “para nuestros ojos” como diría Costa, en este caso, nuestros ojos occidentales. ¿Qué pasaría si te pidieran el diseñar la misma información también para Arabia Saudita? ¿Sería diferente el proceso? ¿Seguro? ¿Podrías afirmar por qué?

El experimento va así: entrar al sitio de la KAUST, darle una escaneada rápida al homepage y de ahí identificar qué fue relevante para nuestros ojos. Ahora, buscar la opción “en árabe”. ¿cómo se siente ese cambio? Podemos regresar y repetir la operación un par de veces… ¿se siente raro? ¿no normal? ¿se te ha cruzado en la cabeza términos como “curioso” o “por qué hacen X o Y cosa? Página de inicio de KAUST, versión occidental:

Página de inicio de Kaust, versión árabe:

Acercamiento de esta página:

• Como diseñadores de identidad, ¿podrías decir por qué es relevante que primero se lea la marca en extenso y luego el imagotipo? ¿que no da igual poner KAUST y luego el nombre largo? Si observamos la versión en árabe, no crea mayo conflicto, al contrario, entiendes KAUST y te quedas entonces con esa marca en la cabeza, aunque no sepamos bien que significa.
• Lo mismo sucede con la foto de del profesor. Si estuviéramos diseñando un portal similar, ¿por qué es importante que aparezca la foto primero? ¿estamos conscientes de por qué tomamos ese tipo de decisiones?
• ¿El menú debe ir a la derecha o a la izquierda? En los sitios web actuales, fuera de nuestra “occidentalidad” de leer de izquierda a derecha y de arriba hacia abajo, encontramos menús del lado derecho o izquierdo. En este caso el “What’s KAUST?” es quien determina la prioridad de lectura de este chunk de información… ¿cuántas veces sabemos que priorizamos contenido en sitios web de forma adecuada? Si fuera un menú común y corriente, da igual que sea derecha o izquierda..?

Parece que pasar de español a árabe consiste en un “flipeo” del layout… Ok. Puede ser. Pero si vemos el sitio en árabe, ¿no es curioso como rompe con nuestra “normalidad” de cómo diseñar para occidente? 

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.

Se abre la convocatoria para la recepción de trabajos en el taller de HCI en México. Participan, computólogos e ingenieros (en cómputo o sistemas), diseñadores, psicólogos, etnógrafos y cualquier profesionista relacionado con el estudio de los usuarios y su interacción con dispositivos/interfaces computacionales. 

El taller será dentro del Encuentro Mexicano de Computación 2008, uno de los congresos más importantes de cómputo en México. Los trabajos aceptados serán publicados en las memorias de dicho congreso bajo la edición de la IEEE. La sede será la Universidad Autónoma de Baja California, Campus Mexicali.

La ventaja de participar como diseñador es el cruzar la frontera entre lo clásico, el enfoque de cómputo y sistemas, por lo actual, los estudios cualitativos (y la investigación secundaria en general) que inciden en el conocimiento general de la disciplina y la creación de productos (de diseño) innovadores.

Hay tres modalidades para participar

• Poster. Una página.
• Ponencia corta. 2 a 4 páginas.
• Ponencia extendida. 5 a 8 páginas.

La fecha límite para el envío de trabajos es el 30 de mayo del presente.

• Descargar convocatoria en PDF (48 KB).

Para la gente de las disciplinas proyectuales es una gran oportunidad para involucrarse con la comunidad científica y tener una publicación oficial, lo cual curricularmente es muy bueno; además del enfoque fresco que pueden aportar.

Mayor información en el sitio oficial del taller: www.mexihc.org.

Hace 101 posts, había comentado sobre cómo en un concierto de 30-añeros o más, se acercaba la gente con los celulares para captar a los cantantes y tener así recuerdos. El fin de semana pasado asistí al concierto de PXNDX (se lee Panda, y sí, sí los escucho… plop. Nooo, no soy emo). En esta ocasión, el concierto estaba lleno de mocosos (como llamamos en México a los adolescentes y sí… ya sé, contrastaba un poco).

En cuanto a la tecnología fue lo mismo, pero en mayor escala. Muchos tenían a la mano un celular y en esta ocasión hasta vi cámaras fotográficas para ser empleadas como videocámaras. La tecnología funciona, en cuanto a experiencias de este tipo, como una extensión de la memoria, no hay duda. ¿Pero será que tecnología remplace un concierto real con uno virtual?

En el Mundo Feliz de Aldous Huxley, la gente que iba a conciertos podía “oler” los sonidos del evento que presenciaba. Después apareció el enfoque de cómo la tecnología te hacía entrar a la realidad virtual, enfoque aun manejado en programas como Futurama.

El estar chavo y gritar, echar desmadre, y hacerle coros a tus ídolos mientras los ves sudando por el calor, es algo que la tecnología tendría que reemplazar por prácticamente lo mismo. El diseño de experiencias y la tecnología para llegar a ese punto, aún están en pañales. Sin embargo, la tecnología sigue ahí y por tanto nuevas necesidades van surgiendo; no tendrán que ser las mega-wow, pero sí las que apoyen o se integren como parte de esta socialización y cultura de lo online.

Me qudé con algunas ideas después de vivir la experiencia… Si todos estos chavos tienen celular, por qué no usarlos como camarógrafos para un broadcasting en vivo. Por ejemplo, tiempo aire brindado por youTube, de forma que pueda mandarse su video a la base de datos en casi tiempo real (chance y esto jale con los G3, pero desconozco bien qué puedo hacer con un celular de esta generación).

O bien, que ahora que está de moda el Twitter, el celular (si no es que ya lo hace) tenga una especie de interfaz extendida de Twitter, que en realidad implique la generación de metadatos, los cuales son muy valiosos para algoritmos de recuperación de información o bien para el análisis tendencias y mercadotecnia hacia los mismos asistentes al concierto.

Creo en la juventud para este tipo de aplicaciones porque a diferencia de la gente mayor, los chavos, en la adrenalina y emoción de mostrarse asi mismos al mundo, y de aquello con lo que se identifican, harían uso de sus celulares (o cualquier dispositivo de conexión móvil conectado a una red inalámbrica)… en cierto punto, para la juventud, un video es relevante, pero compartir experiencias, ya no queda impreso en un papel glosy y a pesar de que se diga que los chavos emplean un lenguaje más degenerado, necesitan nuevos medios de expresión no necesariamente tangibles.

Por cierto, si no sabes quién es Pxndx, aquí dejo dos videos..

En el Tech Beat del Business Week está un artículo sobre el Apple Design Process según explicó Michael Lopp, administrador de ingeniería senior. Cuatro puntos de esa charla según hace Apple son:

1.  Mockups o maquetas (prototipos) perfectas (en pixel). Aunque lleva mucho tiempo, elimina cualquier ambigüedad según Lopp.
2. 10 a 3 y luego a 1. Para cualquier cosa que se esté tratando, los diseñadores de apple presentan 10 maquetas sin restricciones, luego se consideran las mejores 3, se vuelve a trabajar unos meses más sobre ellas y al final se quedan con la más fuerte.
3. Juntas de colegas diseñadores. Cada semana, los equipos de trabajo tienen dos juntas, una donde pueden “alocarse” creativamente y luego otra donde diseñadores  e ingenieros van aterrizando las cosas con lo que se puede hacer o no.
4. Junta de Poni. Es la que toma en cuenta la opinión de los mandos, que en general quieren cosas, y piden tanto como si quisieran hasta un poni. De ahí el nombre. Entonces hay que tomar en cuenta las ideas de estas personas y emparejarlas con la de los diseñadores.

Ok… creo que tengo todo. Ah no…solo me faltan grandes presupuestos en millones de dólares, mucha gente en friega trabajando, unos 1000 hindúes programando y 1 año. Jum. 

La ley de Fitt es qué tan precisamente puede alcanzarse un objeto dependiendo de su tamaño y lejanía.Esto hay que tenerlo en cuenta cuando hay que mostrar elementos de un grupo en una interfaz, cosas que estén relacionadas. En la página de Mac, la barra de navegación global y los “anuncios” principales se identifican claramente como grupos.

El hecho de que los botones de la barra estén “pegaditos”, ayuda a llegar más rápido a la opción que se desea, ya que con un movimiento horizontal rápido del mouse, de izquierda a derecha, va uno pasando de botón en botón, pero además basta estar en el primer pixel de un botón para ya poder hacerle clic… así, el tiempo de acceso es corto y la facilidad de manipular el botón es alta.Caso contrario si la página se viera como sigue.

Entonces, en el diseño web y de interfaces en general, hay que saber qué agrupar, hacer chunks de información y que aquellas cosas que sean manipulables y necesarias para hacer algo (completar una tarea) no estén muy separadas o muy chicas. Hay que pensar en cómo el usuario podría hacer el recorrido visual y de ahí ver dónde y cómo colocar los elementos de interfaz. Otros buenos ejemplos:

Marcin Wichary de la Vrije Universiteit nos ofrece un interactivo con experimentos muy bueno y hecho en flash.

Buscando información sobre Interacción Humano Computadora (HCI por sus siglas en inglés) en la web, me topé con una empresa que se especializa en esta disciplina, en particular con la siguiente imagen:

Esto me reafirma la idea de por qué la Maestría en Diseño de Información de la UDLA tenía de entre los ingenieros que estábamos en la generación, al menos a 3 que nos interesa la HCI. De hecho, una amiga mía de la generación me comentó que viniendo de ingeniería (ella es Ing. en Sistemas Computacionales) la MDI era “lo más cercano” para continuar tu formación hacia HCI.

El punto al que quiero llegar, es que este dibujito me recordó la frase “diseñar para diseñadores” (muy popular en los concursos de diseño) y que estando en cómputo, parece que si uno no se mete a esto de lo transdisciplinario, la HCI podría resultar muy “sintética”, esto es: “HCI de computólogos para computólogos”. ¿Será? Estoy bien “moco” en HCI pero me da curiosidad.

Sumado a lo anterior, creo que el diseñador también va por ahí, sobretodo los diseñadores de interacción (obvio), de experiencia y de información. A ver que sucede….

Apéndice:

En la MDI llevé muchas materias que si no son la “burbujita de arriba” al menos tenían que ver con alguna…* 

•  Psicología: Llevé una materia de psicología cognitiva. Los de cómputo no llevan cursos de este estilo… Se habló de percepción y eso ayuda mucho en el diseño de interfaces. También llevé en otro curso temas de psicología social, muy enfocados a estudios de género, que me resultaron interesantes aunque aun no me queda clara la conexión con HCI (o aplicarlo a diseño de interfaces).
• Ergonomía y factores humanos: Mmm… creo que esos temas corresponderían a los cursos que tuve de psicología, tipografía y texto, diseño de interfaces y psicología. 
• Ingeniería: Ahí dependía de cada quien… habíamos en mi generación dos ingenieros industriales**, dos ingenieros en sistemas y yo de computólogo.
• Diseño: Ahí si… si no todos los cursos, el 99% se traslapaba con el diseño.
• Semiótica y branding: Tuve un curso de semiótica y uno de retórica… como me encantan esas materias. Aunque admito que leer a veces sobre ellas es un zzzzzz…
• Etnografía: En mi clase de proyectos y en la clase donde tocamos temas de psicología social.
• Sociología: Tuve una clase de sociología, aunque enfocada a la comunicación… Pero tuve un curso de sociología ¡que raro siendo computólogo! Junto con mi curso de comunicación (muy bueno) te dan un enfoque social de la comunicación, hegemonía, estrategias, etc.
• Lenguaje: Mi curso de teoría del texto… definitivamente. Y de hecho, los 3 interesados en HCI tomamos un taller en el CLIHC 2005 donde se explicaba la semiótica, narrativa y estructuras textuales de una interfaz…. que chistoso, hasta ahí nos dimos cuenta que no andábamos tan errados en el camino.
• Ciencias de la computación: Pues también… eso de la carrera.

 Notas:

* Obviamente, esta es una perspectiva personal sobre lo que he visto, medio aprendido y medio razonado (ahí vamos poco a poco con estos rollos). Y cual disclaimer, no refleja los intereses de nadie en la MDI, ni de mis profes ni de mis compañeros de clase y además el plan de estudios actualmente es otro.

** Me encanta como los Ingenieros Industriales ven y desean aplicar el diseño de información: mucho de cómo estructurar datos y luego como presentar la información resultante y que esta sirva como herramienta de análisis y toma de decisiones.