Cuando esa persona además habla de una actividad profesional que cambió su actitud en torno a la vulnerabilidad, merece dedicarle un rato.

Brene Brown habla sobre la conexión entre las personas, el miedo y la vergüenza, y el papel de la vulnerabilidad y el coraje en nuestras relaciones con los demás.

…Y ya saben qué pienso sobre la vulnerabilidad: la detesto.  Por eso pensaba que era mi oportunidad para destrozarla con mi vara de medir. (…) voy a entender cómo opera la vulnerabilidad, pero yo voy a ser más astuta. (…) Como saben, no resultó ser así.

Espero que os guste.

Empecé a leer este libro con la intención de recibir visiones diferentes a las que, por mi dedicación a la tecnología, estoy más acostumbrado a escuchar.  Es un ejercicio que hago de vez en cuando.  Ojalá lo hiciera más.

Ese fue el punto de partida, y el objetivo se ha cumplido.  Sin embargo, en el paso por los ingentes casos que expone la autora, cierta angustia se ha sumado al objetivo inicial.  Y no a lo desconocido, sino a lo palpable en el día a día que nos rodea; a lo que de alguna manera se intuye pero que en este libro se explicita: el papel de la tecnología de la comunicación como la tecnología de la soledad.

Los robots no sueñan

Ni ovejas eléctricas ni nada por el estilo.  Como mucho simulan el sueño.  Al igual que pueden simular las emociones y las actitudes humanas.  Pero la perfección con la que simulan ya pasa por válida para muchos… empezando por los niños.

Atrás quedaron los tiempos de los tamagotchis.  Aunque esos llaveros animados provocaron emociones entre los pequeños (quienes no querían cambiar las pilas para reiniciar el aparato, sino enterrarlo como a un familiar  muerto), su apariencia externa no provocaba dudas en los adultos: era un juguete.

Pero la evolución tecnológica ya permite crear materiales con tacto similar a la piel humana, caras con músculos faciales, y robots que reconocen tonos de voz, la voz, y que están programados para que podamos sentir que tenemos una interacción social realista.

Rorschach y la simulación

En el fondo de la cuestión está el hecho que cuando nuestro cerebro interactúa con la tecnología, proyecta sobre ésta una serie de cualidades.

Este proceso de proyección, similar al test de Rorschach (del de las manchas) es un mecanismo adaptativo para contrastar nuestras hipótesis internas con la realidad.  Si esa proyección funciona, la mente se adapta: reconoce patrones y formas de comunicación con ese entorno.

En este proceso hay una laguna significativa que la evolución no nos ha enseñado: ¿qué sucede si esa realidad es simulada mediante la tecnología? Es decir, ¿Qué sucede si un robot que sonríe lo hace porque está programado para ello, y no como algo genuino?

Nuestro cerebro responde igual.  Y es así como se crea la ilusión de mantener una conversación con una máquina, que no ha tenido vivencias, ni frustraciones ni alegrías.  Sólo está programado para simular las conclusiones de quien lo ha creado.

Esto que suena evidente para cualquiera que tenga una iniciación en tecnología, es algo casi mágico para alguien que ajeno a ésta.  Y esa sensación ingenua de magia conduce a la admiración, y finalmente de confianza.

Porque lo malo, si robotizado, dos veces bueno

En ese proceso de generación de confianza surgen ideas sobre cómo conseguir que los robots se ocupen de tareas árduas, o ya directamente desagradables.  ¿Ejemplos?

• Cuidar de la gente mayor.
• Cambiar los pañales de los niños.
• Cuidar de pacientes con depresión severa.

Sobre el último caso, la autora relata el caso de un robot japonés llamado Paro (obviaremos ironías) que es capaz de establecer el contacto ocular e identificar el tono de voz.  Es un robot especialmente pensado para tratar pacientes con depresión severa.

¿Cuál es la diferencia entre este robot y un animal? Para la autora, la diferencia es clara: el robot no entiende nada.  Miriam, la paciente con la que se entrevistó, vivía con el robot. Se sentía reconfortada por él.  Pero en realidad, Miriam estaba sola.  La dejaron sola.

Un parche para las habilidades sociales

Y es que en el fondo, ¿qué mejor que utilizar la tecnología para cubrir lo que nos falta? Aunque eso resulta evidente cuando consideramos los avances para salvar las distancias geográficas y facilitar la comunicación asíncrona, cuando la tecnología llega a la frontera de los robots sociales, algo rechina.

