What to look for in a Mobile CMS?

Contents
    Try Storyblok

    Storyblok is the first headless CMS that works for developers & marketers alike.

    Management of mobile content is crucial for online businesses as a growing number of consumers prefer to shop through their phones. A robust mobile CMS (content management system) can ensure persistent quality, fast customer experience, while one lacking in proper qualities can turn away loyal customers. At the same time you don’t want a CMS solely designed with mobile apps in mind. The best CMS can manage your content on any digital channel. This article will outline the most essential factors in choosing the right mobile CMS with eCommerce issues particularly in mind.

    Content being managed on android and iOS apps, plus websites.

    What exactly is a Mobile CMS?

    Depending on your perspective, you may have two different answers to this question:

    1. A CMS for managing mobile apps: This basically means managing the content used on a native mobile app. For example, if you have an online shop and sell your products through an app, all the product information and everything else that shapes your storefront will be managed through a CMS.

    2. A CMS for managing mobile websites: This would mean managing content for websites specially optimized for mobile experiences.

    Let’s take a typical example: a clothing brand selling their products through an app. If you think about it, every single product in their catalog has a unique description, a dedicated page, and at least a couple of pictures. This is of course in addition to a considerable amount of content that is not directly connected to the products, but the brand itself.

    So what are the options here?

    Not using a dedicated CMS (app as content storage)

    The first and arguably worst one is to use the app itself as a platform for managing content, meaning storing all the content inside the app. In other words, this means not using a CMS at all and having the content interfere with the native code. This seems like a simple and straightforward solution; however, the negative consequences are so crucial that it rarely pays off to do so. For example:

    • Slow user experience: If all content is saved locally, the app would require greater processing resources on the user’s end, just to function normally. This will eventually lead to many customers experiencing slow and unresponsive shopping sessions.

    • Lengthy content updates: Since content would be an inherent part of the app, every content update (creation, modification, or deletion) would be technically registered as a change to the app itself. This means every single content update would count as an app update, which means the app must be resubmitted to the app store every single time.

    • No link between the apps: If the business decides to offer multiple apps on the same operating system, or the same app on different operating systems (or even a combination of both), then each app has to be treated as a completely isolated case. Meaning each update would have to be manually applied to every app. Combined with the last point, this means a huge amount of time and effort has to be spent just to put the products on display.

    • No link between the app(s) and other digital touchpoints: Let’s assume that our hypothetical online business also has a website that sells the same products. If the app is used as a quasi CMS, then the content cannot be shared between the two (or more) platforms.

    • Complicated omnichannel and personalization processes: Considering all the points, maintaining a quality presence in different platforms suddenly becomes an extremely difficult task. Just updating and applying the same quality for Android and iOS would be a huge burden. In an environment where updating content takes so much time and effort, any personalization attempt is hindered significantly.

    All these shortcomings mean that this option could only benefit cases where the app has an extremely limited amount of content. In the case of eCommerce, this means if you have a catalog with a wide-ranging set of products, or if the products are updated regularly, then this is not the right choice for you. However, if you have an extremely small set of products that are going to remain more or less the same way for a long time, then this can be a simple solution for your content management issues.

    We have been talking about the app, but what about the mobile website?

    That is the other major flaw in this solution: you have to manage the website through a separate CMS. This means content management on the app and the website will be done in isolation without any link. This severely increases the effort and resources you need to use the same content in different formats. Every piece of content has to be tailored twice, every update has to be manually applied to the app and the website separately, and so on. This is virtually doubling your work-load for no good reason.

    Using mobile BaaS as a CMS

    Another option that some choose to take, is using backend-as-a-service (BaaS) as a CMS. Instead of copying all the content within the app, this option offers the possibility to store everything in a provided back-end. Since the content is not going to be stored within the app, many of the previously mentioned issues are going to be fixed, however, there are some problems that also show themselves here.

    It is important to know that what BaaS solutions offer is strictly a back-end, and not necessarily content management capabilities. In other words, these solutions usually lack comprehensive editorial tools and workflows. However, the biggest drawback here is that BaaS solutions are extremely developer-oriented and are unfriendly towards editors and non-technical users.

    Baas solutions have the same major flaw as the previous solution: neither of them can help you with maintaining a website optimized for mobile users. This means you have to deal with two different solutions for your content management on the app(s) and the website(s).

    Using an API-first mobile CMS

    While mobile apps are extremely popular among shoppers, people still use their phones’ browsers to visit websites and purchase products. This is why settling for a solution that ignores the mobile websites completely doesn’t seem like a good option. Additionally, it is more likely that if an online business has an app, they already have an established website that is supposed to offer services on computers and mobile devices. This means that in most cases, eCommerce companies should find a solution that would address their app and website needs simultaneously and more importantly with the same quality.

    What do I mean by offering the same quality simultaneously? Well just try to imagine all the possible devices that people may use to access an online shop: phones with different operating systems and screen sizes or resolutions, tablets of any kind, smartwatches with completely different shapes, and even voice-activated assistants. If you fail in offering your products/services through any of these devices, then you are actively limiting your revenue. In the meantime, if you offer your products without ensuring a sense of consistency in quality, you are eventually going to lose some customers.

    So how can you offer a true omnichannel experience to your consumers on mobile devices? Try using an API-first CMS.

    API-first refers to the central role of application programming interfaces (APIs) in these systems. APIs work as interfaces that define the interactions between different software intermediaries. The common analogy used to describe them is “waiters in a restaurant”: they are the “interface” customers have to deal with, without worrying about whatever goes on in the kitchen. This means easy access to services without directly interacting with the “engine”.

    APIs delivering content from the back-end to different devices and platforms.

    How do APIs fix the problems?

    Very simply said, your content will be stored in a central hub (not inside the app itself), which is then “called” through APIs and delivered to every place it is needed. This not only means a lighter app, but also complete control over the actual management of the content which BaaS solutions lack.

    These content management systems are also known as “Headless”. Headless in this context simply means that the front-end (the presentational end or the “head”) is separated from the back-end (the engine or the foundational pillar, the “body”). This way, you can fit as many different “heads” (websites, apps, etc.) as you want on the same “body”. You can read this article for a more detailed look on headless systems.

    The headless nature means you can use the same CMS to create and manage content on every platform and device, using the same hub. In other words, not only the app and the mobile-optimized website are managed from the same place (and with the same quality), but also any further touchpoints such as computers and smartwatches are covered.

    Content Management for eCommerce

    Read our comprehensive marketer's guide to content management, complete with a free evaluation guide!

    Where should I begin: How to choose the best mobile CMS.

    Depending on your current content strategy, you might have different roads ahead of you. If you currently have no CMS, then you are free to experiment with different API-first systems to find out which one suits your needs better. Some companies like Storyblok offer completely free trials where you can familiarize yourself with the system before making any decision.

    If you are already using a CMS which is not API-driven, then you should consider your individual goals and strategies before making the jump. As each case is different, the best way to go ahead is to try the different options yourself and see which one suits you best. However, since most traditional (non-API-driven) CMSs share a set of core characteristics, you can start by taking this quick comparison table into account:

    Traditional CMS Headless CMS
    Approach Monolithic Headless through APIs
    Targeted Devices Web-only All devices
    Setup Based on specific CMS rules Based on your existing tech stack
    Coding Co-existing content, CMS, and Front-end code creates dependency, making each addition a complex task Content is independent and works with API calls. Any new "head" can be added with simplicity
    Customer's Interface Pre-built templates with minor customization possible Absolute control over the presentation of content
    Technology Choice Dictated by the CMS Free Choice
    Redesign Changes require modifying the whole system Changes are isolated to cases
    Platform independence - Yes
    Cross Platform Support - Yes

    In addition, there are a couple of clear indicators that a headless CMS would serve your business better than a traditional one. For example:

    • You want your content and products to stand out amongst the competition by giving your users an individually tailored experience that is unique to your brand.

    • Speed is a priority in your business. You want your customers to have a quick experience on your platform, but also you want them to receive their personalized content as fast as possible.

    • Your business requires omnichannel presence and cross-platform support is a primary issue.

    • Your business produces a lot of content and/or needs to update its existing content regularly.

    • Flexibility and customization are high-importance concerns.

    Mobile Content Management Checklist: Choosing a mobile CMS

    If you decide to settle on a new mobile CMS, there are some key features that you should definitely look for:

    1. It has to support both the app(s) and the website(s).

    2. It should offer omnichannel publication on different devices (pc, phone, tablets, virtual assistants, AR/VR headsets, smartwatches, etc.)

    3. It should allow your marketers and content editors to create content without having to rely on programmers.

    4. It has to support content automation and reusability through modular systems and implementing intelligent content.

    5. It should support best-of-breed practices.

    6. It should give you complete control over the customization of content and must not be limited to pre-made templates.

    7. It should be framework-agnostic and give your developers the freedom to work with their own preferred methods.

    Dive deeper

    Still unsure? You can read more about content management systems and eCommerce issues in our other resources before making any decisions:

    Resource Links
    Headless CMS Headless CMS explained in 5 minutes
    CMS for eCommerce The new era of eCommerce CMS
    Headless stack or monolithic package Best-of-breed vs. all-in-one
    A complete guide to eCommerce content management Content management for eCommerce
    eCommerce integrations Storyblok’s eCommerce integrations

    An error occurred. Please get in touch with support@storyblok.com

    Please select at least one option.

    Please enter a valid email address.

    This email address is already registered.

    Please Check Your Email!

    Almost there! To confirm your subscription, please click on the link in the email we’ve just sent you. If you didn’t receive the email check your ’junk folder’ or