Diseñador-Programador

15 septiembre, 2014
Yusef Hassan

El pasado mes de agosto Javier Cañada firmaba el recomendable artículo “Demigods are better than unicorns”, en el que argumenta que un diseñador-desarrollador es una combinación de perfiles que realmente no funciona bien en el desarrollo de productos digitales para terceros:

Why? the bar they set for the overall quality is as high as their weakest skill. And you want the best of both for the end result.

Termina recomendando que al contratar estos perfiles mixtos la mejor opción es que ejerzan su actividad exclusivamente como diseñadores o como desarrolladores, pero no como ambos.

Ayer tuve además la suerte de asistir a la excelente charla que Sergio Álvarez Leiva impartió en UX Fighters, titulada “Design Culture is bullshit”, en la que, entre otros temas, defendió justo la visión opuesta. Sergio vislumbra un futuro (en el entorno digital) en el que los perfiles de diseñador y desarrollador terminarán fusionándose, argumentando las ventajas que el saber programar implica para diseñar, y viceversa.

En su mayor parte estoy de acuerdo con los argumentos que Javier y Sergio defienden, lo que me lleva inevitablemente a discrepar con ambos.

La mayor parte de mi actividad profesional la dedico tanto a diseñar como a programar (front y back). Por tanto, si tengo que buscar una etiqueta que describa qué hago profesionalmente probablemente una de las más aproximadas sea la de diseñador-desarrollador (designloper, devdesigner o como queramos llamarlo).

En mi opinión, el designloper tiene una especialidad diferente a la del diseñador o el desarrollador, una especialidad cada vez más demandada, pero que no viene a sustituir a las otras dos.

Obviamente si dedicas tu carrera profesional exclusivamente al diseño o al desarrollo es más probable que alcances un mayor grado de excelencia que dedicándote a ambas actividades. Llega un momento en el que tienes que elegir entre aprender más sobre tipografía o sobre optimizar código para el motor v8. Además, como señala Cañada, es probable que tu grado de habilidad en una faceta condicione tus resultados en la otra.

Pero este perfil mixto también implica sus propias ventajas. La más obvia es la autonomía y agilidad (tanto trabajando de forma individual como en equipo), lo que lo hace un perfil tan apetecible, por ejemplo, para startups. Además existen problemas de diseño y desarrollo que son más eficazmente afrontables desde perfiles mixtos. Se me ocurren: animaciones, transiciones y microinteracciones; visualizaciones con un importante componente algorítmico; responsive design…

Igualmente, existen multitud de contextos en los que resulta más eficaz contar con perfiles claramente diferenciados, por lo que no creo que vayan a dejar de ser necesarios especialistas en diseño o especialistas en desarrollo.

La forma de la ciencia

3 julio, 2014
Yusef Hassan

The Shape of Science es un reciente proyecto de visualización creado por Scimago Lab en el que he colaborado en el diseño y desarrollo (para acceder es recomendable utilizar un navegador con amplio soporte SVG, como chrome u opera).

shapeofscience1

El objetivo del proyecto es, por un lado, ofrecer una visión global de la estructura de la ciencia y, por otro, permitir la exploración y el análisis en detalle.

En la visualización se mapean 19540 revistas científicas, donde la posición de cada revista refleja su similitud o disimilitud temática con respecto al resto. Es decir, cuanto más próximas entre sí están ubicadas dos revistas más similares son, y viceversa.

El cálculo del grado de similitud entre revistas se realiza sobre los datos de citación bibliográfica: cuanto mayor sea la frecuencia con la que dos revistas se citan entre sí o son co-citadas, mayor será su similitud.

Para traducir todas estas relaciones de similitud (aproximadamente 3,5 millones) en posiciones bidimensionales se ha empleado un algoritmo de tipo force-directed, utilizando el modelo de energía LinLog de Andreas Noack.

Además, sobre estas mismas relaciones de similitud, se ha aplicado un algoritmo de clustering con el objetivo de segmentar o diferenciar los principales grupos o clusters de revistas. El color de cada revista representa el cluster al que pertenece, pero además el contorno de cada cluster también se evidencia mediante los colores del fondo.

shapeofscience2

Las diferentes opciones permiten filtrar por el país de la revistas, el país de los autores que publican en las revistas, y el área o categoría temática al que pertenece cada revista. También es posible elegir el indicador cienciométrico a representar por el área de cada revista (nodo).

shapeofscience3

Para conocer más detalles sobre la metodología y el proyecto se puede consultar el artículo:

Hassan-Montero, Y.; Guerrero-Bote, V.; Moya-Anegón, F. (2014). Graphical interface of the SCImago Journal and Country rank: an interactive approach to accessing bibliometric information. El profesional de la información, may-june, v. 23, n. 3, pp. 272-278.


