Primeras decisiones importantes en el desarrollo de la plataforma para BueuGrafías
Ushahidi vs WordPress: ¿Qué sistema de gestión de contenidos (CMS) a usar?
Al principio, la elección fue Ushahidi, por su potente sistema interno (fichas de inserción de nuevas localizaciones, visualización por listado de contenidos, etc). Pero las pegas eran, por un lado, su visualización, que permite distintas categorías y subcategorías pero no que se vean todos lo iconos de cada categoría al mismo tiempo, lo que dificulta la búsqueda de localizaciones por el icono de su categoría (y modificar eso implica hacer muchos cambios en su librería javascript de geolocalización, y otros cambios en sus archivos internos); y por otro, que implementar las demás funcionalidades (la red de nodos en grafo, etc) era también difícil, porque aunque tiene una buena red de desarrollo, no es tan grande y los plugins van poco a poco. Por lo que decidí volver a WordPress como el CMS base a utilizar.
En WordPress, en cambio, sí que hay muchísimos plugins activos y en desarrollo, algunos de los cuales ya pueden servir de base para algunas de las funcionalidades que queremos darle a la futura plataforma. Y, en general, usar un CMS ya existente permite que cualquier web basada en ese sistema puede convertirse en una versión de la plataforma. En este caso, cualquier WordPress instalado en servidor propio puede adquirir las funcionalidades de la plataforma.
Mazinger-Z vs Frankenstein: ¿Desarrollar una plataforma única que resuelva todos los problemas o un conjunto de plugins ensamblables?
Desarrollando la monolítica y complicada eGlia, ya me di cuenta de esto: es mucho más eficaz preparar distintas mini-aplicaciones que funcionen independientemente, y que combinadas de una determinada manera construyen la plataforma deseada, pero que se pueden utilizar independientemente o recombinándolas con otras para distintos proyectos o plataformas. Además, antes de decidir esto investigué la versión instalable de WhatIf, que sigue el mismo concepto: ensamblar las funcionalidades usando plugins. El motivo de no usar Whatif era que está programado como un tema, no un plugin, lo que dificulta su combinación con blogs ya existentes.
Así que la plataforma final estará formada por la combinación desde el administrador de WordPress (no desde código) de distintos plugins funcionalmente independientes. Esta estrategia permite que la recombinación de los distintos plugins puede dar lugar a distintas plataformas con diferentes funcionalidades y objetivos: cualquier WordPress instalado en servidor propio podría adquirir las funcionalidades de una plataforma de trabajo y gestión de este tipo, un Frankenstein más flexible y reutilizable que la superdiseñada y poco adaptable eGlia, un pretendido Mazinger-Z.
Plan de trabajo y primeros desarrollos
El primero de estos plugins ensamblables está siendo WP_glia, una herramienta que permite visualizar los posts del blog en conexión en red, como hacía la vieja eGlia. Su motor gráfico constructor de la red es VivaGraphJS, una librería JavaScript potente, eficaz, y sencilla de adaptar. Lleva ahora mismo 22h de trabajo y esas imágenes son el resultado por ahora, lo que anima a pensar que será un desarrollo relativamente rápido. Es imprescindible que lo sea, porque después de este seguiremos con los demás plugins ensamblables (para los que ya existen múltiples plugins para Worpress, aunque alguno de ellos mejorable), y el siguiente inmediato será el de la geolocalización.
Sigamos!
me parece fantástico el pensar en las imágenes producto de esa vestimenta de Frankestein que se la puede calzar cualquier Mazzinger, me quedan muchas preguntas: ¿se podrá explorar toda la versatilidad semántica a la que llegó Eglia? me refiero a todas las opciones de jerarquización de relaciones entre nodos, que se puedan encender, apagar y ver o no de manera simultánea?, me intriga también, que al trabajar sobre wp, pero sin ser una plantilla, ¿cuál será la presentación de la herramienta? una app que se asocia a una base de datos? y en ese caso cual será la forma de introducción de datos?…bueno muchas preguntas que espero que se vayan aclarando poco a poco!!!me alegro que #bueugrafias empiece a respirar!!!enhorabuena Compañero!!!
Gracias Mario!
Las ayudas a la visualización (apagar/encender nodos/conexiones, etc) irán llegando, pero sí que están dentro de los planes 😉
En cuanto a como introducir datos, en principio se está gestando como un servicio al wordpress sobre el que se intale, es decir, que los datos en realidad serán posts, páginas, etc, de ese wordpress. No habrá datos que meter en la aplicación, ella los bebe del blog en el que es está. Los únicos datos serán opciones desde el administrador, pero no contenidos.
Y respecto a la base de datos, pues está usando la propia del wordpress, por lo que no hay que crear ninguna nueva. Esto en realidad tiene que ver con lo de antes: la aplicación no tiene base de datos de contenidos, son los de la base de datos del wordpress.
🙂
Uala Sergi! Gran trabajo!
Como fan de wordpress, me gusta mucho el nuevo enfoque! Ya estoy pensando en varios proyectos que podemos usar esto o sus variaciones, así que si vas subiendo código y necesitas beta-testers o, incluso, alguna ayuda corrigiendo bugs me avisas 🙂
Abrazos!!
ole Ester! 😀
El desarrollo va lento, por ahora espero tener para Septiembre una versión beta más o menos estable, jej. Te meto en la lista de tests jejej. Y darle aplicabilidades sería más que genial! Te tendré informada. Una cosa pendiente es montar un GitHub 😉
Por ahora me centro en explicar cuestiones de programación, usabilidad, etc. Sería estupendo llegar a la descripción crítica de aplicaciones de mapping con que se está llevando la investigación #metamap de Ecosistema Urbano (http://ecosistemaurbano.org/blog/metamap/), que @mariohidrobo también está usando en Twitter con el mismo fin.
Sigamos! 🙂