Un año más

30 diciembre, 2013. Autor: Yusef Hassan.

Termina un año en el que he intentado, una vez más, mantener vivo este viejo blog maltratado por google. Entre las entradas publicadas destacaría las dedicadas a innovación y experiencia de usuario o a big data.

Ha sido un año en el que también he publicado pequeños textos en otros medios. Hablaba sobre investigación con usuarios en hipertext, sobre sesgos metodológicos en pruebas con usuarios en el blog UXed, acerca de la evolución del sector UX en PuroMarketing, o del coste de hacer una web usable en la guía de nuevas profesiones INKS 2013 (pdf).

También he tenido tiempo de publicar textos más desarrollados, junto a Sergio Ortega, como una introducción a la interacción persona-ordenador en el libro Pioneros y Hacedores, o un análisis de los sitios web universitarios españoles (pdf) en la revista Perspectivas em Ciência da Informação.

En cuanto a conferencias, además de trabajar codo con codo junto a Sergio, Sergi y César en la organización de UX Spain, he tenido tiempo para dar una charla sobre diseño de información cuantitativa en Bogotá, organizada por Usarte, o para hablar sobre experiencia de usuario en el primer Hackathon EBE-Betabeers.

Entre los propósitos de año nuevo están presentaros un pequeño proyecto personal en el que estoy trabajando, introducir algunas novedades en No Solo Usabilidad, o hablar más acerca de algunos proyectos de visualización de información que estoy desarrollando junto a Scimago Lab.

Interfaz de Usuario

3 diciembre, 2013. Autor: Yusef Hassan.

Hace no demasiado se hizo bastante popular un artículo de Erik Flowers titulado UX is not UI. En mi opinión la interfaz de usuario es un concepto al que le damos menos valor del que merece y un sentido excesivamente restringido.

La interfaz de usuario es el punto de encuentro entre usuario y producto, la superficie donde la interacción tiene lugar; un concepto muy flexible pero que solemos limitar a cuestiones de layout y diseño gráfico, tratándolo como simple abreviatura de interfaz gráfica de usuario.

Las interfaces de usuario no tienen por qué ser gráficas, y aún siéndolo no solo abarcarían aquello que se ve en pantalla, sino también su comportamiento o los dispositivos que utilizamos como medio de interacción.

En una línea similar a lo que dice Ryan Singer, yo veo la interfaz de usuario como aquello que hacemos, y la experiencia de usuario como el resultado y objetivo perseguido. Diseñamos interfaces de usuario con la mirada puesta en cómo serán experimentadas.

Esto no es nada nuevo. No seré el primero en entender como más preciso hablar de diseñar para la experiencia de usuario que de diseñar la propia experiencia de usuario.

El diseño de servicios parece tener su propio metalenguaje. Quizá en lugar de touchpoints podríamos hablar igualmente de interfaces de usuario, esta vez no como puntos y espacios de contacto entre usuario y producto, sino entre usuario y organización.

Ley de Hick: mito y realidad

25 noviembre, 2013. Autor: Yusef Hassan.

Uno de los argumentos más utilizados a la hora de justificar la decisión de reducir el número de opciones en una interfaz de usuario es citar la ley de Hick; afirmar que a mayor número de opciones, mayor será el tiempo y esfuerzo del usuario para localizar la deseada.

Ley de Hick-Hyman

La conocida como ley de Hick-Hyman (Hick; 1952) (Hyman; 1953) hace referencia a un modelo predictivo basado en la Teoría de la Información de Shannon. Este modelo predice el tiempo de reacción RT de una persona ante un número n de estímulos o posibles opciones de la siguiente forma:

RT = a + b log2(n)

Donde a y b son constantes determinadas empíricamente.

Como vemos, el modelo establece una relación logarítmica entre el tiempo de reacción y el número de opciones. No obstante, para que esto sea así tienen que darse dos factores. Por un lado que el usuario esté realizando una búsqueda por ítems conocidos, es decir, tener una representación mental sintáctica de su necesidad, conocer previamente el término específico a localizar; y por otro que las opciones estén ordenadas alfabéticamente (en el caso de opciones textuales).

Que el tiempo siga una distribución logarítmica, y no lineal, se debe precisamente a que la ordenación permite al usuario la continua subdivisión del conjunto de opciones a explorar (Landauer, Nachbar; 1985).

Cuando la representación de la necesidad es semántica (Mehlenbacher, Duffy, Palmer; 1989), es decir, cuando el usuario no conoce previamente el término específico que deberá seleccionar, sino que tendrá que comparar una por una las opciones con la representación mental de su objetivo, podríamos decir que la relación entre tiempo de respuesta y número de opciones será lineal…

El mito

