Tzek Blog de Diseño

Después de resistirme y negarme mucho tiempo a entrar a una red social, por fin he cedido. Ya estoy en FaceBook, que no es lo de hoy, pero ha demostrado ser el más popular, junto con Twitter. Como comenta Eduardo de Análisis Gráfico: a ver que sucede.

He creado un grupo de Diseño de Interacción para saber quién hace DIx, qué hace, en dónde, qué nos recomiendan aprender, a quiénes contactar y pasarnos información que nos ayude a todos a “marcar” esta disciplina en “español”. ¡Les invito a unirse al grupo!

PD. ¿Será que ceda ante el Twitter también?

Elías de Isopixel nos comenta el libro llamado “Pensamientos en Diseño de Interacción“ de Jon Kolko y colegas está en línea; un libro que al parecer por ser bueno y publicarse tan sólo 1000, ya está agotado en su versión impresa. La pregunta que me hago, en mi contexto mexicano, es: ¿qué entendemos por diseño de interacción?

Tengo la fortuna de “tener un pie”, en este momento y académicamente hablando, en dos disciplinas del diseño que me apasionan: el diseño de información y el diseño de interacción. Convivir con los alumnos y escuchar lo que piensan es muy enriquecedor. Noto que surgen inquietudes relacionadas con el “qué” (¿qué estoy estudiando?), el “cómo” (¿cómo me vuelvo un verdadero diseñador de esto?) y el “dónde” (¿dónde voy a trabajar cuando egrese?). Y aunque se tengan dudas, no quiere decir que no haya trabajo, ya que en ambas existen actualmente practicantes profesionales mexicanos que hacen diseño de información o de interacción independientemente del título académico.

Sin embargo, me parece que en general aún no queda claro qué puede hacer un diseñador de información y/o interacción que estudió una licenciatura “sólo” en eso; en muchas personas ajenas al “diseño” he notado que la “línea” que separa al diseño gráfico (y lo menciono porque está arraigado en el imaginario colectivo cuando se habla de “diseño”) del diseño de información e incluso del diseño de interacción, simplemente no está clara. Me temo que entre colegas nos pasa igual.

Sólo considerando el diseño de interacción (denotado “DIx”), creo que la comunidad mexicana se encuentra aún muy fragmentada y por ende, no existe una cultura sino ideas que adoptamos de lo visto, escuchado y aprendido por el acceso vía Internet. Incluyo a esto último, no sólo blogs, foros de discusión y libros en línea, sino también hasta la capacidad de comprar libros o establecer contactos vía Twiter, Facebook o por mail.

Por un lado están los académicos/investigadores que en su mayoría son gente del área de cómputo y los cuales representan fuertemente a la comunidad de Interacción Humano-Computadora en México. También están los profesionales (que estudiaron diseño, sistemas computacionales, o quizá no estudiaron “formalmente”) quienes atacan los problemas en sus proyectos con profesionalismo, parcialmente instruidos o referenciando a gente como la anterior pero de nacionalidad no mexicana (como Maeda, Nielsen, Norman, Shredroff o el mismo Kolko del libro mencionado arriba). En adición, se agregan los estudiantes que llevan una materia relacionada aunque no “redondea” en sí a DIx (por ejemplo, de “Interacción Humano-Computadora” como en licenciatura o parte del posgrado) y los estudiantes de una licenciatura en diseño de interacción (que según yo se pueden contar con los dedos de una sola mano en este país). A mi juicio, es importante diferenciar a estos últimos de lo que popularmente se conoce como estudios (de licenciatura) en diseño “interactivo” o diseño “digital”, cuyo enfoque es “usar” la computadora y paquetes de software en vez de las herramientas tradicionales del diseño gráfico (como el aerógrafo).

