Trabajando junto con UNICEF en la mitigación de riesgos socio-ambientales en las favelas de Río. Parte II

Esta foto del puente Uga-Uga, en la favela del Morro dos Prazeres, barrio de Santa Teresa (Río de Janeiro), fue tomada cuando la ONG brasileña CEDAPS, con el auspicio de UNICEF y el soporte tecnológico del MIT, comenzó con la puesta en funcionamiento del primer workshop de Mapeo Digital de Riesgos Socio-Ambientales Liderado por Jóvenes en dicha comunidad a mediados del año pasado, al que luego le seguirían otros cuatro –Macacos, Borel, Urubus y Rocinha –. Éste representa tan sólo uno de los tantos peligros potenciales que se ciernen sobre los pobladores de las favelas de Río, y muy especialmente sobre los niños...

En nuestro post anterior prometimos que en esta oportunidad relataríamos cómo en poco más de un mes, entre el primer taller del que participó el equipo del InSTEDD iLab América Latina, en el Morro do Borel, y el segundo, en el Morro dos Urubus, se logró optimizar la usabilidad de la plataforma tecnológica de relevamiento, y que incluso te mostraríamos casos concretos que ilustrasen el impacto tangible de esta iniciativa.

Pues bien, a continuación te presentamos cómo las autoridades municipales, de la mano de Defensa Civil, repararon el puente ni bien se enteraron informalmente de este riesgo socio-ambiental detectado por los propios chicos de la favela.

Resulta muy alentador comprobar que una experiencia piloto que partió de humildes talleres con líderes comunitarios y niños y adolescentes, que se nutrió del trabajo de campo de jóvenes del lugar, está empezando a dar sus frutos concretos. También disponemos de imágenes del saneamiento de un gran basural en Prazeres, que hasta hace poco lucía así:

Y gracias al esfuerzo mancomunado de los propios pobladores de la comunidad y de un equipo de trabajadores provisto por Defensa Civil ahora se ha librado de tantos desechos insalubres, recuperándose de esta manera un valioso espacio público.

Resolviendo problemas técnicos y de usabilidad de la plataforma

Veamos ahora cuáles fueron los problemas técnicos y de usabilidad de la plataforma de mapeo digital de riesgos que fueron detectados por Martín Verzilli y Ary Borenszweig –iLab América Latina– e Ives Rocha y Alexei Dunaway –CEDAPS– luego del taller en el Morro do Borel, y cómo se superaron, lo que permitió que en el siguiente workshop, un mes después, en el Morro dos Urubus, los jóvenes pudieran generar sin ningún inconveniente sus reportes, y que éstos, a su vez, pudieran ser subidos al sitio web satisfactoriamente.

Alexei Dunaway - Ives Rocha (CEDAPS)

Ary Borenszweig - Martín Verzilli (InSTEDD iLab América Latina)

Ives Rocha, encargado de Monitoreo y Evaluación del CEDAPS, narra su experiencia junto con el equipo del InSTEDD iLab América Latina en el despliegue del proyecto de Mapeo Digital de Riesgos Socio-Ambientales Liderado por Jóvenes en favelas de Río de Janeiro, inmediatamente después del workshop en el Morro do Borel.

Por otro lado, Alexei Dunaway, un egresado de la Universidad de Stanford  –Relaciones Internacionales– que trabaja como voluntario en el CEDAPS desde hace unos meses, en esta breve entrevista se refiere a su percepción de aquello que podría mejorarse de la aplicación para que ésta se torne más escalable y abierta al público masivo en instancias futuras.

Y ahora sí, entrando de lleno en el abordaje de los problemas detectados y de los antídotos que se fueron aplicando para superarlos, pasemos a la entrevista a Martín Verzilli, Líder de Proyectos del InSTEDD iLab América Latina, narrando todos los pormenores pertinentes.

Morro dos Urubus

Martín, ¿podrías enumerar cuáles fueron los problemas técnicos y de usabilidad que detectaste después del primer workshop (Borel), y cuáles fueron los antídotos respectivos aplicados para que en el segundo (Urubus) todo funcionara correctamente?

Sí, pero ante todo me gustaría destacar que aquí todo debe ser analizado a la luz de una restricción fundamental del trabajo, que es la limitación temporal, es decir, había que resolver los problemas rápidamente. Si bien –en tren de ponernos exigentes en extremo– podríamos decir que la plataforma, así como quedó luego de las correcciones, todavía dista de ser la ideal, el objetivo era obtener algo suficientemente funcional y “usable”, y que pudiera ser desarrollado en el exiguo lapso de un mes para lograrlo. Éste es un detalle muy importante a la hora de analizar las recomendaciones que hicimos, porque si no hubiera sido ése el caso, el estado ideal al que debería haber llegado la aplicación debería ser otro... Ello pone de relieve lo importante que es el concepto de que el diseño de interacción es una actividad contextual: no existe una solución ideal en abstracto, para cualquier tipo de escenario, sino que debes analizar cuáles son tus problemas hoy y cuál es el universo de soluciones factibles para este tiempo y este lugar.

Pues bien, teniendo en cuenta esto, la mayoría de nuestras sugerencias giraron en torno a simplificar y a remover elementos superfluos de la interfaz, o que no fueran imprescindibles. Partir de un conjunto muy simple de funcionalidades, los más sencillas posible, y poder concentrarlas todas en una aplicación reducida. De esta manera se logran dos cosas: mientras uno tiene menos elementos en una interfaz, y menos factores en juego, más simple es para el usuario entenderlo, y, a la vez, más simple es para un desarrollador pensar todas las posibles formas en las que esa interfaz podría llegar a fallar; entonces, es más fácil lograr llegar a buen puerto, a un buen producto, cuando se cuenta con un diseño más simple, con menos componentes, más despojado...

OK, hecha esta aclaración, pasemos entonces a los distintos problemas detectados y a sus soluciones respectivas.

1. Lo primero que traía problemas en cuanto a la usabilidad era que la versión que había antes de que nosotros fuéramos incorporados al proyecto permitía que los usuarios recorrieran varias pantallas de la aplicación en cualquier orden, y pudieran avanzar y retroceder a través de esas pantallas constantemente, a voluntad. Si bien esto –la navegabilidad irrestricta–, a priori, pareciera ser una ventaja, una libertad de uso deseable, en realidad es contraproducente... Ello provocaba que el foco del usuario se dispersara, ya que se le agregaba un paso de toma de decisión absolutamente innecesario en esa instancia del procedimiento. Era preciso simplificar, buscando que el cambio implicase eliminar funcionalidades superfluas en vez de agregar componentes nuevos. Eso repercutiría en la ganancia de tiempo, y, por ende, en la factibilidad de la solución. Las pantallas eran las siguientes: uno entraba a la aplicación para crear un reporte, y debía completar los campos de tres solapas: a) Ubicación; b) Título / Descripción del riesgo / Tag; c) Elemento multimedia (foto o video). Entonces uno podía ir saltando de una pantalla a la otra, y los chicos se la pasaban haciendo eso, y nunca terminaban de cerrar ningún reporte...

Captura de pantalla de Android que muestra la interfaz anterior de la aplicación

La solución que habíamos barajado inicialmente había sido incorporar todo en un modo secuencial de pantallas. Sacas la foto, aprietas “Siguiente”, llenas la información, nuevamente “Siguiente”, permites que el GPS detecte la ubicación, y listo. Lo que finalmente terminamos haciendo, consensuándolo con el equipo de desarrollo del MIT, fue incluir todo en una sola pantalla, en la que naturalmente uno va leyendo de arriba hacia abajo.

Captura de pantalla de Android que muestra la interfaz actual de la aplicación 

2. La segunda dificultad superada fue una combinación de problemas técnicos y de usabilidad, que repercutía en la posterior subida eficiente del componente multimedia (foto y/o video). Algo que descubrimos observando el trabajo de campo de los jóvenes y viendo cómo usaban la aplicación fue que como había dos campos, uno para título y otro para descripción del riesgo detectado, eso les resultaba un tanto excesivo, ya que estabábamos forzando al usuario a llenar un campo más, cuando no es tan fácil tipear en un teclado touch, y además lo que terminaba pasando era que siempre el título era parte de la descripción, o tener que dirimirlo los confundía, o les hacía perder tiempo innecesariamente. Entonces decidimos reducirlo a un único campo, cosa de exigirle al usuario un único input, por un lado, y por el otro, tener la interfaz más limpia. Seguimos guiados por el mismo principio regente de simplificar que te había mencionado al principio.

