During my vacations I decided to start a side project. The idea was to spend part of this free time to improve my design and development skills as well as to create something that eventually, would came in handy for my daily work.
Motivated by my customers recurring needs, and aided by a book I was reading at that time, I decided to craft Mario, an headless CMS with a conversational UI.
Create a custom CMS from scratch could sounds an insane and challenging task, considering the rich offer of CMSs and the complexity that these systems can reach, but I think that despite the final result, with or without a working CMS it will be worth the effort.
Separating Content and Code
Before the intent to create a CMS from scratch, I used Kirby as default choice for many projects. Kirby is simple, modern and “flexible as hell”, it is a nice blend between a content management system and a web framework. It has an uncluttered admin panel, a simple content modeling through pages trees, custom types, internationalization out of box and many other nice features.
However, in some occasions I reached its limits mainly due the lack of a “real” database and in my opinion, try to patch the disadvantages of a product marketed as a file‑based CMS would have been crazier than reproduce its good parts with database support.
Separating Management and Delivery
Kirby provides a content management panel and all the necessary to publish contents on the same server with very few requirements. Thanks to its supposed ubiquity, it can be hosted on existing customers LAMP servers on request. However, also LAMP stacks can reserve incompatibilities just like browsers mainly due to legacy configurations and strict security polices.
A way to mitigate hosting inconsistencies is to decouple content management from its delivery, letting me to develop the backend in a programming language I’m happy to use and master and to deliver contents remotely with a truly ubiquitous static website, a single page application or by targeting other channels.
However, instead of manage multiple content repositories in a large remote application, my will is to create an open source CMS that can be installed as a single, standalone application, or to be embedded in existing projects as a plugin.
Talk to Me
Apart to separate the Kirby panel from content presentation, another challenge would be to complement its “traditional” UI with a conversational one. I’m not sure it will work, but the idea of transforming a CMS interface in a bot that can execute tasks such as “create a new page” or “show me the latest five post” is very exciting 😀.
Furthermore, beyond “just” delivering contents in one way, Mario will be able to accept messages from its remote targets or to be managed along with other instances by a centralized dashboard.
Despite the ambition to provide Kirby with a conversational UI and turn it in an headless CMS with database support, its implementation wouldn’t be oriented to solve engineering problems, instead it will be focused to propose design and business solutions through technologies.
Based on these premises my approach to front-end development will be quite essential, trying to translate in users opportunities the emerging web platform capabilities, instead of spend my time finding and learning yet another way to fetch data and manipulate DOM. Think about this intent, as a reaction to the front-end frameworks overload of the last 6–7 years.
On the back-end side I’ll follow a traditional way, giving back to it the responsibility to render a good part of the markup required by the web front-end as well as to provide alternative formats for other clients. In this case the implementation will be essential yet naive due to my inexperience on this side, however I’m quite sure that a good framework will support me in this challenge.
I planned to work on a small feature at time, with a short iteration cycle of research, ideation, prototyping and testing, organized in GitHub issues. During each cycle/milestone, I’ll try to figure out possible dependencies with other planned or incumbent requirements, trying to be focused and preserving an holistic approach at the same time.
In the next posts I’ll try to document design iteration cycles publishing the resulting code on a GitHub repository. If you are interested to follow Mario’s adventures, just follow me!