Content Management im Museum

Digitale Inhalte sind im Museum nicht mehr weg zu denken. Aber wie sieht der optimale Weg zum Erstellen und Einpflegen von Inhalten aus, wenn man verschiedene Gewerke miteinander koordinieren muss?

Das können Texte, Bilder, Videos oder Audioaufnahmen sein, die auf dedizierten Playern im Loop laufen. Auch diese Inhalte müssen verteilt werden und sollten jederzeit austauschbar sein. Meistens wird dies mittels einer Dateiübertragung gemacht, sprich die Inhalte werden direkt auf die Ausspielsysteme kopiert (Content Push).

Komplizierter wird es allerdings wenn diese Inhalte Teil einer größeren interaktiven Anwendung sind. Spätestens dann sollte man nicht mehr auf den Einsatz eines CMS verzichten. Denn an der Stelle wird ein Austausch von Inhalten unter Umständen teuer. Wenn beispielsweise für eine kleine Textänderung ein Programmierer, der in München sitzt, die Anwendung neu kompilieren muss und die Anwendung anschließend in Berlin neu eingespielt werden muss. Die Anwendungen sollten also so geschrieben bzw. erstellt werden, dass sie sich die Inhalte bei einem CMS Server abholen.

Content Management System
– CMS ist nicht gleich CMS.

CMS ist kein geschützter Begriff und beschreibt lediglich den Umstand, dass irgendwie und irgendwo Inhalte ausgetauscht werden. 

Aber man sollte ganz genau auf die eigene Anforderung achten. Sucht man man beispielsweise den Begriff CMS im Internet, stößt man schnell auf die üblichen Verdächtigen wie WordPress, Joomla oder Typo3. Es gibt mittlerweile unzählige Content Management Systeme, und jedes erfüllt den ein oder anderen Zweck besser oder schlechter. 

Wenn Sie beispielsweise eine Blog Seite bauen wollen, sind Sie mit WordPress gut bedient und für einen Web Auftritt sind Joomla oder Typo3 keine schlechte Wahl. 

Aber wie verhält es sich, wenn Sie verschiedene interaktive Anwendungen haben, deren Inhalte Sie ganz individuell austauschen möchten – wie zum Beispiel in einem Museum? Da offenbart sich die große Diskrepanz zu den eben aufgezählten klassischen Web-CMS Systemen. Diese Systeme sind dafür konzipiert EINE Quelle zu erstellen beispielsweise EINEN Blog mit vielleicht mehreren Unterseiten. Diese EINE Quelle wird wiederum von VIELEN Endgeräten aufgerufen, sprich viele Leute schauen sich mit ihrem Browser diesen Blog an und er sieht bei jedem Betrachter gleich aus. Wie die Inhalte angezeigt werden bestimmt in dem Fall auch das CMS, genauso wie das Verhalten der Seite.

Da kommen wir auch schon zum zweiten Kriterium, denn im Fall des Museums hat man unterschiedliche Anwendungen, zum Beispiel ein Spiel, eine Informationsanwendung und eine Video-Slideshow. Und deren Aussehen und Verhalten sollen jeweils unterschiedlich sein, also individuell programmiert. Aber alle Anwendungen sollen sich aus EINEM CMS die Daten holen. Das CMS soll also eigentlich nur Inhalte bereitstellen und sich nicht um das Aussehen kümmern, dafür aber Inhalte für viele unterschiedliche Anwendung bereitstellen.

Diese Art von CMS fällt heute eher unter den Begriff Headless-CMS. NeuroomNet beinhaltet so ein CMS. Dieses stellt eine API bereit, also eine wohldefinierte Schnittstelle, um den Programmierern eine einheitliche Möglichkeit zu geben, Inhalte von zentraler Stelle abzufragen, die vom Museum jederzeit geändert werden können.

Dieser Umstand sollte besonders bei Ausschreibungen beachtet werden. Denn erwartet man dort ausschließlich ein CMS, bekommt man unter Umständen eines der oben genannten Web-CMS. Diese Tools sind meist kostenfrei zu installieren, bringen aber nicht die gewünschte Funktionalität. 

Von der Idee zum Endprodukt

Nehmen wir einmal an, dass wir eine Software für eine Museumsanwendung schreiben lassen wollen. Zuerst sollte, wie bei jeder guten Software, ein Pflichtenheft, am besten mit aussagekräftigen Screendesigns, erstellt werden. Aber da sind die Grenzen fließend, ob man nun den klassischen Weg oder eher einen agilen Ansatz wählt.

Wenn man allerdings plant, die Inhalte später auszutauschen oder zu ergänzen, sollte man sich an dieser Stelle schon einigermaßen klar sein, welche Inhalte dies denn betrifft. Haben wir beispielsweise eine Anwendung, die alle Nobelpreisträger mit entsprechenden Zusatzinformationen auflistet, will man auch neue Wissenschaftler hinzufügen können. Schreibt man aber nun „Alle Inhalte sollen über ein CMS austauschbar sein“, hat man zum einen das Problem, dass das CMS nicht definiert ist (siehe oben), und zum anderen, dass für den Programmierer auch die Grafiken auf den Buttons oder die Hintergrundgrafik oder Beschriftungen von Buttons Inhalte sind. Es kann sein, dass man diese Inhalte auch austauschen will, aber wenn nicht, treibt das nur die Kosten in die Höhe.

Wann kommen die Daten?

Gemacht, getan, geeinigt. Die Programmierer können mit der Arbeit beginnen. Parallel werden die Inhalte erstellt. Kein Problem, die Programmierer können ja schon mal mit Dummy-Daten arbeiten. Klar können sie, aber gut wenn an dieser Stelle schon Formate geklärt sind. Überraschungen wie „oh, die Bilder sind aber groß/klein“ oder „.doc Files können wir nicht einlesen“, das braucht niemand und führen meistens auf irgend einer Seite zu mehr kosten.

Glücklich wer an dieser Stelle schon auf ein CMS zugreifen kann. Wenn das CMS in der Museums IT läuft brauchen Programmierer, Übersetzer, Grafiker etc. ’nur‘ noch ein VPN um auf die selben Daten zuzugreifen wie die intern arbeitenden Wissenschaftler und Museumsmitarbeiter.

In der Praxis sieht es meist anders aus. Dann zum Beispiel, wenn das Museum noch im Bau oder Umbau ist. Oder zumindest die IT entsprechend umgerüstet werden muss, oder, oder…

Konzentrieren wir uns daher auf die Entspannteste aller Lösungen. NeuroomNet hostet das CMS in der Entwicklungsphase für sie Online. Alle beteiligten benutzen, erstellen, korrigieren von Anfang an die selben Daten. Probleme wie zu groß, zu klein, zu viel Text, zu wenig, fallen sofort auf und nicht erst wenn die Anwendung fertig ist. Am Ende, wenn die Anwendung vor Ort installiert wird, und NeuroomNet das CMS lokal im Museum bereit stellt, zieht NeuroomNet die Daten ganz einfach in die Lokale Museums IT um.