This has been an exciting year for Nimble Ape, as our team grew to include operational and marketing staff for the first time! This has meant rethinking how we do certain things to make sure each team member can perform at their best, and this includes how we make our websites.
For us as developers, making a website typically means starting out with our framework of choice, importing a UI template or library, and then writing all the content in HTML, JSX, or Markdown. Need to update the content? Make your changes in a branch, open a PR, and merge to deploy. Done 🙂
When Ellie joined as our marketing manager, I soon learnt that creating content is an iterative process, so having to go through a developer to make a new build to see the result of each iteration wouldn’t work. Most importantly, we wanted to empower all team members to be able to easily create and update content, rather than having to wait for a developer to implement it.
The Nimble Ape team in London!
Enter the visual headless content management system
We needed a CMS. Not just any CMS would do, though: It had to be headless, because we still wanted control over how the website is produced, so we could follow web development best practices and provide optimal performance. At Nimble Ape, we have a strong commitment to open source. Therefore, finding an open source project that we could self-host ranked high in our requirements list. Self-hosting would also allow us to keep control of all our content, which is very important to us.
There are many good open source CMS tools out there; however, a headless CMS alone won’t give the content manager control over how the content is structured within the page: The order of information is still hard-coded and a developer is needed to make changes to it. This would still be a blocker in the iterative content creation process.
The contenders:
Recently, several services have been popping up that promise to make both content managers and developers happy. Builder.io and Storyblok are two of the alternatives we considered. Both are very similar: They integrate with your framework and hosting service of choice, and provide you with a visual editor where you can enter your content directly into a live preview of your website to see how it will reflect in the final result. You can even import your own custom components and drag them and drop them around the layout. Essentially, a WYSIWYG editor for your website – Magic! 🤯
Unfortunately, during our research we didn’t find an alternative that would satisfy all our requirements of an open source CMS with a visual editor, with a clean interface and that would offer self-hosting, so we needed to compromise. We eventually decided on Builder.io, which is a hosted service, as it seemed to best suit our specific use case.
Building the website
We decided to try out this headless visual CMS when redesigning the landing page of our sister company Everycast Labs’ product, Broadcast Bridge.
We started from a Tailwind website template to give ourselves a design base. Although Builder.io integrates with the majority of Front-End frameworks, its creators also developed Qwik, a new open source framework that focuses on website performance and speed, which we decided to use. We adapted the template components to work in Qwik, registered them with Builder.io and removed all hard-coded content. Now, all components receive their content as props from the CMS.
Here’s an example of what it looks like for our TextBlock component:
The TextBlock component receives all content as props from the CMS.
From a code perspective, the site is now just a collection of empty components. We deployed it to Cloudflare Pages and pointed our Builder.io project to its URL. Instantly, the visual editor connected to the components we registered in our website and we could start dragging-and-dropping into the layout!
The site fetches the content from the CMS immediately after load, so the UI was soon updated with the new layout and content.
The marketer’s view: Editing text fields in our custom TextBlock component in the visual editor.
Challenges
When we initially started building the website, we decided to run the build as a GitHub Action and then deploy it to Cloudflare as a Direct Upload. We’ve done this in the past and found it a good way to have granular control of the build, including a staging environment and version releases. However, we didn’t find a way to make this process work with the visual editor in Builder.io: For it to talk properly with our custom components, we installed the Qwik Cloudflare Pages adapter and let Cloudflare handle the build. We’re still working on cracking the code on introducing a staging environment – we’ll let you know when we do, so stay tuned!
Planning the components to work with the CMS presented some challenges, in that we needed to think how they would be used by someone who couldn’t see the code. Here, talking to Ellie about what type of components she would need was key for us to build them with the necessary inputs and flexibility.
What’s next
More websites! We’re in the process of converting all our main websites to using a visual CMS and we’ve been quite happy with Builder.io. This very website is also on the list for getting a makeover! Making a blog website will be a nice new challenge, and we think it will be where we’ll get the most of the benefits of using a visual CMS.
Stay tuned to learn about all the new websites we’ll release in 2024!
- Marco and the Nimble Ape team