Quizá esta fragmentación es simplemente el estado inicial de algo. Aquí en México, no creo que existan muchas empresas donde exista gente se preocupe por hacer DIx como “vemos” en la Internet; y cuando “sucede”, o bien corresponde al grupo de diseño de sistemas (computacionales y mecatrónicos) en una empresa de desarrollo de software o es alguien proveniente de alguna disciplina proyectual (es decir, diseño) que está involucrado en algo probablemente diferente al tipo de proyecto de los primeros. Me parece emocionante considerar a otro tipo de profesionistas como psicólogos, antropólogos, lingüistas y una presencia más fuerte del diseño industrial (que por cierto, ahí va aumentando el número de lugares donde se ofrece esta licenciatura fuera de la capital). Lo que sí es cierto es que la disciplina se está consolidando: hace una década no era considerados términos como experiencia de usuario, diseño centrado en el usuario, diseño emocional, ingeniería de usabilidad, design research, design thinking y por supuesto diseño de interacción, entre otros. Quizá en un futuro, sea más claro para las empresas quiénes y qué hacen los egresados de DIx… Por ejemplo, ¿qué no empezaron los computólogos como gente de matemáticas o ingeniería antes de existir los primeros titulados? Creo que los próximos 6 años, cuando hayan egresado ya las 3 primeras generaciones, se verá más claro este asunto.

Pues yo hasta aquí con mis debrayes. Gracias por tomarte el tiempo de leer. Ya sólo dejo un fragmento que está en el libro de Kolko…

El diseño de interacción no es necesariamente la creación de sitios web. No es necesariamente diseño de multimedia o diseño de interfaces gráficas de usuario (GUI, por sus siglas en inglés), y no tiene que estar enfocado primariamente en tecnología avanzada… es la creación de un diálogo entre una persona y un producto, un sistema o un servicio.

El diseño de interacción frecuentemente se confunde con el diseño de sitios web porque la gente interactúa con estos sitios y porque los equipos de desarrollo encuentran valioso tener diseñadores de interacción trabajando con ellos… Mientras los diseñadores de medios interactivos ciertamente deberían tener habilidades en técnicos y métodos descritos en este texto, los medios interactivos están casi siempre centrados en la tecnología más que en los humanos. La mayoría del desarrollo multimedia profesional está restringido a un paquete de software específico y las capacidades asociadas con él, en vez de centrarse alrededor de las restricciones de un usuario final.

Mi amigo Russel, desarrollador en móviles, me pasó la liga en Gizmodo del video que muestra el funcionamiento del T-Mobile G1, una muy bien marcada competencia para el iPhone.

El iPhone establece sin duda una nueva pauta de interacción: la pantalla táctil es lo de hoy, punto. Lo mismo sucedió con el iPod; los demás dispositivos derivan en una “extensión” o mejora a lo que la clickwheel institucionalizó como la mejor forma de interactuar simplista y usablemente con un reproductor de mp3.

El G1 presenta el mismo caso: “hay que derribar a Apple mejorando lo que el iPhone tiene”. Supongo que esta será una ola de varios dispositivos que en un futuro cercano serán tan habituales como tener una interfaz gráfica en el celular y/o al menos la capacidad de enviar mensajes de texto. En este punto, lo interesante a considerar es la posibilidad de que Google derroque a Apple, lo cual tendría como consecuencia que

1. la marca (Apple) se vaya a pique en cuanto a móviles y repercutiría indirectamente con las ventas de los demás equipos, sobretodo si Google desarrollaría pensando en usuarios Windows y 
2. Google indicaría hacia donde sería el estándar de interacción y/en cómputo ubicuo así como la relevancia para el desarrollo de aplicaciones en este tipo de dispositivos. 

En síntesis, ya no vas a querer más una Mac porque Google gobernaría el reino móvil y ¡vamos! en el 2011 (por decirlo así) es igual de importante traer un buen móvil que una “estorbosa” laptop (¡aunque pese 400 gramos!)… la realidad del cómputo ubicuo próximo.

Supongamos que no pase tal cosa y que Apple, con su constante mercadotecnia de brindar lo mínimo a sus usuarios pero lo más fácil de usar y brindar la mejor experiencia (emotiva) de usuario con eso poco, se quedara con el mercado de los móviles… ¿qué va después del touchscreen? Hoy ya se pueden sacudir los iPod nano. Me da el feeling que el siguiente paso, para “extender” la posibilidad del acelerómetro, es la manipulación directa (literalmente)  sobre la interfaz. Esto es, pasar del 2D de la pantalla (con eventos como tocar, dejar en hold el tocar, arrastrar, estirar y pinchar) a un control 3D como podría ser el sumergir los dedos a cierta profundidad (ya sea una pantalla “gelatinosa” o una interfaz similar) y con eso dar más espacio de manipulación.

