Published on March 31, 2017 by Christopher Zimmermann
Your job is to develop the app, not to wrangle the content. Empower content authors or your marketing team to manage the content, so that you don’t have to.
Effective organizations give the right tools to the right people, so that everyone can do what they do best without friction or bottlenecks. Websites can be updated instantly because they are editable directly by the marketing staff, via an authoring interface such as a CMS. We can gain the same benefits within React apps, whether as widgets embedded on a website, single page apps, mobile apps with React Native and desktop apps with Electron for example.
Since this blog is hosted on a CMS vendor website, you may imagine that I’m going to try to sell you on it. But I promise I’m not - this will be an overview of the topic that applies to all content management systems (I’ll have another more technical post with specifics of wiring up React and Magnolia.)
Before we start, consider that every app actually does have a “content management system”, it just might be an implicit one like the popular “hard-coded strings in my source files” or “json files in my root directory”.
Compare the descriptions below to the content in your app to get ideas on how you can better manage or professionalize your app processes.
What is the main thing that people do in your app? Do they browse news, social media posts, departments in a university? Do they shop for products? This is the primary content of your app.
Or is your app different - do your visitors play a game? Or calculate something, like a route, or a mortgage? Is this still content? It may not be as clear cut - but for our purposes these can be considered as content as well. Perhaps a visitor can choose between multiple games. Or perhaps the game has multiple levels, or multiple characters, all of which can be thought of as content.
The primary content may be pulled from an existing or external content source, or it might be new custom content that you need to manage somehow.
Besides the primary content, your app has a collection of labels which help people use your app. Things like “next” and “back” links, the labels in buttons, and descriptions and help texts.
I chose a simple concrete term here - “label”, but this category really encompases the whole of the UX. You may not think of this as content in the traditional sense - but labels are something that need to be included in your app one way or another, and perhaps also translated.
Whether a simple website widget or a full mobile app, many apps display some kind of marketing content. A discount promotion, a banner for the currently active campaign, a personalized call to action based on the user's browsing history, an image to cross-sell a related product, a custom advertising banner, or a widget from an ad network are all examples of marketing content.
When considering these types of content in your app - ask yourself whether this content sometimes needs to be changed, who should be able to change it, and if it needs to be multi-language. If you are a one-person show, your needs are different than a multinational team. Let’s look at the techniques to manage content in increasing sophistication.
For all but the most basic apps, you’ll want to extract all types of content from the application itself. A first step is to store the content in external files; yaml or json formats are good options. Now the app won’t need to be rebuilt just to change a label.
The next step towards flexibility is to store this file independent of the app on a web server so that the content can be updated at any time without needing to redeploy the app. Especially in the case of a native mobile app or a desktop app, you will be able to adjust content without relying on your users to update their app.
But with files, regardless of whether they are bundled with your app or available on a web server, only a developer or technically savvy person is going to be able to update the content.
Admin UX / CMS
Enter the CMS. At the core of a CMS is a (hopefully) easy-to-use web-based admin interface that non-technical staff can log into to enter and edit content.
Your React app can retrieve the exact content it needs as JSON from REST endpoints provided by the CMS. This is ideal for structured content, where each item has a well defined set of fields, like products or departments.
Depending on your needs, it can also be convenient to retrieve pre-rendered HTML Fragments from the CMS as well. For example, a marketing team can then design a campaign promotion with complete freedom in a WYSIWYG editor, which can then be displayed in a view of your app. This use-case would be hard to achieve with simple structured content in JSON.
A common use-case is embedding a React-based app on a web page to provide some interactivity - such as a mortgage calculator. If the website is already based on a CMS, then it is a no-brainer to create a new CMS component which provides the React app. This provides two benefits for website authors:
An author can now place that React app wherever they need it on their website.
The author can manage the content of that specific app - maybe even configuring the behaviour of the app, if the app is written in a flexible manner. For example, an author could supply a formula for a calculator app.
If you are on-board with the idea of enabling authors to manage the content in your app, there’s still the question of whether to roll out your own CMS or to choose an existing one. The vast array of choices is daunting and it can feel faster to just write one than to even spend the time evaluating them. However, don’t forget the first rule of software development: “Never build your own CMS.” But seriously, it all boils down to your requirements.
Magnolia provides a free open-source community edition with a great UX and developer experience. And for big projects, like the Atlassian and Avis websites, we have an enterprise edition with features like multi-site, personalization, campaign management and advanced workflows.
Lead photo "Whirlwind" from Darion Nguyen.
See all posts on Christopher Zimmermann