Algunas ideas en torno a la visualización de datos

30 junio, 2014
Yusef Hassan

Recientemente he tenido la suerte de poder impartir un taller de visualización de datos a dos grupos diferentes de alumnos de la nave nodriza. Es una suerte, primero por tener la posibilidad de debatir y compartir lo aprendido durante estos años con colegas de profesión UX, pero también por poder hacerlo en un entorno formativo impregnado de la visión y saber hacer de sus capitanes.

fotomordodemaru

En el taller hago énfasis en diferentes ideas que considero fundamentales, y que comento a continuación.

La primera de las ideas es que el objetivo último de la visualización de datos no es hacer visibles los datos ante nuestros ojos, sino ante nuestro entendimiento.

proceso

Comprender cómo las personas percibimos visualmente es comprender la gramática gráfica, su sintaxis y semántica. El primer paso para que una información visual sea fácilmente entendible, es que su procesamiento visual sea ordenado e intuitivo. Se trata de jerarquizar información, de definir puntos de entrada; de coordinar y agrupar los elementos para guiar la atención del usuario; y de facilitar al usuario la interpretación de aquello a lo que está atendiendo en cada momento.

jer

Como no podría ser de otro modo dedico una parte importante del taller a hablar sobre los datos, sobre cómo estructurarlos; identificar la tipología de cada variable, su longitud y semántica; qué operaciones de transformación suelen aplicarse… Su importancia radica en que es precisamente la naturaleza de los datos la que determinará de qué posibilidades de representación gráfica dispondremos, así como su diferente grado de efectividad.

Otro factor que condicionará la idoneidad de la solución gráfica serán las tareas de analítica visual que pretendemos que soporte: comparaciones simples, identificación de tendencias, relaciones de ranking, relaciones parte-todo, desviación, distribución, correlación…

tareasvisuales

Por último, la parte a la que más tiempo dedico en el taller es al proceso de elección de los atributos gráficos para codificar cada variable. Estas son decisiones de diseño que tomamos de forma intuitiva, en base a nuestro background y experiencia visual. El problema es que ese background muchas veces está contaminado por prácticas muy extendidas, pero muy poco efectivas. El objetivo de esta parte, y del taller mismo, es la de ir puliendo esas decisiones, la de replantearnos determinadas opciones como, por ejemplo, la de elegir atributos gráficos bidimensionales cuando es posible, y mucho más recomendable, optar por atributos gráficos unidimensionales.

Fotografía de @MordodeMaru

Entradas relacionadas:

Calmly Writer

29 abril, 2014
Yusef Hassan

captura de pantalla de Calmly Writer

Hoy os presento un pequeño proyecto personal, que he podido desarrollar en el poco tiempo libre que estos últimos meses me han dejado.

Se trata de Calmly Writer, un editor de textos de tipo distraction-free, es decir, diseñado para que puedas escribir tu libro, post o email sin mil opciones y barras de herramientas molestando en pantalla. Está inspirado en otros editores de textos distraction-free disponibles en el mercado (especialmente para Mac), pero también en el editor de Medium. Se puede dar estilo o formato al texto seleccionándolo y haciendo click en la barra de herramientas emergente (como en Medium), pero también utilizando marcas (al estilo markdown).

Calmly Writer puede utilizarse online, pero también instalarse como aplicación de escritorio*, que es la forma en la que realmente cobra sentido. No solo porque puede usarse offline, sino porque incorpora características imposibles (o complicadas) de implementar en la versión online.

No hace falta decir que si le dais algo de difusión o si queréis ponerle 5 estrellas en la chrome store, os estaría eternamente agradecido :). Y por supuesto, cualquier comentario o sugerencia de mejora será bienvenido.

* Al tratarse de una packaged app de chrome puede instalarse en Mac, Windows, Linux o ChromeOS. El único requisito es tener instalado previamente Chrome.

Interfaz de Usuario

3 diciembre, 2013
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
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
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.

Data

19 junio, 2013
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
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.

Investigación con usuarios

18 mayo, 2013
Yusef Hassan

La investigación con usuarios es la más poderosa herramienta para comprender el problema y validar hipótesis, pero no aporta la solución al problema.

Hace algunos meses, desde la revista hipertext, me pidieron muy amablemente que escribiera una pequeña editorial/tribuna para un número especial sobre investigación con usuarios, que se acaba de publicar.

El número que se publica incluye los siguientes artículos:

¡Hola! Este blog se escribe con Calmly Writer y se gestiona con Wordpress (rss)