Archivo de Categoría «General»

No todos los proyectos en que uno trabaja salen al aire. Unos porque son de carácter privado, otros porque su publicación se dilata demasiado. Y algunos terminan no saliendo. Por esto no deja de ser grato ver un proyecto en el que, junto con un equipo de colaboradores, invertimos tanto tiempo. Se trata del sitio del Banco Central de Chile, que desde hace una semana está al aire.

Las dimensiones del sitio y el hecho de que aún es mantenido a mano, sin un sistema administrador de contenido, hicieron necesarias algunas concesiones para facilitar la actualización y mantenimiento. Es un buen ejercicio poner la teoría a prueba ante condiciones difíciles para dejar de lado algunos dogmatismos. Por lo mismo, mis felicitaciones al equipo del Banco que hace su mejor esfuerzo para mantener el sitio.

Esta es ya el tercer diseño del sitio y me ha tocado participar en los últimos dos. Siempre desde afuera, como proveedor. Una de las cosas interesantes en lo personal es que éste fue el primer sitio en ser publicado con una diagramación basada en CSS en Chile por allá por 2003. Al menos el primero de estas dimensiones y de relevancia pública. Por lo mismo, este rediseño es significativo para mí porque deja atrás un pedazo de historia, la versión anterior del sitio, para adaptarse a las condiciones y necesidades actuales.

Son muy pocas las excepciones en que escribo notas personales en este sitio. Esta no la podía dejar pasar.

Finalmente, acabo de ver el documental Actores Secundarios. El documental narra parte de la historia del movimiento de los estudiantes secundarios que se oponían a la dictadura, con entrevistas a algunos de los protagonistas más visibles. Tras ellos había muchos más.

Cuando se estrenó el 2004 no pude ir a verla al cine. Cuando la pasaron en televisión nunca coincidí con ella. Y cuando la busqué en DVD estaba agotada. Hoy la encontré y la compré. La vi entera y reviví esa época, un tiempo duro y doloroso, horrible. Pero a la vez, paradojalmente, lleno de momentos deliciosos.

Lo he disfrutado porque me permitió recordar una época que viví directamente y de modo incansable. Sin duda una de las experiencias que más me ha marcado en la vida fue la participación en el movimiento secundario durante la dictadura militar en Chile. Desde los 15 a los 17 años fue mi principal motivación y me hizo en gran parte la persona que soy hoy. Los trabajos voluntarios, las marchas, protestas, los compañeros y amigos conocidos y anónimos (en esa época no siempre era seguro conocerse por el nombre real…). No podía dejar de comentarlo.

El sábado pasado tuvimos en Santiago la segunda Desconferencia. La primera versión la organizaron los españoles y fue una muy buena experiencia a juzgar por lo que ellos cuentan. La segunda se organizó en torno a AIChile y se realizó el sábado 22 de julio entre las 9:00 y las 13:30.

En AIChile se habían organizado otras reuniones a las que yo no había podido asistir, por lo tanto conocía a la mayoría sólo por la lista de correo. Fue muy grato ver las caras de los integrantes y quedé muy contento con el resultado de la conversación.

La jornada partió con el sorteo del orden de los participantes y tuve el privilegio de partir con la primera exposición. Me interesaba generar una conversación para poder compartir nuestras experiencias y visiones, así que decidí hablar sobre los wireframes en el contexto de las aplicaciones ricas o RIAs. Este tema ya lo venía tratando desde hace un tiempo y me interesa particularmente desde la perspectiva del proceso de diseño y cómo nos adaptamos a las nuevas condiciones tecnológicas.

El resumen de la conversación lo pueden encontrar en el sitio de la desconferencia, la verdad es que me dediqué a tomar fotos: publiqué una galería con cerca de 80 fotos.

En suma, fue todo un placer conocer a los que no conocía y ver a los antiguos (para no decir viejos) de siempre. Notas destacadas (por mis intereses, obvio, la verdad es que en general todo estuvo notable):

• Camus, excelente presentación, me encantaría escucharte hablar más sobre la escritura para el web
• Javier, quedé con gusto a poco, esperaré el IA Retreat ansiosamente
• Rodrigo, el tema estuvo muy interesante, definitivamente en internet móvil hay todo un mundo

Esperaré ansiosamente la próxima oportunidad, ya hay ofrecimientos muy interesantes como el de Jorge de ser anfitrión en la 5ª región.

