Sopa de bits

Reflexiones sobre la información

By

Nuevo diseño en sopa de bits

By

Sistema de tagging – la nube de etiquetas


Características y elementos de las nubes de tags

Por lo que respecta a la definición de una nube de tags, creo que una imagen vale más que mil palabras. Por lo tanto, puedes ver La nube de tags de del.icio.us o bien las de flickr.

La principal utilidad de las nubes de etiquetas es la de presentar información agregada, y en el mejor de los casos, sintetizada (que no resumida). Visualizar una nube de tags de un portal equivale a disponer de un cuadro resumen de conceptos que identifican los contenidos. Cuanto más grandes se presentan los términos en una nube de tags, más frecuente es el uso de ese término. Concretaré este "cuanto más" un poco más abajo.

Después de una primera fase de uso de las nubes de etiquetas, han aparecido algunas variantes en los sistemas de visualización. Algunas de las características introducidas han sido:

  • Ordenación:
    • Alfabética: Los términos se ordenan alfabéticamente.
    • Por frecuencia: Los términos se muestran por frecuencia de uso.
  • Agrupación:
    • Alfabética: Los términos se separan por letra inicial.
    • Semántica: Los términos se agrupan por co-ocurrencia (Hassan, Herrero-Solana; 2006).
  • Sobre el uso del espacio donde se muestra la nube (Owen, Lemire; 2007):
    • El espaciado e interlineado entre tags son gestionados por el navegador.
    • Se aplican técnicas de CSS y HTML para aprovechar mejor el espacio.

Los criterios de ordenación y la agrupación son combinables, por lo que se pueden crear varios niveles de ordenación-agrupación que dieran como resultado una mejor visualización de contenidos.

Uno de los temas que son más de interés para mi ha sido encontrar un algoritmo de determinación del tamaño de las etiquetas. He encontrado información, pero no me ha parecido satisfactoria. Por ejemplo, encontré el artículo de Owen y Lemire anterior un algoritmo para la determinación de los tamaños de etiquetas.

Otro artículo en echochamber me pareció interesante por lo visual de su explicación, aunque conceptualmente creo que es erróneo. El sistema que utilizan es interesante, y en parte muy en la línea de lo que estaba pensando yo, pero no me acabó de convencer. Creo que es un error centrarse en la densidad, y no en la distribución. Es decir, calcular los tamaños de las etiquetas en base a las frecuencias simples, y no a las acumuladas.

Aunque ya es vox populi que la distribución de las etiquetas sigue una distribución con la característica cola larga, esa cola presenta diferentes pesos, el conjunto de la distribución puede tener varias formas, y por lo tanto la determinación de los tamaños puede no ser el adecuado utilizando fórmulas como las indicadas en el artículo anterior.

Abandonarse a las estadísticas

No sólo me apetece: creo que en este caso es lo mejor. Supongamos que las etiquetas siguen una distribución de frecuencias parecidas a la distribución Zipf: cola larga, pocos ítems con mucha frecuencia, muchos ítems con poca frecuencia, y los ítems del rango medio.

Si siguiéramos los criterios de sistemas de indexación full-text, los términos más utilizados se considerarían palabras vacías por ser muy frecuentes, con lo que se descartarían. La principal razón es que un término muy utilizado es un mal criterio discriminante. Por lo general, las etiquetas más utilizadas son las que aparecen en la nube, porque son cuantitativamente más importantes. Esto a nivel semántico no parece lo mejor. Esto también queda para más adelante.

Sin embargo, no descartamos los términos más habituales. La lista de tags ordenados de más a menos frecuente recuerda un gráfico de Pareto.

Echando un vistazo al gráfico de Pareto, podemos ver dos elementos: las barras, que representan la función de densidad (frecuencia en un punto), y la línea, que representa la función de distribución (frecuencia acumulada).

Podemos ver que tanto un esquema como el otro siguen una forma que se puede trazar con una línea curva: sin alteraciones. Esta forma de distribución de los datos, tiene lugar cuando existe una gran cantidad de elementos (recursos etiquetados). La variabilidad se estabiliza y es difícil crear grandes alteraciones sin introducir mucha información

Bajando del tren teórico y volviendo a la realidad: una organización está iniciando la introducción de datos etiquetados. Ese etiquetado ya empieza a presentar una larga cola, debido a que hay términos que sólo se han utilizado una vez. Sin embargo, no existe aún la cabeza de la cola. O quizá lo que está sucediendo es que los "tags medios" aún no se han formado, por lo que hay un hueco entre tags muy frecuentes y los poco frecuentes.

Esta circunstancia puede repetirse cuando se agrupa o se disgregan los tags según alguno de los criterios indicados anteriormente.

