Mariano Viola

During my vacations, I decided to start a side project. The idea was to spend part of this free time improving my design and development skills as well as to create something that eventually, would come in handy for my daily work.

Motivated by my customer’s recurring needs, and aided by a book I was reading at that time, I decided to craft Mario, a headless CMS with a conversational UI.

Creating a custom CMS from scratch could sound like 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 the 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, simple content modeling through page trees, custom types, internationalization out of the box, and many other nice features.

However, on some occasions, I reached its limits mainly due to the lack of a “real” database, and in my opinion, trying to patch the disadvantages of a product marketed as a file‑based CMS would have been crazier than reproducing its good parts with database support.

Separating Content Management and Delivery

Kirby provides a content management panel and all the necessary to publish content 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, LAMP stacks can reserve incompatibilities just like browsers mainly due to legacy configurations and strict security policies.

A way to mitigate hosting inconsistencies is to decouple content management from its delivery, letting me develop the backend in a programming language I’m happy to use and master and to deliver content remotely with a truly ubiquitous static website, a single page application, or by targeting other channels.

However, instead of managing 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 from separating the Kirby panel from the 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 into a bot that can execute tasks such as “create a new page” or “show me the latest five posts” is very exciting 😀.

Furthermore, beyond “just” delivering content in one way, Mario will be able to accept messages from its remote targets or be managed along with other instances by a centralized dashboard.

Happy Prototyping

Despite the ambition to provide Kirby with a conversational UI and turn it into a headless CMS with database support, its implementation wouldn’t be oriented to solve engineering problems, instead, it will be focused on proposing 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 spending 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 backend 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.

What’s Next

I planned to work on a small feature at a 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 a 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 in following Mario’s adventures, just follow me!