Efectivamente, el número de opciones condiciona el tiempo y esfuerzo de decisión. Sin embargo, el problema de asumir (como una ley) que en una búsqueda semántica el tiempo de respuesta será directamente proporcional al número de opciones es que estamos asumiendo que el único factor determinante en esta ecuación es el número de opciones.

El tiempo o esfuerzo también estará determinado, entre otros factores, por cómo de fácil le resulte al usuario equiparar o relacionar mentalmente cada opción con su necesidad u objetivo. Es decir, puede que ante cuatro opciones más genéricas o ambiguas el esfuerzo de la decisión sea mayor que ante ocho opciones más específicas o precisas. En este sentido el mito de la ley de Hick (aplicada al diseño de interfaces) muestra algunas similitudes con el famoso mito de los 3 clics.

En resumen, no siempre menos es más. El minimalismo en diseño de interacción, la reducción a cualquier precio, puede ser tan contraproducente como lo es el minimalismo en otros ámbitos del diseño.

Bibliografía

Hick, W.E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, vol. 4, pp.11-36.

Hyman, R. (1953). Stimulus information as a determinant of reaction time. Journal of Experimental Psychology, vol 45, pp.188-196.

Landauer, T.K.; Nachbar, D.W. (1985). Selection from alphabetic and numeric menu trees using a touch screen: Breadth, Depth and Width. CHI’85 Proceedings, pp.73-78.

Mehlenbacher, B.; Duffy, T.M.; Palmer, J. (1989). Finding information on a Menu: Linking Menu Organization to the User’s Goals. Human-Computer Interaction, vol. 4, pp.231-251.

Optimización del algoritmo del camino más corto entre todos los nodos de un grafo no dirigido

17 septiembre, 2013. Autor: Yusef Hassan.

Aviso: Entrada más técnica de lo normal

Una forma muy habitual de estructurar datos es la de grafo, es decir, en forma de un conjunto de nodos y de enlaces entre los mismos. Los grafos no dirigidos son aquellos en los que entre dos nodos no puede existir más de un enlace y siempre bidireccional.

El problema del camino más corto consiste en determinar cuál es la distancia más pequeña que hay que recorrer para llegar de un nodo a otro. Se entiende que el valor asociado a los enlaces (su peso) representa distancias o disimilitudes. Si lo que tenemos es un grafo en el que los pesos indican proximidades o similitudes, siempre podemos transformarlos mediante la función: disimilitud=1/similitud.

Floyd-Warshall

Uno de los algoritmos más utilizados para resolver este problema, seguramente por la belleza y simplicidad de su implementación, es el de Floyd-Warshall:

for k from 1 to |V|
   for i from 1 to |V|
      for j from 1 to |V|
         if dist[i][k] + dist[k][j] < dist[i][j] then
            dist[i][j] ← dist[i][k] + dist[k][j]

Aunque en el caso de grafos no dirigidos se puede optimizar (dado que la matriz de enlaces es simétrica), del pseudocódigo se puede deducir su alta complejidad computacional, de orden exponencial.

Esta complejidad es independiente de la densidad de enlaces. Ya que lo normal es que no tratemos con grafos con alta densidad (muchos nodos están enlazados a muchos nodos), sino de más baja densidad (pocos nodos están conectados a muchos nodos, y muchos nodos están conectados a pocos nodos), resultará más eficiente utilizar un enfoque diferente.

Dijkstra

El algoritmo de Dijkstra, dado un nodo s, determina cuál es el camino más corto desde ese nodo hacia el resto de nodos del grafo. Para calcular el camino más corto entre todos los nodos del grafo únicamente habría que repetir el proceso por cada uno:

for each vertex s in Graph:
      for each vertex v in Graph:                 // Initializations
          dist[s][v]  := infinity;                // Unknown distance from s to v
      end for                                                   
      
      dist[s][s] := 0;                            // Distance from s to s
      Q := the set of all nodes in Graph;         // All nodes in the graph are
                                                  // unoptimized – thus are in Q

      while Q is not empty:                       // The main loop
          u := vertex in Q with smallest distance in dist[s][];
          remove u from Q;
          if dist[s][u] = infinity:
              break;                              // All remaining vertices are
          end if                                  // inaccessible from source
          
          for each neighbor v of u:               // Where v has not yet been 
                                                  // removed from Q.
              alt := dist[s][u] + dist_between(u, v);
              if alt < dist[s][v]:                // Relax (u,v,a)
                  dist[s][v]  := alt;
                  decrease-key v in Q;            // Reorder v in the Queue
              end if
          end for
      end while
end for

Código adaptado de la wikipedia.

Ya que este es un algoritmo cuya complejidad computacional sí depende de la densidad de enlaces (siempre que la función que devuelve los vecinos v de u esté optimizada), en la gran mayoría de ocasiones resultará más eficiente que utilizar el algoritmo de Floyd-Warshall.