Y es que, a diferencia de las limitaciones físicas, las racionales o emocionales no son tan fáciles de valorar entre las personas con un cerebro sano.  Podemos hacer deporte para ejercitar nuestros músculos y podemos ver claramente que esos músculos evolucionan pero… ¿tenemos medios para hacer lo mismo con nuestra musculatura emocional y relacional? ¿Y con los demás?

En el fondo, ese límite está en el rol futuro de esta tecnología: ¿complementar o suplir? El futuro apunta a la segunda opción: a ser los arquitectos de nuestra intimidad para que no nos obligue a convivir con las frustraciones de la realidad.  Los robots lo harán por nosotros.

Cuestiones adicionales y conclusiones

El libro hace un recorrido mucho más amplio por la introducción de la tecnología en nuestras vidas.  No son los robots el único indicador de todo este proceso.

Es obvio el papel de los móviles y las redes sociales (que al menos en USA tomaron una importancia clave después del 11-S para estar conectado en caso de otra catástrofe similar).  Los primeros en su intrusión en la vida familiar, y los segundos por el papel que juegan en la construcción de la identidad de los adolescentes.

Y en el sustrato de todo el texto, un fantasma de fondo: el riesgo de que la tecnología nos evite vivir con la frustración, y que por ello se nos escape la oportunidad de aprendizaje que ello supone.

En resumen, es un libro reflexivo, escrito por una psicóloga clínica que tiene la oportunidad de vivir en primera persona la tecnología que pasa por el MIT en cuanto a robots sociales.  Una gran parte de sus preocupaciones las reconozco en mí, pero leyendo este libro he tenido la oportunidad para poder entender los argumentos de fondo que me faltaban.

Me ha gustado la reseña del NYT sobre Alone Together, donde se resume parte de la obra y la trayectoria de la propia autora (del optimismo en libros anteriores al pesismismo actual).

Estructuras de datos más complejas

Aparentemente, el punto de partida de JIT es el inverso al de Protovis.  Si en el caso de Protovis se partía de una estructura de datos principalmente lineal (un listado de elementos a visualizar), sobre los cuales se puede aplicar una estructura de visualización concreta, Infovis parece partir del objetivo de visualizar estructuras complejas, ya sean árboles o grafos.

Infovis también permite la composición.  Es decir, el elemento de una visualización (el nodo de un grafo) puede ser también otro componente (ver el ejemplo del hiperárbol de diagramas de sectores).

La diferencia, eso sí, es también el peso de la biblioteca.  JIT está mucho más pensada para el entorno web y sus archivos de javascript son mucho más ligeros que Protovis.

Velocidad

Infovis sorprende por su velocidad de proceso, especialmente en los casos con estructuras complejas.  Quizá sea por ello que en la mayoría de gráficos de muestra se incluyen por defecto animaciones introductorias, que provocan el sufrimiento de la CPU si no estamos utilizando Google Chrome.

Por lo tanto, es una velocidad con vistas al futuro, considerando que el proceso de optimización a la que están sometidos los navegadores (aparte de la introducción de tecnologías HTML5 especialmente interesante como los web workers) permitirá que en un futuro cercano estas visualizaciones sean potentes en todos los navegadores.

Si utilizas el código de alguna de las visualizaciones de demostración, y prevees su uso en navegadores diferentes de Chrome (pienso en Firefox, y siendo optimistas IE8, aunque mejor es intentarlo antes de decepcionar), procura desactivar las animaciones (o escoger la menos intensiva) para garantizar la experiencia del usuario.

WebGL

Otro de los aspectos a seguir en un futuro próximo es la implementación de WebGL en Infovis.  Este aspecto es sugerente, aunque queda por demostrar en qué casos es realmente necesaria esta tecnología.

En este punto existen dos razones para justificar el uso de WebGL: su capacidad de visualizar en 3D, y por otro lado la capacidad de utilizar la GPU de la tarjeta gráfica para agilizar las visualizaciones concretas.

En el primer caso es una cuestión metodológica y está por ver que el 3D aporte mucho valor a la visualización en general.

