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, it becomes 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 reloaded 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 one serves 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 reveals the big discrepancy to the classic web CMS systems just listed. These systems are designed to create ONE source, for example ONE blog with maybe several subpages. 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 slide show. And 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 querying content from a central location, which the museum can change 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 now write “All content should be exchangeable via a CMS”, you have the problem that the CMS is not defined (see above) and that for the programmer the graphics on the buttons or the background graphics are also important 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. The content is created at the same time. No problem, the programmers can work with dummy data. Of course they can, but it’s good if formats have already been clarified at this point. Surprises like “oh, but the pictures are big/small” or “we can’t import .doc files” are not needed and usually lead to more costs on some page.

Happy if you can already access a CMS at this point. If 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 internally working scientists and museum employees.

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 converted accordingly, or, or…

So let’s focus on the most relaxed of all solutions. NeuroomNet hosts the CMS online for you during the development phase. Everyone involved uses, creates and corrects the same data from the start. Problems like too big, too small, too much text, too little, are noticed immediately and not only when the application is finished. In 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.