3. La aplicación originalmente permitía subir tanto una foto, sacándola en el momento o bien eligiéndola de una galería de fotos y agregándola posteriormente, como un video, pero las últimas dos opciones no estaban funcionando. Entonces propusimos que nos concentráramos en el caso principal (foto sacada en el momento de creación del reporte) y descartáramos las otras dos, por ahora. Seguimos achicando. Eso nos permitió desplegar todo lo relativo a multimedia en una misma pantalla. El título, el ícono de una camarita... Puedes verlo aquí:

Finalmente quedó el título del reporte, un campo donde se indica si el GPS ya ubicó la posición del celular, el botón para la foto y los tags. En la versión anterior había componentes extra que distraían. Éste es un ejemplo que involucra ambos problemas: técnico y de usabilidad. La solución a la que arribamos simplificó la interfaz, permitiendo una sola opción, por un lado, y por el otro, le facilitó al equipo técnico concentrarse en que eso funcionase, lo que obviamente insume menos tiempo que enfocarse en que tres cosas anden bien simultáneamente...

4. Fíjate en la versión anterior, y vas a ver que la pantalla está prácticamente vacía, y hay un botón que dice “Localización”. Bueno, ahí se supone que hay un mapa... Ahora bien, como estos celulares Android terminaron siendo utilizados en lugares que carecían de conectividad a internet, ya sabíamos que no se podría usar el mapa en el campo. Por lo tanto, en vez de ayudar, porque eso te permite ver el mapita y el punto en el que tú te encuentras en ese momento, esa funcionalidad entorpecía la usabilidad... Confundía, porque uno veía un gran fondo gris que no servía para nada... Entonces, la sugerencia fue que si no íbamos a poder ver mapas durante el trabajo de campo, no mostráramos un espacio gris. Que sólo nos limitáramos a lo que pudiésemos ver. Por lo tanto, la funcionalidad original se transformó en un texto que dice “Buscando...”. Éste es un claro ejemplo de cómo el tiempo pesa en estas decisiones, porque la verdad es que reducir el tema de la ubicación a un texto no es lo ideal... Pero la complejidad técnica que hubiese requerido poder ver mapas en lugares sin conectividad habría tornado infactible su resolución en el escaso tiempo del que disponíamos.

5. Y eso se relaciona con otro de los problemas de usabilidad: el GPS. Por un tema técnico, lleva un buen rato obtener la ubicación del celular vía GPS. Había que pedirles a los jóvenes que permanecieran parados en esa pestaña de “Localización” durante un buen rato, de entre 1 minuto y 1 minuto y medio, hasta que el satélite geo-localizase el celular. Si bien no parece tanto tiempo, ten en cuenta que tienen que estar más de un minuto mirando el celular, sin moverse, que encima se trata de niños y adolescentes inquietos, que están recorriendo su comunidad, en un workshop, que es una actividad que naturalmente provoca mucho entusiasmo...

Entonces acá seguramente la solución provino más del lado humano que del técnico, como pedirles a los chicos que tuvieran paciencia, ¿no..?

No, fíjate qué interesante... Si bien uno no puede luchar contra ese delay impuesto por una cuestión técnica insalvable, sí podíamos trabajar en reducir lo que generalmente se denomina “user percieved waiting time”, o sea, el tiempo que el usuario percibe que está esperando. Acá había dos problemas: dejar esperando al usuario durante 1 minuto o más, y el otro problema es que ése era el primer paso de la creación del informe, y además, para colmo, si el chico pasaba a otra pestaña, el proceso se interrumpía, por lo cual había que comenzar de nuevo y volver a esperar. Volviendo a tu pregunta... Cuando uno se topa con problemas de esta naturaleza se le abren dos caminos: uno es echarle la culpa al usuario y pedirle que modifique su comportamiento, lo cual no nos parece adecuado; y el otro consiste en tratar de usar más la cabeza y pensar cómo se puede mejorar la situación sin modificar artificialmente el comportamiento del usuario. 

Confieso que has captado toda mi atención... Estoy muy intrigado por saber qué hicieron...

Algo muy sencillo... Por empezar, partimos de la idea de no obligar al usuario a estar mirando su celular sin hacer nada durante ese minuto, mientras la aplicación localiza al aparato, que es lo que pasaba con la versión anterior... Lo que hicimos fue cambiar el orden del procedimiento... Apenas uno comienza a crear el reporte, desde ese momento empieza a buscarse tu ubicación. Originalmente no era así. No se lo hace esperar al usuario hasta que no termina de llenar los campos, de ingresar toda la información: poner el título, sacar la foto y agregar alguna etiqueta (si quiere), y apretar “Grabar”. Recién ahí, si todavía el GPS no logró ubicarlo, le aparece un mensaje que dice: “Por favor, espera, que tengo que terminar de localizarte”, y además se le explica por qué es importante que espere, en ese mismo mensaje: “Es importante que te quedes quieto en el lugar en el que estás porque después eso nos permitirá mostrar tu reporte en la ubicación del mapa que corresponde”.

¿Cómo se dio la sinergia tecnológica iLab-MIT en la resolución de este problema en particular?

Buena parte de la programación de estos cambios corrió por cuenta de Ary y de mí, con el consenso de los miembros del equipo del MIT. Fue un ida y vuelta, entre todos fuimos consensuando cuál sería la mejor solución. Dijimos: “No hay que pensar más en nada durante este mes que en la subida de una foto por reporte, y en que la geo-localización sea rápida, o, mejor dicho, que el tiempo que el usuario percibe que está esperando se achique tanto como sea posible... Ésos son nuestros dos objetivos prioritarios de acá a un mes, todo lo demás es accesorio”. Creo que una de las cosas más meritorias de nuestro trabajo fue haber señalado esas dos prioridades, que eran atacables en el lapso de un mes, porque si hubiéramos dicho “No, hay que tirar todo abajo y empezar de cero”, eso habría sido un despropósito, porque no habríamos aprovechado los aciertos de la plataforma, ni los seis meses de trabajo, amén de que algo semejante habría insumido tiempo y dinero extra.

O sea, aprovecharon la plataforma del MIT, quitaron los superfluo y optimizaron lo que quedó...

Exacto...

6. Adicionalmente, había otras pantallas en las que se usaban mapas, y procedimos de la misma manera, quitándolos. Eso nos permitió, una vez más, limpiar la interfaz y ganar espacio de pantalla, que es un bien muy preciado en un teléfono móvil. 

Para finalizar, ¿podrías profundizar un poco acerca del deseo que expresa Alexei en la entrevista, en el sentido de que esta aplicación sea menos restrictiva en cuanto a su uso masivo?

Eso surge de algo que hablamos con Alexei en su momento, en cuanto a que todo lo que hace InSTEDD es recurrente en el sentido de intentar que las soluciones desarrolladas sean accesibles para la mayor cantidad de gente posible. Cuando tú encaras un proyecto que aspira a extenderse a toda la comunidad, y no sólo a un pequeño grupo que participa de una experiencia piloto, en un workshop, si dices “Voy a usar una aplicación Android para esto”, automáticamente estás dejando a un montón de gente afuera, porque esa tecnología todavía resulta inaccesible para muchísimas personas... Desconozco la proporción exacta comparativa, pero, obviamente, hay una cantidad inmensa de personas que tienen celulares comunes, y no Androids. Y cualquier celular, hasta el más barato, si bien carece de GPS, está habilitado para intercambiar SMS. Podría especificarse vía SMS la intersección de las calles donde se localizó el riesgo. O podría implementarse un sistema de grilla o cuadrícula preestablecido, para los alrededores de tu casa, y tú podrías enviar un SMS diciendo: “Encontré este problema en el cuadrante B-2”, por ejemplo, que es una alternativa que podría ponerse en práctica mediante una aplicación como Walking Papers.