En el segundo caso, el uso del webGL puede estar justificado para el caso de visualizaciones que requieren cálculos complejos delegables en la GPU.  Este es el caso de los grafos con representación por equilibrio de fuerzas entre los nodos (Force Directed Layout).  En este punto, el Canvas no es una alternativa frente a una GPU dedicada.

Como muestra de esto último se puede ver el vídeo que muestra Nicolás García Belmonte (creador de JIT) en el blog del proyecto sobre la demostración de Infovis con webGL.

HTML5, aunque en vías de implantación (probablemente durante meses o algunos años), representa todo lo que no se hizo durante los últimos 5 años porque se disponía de Flash y ya era suficiente.  Probablemente también porque el mercado de navegadores estaba dominado por Internet Explorer.

Con la nueva versión de HTML aparecen dos elementos clave para representar gráficamente datos en la web: el Canvas y WebGL.  El canvas está pensado para mostrar gráficos en 2D, mientras que webGL está pensado para visualizaciones 3D que aprovechen la unidad gráfica de proceso (o GPU) de nuestra tarjeta gráfica.  En el segundo caso hay un objetivo claro: utilizar juegos con altas exigencias gráficas en el navegador.

Del Flash al HTML5

La primera diferencia que uno siente al trabajar con gráficos basados en HTML5 els la sensación de continuidad: no precisar el cambio de contexto ni de lenguaje de programación para realizar gráficos.

Sin embargo el gran motivo de cambio hacia el HTML5 son los móviles, con los que Flash provoca problemas de rendimiento, si es que lo tienen integrado en los navegadores.

Diferencias claves de Protovis

Existiendo bibliotecas gráficas para HTML5 como raphaeljs, o el port de processing, o Google Charts, entre otras que he visto, me planteo sus factores diferenciales.  Estos factores diferenciales me permiten valorar si el tiempo de aprendizaje me compensa por:

• Su flexibilidad o su especificidad de acuerdo a nuestros objetivos.
• Su velocidad.
• Usabilidad.
• Tipo de licencia
• Facilidad de desarrollo (la usabilidad para el programador).
• Mantenimiento, comunidad y en general, garantías de continuidad.

Los puntos más a favor de esta biblioteca para mis potenciales usos son:

• Se basa (o al menos se inspira) en el framework de la gramática de los gráficos, por lo que tiene una versatilidad prácticamente ilimitada.
• El método de configuración de un gráfico es relativamente sencillo, ya que se basa en el método de encadenamiento.
• Al funcionar por capas conceptuales de la gramática, permite componer gráficos y subgráficos, aparte de facilitar la creación de nuevos elementos en cada nivel de definición del gráfico.
• Aunque está muy enfocada a los gráficos estadísticos, su método de desarrollo permite pensar en su uso para visualizaciones más bien estructuradas y basadas en los datos.
• Incorpora algunas funciones estadísticas como preparación de los datos, aunque no es su objetivo principal.
• Licencia BSD (similar a la MIT), prácticamente la que proporciona más libertad para su uso (tanto si el desarrollo final es también libre o propietario).

También surgieron algunos contras al respecto:

• Es una biblioteca pesada, más bien pensada para Intranets o conexiones rápidas, aunque con un buen uso del caché de navegador y los ETags sólo se notará en la primera carga.
• Su potencial es el uso específico, personalizado.  Si el objetivo son gráficos sencillos, existen otras bibliotecas más adecuadas.

Trabajando con Protovis

En el sitio de protovis se hallan ejemplos bastante representativos de las posibilidades generales de protovis, y opciones de personalización interesantes.  La mayoría de gráficos estándares pueden basarse en tales ejemplos de código

Como colofón, se puede encontrar la muestra del gráfico de Minard realizada con Protovis que Tufte considera el mejor gráfico de la historia.  Este gráfico también aparece en el libro de la gramática de los gráficos, como muestra de los factores componentes de esta visualización.

Por otro lado, también es posible incrustar gráficos de Protovis en WordPress, utilizando el plugin de carga de Protovis.

El resumen (traducido y con resaltado mío) es el que sigue:

Estudiamos un modelo prototípico de un Parlamento con dos Partidos o dos Coaliciones políticas, y mostramos cómo la introducción de un porcentaje variable de legisladores independientes seleccionados aleatorioamente pueden aumentar la eficiencia global de una legislatura, tanto en términos del número de leyes aprobadas y de la media de bienestar social obtenido.  También encontramos analíticamente un “número áureo de la eficiencia” que permite establecer el número óptimo de legisladores que deben ser seleccionados aleatoriamente después de que las elecciones regulares hayan establecido la proporción relativa de los dos Partidos o Coaliciones.  Estos resultados están alineados tanto con el antiguo sistema democrático Griego como con el descubrimiento de que la adopción de las estrategias aleatorias pueden mejorar la eficiencia de las organizaciones jerárquicas.

El artículo utiliza la metodología de la simulación, por lo que no es un ejemplo real con datos basados en experiencias humanas.  Es por ello que el artículo se basa en una abstracción matemática que puede restar interés para quien no se quiera adentrar en los números.  Trataré de allanar un poco el camino.

Una explicación menos matemática

Para establecer un modelo de simulación como el del artículo es necesario establecer unas reglas de actuación y unos individuos (los agentes), que actuan con una lógica independiente sobre la cual toman decisiones individuales.  La suma de decisiones conforma un escenario que es el objeto del análisis.

En este caso, los agentes se encuentran en un espacio planteado por Carlo M. Cipolla, donde se plantean dos factores:

• Acciones del individuo que resultan beneficiosas/perjudiciales para sí mismo.
• Acciones del individuo que resultan beneficiosas/perjudiciales para los otros.

En el modelo, estos dos factores se transforman en:

• Beneficio personal.
• Beneficio social

Cada uno de estos factores puede tomar valores entre -1 (muy perjudicial) y +1 (muy beneficioso).  Los cuatro tipos extremos, con valores asignados según lo anterior, son:

• Los Inteligentes se benefician a ellos y a los demás (+1, +1).
• Los Incautos benefician a los demás pero no a ellos mismos (-1, +1)
• Los Malvados se benefician a ellos y perjudican a los demás (+1, -1)
• Los Estúpidos se perjudican a ellos y a los demás (-1, -1)

Lo anterior son valores extremos y no los casos típicos.  Los he utilizado para clarificar la conversión de palabras a números.  En la simulación se podrá encontrar agentes con coordenada (0.25, -0.1 -> algo egoísta, ligeramente malvado), por poner un caso.

La razón para escoger el intervalo entre +1 y -1, está en parte explicada en el artículo sobre normalización y distancias normalizadas.  En una palabra: simplicidad y facilidad de cálculo, aparte de ser muy intuitiva.  Se podría escoger +100 y -100, pero esto sólo aumenta la complejidad de los cálculos: a nivel de simulación no aportan valor alguno.

Los agentes pueden realizar dos acciones: presentar una ley, o bien votarla (a favor o en contra).

En el momento de la decisión, los agentes parten de su centro de gravedad, pero están de acuerdo con cualquier ley que tenga valores más positivos que su centro de gravedad.  Gráficamente: que se encuentren más a la derecha y por encima de su centro de gravedad personal.

Por otro lado, cuando los agentes son miembros de un partido, aceptan sus directrices.  Estas directrices se representan gráficamente por el círculo de tolerancia del partido.  Este círculo muestra las leyes que el partido en conjunto está dispuesto a votar.

En suma, el agente depende de su adscripción política (círculo de tolerancia) y de su postura personal (ventana de aceptación).  Esta dependencia impone las siguientes reglas en el juego:

• El círculo de tolerancia de un agente miembro de un partido muestra en sus decisiones es el mismo que el del propio partido (lo que conocemos com disciplina de voto).
• El agente miembro de un partido siempre vota a favor de las leyes que presenta alguien de su partido.
• El círculo de tolerancia del partido es más o menos pequeño, dependiendo de si se trata de partidos más o menos autoritarios (o rígidos, si se prefiere).
• Los parlamentarios elegidos aleatoriamente no podrán repetir en sucesivas elecciones, para evitar ser abducidos por los partidos mayoritarios.

Y ahí es donde esta la clave de la simulación, en combinación con la disciplina de partido.  Por resumirlo en una frase: Al seleccionar un grupo aleatorio de individuos se cubren las distancias entre los marcos de tolerancia de los partidos.

Gráficamente se puede imaginar dos grandes círculos (los partidos), con todo su entorno salpicado por los individuos seleccionados aleatoriamente.  Estos individuos pueden servir como soporte para leyes que quiera presentar el miembro de un partido, cuando estas leyes estén en el límite.