Continuando con los bocetos anteriores, provocados por el post de Dani Torres Burriel, y siguendo la respuesta de Javier Cañada, ahora voy con mi kit de trabajo:

El detalle es el siguiente:

• Lápiz goma de vinilo, para borrar detalles
• Lápiz de grafito de 2.0 mm. para trazos gruesos y definitivos
• Lápiz de grafito de 0.5… sólo porque es muy lindo
• Lápices de tinta, puntas de 0.3 y 0.7 mm. para definir trazos
• Lápiz de grafito de 0.7, blando para esbozar
• Lápiz de grafito de 0.7, duro para líneas más finas y limpias
• Goma de borrar de vinilo, para cuando hay que hacer ‘undo’…

Tengo que agregar que se me quedó fuera de la foto un surtido de post-its que siempre resultan útiles tanto para hacer anotaciones como para armar prototipos un poco más elaborados, e incluso realizar diagramas.

Daniel Torres Burriel escribió una apasionada defensa del lápiz y el papel, lo que me motivó a compartir algunas páginas de mis propios bocetos, wireframes e interfaces en su estado más básico: en papel, con grafito, como ideas crudas en proceso de elaboración.

Independientemente del contexto en que se haya dicho, las expresiones de Mike Danseglio, program manager del grupo de Soluciones de Seguridad de Microsoft, son inaceptables:

Social engineering is a very, very effective technique. We have statistics that show significant infection rates for the social engineering malware. Phishing is a major problem because there really is no patch for human stupidity.

[traducción:] La ingeniería social es una técnica muy, muy efectiva. Tenemos estadísticas que muestran tasas de infección significativas para el malware de ingeniería social. Phishing es un problema mayor porque no existen parches para la estupidez humana.

Para ser justos, hay que reconocer el trabajo de equipos como el de Office 2007 y la labor de difusión de profesionales como Jensen Harris, Lead Program Manager del equipo de experiencia de usuario de Microsoft Office, pero lo de parches para la estupidez humana es demasiado.

Los usuarios no se contagian virus o gusanos porque son idiotas, es porque los programas no son lo suficientemente seguros. El compromiso entre usabilidad y seguridad es un problema permanente, pero si un sistema es vulnerado, no se puede culpar al usuario. Eso es pura irresponsabilidad.

Vamos, sé que saldrán ejemplos sobre usuarios incautos o irresponsables, pero no se trata de eso. Esto es sobre no aceptar la responsabilidad propia.

Cuando realizas evaluaciones de usabilidad, frecuentemente observas a usuarios manifestar que no han podido completar una tarea por culpa de ellos mismos. Nosotros sabemos que es por una falla de diseño y no por culpa del usuario. Y por eso estamos en esto, para solucionar esos problemas. Por eso, una afirmación como la de Danseglio es una idiotez monumental.

Tengo un interés especial en el gobierno electrónico y gran parte de mis proyectos se han desarrollado en esa área. Sin duda una de las experiencias más importantes fue participar en la evaluación de usabilidad para trámites en línea del Gobierno chileno durante el año pasado.

En esa oportunidad me hice cargo de la evaluación de 60 trámites de diversos servicios públicos, mediante evaluaciones heurísticas. Aparte de esto se desarrollaron testeos con usuarios y focus groups, aunque en ellos yo no participé.

La evaluación heurística de los sitios fue monstruosa en términos del esfuerzo que requirió:cada sitio fue evaluado tres veces por diferentes evaluadores y luego esas evaluaciones fueron consolidadas en un solo informe. Eso significa que se realizaron 180 evaluaciones en total. Esto no hubiera sido posible sin la ayuda de una herramienta que desarrollé para esa oportunidad. Se trata de una aplicación web que permitió gestionar las evaluaciones a cada uno de los evaluadores, evaluar en línea los trámites, controlar el total de evaluaciones y sus estados y generar informes automatizados, entre otras cosas.

Además de la experiencia directa que este proyecto significó, me dió la posibilidad de tener una visión que normalmente es muy elusiva: el aparato del Estado es una máquina enorme, con muchas dimensiones insospechadas y con un alcance impensable para la mayoría. Me refiero a que como ciudadano, uno normalmente tiene que realizar ciertos trámites, pero está limitado a un grupo muy concreto de tareas. La cantidad de trámites disponibles y la diversidad de ellos es sorprendente. En esto el Gobierno chileno ha realizado una labor de promoción importante. Es cierto que el nivel es aún muy desigual, y que incluso los servicios estrella, como el Servicio de Impuestos Internos, tienen importantes deficiencias de usabilidad. Pero el sólo hecho de haber comenzado con este camino ya es importante.

