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, se vuelve más complicado cuando este contenido es parte de una aplicación interactiva más grande. 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 para un pequeño cambio de texto y la aplicación debe volver a cargarse 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 busca el término CMS en Internet, por ejemplo, encontrará rápidamente los sospechosos habituales, como WordPress, Joomla o Typo3. Ahora hay innumerables sistemas de administración de contenido, y cada uno sirve para uno u otro propósito mejor o peor.

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? Esto revela la gran discrepancia con los sistemas CMS web clásicos que acabamos de mencionar. Estos sistemas están diseñados para crear UNA fuente, por ejemplo, UN blog con quizás varias subpáginas. 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 una presentación de diapositivas de video. Y su apariencia y comportamiento debe ser diferente en cada caso, es decir, programado 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 brindar a los programadores una forma uniforme de consultar el contenido desde una ubicación central, que el museo puede cambiar 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 ahora escribes «Todo el contenido debe ser intercambiable a través de un CMS», tienes el problema de que el CMS no está definido (ver arriba) y que el programador también tiene que cambiar los gráficos de los botones o los gráficos de fondo o las etiquetas de los botones 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, acordado. Los programadores pueden empezar a trabajar. El contenido se crea al mismo tiempo. No hay problema, los programadores pueden trabajar con datos ficticios. Por supuesto que pueden, pero es bueno si los formatos ya se han aclarado en este punto. Las sorpresas como «oh, pero las imágenes son grandes/pequeñas» o «no podemos importar archivos .doc» no son necesarias y generalmente generan más costos en alguna página.

Feliz si ya puede acceder a un CMS en este momento. Si el CMS se ejecuta en la TI del museo, los programadores, traductores, diseñadores gráficos, etc. ‘solo’ necesitan una VPN para acceder a los mismos datos que los científicos y empleados 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 la TI tiene que ser convertida en consecuencia, o, o…

Así que centrémonos en la más relajada de todas las soluciones. NeuroomNet aloja el CMS en línea durante la fase de desarrollo. Todos los involucrados usan, crean y corrigen los mismos datos desde el principio. Los problemas como demasiado grande, demasiado pequeño, demasiado texto, demasiado poco, se notan de inmediato y no solo cuando finaliza la aplicación. Al final, cuando la aplicación se instala en el sitio y NeuroomNet proporciona el CMS localmente en el museo, NeuroomNet simplemente transfiere los datos a la TI del museo local.