¿Cuántos diputados escoger aleatoriamente?

La fórmula para el cálculo de los diputados escogidos aleatoriamente (per la página 13 de la versión PDF del artículo) es aparentemente compleja, pero se basa en dos factores básicos:

• El número de diputados del congreso en cuestión.
• La proporción de diputados del partido mayoritario.

El gráfico de la página 14 del documento muestra el comportamiento de la función que calcula los diputados independientes.

Considerando el caso del bipartidismo, los votos del partido más votado pueden oscilar desde el 50% hacia arriba.  En el eje vertical vemos el número de diputados en el caso que el congreso tuviera 500 escaños (el caso de la simulación).

Como se puede ver, si el resultado es equilibrado (50-55% para el partido ganador: casi un empate técnico) el número de votantes independientes es pequeño porque es fácil desequilibrar la balanza.  Cuanto más grande es la mayoría, más independientes.

Quizá sea posible esperar nuevas simulaciones con multipartidismo, para así poder analizar casos más complejos.

Aunque la conclusión se basa en un análisis de los resultados de la simulación, la causa, según la explicación de los autores, es relativamente intuitiva:  Si la selección de independientes es realmente aleatoria, su soporte será mayoritario para el partido ganador.  Sin embargo, al evitar la disciplina de voto pueden favorecer a más acuerdos.

En palabras de los autores: No se pierde nada del sistema de partidos (efectividad en los sistemas de votación) y se gana todo por la aparición de diputados independientes (la calidad de sus propuestas).

Dudas

• ¿Cómo afecta la inclusión de otros partidos a la cantidad de independientes?
• ¿Por qué la ventana de aceptación de un individuo se establece con un mínimo y aceptar lo que sea siempre más positivo (sobretodo a nivel social)? ¿Se podrían plantear márgenes más cerrados?
• A nivel de las interacciones: ¿Cómo afectaría al círculo de tolerancia de los partidos la aparición de los independientes?

Conclusiones y aplicaciones:

• Tratándose de una simulación, el resultado no parece aplicable directamente.
• El planteamiento del paper es por sí mismo muy creativo y sugerente.  Y eso no le resta en absoluto vínculos con la realidad.
• ¿Quizá lo aplicable por fórmula del partido más votado se podría aplicar en base a la abstención? ¿Y sobre los votos en blanco?

Un apunte final: En relación a la selección aleatoria de individuos, encontré hace tiempo un artículo de (casi) los mismos autores relacionado con la Promoción aleatoria de personas en las empresas para evitar el principio de Peter.

Ha sucedido en otras ocasiones, con la cercanía de algunas elecciones. Pero en anteriores casos este aumento se mantenía en el tiempo. En este caso, el efecto es claro: empezaron a subir a partir del día 16, y siguen subiendo (especialmente el del voto en blanco).

Esto no me sorprende. Ayer tuve la oportunidad de ir a Plaça Catalunya y comprobar, en primera persona, y como uno más, lo que estaba sucediendo. Y lo que sucedió es que hablaba, escuchaba y preguntaba. Cualquiera que desee salir de dudas sobre lo que está pasando, tiene un punto de referencia.

Un apunte corto, pero que quería comentar por cómo de evidente es el ejemplo. El experimento se ha llevado a cabo en niños por lo que no significa que no se pueda trasladar a los adultos. Personalmente lo creo así.

El proceso es diferente pero, en el fondo, esa necesidad de adaptación al medio que lleva a cabo el cerebro recopilando información permite detectar patrones, recopilar feedback de nuestras acciones y, finalmente, aprender.

Estas son preguntas que por lo general no nos planteamos en el momento de representar datos gráficamente.  Lo obviamos por agilidad, igual que no estamos dando órdenes conscientes de inspirar-expirar o pie izquierdo/pie derecho.

La pregunta de fondo es: ¿Importa tenerlo presente? Puede que antes no fuera necesario, pero ahora, para mí, sí.

Me refiero a antes como a las épocas en que los conjuntos de datos eran más bien limitados, las interrelaciones entre ellos eran simples, e incluso cuando se dibujaban los gráficos a mano.  Hablo de antes como el momento en el que las interrelaciones entre datos no formaban parte del núcleo del análisis ni había interacción posible con ellos.

