Scratch y The Gimp en el MDE11

Durante el 13, 14 y 15 de octubre y el 18 y 19 de octubre estuve en Medellín, en la Casa del Encuentro y en la Biblioteca Pública Piloto, haciendo una serie de talleres sobre diseño, creación y prueba de historias, juegos y simulaciones – con un enfoque en materiales multimedia – usando The Gimp y Scratch en el marco del MDE11, gracias a una invitación de los amigos de Hiperbarrio.

A continuación una breve descripción del taller y algunos de sus resultados.

Al inicio del taller se definieron el tipo de historias, juegos o presentaciones que se iban a obtener al final del ejercicio. Como planteamiento inicial se tomó el tema de la narrativa, más como propuesta metodológica que como propuesta temática.

Por que partir de la metodología?

Los ejercicios de narrativa permiten la libre expresión y el desarrollo de la creatividad de los participantes. El taller se orientó a desarrollar estas capacidades antes que pensar en un adiestramiento sobre las herramientas.

El ejercicio propuesto retoma los elementos de talleres introducidos por Barbara Barry en Narración y computación pidiendo pensar en dos personajes que se encontrarían en un escenario (que puede cambiar o no) entre quienes surge una confrontación, que lograr solucionar con un resultado inesperado.

Este sencillo planteamiento permite la exploración de escenarios,objetos, personajes, interacciones, mensajes, variables y de más elementos propios de la programación en scratch, además que brinda la posibilidad de usar fotografías tomadas por los mismos asistentes al taller para ser modificadas en The Gimp con el fin de convertirlas en esos escenarios, personajes y objetos.

Con este objetivo, el de construir la historia, durante los talleres se aprendieron a editar y manipular imágenes, tanto fotografías tomadas por los asistentes como imágenes descargadas desde Internet. Se hicieron prácticas de recorte, escalamiento, modificación de color, filtros y efectos.

Luego de editadas las imágenes se importaron a scratch para ser utilizadas en la construcción de las diferentes historias.

Ya en scratch, se trabajó en el paradigma de programación orientada objetos, para darle vida a los personajes elegidos por los asistentes. Representar el conflicto y mostrar el desenlace. Eso permitió explorar las herramientas de movimiento, control, apariencia, variables, sensores, incluso sonidos con que cuenta scratch.

Al finalizar el taller los asistentes crearon sus respectivas cuentas en la comunidad de scratch y compartieron sus trabajos en internet. Esta es una muestra de ellos:

Entre un lápiz y un borrador

Scratch Project

Blancanieves cabello sedal
Scratch Project

Ojitos
Scratch Project

Me van a comer
Scratch Project

A los participantes, organizadores y demás amigos con los que compartí esa semana en Medellín, mis más cordiales saludos.

Anuncios

Explicitar los lugares comunes

Algunas notas sobre el grupo de Implementación de Sugar

Hace un par de semanas me propusieron ayudar en la coordinación del grupo de Implementación de Sugar Labs. Es una de esas misiones que uno asume con una mezcla de felicidad y preocupación. Casualmente esta última semana se ha discutido bastante sobre el tema en la lista de sugar-devel. Así que dispuesta a aceptar el cargo, estas son algunas de mis impresiones sobre el  grupo de implementación de Sugar Labs y sobre los retos de esta tarea.

Cual es la mision del Grupo de Implementación?

Del wiki: “The mission of the Deployment Team is to voice the needs of Sugar deployments to the Sugar community, to find ways to support those needs, to organize forums for the exchange of experiences between Sugar users and Sugar developers, and to build local Sugar Labs organizations worldwide.”

Teniendo eso en cuenta, lo que interesaría es tratar de contactar y mantener una relación estrecha con las implementaciones.

¿Quiénes serían el grupo objetivo de esta búsqueda de cercanía?

  1. los usuarios directos de Sugar: niños, niñas y docentes que utilizan cotidianamente Sugar en un proceso de enseñanza-aprendizaje.
  2. Los administrativos a cargo del proceso de implementación en las instituciones, a quienes se les debe “convencer” de la necesidad de esta comunicación. La idea de “convencer” debería dar cuenta de darles algo que también les sirva. Ofrecer a la institución algo que sirva de intersección y a la vez permita empoderar a los individuos de la comunidad.
  3. Los desarrolladores de Sugar, que necesitan una retroalimentación constante para mejorar la plataforma.

Ser la voz de las implementaciones implica estar en ellas, padecerlas y conocerlas. En últimas el grupo de implementación debe preguntarse por cómo construir posturas válidas desde dentro, incluyendo a todas las partes del proyecto, siendo consciente de lo local.

Buscar la manera de soportar las necesidades es estar conscientes de los retos y las limitaciones que impone el tipo de trabajo en el que estamos. Quienes somos, o quienes creemos ser: un proyecto comunitario, mayoritariamente voluntario, donde generalmente hay una gran distancia entre aquellos que elaboran el software y los otros que lo implementan.  Esas distancias muchas veces han sido legados de procesos pasados de los que aun conservamos cierta tendencia al centralismo, al asistencialismo y a abstraer tanto a usuarios como a desarrolladores. Teniendo esto en cuenta necesitamos pensar, ¿cuáles son los espacios de confluencia? ¿cuáles son los mecanismos que nos permiten una comunicacipn más fluida?, ¿cómo se  logran romper las barreras impuestas por el idioma y las idiosincrasias?, ¿cómo darles voz a aquellos cuya opinión generalmente no ha sido tomada en cuenta?, ¿cómo volver este proceso más transversal?

