New web-powered devices, such as wearables and augmented reality, have changed the way we experience the web. How must we change the way we develop our web content to ensure we’re still delivering the best experiences possible?
For as long as most of us have understood and experienced the internet, we’ve accessed it via a web page, but with new interfaces and web-powered devices on the market, such as wearables, IoT, augmented and virtual reality, and conversational interfaces, that’s increasingly changing.
As a software studio that works with these leading-edge technologies every day, we at Myplanet have been keeping close tabs on the ways these new items alter how we experience the web.
Yes, these devices are connected, but they’re not relying on a traditional website interface. As the experience of being connected changes, how we create those experiences needs to change, too.
For example, people are accessing Android devices of all shapes and sizes and with widely differing capabilities.
Visual representation of fragmentation of Android devices, 2014. Source: opensignal.com
This fragmentation shows how many different types of devices are using the same operating system.
One thing that remains constant, however, is the continued need for content. But while that content is often identical in substance to the website-based content we’re used to, it tends to differ substantially in presentation and format. And that’s what complicates the ways we develop for it.
Delivering content can have vastly different requirements from one setup to another, and it can be needlessly cumbersome if we adhere to our old solutions, which is why it’s a very good idea to become familiar with decoupling.
What is Decoupling?
Before we get to why decoupling is a good solution for the new challenges posed by the changing digital landscape, we need to establish what it is and how it differs from a coupled content management system (CMS) and a completely headless CMS.
Coupled: To understand decoupled CMS, you need to understand what a coupled CMS is.
A coupled (also known as “traditional” or “monolithic”) CMS knits together the front- and back-ends. Working off the same application, developers and content managers make adjustments to the back-end while users interact with the front-end, but both are experiencing, viewing, and interacting with the same system.
The underlying works serve both the authoring side of things (i.e., development and content management) and the delivery side (i.e., the live-site customer experience). In the familiar world of website-only internet experiences, this system made a lot of sense, but with new technology, it doesn’t always work today.
Decoupled: In a decoupled CMS, the front-end and back-end are separated. The CMS handles the back-end, and a delivery system handles the front with an application programming interface (API) that connects them for publishing.
Because they are separated, developers and content managers have greater flexibility and faster delivery for their user experiences across websites, apps, and other devices, making this option a very appealing option in a rapidly changing digital scene where two visitors are likely to experience the sites from different sized screens and perspectives.
Headless: Unlike a decoupled instance, a headless CMS never has a predefined front-end.
This option provides the greatest flexibility for developers, as it allows content to be pushed to any output option.
The legwork of headless can be much higher, and this solution may necessitate having a developer working full-time with the content team. Depending on the needs, a more straightforward coupled approach might make more sense.
Each of these options has advantages, and each one is the best choice in certain situations. However, based on our experiences working on projects for clients with needs that encompass commerce, accessibility, and easy information dissemination, the flexibility and speed alongside the realities of budget, time, and developer availability make decoupled CMS the one we’re turning to with increasing regularity.
Decoupling Delivers Content Across Platforms
As websites shift from being the only format to one of many, decoupling can solve many of the problems that arise when we need to deliver content across platforms and systems. And as the digital world offers more and more devices, it is an increasingly important option to consider.
Erin Marchak, a senior Drupal developer at Myplanet, has been working with decoupled Drupal with increasing frequency over the past two years. She knows the advantages of decoupling well and is an advocate for the decoupled approach.
“Decoupling allows front-end and back-end development to be separate but to still work together,” Marchak said. By doing this, she notes that “front- and back-end teams can work at their own pace,” the end result of which is a system with fewer development blocks at the outset because neither group is dependent on the other. Plus, by separating them out, decoupling takes advantage of the typically greater longevity of back-end structures, saving both effort and money in the long run.
Headless Approach Provides Flexibility
Still, some organizations do need the flexibility enabled by a headless approach.
“One of the biggest advantages we’ve found with a decoupled approach is that the final output can have multiple heads,” Marchak said. “Being able to serve content to multiple instances, whether it’s a website or a native app or TV set-top box makes a big difference to content authoring and management, especially when applied at scale.”
A headless approach is API-first, which means it can deliver content anywhere and on any device and through both coupled and decoupled options.
Because of our extensive work with both coupled and decoupled Drupal, we know firsthand that a solution that can do both simultaneously works incredibly well for our customers. Even in standard delivery options (i.e., a typical website), the decoupled option can allow for more dynamic user experiences, as was the case on a recent project we worked on for the travel brand Trek America.
“Using a content repository, we were able to combine both the geographic information system (GIS) and marketing data in decoupled, interactive maps utilizing Google’s APIs. By doing this, users have the power to interact with locations, so they can explore and gain context on their trips.” — Myplanet “Trek America” Case Study
With the headless approach, users of Trek America can interact with locations.
API-First Approach Offers Advantages
In its annual ranking of content management systems, Gartner listed an API-first approach as one of the key reasons for placing some of its highest-ranked platforms on top.
The highest-ranked companies are API-first.
Dries Buytaert, founder and lead developer of Drupal and CTO of Acquia, emphasizes the flexibility of the options as well: “Content management systems need to serve content beyond editor-focused websites to single-page applications, native applications, and even emerging devices such as wearables, conversational interfaces, and IoT devices.”
Not every instance requires a headless solution, but for those that do, the flexibility to choose headless offered by decoupling is a compelling and important advantage.
When we look at the digital landscape and the shifting tides brought on by wearables, IoT, and more, the reality is it’s not just good to be thinking API-first, it’s essential.
Buytaert agrees, saying, “An API-first approach is critical in a world where you have to operate agnostically across any channel and any form factor.”
Decoupling is a growing area in development circles, and it should be on everyone’s radars going forward.
Choose the Right Approach
There are tradeoffs when we change how we do things—there always are—but as API-first gains momentum and our hardware shifts to demand more flexible software solutions, it’s clear that decoupling is not going anywhere.
About the Author
Leigh Bryant is a content manager at Myplanet, a software studio in Toronto, Canada, that makes smarter interfaces that empower employees and engage customers.