Mis propósitos de año nuevo estaban enfocados a sacar adelante ciertas ideas y proyectos que desde hace tiempo están rondando en mi cabeza y en mis listas de cosas por hacer. Este es el primero de una serie de entradas en las que iré comentando el desarollo de éste y de otros proyectos.
Yomemicontigo es uno de esos propósitos. También es el proyecto de tesis de Lola, mediante el que pretende investigar los procesos de aprendizaje colaborativo y autónomo, apoyándose en enfoques educativos como el conectivismo y el aprendizaje para toda la vida. La idea para llevar a cabo este proyecto es una red social para estudiantes de español. En ella, además de perfiles de usuario, y herramientas como blogs, foros y grupos, también habrá actividades, propuestas por Lola, como relatos colaborativos, ejercicios basados en mapas y otras cosas.
El primer paso para construir Yomemicontigo es elegir el armazón que nos servirá como base de desarrollo. En nuestro caso, elegimos Drupal, pero estuvimos valorando también otras opciones, como Dolphin, Elgg o Moodle. Siempre dentro del software libre:
- O casi. Dolphin fue rechazado desde el principio por no ser software libre. En vez de GPL, es CC-BY, y para deshacerte del enlace a BoonEx, has de pagar una cierta tarifa. Las funcionalidades están bien, pero el hecho de no ser software libre limita mucho el tamaño de la comunidad que puede aportar plugins para funcionalidades extras, o la documentación necesaria para poder personalizar el diseño.
- Moodle también fue descartado desde el principio. No es propiamente un CMS o un gestor de comunidades, sino que es propiamente un LMS. El hecho de estar diseñado tomando el curso como elemento central, con calificaciones y actividades cerradas, limitaba mucho nuestras posibilidades. Además, este enfoque es totalmente opuesto a la filosofía educativa de la que partía el proyecto, mucho más abierto e informal.
- Elgg fue uno de los candidatos con más posibilidades de ser utilizado como esqueleto del proyecto. Elgg es un gestor de comunidades y redes sociales basado en el usuario. En ese sentido, tenía todas las funcionalidades que buscábamos: perfiles, grupos, amigos, mensajes, blogs de usuario, etc. Sin embargo, carecía de versatilidad para añadir la parte de actividades. Otros puntos en contra eran la reducida comunidad de desarrolladores y una cierta fama de código enmarañado que dificultaban el desarrollo y el diseño de temas visuales propios, aunque esto parece ser que iba a cambiar en versiones posteriores.
- Sabiendo por qué no hemos escogido las aplicaciones anteriores, está claro por qué hemos escogido Drupal.
En primer lugar, está la versatilidad. Con Drupal y los módulos adecuados, se puede replicar cualquier cosa: flickr, myspace, lo que quieras. Hay cientos de módulos disponibles que amplían las funcionalidades de Drupal. De hecho, hay demasiados módulos, tanto que varias funcionalidades están cubiertas por más de un módulo, como chat o grupos, y cuesta elegir el adecuado buceando en los foros de soporte, aunque este problema está comenzando a ser resuelto con la fusión de varios proyectos.
En realidad, la duplicidad de módulos es ecológicamente efectiva, ya que la resolución de necesidades o problemas desde diferentes perspectivas enriquece el resultado final cuando varios proyectos comienzan a trabajar juntos, o uno de ellos es abandonado en beneficio de otro. La gestión de los módulos en el sitio de Drupal tampoco es la más adecuada, y no es posible distinguir cuáles son los módulos más populares (más descargados o más en uso actualmente), estables, actualizados o mejor soportados.
Para complicar las cosas, las peculiaridades del desarrollo de Drupal hacen que para cada versión se hayan de actualizar todos los módulos existentes. Eso deja obsoletos a módulos perfectamente estables, cuyo desarrollo ha sido ya abandonado. Esa es la única razón de utilizar la versión 5.7 en vez de la más reciente y muy mejorada 6.2. Módulos básicos para el proyecto como Organic Groups todavía no tienen su correspondiente versión para la rama 6.x.
La curva de aprendizaje demasiado pronunciada es otra de las críticas que se le suelen hacer a Drupal. Y es una crítica veraz, reconocida por el propio Dries Buytaert, creador e impulsor del proyecto Drupal, en la DrupalCon del 2007 en Barcelona, que fue mi primera toma de contacto con este CMS. Sin embargo, no era algo que me preocupase demasiado. Fuese cual fuese la elección que tomásemos, habría una curva de aprendizaje hasta lograr a dominar el sistema elegido. En el caso de Drupal, este aprendizaje se haría con un alto volumen de documentación disponible, una comunidad amplia y activa y con la seguridad, sabiendo que Drupal ha sido utilizado para poner en marcha versiones digitales de periódicos y revistas, de poder rentabilizar esta inversión en otros proyectos en el futuro.
La gran cantidad de documentación existente, en foros, blogs, en el propio sitio de Drupal, en libros, etc. me daba la seguridad de poder aprender a poner en marcha cualquier cosa, y de saber cómo funciona. Así, cuando llegue el momento de realizar el diseño de la interfaz de Yomemicontigo, cuento con libros, ejemplos y tutoriales suficientes para saber dónde situar cada función de PHP. El diseño de Yomemicontigo y el libro sobre los temas de Drupal que utilizaré como referencia para ayudarme tendrán su propia entrada en un futuro.
En la próxima entrada veremos la lista de módulos adicionales que hemos seleccionado, qué nos permitirán hacer y por qué hemos elegido esos módulos sobre otros adicionales.
Francisco LaFundició
Hola Carlos! Nos encontramos de nuevo, ahora en tu blog! que ya he añadido al NetNewsWire 😉 Nos interesa mucho vuestro proyecto Yomemicontigo y esperamos que nos contéis paso a paso como evoluciona y cuales son sus resultados.
A propósito de lo que comentas en el post, nosotros también estamos enfrascados en la creación de un sitio web administrado de forma colectiva, el de la Asociación EspaiDer3* . El sitio funcionará, en principio, más como una página web al uso con diversas secciones y un blog único incorporado en la página principal y quizás más adelante un chat, pero queríamos que fuese fácil de administrar por un grupo reducido de personas. Sin saber exáctamente porqué, nos hemos decidido por utilizar SPIP ¿qué te parece esta opción?
Carlos
Hola Francisco! Pues si te digo la verdad, de SPIP sólo he oído hablar, pero no he podido echarle a un ojo. Intentaré hacer una prueba en local, a ver qué tal.
De todos modos, lo que pretendéis hacer es posible hacerlo hasta con WordPress, que veo que ya le dáis uso. Te diría Drupal, por aquello del caching, la seguridad y por la mayor potencia de la parte de gestión de contenidos, pero WordPress es mucho más sencillo de gestionar, y también se le puede añadir algo para gestionar eventos, agenda y demás, que por lo que pude ver brevemente en la web de La Fundició, es importante.
Y bueno, a nivel de diseño, la creación de plantillas (templates) está muy documentada en Drupal, y en WordPress. La verdad, desconozco este aspecto en SPIP.