Content management in the museum

Digital content has become indis­pensable in museums. But what is the optimal way to create and post content when you need to coor­di­nate diffe­rent trades with each other?

These can be texts, images, videos, or audio recor­dings that run on dedicated players in the loop. This content must also be distri­buted and should be inter­ch­an­geable at any time. In most cases, this is done using a file transfer, i.e. the content is copied directly to the playout systems (content push).

However, things get more compli­cated when this content is part of a larger inter­ac­tive appli­ca­tion. At the latest then one should no longer do without the use of a CMS. Because at that point, content exch­ange may become expen­sive. For example, if a programmer based in Munich has to recom­pile the appli­ca­tion for a small text change and the appli­ca­tion then has to be re-installed in Berlin. The appli­ca­tions should ther­e­fore be written or created in such a way that they fetch the content from a CMS server.

Content Management System — CMS is not just CMS.

CMS is not a protected term and simply describes the fact that somehow and some­where content is exch­anged.
But you should pay very close atten­tion to your requi­re­ment. If you search for the term CMS on the Internet, for example, you will quickly come across the usual suspects such as Word­Press, Joomla, or Typo3. There are now count­less 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 Word­Press and for a web presence Joomla or Typo3 are not a bad choice.

But what about when you have diffe­rent inter­ac­tive appli­ca­tions whose content you want to share individually — like in a museum, for example?

This is where the big discrepancy with the classic web CMS systems just listed becomes appa­rent. These systems are desi­gned to create ONE source, for example, ONE blog with perhaps several sub-sites. This ONE source is in turn accessed by MANY devices, meaning many people look at this blog with their browser and it looks the same to every viewer. In this case, the CMS also deter­mines how the content is displayed, as well as the beha­vior of the page.
This brings us to the second criterion. Because in the case of the museum, you have diffe­rent appli­ca­tions, for example, a game, an information appli­ca­tion, and a video slide­show. Their appearance and beha­vior should be diffe­rent in each case, i.e. individually programmed. But all appli­ca­tions should get the data from ONE CMS. So the CMS should only provide content and not care about the appearance, but provide content for many diffe­rent appli­ca­tions.
This type of CMS today rather falls under the term head­less CMS. NeuroomNet includes such a CMS. This provides an API, i.e. a well-defined inter­face, to give programmers a uniform way of retrie­ving content from a central loca­tion, which can be changed by the museum at any time.
This circum­s­tance should be taken into account, espe­ci­ally in tenders. Because if you expect only a CMS there, you might get one of the web CMSs mentioned above. These tools are mostly free to install but do not bring the desired func­tion­a­lity.

From the idea to the end product

Let’s assume that we want to have soft­ware written for a museum appli­ca­tion. First, as with any good soft­ware, a speci­fi­ca­tion sheet should be created, prefer­ably with meaningful screen designs. But there the boun­da­ries are fluid, whether you choose the classic path or more of an agile approach.
However, if you plan to exch­ange or add to the content at a later date, you should already be reason­ably clear at this point about what content this concerns. For example, if we have an appli­ca­tion that lists all Nobel laureates with corre­spon­ding additional information, we also want to be able to add new scientists. But if you write “All content should be exch­an­geable 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 back­ground graphics or labels of buttons are content. You may want to share that content as well, but if you don’t, it just drives up the cost.

When will the data come?

Done, done, agreed. The programmers can start working. In parallel, the content is created. No problem, the programmers can already work with dummy data. Sure, they can. But good, if formats are already clari­fied at this point. Surprises like “Oh, but the pictures are big/small” or “.doc files we can’t read in” — Nobody needs that and usually lead to more costs on some side.
Lucky who can already access a CMS at this point. When the CMS is running in the muse­um’s IT, programmers, trans­la­tors, graphic designers, etc.“only” need a VPN to access the same data as the scientists and museum staff working intern­ally.
In prac­tice, things usually look diffe­rent. Then, for example, when the museum is still under cons­truc­tion or recon­s­truc­tion. Or at least the IT has to be retooled accor­dingly, or, or, or.…
Ther­e­fore, let’s focus on the most relaxed of all solu­tions. NeuroomNet hosts the CMS online for them during the deve­lo­p­ment phase. All parti­ci­pants use, create, and correct the same data from the begin­ning. Problems like too big, too small, too much text, and too little, are noticed imme­dia­tely and not when the appli­ca­tion is ready. At the end, when the appli­ca­tion is installed on-site and NeuroomNet provides the CMS locally in the museum, NeuroomNet simply moves the data to the local museum IT.