Que deslumbrante sería que además de estirar o pinchar, dependiendo de qué tanto incrustemos nuestros dedos, hagamos un zoom en 3D. Por ejemplo, para ir avanzando más rapido en la visión de calle de los Google maps.

Sea que lo que sea, aún no volamos en nuestros automóviles y ya estamos prácticamente en el 2009. Sin embargo, sí que la tecnología va marcando la pauta de “lo que se puede hacer”. En contraste, podemos notar que zapatos y ropa siempre serán “los mismos” (la necesidad relacionada no muta o no mutaría mucho más), pero ver que el G1 te permite “moverte” en las calles gracias a su acelerómetro y el Google maps, podría derivar en una gama de necesidades creadas, naturales e incluso heredadas (porque antes “no se podía”), las cuales establecerán nuevas normas de comunicación, trabajo y aspectos culturales en una sociedad “casualmente” consumidora de tecnología.

Peter Cho egresó de la Maestría en Ciencias y Artes para los Medios en el Media Lab del MIT y se enfocó en tipografía que reaccionara en el tiempo (por no decir interactiva). Al igual que Ben Fry, fue uno de los discípulos de John Maeda, cuando existía el Grupo de Computación y Estética en dicho laboratorio. 

Justo acaba de poner un applet hecho en processing (o proce55ing) llamado Wordscapes. No sólo es un catálogo de tipografía del tipo “letra-concepto con dicha letra”, sino que explota bien las ideas de lo que se puede hacer con este lenguaje de programación. 

Acceso directo desde : http://www.typotopo.com/wordscapes/wordscapes.html

Es recomendable darse una vuelta en la sección de Exhibition del portal de processing. Hay cosas muy interesantes.

Justo ahora me dejaron en stand by en el teléfono y lo típico: una melodía suave ochentera mientras esperas… Entonces si no mal recuerdo, en mi tierra natal, Yucatán, uno de los diarios locales (si no es que fue Teléfonos de México mismo) ofrecía “canales” de música en el teléfono… sí, ¡en el teléfono! Marcabas creo que 4141 y después una opción y entonces te ponías a escuchar música.

Quizá ahora parezca tonto. Mucho de esto último porque quién pensaría en escuchar música o noticias en tu teléfono si tienes un celular que podría estar conectado a Internet y que además tiene un player de mp3 o mp4 para que escuches mediante tus audífonos peeeerfectamente todas tus canciones favoritas.

Tonto, efectivamente… pensando que en los 80s y hasta mediados de los 90s, la gente, como suele pasar en algunas ocasiones, se la pasaba hoooooras pegada al teléfono, y no era raro recibir un regaño de algún adulto haciendo hincapié en la enorme cuenta. Es curioso como el paradigma de comunicación y entretenimiento en un sólo dispositivo ha cambiado. Ver una escena de llamada telefónica para “desahogar” el alma ya parece cuento viejo… si no pregúntele a dos niños de primaria con teléfono celular en la mano: ¿para qué quieren un celular? teniendo en cuenta que en su mayoría se envían mensajes de texto y que ya de por sí, se la pasan ahí en la Web navegando.

¿Tonto? O una forma que en su momento trató de innovar y que no sólo quizo explotar el medio, sino también enriquecer la experiencia de usuario con un dispositivo ya dado. No sé, quién sabe que aparezca nuevo con los iPhone, blackberries y otros aparatejos 3G fuera de lo que vemos actualmente.

Tendré en cuenta fijarme en lo que parece estúpido… quizá sea el principio de algo.

Las revistas de chismes del espectáculo son popularmente adictivas. En México existe una gran circulación de este tipo magazines, siendo TV y Novelas una de las más representativas y con más trayectoria. Una característica distintiva de éstas es sin duda la portada, la cual tiene que gritar para llamar la atención de los lectores potenciales. Y que mejor manera de hacerlo con textos en caja alta, colores vibrantes, falta de aire en la composición y enunciados estridentes.

Portada de TV y Novelas

Lo importante tiene que aparecer en la portada. Pero, ¿qué es lo importante? ¿quién lo determina? Quizá a muchos nos cruza por la cabeza la palabra editor y más aún, podríamos determinar que “él decide, él dirige, y punto”.

