La radio del ascensorista de Begoña

El ascensor que te sube a Begoña desde el Casco Viejo es de pago. Arriba las ventanas no se abren y está lleno de moscas, …

Bilbao tomado

Defendiendo la cultura 1

Defendiendo la cultura 1

Iré acualizando este post con las imágenes de Bilbao con motivo del Global Forum Spain que ocurre estos días en al ciudad.

Efímeros

Fútbol en el parking por donde pasará el futuro Canal de Deusto, Bilbao.

¿Por qué colaboro con #QuerellaBárcenas?

Un año #querellabarcenas

Texto publicado en el artículo colectivo Un año de la #QuerellaBárcenas. Quiénes somos y por qué hacemos esto para explicar por qué colaboro junto con otros voluntarios con el proyecto colectivo #QuerellaBárcenas.

Desde antes del estallido de la burbuja inmobiliaria hemos ido documentando en Basurama los efectos en el territorio de los excesos del desarrollismo en forma de desarrollos urbanísticos o de aeropuertos vacíos. Lo que mostraban los conocidos como “papeles de Bárcenas”, cuya denominación más adecuada es la de “ supuesta contabilidad B del PP”, eran los flujos de dinero desde las empresas constructoras adjudicatarias al Partido Popular y desde el partido a sus miembros. De este modo se podían entender esos planes megalomaniacos (PAUs, autopistas) como el resultado directo del dinero en el bolsillo de los políticos (o en una cuenta en Suiza), y no solo por delirios de grandeza o gratificaciones en forma de puestos en consejos de administración junto con algún regalo.

Por otro lado, desde que se conoció el caso Gürtel he ido siguiendo casi todo lo que se publicaba al respecto. Los datos contenidos en los papeles de Bárcenas venían a ser una especie de piedra Rosseta de la corrupción: 28 años de cifras, políticos y empresarios. Tuve la suerte de toparme con #AdoptaUnCorrupto, un proyecto colaborativo para pasar a limpio y en formato reutilizable los datos contenidos en los papeles de Bárcenas. Participé ayudando a limpiar algunos errores que la transcripción de El País contenía y añadiendo algunos datos más. El siguiente paso era visualizar los datos para poder entenderlos en su conjunto, ya que no encontré ninguna visualización en la prensa que los mostrara todos.

Desde hace unos meses participo en #QuerellaBárcenas, mi principal motivación es ayudar a investigar y a comunicar los miles de datos que contiene este macroproceso. Espero poder ayudar a desarrollar herramientas y visualizaciones que expliquen estos datos y los hagan accesibles a cualquier persona interesada.

(…) Puedes informarte de la #QuerellaBárcenas en nuestra web. También estamos en las redes, twitter y Facebook. Esta querella es cosa de todos, así que cada pocos meses convocamos asambleas abiertas donde se puede participar. También intentamos participar regularmente en charlas y actos donde abogados y otros miembros de la Querella informan del estado de las cosas. Aquí, una de las últimas. En cualquier momento puedes contactar con el equipo de comunicación de la Querella a traves de este formulario. Gracias.

Visualización de la contabilidad B del PP

Rincones de Bilbao

Empiezo serie de imágenes de Bilbao que iré publicando cada viernes.

Conclusiones #otrainvestigación: inventa las herramientas que quieras usar

Este post es el último 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.

Este informe incluye varias investigaciones de temáticas muy diferentes entre sí que se desarrollan en entornos igualmente diversos, entre otros: Nathan Matias, investigador en el MIT, escribe un programa que le ayuda a codificar y visualizar quién escribe las noticias según su género; Public Lab desarrolla opensource hardware y software para monitorizar el medio ambiente al servicio de grupos de base y se financia habitualmente por crowdfunding; #meetcommons es un espacio y tiempo de encuentro pensado para experimentar metodologías de organización e investigación de un grupo abierto formado en torno a las charlas online de ThinkCommons; Eventweet es una herramienta que convierte en archivo navegable los tuits que de otra manera quedarían perdidos; los hackathons de OccupyData y Hurricanehackers son eventos pensados para condensar la creatividad y unir a un grupo heterogéneo de personas durante un breve periodo de tiempo; Obsoletos es un colectivo que difunde todo lo que investiga en su blog, donde recoge tanto proyectos propios como ajenos; voragine.net es un blog personal que recopila en forma manual todas las soluciones de programación de código que Alfonso Sánchez Uzábal va aprendiendo y desarrollando.

