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; it simply describes the fact that content is exch­anged in some way and some­where.
But you should pay very close atten­tion to your own requi­re­ments. For example, if you search for the term “CMS” on the Internet, you’ll quickly come across the usual suspects like Word­Press, Joomla, or Typo3. There are now count­less content management systems, and each one fulfills one purpose or another—some better than others.
For example, if you want to build a blog, Word­Press is a good choice, and for a website, Joomla or Typo3 aren’t bad options.

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 reveals the major discrepancy compared to the tradi­tional web CMS systems listed above. These systems are desi­gned to create ONE source—for example, ONE blog with perhaps several subpages. This SINGLE source is, in turn, accessed by MANY devices—that is, many people view this blog using their brow­sers, 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 page’s beha­vior.
This brings us to the second criterion. In the case of the museum, there are diffe­rent applications—for example, a game, an infor­ma­tional appli­ca­tion, and a video slide­show. Their appearance and beha­vior should each be different—that is, individually programmed. But all appli­ca­tions should retrieve their data from ONE CMS. So the CMS is actually intended to provide content only and not worry about the appearance, but instead supply content for many diffe­rent appli­ca­tions.
Today, this type of CMS is gene­rally referred to as a head­less CMS. NeuroomNet includes such a CMS. It provides an API —a well-defined interface—to give programmers a stan­dar­dized way to retrieve content from a central loca­tion, which the museum can modify at any time.
This should be taken into account, espe­ci­ally in calls for propo­sals. This is because if a call for propo­sals speci­fies only a CMS, the result may be one of the web-based CMSs mentioned above. These tools are usually free to install but do not provide the desired func­tion­a­lity.

From the idea to the end product

Let’s assume we want to have soft­ware deve­loped for a museum appli­ca­tion. First, as with any good soft­ware, a requi­re­ments speci­fi­ca­tion should be created—ideally with detailed screen designs. But the lines are blurred here, whether you choose the tradi­tional approach or a more agile one.
However, if you plan to replace or supple­ment the content later, you should already have a reason­ably clear idea at this stage of exactly which content this will affect. For example, if we have an appli­ca­tion that lists all Nobel Prize winners along with rele­vant additional information, we’ll also want to be able to add new scientists. But if you write, “All content should be replaceable via a CMS,” you face two problems: first, the CMS isn’t defined (see above), and second, from the programmers’ perspec­tive, the graphics on the buttons, the back­ground image, and the button labels are also considered content. It’s possible that you’ll want to update this content as well, but if not, it will only drive up costs.

When will the data come?

Done and dusted, everything’s settled. The programmers can get to work. Mean­while, the content is being created. No problem—the programmers can work with dummy data in the mean­time. Sure, they can. But it’s good if the file formats are already clari­fied at this stage. Surprises like “Oh, but the images are too big/too small” or “We can’t import .doc files”—nobody needs that, and it usually leads to extra costs down the line.
Lucky are those who already have access to a CMS at this stage. If the CMS runs on the museum’s IT infra­struc­ture, programmers, trans­la­tors, graphic designers, etc.,“only” need a VPN to access the same data as the rese­ar­chers and museum staff working in-house.
In prac­tice, things usually look diffe­rent. For example, when the museum is still under cons­truc­tion or under­going reno­va­tions. Or at least when the IT infra­struc­ture needs to be upgraded accor­dingly, or, or, or…
Let’s ther­e­fore focus on the most stress-free of all solu­tions. NeuroomNet hosts the CMS online for you during the deve­lo­p­ment phase. Ever­yone involved uses, creates, and corrects the same data from the very begin­ning. Problems such as “too big,” “too small,” “too much text,” or “too little text” are noticed immediately—not only after the appli­ca­tion is finished. In the end, when the appli­ca­tion is installed on-site and NeuroomNet makes the CMS available locally at the museum, NeuroomNet simply migrates the data to the museum’s local IT system.