Gestión de contenidos en el museo.
Los contenidos digitales se han vuelto indispensables en los museos. Pero, ¿cuál es la mejor manera de crear y agregar contenido si tiene que coordinar diferentes oficios entre sí?
Esto puede ser texto, imágenes, videos o grabaciones de audio que se ejecutan en un bucle en reproductores dedicados. Este contenido también debe distribuirse y debe ser canjeable en cualquier momento. Esto generalmente se hace mediante una transferencia de archivos, es decir, el contenido se copia directamente a los sistemas de reproducción (contenido push).
Sin embargo, la cosa se complica cuando este contenido forma parte de una aplicación interactiva mayor. Para entonces, a más tardar, ya no debería estar sin el uso de un CMS. Porque a estas alturas un intercambio de contenidos puede resultar caro. Por ejemplo, si un programador con sede en Múnich tiene que volver a compilar la aplicación por un pequeño cambio de texto y la aplicación tiene que volver a instalarse en Berlín. Por lo tanto, las aplicaciones deben escribirse o crearse de tal manera que recuperen el contenido de un servidor CMS.
sistema de gestión de contenidos – CMS no es solo CMS.
CMS no es un término protegido y simplemente describe el hecho de que el contenido se intercambia de alguna manera y en algún lugar.
Pero debe prestar mucha atención a sus propios requisitos. Si se busca el término CMS en Internet, por ejemplo, se encuentran rápidamente los sospechosos habituales como WordPress, Joomla o Typo3. En la actualidad, existen innumerables sistemas de gestión de contenidos y cada uno de ellos cumple mejor o peor un propósito u otro.
Por ejemplo, si desea crear un sitio de blog, está bien servido con WordPress y para una presencia en la web, Joomla o Typo3 no son una mala elección.
Pero, ¿qué sucede si tiene diferentes aplicaciones interactivas cuyo contenido desea intercambiar individualmente, como en un museo? Aquí es donde se hace evidente la gran discrepancia con los sistemas clásicos de CMS web que acabamos de enumerar. Estos sistemas están diseñados para crear UN recurso, por ejemplo UN blog con quizás varios subsitios. Esta fuente ÚNICA es a su vez llamada por MUCHOS dispositivos finales, es decir, muchas personas miran este blog con su navegador y se ve igual para todos los espectadores. En este caso, el CMS también determina cómo se muestra el contenido, así como el comportamiento de la página.
Esto nos lleva al segundo criterio. Porque en el caso del museo, tienes diferentes aplicaciones, por ejemplo, un juego, una aplicación de información y un pase de diapositivas. Su aspecto y comportamiento deben ser diferentes en cada caso, es decir, programados individualmente. Pero todas las aplicaciones deben obtener los datos de ONE CMS. Por lo tanto, el CMS en realidad solo debe proporcionar contenido y no preocuparse por la apariencia, sino que debe proporcionar contenido para muchas aplicaciones diferentes.
Hoy en día, este tipo de CMS se conoce más comúnmente como CMS sin cabeza. NeuroomNet incluye dicho CMS. Esto proporciona una API, es decir, una interfaz bien definida, para dar a los programadores una forma uniforme de recuperar el contenido desde una ubicación central, que puede ser modificada por el museo en cualquier momento.
Esta circunstancia deberá tenerse en cuenta en particular en el caso de las licitaciones. Porque si solo espera un CMS allí, es posible que obtenga uno de los CMS web mencionados anteriormente. Estas herramientas generalmente se pueden instalar de forma gratuita, pero no brindan la funcionalidad deseada.
De la idea al producto final
Supongamos que queremos tener un software escrito para una aplicación de museo. Como con cualquier buen software, primero se debe crear una especificación, preferiblemente con diseños de pantalla significativos. Pero allí los límites son fluidos, ya sea que elija la forma clásica o más bien un enfoque ágil.
Sin embargo, si planea intercambiar o agregar contenido más adelante, debe tener razonablemente claro en este punto a qué contenido afecta esto. Por ejemplo, si tenemos una aplicación que lista todos los premios Nobel con la información adicional correspondiente, también queremos poder añadir nuevos científicos. Pero si escribes «Todo el contenido debe ser intercambiable a través de un CMS», por un lado tienes el problema de que el CMS no está definido (ver arriba), y por otro lado que para los programadores los gráficos de los botones o los gráficos de fondo o las etiquetas de los botones también son contenido. Es posible que desee compartir ese contenido también, pero si no lo hace, eso solo aumenta el costo.
¿Cuándo llegan los datos?
Hecho, hecho, de acuerdo. Los programadores pueden empezar a trabajar. Los contenidos se crean en paralelo. No hay problema, los programadores pueden trabajar con datos ficticios. Claro que sí. Pero es bueno que los formatos ya estén aclarados en este punto. Sorpresas como «Oh, pero las fotos son grandes/pequeñas» o «los archivos .doc no se pueden leer» – nadie necesita eso y normalmente conduce a más costes por algún lado.
Feliz si ya puede acceder a un CMS en este momento. Cuando el CMS se ejecuta en la TI del museo, los programadores, traductores, diseñadores gráficos, etc. «sólo» necesitan una VPN para acceder a los mismos datos que los científicos y el personal del museo que trabajan internamente.
En la práctica, por lo general se ve diferente. Luego, por ejemplo, si el museo todavía está en construcción o renovación. O al menos hay que retocar la informática en consecuencia, o, o, o….
Así que centrémonos en la más relajada de todas las soluciones. NeuroomNet aloja el CMS en línea para ellos durante la fase de desarrollo. Todos los participantes utilizan, crean y corrigen los mismos datos desde el principio. Problemas como demasiado grande, demasiado pequeño, demasiado texto, demasiado poco, se notan inmediatamente y no cuando la aplicación está lista. Al final, cuando la aplicación se instala in situ y NeuroomNet proporciona el CMS localmente en el museo, NeuroomNet simplemente traslada los datos a la TI del museo local.
