Investigación Sprint vs. Investigación de largo recorrido

Este post es parte de la serie “Investigación colaborativa, divertida, barata, transmedia. Otras formas de entender la investigación” publicada a modo de cruce de posts entre numeroteca.org y voragine.net. Este trabajo se enmarca dentro de un estudio sobre Investigación en red coordinado por Mayo Fuster Morell parte de un proyecto más amplio sobre Juventud, Internet y Política bajo la dirección de Joan Subirats en el marco del grupo IGOPnet.cc, con la colaboración de Montera34, para la Fundación Museo Reina Sofía sobre adolescencia y juventud. #otrainvestigación es el hashtag.

#OccupyData Hackathon

Uno de los grupos de trabajo de los que formaba parte dentro de Occupy Research, red abierta y distribuida de investigación, que comentaba en la anterior entrega fue Data and Visualization, que consistía en recopilación de datos sobre el movimiento Occupy y tratar de visualizarlos. Como contaba el resumen de este apartado en la wiki de Occcupy Research cuando interactuamos en redes sociales en Internet dejamos una huella en forma de datos. Muchos de esos datos son esos registros a los que hacía referencia Alfonso en la entrega anterior, Investigar sin darse cuenta: archivos personales: dominios que visitamos, términos de búsqueda, y también los más obvios y visibles como tuits, estados de Facebook, “me gustas” que más tarde pueden ser recogidos y analizados. Este análisis lo pueden hacer las empresas en Internet para ofrecernos conocer mejor a los usuarios y proporcionar publicidad más personalizada para así obtener más beneficios. Pero también, como está destapando el caso Snowden sobre la Agencia Nacional de Seguridad (NSA) de EE.UU, las agencias de inteligencia de los estados pueden obtener información de las redes sociales, tanto datos oficialmente públicos como los supuestamente privados, para estudiar el comportamiento de los ciudadanos según su actividad en Facebook, skype o emails.

occupydata-poster-1

Occupy Data trataba de obtener y utilizar esos datos que vamos dejando en las redes sociales para aprender sobre el movimiento Occupy visualizando la información de forma inteligible. Había gente interesada en compartir diferentes métodos de obtención de datos (entrevistas en las acampadas, scrapers que descargaban datos atomáticamente), y otros en compartir bases de datos que habían generado. Nos llegó una base de datos de un particular que había recopilado por su cuenta información relacionada con cada uno de los nodos de Occupy: sus cuentas de Twitter, Facebook, dirección física, teléfono, email… todo un ejemplo de investigación no distribuida pero de gran calidad.

A raíz del anuncio de publicación de un archivo de varios millones tuits sobre Occupy, que la organización R-Shief (r-shief.org) había recopilado, organicé junto con Sasha Costanza-Chock, profesor del MIT y co-director del Center for Civic Media, un hackathon desde Occupy Research para analizarlos colectivamente y hacer visualizaciones. Se trataba de un evento deslocalizado y pensamos que era una buena oportunidad para juntarnos y crear colectivamente. #OccupyData hackathon iba a ocurrir simultáneamente en diferentes ciudades del mundo los días 9 y 10 de diciembre de 2011.