Optimización

El algoritmo de Dijkstra se puede optimizar de diferentes formas, algunas comentadas en su entrada de la wikipedia.

Una optimización que deduje conforme lo implementaba (y que imagino estará ya recogida en algún trabajo) es la que se deriva de que su complejidad dependa precisamente de la densidad de enlaces.

La idea consiste en eliminar o podar todos aquellos enlaces del grafo que no formen parte de ninguno de los caminos más cortos, para que así el algoritmo no tenga que considerarlos en su búsqueda.

Esta tarea de poda se puede acometer de dos formas.

Procedimiento previo

Identificar todas aquellas tripletas de nodos enlazados entre sí, y en cada tripleta eliminar de los tres enlaces que la forman, aquel cuya distancia sea mayor que la suma de las distancias de los otros dos.

Procedimiento integrado

Aunque en las pruebas que he realizado este procedimiento parece menos eficiente que el anterior, otra opción es ir eliminando estos enlaces prescindibles como parte del procedimiento del algoritmo de Dijkstra:

          for each neighbor v of u:                                                                                             
              alt := dist[s][u] + dist_between(u, v) ;
              if alt < dist[s][v]:                                  
                  dist[s][v]  := alt ;
                  decrease-key v in Q;                           
	          if s!=u and dist_between(s, v)>alt:
	     	      remove-edge s,v from Graph;
	          end if
              end if
          end for

Es decir, si se encuentra una distancia entre dos nodos menor que la de su enlace directo, esto significa que dicho enlace es prescindible para los objetivos del algoritmo.

Pequeños detalles

13 septiembre, 2013. Autor: Yusef Hassan.

Tienda de Apple
Leyendo el artículo Why now is the right time to become a UX designer, me detengo en el siguiente párrafo (las negritas son mías):

There is no better place to see the impact of good user experience approach than in your nearest Apple Store; every detail has been considered, and nothing is there by chance. If you have ever been in one of these stores, you will know that feeling that hits you as you walk in: you feel safe, you feel good.

No pongo en duda que las tiendas de Apple estén entre las mejor diseñadas del mundo, pero leyendo ese párrafo no pude evitar acordarme de lo que me contaba uno de sus trabajadores: la cantidad de niños corriendo, o adultos mirando sus móviles, que se estampan contra sus cristales.

Entrevista

5 septiembre, 2013. Autor: Yusef Hassan.

Acaban de publicar en PuroMarketing una entrevista que me hicieron sobre UX: Cada vez surgen más departamentos específicos de experiencia de usuario dentro de las empresas

Los diseñadores deben saber programar, o no

7 agosto, 2013. Autor: Yusef Hassan.

Un buen artículo sobre este tema es el firmado por Davide Casalli, The “designers should code” bullshit and a not so new idea.

Reconozco que personalmente no encuentro mucho interés ni provecho real en este debate. Yo no creo que los diseñadores deban saber programar, yo creo que todos deberíamos saber programar. O mejor dicho, que todos nuestros hijos deberían aprender a programar.

Como una vez comentaba, no sé si aprender a programar te enseña a pensar, pero sí a comprender la dimensión práctica de conceptos abstractos, que no es poco.

A excepción de aquellas personas con memoria fotográfica, el resto de los mortales solo retenemos aquellos conocimientos que practicamos, aquellos que utilizamos con algún propósito y por tanto alcanzamos a comprender de forma tangible. Y esa es en parte la razón por la que olvidamos la inmensa mayoría de conocimientos a los que nos expusieron en la escuela y el instituto, porque nunca hicimos nada con ellos.

Me gusta imaginar cómo hubieran sido aquellas lejanas asignaturas como la de Física (entre otras) si como libro de texto hubiéramos utilizado The Nature of Code (por cierto, de acceso abierto). Cómo el poder jugar con aquellos conocimientos hubiera transformado nuestra comprensión de los mismos.

Cuando hablo de nuestros hijos es porque programar es muy parecido a adquirir un segundo idioma o aprender a tocar un instrumento musical, algo que resulta mucho más complejo con la edad.

Son los niños los que deberían aprender a programar, todos. Dotarles de esta herramienta de comprensión amplificaría sus posibilidades y futuro desarrollo profesional, sea éste el que sea.

Pós-graduação em Design de Interação e Usabilidade

22 julio, 2013. Autor: Yusef Hassan.

posgrado_ptYa han pasado nueve años desde que empecé a impartir docencia sobre UX, años en los que he participado, como docente y/o coordinador, en numerosos cursos de especialización y posgrados, tanto presenciales como virtuales.