De hecho, dentro de un mismo recurso también se da el proceso que tiene lugar en el conjunto: a medida que los usuarios de un sistema de bookmarking social etiquetan un mismo contenido, la distribución se va estabilizando, formando también una distribución con cola larga.

Antes de llegar a la estabilidad, el tamaño de los tags es importante para tener una buena representación. Mostrar todos los tags muy grandes o muy pequeños puede alterar la calidad de la visualización de la nube, y por ello su objetivo. Esto tiene consecuencias a varios niveles: desde la recuperación de la información, hasta el diseño de interficie.

En esta situación, existen varias aproximaciones de base estadística al problema. Aún sabiendo que no seré exhaustivo, destaco tres:

  • Análisis en base a la "forma" o ley que sigue la distribución de frecuencias. Es decir, análisis paramétrico. Por lo general la mayoría de herramientas del análisis paramétrico se centran en la distribución normal.
  • Análisis no paramétrico: al no establecer a priori la distribución (ni su forma), se aplican técnicas no basadas en (los parámetros de) esa distribución.
  • Estadística robusta: Estadística basada en la ordenación de los datos y la obtención de valores estadísticos menos sensibles a variaciones.

De las tres, yo escojo la tercera. Para empezar, es la más sencilla de abordar, ya que las técnicas son sencillas de aplicar. Al no basarse en la distribución, se adaptan mejor a los varios casos posibles de distribuciones. Además, computacionalmente son más abordables (exceptuando por la ordenación).

Aunque esto está por ver, los efectos de utilizar la estadística robusta son intuitivamente más comprensibles por un usuario (administrador de un sitio) que quisiera configurar el comportamiento de la nube de tags, por lo que también se da pie a sencillas interficies de configuración.

La única excepción está en la ya comentada velocidad de computación por el hecho de ordenar la muestra, aunque al tratar con un conjunto ya agregado (antes de ordenar ya se han escogido un grupo reducido de etiquetas), ese aspecto no debería ser preocupante.

Nubes de etiquetas con estadística robusta

Para empezar a abordar las circunstancias comentadas antes, podemos ver un gráfico de lo que sería una distribución acumulada de tags:

Frecuencia de tags

La distribución acumulada viene a decir: si miras el porcentaje en el punto X, el valor acumulado te indica qué porcentaje de elementos (en nuestro caso tags) de la muestra estan por debajo de esa cantidad. Es decir, si en 35 tienes un 70%, quiere decir que el 70% de los tags tienen 35 o menos usos.

En cambio, la información que proporcionan los gráficos de densidad son que en el punto X hay una proporción determinada. En resumen, no dan una visión de conjunto.

Si ordenamos los valores del gráfico de densidad de menor a mayor, tenemos una "función de densidad" siempre creciente, con una forma inversa a la que habitualmente presenta un gráfico de Pareto.

Utilizando percentiles, lo que hacemos es dividir esta lista por partes. Supongamos que seleccionamos 100 tags para la nube. Si queremos una distribución equivalente de cinco tamaños de fuente, podemos seleccionar los percentiles 20,40,60 y 80. Con esto tendremos que:

  • Entre 0 y 20 tiene tamaño 1 (el más pequeño).
  • Entre >20 y 40 tiene tamaño 2.
  • Entre >40 y 60 tiene tamaño 3.
  • Entre >60 y 80 tiene tamaño 4.
  • Entre >80 y 100 tiene tamaño 5 (el más grande).

El cálculo de los percentiles con la muestra ordenada es muy sencilla. Para el caso (ideal) que planteo, sólo es necesario escoger los valores que hay en las posciones 20, 40, 60 y 80. Con estos valores, sólo hemos de ir comparando la frecuencia de uso en cada tag y asignar el tamaño del intervalo.

Hagámoslo sencillo: un ejemplo de 10 tags:

tag1 = 1
tag2 = 2
tag3 = 3
tag4 = 5
tag5 = 8
tag6 = 9
tag7 = 14
tag8 = 20
tag9 = 100
tag10 = 150

Con los percentiles anteriores, tenemos que los valores a seleccionar serían 2,5,9,20. A efectos prácticos esto significa que el tag1 y tag2 tienen tamaño 1, …. y el tag9 y tag10 tienen tamaño 5.

Para este cálculo hemos ordenado los tags *por frecuencia*. Lo que sucede a menudo es que al mostrarse en la web, se ordenan alfabéticamente. Por lo tanto, el cálculo de tamaños y el proceso de mostrarse en pantalla se hacen por separado.

Consecuencias del uso de percentiles

Una de las consecuencias del uso de percentiles es que no siempre se consigue un efecto deseable. Por ejemplo, alteraremos la muestra anterior:

tag1 = 1
tag2 = 1
tag3 = 1
tag4 = 5
tag5 = 5
tag6 = 9
tag7 = 22
tag8 = 150
tag9 = 180
tag10 = 2000

