CMS’ have greatly changed the way we as web developers think, code and evolve our digital solutions. As the tech landscape changes, we now need to account for more and more ways that content can be accessed. First it was hindered by browser compatibility, then it was responsive design, next mobile apps, and now it’s voice. With the plethora of devices that people access content through, how can we as developers keep up?
Enter a decoupled world…
Decoupled Drupal is a concept that has been floating for a few years now. The idea of decoupling was first brought to peoples attention with the advent of mobile apps. The idea with behind decoupling your content sent as a structured data set that is then interpreted on the device in the best way possible. You enter the data once and it goes everywhere. In this way, a Drupal site can power a web app, mobile phone app, and an Alexa skill all from the same content. This also allows for development teams to all get along because the backend nerds can have fun in the database with code, frontend hipsters can gulp their coffee-script until they burn themselves with an ember(.js) and the iOS developers can remortgage their house to fit the app around “the notch.” Dries has publicly said that this is in his view the way forward for Drupal and is in theory great. However, decoupled Drupal costs a lot more to develop it does seem me to have one fatal flaw.
Decoupling Drupal comes at the expense of the developers end user — the content editors. As a developer, we need to remember it is through the needs of the content editors that have made CMS’ what they are today. Having a decoupled site is great in it allows for content be repurposed and provides a native experience to the user. A caveat to that is that the editorial functionality has to be diminished (the last thing you would want is Alexa spurting out about the <h1> and <p> tags in the site) resulting in a reduced feature-set for the editors. However, editors requirements are more becoming more rigorous than ever before as services like Squarespace provide flexibility around the layout and positioning of the site. A common capability I am asked for in a CMS is a set of features to facilitate easy building of pages and to be able to easily create landing pages. This isn’t something that easily possible within decoupled sites.
So, what’s next?
Enter Experience Management
I believe the next step isn’t about decoupling but actually better tying the needs of the editor better together to provide a more coherent experience. To do this we need to identify push and pull relationship that our content editors are working with on a daily basis to best captivate their end users. Content editors are constantly trying to entice (pull) new users through the channels that are available and illustrate the end user how their content is of benefit. Then they are reminding (pushing) the end user that the content is there. This content may be a new service, new product or a news story. It is the overall combination of this experience which forms the basis of a brands unique identity today and is what we as developers need to be focusing on how we best provide the management of this to our clients. Today in 2018, a CMS actually needs to be responsible for a whole lot more and actually should be an experience management system.
How do we tackle this mountain of a problem?
That’s a great question. In my next post, I’ll outline how I think we best achieve this. :)