We wanted to build a highly user friendly and beautiful website that offered flexibility and was primed for scale. Traditional CMS was not good enough. So we found a process that would be worthy of our vision.
Can you conduct an experiment with me? Take a one-liter bottle, a half-liter pot and a small drinking glass. Now take a liter of water and try to fit this whole liter into the bottle first, then the pot, and finally the glass. Does the liter of water fit equally well in all three vessels? We know, without even conducting this experiment, that it doesn’t.
And yet, this is what developers try to do everyday when they force fit content made for a website to a tablet, a smart phone or even a smart watch. Overflow, bloating, and a terrible user experience are the results.
When we were preparing to build the SuperOps.ai website, I wanted to break out of this. I had struggled with traditional Content Management Systems (CMS) in the past and dealt with painful CMS transitions, and I knew that system was broken.
I wanted to find a solution that would ensure great user experience, support beautiful design, offer better security, improve and speed up the development cycle, deliver only the needed content to the appropriate device, and allow for scale.
Here’s how we ensured the SuperOps.ai website (which I believe is beautiful!) fits all these parameters.
Decoupling for flexibility & speed
The biggest challenge I faced with traditional CMS like WordPress and Drupal, is that the frontend and backend are coupled. The content, design, and development are consolidated and managed through a single tool.
In such a system the content cannot be broken down to fit different devices. Content for websites is forced into the smaller frame of a smartphone and even though we have mobile adaptive sites, the content is not easily consumable.
When we started to work on the SuperOps.ai website I wanted to find a solution, since I had struggled with this issue for years. That’s when I looked at Headless CMS.
In Headless CMS, the frontend and backend are decoupled. Further, content can be developed and stored in “modules”. This allows for the mixing and matching of content on the frontend. I may have 100 such “modules” of content for the website, but may choose only 50 for the smartphone. I can pick and choose the content and drive it to the frontend according to the frontend capacity.
This flexibility ensures we are able to offer a truly customized experience for users that is appropriate for the device from which they are accessing the site.
This also allows for a faster development process, due to the modular nature. We can make major design-led changes in just a week, which would otherwise have taken at least a month in the traditional system. We create multiple templates based on the design and keep them ready, so development and deployment become simple and fast.
Since the content in the backend is modular, changes made in one section do not impact other sections. So changes are easier and faster and I don’t have to worry about unintended consequences when making changes.
Not just that, when we do go in for a major redesign, only the frontend will need to be changed. It does save me from having sleepless nights worrying about the scenario when we do eventually undertake a redesign!
Need for security
Another choice we made was to mix the goodness of 1980s websites with the goodness of today’s technology.
In recent years, web application content has been generated from the backend. The data is heavy and this affects the network and speed. This wasn’t the case in the 1980s, when through File Transfer Protocols (FTP) HTML was generated and uploaded. This was static content and was fast. Now, with the evolution of programming languages, dynamism entered the space and all HTML content moved from server to server, making it slower. In the earlier era of static websites the content didn't stay in the server for long, so there was not much server manipulation.
While this was faster, it wasn’t dynamic. We decided to marry these two.
Like I said, we have different modules of content in the backend. We take this dynamic HTML, make it static and that is what is “served”. This happens in a continuous development model, unlike the traditional model where this process happens in the server.
This also has a positive impact on security. In CMS with plugins written in the PHP scripting language, security issues were a concern. For instance, malicious scripts had to just be added in the comments to compromise a site.
Since we are converting the website from dynamic to static, such malicious scripts do not reach the backend database, ensuring better security.
In fact, our Senior Frontend Engineer Panneerselvam Mani had collected rich data on performance and security of different types of CMS like Wordpress and Drupal for almost five years, and it is based on this in-depth research that we took the decision to opt for Headless CMS.
Free from restrictions
In traditional systems, the CMS strictly defines what designs it can support and what it cannot. There are frameworks and formats that the designers can choose from and create within those boundaries.
We didn’t want to be restricted like that.
Our Visual Design Lead, Karthikeyan Ganesh, has created a unique, fresh, and vibrant look and feel for the website that fits the fast, innovative and young ethos of the SuperOps.ai brand. It would have been very tough, almost impossible, to bring this design to life if we had used a traditional CMS.
Since the frontend is decoupled we can choose any website development tool. Not just that we can use the best frontend development tool for websites, for smartphones, for tablets and for any other device. We are not forced to use the same system for every format.
And, when we make changes in the backend it gets reflected in all the linked frontend systems—we do not need to make changes for each of them.
Not just that, we are also not dependent on the CMS to make advancements in tech to be made available to us.
Further, we are not treating the website as just a website. We are treating different parts of it as standalone applications. For instance, our blog, The Bugle, is an application, as is our podcast, SuperPod. What this means is we can easily and quickly create separate mobile apps directly for these applications. Scalability is built in.
There is always a but
While using Headless CMS has been quite freeing, it is true that it is more developer friendly than content creator or marketer friendly. Here you won’t find the drag and drop capability that many of the traditional CMS have.
Content marketers are dependent on the developer a bit more. All the content is housed in the backend in a manner very different from that of traditional CMS—it is divided page by page and block by block. There is a learning curve for the content marketer, who needs to navigate the backend that is more like a database of content. They need to understand how the content flows, and where each piece of content is stored.
For those starting out on this process and who are about to start using Headless CMS, I suggest you separate each page and keep them as separate repositories and applications. When content scales rapidly in the future, the system will be better placed to handle it.
The flip side is that once you get used to this, there is no going back. Traditional style of website development will feel burdensome and slow. I have had former team members call me and complain about how time consuming, inflexible, and boring it is to develop a website the traditional way in their new organizations!
This system is ideal for those companies who have a good development team, who want to have a design-led system and website, who want to build fast without compromising on quality, who want to offer a great user experience, and who want to build for scale right from day one. No wonder it fit SuperOps.ai perfectly!
Passionate about building products from scratch. Raised by good leaders. Technophile and a day-to-day learner.