En este caso aparecen dos cuestiones importantes:

  • El percentil 20 sigue siendo 1, pero al generar la nube de etiquetas, el tag3 también se mostrará con tamaño 1. Este efecto es habitual en pequeñas colecciones o en muestras que tienen tendencia a mostrar el comportamiento de larga cola.
  • El segundo efecto importante es el de tag10: su frecuencia de uso es mayor que la suma del resto, pero a nivel de tamaño se muestra igual que el tag9, cuando en realidad tag9 está más cercano a tag8.

Un consuelo sirve para las dos: en el momento de agrupar y categorizar, siempre existen estas imperfecciones. De los dos, el más preocupante es el segundo, ya que el principal interés al agrupar datos es que se mantenga la representatividad de la información: si un tag utilizado 2000 veces se representa como igual de importante que otro utilizado sólo 180 veces, algo falla.

Por suerte, la estadística robusta ya considera la presencia de los datos extremos (outliers). Estos datos extremos se dan tanto por máximos como por mínimos. Por lo general, su cálculo se realiza mediante cuartiles y el rango intercuartìlico: el rango intercuartílico indica la distancia entre el cuartil 1 y el cuartil 3, lo que equivale a la distancia entre los percentiles 25 y 75. Esta distancia se utiliza como regla de medida para determinar lo máximo esperado para valores no extremos.

Así, si un dato está más allá de N rangos intercuartílicos respecto la mediana, se considera un outlier (valor extremo). En los casos como el gráfico box-plot, lo que se hace es dejar al outlier fuera del gráfico general, aunque marcando su posición. Para el caso que nos ocupa, la cuestión sería utilizar un criterio distinto para cada extremo:

  • Si se trata de un extremo por mínimo, debería eliminarse: si la nube de tags se utiliza como indicador agregado de contenidos, un mínimo excesivamente bajo no es representativo, ya que probablemente es parte de la "cola".
  • Para el caso de los máximos, debería existir un tamaño de fuente aplicable sólo a este tipo de datos, ya que de este modo se resaltaría esta propiedad. Es decir, una clase CSS asignada a un tag outlier.

En ambos casos, a medida que aumenta la muestra es muy probable que desaparezcan. Sin embargo, es probable que sigan teniendo presencia en nubes de tags más filtradas.

Una vez saciadas las exigencias de representatividad, ya tenemos un criterio bastante básico, que se puede concretar en el siguiente pseudocódigo.

  • A = los tags más utilizados y sus frecuencias.
  • B = Ordenar A de menor a mayor frecuencia.
  • C = Matriz con los percentiles 20, 40, 60 y 80. (escoger valores en posiciones correspondientes)
  • Para cada A[i] en A:
    • Para cada C[j] en C:
      • Si frecuencia de A[i] <= C[j]:
        • Imprimir el tag A[i] con tamaño "j"
        • break (pasar al siguiente tag)
      • Fin Si
    • Fin bucle C[j]
  • Fin bucle A[i]

Conclusiones

Si la web tiene una gran cantidad de contenidos, la nube de tags se convierte en un equivalente nada sintáctico de un resumen. Sin embargo, los formatos de las nubes de tags quizá evolucionen hacia modelos más basados en análisis de co-ocurrencia.

El hecho que se dé una buena representatividad en esta nube reflejará mejor los contenidos, por lo que ayudará a que el usuario pueda decidir si se queda o se va. La distorsión de la nube de tags (con o sin intención) es infructuoso, ya que tarde o temprano el usuario se dará cuenta que la nube no refleja el conjunto.

A nivel técnico, el algoritmo que se deriva del pseudocódigo anterior es rápido. Este tipo de consultas agregadas son sencillas, y el único factor que pudiera jugar en su contra es la memoria que puede utilizar la consulta a la base de datos.

Por delante me quedan varios temas. Uno de ellos es crear un algoritmo de creación de nube de tags que permita varios esquemas de visualización, considerando criterios de ordenación y agrupación combinados.

El segundo, de carácter más técnico, es realizar pruebas de rendimiento sobre varios esquemas de bases de datos enfocados a almacenar sistemas de tagging. Es una pregunta habitual, que también permitirá profundizar en sistemas de optimización de bases de datos.

By

Si hay que hacer zoom, se hace…

Zoom en IE7

Primera respuesta: no, no es una captura de pantalla desde un móvil. Es una captura en pantalla de 1280×1024. Cada cual que se haga la idea de la impresión que se tiene al ver esto en una pantalla de 17 pulgadas.

El caso es que en primer término uno piensa, "¿qué es esto?". Casi ocupan lo mismo las barras de desplazamiento que el contenido. Además, las scrollbars aparecen pixeladas: algo muy… Vaya, no tengo adjetivos.