Todos estos casos comparten una preocupación por desarrollar las herramientas que les permiten realizar su investigación. Investigar, dialogar y difundir son parte de una misma acción para compartir lo investigado y atraer la atención del público u otros investigadores. Se publican las instrucciones o el código usado para investigar para que puedan ser replicadas. El uso de licencias libres es denominador común.

Todos ellos muestran también una preocupación por los canales y métodos en los que se difunde lo investigado. Escribir un artículo en una revista especializada no es el objetivo principal o prioritario de ninguno de estos casos. Por ejemplo, Nathan Matias monta una mini web para publicar sus visualizaciones de datos y asociado con un periódico, The Guardian, publica ahí sus resultados. #meetcommons mientras, usa Eventweet para archivar y difundir un diálogo online que se mantuvo en Twitter y permitir una multi-narrativa del evento.

En la mayoría de los casos se busca generar entornos de trabajo que permitan la innovación y el fluir de información: los hackathons de OccupyData o la retransmisión en directo de las charlas (liveblogging) del Center for Civic Media.

No existe una receta única para investigar, pero sí la certeza de que, como en la cultura hacker, a investigar se aprende investigando y explorando los límites de las herramientas de las que disponemos. Llegado al límite: hay que inventar las herramientas que quieras usar.

-

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
  7. Investigación Sprint vs. Investigación de largo recorrido en numeroteca.org
  8. Snippets: un gran repositorio de código distribuido en voragine.net
  9. Conclusiones #otrainvestigación: inventa las herramientas que quieras usar en numeroteca.org

New feature in PageOneX: Switch on and off layers in the data visualization

New feature in PageOneX.com: now you can switch topics on and off in the data visualization just by clicking on the topics in the legend. New …

Vueven los colores a las portadas #colorcorrupción

140213-colorcorrupcion-spain-febrero2014

13 febrero 2014

Tras el climax con la declaración de la infanta (verde) vuelve el resto de casos de corrupción a portada:

  • El País y El Mundo con la imputación de directivos de la CAM (violeta)
  • ABC y La Razón con la imputación del vicepresidente de la junta de andalucía del PSOE (rojo)

Puedes ver la versión interactiva de este gráfico, actualizada día a día, PageOneX.com.

Este post también se publica en colorcorrupcion.tumblr.com.

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. 1 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

Notes:

  1.  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.

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

Investigar (es ir) haciendo y compartiendo: Public Lab y PageOneX

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

Public Laboratory: comparte y cuida a la comunidad de usuarios

The Public Laboratory for Open Technology and Science, o mejor Public Lab, desarrolla su actividad en otro campo completamente diferente al del estudio de los flujos de información: diseña y construye herramientas de software y hardware de bajo coste en torno a temas relacionados con el medio ambiente. Un tipo de ciencia ciudadana, investigación científica desarrollada por científicos no profesionales (ciudadanos), que se desarrolla en formatos abiertos en torno a una comunidad de usuarios-desarrolladores interesados.

Los orígenes del proyecto fueron cuando Jeff Warren, todavía estudiante en Media Lab empezó a experimentar a hacer fotos desde el aire con una cámara compacta normal (=barata) colgada de un globo para producir imágenes aéreas de alta resolución, lo que más tarde sería su tesina de master.  Por aquel entonces se llamaba Grassroots Mapping. Quería desarrollar técnicas y enseñárselas a comunidades de base para que pudieran producir sus propios mapas. La cámara hacía fotos en formato continuo mientras se elevaba: bastaba con unir esas fotos para poder tener el mapa de la zona mapeada.

Con el tiempo las actividades de Public Lab se han expandido a otra áreas de la ciencia, como son la espectrofotometría y la fotografía infraroja, a la vez que siguen compartiendo tanto el hardware y software que desarrollan como los datos que archivan con esas mismas herramientas.

Cuando en 2010 la plataforma petrolífera de BP estalló en el golfo de México, Jeff envió un email a la lista de correo de Grassroots Mapping, creada 6 meses antes, para preguntar cómo se podría empezar a mapear lo que el vertido de petróleo iba a destruir. Unos días después viajó a Nueva Orleans junto con Oliver Yeh y se empezaron a organizar con la Louisiana Bucket Brigade para hacer fotos de antes y de después de que llegara la marea de petróleo a la costa. Hacer las fotos cumplía una doble función: por un lado querían tener la documentación, ya que serían relevantes en un más que probable futuro juicio contra BP y no contaban con las fotografías de los satélites para apoyarles; por otro, el acto mismo de mapear servía para atraer la atención, y la colaboración, de la ciudadanía.