Ahora, el momento en el que hay (sobre)abundancia de datos, disponemos de aplicaciones informáticas capaces de gestionar la interactividad; cuando buscamos respuestas más profundas, revisar la razón de ser de los gráficos y sus componentes resultaba para mí un ejercicio casi imprescindible.

Buscando entre libros que pudieran servirme de base y que plantearan una definición estructurada, me topé con el libro de Leland Wilkinson, The Grammar of Graphics (Springer, 2a ed. 2005).

Punto de partida

Wilkinson, además de profesor universitario de estadística, ha sido vicepresidente de SPSS del 1994 al 2007 y actualmente vicepresidente ejecutivo de SYSTAT.  Se puede decir que ha estado en sitios de suficiente prestigio como para decir que sabe de lo que habla.

Con su experiencia empezó a recopilar gráficos de cualquier tipo para empezar a detectar patrones, factores y elementos a tener en cuenta para desarrollar esta gramática.  A partir de esa base, desarrollo un marco de trabajo sobre el que se puede definir prácticamente cualquier representación gráfica de datos.

¿A quién va dirigido este libro? Exceptuando los conceptos puramente matemáticos/estadísticos, Wilkinson comenta que ha desarrollado su exposición partiendo de una terminología no especializada.  Según él, cualquier persona interesada en los gráficos científicos o de negocios. Diferencia en tres niveles según el grado de conocimiento en matemáticas:

• Los que buscan un catálogo/tesauro de gráficos.
• Los que quieren seguir el argumento sin necesidad de entrar en los aspectos matemáticos.
• Los que tienen suficientes conocimientos matemáticos para entender la notación matemática y seguir los criterios.

Cuanto más nivel, más contenido relevante.  Pero los tres niveles pueden seguir sus argumentos.  Personalmente creo que sacarán mucho más partido del libro las personas con conocimientos matemáticos y/o informáticos para aplicar sus ideas.

Hay una delimitación explícita sobre lo que no tiene por objetivo este libro.  Lo que Wilkinson no plantea es:

• Un lenguaje de comandos (o de programación, como se prefiera). Sin embargo utiliza expresiones similares.
• Una taxonomía, aunque la cantidad y variedad de gráficos es notable.
• Una aplicación de dibujo (drafting package).
• Un libro de las buenas virtudes: con lo que explica se pueden conseguir tanto gráficos maravillosos como horribles. Es tarea de quien lo utilice identificar las cualidades y defectos del resultado.
• Un método heurístico: El primer paso es definir un lenguaje formal de los gráficos (que es lo que él propone en el libro) para luego establecer una heurística que determine los gráficos más adecuados a cada caso.
• Un sistema de información geográfica.
• Un sistema de visualización. Matiza que sus bases se pueden utilizar para la visualización, pero que no lo incluyen para no viciar (concentrarse en) los conceptos básicos.

La gramática (o cómo hacer un gráfico de sectores)

El capítulo 2 es una aproximación rápida a la propia gramática, y expone en un ejemplo práctico (el diagrama de sectores) los componentes de la gramática.  En una lista:

• Relacionados con datos:
  • Variables/datos: Lo que nos viene dado. Nuestro punto de partida.
  • Álgebra: Operaciones matemáticas sobre los datos que permiten representarlos dentro del marco que supone un gráfico.
  • Escalas: Por decirlo de un modo simple, unidades de medida.  Decidir las escalas y adecuar los datos a ellas es una parte importante del proceso.
  • Estadísticas: Los cálculos matemáticos propiamente estadísticos sobre los datos. Incluye desde medias, cuartiles y proporciones, hasta relaciones de agregación o separación entre datos.
• Relacionados con la representación gráfica:
  • Geometría: Las formas a aplicar sobre los elementos a representar.
  • Coordenadas: Las guías visuales que servirán de referencia para la representación.  Por ejemplo, en el caso del gráfico de sectores, tratamos con coordenadas polares.
  • Elementos estéticos: Color, texturas, etiquetas, títulos,

Los elementos están en el mismo orden en el que según Wilkinson deben ser aplicados sobre el gráfico a representar.  Por mi parte destacaría el capítulo de coordenadas.  Las coordenadas dan coherencia y facilitan la lectura visual del gráfico para identificar patrones.  Hay una relación estrecha entre escalas y coordenadas, pero no es lo mismo.

