Content Management im Museum

Digi­tale Inhalte sind im Museum nicht mehr weg zu denken. Aber wie sieht der opti­male Weg zum Erstellen und Einpflegen von Inhalten aus, wenn man verschie­dene Gewerke mitein­ander koor­di­nieren muss?

Das können Texte, Bilder, Videos oder Audio­auf­nahmen sein, die auf dedi­zierten Playern im Loop laufen. Auch diese Inhalte müssen verteilt werden und sollten jeder­zeit austauschbar sein. Meis­tens wird dies mittels einer Datei­über­tra­gung gemacht, sprich die Inhalte werden direkt auf die Ausspiel­sys­teme kopiert (Content Push).

Kompli­zierter wird es aller­dings, wenn diese Inhalte Teil einer größeren inter­ak­tiven Anwendung sind. Spätes­tens 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 beispiels­weise für eine kleine Text­än­de­rung ein*e Programmierer*in, der*die in München sitzt, die Anwendung neu kompi­lieren muss und die Anwendung anschlie­ßend in Berlin neu einge­spielt werden muss. Die Anwen­dungen 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 ledig­lich den Umstand, dass irgendwie und irgendwo Inhalte ausge­tauscht werden.
Aber man sollte ganz genau auf die eigene Anfor­de­rung achten. Sucht man beispiels­weise den Begriff CMS im Internet, stößt man schnell auf die übli­chen Verdäch­tigen wie Word­Press, Joomla oder Typo3. Es gibt mitt­ler­weile unzäh­lige Content Management Systeme und jedes erfüllt den ein oder anderen Zweck besser oder schlechter.
Wenn Sie beispiels­weise eine Blog Seite bauen wollen, sind Sie mit Word­Press gut bedient und für einen Web Auftritt sind Joomla oder Typo3 keine schlechte Wahl.

Aber wie verhält es sich, wenn Sie verschie­dene inter­ak­tive Anwen­dungen haben, deren Inhalte Sie ganz individuell austau­schen möchten – wie zum Beispiel in einem Museum?

Da offen­bart sich die große Diskre­panz zu den eben aufge­zählten, klassischen Web-CMS Systemen. Diese Systeme sind dafür konzi­piert, EINE Quelle zu erstellen, beispiels­weise EINEN Blog mit viel­leicht mehreren Unter­seiten. Diese EINE Quelle wird wiederum von VIELEN Endge­räten aufge­rufen, sprich viele Leute schauen sich mit ihrem Browser diesen Blog an und er sieht bei jedem Betrachter gleich aus. Wie die Inhalte ange­zeigt werden bestimmt in dem Fall auch das CMS, genauso wie das Verhalten der Seite.
Da kommen wir auch schon zum zweiten Krite­rium. Denn im Fall des Museums hat man unter­schied­liche Anwen­dungen, zum Beispiel ein Spiel, eine Infor­ma­ti­ons­an­wen­dung und eine Video-Slide­show. Deren Aussehen und Verhalten sollen jeweils unter­schied­lich sein, also individuell program­miert. Aber alle Anwen­dungen sollen sich aus EINEM CMS die Daten holen. Das CMS soll also eigent­lich nur Inhalte bereit­stellen und sich nicht um das Aussehen kümmern, dafür aber Inhalte für viele unter­schied­liche Anwendung bereit­stellen.
Diese Art von CMS fällt heute eher unter den Begriff Head­less-CMS. NeuroomNet beinhaltet so ein CMS. Dieses stellt eine API bereit, also eine wohl­de­fi­nierte Schnitt­stelle, um den Programmierer*innen eine einheit­liche Möglich­keit zu geben, Inhalte von zentraler Stelle abzu­fragen, die vom Museum jeder­zeit geän­dert werden können.
Dieser Umstand sollte beson­ders bei Ausschrei­bungen 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 kosten­frei zu instal­lieren, bringen aber nicht die gewünschte Funk­tio­na­lität.

Von der Idee zum Endpro­dukt

Nehmen wir einmal an, dass wir eine Soft­ware für eine Museums­anwendung schreiben lassen wollen. Zuerst sollte, wie bei jeder guten Soft­ware, ein Pflich­ten­heft, am besten mit aussage­kräftigen Screen­de­signs, erstellt werden. Aber da sind die Grenzen flie­ßend, ob man nun den klassischen Weg oder eher einen agilen Ansatz wählt.
Wenn man aller­dings plant, die Inhalte später auszu­tau­schen oder zu ergänzen, sollte man sich an dieser Stelle schon eini­ger­maßen klar sein, welche Inhalte dies denn betrifft. Haben wir beispiels­weise eine Anwendung, die alle Nobel­preis­träger mit entspre­chenden Zusatz­informationen auflistet, will man auch neue Wissen­schaftler hinzu­fü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 defi­niert ist (siehe oben), und zum anderen, dass für die Programmierer*innen auch die Grafiken auf den Buttons oder die Hinter­grund­grafik oder Beschrif­tungen von Buttons Inhalte sind. Es kann sein, dass man diese Inhalte auch austau­schen will, aber wenn nicht, treibt das nur die Kosten in die Höhe.

Wann kommen die Daten?

Gemacht, getan, geei­nigt. Die Programmierer*innen können mit der Arbeit beginnen. Parallel werden die Inhalte erstellt. Kein Problem, die Programmierer*innen können ja schon mal mit Dummy-Daten arbeiten. Klar, können sie. Aber gut, wenn an dieser Stelle schon Formate geklärt sind. Über­ra­schungen wie „Oh, die Bilder sind aber groß/klein“ oder „.doc Files können wir nicht einlesen“ – Das braucht niemand und führen meis­tens auf irgend­einer Seite zu mehr Kosten.
Glück­lich wer an dieser Stelle schon auf ein CMS zugreifen kann. Wenn das CMS in der Museums IT läuft, brau­chen Programmierer*innen, Übersetzer*innen, Grafiker*innen etc. “nur” noch ein VPN, um auf die selben Daten zuzu­greifen wie die intern arbei­tenden Wissenschaftler*innen und Museumsmitarbeiter*innen.
In der Praxis sieht es meist anders aus. Dann zum Beispiel, wenn das Museum noch im Bau oder Umbau ist. Oder zumin­dest die IT entsprechend umge­rüstet werden muss, oder, oder, oder…
Konzen­trieren wir uns daher auf die Entspann­teste aller Lösungen. NeuroomNet hostet das CMS in der Entwick­lungs­phase für sie online. Alle Betei­ligten benutzen, erstellen, korri­gieren 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 instal­liert wird und NeuroomNet das CMS lokal im Museum bereit stellt, zieht NeuroomNet die Daten ganz einfach in die lokale Museums IT um.