He de reconocer que la docencia crea cierta adicción; te obliga a estructurar y repensar aquello que haces, buscar la mejor forma de hacérselo ver a quien te escucha, desaprender lo que la experiencia te ha demostrado falso, y en definitiva comprender para lograr poner en común.

Ahora estoy ilusionado y embarcado en un nuevo reto, más allá de nuestras fronteras (aunque solo un poco más allá). Se trata del Pós-graduação em Design de Interação e Usabilidade que se celebrará en Aveiro (Portugal), coordinado por Sergio Ortega, y en el que colaboro en la dirección académica.

Aunque lógicamente el público al que se dirige principalmente es el portugués, gran parte de las clases se impartirán en español, lo que sumado a su cercanía geográfica espero que atraiga también a alumnos españoles.

Más información en el post de Sergio Ortega.

Data

19 junio, 2013. Autor: Yusef Hassan.

Como argumenta Stephen Few en su artículo “Big Data, Big Deal”, el concepto de Big Data se presenta como un gran hype, una etiqueta aprovechada por los departamentos de marketing de compañías de Business Intelligence para vender soluciones tecnológicas.

Ni el volumen de datos se ha incrementado repentinamente, ni las técnicas de análisis y explotación son sustancialmente innovadoras o diferentes a las que se han venido utilizando desde hace años.

En la misma línea, Francis Gouillart firma un interesante y recomendable artículo titulado “Big data NSA spying is not even an effective strategy”, en el que defiende que el trabajo con inmensos volúmenes de datos es generalmente inútil, mientras que los conjuntos pequeños de datos altamente contextualizados son una gran fuente de conocimiento. El autor ilustra su argumento con la siguiente experiencia:

You need local knowledge to glean insights from any data. I once ran a data-mining project with Wal-Mart (WMT) where we tried to figure out sales patterns in New England. One of the questions was, “Why are our gun sales lower in Massachusetts than in other states, even accounting for the liberal bias of the state?” The answer: There were city ordinances prohibiting the sale of guns in many towns. I still remember the disappointed look of my client when he realized the answer had come from a few phone calls to store managers rather than from a multivariate regression model.

En mi opinión, no se trata de que disponer de grandes cantidades de datos no implique nuevas oportunidades. La clave está en la calidad de esos datos, y en la capacidad para explotar el conocimiento subyacente. Como afirma Few:

Big data is built on the unquestioned premise that more is better. More of the right data can be useful, but more for the sake of more does nothing but complicate our lives. In the words of the 21st Century Information Fluency Project, we live in a time of “infowhelm.” Just because we can generate and collect more and more data doesn’t mean that we should. We certainly shouldn’t until we figure out how to make sense and use of the data we already have. This seems obvious, but almost no attention is being given to building the skills and technologies that help us use data more effectively.

Hablar de Big Data es hablar de Minería de Datos, un concepto menos “trendy” pero que creo denota una característica inherente a trabajar con estos volúmenes de datos: esfuerzo.

Entre las cosas que he aprendido trabajando en proyectos en los que manejábamos enormes bases de datos es que su explotación requiere tiempo. No existen procedimientos, técnicas o algoritmos mágicos que desvelen automáticamente conocimiento oculto. Además, que el volumen de datos con el que trabajemos sea muy grande no significa que sea completo; en muchísimas ocasiones la única forma de extraer algún valor de esos datos es cruzándolos con otras fuentes. Y por último, si hay algo omnipresente en los grandes volúmenes de datos es el ruido, datos de los que se puede y debe prescindir.

Para finalizar, aunque son varias las fantasías que se venden bajo el emblema del big data, creo que la mayor de todas es la promesa de que esos datos o las soluciones tecnológicas asociadas nos van a permitir predecir cisnes negros.

Actualización 14/08/2013. Al hilo de este tema, Mario (sopadebits.com) publica una interesante reflexión: Transparencia, claridad y Big Data

Seleccione tipo de gráfico

10 junio, 2013. Autor: Yusef Hassan.

selecciones_tipo_grafico
Fuente de la imagen: infogr.am

Esta es una opción que nos persigue desde el origen de los tiempos (digitales), desde aquellas primeras aplicaciones de ofimática hasta las actuales “infografistas” en la nube.

Seleccione tipo de gráfico.

Da igual la naturaleza de los datos que queramos representar. No importa el número de variables, su tipo, su longitud. Menos aún la tarea que queramos que soporte la representación gráfica. Antes de nada:

Seleccione tipo de gráfico.

Toda expresión gráfica queda reducida a un conjunto de formas y lenguajes familiares, algunos históricamente inútiles, otros de reciente incorporación a nuestro imaginario colectivo.

Seleccione tipo de gráfico.

Es la tiranía interactiva de los wizards.

RSS Powered by Wordpress