En una segunda fase, uno se pone en la piel de alguien con discapacidades visuales y piensa "bueno, al menos lo tendrán fácil para encontrar la barra espaciadora.

Ahora bien, en la tercera y definitiva fase uno piensa: Y por qué no se aplica el cambio sobre el control mismo en vez de hacer zoom? Parece que IE7 debe realizar una captura de pantalla sobre el contenido renderizado, porque si en vez de aumentar se reduce, todo el layout de la página se reduce proporcionalmente al zoom. Es decir: no se reduce la letra, se reduce todo.

Dentro de poco acabo exámenes. Tengo unas ganas locas de tener un rato para escribir sobre los temas pendientes y otras cosas que tengo entre manos.

By

Estudio de usabilidad: por un mejor escritorio

El proyecto se llama better desktop y según el contenido del propio sitio, su objetivo es compartir con el resto de la comunidad Linuxera los estudios que realizaron para mejorar la experiencia del usuario en el escritorio sobre Linux. El sitio recoge más de un centenar de videos con la particularidad que están hechos en tres enfoques: la cara del usuario, el escritorio del PC, y la visión del teclado-ratón.

La combinación es realmente interesante: puedes ir viendo lo que escribe en pantalla el usuario mientras observas las muecas o la sorpresa por los resultados de la interacción.

A raíz de este estudio, el equipo de OpenSuse recopiló una serie de resultados consultables en el mismo sitio, y al final de los cuales se elaboró una serie de informes también disponibles para descarga.

El sitio no tiene mucho más: lo cierto es que es de aquellas webs que vas a lo que vas, porque no hay nada más.

En referencia a los videos: Cada bloque de vídeos se refiere a una acción. Al mirar los videos lo recomendable es escoger un par de ellos, observando la valoración sobre el nivel del usuario (Columna experience de las tablas de vídeos). Luego sólo hay que comprobar el tamaño de los vídeos: dado que se trata de la misma acción, cuanto más peso tenga el vídeo más ha costado realizar la acción.

Esto último es importante porque al equivocarse el usuario surgen los posibles conflictos de usabilidad que tiene el entorno para usuarios no tan expertos.

Podéis ver al pie de la página de vídeos que se actualizó por última vez en Diciembre de 2006, así que no es de ferviente actualidad. Además, seguro que existen una gran cantidad de recursos, aunque a mí me sorprendió por su calidad y exhaustividad.

By

Una partida de Ajedrez entre Windows y Linux

Hablo de una situación que viví hace más de diez años, con lo que no voy a entrar en detalles. En un campeonato abierto de ajedrez, cuando las partidas de la jornada ya estaban terminándose, surgió una conversación entre dos ajedrecistas de buen nivel (uno de ellos era Maestro Internacional).

Cuando me acerqué, oí que estaban comentando sobre cómo variaba la valoración de un jugador para una determinada posición, según si se realizaban las mismas jugadas con blancas o negras. Es decir, al empezar una partida, empiezan las negras, que juegan las mismas jugadas que harían las blancas en situación normal.

El principal impacto que se percibe es el cambio de situación. Las aperturas parecen diferentes, la misma posición que con blancas podía parecer equilibrada (sin ventajas para los oponentes) era ahora muy mala para las negras. Una situación buena para las blancas, era simplemente de equilibrio para las negras. ¿Por qué? Del sinfín de razones que se me ocurren, apunto las siguientes:

  • La primera, y obvia, es por la costumbre de ver las cosas desde un lado.
  • La segunda, porque al ver las cosas desde el lado opuesto, es fácil darse cuenta lo importante que es disponer de la iniciativa, pero que no es suficiente.
  • La tercera, corolario de la anterior, porque a veces el cambio de mentalidad comporta olvidarse de lo aprendido cuando se ocupaba otra postura.

En el fondo, da igual si hablamos de ajedrez o del entorno empresarial: la iniciativa (o lo que por analogía se llama the first mover's advantage) es importante, pero los errores en la iniciativa traen dos tipos de consecuencias: las propias del error, y la posibilidad de perder esa misma iniciativa.

Traspasando esto a la partida Windows-Linux, ¿os imagináis por un momento si se cambiaran los colores? Es decir, en el mercado estaba Linux con posición dominante, y aparece Windows… Con errores, vulnerabilidades, inestabilidad…

En esa situación… ¿Qué cuota de mercado creéis que absorbería Windows?

También estoy pensando qué pasaría si el conjunto de distribuciones de Linux llegaran a tener mayor cuota de mercado que Windows (personalmente creo que aún queda). Es decir, si Linux jugara con blancas y llega Windows… ¿Què estaría ofreciendo mejor que la comunidad Linux? Sea lo que sea, eso es lo que tiene pendiente Linux para mejorar su juego y obtener en algún momento ventaja por calidad.