De esta manera no se exigiría que el usuario tuviera un smartphone para participar de la experiencia. Obviamente, no se tendría el mismo nivel de precisión que con el Android, no podrías pedirle al usuario que respondiera todas las preguntas, como en este caso, para armar un reporte preciso, pero serviría, sobre todo para validar información. Se me ocurre el siguiente flujo: un usuario reporta basura en determinado lugar; tú le envías un SMS a alguien que se haya inscripto como voluntario para validar reportes, pidiéndole que vaya a chequear si el dato es cierto. La persona va y responde por sí o por no. De esta manera estarías incluyendo a alguien que de otra forma tal vez no habría podido participar del relevamiento, y así le estarías permitiendo que aporte su granito de arena a la causa. 

Infografía producida por UNICEF

Para concluir con esta crónica en dos capítulos nos gustaría compartir contigo algunos fragmentos del reporte que Alexei Dunaway le envió a Joe Agoada (Coordinador de Desarrollo Tecnológico de UNICEF), como buen exponente de los notables adelantos percibidos en el workshop de Urubus respecto del anterior en Borel, y que gentilmente nos autorizó a reproducir:

“El entrenamiento fue fantástico. La aplicación funcionó correctamente, lo que marcó una gran diferencia respecto del workshop anterior, en el Morro do Borel. La nueva interfaz, mucho más simplificada, permitió que resultara mucho más fácil entrenar a los jóvenes en el uso de la aplicación, y fueron capaces de crear 150 reportes en una sesión de mapeo de tan sólo una hora y media. También pudimos recoger un poco de feedback acerca de cómo mejorar aún más la aplicación, a pesar de que se presentaron muchos menos motivos de crítica y/o frustración en comparación con los talleres anteriores. Todavía nos quedan cosas por mejorar en la plataforma, pero nos alivia constatar que ésta funciona satisfactoriamente”. 

“Los chicos se comportaron estupendamente bien; verdaderamente comprendieron lo sustancial del entrenamiento y se mostraron sumamente comprometidos con la causa. Incluso fuimos incorporando nuevos participantes sobre la marcha, y el número de jóvenes subió de 26 a 32 el segundo día...”.

Contáctanos...

Esperamos que esta experiencia que hemos compartido contigo a lo largo de estos dos posts te haya inspirado y funcione como disparador para que se te ocurran ideas análogas que puedan ser aplicadas en tu propia comunidad. Si estás interesado en que exploremos posibles abordajes conjuntos, no dudes en consultarnos: http://www.ilabamericalatina.org/contactanos.

Trabajando junto con UNICEF en la mitigación de riesgos socio-ambientales en las favelas de Río. Parte I

Estamos trabajando junto con UNICEF, la ONG brasileña CEDAPS (Centro de Promoção da Saúde) y el MIT (Massachusetts Institute of Technology) en un proyecto que nos entusiasma mucho, no sólo por lo novedoso de su abordaje y su tremendo impacto social, sino también por su prometedora perspectiva de crecimiento y replicabilidad a mediano y largo plazo.

UNICEF desde hace más de 60 años viene actuando en favor del desarrollo y la protección de los niños y adolescentes de todo el mundo. Ellos son los más vulnerables, pero, a su vez, los que tienen mayor potencial natural como para asimilar metodologías nuevas y aplicarlas con compromiso y vehemencia para torcer el destino del planeta. Si se les suministran las herramientas adecuadas, en un entorno de contención emocional, capacitación personalizada y respeto incondicional, pueden transformar el futuro...

A mediados del año pasado UNICEF Nueva York y UNICEF Brasil decidieron emprender una experiencia piloto con foco en cinco favelas de Río de Janeiro. El 6 % de los brasileños, 11,4 millones de personas, vive en favelas o en asentamientos irregulares que suelen tener condiciones insalubres y un acceso deficitario a los servicios básicos. La idea era que, desde las bases, los jóvenes pertenecientes a dichas comunidades pudieran mapear digitalmente y de una manera sencilla los factores de riesgo socio-ambientales que los amenazaban, para darles una mayor visibilidad ante el gobierno y la opinión pública. Para ello contaron con dos componentes de relevamiento, a saber:

1) Una aplicación para teléfonos celulares Android desarrollada por el MIT, a través de la cual los jóvenes pueden reportar los distintos factores de riesgo que van detectando en sus recorridas grupales por las favelas, asistidos por gente del CEDAPS. Primero consignan el tipo de peligro según categorías preestablecidas, más una breve descripción, le toman una foto o lo graban con su celular, aguardan que el aparato detecte su ubicación vía GPS, y luego suben toda esa data a un sitio web público. Si se dispone de conexión a internet en el terreno, el upload es automático y en tiempo real. De lo contrario, al finalizar la jornada de exploración los celulares son trasladados a las oficinas centrales y se los conecta para que se produzca la subida de datos.

2) Adicionalmente, y como complemento del mecanismo anterior, la plataforma permite sumar a la visualización de datos de campo fotografías aéreas capturadas con dispositivos de muy bajo costo, que constan de cámaras digitales configuradas para disparar fotos continuamente, adosadas a barriletes (cometas) o globos, lo que permite un mapeo de las favelas más actualizado y de mayor nitidez, incluso, que el provisto por Google Maps, ya que de esta manera se puede contar con datos al día, de manera tal de poder articular los reportes con sus fotos respectivas, sobre la superficie de un mapa que ellos mismos contribuirían a optimizar.

En definitiva, esta iniciativa permite que jóvenes de las favelas participen activamente de todo el proceso de puesta en conocimiento de la opinión pública y de agencias gubernamentales de los problemas socio-ambientales que los aquejan: infraestructura y condiciones sanitarias (desagües, cloacas, desechos, escombros), servicios insuficientes de recolección de basura, riesgo de deslizamiento de tierra, escaleras sin protección o inestables, baches u obstáculos que impidan el acceso de ambulancias, estructuras precarias de puentes o de columnas que sostienen casas, iluminación, electricidad (postes de alta tensión peligrosos y cables que cuelgan a la altura de los transeúntes) y demás.

A continuación te presentamos un video producido por UNICEF, de poco más de 4 minutos de duración, que sintetiza la primera etapa de esta gran iniciativa, cuando todavía no habíamos sido convocados para sumarnos a ella. Y posteriormente te relataremos cómo se fue dando la integración del equipo del InSTEDD iLab América Latina al proyecto, participando de dos workshops y del trabajo de campo respectivo, que permitió brindarles soporte técnico a los grupos de relevamiento, mejorar el diseño de interacción y optimizar la esmerada plataforma tecnológica desarrollada por el MIT.

Este Mapeo Digital de Riesgos Ambientales Liderado por Jóvenes partió de un primer taller, en el Morro dos Prazeres, en el que se capacitó a 25 líderes comunitarios para que coordinaran los grupos de relevamiento de riesgos en sus respectivas favelas. A ése le siguió otro taller en el Morro dos Macacos. En diciembre de 2011 se llevó a cabo un tercer workshop en el Morro do Borel, y al mes siguiente se organizó otro más en el Morro dos Urubus. En estas últimas dos instancias UNICEF ya nos había convocado para que realizáramos diseño de interacción in-field, de manera tal de brindarles soporte técnico y optimizar la usabilidad de la plataforma desarrollada por los ingenieros del MIT. Aún queda pendiente el quinto taller, que se llevará a cabo en Rocinha.

En este post y en la siguiente entrega compartiremos contigo las experiencias del equipo del iLab en sendos workshops –Borel y Urubus–, trabajando en cooperación con el magnífico grupo humano nucleado por el CEDAPS. Puedes explorar este mapa para ir viendo los resultados actuales del trabajo: http://locast.mit.edu/unicef. Los niños y adolescentes de las favelas que participaron de esta experiencia piloto están muy orgullosos de ser los pioneros en un emprendimiento social de semejante magnitud, que a mediano y largo plazo podrá ser replicado tanto en otros Estados de Brasil como así también en otros países.

Workshop en el Morro do Borel

Morro do Borel

Martín Verzilli, Líder de Proyectos del InSTEDD iLab América Latina, nos relata en primera persona cómo se fue dando su interacción con la gente de UNICEF Brasil y del CEDAPS, como así también con los grupos de niños y adolescentes con los que estuvo trabajando en el terreno.

Martín Verzilli

Para empezar, por favor háblanos del CEDAPS y de cómo se incorporan a este proyecto.

Ives Rocha - Alexei Dunaway