Además, las coordenadas incluyen guías visuales, aunque también las proyecciones y en definitiva todo lo que da forma al conjunto del gráfico.  Bajo mi punto de vista en las coordenadas tienen lugar los aciertos y errores más claros, a la vez que difíciles de detectar por un espectador.

Valoración

Releyendo lo escrito hasta aquí me doy cuenta que estoy dejando de lado un aspecto importante.  Aunque el libro tiene un objeto claro, el proceso ha sido más interdisciplinar de lo que parece.  Por ejemplo, se comentan aspectos psicológicos en la diferenciación de las escalas de colores, formas y coordenadas, así como los efectos de combinar algunos tipos de gráficos.

No es comparable con los libros de Tufte, más bien complementario.  En algunos puntos parece que se hubieran puesto de acuerdo: donde empieza uno acaba el otro.

Tanto Wilkinson como Tufte me han aportado muchas ideas y enfoques renovados a la representación gráfica. Espero sumar en breve la lectura de un tercer autor que tengo en el punto de mira, Jacques Bertin y su semiología de los gráficos.  Hasta el pasado Noviembre no se reeditó el libro, pero ahora ya no hay excusa…

Aunque existen muchos tipos de pruebas de aplicaciones, considero que las pruebas de UI son especialmente críticas: en último término determinan la calidad percibida, con independencia de la calidad interna del producto.

Mi utilización de Selenium (en especial Selenium RC) se ha limitado a su objetivo original, pero durante las horas de vuelo que transcurren durante las pruebas surgen ideas sobre el papel del testeo en el desarrollo de aplicaciones web.  Sólo con ver la ejecución automática del testeo y adoptar el sombrero del usuario final, se pueden llegar a contar las mejoras por docenas.

La realidad del equipo de desarrollo

Aunque la tecnología web precisa una mirada interdisciplinar, cada equipo enfoca las soluciones según sus conocimientos.   Mi experiencia se basa en proyectos más centrados en la parte técnica, por lo que el desarrollo (mucha programación y menos diseño) absorben mucho tiempo.  Si el tiempo estimado se agota, la inercia lleva a sacarlo de las fases finales.

He comprobado también por la experiencia que el tiempo de testeo y documentación se acaban recuperando, quizá fuera de plazo, y a lo peor con la decepción del cliente.  Porque al cliente le importa poco la implantación del modelo de datos, e incluso las luces y colores.  Si no funciona como la entiende, la aplicación está rota.

Sé que testear la interacción y documentar para el usuario final son tareas percibidas como tediosas, ya que suponen un cambio de sombrero para cualquier desarrollador.  Es el equivalente informático a corregir nuestro propio dictado.

¿Argumentos habituales? Sobre el testeo de UI se dice que ya es suficiente con las pruebas que se realizan mientras se desarrolla (falso); de la documentación de usuario… quizá ni hablemos, porque con el axioma Mac segun el cual un programa se explica por sí solo (error grave), la excusa está servida.  Claro, porque todas las empresas de desarrollo han de ser como Apple, ¿no?

Ponerse unas horas en la situación del usuario después de semanas de verlo todo desde dentro es mucho más complejo de lo que pueda parecer: un programador conoce los datos y la estructura de la aplicación. Ve todas las opciones aunque sean invisibles (porque las ha puesto él), y sabe que ante un error puede resolverlo rápidamente (no como el usuario final).  Su percepción de las consecuencias no está alineada con la del usuario final, y esto le resta capacidad crítica.

Pero si además se le plantea que redacte el manual de usuario, utilizará terminología técnica (porque se han familiarizado con ella).  Y yo, que conste, lo entiendo.  No sólo porque desarrolle, sino porque cuando lo veo desde el otro lado sé que es complicado. Por no decir lo poco que motiva explicar la aplicación por segunda vez (la primera vez lo ha explicado a una máquina) y en términos distintos.

Tendiendo puentes

Es por eso que cada vez veo con más interés el testeo como el puente que vincula la visión del cliente y el desarrollo.  El testeo puede establecer guías concretas sobre el que un intermediario puede hablar con el cliente.  Esa concreción por sí misma evita los malentendidos habituales. Y aporta mejoras en concreción.

Con la información recopilada en esas reuniones puede desarrollar casos de uso (o escenarios de usuario),  describir la prueba, estructurar las fases y establecer los requerimientos.

