Home »
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.
In an “all-around happy package,” we accomÂpany you from consulÂtaÂtion, planÂning, hardÂware procuÂreÂment, instalÂlaÂtion, confiÂguÂraÂtion, and commissioning to documentation and training of your staff.