El CEDAPS es una ONG carioca que promueve la plena participación y el empoderamiento de las comunidades populares en los procesos de desarrollo y de mejoramiento de políticas públicas en sus territorios en cuanto a salud, derechos humanos e igualdad. Ante todo quiero destacar el excelente nivel humano y profesional que encontré allí. Ives Rocha, psicólogo, de Pernambuco, es el encargado de Monitoreo y Evaluación del CEDAPS. Junto con Alexei Dunaway, un egresado de la Universidad de Stanford (Relaciones Internacionales) que trabaja como voluntario en el CEDAPS desde hace unos meses, se encargaron de llevar adelante los workshops, con todo el trabajo adicional que ello implica.

El proyecto nace a partir de una iniciativa propuesta por UNICEF, que tenía esta idea de hacer mapeo digital de riesgos ambientales liderado por adolescentes, y el primer acercamiento a algo así había sido en Kenia. Estos proyectos siempre dependen de que haya alguna organización que tenga un caudal de antecedentes trabajando in-field, y ahí es donde aparece el CEDAPS, que viene desempeñándose muy bien en esos entornos, con un enfoque en temas de salud y sociales, de desarrollo humanitario, y ya venían colaborando con UNICEF en otros proyectos, como la Plataforma dos Centros Urbanos. No estaban habituados a lidiar con asuntos tecnológicos, ya que su campo de acción es el del desarrollo social. El CEDAPS garantiza la implementación del programa desde el punto de vista sociológico, y el MIT aportó la plataforma tecnológica de relevamiento, monitoreo y mapeo.

Gracias a sus capacidades en el terreno de lo social, su experiencia previa y sus conexiones con gente del lugar, pudimos llevar a cabo todo el trabajo de campo sin ningún inconveniente. Como el CEDAPS ya tenía redes tendidas en cada favela, con un nivel de foco minucioso que llega hasta el último de los beneficiarios, se constituyó en un articulador clave para que UNICEF pudiera llevar adelante esta iniciativa. Como te decía, UNICEF ya venía con la idea de hacer reportes y mapeo.