Si hacemos la analogía con la Web, la portada vendría siendo la página de inicio. ¿Cuáles son las respuestas a las mismas preguntas? El editor o webmaster sería quien determina qué, en qué orden y dónde van las cosas ¿no? Sin embargo, la Web es una de las entidades donde el poder del usuario final tiene más peso para lograr el éxito ¿o no?

Supongamos que el webmaster es en sí el “diseñador web”: el que se encarga no sólo del mantenimiento sino que ha participado tiempo atrás, tanto en la estructura como en el layout. Este caso es fácilmente visible en freelancing o en trabajos donde un equipo pequeño (incluso de una o dos personas) se encarga de un sitio completo.

Pues bien, la premisa del “lado del diseñador” sería “poseo los conocimientos para determinar cómo indentificar la estructura del sitio y la interfaz de este”; ergo, “aquí está el sitio propuesto, úsese”. Sin embargo, existe una contraparte: los stakeholders o las personas interesadas (en el sitio). No estamos hablando del usuario final. Entre estas personas puede estar quien encarga el sitio (contratista), el jefe, un comité que determina qué información se estará presentando, etc. Lo “sabroso” se da cuando la mente (y el ego, por qué no) del diseñador se encuentra con la de los stakeholders para determinar, entre otras cosas, qué incluye y cómo debe ser la página de inicio, la “gran carta de presentación”.

En ese cruce de “aires”, cual formación de tornado, suele darse un “Síndrome de portada TV y Novelas” en el index o página de inicio, el cual corrompe terriblemente la posible propuesta óptima de interfaz web por parte del diseñador. Todo es importante y todo debe resaltar. Claro, las opiniones son muy sesgadas dependiendo del stakeholder en cuestión. Justo ahí es donde entra el grado de influencia de cada uno de ellos; sin embargo, todos quieren tener visible el nicho de información de su interés.

La “homepage TV y Novelas”, le pone al usuario todo a la mano, eso debe ser bueno. Se pueden encontrar banners animados en flash y muchos botones o imágenes por todas partes, textos de gran tamaño, menús desplegables con muchas pero muchas opciones, más de 5 logotipos (por eso de mostrar que el sitio es importante), etc. 

El ying-yang de este asunto puede describirse así: el diseñador web no preparó la estructura (navegacional y visual) del sitio “a prueba de balas” y tampoco se preocupó por sensibilizar a los stakeholders hacia una cultura de la usabilidad y fucionalidad (¿qué queremos con el sitio? ¿para qué servirá?); por otro lado, las personas interesadas sí quitan autoridad al diseñador (aunque se les explique), debido a que lo “importante” es lo importante y tiene que estar en el index, cuanto más opciones, mejor. No se trata de armar “pleito”, ni de ver quién tiene la razón, sino de darse cuenta que un sitio web va más allá de “presentar información”, porque en la mayoría de las veces están ahí para usarse.

¿Y a qué lleva el último punto? La respuesta es simple: cuando los usuarios usan el sitio (valga la redundancia), se topan con una página de inicio saturada, con demasiada información, muchas opciones para seguir navegando y que pobremente responde a sus necesidades. Después, cuando llega la retroalimentación, sobretodo en esas situaciones donde se apremia “la calidad en el servicio”, los stakeholders se dan cuenta que la página de inicio y todo el sitio, están mal.  Como parte de este síndrome entra su desesperación por no quedar mal y demostrar que sí hay aptitud, que se tiene un sitio web bueno, usable y relevante. Es posible que en este punto se recurra de nuevo al diseñador para que “corrija” tales desperfectos.

El síndrome puede evitarse, pero requiere de la participación de los stakeholders y que sepan hasta dónde llega su autoridad, dejando lo pertinente al diseñador web, que en teoría es el experto y sabe lo que conviene pensando en los usuarios del sitio. Lo complicado está que se involucran aspectos emocionales (en particular de egocentrismo) tanto en el diseñador como en las personas interesadas, por lo que “sanar” es más difícil de lo que parece.

El diseñador para ponerse frío, hay que reconocerlo, debe hacer su chamba, documentar en la medida de lo posible (wireframes y blueprints, esquemas y diagramas, todo lo válido para comunicar por qué se hacen las cosas) y ser claro ante los stakeholders sobre lo que se pensó, lo que se tiene, lo que puede ser y lo que se podría hacer. 

¿Complicado o díficil? Sí. Pero es parte del show ¿o no?

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.