Content management in the museum
Digital content has become indispensable in museums. But what is the best way to create and add content if you have to coordinate different trades with each other?
This can be text, images, videos or audio recordings that run in a loop on dedicated players. This content must also be distributed and should be exchangeable at any time. This is usually done by means of a file transfer, i.e. the content is copied directly to the playout systems (content push).
However, things get more complicated when this content is part of a larger interactive application. By then, at the latest, you should no longer be without a CMS. Because at this point an exchange of content can become expensive. For example, if a programmer based in Munich has to recompile the application for a small text change and the application then has to be re-installed in Berlin. The applications should therefore be written or created in such a way that they retrieve the content from a CMS server.
content management system – CMS is not just CMS.
CMS is not a protected term and merely describes the fact that content is exchanged somehow and somewhere.
But you should pay close attention to your own requirements. If you search for the term CMS on the Internet, for example, you will quickly come across the usual suspects such as WordPress, Joomla or Typo3. There are now countless content management systems and each fulfills one or the other purpose better or worse.
For example, if you want to build a blog site, you are well served with WordPress and for a web presence, Joomla or Typo3 are not a bad choice.
But what if you have different interactive applications whose content you want to exchange individually – such as in a museum? This is where the big discrepancy with the classic web CMS systems just listed becomes apparent. These systems are designed to create ONE source, for example ONE blog with perhaps several sub-sites. This ONE source is in turn called up by MANY end devices, i.e. many people look at this blog with their browser and it looks the same to every viewer. In this case, the CMS also determines how the content is displayed, as well as the behavior of the page.
This brings us to the second criterion. Because in the case of the museum, you have different applications, for example, a game, an information application and a video slideshow. Their appearance and behavior should be different in each case, i.e. individually programmed. But all applications should get the data from ONE CMS. So the CMS should actually only provide content and not care about the appearance, but instead provide content for many different applications.
Today, this type of CMS is more commonly referred to as headless CMS. NeuroomNet includes such a CMS. This provides an API, i.e. a well-defined interface, to give programmers a uniform way of retrieving content from a central location, which can be changed by the museum at any time.
This circumstance should be taken into account in particular in the case of tenders. Because if you only expect a CMS there, you might get one of the web CMS mentioned above. These tools can usually be installed free of charge, but do not provide the desired functionality.
From the idea to the end product
Suppose we want to have software written for a museum application. As with any good software, a specification should first be created, preferably with meaningful screen designs. But there the boundaries are fluid, whether you choose the classic way or rather an agile approach.
However, if you plan to exchange or add to the content later, you should be reasonably clear at this point which content this affects. For example, if we have an application that lists all Nobel Prize winners with the corresponding additional information, you also want to be able to add new scientists. But if you write “All content should be exchangeable via a CMS”, you have on the one hand the problem that the CMS is not defined (see above), and on the other hand that for the programmers also the graphics on the buttons or the background graphics or labels of buttons are content. You may want to share that content as well, but if you don’t, that just drives up the cost.
When is the data coming?
Done, done, agreed. The programmers can start working. At the same time, the content is created. No problem, the programmers can work with dummy data. Sure, they can. But it’s good if formats are already clarified at this point. Surprises like “Oh, but the images are big/small” or “.doc files we can’t read in” – Nobody needs that and usually leads to more costs on some side.
Happy if you can already access a CMS at this point. When the CMS is running in the museum’s IT, programmers, translators, graphic designers etc. ‘only’ need a VPN to access the same data as the scientists and museum staff working internally.
In practice it usually looks different. For example, if the museum is still under construction or renovation. Or at least the IT has to be retooled accordingly, or, or, or….
So let’s focus on the most relaxed of all solutions. NeuroomNet hosts the CMS online for them during the development phase. All participants use, create, correct the same data from the beginning. Problems like too big, too small, too much text, too little, are noticed immediately and not when the application is ready. At the end, when the application is installed on site and NeuroomNet provides the CMS locally in the museum, NeuroomNet simply moves the data to the Local Museum IT.