En cuanto al trabajo de los desarrolladores y el grupo de Implementación, ¿hemos logrado mejorar el software y la interfaz gráfica a partir de supuestos o estamos más cercanos y atentos a las verdaderas necesidades? ¿cómo conocerlas? ¿cómo dejar las suposiciones?  Es necesario lograr tener interlocutores (pares capaces de dialogar) antes que interpretes.

¿Qué tipo de foros y en que tipo de espacios se deben encontrar los desarrolladores y las personas de implementación? Foros de maestros, listas de correo, foros de discusión de software, eventos de divulgación, eventos académicos, eventos de promoción de tecnología, ferias de ciencia? Será alocado pensar que los desarrolladores deben buscar la cercanía y no tratar de forzar a los maestros a que participen en un proceso que sienten lejano. Necesitamos espacios de conversaciones transversales, no espacios donde se va a escuchar al que sabe (conferencias, foros…)  y más espacios de escucharnos entre los que construimos y tenemos saberes distintos (world café, open space…) Hay que construir espacios de diálogo, hay que dejar de esperar que vengan a contar como ha sido la experiencia de uso y tal vez ir a ver que es lo que buscan, quieren o necesitan ¿Cómo se puede construir en conjunto?

¿Qué aportan los local labs en este proceso? De la forma como se están generando los local labs pueden ser espacios de confluencia. Lugares donde permitir que haya una mayor circulación de las ideas y donde la limitaciones de idioma e idiosincrasia suelen ser fácilmente salvables. Faltan en estos procesos lograr mayor autonomía y autosostenibilidad en el tiempo.

Los peligros del pasado

Algo que encuentro desafortunado y que definitivamente no podemos repetir es el centralismo que ha caracterizado a OLPC como organización y la necesidad de mantener el control de las implementaciones, impidiendo la cercanía de la comunidad con muchas de ellas. Esto aparece como un obstáculo para que el grupo de implementación tenga una injerencia real en las implementaciones. A título personal creo que la falta de visión de OLPC como una gran comunidad, donde se favorezcan grupos locales antes que globales y donde el proyecto se centre en procesos  de apropiamiento tecnológico desde lo micro y no desde lo macro ha sido un factor que ha contribuido al alejamiento, desconocimiento e incluso recelo a la participación de las comunidades en estos procesos. Si a eso se suma que generalmente los proyectos no han sido consultados ni construidos con aquellos a los que directamente se les hace responsables de las implementaciones nos vemos con un problema mayor.

El reto planteado

Abramos canales que permitan ser mantenidos desde la cercanía, ¿conocen un proyecto que use Sugar que no tenga acompañamiento? del que no tengamos retroalimentación, por más distante siempre será posible conseguir los datos de las personas responsables de él, podemos ofrecerles la idea de convertirnos en una comunidad que los apoye, donde sus inquietudes puedan ser oídas,  donde sus aportes permitan mejorar su trabajo, podemos proponer eventos de intercambio de experiencias o de intercambio de prácticas. Facilitemos dinámicas que empoderen a los docentes pero que sirvan también a la institución. El reto es buscar lugares de intersección con las instituciones donde potenciar a los individuos y crecer como comunidad.

Finalmente, para mí, estos son nuestros “lugares comunes”. Las acciones que nos pueden permitir encontrarnos: transvesalizar, flexibilizar, favorecer microcambios que generen macrocomportamientos, tender puentes, crear comunidades sostenibles autónomas pero vinculadas, lograr apropiación tecnológica, escalar los procesos, crecer y madurar como comunidad, incluir otras experiencias, favorecer lo local, construir lo global, crecer orgánicamente…

Nuestra ventaja es que tenemos un elemento didáctico, tenemos el software, las actividades, la propuesta de interfaz, pero nuestros objetivos nos llevan más allá a pensar en el ambito pedagógico y la pregunta por como mejorar la educación siempre implica apuestas políticas, si se quiere ideológicas.  ( No lo digo yo, lo retomo de Freire, de la pedagogía de la esperanza). Pensar en personas críticas que puedan solucionar de forma creativa problemas, pensar en personas éticamente convencidas de la utilización de herramientas libres y contribuir a la construccion de una sociedad con valores dieferentes es una apuesta política. Pero en la realidad muchos son los lugares comunes y muy pocas las prácticas que nos permiten visualizarlos. Ese es el reto.

Lo prometido es deuda

Hace más de un mes me comprometí a hacer una artículo sobre el software libre y sobre sugar para la mesa social por la educación. Un grupo de representante de organizaciones inquietas por el tema educativo que están apostando a la construcción de un proyecto pedagógico alternativo.

Más allá de las mis filiaciones particulares con este proyecto me pareció importante el ejercicio de escribir sobre las cosas en las que he estado trabajando durante los últimos 3 años. Sobre todo por que a pesar de que he dado charlas en muchos eventos y de que hemos discutido muchas veces sobre OLPC, Sugar, Sugar Labs referidos como casos concretos de uso de Software Libre en Educación con la mayoría de las personas cercanas, son muy pocos los textos documentales dejados en concreto. Salvo los correos de la lista de olpc-sur y algunos de Colibri es poco lo que puedo decir que he elaborado de forma escrita sobre el tema.

Así que este es mi primer ensayo. Lo dejo a la consideración amable de los que pasen por este blog en la casilla de documentos compartidos.

Luego de ver la reseña en el blog de Tomeu,  dejo el artículo Sugar, usando Software libre para aprender disponible sin la necesidad de pasar por flash.