Con esto, puede pactar con el equipo de desarrollo las tareas a realizar, desarrollar la prueba, y redactar la documentación de usuario bajo un guión unificado.  Y lo que verificará que la tarea está hecha es la superación de las pruebas.

Espero tener tiempo para comentar en otros artículos el detalle de estas relaciones, lo que permiten y lo que pueden complementarse con otros métodos.

Durante el tiempo en que Rhino ha estado en el escenario, el concepto de javascript en general se asociaba a bugs, inmadurez en las herramientas de desarrollo y testeo, y sobretodo lentitud.  En especial por lo último habría que hablar de Internet Explorer 6 (del que ahora, quizá un poco tarde, piden disculpas).

Vale la pena decir que esta lentitud no era tanto debida al propio javascript sino al DOM (la estructura que se genera a partir del HTML para que el navegador muestre las páginas web como se espera).  Pero para un usuario final eso da lo mismo (y con razón): si hay javascript y va lento, entonces javascript es lento.

Pero entonces llegó Chrome, su motor de Javascript con nombre de coches de carreras, y una visión clara: velocidad.  Su funcionamiento interno lo posicionaba para todo lo que se podíamos soñar para la web, pero que no podíamos realizar.  Cualquier prueba de rendimiento puede dar fe de su potencia.  Complementando V8 con el motor de renderizado de Webkit (el mismo de Safari), el resultado es un caballo ganador que ha entrado fuerte en la web (y se ha notado en las estadísticas).

Quizá conociendo el concepto de Javascript en el servidor derivado de Rhino, alguien decidió seguir sus pasos: si V8 es capaz de ejecutar JS a velocidades cercanas al C++, por qué no desarrollar en javascript para el cliente (navegador)  y también en el servidor?

Hay varias ventajas:

• No hay que hacer un cambio de chip en un mismo proyecto en la parte cliente y servidor.  No hay lenguaje de cliente y lenguaje de servidor.
• El intercambio de datos para aplicaciones Ajax tiene un formato ideal: JSON.  Un formato nativo del lenguaje es lo mejor que puede pasar para simplificar el intercambio.
• Su ligereza y su simplicidad en el desarrollo (sobretodo en comparación con Java, pero también con otros de Scripting como PHP, Ruby, Python).
• Para todos los desarrolladores de javascript en la web se abre un campo inmenso en el cual expandirse.

Y así fue que apareció nodejs.   No se trata de utilizar javascript sin más: incorpora los eventos como parte interna del lenguaje (y aparentemente evitando el bloqueo de I/O), permitiendo la devolución de respuestas de forma asíncrona y sin necesidad de trabajar con hilos de ejecución como por ejemplo lo hace java.

Todo esto sin considerar que puede ejecutar en el servidor lo último del HTML5 (web workers, web sockets, etc) sin las restricciones de seguridad de un navegador.

De ahí que estén surgiendo ideas para la computación distribuída utilizando V8 en el servidor (o conectando varios usuarios a una misma página, por ejemplo), o crawlers (se puede integrar jQuery y sus selectores en el javascript de nodejs).  Pero esto ya es un tema aparte.

El cambio de reglas que ha introducido nodejs ha provocado un crecimiento muy rápido de un ecosistema a su alrededor.  En poco tiempo ya tiene varios frameworks de desarrollo, motores de plantillas, e incluso un gestor de paquetes para facilitar la instalación de componentes en el servidor.

En la web el desarrollo se asienta por dos filosofías opuestas que se combinan en menor o mayor grado: los que buscan soluciones estables, verificadas, seguras (certificadas) sobre las que canalizar un negocio preexistente; y por otra los que quieren hacer algo sin preocuparse demasiado por aplicar técnicas formales de análisis y desarrollo de aplicaciones, desarrollando silver bullets y siguiendo el criterio del release early release often.

Pero sucedía una paradoja: mientras que los primeros han utilizado Java como tecnología principal y han creado un gran paquete de herramientas, los segundos trabajan con variedad de lenguajes, herramientas de soporte más simples (y quizá menos productivas).

Para los segundos, Javascript en el servidor me parece una apuesta arriesgada, pero con muy buenas perspectivas.  Eso sí, los nuevos conceptos obligan a practicar unas horas (depende del nivel de cada uno) antes de ponerse a fondo.

Si te ha picado la curiosidad, deja de leer y pruébalo ya