El proceso de hacer las fotos y enseñar a otros la técnica redundó en una mejora de las herramientas y en la creación de una comunidad de usuarios que detectaban problemas y proponía sus propias mejoras técnicas. Es un ejemplo idóneo para entender cómo hay que equilibrar el desarrollo de una herramienta y el cuidado del grupo de usuarios. Es tan importante el desarrollo de una tecnología que la gente pueda usar, porque es sencilla y asequible, como la creación de una comunidad de usuarios que la apoye y la use. En el proceso de diseño es también fundamental contar desde las primeras fases con los futuros usuarios (co-design o co-diseño). La experiencia del mapeado del vertido de petróleo del golfo de México y el trabajo en común fue el germen de Public Lab.

Public Lab como organización (hace poco consiguieron el estatus de organización sin ánimo de lucro en EE.UU.) empezó a andar gracias a el primer premio del News Challenge de la Kight Foundation. Desde entonces han buscado otras fuentes de ingresos para mantenerse, por ejemplo, sus campañas de crowdfunding para desarrollar projectos, como el caso reciente de infragram, o mediante la venta a través de su propia tienda de los productos de ciencia ciudadana que van desarrollando.

La investigación compartida se desarrolla principalmente a través de sus múltiples y abiertas listas de correo, organizadas temática y geográficamente. En su web también publican posts sobre las investigaciones y proyectos en marcha y animan a que cualquiera pueda publicar allí. Los modos de documentar se amplian haciendo que la web entera sea una wiki, esto es, que cualquiera pueda colaborar en editar, añadir y corregir cualquier parte de ella.

saugus-map-3b

Mapa del vertedero de cenizas provenientes de la incineradora de Boston, en la localidad de Saugus, realizado desde una cometa y ensamblado con Mapkintter.org.

Hacer un mapa con este método es ir recomponiendo el terreno a partir de los cientos de imágenes que la cámara tomó en modo automático. Es un proceso que permite el trabajo colaborativo en Mapknitter.org, el software que ha desarrollado para componer ese puzzle de imágenes. Cuando el año pasado hacíamos fotos desde una cometa del vertedero de Boston en Saugus, donde se dejan las cenizas de la aneja incineradora, cumplíamos el doble propósito de estudiar cómo era ese vertedero a la vez que queríamos llamar la atención sobre su existencia y sobre la incineración de residuos. Además, la excursión al vertedero, anunciada públicamente en la lista de correo de Public Lab, era también un evento para enseñar esta técnica a quien quisiera acercarse a participar. El mapa producido quedó publicado con licencia CC-BY en el archivo de mapas de publiclab.org.

Mapa de Saugus en Google Maps. El vertedero no está dibujado.

Mapa de Saugus en Google Maps. El vertedero no está dibujado.

Mapa de Saugus en OpenSteetMap. La mancha marrón es el vertedero.

Mapa de Saugus en OpenSteetMap. La mancha marrón es el vertedero.

Sin embargo, ir al lugar y mapear algo físicamente es sólo una de las formas posibles para estudiar un lugar, a la vez que llamar la atención sobre él. En Google Maps (el que muchos entienden como el mapa online por defecto), el vertedero no aparece y la incineradora es difícilmente identificable como tal. En OpenStreetMap, un mapa construido colaborativamente por usuarios de todo el mundo, algo así como la Wikipedia de los mapas, fuimos nosotros los que dibujamos el perímetro del vertedero para hacerlo visible (la zona marrón). Es un proceso análogo a cuando un usuario corrige o escribe un artículo en Wikipedia: puede estar documentando para sí mismo, pero también sirve para compartir con otros lo que ha investigado.

Algo así me ocurrió en mayo de 2011 cuando iba siguiendo desde Boston todo lo que estaba ocurriendo en Madrid al hilo del movimiento 15M. Empecé entonces mi propio archivo personal de imágenes, documentos y prensa (online, televisión, papel), quería archivar todo lo que estaba aconteciendo. Después de leer varios comentarios sobre la pobre cobertura que las movilizaciones estaban teniendo pensé que se podía enfocar la respuesta como una visualización de datos. Descargué “a mano” las diferentes portadas de los periódicos más importantes, las ordené en una matriz y dibujé unas áreas naranjas allí donde había noticias relacionadas sobre el 15M. Publiqué en Twitter el gráfico y me fui a dormir. Cuando me levanté el viernes por la mañana aquel gráfico se había difundido y republicado en varios medios. Su amplia difusión seguramente se debía a la rapidez con que se leía el gráfico: hasta el jueves 19 de mayo los periódicos no se habían volcado enteramente a cubrir las movilizaciones. Era el inicio de lo que más tarde sería PageOneX.