La idea de que los reportes fueran vía celular y con fotos aéreas provino de UNICEF, pero no se trata de algo inédito. De hecho, hay muchas plataformas, como nuestro GeoChat, o Ushahidi, por ejemplo, que articulan reportes vía SMS y mapas, y otros emprendimientos que a partir de fotografías aéreas low-cost desarrollan formas muy baratas y DIY –Do It Yourself– de mapeo, como Grassroots Mapping. Básicamente, hay dos métodos que se usan a tal efecto: uno es con una cometa; y el otro, con un globo inflado con helio. El segundo tiene la contra de que el helio es caro, pero bueno, es algo parecido a lo que hizo Eduardo Jezierski –CTO de InSTEDD– en Camboya (ver http://ow.ly/9jKB6). Por otro lado, los globos también presentan la desventaja de que no puedes controlar dónde caerán...

¿Cómo definirías los lineamientos básicos del proyecto, los primeros pasos?


El proyecto de Mapeo Digital de Riesgos Ambientales Liderado por Jóvenes se asienta sobre la idea básica de que los jóvenes, por naturaleza, son más proclives a la tecnología, más permeables al uso de nuevas herramientas, son más participativos, y además representan el futuro de la comunidad. Es probable que la gente que ya vive hace 30 o 40 años en la favela no acepte determinadas cosas novedosas sin oponer resistencia... Esto arrancó a mediados de 2011. Organizaron una capacitación para líderes comunitarios de cada favela que iba a ser mapeada, donde se les explicó cómo se iban a desarrollar los workshops subsiguientes y se les enseñó a usar la aplicación.

El objetivo era mapear cinco comunidades entre agosto de 2011 y febrero de 2012. Abordaron las dos primeras con gente de UNICEF en Nueva York, gente del MIT proveyendo la tecnología y miembros de UNICEF Brasil (Río) como co-coordinadores, más la gente del CEDAPS haciendo el trabajo de campo. Los dos primeros talleres desde lo humano iban bien, pero fueron apareciendo dificultades de usabilidad, que complicaban el desarrollo del trabajo in-field, y técnicas, que entorpecían la subida de los reportes a internet, que era el primer objetivo tangible que se perseguía.

Entonces, a raíz de eso, UNICEF termina publicando un RFP  –Request for Proposal–, una convocatoria de recepción de propuestas, buscando específicamente alguna organización que tuviera la capacidad de desempeñar una combinación muy específica de roles: soporte técnico en campo, detectar problemas de usabilidad e interacción con la tecnología, sugerir posibilidades de mejoras en la metodología, evaluar y monitorear resultados, etc. En otros términos, hacer de nexo entre lo que pasara en el campo y el equipo técnico que debía avanzar con el desarrollo, y así fue como entramos nosotros en la escena...


El detalle pintoresco de las cometas llamó mucho la atención de la opinión pública, ¿verdad?

Dispositivo low-cost
adosable a un barrilete 

En esa instancia ya se había hablado de los barriletes como recurso...  Esto ya se había hecho muchísimas veces en otros lados. Acá el elemento diferencial es que los chicos van recorriendo las favelas, sacándoles fotos y reportando los problemas que viven en su comunidad, vertiendo toda esa data a modo de testimonio público en un sitio web, y el gobierno no tiene forma de desmentir que esos datos son reales, y no se puede desentender del asunto... El barrilete resuelve un problema, y el celular resuelve otro, totalmente distinto. Se complementan. De hecho, podrían ser dos proyectos aparte. Le adosas una cámara al barrilete, te las ingenias para que dispare fotos en modo continuo, cada 10 segundos, por ejemplo –cada cámara tiene sus tiempos–, y lo remontas.

Es una manera muy sencilla y extremadamente barata –low-cost y DIY– de tomar fotografías aéreas, que permite confeccionar un mapa muy detallado y con muchísima mayor resolución que lo que se podría llegar a obtener vía Google Maps, por ejemplo. Las fotos que ves en Google Maps suelen tener varios meses de antigüedad, y a veces, hasta unos años... Entonces, si hubo un desmoronamiento de tierra, por ejemplo, cambia la fisonomía del lugar, y tal vez pasen dos o tres años sin que esa imagen sea actualizada... En cambio, gracias a este proyecto se dispone de mapas absolutamente actuales, que se corresponden con la realidad. Entonces, ante desastres naturales o provocados por el hombre, puedes subir imágenes actualizadas de los distintos lugares en los que uno está enfocado, muy rápidamente. Un caso emblemático de esto es el del derrame de petróleo de la British Petroleum en la costa este de EE.UU., en mayo de 2010. Aparentemente hubo presiones del gobierno estadounidense para que Google Maps no actualizara las imágenes satelitales... Y gente independiente, por su cuenta, recurrió a estos métodos alternativos low-cost para sacar fotos aéreas de la gigantesca mancha de petróleo, y las dio a conocer públicamente en internet (ver http://publiclaboratory.org/place/gulf-coast).

Relátanos una crónica de tu primer viaje...

Ives Rocha - Alexei Dunaway

Como te decía, llegué a las oficinas del CEDAPS e hicimos un par de actividades con Alexei e Ives, como para ir interiorizándome del estado del proyecto, para conocer los aciertos pero también sus preocupaciones por lo que no funcionaba bien, y saber cuál era su escala de prioridades. Qué veían que se podía mejorar de lo que andaba mal. Los dos son personas excelentes, y yo remarcaría que eso es algo fundamental para que los proyectos funcionen. Se trata del famoso tema del peopleware, del que ya hemos hablado tantas otras veces (ver http://blog.ilabamericalatina.org/2011/10/las-10-necesidades-claves-que-hemos.html, punto 5). Si el implementador local no tiene el carácter y el empuje como para sobreponerse a las dificultades, el don de liderazgo, aunque le des la mejor plataforma, no va a funcionar... De la semana que estuve ahí, hubo dos días que los pasamos enteros en Borel.

Allí hicimos trabajo de campo con los jóvenes. Mi idea era ser prácticamente invisible... Presencié el workshop, les di una mano con la logística, porque cargaban cosas, repartían refrigerios, etc., y uno ayuda para agilizar las cosas. El grupo rondaba las 15 personas en el primer viaje, y en la segunda favela participaron más de 30. Se apuntaba a que fueran grupos de 25 chicos, de entre 11 y 20 años, más o menos... Por un lado estaba la líder de la comunidad, que era el nexo entre nosotros y la favela, que también participó del workshop. Llegado un momento, los chicos se dividieron y se les repartió un celular por grupo, y cada uno era liderado por un adulto. Yo fui con uno de los grupos, junto con Alexei, que lo encabezaba. Recorríamos la favela, y yo iba viendo las dificultades que se presentaban, como problemas de velocidad para encontrar la ubicación geográfica del celular, lo que provocaba que se impacientaran y descuidaran el reporte... Yo trataba de no intervenir ni de resolverles a los jóvenes sus problemas inmediatamente, a propósito, para poder identificar qué dificultades se les presentaban en el uso de la aplicación, y recién después de eso los ayudaba.

Profundicemos sobre los componentes de la plataforma tecnológica...


Hay dos componentes tecnológicos: un sitio web (http://locast.mit.edu/unicef), en el que se puede visualizar un mapa, diversas categorías de riesgos y los reportes ubicados geográficamente. Por otro lado están las imágenes aéreas captadas por los barriletes, que todavía no han sido volcadas en el mapa ni subidas al sitio de UNICEF. En algún momento se van a subir y van a ser visibles en la página. La etapa de los barriletes se hizo en Prazeres y Borel. En Urubus la suspendimos, por una serie de factores que complicaron su implementación. Las fotos que hay en el mapa son los reportes de riesgo hechos por los chicos, a través de celulares.

Ensamble de imágenes aéreas de Google Maps

¿Qué tal fue la receptividad de los niños y adolescentes durante el workshop?

Excelente. Ante todo se les hizo tomar conciencia de lo importante que era su participación en una experiencia de esta naturaleza, como verdaderos pioneros que iban a marcar la senda de los que vendrían detrás de ellos. Seguidamente se les enseñó el concepto de riesgo, de vulnerabilidad, de susceptibilidad ante desastres naturales y provocados por el hombre, y se les mostraron ejemplos. Después los chicos se separaron en grupos, y cada uno de ellos eligió un tipo de riesgo que iba a reportar durante la exploración, para mapearlo posteriormente. Las categorías que hoy pueden verse en el sitio surgieron de los workshops. Como todas las favelas tienen entornos y problemas parecidos, en general, las categorías convergen bastante. Tal vez usen palabras distintas para referirse a lo mismo, pero en definitiva se trata de entornos similares. Se contempla cualquier cosa con la que tú te topes y te parezca que podría implicar riesgos, por ejemplo: “Oh, aquí alguien se podría caer”, o “Este desagüe, esta cloaca o este amontonamiento de basura pueden desencadenar enfermedades”, etc. En ese sentido el proyecto es muy poco restrictivo, trata de no desalentar ningún tipo de reporte.

¿Qué otro tipo de indicaciones se les impartieron a los jóvenes durante sus recorridas?

Tendido eléctrico peligroso

Obviamente, que no se reportaran hechos de violencia ni nada que involucrase a individuos particulares. Se hizo mucho hincapié en no sacar fotos de personas, ni de situaciones violentas, ya que ello pondría en riesgo el proyecto y la seguridad personal de los chicos, como una manera de resguardar la integridad del que reporta, que encima es un niño. El foco estuvo puesto en lo ambiental. Este primer cimiento está constituido por los reportes subidos al sitio web, que sirven como herramienta de diagnóstico de vulnerabilidad de la comunidad: basura por todos lados, escaleras peligrosas sin barandas, baches en las calles que pueden impedir la circulación y el acceso de ambulancias, riesgo de desmoronamientos, en fin...  ¿Cómo llegan los datos al mapa? Si bien uno puede agregarlos a mano en el sitio, logueándose y accediendo a la opción “Add cast to this map”, la idea es que la subida de los reportes sea automática, si se dispone de conexión a internet. Entonces los chicos salen a recorrer el terreno, y cuando encuentran un riesgo abren la aplicación, sacan fotos y/o graban un video, agregan la descripción y esperan un poco a que el GPS los localice, como para que después esa foto sea subida al mapa en su ubicación correspondiente, lo cual es importante, porque a posteriori esto debería servir como una herramienta no sólo para diagnosticar sino también para actuar en consecuencia. El Gobierno –Defensa Civil– debería ocuparse de solucionar esos problemas puntuales.

¿En qué consistió específicamente tu trabajo? 


En oficiar de puente entre la realidad del trabajo de campo y el equipo tecnológico. Cuando llegué allá me di cuenta de que había un montón de cosas que no funcionaban de ninguna manera... De hecho, el primer workshop en el que participamos nosotros no terminó bien... Fue bueno en cuanto a que los chicos comenzaran a foguearse con los conceptos de riesgos socio-ambientales y demás, pero la aplicación no funcionaba. Había dos tipos de problemas. Uno era de diseño de interacción: la aplicación presentaba varios problemas que hacían que los chicos necesitaran demasiada paciencia para lograr llevar a buen puerto un reporte. Y cuando una aplicación requiere del usuario demasiada paciencia, automáticamente pierde su efectividad...

Por el otro lado había inconvenientes técnicos: para entender esto hay que ver cómo sigue el workshop. Recorríamos la favela con los chicos, ellos sacaban fotos y agregaban descripciones, y al otro día, o al siguiente, se les mostraban sus reportes ya volcados en el website. “Este reporte que tú haz hecho ahora es público para todo el mundo desde este sitio, y ahora tiene visibilidad. Cualquier oficial del gobierno, cualquier ciudadano de Río o del mundo abre esto y ve que tú en la esquina de tu casa tienes un poste de luz a punto de caer”. Esa parte del workshop es crucial, porque se termina de cerrar el círculo. Bueno, la cuestión es que no funcionaba... Los jóvenes enviaban sus fotos con los reportes, pero eso nunca llegaba al mapa...

No olvidemos que las particularidades de este contexto  –se trata de favelas, de niños y adolescentes, hay mala conectividad a internet, etc.– provocaron que una aplicación de probado funcionamiento en otros tipos de ambientes resultara inadecuada y difícil de utilizar en el marco de este proyecto. Éste es un ejemplo de manual de nuestro principio de diseño bottom-up: para sortear las dificultades era fundamental contar con miembros del equipo de diseño en el campo, que analizaran la aplicación a la luz de los problemas específicos que este contexto particular ponía sobre el tapete. Nuestro trabajo in-field en Río sirvió para potenciar la excelente labor del MIT en EE.UU.

Y en cuanto a las fotos tomadas con las cometas, como te decía antes, la ejecución de esa parte del workshop, a cargo de la gente del CEDAPS, desde mi punto de vista, ha sido impecable. La actividad tiene valor para mostrarles a los chicos una técnica súper barata de generar imágenes aéreas de su comunidad, pero insisto en que el énfasis en la verdadera participación ciudadana viene por el lado de los reportes vía celular.

Continuará...

En el próximo capítulo de esta crónica te relataremos cómo en poco más de un mes, entre el primer taller y el segundo, se logró optimizar la plataforma, e incluso podrás conocer algún caso concreto que ilustre el impacto tangible de esta iniciativa. Acaso la clave para comprender una gestión eficiente de diseño de interacción resida en un lema sencillo pero bastante gráfico elegido por el ex CEO de InSTEDD Eric Rasmussen para ilustrar sus experiencia en Haití luego del terremoto de enero de 2010, y que se ha convertido en la piedra basal de nuestra filosofía de trabajo:  “If you don't go, you don't know” (ver IxDSA 2011: El diseño de interacción en la respuesta ante emergencias y desastres), lo que podría ser traducido, conservando la rima del inglés, como  “Si no vas, nunca sabrás”...

Ir a Trabajando junto con UNICEF en la mitigación de riesgos socio-ambientales en las favelas de Río. Parte II.

InSTEDD y mBlox se alían para proveer servicios móviles críticos a poblaciones vulnerables de América Latina

Indudablemente, la irrupción de la telefonía móvil en la escena mundial de los últimos años significó un salto cuántico en el acceso a las nuevas tecnologías por parte de las poblaciones más vulnerables, a un ritmo de crecimiento apabullante. Uno de los casos más representativos de este fenómeno es Haití, el país latinoamericano más pobre. A pesar de que la mayoría de sus habitantes sobrevive con sólo 2 o 3 dólares por día, más del 75% de ellos tiene un celular, y ello permitió salvar muchas vidas luego del devastador terremoto de enero de 2010...

Un colosal operativo de colaboración internacional, sin precedentes hasta ese entonces, comenzó a montarse a las pocas horas de desatado el desastre. ONGs, fundaciones, entidades gubernamentales y demás agencias de cooperación mancomunaron esfuerzos para coordinar acciones de rescate y contención ante tamaña emergencia. El prestigioso medio de tecnología y tendencias web en español TICbeat publicó en su momento una excelente crónica que retrataba cómo se había dado esta interesante sinergia de organizaciones durante el despliegue de la ayuda humanitaria. Puedes leerla aquí: El cloud computing en la ayuda a Haití.

Más allá de la invaluable participación de cada uno de los numerosos actores que formaron parte de este complejo entramado de cooperación internacional, un rol fundamental para que la maquinaria de salvataje pudiera ser puesta en marcha fue el cumplido por dos de los tres operadores de telefonía móvil de Haití, Digicel y Comcel, que proporcionaron un shortcode (número corto) gratuito para que la gente pudiera enviar y recibir los SMS salvadores: el 4636.

Nicolás di Tada

“Se tomó el control de un servicio meteorológico con un código corto (4636) y se instaló en las redes Digicel y Comcel para servir como puerta de entrada para cualquiera que tuviese acceso a un teléfono móvil. Josh Nesbit, cofundador de FrontlineSMS:Medic, describe humildemente su participación como co-coordinador que ha reunido al equipo de SMS al lograr el diálogo entre muchos voluntarios y diferentes organizaciones. Este trabajo lo han realizado personas como Jean-Marc Castera, un técnico de redes haitiano de Digicel, y Nicolás di Tada, de InSTEDD, que fue de emisora en emisora para asegurarse de que el mensaje se enviase y quedase claro. El servicio se hizo público mediante las emisoras de radio locales y el boca a boca”.

Éste fue un claro ejemplo de que la información salva vidas, y en este caso en particular, bajo la forma de simples SMS –alrededor de un millón– con información  práctica sobre cómo desenvolverse ante la crisis, qué hospitales estaban abiertos y cuál era su disponibilidad de camas, dónde había medicamentos y se entregaban alimentos u otros insumos, tips de supervivencia, etc. Estudios posteriores revelaron que la incidencia sobre los cambios de comportamiento de los sobrevivientes gracias a los SMS recibidos había sido del 85% –porcentaje altísimo, por cierto–.

Diagrama de Mission 4636, cortesía de Josh Nesbit

Ahora bien, no siempre se puede contar con operadores –también llamados carriers o telcos– dispuestos a proporcionar shortcodes gratuitos como en esta oportunidad, y, en todo caso, ello recién sería posible luego de arduas negociaciones que demandan su tiempo, amén de que ante un proyecto de asistencia de alcance regional, como podría serlo uno que abarcase a toda América Latina, por ejemplo, deberían preestablecerse acuerdos con los respectivos carriers de cada país involucrado. Y es aquí donde entran en escena los “agregadores” –aggregators, en inglés–, que ofician de intermediarios para proveer una amplia gama de servicios y soluciones móviles.

Y precisamente mBlox, líder en servicios de telefonía móvil con quien acabamos de concertar la alianza estratégica a la que nos estamos refiriendo, es uno de los principales agregadores del mundo. Cuenta con una red de más de 800 operadores en unos 180 países, con una cobertura que alcanza a más del 90% de la población planetaria (EE.UU., Europa, el sudeste asiático y ahora también América Latina).

En este reciente comunicado de prensa se informó que mBlox e InSTEDD, “un pionero en la integración de los abordajes sociales y tecnológicos para la solución de cuestiones humanitarias”, han anunciado que van a trabajar juntos en el curso de este año para mejorar la salud, la seguridad y el desarrollo de las comunidades vulnerables en América Latina.

La alianza entre mBlox e InSTEDD permitirá proveerles a ONGs, gobiernos, emprendedores sociales y otras organizaciones de América Latina acceso instantáneo, confiable y escalable a herramientas tecnológicas de telefonía móvil que faciliten la labor de aquellos que se encargan de suministrar ayuda humanitaria en escenarios de crisis tales como epidemias o desastres naturales.

Los alcances del acuerdo

Steve Love

“Vemos nuestra relación con InSTEDD como una oportunidad única de trabajar con una organización que puede aprovechar nuestro alcance global para ayudar a que todo tipo de comunidades puedan comunicarse entre sí”, declaró Steve Love, CEO interino de mBlox. “Nos apasiona la idea de emprender la construcción de una red en América Latina que beneficiará a los más necesitados. Esperamos con interés trabajar con InSTEDD para aumentar nuestro impacto social en el futuro”, agregó.

InSTEDD ve en mBlox al socio ideal que le facilitará hacer realidad su visión de proporcionar ayuda de una manera mucho más eficiente a las comunidades vulnerables de todo el mundo a través de la tecnología de colaboración, y especialmente en Latinoamérica, apalancando la consolidación de su laboratorio de innovación regional, el iLab América Latina. mBlox aportará su vasta experiencia en este terreno, sobre la base de una infraestructura estable que apuntalará la concreción de los servicios proporcionados por el iLab.

Eduardo Jezierski

“América Latina es una región con grandes desigualdades internas y entornos de muy bajos recursos, pero llena de potencial en términos de usar la tecnología para empoderar a las comunidades dentro de sus contextos locales”, aseguró Eduardo Jezierski, CTO de InSTEDD. “Hemos identificado que mBlox resuelve muchos de los desafíos que implica trabajar con proveedores locales y regionales. mBlox ha establecido redes, infraestructura optimizada para una máxima flexibilidad y programas costo-efectivos que podemos conectar e integrar a nuestra plataforma de herramientas de colaboración. Su visión –que compartimos– de ayudar a las comunidades regionales en América Latina también es muy importante para nosotros”. 

La red especialmente diseñada por mBlox obrará de soporte para la plataforma tecnológica de InSTEDD, y les permitirá a las diversas comunidades de la región comunicarse vía SMS y MMS –Multimedia Messaging System–, de manera que puedan mejorar progresivamente su salud, su desarrollo social y la protección de su integridad física y sus derechos individuales. Así, los beneficiarios podrán responder en tiempo real, interactuando a través de herramientas de comunicación confiables y robustas. Los servicios provistos por mBlox le permitirán a InSTEDD despreocuparse de aquellos aspectos del proceso que atañen al agregador, para poder centrarse en el diseño, desarrollo e implementación de herramientas de código abierto que ayudarán a difundir información crítica entre los más necesitados de la región latinoamericana.

Eduardo Jezierski nos relata pormenores del acuerdo, haciendo hincapié en sus ventajas: “Ante todo, esta alianza permitirá incrementar drásticamente la accesibilidad de los beneficiarios, y una más rápida evaluación de las herramientas de InSTEDD alojadas en la Nube, listas para ser usadas con sólo registrarse, lo que hoy por hoy es casi una excepción en la industria de la telefonía móvil. Por otro lado, hará falta menos infraestructura: no será necesario disponer de una computadora, ni de un Android, ya que mBlox también provee los gateways”.

“Este acuerdo se traducirá en una exploración conjunta que creemos que va a abrir nuevas puertas... Hemos presenciado en reiteradas oportunidades cómo muchos grupos que trabajan en el campo de la ayuda humanitaria se paralizan un poco a la hora de tener que resolver obstáculos técnicos. Por el contrario, esta alianza ayudará a tornar más accessibles las tecnologías a destinatarios que por lo general no tienen tiempo ni dinero como para resolver problemas de interconexión, como por ejemplo en el caso de proyectos de cuidado de la salud materno-infantil en entornos de muy bajos recursos, como el de Maternova en Chiapas (México)”, agrega.

“Las primeras tratativas con mBlox arrancaron en 2008, pero en aquel entonces sus servicios nos resultaban demasiado costosos. Reanudamos las conversaciones con Andrew Tinio en 2009, explorando cómo sería la implementación de gateways para Asia, América Latina y EE.UU., pero todo se mantuvo en el terreno de lo virtual... En enero de 2011 todavía no tenían nada para ofrecernos que nos pudiera ser útil, pero en abril nos enviaron un anuncio de los nuevos productos para América Latina, lo cual nos pareció como si hubiera estado hecho a medida para nosotros, ya que acabábamos de lanzar el iLab en la región... Nuestras expectativas a corto y mediano plazo pasan por establecer conectividad vía voluntarios en los cuatro países latinoamericanos abarcados por mBlox: Argentina, Brasil, Colombia y México, hacer pruebas cuanto antes, desarrollar prototipos que los destinatarios puedan ir aprovechando y concretar unos cuantos proyectos”, concluye.

Ejemplos de casos de uso

He aquí algunos ejemplos prácticos de las soluciones tecnológicas que el iLab América Latina puede proveer a partir de plataformas de envío y recepción de mensajes de texto, y que ahora se facilitarán y potenciarán gracias a la alianza con mBlox:

• Un trabajador social que se desempeña en un área rural necesita evacuar una duda o consultar cierta información con sus colegas, quienes también se hallan en áreas remotas. Envía un único mensaje de texto a un número de teléfono, que automáticamente reenvía ese mensaje a todo su grupo de trabajo. Cualquiera de esas personas podrá luego responder el mensaje, el cual, asimismo, se reenviará nuevamente a todos los demás.

• Un coordinador de un equipo de construcción de viviendas recibe una alerta meteorológica, y desde su oficina con internet les envía una alerta a todos los trabajadores en el área afectada, quienes reciben el mensaje inmediatamente en sus respectivos celulares.

• Clínicas rurales o en pueblos sin conectividad a internet reportan casos de enfermedades infecciosas a través de una llamada telefónica o un mensaje de texto, recibidos por un sistema que les permitirá luego consultar y visualizar la información recabada desde la oficina provincial.

• Una organización de acción ciudadana lanza una campaña vía SMS mediante la cual sus seguidores reciben un mensaje en sus celulares que los alerta acerca de un proyecto minero en un glaciar. Respondiendo el mensaje con un  “SÍ” firman la petición para detener la instalación, y luego pueden enviarles el mensaje a amigos o familiares, quienes también podrán firmar. El sistema contabiliza las firmas recibidas y registra los números de teléfono de los firmantes.

• Una enfermera que trabaja en el área de la salud materno-infantil visita a una mujer embarazada. Envía un mensaje de texto a un sistema registrando a la mujer y el embarazo. La embarazada recibirá SMS a lo largo de los siguientes meses, mediante los cuales se le proveerá información sobre los síntomas que podría experimentar, instándosela a visitar la clínica para hacerse un chequeo en determinadas semanas, y poniéndose sobre aviso a la enfermera o al médico a cargo sobre fechas importantes del cronograma sanitario.

• Un grupo barrial organiza una encuesta vía teléfonos celulares para conocer cuáles son las prioridades de los vecinos. Las personas reciben mensajes de texto con las preguntas, y posteriormente pueden contestar respondiendo con números para cada opción. Los resultados se almacenan en una planilla que luego podrá ser filtrada, agrupada y graficada.

Martín Verzilli, Líder de Proyectos del InSTEDD iLab América Latina, nos explica la incidencia que la alianza con mBlox tendrá genéricamente en todos estos casos, en los siguientes términos:

Martín Verzilli

“Esencialmente, los casos de uso no cambian, lo que cambia es que se facilita drásticamente la implementación de nuestras herramientas en dichos entornos. mBlox nos provee shortcodes casi on-demand, lo que normalmente llevaría meses de gestiones con cada una de las telcos que operan en el área que se quiere cubrir. Los shortcodes son mucho más efectivos que los longcodes para montar aplicaciones basadas en SMS, porque facilitan la memorización por parte del usuario del número asociado a la aplicación. Además, el servicio prestado por mBlox está pensado para manejar grandes volúmenes de mensajes, no obstante lo cual continúa siendo económicamente viable con niveles de consumo relativamente bajos. Por otro lado, hay una reducción del costo de envío hacia los usuarios para las organizaciones a partir de determinado volumen”.

“De más está decir que la solución ideal es siempre tener acuerdos directamente con las telcos para que provean shortcodes gratuitos, pero como esto en la mayoría de los casos es casi imposible de conseguir, la segunda alternativa es recurrir a agregadores como mBlox, que ya tienen acuerdos concertados con los principales carriers del mundo...  Si uno necesita shortcodes y/o altos volúmenes de intercambio de SMS, los agregadores son la segunda mejor opción...”, finaliza.

Te presentamos a nuestro hermano mayor: el InSTEDD iLab Sudeste Asiático

En 2006 el Dr. Larry Brilliant, haciendo honor a su apellido, se despachó ante un selecto auditorio con una disertación magistral que le permitió ganar el Premio TED de ese año. Con esos fondos, sumados a los aportes de Google.org y de la Rockefeller Foundation, creó InSTEDD. Desde entonces, su frase emblemática “Detección temprana, respuesta temprana” cobró una popularidad inusitada entre todos aquellos que trabajan por el bien del prójimo en entornos hostiles y carenciados. Un año después Brilliant pudo ver plasmado su sueño de desarrollar y suministrar tecnología de código abierto con propósitos humanitarios, que condujo a la fundación del primer laboratorio de innovación de InSTEDD: el iLab Sudeste Asiático, con base en Phnom Penh (Camboya).

Ya hemos explicado con lujo de detalles cómo ha sido la génesis de este proceso en otro post, que incluía un video subtitulado de la charla completa de Brilliant: Las 10 necesidades claves que hemos detectado en las ONGs y demás organismos sociales de América Latina, pero en esta oportunidad nos interesa focalizarnos un poco más en el desempeño de nuestros predecesores en la Cuenca del Mekong. Te vamos a revelar algunos detalles de la “cocina” detrás del iLabSEA, narrados por sus propios protagonistas, para que comprendas un poco mejor nuestro presente...

Un laboratorio de innovación tecnológica, o iLab, es un espacio neutral que permite la exploración compartida de soluciones para afrontar múltiples problemáticas, a través de un diálogo interdisciplinario que involucra a especialistas en diferentes áreas, emprendedores sociales y desarrolladores de software. Los laboratorios de innovación son ámbitos propicios para la transferencia de tecnología y la colaboración entre organismos de bien público internacionales y comunidades locales.

Tal como lo manifiesta Eduardo Jezierski, CTO de InSTEDD, “El concepto de iLab proviene de una 'fusión de pensamientos' que combinan lo tecnológico con el trabajo social. Mi background es eminentemente tecnológico, mientras que Dennis Israelski, CEO de InSTEDD, ha dedicado su carrera a trabajar en asuntos de salud pública mundial, especialmente en África y China. Aunque inicialmente diera la sensación de que estos dos dominios –el diseño de interacción tecnológica y la salud pública– distan de parecerse, hemos descubierto que en realidad tienen muchísimo en común...”.

“Tanto para Dennis como para mí es fundamental que aprendamos a adaptarnos constantemente a las situaciones cambiantes, implementando procesos iterativos. Se trata de una metodología muy distinta a la empleada para –digamos– la fabricación de un automóvil, por ejemplo, donde se sigue un conjunto estandarizado de procedimientos para crear un producto básico. Los estilos y prácticas de organización post-industrial simplemente no aplican en este caso... Nuestro objetivo común es extender las fronteras del diseño tecnológico para mejorar la salud, la seguridad y el desarrollo en entornos de muy bajos recursos, y asegurarnos de que esas mejoras sean reales y medibles, y de que puedan ser impulsadas y sostenidas localmente”.

Prácticamente el 100% del staff del iLabSEA está constituido por camboyanos, si bien reciben permanentemente la visita de ingenieros, programadores, diseñadores y voluntarios de otras partes del mundo, y en especial de integrantes de la comunidad de trabajadores de InSTEDD (EE.UU.). Cabe destacar que la participación comprometida y sostenida en el tiempo por parte de varios miembros de Manas Technology Solutions –Argentina– , a través de sus reiterados viajes a los países de la Cuenca del Mekong, como Camboya y Tailandia, fue lo que facilitó bastante la creación del iLab América Latina, ya que ahora estamos aprovechando toda esa valiosa experiencia in field previa y adaptándola a las necesidades locales.

Algo fundamental que distingue al iLabSEA del Silicon Valley –continúa diciendo Eduardo– es que el primero “contribuye a fomentar un enfoque mucho más amplio del trabajo, que incluye el impacto social como un objetivo primordial explícito de cualquier emprendimiento... Camboya, al igual que otros países en desarrollo, tiene una gran oportunidad de pegar un salto significativo por encima de las maneras tradicionales de hacer negocios y construir compañías”.

Para finalizar este post te presentamos un interesante slideshow creado por el Dr. Chun Cheng, Project Manager del InSTEDD iLabSEA, que proporciona un panorama bastante amplio de la labor desarrollada por el laboratorio de innovación asiático durante todos estos años, como así también de la plataforma de herramientas tecnológicas empleada, y te servirá para que conozcas mejor los orígenes de su “hermano menor”, nacido en abril de 2011: el iLab América Latina, con sede en Buenos Aires.

InSTEDD iLab Sudeste Asiático: Soluciones de eHealth prácticas e innovadoras

IxDSA 2011: El diseño de interacción en la respuesta ante emergencias y desastres

Del 1 al 4 de diciembre de 2011 se llevó a cabo en Belo Horizonte –Estado de Minas Gerais, Brasil– el evento Interaction South America 2011, que convocó a algunos de los más prestigiosos expertos en diseño de interacción del mundo, de la talla de Brian Rink (IDEO), Jon Kolko (Austin Center for Design) y Mike Kuniavsky (Adaptive Path).

Martín Verzilli, Líder de Proyectos del InSTEDD iLab América Latina, disertó acerca del diseño de interacción en situaciones de crisis extremas, a partir de su experiencia como integrante del equipo que brindó soporte tecnológico a las organizaciones que proveyeron ayuda humanitaria a las víctimas del terremoto que devastó Haití en enero de 2010 –ver La presencia del iLab en el Foro Virtual sobre el Uso de las Nuevas Tecnologías y Redes Sociales en la Acción Humanitaria–.

En otra oportunidad, en nuestro post OpenIDEO: Cuando el diseño inteligente deja de ser algo simplemente “cool”, y pasa a transformar vidas..., hemos abordado en profundidad el tema de los alcances reales del diseño bien entendido y del design thinking. Pues bien, este tipo de encuentros son oportunidades excelentes para que algunos de los máximos exponentes alineados con esta nueva corriente de pensamiento de diseño puedan relacionarse entre sí, a través de modalidades como disertaciones, workshops, design challenges, presentaciones de artículos temáticos y exposiciones de arte interactivo.

A juzgar por las repercusiones periodísticas posteriores más las impresiones personales de primera mano que hemos podido recoger a partir del testimonio de Martín, la mayoría de las disertaciones tuvieron un nivel altísimo e impactaron positivamente en la audiencia y en los medios que cubrieron el evento. Si te interesa profundizar aún más en el tema, aquí podrás ver las presentaciones respectivas en Slideshare de Caio Vassão, Mike Kuniavsky, Érico Fileno y Jon Kolko, entre otros: http://www.slideshare.net/ixdsa/presentations.

Y ahora sí, entrando de lleno en la presentación de Martín Verzilli, y para que puedas ubicarte un poco mejor en el contexto pertinente, imagínate que eres un diseñador que está acostumbrado a proyectar soluciones en marcos como éste:

... para personas como éstas:

... que intentan venderles bienes y servicios a personas como éstas:

Pero, ahora bien, ¿qué sucede cuando debes diseñar en contextos como éste:

 ... para personas como éstas:

... que están tratando de ayudar a gente en situaciones como ésta?

En escenarios de crisis profundas como la desatada en Haití en enero de 2010, la validez de técnicas tradicionales de diseño como las encuestas etnográficas, el card sorting y demás se torna sumamente cuestionable, debido a que no hay tiempo para desplegarlas adecuadamente, y cada segundo es crucial para salvar vidas. Partiendo de esta premisa, Martín pasa a desarrollar la cuenta regresiva de los ocho puntos básicos e ineludibles que deben ser tenidos en cuenta a la hora de diseñar estrategias de respuesta ante catástrofes:

8. Estar presentes en el terreno: “Si tú no vas, jamás sabrás” (Eric Rasmussen, ex CEO de InSTEDD).

7. Estar preparados y ser autosostenibles: “Preparándome para las batallas, siempre me he percatado de que los planes son inútiles, pero la planificación es indispensable” (Dwight D. Eisenhower).

6. Pensar en pequeño y actuar con rapidez: “En materia de diseño resulta crítico identificar el recurso más escaso y optimizarlo” (Fred Brooks).

5. Concentrarse en un solo usuario: “No conozco cuál es la clave del éxito, pero sí sé que la clave del fracaso consiste en intentar agradarle a todo el mundo” (Bill Cosby).

4. Obtener feedback en ciclos cortos y rápidos: “Dejad que cada hombre ejercite el arte que mejor conoce” (Aristófanes).

3. Arreglarse con lo que hay disponible: “Si no tienes un hacha, no podrás cortar ninguna madera” (John Eaton).

2. Dividir un problema grande en muchos problemas pequeños: “La mejora continua es mucho más valiosa que la perfección postergada” (Mark Twain).

1. Entrenarse y ensayar: “No fastidies... Sólo toca” (Wynton Marsalis).

Cabe destacar que el diseño gráfico y las ilustraciones de la presentación que verás a continuación estuvieron a cargo de Jonathan L. Kicillof.

Interaction South America 2011: Martín Verzilli  

Video: Cómo la Cruz Roja se está beneficiando con nuestra herramienta de reclutamiento Watchfire

“Entre que se nos notifica acerca de la emergencia en cuestión y llegamos hasta el lugar debe haber transcurrido menos de una hora, así que desde ese primer momento el reloj ya está corriendo... Uno de los primeros pasos que debemos dar es lograr que nuestros voluntarios se aproximen al terreno, por eso es muy importante la manera en que nos comunicamos con ellos...”.

Acerca de la herramienta

De esta manera Al Mallamo –director del Servicio de Gestión de Respuestas ante Desastres de la Cruz Roja del Área de la Bahía de San Francisco– describe el contexto a partir del cual el equipo de InSTEDD respondió al desafío de facilitarles la tarea de alistamiento de voluntarios de manera rápida y expeditiva frente a cualquier emergencia que debieran atender.

Se trabajó codo a codo con la gente de la Cruz Roja para desarrollar una herramienta que les alivianara la tarea de convocar veloz y eficientemente a sus voluntarios, para que éstos pudieran actuar cuanto antes en los diferentes escenarios de crisis. Desde que el reloj comienza a correr, cada segundo cuenta... Watchfire es una plataforma sencilla pero robusta que inicia y monitorea el proceso de reclutamiento de los miembros de un equipo de respuesta ante desastres que se encuentran próximos geográficamente al centro del evento, mediante llamadas telefónicas y mensajes de texto.

El breve video que te presentamos a continuación –de poco más de 3 minutos de duración– refleja cómo se fue dando el proceso de desarrollo de Watchfire, con testimonios de sus beneficiarios, y el gran impacto que los miembros de la Cruz Roja del Área de la Bahía de San Francisco aseguran que tendrá sobre sus tareas cotidianas.

 

Acerca del desarrollo del proyecto

En octubre de 2010 InSTEDD ganó un subsidio concedido por Cisco Systems con el propósito de desarrollar tecnología que permitiera mejorar la resiliencia de la comunidad de la Bahía de San Francisco en cuanto a su respuesta ante desastres naturales o provocados por el hombre. Este financiamiento estaba destinado a la implementación de algún programa que incrementara la seguridad y la autoconfianza comunitaria ante situaciones amenazantes o de crisis.

En 2011 InSTEDD diseñó, desarrolló y testeó un prototipo llamado Watchfire con el objetivo de ayudar a la Cruz Roja del Área de la Bahía de San Francisco a que optimizara su nivel de respuesta ante situaciones de emergencia. Trabajando en estrecha colaboración con ellos, en el marco de una meticulosa evaluación de sus necesidades más apremiantes, aprendimos que su máxima prioridad consistía en mejorar la velocidad de respuesta y la coordinación de los Equipos de Acción ante Desastres (DATs).

Y así fue como a través de un proceso de diseño ágil e iterativo, que involucró la participación activa de los miembros de la Cruz Roja en cada uno de los tramos del ciclo, de manera de ir alcanzando las soluciones tecnológicas más adecuadas para cada etapa, desarrollamos Watchfire. Puedes conocer más pormenores acerca de esta plataforma leyendo nuestro post La herramienta de InSTEDD que le permite a la Cruz Roja reclutar 40 voluntarios en 10 minutos...