Pensaba contarles un poco más sobre la experiencia concreta y las observaciones particulares sobre los problemas de usabilidad de los sitios web de gobierno, de hecho inicialmente el título era otro, pero no había tenido oportunidad antes de hablarles de todo el proceso. De todos modos, me comprometo a escribir pronto sobre los problemas de usabilidad más frecuentes en los sitios de gobierno y los detalles de este proyecto en particular.

Aunque para muchos no tiene sentido hacer una distinción entre Diseño de Interacción yDiseño de Interfaces, yo creo que al menos desde la perspectiva de planificación de proyectos, es muy útil separarlos. Además, creo que es relevante tener en claro los límites y responsabilidades de diseño. En la prácica, sabemos que la línea que los separa es difusa, que forman parte de una misma cosa (el diseño de un producto) y que normalmente la misma persona va a tener la responsabilidad del diseño de interacción y del diseño de interfaces, entre otras tareas más. Pero tener una visión abstracta del proceso completo de desarrollo, ayuda a resolver problemas y a tener una visión del proyecto como una unidad.

Entonces, ¿Dónde está la diferencia entre diseño de interacción y diseño de interfaces? ¿Cómo es que dividir aún más ayuda a ver las cosas más unidas?

Enfrentar los problemas de interacción primero desde un nivel más abstracto obliga a pensar en todos los aspectos comunes del proyecto, cómo se resuelven situaciones similares en distintas circunstancias, qué reglas generales aplicaremos. Luego podemos dedicarnos aldetalle de implementar casa cosa por separado.

Hace unos días conversaba se esto con un grupo de alumnos y una forma de explicarles el problema me hizo mucho sentido: en el diálogo que se establece entre un sistema y el usuario, el diseño de interacción es el lenguaje, con su universo de reglas y restricciones y el diseño de interfaces es el vocabulario, con los verbos y términos concretos.

Exactamente esa es la relación, al menos desde mi perspectiva. El diseño de interacción es el diseño de los flujos, metáforas, las reglas y patrones generales. El diseño de interfaces se hace cargo del detalle, de la implementación de las piezas de interacción concretas: un patrón específico, un formulario determinado, con todas las decisiones que eso implica, las etiquetas, etc.

En suma, el diseño de interacción se refiere a lo general y el diseño de interfaces a lo específico. El primero produce diagramas de interacción, flujos y patrones. El segundo wireframes, storyboards y prototipos.

Hace cerca de 12 años comencé a trabajar en multimedia usando Director. Los productos típicos eran presentaciones interactivas, kioskos, y CD-ROMs interactivos. En este tipo de aplicaciones el concepto de página era tan flexible como el de las actuales RIA oaplicaciones ricas para internet. Una pantalla normalmente tenía más de un estado y los contenidos se cargaban directamente modificando sólo una zona sin necesidad de cambiar a otra página. Este es el mismo concepto de interacción de las RIA. Claro, para efectos deinteracción es irrelevante que estés realizando solicitudes asincrónicas al servidor (AJAX), o cargando contenido desde un lector de CD-ROM.

En esa época utilizábamos una herramienta prestada del mundo audiovisual para representar estas interacciones, estados y elementos dinámicos: el storyboard. El storyboard representa las pantallas, y se comentan los aspectos más relevantes, incluso las zonas interactivas o los diferentes estados. Si es necesario, se pueden representar estados especiales en hojas adicionales. En suma, todo se parece mucho a lo que Andrés Zapata presenta en The Guided Wireframe Narrative for Rich Internet Applications.

Andrés muestra una serie de wireframes con comentarios de diversos estados, la idea es flexibilizar los wireframes para adaptarse a los requerimientos de este nuevo contexto, las aplicaciones ricas usando AJAX o Flash. Pues bien, esto es prácticamente un storyboard y no es algo nuevo. De hecho, Andrés menciona en una oportunidad los storyboards, aunque tengo la impresión de que se refiere a su uso en animación.

Explorando con Google, encontré algunos recursos interesantes:

• Storyboarding Multimedia, de 1995
• Detalle de un storyboard simple
• Ejemplo de un storyboard para multimedia

Volveré más adelante sobre esto con algunos ejemplos prácticos, porque creo que será útil reflotar esta herramienta en tiempos de las RIA.