Managing content in a decoupled Drupal
"Um...ok...what?" That was my first reaction when I learned that the new web project I had signed on to manage was built with a "headless Drupal," or more commonly referred to as decoupled architecture. I had been having problems understanding why our digital partner kept telling me "this website works in a new way." I had so many questions - and that was his answer. He didn't explain to me, a professional with over 10 years of open source content management experience, how our web architecture was different than what I had expected. I concretely expected to create content types, taxonomies, views, and panels. I planned my work around the ability to have flexibility and ease in making front-end adjustments. But to my surprise, my hands were tied.
I suspect much of my frustration was rooted in the fact that while decoupled architecture is hailed as the next big thing, even the experts don't have much experience with products designed this way, making it difficult for them to help onboard their clients to the "Lamborghini" of architectures.
So what have I learned?
- Having a front-end developer that can work in this environment is necessary. That means you need someone interested in the front-end and back-end technologies. You need a self starter. Someone who is more stubborn than the rest. And most importantly, you want to work with someone who knows the potential of decoupled architecture.
- Break your habits. The role of content administrator/content strategist has emerged as a result of user friendly web publishing platforms. I didn't need to learn a specific program language to do what I do (while I do consider myself an html and css "hack"). In order to provide a user experience that continues to delight, you must be able to adapt pages to accommodate your content. And in a decoupled environment you can forget about using your CMS to affect most of your front-end changes. This is why you need the front-end developer.
- Content planning must come first. I once came in on a project whereby the digital strategy was complete, approved, and 75% developed ---- without a content strategy! Boy - oh boy - did we have a time back-fitting content into a rigid architecture that would have cost us tens of thousands of dollars to adjust to accommodate the real content. What did we lose? As the content strategist I lost the ability to design around the content and cut from a new bolt of fabric. Rather, I was given remnants and a fast approaching timeline with no budget to spare.
- Find the opportunity to think ahead and plan for next year. Draft the content strategy knowing you may have more flexibility than a standard CMS using a decoupled architecture. Pay attention to workflows and governance. How can you be more efficient? How can you leverage the flexibility of your page components?
- Don't forget about SEO. This is one of the biggest challenges I have experienced in a decoupled architecture. In a typical CMS environment, you would use modules native to the platform to optimize your site and pages. Do your research and understand that you will have to work harder for those search engines to find you in a decoupled environment.
- Work with your team - because a successful product takes a team. And everyone is constantly learning. System administrators, developers, designers, writers, strategists ... all of our skills overlap in ways. Ask the questions, brainstorm ideas, test your solutions. This is the work.
I'd love to hear from other content strategists and managers working with a decoupled architecture. What tips do you have for like-minded professionals that are embarking on their journey?