When Unisphere Research asked the top global service providers, creating a unified user experience in a cross platform environment was the most desirable achievement for the service providers of today.
I dare to venture to say that designing and shipping a solution that has such traits (i.e. a unified and high quality user experience across all platforms) is the “easy” part. Finding the backend service stack that can help you manage not only the platforms but also cater to your specific deployment needs over time however, is in an entirely different ballpark.
In this article, I will discuss one of the pillars of such a service stack that historically may have been overseen or at least taken too lightly, namely the appearance- and layout management. With this, I’m referring to how you as an application owner and content provider can control how your application behaves, looks and presents the content that you supply to your end users, across screen sizes and devices types, geographical borders and time of day, application- and platform OS versions, and so on and so forth.
Taking all of these dimensions into consideration, it becomes apparent that any system that aims at solving any one of your problem(s) either has to be a productised jack of all trades, giving you, your designers and developers full flexibility and the ultimate choice on how to structure whatever piece of information you’d like to model in the system; or a system that is built according to specs and fully tailored to you and your needs. Anything other than either of these, will most likely eventually have you run into a brick wall at full speed as your application solution evolves and becomes more and more complex, giving you the realisation that the solution you were promised couldn’t deliver on this or that topic. With custom solutions often ending up being very cost-inefficient (since you pay for every piece of functionality being developed, even though the functionality may already exists in some other deployment of the base product), accompanied by a sometimes dodgy SLA, I’m going to promote the aforementioned.
More specifically, if I were a service provider with anything other than an aspiration for a WordPress-driven Web application, I would use a headless Content Management System (CMS) to manage the content-, layout and appearance management of the deployment. A headless CMS is a CMS which serves data through an API rather than embedded in HTML templates and stylesheets. Equally important, if not more, is that it also allows for you yourself to actually define and take control of the models of whatever piece of content you want to manage, be it your page structure, articles, video items or even your app translations. In contrast, a standard CMS usually have predefined templates for what metadata you can supply in any given content piece, and those predefined templates usually never cover all the needs of any given application design, especially not if in a cross-platform context.
Working with a headless CMS basically has four steps to it, namely
- You define the models of your content pieces (be it your pages, containers, menus, dictionaries, articles, etc.) within models (in headless systems they’re usually called models, entry types or content types). Although it might sound complex, it’s actually pretty straight-forward; if your articles needs a header, body and some images, you define the model for your articles to contain just that; two text fields and one image field. Similarly, if your Pages require to contain a title, as well as some carousels and grids, you set up the model to enable just that.
- Your developers develop the applications around the models you’ve created and modelled in the headless CMS, catering to the design guidelines of the platform and leveraging the best-of-breed technologies available on each platform and device type.
- You populate and publish content pieces, creating them based on the models you have defined and you work with the publishing workflow, as would be expected from a classic CMS such as WordPress or Drupal.
- The applications consume the content through an API, such as a RESTful JSON-based API and display them in whatever way you have chosen to design the applications on the various platforms.
The possibilities and upsides of using a headless CMS, as mentioned before, really stands out in multi-platform deployments, especially when dealing with native application deployments and custom designs, but can provide huge benefits in a variety of contexts. Although not at all a full list and in no particular order, I’ve gone ahead and listed some of these below.
- You are in full control of your models, design and logic, not hindered by set templates and service restrictions, allowing not only the individual applications-, but also your service offering and platform reach to evolve with a minimal risk of requiring patch-work systems and solutions,
- The content is served through a fast and stripped-down API with minimal overhead and unnecessary data traffic, optimizing load times and performance and therefore user experience, with a clear separation of concern for design and data,
- All applications can cater to best practises, design guidelines and best-of-breed industry technologies to present your content on the various platforms, easing the user journey and discovery process,
- All platforms can be managed from one service, aligning internal stakeholders, minimizing learning curves and knowledge management as well as cutting costs and minimising risks of having to juggle multiple solutions,
- You don’t need to wear a helmet since the solution is headless.
At Accedo, we have helped our customers address the complexities of delivering and more importantly managing highly dynamic cross-platforms deployments without sacrificing the UI/UX quality for more than a decade. Recently, I performed a webinar together with Raphael Duhayon, our Product Manager for AppGrid, Accedo’s cloud-based configuration- and content management platform, which enables content providers to solve the problems described in this article. If this sounds like a challenge that you shouldn’t neglect any more, feel free to check out this link webinar video or drop by http://www.accedo.tv/appgrid for more information.
If there’s one thing you should take with you from reading this article, it should be that as the complexities of navigating the OTT space, with competition popping up around every corner, you should never consider an application deployment as a one-time investment. Because the winner of this race is not the one first out of the starting gate or even the one first crossing the finish line, it’s the one who still stands when everybody else has dropped out from exhausting their resources.