Un Hackathon, que viene de Hack y Marathon, es un evento en el que durante poco tiempo se juntan varias personas para desarrollar intensamente un proyecto, habitualmente de software. En esta ocasión se partía de varios millones de tuits que contenían hashtags relacionados con occupy (#occupy, #OccupyWallSt, #OccupyBoston, #OccupyOakland, etc.). Un hashtag es la forma de etiquetar el contenido de un tuit. La palabra que sirve de etiqueta, el hashtag, debe estar precedida del símbolo “#”. Si el usuario hace click en ella puede ver el resto de mensajes que otros usuarios han publicado con esa etiqueta.

El hackathon empezó exponiendo a los participantes con qué datos contábamos para pasar rápidamente a una lluvia de ideas sobre qué hacer con ellos. Entre todos evaluamos las diferentes propuestas que habían quedado dibujadas en la pizarra para decidir cuáles podíamos llevar a cabo, dado el tiempo y las capacidades técnicas de las que disponíamos. Cada cierto tiempo había preparadas conexiones por videoconferencia (Google Hangout) con otras ciudades para compartir avances y exponer los prototipos generados.

Compartir espacio físico durante unas horas o unos días es un buen método para forjar alianzas y conocerse. Puede dar pie a que los proyectos tengan recorrido más allá del tiempo programado del hackathon. Como comentaba Charlie DeTar, doctor por MIT Media Lab y colega del Center for Civic Media, un hackathon es un buen método para concentrar creatividad multidisciplinar e inspiración en un corto periodo de tiempo, a la vez que puede ayudar a atraer la atención sobre un determinado tema.

OccupyTweets: de la idea al programa en dos días

OccupyTweets: cada pixel representa un link. El color es la categoría a la que pertenece.
OccupyTweets: cada pixel representa un link. El color es la categoría a la que pertenece.

Una de las propuestas de esa lluvia de ideas inicial era clasificar y cuantificar visualmente los enlaces (las url) contenidos en los tuits. En vez de analizar las palabras del mensaje nos queríamos centrar en las url, la mayoría de las veces indicativo de dónde quería fijar la atención el usuario que enviaba o retuiteaba un mensaje. Pensamos que clasificando cada uno de esos enlaces por tipo de página web enlazada, podíamos entender qué sitios en internet estaban teniendo más importancia dentro de la temática occupy.

La primera dificultad técnica era ‘extraer’ las url de los mensajes, ya que en Twitter los enlaces aparecen acortadas (con url’s como t.co, o bit.ly) para ahorrar espacio de los limitados 140 caracteres que permite cada mensaje. Así una dirección como “http://www.ustream.tv/channel/occupy-chicago” está insertada en el tuit como tiny.cc/b7f6h, y a su vez acortda como http://t.co/mjoQVsQr. Para poder clasificar las url necesitamos obtener los enlaces originales.

Una vez resuelto este paso había que clasificar las url  y para ello creamos una serie de categorías. Las que más se repitieron fueron: imágenes (123.683 veces), vídeos (89.139), Twitter (68.711), blogs (41.468), noticias (35.610), facebook (19.188), video stream (3.462), Google (2.868), sitios web de occupy (2.064), Wikipedia (2,030) y a campañas de donaciones (381).

Una primera versión, en la que usamos solamente los tuits sobre #OccupyBoston para probar el sistema, estuvo disponible el segundo día por la noche, al terminar el hackathon. Para entonces ya habíamos publicado un post explicando lo que queríamos hacer, un vídeo de cómo lo hacíamos y otro explicando el resultado obtenido. El código estaba disponible también online: se trataba de hacer herramientas que otros investigadores también pudieran usar y modificar.

Si todo el proceso está bien documentado, diferentes personas pueden colaborar en su desarrollo aportando su conocimiento y capacidades en diferentes momentos del mismo. Una documentación de calidad convierte un proyecto en verdaderamente abierto, especialmente si se trabaja deslocalizadamente, pero también si se está en un mismo lugar físico.

En un breve lapso de tiempo, tan solo dos días, habíamos podido ir de un borrador en una pizarra a una primera herramienta para estudiar una ingente cantidad de datos. Fue posible porque habíamos seleccionado una idea que era factible realizar en el tiempo y con los recursos que teníamos disponibles. Esto incluía contar con alguien que pudiera  programar el código necesario. En este caso contábamos con Charlie DeTar, que hizo toda la programación.

Sin embargo, es importante señalar lo que Charlie comentaba en su post “los hackathons no resuelven problemas”. La mayoría de los prototipos que salen de un hackathon requieren casi siempre retoques y desarrollo posterior para que sean usables por el gran público una vez ha terminado el hackathon. En el caso de la visualización de tuits, si echamos un ojo a las líneas de código que escribió, veremos que una vez terminado el proyecto siguió mejorando la herramienta y corrigiendo errores días después de que el evento hubiera acabado. Añadía también que los resultados de un hackathon no suelen tener la calidad y complejidad para resolver los problemas complejos del mundo real. Si son útiles, es sobre todo por el contexto dentro del que se desarrollan y por la red de usuarios y gente que los apoyan y usan.

Un proyecto como OccupyTweets, que esencialmente es una herramienta de análisis de links tweets emparentada de alguna forma con Eventweet, tiene mucho margen de mejora: búsqueda por fecha, añadir captación de tuis en directo, etc. Lo que es necesario para que eso ocurra es un grupo de usuarios que lo usen, que demanden implementaciones en el código, y unos desarrolladores que puedan dar respuesta a esas necesidades.

HurricaneHackers: ¡Esto es sólo una demo!

 Documento en Googledocs, índice de HurricaneHackers. http://bit.ly/hh-index
Documento en Googledocs, índice de HurricaneHackers. http://bit.ly/hh-index

Otro grupo de investigación informal que surgió animado por los acontecimientos que nos rodeaban fue el de HurricaneHackers. Un día antes de la llegada del huracán Sandy a la costa este de Estados Unidos un grupo de personas, animados por Sasha Costanza Chock, se empezó a organizar a través de Internet bajo el nombre de HurricaneHackers, lo que viene a ser algo así como los hackers del huracán. Se pretendía pensar colectivamente qué podían hacer los ciudadanos para ayudar y coordinarse frente a la ‘supertormenta’ Sandy.

El grupo, de número y composición indefinida, se coordinaba a través del hashtag #hurricanehackers en Twitter y de un canal de chat en IRC. La información sobre los diferentes proyectos se iba escribiendo en un googledocs que centralizaba la información. Paralelamente se iba completando una lista con todos los enlaces relevantes para estar informado sobre Sandy: http://bit.ly/hh-linklist.[ref] Los links acortados tipo bit.ly eran usados para facilitar el compartir url difíciles de memorizar. Una url como https://docs.google.com/document/pub?id=1SGcfQz13ce4FfB-QHKF3WLwxHoCRGBouuvZn-3aoX0k se convertía en http://bit.ly/hh-index.[/ref] Al carecer de un espacio físico común, todo el proceso de lluvia de ideas, evaluación y desarrollo de proyectos, similar al proceso de un hackathon, se hacía online. El proyecto atrajo la atención de los medios de comunicación (boing boing, cnet, techpresident) y muchas personas se acercaban por el canal de char de IRC de hurricanehackers. Enseguida nos dimos cuenta de que era importante tener a alguien para la dar la bienvenida a los recién llegados y redirigirlos a donde hicieran más falta. Si no, mucha gente con ganas de ayudar podría verse abrumada con la conversación y los proyectos ya empezados.

El sentimiento de urgencia puede provocar querer empezar proyectos que ya existen. Siempre será mejor empezar donde otro lo dejó que desarrollar un herramienta desde cero, uno de los lemas del software libre aplicable a cualquier tipo de investigación. Muchas veces no hará falta escribir ni una línea de código, sino pensar cómo usar las herramientas existentes.

Como Sasha comentó en una entrevista, era importante centrarse en proyectos realistas que pudieran funcionar directa y rápidamente, especialmente en una emergencia como aquella, donde muchas personas quedaron aisladas sin agua ni luz durante días. Los proyectos que tendrían mayores posibilidades de funcionar eran aquellos que se basasen en necesidades reales de grupos trabajando en lugares específicos.

Unos días después, HurricaneHackers se unió a la iniciativa Sandy CrisisCamps, que consistía en una serie de hackathons promovidos por CrisisCommons en diferentes lugares del mundo para ayudar a las víctimas de Sandy, y empezamos a organizar un hackathon en el MIT Media Lab, que coorganicé con Denise Cheng. La tarea que teníamos por delante era mucho más compleja que con el hackathon de OccupyData: había víctimas, gente necesitada y mucha urgencia.

Aunque organizamos el evento invitando a expertos en emergencias y a desarrolladores de software (hackers) para intentar conseguir resultados tangibles, los resultados del hackathon no llegaron a producir ninguna herramienta lista para ser usada. Probablemente porque los datos y la situación eran demasiado complejos y porque entraron en juego problemas de coordinación con otros grupos en la definición misma de los problemas a solucionar.  Como advierte un informe de la Universty of Missouri “no intentes organizar una web de ayuda a no ser que estés preparado para ocuparte de ella 24 horas al día”.  Al menos el proceso sirvió para concienciar a los que asistieron al hackathon de la complejidad de desarrollar software para este tipo de situaciones y para revivir temporalmente el grupo de CrisisCommons Boston.

Una de las lecciones que aprendimos de este hackathon, junto con Denise Cheng, fue que es muy importante explicar a los periodistas y a los lectores que se habían acercado a la iniciativa que estábamos desarrollando prototipos y no herramientas listas para usar que sustituyeran a organizaciones como FEMA o Cruz Roja. El proyecto #SandyAid, por ejemplo, quería proporcionar ayuda a víctimas de Sandy a través de Twitter, pero estaba lejos de estar terminado y de tener un equipo detrás que pudiera proporcionar la ayuda y soporte necesarios. Otros proyectos promovidos por ciudadanos proporcionaron ayuda in situ y siguen en activo a día de hoy como por ejemplo una de las secuelas más fecundas de Occupy: occupysandy.net.

La lista de proyectos sobre mapas Sandy Crowdsourced Data Projects: Stage & usage
La lista de proyectos sobre mapas Sandy Crowdsourced Data Projects: Stage & usage

Uno de los proyectos del hackathon, realizado por Mayo Fuster, se dedicó a documentar cómo y cuánto eran usados los diferentes proyectos basados en la recolección colaborativa de datos (crowdsourced). Una de sus conclusiones fue que los proyectos más localizados tenían más probabilidades de ser usados que los más generalistas. Así pensar en un proyecto que quiera mapear toda la información sobre el huracán Sandy en la costa Este de EE. UU. (megalomanía no infrecuente en muchos hackathons) tiene menos probabilidades de funcionar que un pequeño proyecto sobre una ciudad afectada, donde los propios ciudadanos paticiparán más ávidamente.

Otros proyectos tuvieron mucho más largo recorrido hasta poder ser usados. Remembers site sí que llegó a ser un prototipo listo para su uso, gracias a la perseverancia de Sasha. Remembers es una web de homenaje a las víctimas fallecidas en el huracán y que es fácilmente editable a través de un googledocs. El software permite hacer otras webs de homenaje con un simple click y rellenando una nueva hoja de cálculo en googledocs.

Incluir en investigaciones de largo recorrido breves periodos de intensidad (sprint), mediante un hackathon por ejemplo, puede ayudar a introducir nuevos agentes e ideas que mejoren y hagan la investigación más rica. Estos sprint son lugares idóneos para dar lugar a ideas innovadoras y encontrar soluciones inesperadas. Como hemos visto, pasado este periodo de intensidad inicial hará falta tiempo para darles forma y llegar a un prototipo usable. Documentar, hacer rápidos tests y difundir son buenas prácticas para probar si las herramientas desarrolladas son útiles. Esto ofrece la posibilidad a que otros investigadores se sumen al proyecto y colaboren.

La respuesta a este texto llega el jueves 13 de febrero a las 9.00h en el blog de voragine.net.

Entregas anteriores de la serie:

  1. Investigar (es ir) haciendo y compartiendo: Demo or die, en numeroteca.org.
  2. Investigar sin darse cuenta: #meetcommons, acción y documentación colectiva, en voragine.net.
  3. Investigar (es ir) haciendo y compartiendo: Public Lab y PageOneX, en numeroteca.org.
  4. Investigar sin darse cuenta: archivos personales, en voragine.net
  5. Liveblogging, cómo documentar en directo en numeroteca.org
  6. Espacios autónomos de experimentación e investigación en voragine.net

Liveblogging, cómo documentar en directo

Este post es parte de la serie “Investigación colaborativa, divertida, barata, transmedia. Otras formas de entender la investigación” publicada a modo de cruce de posts entre numeroteca.org y voragine.net. Este trabajo se enmarca dentro de un estudio sobre Investigación en red coordinado por Mayo Fuster Morell parte de un proyecto más amplio sobre Juventud, Internet y Política bajo la dirección de Joan Subirats en el marco del grupo IGOPnet.cc, con la colaboración de Montera34, para la Fundación Museo Reina Sofía sobre adolescencia y juventud. #otrainvestigación

All those moments will be lost in time, like tears in rain. Time to die.
Blade Runner

Casi cada día hay una o varias ponencias impartidas por algún invitado o investigador en alguno de los 26 grupos de investigación del MIT Media Lab. A eso hay que sumar los diferentes  eventos de carácter informal pensados para que los investigadores de diferentes grupos se conozcan entre sí. Se quiere construir un ambiente propicio para que unas disciplinas “polinicen” a otras y que surja la colaboración entre personas. Aun perteneciendo a la academia, al fin y al cabo Media Lab está en el MIT, intenta escapar de la ortodoxia de la investigación.

A las charlas que se organizan en el MIT Media Lab hay que sumar el resto de actividades que ocurren en el campus de MIT o en la vecina universidad de Harvard. Capturar y nutrirse de toda esa cantidad de información es una tarea imposible. Si alguien fuera a todos los eventos no tendría tiempo para hacer nada más. Para hacer frente a esa situación, aunque no solo por eso, dentro del Center for Civic Media se ha extendido la costumbre de pedir que alguien transcriba una charla cuando uno mismo no puede asistir al evento, lo llaman liveblog. Este tipo de documentación en directo se ha extendido a otras áreas, como reuniones internas o lluvia de ideas. El documento generado sirve para fijar la información en directo y en internet, y permite ampliar la difusión de la misma.

Una conferencia o una presentación de un libro son eventos efímeros. Habitualmente se les dedica un gran esfuerzo e intensidad para comunicar una información. Es una pena que una vez que han terminado se pierda lo allí ocurrido, como se pierden las vivencias del replicante al final de la película Blade Runner. Para contrarrestar esto, en lo que a divulgación científica se refiere, siempre ha existido la posibilidad de tomar notas, transcribir la charla, o bien, que el evento haya sido convenientemente grabado.

En el MIT Center for Civic Media existe la costumbre de transcribir colectivamente y en directo, liveblog en inglés, las charlas y presentaciones de los ponentes que pasan por allí. Como apuntan Matt Stempeck y Ethan Zuckerman, ávidos livebloggers, de este modo se consigue producir un tipo de documentación de encuentros y presentaciones que de otro modo no existiría. Esto permite ampliar la audiencia de un evento a gente que no haya podido asistir y genera un artefacto, un texto, que puede ser leído y reutilizado.

Siempre ha existido la posibilidad de grabar un evento, y desde hace menos tiempo la tecnología ha hecho asequible y sencillo incluso retransmitirlo en directo, en streaming, sin necesidad de grandes conocimientos técnicos. Sin embargo un liveblog genera una documentación instantánea mientras se produce el evento que es más sencilla y rápida de revisar que el formato audio o vídeo.

Las herramientas de software que permiten la edición simultánea de documentos de texto han revolucionado la forma en que se toman notas. Ver a varias personas transcribiendo por separado, cada uno en su ordenador portátil sin compartir lo que escriben, se ha convertido en algo obsoleto, al menos en el contexto del Center for Civic Media. ¿Por qué no intentar juntos una más completa y mejor documentación que luego se puede compartir con el mundo?

Stempeck y Zuckerman proponen un mínimo de 3 personas para hacer liveblogging mejor y más eficientemente:

Antes de comenzar cualquier evento alguien comparte el enlace al documento online que se va a utilizar. Programas como Googledocs o Etherpad permiten a varias personas editar simultánea y colaborativamente el mismo texto a través de un navegador de web estándar. Este software permite también un canal de chat paralelo a la charla que permite comentar y aclarar cuestiones entre los transcriptores. Para no tener que deletrear decenas de letras incomprensibles (https://docs.google.com/document/d/1dsyL8R3Jt7KIGK…) el creador del documento puede compartir por Twitter o enviar un email con el enlace, o bien crear una dirección acortada legible tipo http://bit.ly/linkaestacharla.

Habitualmente, el que empieza es el transcriptor, aquel que transcribirá lo más fiel que pueda lo que el orador está diciendo. No se trata de escribir palabra por palabra el discurso, a veces habrá que parafrasear para clarificar lo que dice. También se pueden incluir citas literales, convenientemente marcadas entre comillas. En ponencias prolongadas, y dependiendo de la pericia del transcriptor, será necesario más de un transcriptor para poder hacer turnos. A veces 2 transcriptores pueden ir turnándose por frases o ideas.

El buscador de links es el encargado de buscar enlaces relacionados o fuentes originales sobre lo que el orador está hablando. Dependiendo del tipo de evento esta función puede ser muy laboriosa o ligera.

El pulidor presta atención al evento en su conjunto y va limpiando y reordenando lo que ha sido transcrito. Su función es la de convertir un texto que no tiene por qué ser coherente en algo organizado y legible para alguien que no haya estado en el evento. Para ello puede añadir información de contexto o eliminar párrafos innecesarios. Habitualmente va 10 ó 20 minutos detrás del transcriptor para no pisarse en la edición de las mismas frases.

Mediante este método, unos minutos después de terminado el evento, preguntas y respuestas incluidas, puede publicarse un resumen muy completo de lo que ha ocurrido. Esta inmediatez es especialmente útil en el contexto de conferencias con muchas ponencias o de cualquier vida ajetreada, donde no hay tiempo para revisar nuestras propias notas y publicarlas. El esfuerzo colectivo puede ayudarnos a publicar algo que de otra manera se quedaría en nuestra libreta o disco duro sin ver la luz. Hará falta un editor final que revise y dé la forma final al texto, pero el proceso distribuido facilita la tarea.

La ponencia, ahora plasmada en forma de texto, es más fácil que sea leida y usada (remezclada). Los 30-40 minutos de palabras en el aire han quedado traducidos a un texto. Del texto se pueden extraer párrafos o frases para difundir a través de email o redes sociales, o resumir y contrastar con otras ponencias. Se facilita que la información fluya por diferentes canales y plataformas online, posibilitando, o mejor dicho ayudando a que surjan narrativas transmedia. Tener la charla transcrita tan solo unos minutos después facilita el proceso transferencia de conocimiento, cuando todavía las ideas están calientes en nuestra cabeza.

Este proceso es válido también para reuniones internas de un grupo, donde antes era necesario la figura del secretario o tomador de notas que levantaba acta. Ahora esa labor puede ser compartida por diferentes participantes, convirtiendo las notas en una construcción colectiva que puede servir también para estructurar la reunión. Es especialmente útil para reuniones en conferencia, donde los presentes no comparten el mismo espacio físico.

El cambio en la dinámica de documentación de la investigación es reseñable. Ya no se documenta para después compilar y difundir. La documentación, con leves retoques, es la difusión a la vez que el archivo del proceso.

Usamos este tipo de tácticas de documentación en diferentes grupos de investigación. Son especialmente idóneas cuando se dispone de poco tiempo y la estructura de la organización es ligera sin roles claramente definidos. Este era el caso de Occupy Research.

Occupy Research: red abierta y distribuida

Unas semanas después de que el movimiento Occupy empezara a andar en septiembre de 2011 en Nueva York, un grupo de gente conectada con el movimiento puso en marcha Occupy Research. El objetivo era activar una red de personas para coordinar las diferentes investigaciones que se estaban haciendo desde dentro y fuera del movimiento sobre Occupy. La idea era compartir y hacer distribuida y abiertamente lo que algunos grupos y personas ya estaban realizando, entre otras cosas: entrevistas en las acampadas o archivos de tuits (mensajes de Twitter). El objetivo era estudiar el movimiento Occupy a la vez que “ocupar” (occupy) también la investigación. Esto es, aplicar prácticas horizontales y distribuidas a la investigación y liberar con licencias libres lo investigado, al hilo de la filosofía de lo que estaba sucediendo en las acampadas y plazas.

Después de algunas reuniones en Boston, y en algunas de la acampadas que habían establecido sus propios grupos de trabajo de investigación, relacionados o no con la iniciativa Occupy Research, se organizó una quedada online para conocerse y compartir los intereses de cada uno. Unas 30 personas desde varios países hablaban a la vez que tomaban notas online en un documento compartido. El enlace a las notas de la reunión se difundía a través de una wiki, de la lista de correo y de las redes sociales del momento (Twitter, Facebook). No era necesario que “pasar a limpio” las notas: el documento que servía para organizar el orden del día de la reunión era el lugar donde se anotaba todo lo que se decía: presentación e intereses de cada uno, objetivos del grupo, investigaciones en marcha o propuestas de grupos de trabajo. Los que no habían podido asistir a la reunión podían enterarse de lo que había ocurrido y ponerse al tanto.

En una estructura ligera y distribuida como Occupy Research era necesario que el mantenimiento fuera distribuido y descentralizado. Cuanto menos carga de trabajo, mejor para permitir su funcionamiento, ya que no contaba con nadie que se dedicara en exclusividad a ello. Aún así era necesario que alguien se encargara de alimentar y apoyar esa red para que continuara activa: organizando las llamadas y anunciándolas o limpiando y reorganizando los contenidos en la wiki, un trabajo de editor.

Muy pronto la wiki tuvo que protegerse de los trolls mediante una contraseña, para prevenir la vandalización de los contenidos. Como estaba puesto en uno de los documentos compartidos: PLEASE DON’T TWEET LINK TO NOTES UNTIL AFTER CALL – NO TROLLS! Es el peligro de lo abierto, pero también síntoma de que el proyecto ha atraído suficiente atención como para que alguien lo quiera estropear. Como regla general suele ser mejor dejar que los usuarios contribuyan libremente hasta que esto pueda suponer un problema, en vez de cerrar la libre participación desde el inicio.

[En el próximo capítuo veremos cómo se puede mantener viva una red de investigación distribuida: los pros y los contras de los hackathons.]

La respuesta a este texto llega el jueves 6 de febrero a las 9.00h en el blog de voragine.net.

Entregas anteriores de la serie:

  1. Investigar (es ir) haciendo y compartiendo: Demo or die, en numeroteca.org.
  2. Investigar sin darse cuenta: #meetcommons, acción y documentación colectiva, en voragine.net.
  3. Investigar (es ir) haciendo y compartiendo: Public Lab y PageOneX, en numeroteca.org.
  4. Investigar sin darse cuenta: archivos personales, en voragine.net

3 años de movilizaciones en red, 3 años de gráficos de portadas con PageOneX

globalrev-banner

He pasado los dos últimos días en el encuentro/congreso #GlobalRev, hablando de cómo investigar, entender y apoyar las movilizaciones en red: desde la primavera árabe de Túnez y Egipto a las últimas movilizaciones en Brasil, pasando por 15M, occupy y Turquía. He desvirtualizado con mucha alegría (un verbo que se usa para decir que has visto en carne y hueso a gente de la cual solamente conocías su avatar en Twitter) a muchas personas que he seguido en la distancia desde Boston y a través de las cuales he seguido, visto y entendido más el 15M: @suysulucha y sus video streamings o a casi todo el equipo de DataAnalysis15M.

El objetivo, en pocas palabras, es organizar una plataforma de investigación abierta sobre los movimientos sociales en red que estudie comparativamente los casos de los 3 últimos años. En muchos aspecto me recuerda a la red que se intentó establecer con OccupyResearch: compartir datos, herramientas, reflexiones, ideas para pensar e interconectar las diferentes luchas. ¿Qué se puede aprender de los aciertos y errores de OcccupyResearch? ¿Cómo de abierta puede ser una red de investigación? ¿Cómo mantener viva la ilusión y las ganas de trabajar juntos? OccupyResearch funcionó para poner en contacto a diferentes personas que estaban investigando occupy por separado y generar grupos de trabajo que llegaron a desarrollar proyectos como la Occupy Research General Survey o los hackathons de OccupyData. Sus datos y metodologías aún se siguen usando y, según he visto estos días, son fuentes de inspiración. OccupyResearch no fue tan efectiva a la hora de lograr una colaboración estable y de largo recorrido entre sus participantes, y su participación fue poco a poco decayendo. Actualmente la red está casi inactiva, aunque algún nodo se mantenga activo fuera de la red inicial. Habría que poner por escrito en algún momento todo lo que hemos aprendido de la experiencia.

Volvamos al encuentro #Globalrev: si quereis ver lo que se habló el primer día de presentaciones de diferentes países, podéis consultar los estupendos liveblogs en ictlogy.net o las notas que tomamos colectivamente en un etherpad. El segundo día se dedicó a pensar conjuntamente cómo debía ser esa plataforma/grupo de investigación comparativa internacional. Un proyecto ambicioso, que cuenta con Javier @Toret y @DataAnalysis15M como núcleo duro, lo cual es esperanzador a la hora de pensar en un plan de investigación que abarca tantos contextos diferentes (de momento 7 países). Esperanzador porque hará falta un motor fuerte y organizado para coordinar y dinamizar a todo aquel que se sume al proyecto, y su recientemente autopublicada investigación “Tecnopolítica y 15M, la potencia de las multitudes conectadas. El sistema red 15M, un nuevo paradigma de la política distribuida” (junio 2013) es un buen precedente que ha consiguido dar sentido a la complejidad de millones de tuits, hashtags y movilizaciones en las calles.

Pero yo escribía este post para “hablar de mi libro” y de la alegría que ha sido ver las diferentes visualizaciones de PageOneX en varias de las presentaciones. Haciendo repaso mentalmente me daba cuenta de que había al menos una visualización de portadas de prensa por cada uno de los movimientos en red estudiados, menos del #yosoy132 mexicano. La serie se completó justo cuando estaba llegando a Barcelona hace dos días y recibí un email de Benjamín Arditi contándome que había acababa de completar un primer análisis de portadas sobre #yosoy132 en la prensa mexicana.

De hecho, el origen de PageOneX fue durante la primera semana del 15M, y surgió para medir y mostrar visualmente la escasez de cobertura de los medios tadicionales sobre un movimiento social entonces recién nacido. Estos casi 3 años de movilizaciones también han sido la evolución de la herramienta de análisis de portadas: desde una imagen en un tuit hecho descargando y organizando las portadas “a mano” hasta una herramienta online que cualquiera puede usar. He pensado que sería interesante repasar estas visualizaciones, verlas juntas y recordar cómo fueron realizadas y ver cómo la prensa escrita cubrió estos movimientos sociales en red.

Justo hoy, en unos de los infinitos pads en torno a los que se organiza #globalrev y DatAnalysis15M (o GRRN), @Toret había recopilado ya estos gráficos en una única lista, bendita lógica distribuida. Sin un estilo uniforme, pero con los mismos mimbres, pongo todas las imágenes juntas.

15M: blackout de los medios y método casi artesanal

ss
Uno de los primeros gráficos: las fechas van en vertical, las áreas son opacas. Se hizo descargando a mano cada una de las portadas y reorganizándolas después en inkscape.

rtj
Reeleboración del gráfico sobre 15M y Twitter. Los datos de twitter eran pantallazos de la web de la desaparecida trendistic.indexrank.com, de ahí su pixelamiento. Elaborado en inkscape a partir del archivo generado con la primera versión de PageOneX escrita en Processing. Para medir las áreas utilizaba un plugin de inkscape y las calculaba mediante una hoja de cálculo.

 Primavera árabe. Túnez, Egipto, Libia.

svsvsvsv
A raiz de los gráficos sobre el 15M, iecah.org me encargó monitorizar la cobertura de prensa sobre la primavera árabe en la prensa española. El proceso era el mismo: Script en Processing me generaba un fichero svg, que desde Inkscape podía usar para codificar las portadas. Hice un minisite para publicar los diferentes análisis. en este caso se analiza: Egipto y Libia.

Occupy. USA.

ww
Nunca había hecho un análisis con tantas portadas: periódicos estadounidenses subriendo el movimiento Occupy.  Era demasiado para manipularlo en un único archivo de svg y tuve que dividirlo en partes. Datos de Twitter de r-shief.org, se aprecia como los tuits comienzan a aparecer en el archivo una semana después de comenzadas las movilizaciones, justo cuando la gente de r-shief empezó a recopilar los datos.

#direnGezi #OccupyGezi. Turquía

csc
Hecho a partir de 2 hilos en pageonex.com: OccupyGezi en periódicos internacionales y OcccupyGezi en periódicos turcos en colaboración con @matrushka y @bilgenkurt, datos de Twitter de Topsy. Todo ello unido en inkscape pasando por gnumeric.

Brasil protests #VemPraRua #BRevolução

protests-vandals-brazil-june2013
Protesters or Vandals? Para responder al debate de cómo los medios narraban las protestas, Débora Leall usó la ya para entonces en march versión beta de pageonex.com online. Hilo disponible en PageOnex: Violence x Protest. Los datos deTwitter son de topsy y los de las protestas de periódicos y Wikipedia. Todos ls datos se juntaron en Inkscape pasando por gnumeric.

 #YoSoy132. México

Cobertura en portadas de las movilizaciones de #yosoy132 en méxico por la prensa mexicana. Realizado por Benjamín arditi en PageOneX. Hilo disponible en PageOneX.com
Cobertura en portadas de las movilizaciones de #yosoy132 en México por la prensa mexicana. Realizado por Benjamín Arditi (politicaviral) en PageOneX. Hilo disponible en PageOneX.com

Éste listado cronológico de visualizaciones es un ejemplo de cómo a medida que PageOneX se convierte en una herramienta más fácil de utilizar más gente puede usarla autónomamente sin depender de mi. En los primeros casos era una labor en solitario: dadas las características de la herramienta. Después, cuando pageonex.com versión beta ya estaba activo, mi papel ha podido pasar a ser el de guía, apoyo o compilador para generar las imágenes finales, pero no he tenido que codificar las portadas (portadas de periódicos turcos, periódicos brasileños). En el caso de México no he tenido más que imprimir pantalla.


Actualización 4 noviembre 2013: el trabajo que queda pendiente es poner en formatos visualmente comparables las diferentes visualizaciones; completar el estudio con la prensa local en los países (primavera árabe) de los que no se ha analizado: y hacer un análisis cualitativo de cómo era la cobertura en cada caso: favorable, desfavorable, etc. Como algunas visualizaciones son previas al lanzamiento de pageonex.com habrá que recodificarlas de nuevo en la nueva plataforma. Si alguien se anima a participar que me lo haga saber, ahora PageOneX permite que varias personas codifiquen un mismo hilo.