15m-portadas

Primer tuit sobre cobertura sobre el 15M en las portadas de los periódicos en España hasta el jueves 19 de mayo 2011.

PageOneX: del prototipo a la herramienta buscando usuarios

La buena acogida que tuvo el gráfico sobre la cobertura del 15M me llevó a continuar en el desarrollo de ese tipo de visualizaciones. Al igual que Nathan Matias, con su proyecto análisis de género en las noticias, quería automatizar el proceso de codificación de portadas lo más posible y permitir que otros lo usaran. Lo que había empezado como una respuesta al aparente blackout de los medios de comunicación, se iba a convertir en una de mis principales líneas de investigación.

Las portadas son el lugar donde los periódicos condensan la información más importante del día, y constituyen un elemento muy importante dentro del ecosistema de medios a la hora de definir la agenda mediática. La selección de noticias y su enfoque en la portada configuran su línea editorial, más casi que su línea editorial oficial. Utilizar la cantidad de espacio que ocupan en portada determinadas noticias ha resultado ser un buen atajo para estudiar a qué dedican su atención los periódicos. PageOneX, la herramienta que empecé a desarrollar entonces, automatiza y simplifica el proceso de descarga de las portadas, codificación, análisis y la visualización de los datos.

El proceso de desarrollo se ha basado en los retos y necesidades que aportaban los diferentes casos de estudio que fui haciendo: comparativa de cobertura de noticias en diferentes países; análisis cualitativo (positivo – negativo) de la cobertura sobre un tema; comparativa la cobertura en portadas, mass media, con datos de Twitter, social media;

El paso más trabajoso fue convertir la versión inicail del software, que funcionaba en mi ordenador usando diferentes programas y que requería conocimientos técnicos, en un programa online listo para ser usado por cualquiera. Proceso que llevó más de un año de desarrollo, primero con Ahmd Refat dentro del Google Summer of Code y luego apoyado por el MIT Center for Civic Media con Edward L. Platt y Rahul Bhargava. Recién llegados a una versión estable, lo que hace falta para seguir desarrollando, aprendiendo del ejemplo de Public Lab, es usuarios que la usen para sus investigaciones y que guíen hacia donde debe ir la herramienta. Por ejemplo como con el estudio sobre la cobertura de las protestas de Brasil de junio de 2013 por Débora Leal o recientemente con El Estado del periodismo, que analiza un año de portadas en México, por articulo19.

Superficie dedicada a casos de corrupción clasificado por partido/institución en El País, El Mundo, ABC, La Vanguardia y El Periódico. Del 4 de enero (izq.) al 8 de febrero (dcha.) de 2013.

Ejemplo de PageOneX en uso: Superficie dedicada a casos de corrupción clasificado por partido/institución en El País, El Mundo, ABC, La Vanguardia y El Periódico. Del 4 de enero (izq.) al 8 de febrero (dcha.) de 2013. Más sobre este tema en El Color de la corupción.

-

Cuando se comparten el proceso y los datos de una investigación se está facilitando la inclusión de otros investigadores e interesados en la misma, incluso antes de tener unas conclusiones o resultados terminados. El proceso de investigar se abre de este modo a la colaboración y puede nutrirse de críticas y sugerencias ajenas al mismo. Inicia así la difusión del mismo antes de haber concluido, sin necesidad de emplear recursos extra para publicitarlo. El mejor artículo publicado en una publicación especializada, aunque sea de acceso libre, puede no llegar al público u otros investigadores y no ser el motor de cambio deseado. Tener en cuenta cómo se va a difundir la investigación y convertirla en un proceso abierto aumenta las posibilidades de impacto de esta.

La respuesta a este texto llega el jueves 30 de enero a las 9.00h en el blog de voragine.net
Anteriores posts en esta serie:
1. Investigar (es ir) haciendo y compartiendo: Demo or die (numeroteca.org)
2. Investigar sin darse cuenta: #meetcommons, acción y documentación colectiva (voragine.net)