Hello World!

Welcome to Mattrbld and this blog! Thank you for stopping by and showing some interest in this project of mine. 😊 This is the first of many posts I plan on writing to document the development and showcase some of the project’s features.

This first instalment is somewhat special in the sense that I will try my best to explain what this project is about, who I am and why I created it in the first place, as well as how I am approaching it as a whole. While I hope that these articles will be valuable to as many people as possible, please be aware that they will be technical to a certain degree.

What is Mattrbld?

If you’ve skimmed the landing page, you’ll already know that Mattrbld is a new Git-based, headless content management system that I am building as the final project for my BA in communication design at UAS Munich. But what does that mean, exactly?

A Headless CMS

A content management system (often abbreviated CMS for short) is a way for people to edit the contents of a website—or app, magazine, etc.—without having to touch the underlying code that makes up the medium. CMS come in all shapes and sizes, you surely know of the biggest ones such as WordPress and Typo3, and have heard of site-builders such as Squarespace and Wix, which can also fulfil the functionality of a CMS.

Since there are so many CMS and each one of them works slightly differently, it would be impossible to clearly define what is a CMS and what isn’t, but at the end of the day all of them have one purpose in common: to make it possible for people to update websites without having to be a developer.

To accomplish that purpose, many traditional CMS offer a complete package in their own ecosystem. When you pick WordPress as your CMS for example, you’ll often stick to that ecosystem of themes and plugins for all your needs (although it is technically possible to use WordPress solely for content management). That means that you will use (or have a developer write) a website (often referred to as a “theme”) that works with WordPress and you will use SEO, analytics, e-commerce and many other plugins that were made for and work with WordPress.

This can be a great benefit, as everything lives under the same roof, so to speak, but it also comes with a significant maintenance overhead, since all these plugins need to be constantly updated for everything to remain secure, as does the version of WordPress that you will have to run on a server somewhere so your website can be delivered to your customers. Upgrading a plugin or WordPress could have unforeseeable ripple effects that can cause a whole slew of other parts of your website to break, which leads to more updates again.

On top of all that, your content will also be stuck to the way WordPress works, making it very time-consuming to export and re-use it, should you ever want to leave the ecosystem. Other CMS might not even offer a straightforward way to extract your content—especially once you no longer want to pay their subscription fees.

A headless CMS decouples your content from the rest of your website / application / medium. It does not care what technologies your website uses, all it does is manage content and offer you a way to deliver that content to whatever user-facing product or medium you choose.

This is why large media companies with hundreds of sites, apps and even smart home-assistant applications have been using headless CMS for a long time to have one central location for all their content, which will then be distributed to their various platforms.

Based on Git

Many existing headless CMS offer you an API for accessing your content. In simple terms that means that to get the content for a blog post such as this one, the app or website would send a request to a server asking for a blog post with a certain ID and any meta-data associated with it. The server would then process this request, fetch the data from one or more databases and send it back so the website can process and display it to the user.

This procedure once again ties the content to a particular entity or software framework. It will be stored on a server that you either don’t own (forcing you to trust the company) or have to host and maintain yourself, which can be very time-consuming and costly.

An alternative to these API-based headless CMS is storing the content alongside the code that makes up your website in a version control system such as Git, making the CMS Git-based.

Not only does this keep content and code conceptually close (while still being decoupled), it also offers the excellent tools and power that come with a mature system such as Git. While not necessarily very intuitive, a version control system allows for many ways of working collaboratively and even having the peace of mind of always being able to undo even significant changes.

Another benefit is that content will be stored as files, not in a database, making it easy to be backed-up and transferred between services and storage-locations. Git being an open source project means that there are many possibilities, both commercial and self-hosted, to store your content without being tied to a specific vendor or platform.

Static vs. Dynamic Websites

While not having to run a dedicated server with an API to query content from is an advantage in many cases, it also comes at the cost of such a system being less dynamic, since not every request can be replied to with an individual response.

Dynamic websites, such as those resulting from a typical WordPress setup, typically get generated on-the-fly by querying a database as soon as a user sends a request for them through their browser. This allows them to be tailored exactly to that user, based on data they send with their request. However, this also means that many users requesting a site at the same time can slow down (and in extreme cases even crash) a server, since the requested page has to be assembled for each one of them individually (which theoretically can be mitigated by caching a result—but why solve a problem that could be avoided altogether?). A dynamic website requires a “smarter” server / backend that knows how to use a database to assemble sites for a user, which in turn is more expensive and requires more maintenance.

Static websites, on the other hand, get generated only when their content changes, so every user sees the same site, at least before client-side JavaScript kicks in and changes things up. This has the advantage that a static website will be (nearly) equally fast whether one person, or a hundred thousand people request it, since all the server does is send the same pre-generated data to each user. (Although millions of concurrent requests can of course still crash even a static file server.) As a result, the server can be “dumber”, since it only needs to know how to serve static files to a user—something which has been done since the infancy of the internet. Serving a static website is cheaper, requires almost no active maintenance and is more secure, since there are much fewer attack-vectors.

A CMS for the Jamstack

To mitigate the drawbacks that come with a static website, client-side JavaScript and external APIs can be used to achieve the same degree of flexibility and functionality a dynamic website offers. This way of combining JavaScript, APIs and static markup (i.e. HTML) is nowadays commonly referred to as the Jamstack.

One aspect where static websites used to fall behind dynamic ones was content management, since it almost always involved writing the content directly into the markup. This was prone to errors and also required that the editor had some technical knowledge. The rise of static site generators such as Jekyll, Hugo and many others alleviated some of these problems by allowing static markup to be generated from templates and content data, but this content still had to be written in a code- or Markdown-editor. While this worked well for blogs and other sites with predominantly long-form written content, it still wasn’t ideal for most other, more traditional websites.

Only recently, through the efforts of NetlifyCMS, Forestry CMS and others has it become more viable to create static sites which stored their content alongside the code in Git while at the same time providing the user with almost the same degree of content editing features as a more traditional CMS.

Mattrbld aims to improve on that experience, while also trying to cut out some of the fragmentation and stress the decentralised nature of the Jamstack lends itself to. There will always be a place for dynamic websites with traditional content management systems, but oftentimes they are simply overkill for a lot of individuals and small to medium sized businesses that just want an easy and intuitive way of editing the content on their website.

Who am I?

Before I go further into my motivation to pursue this project, allow me to say a couple words about myself. I’m Amadeus, a designer and developer based in Munich, Germany.

I’ve been building websites (coincidentally mostly static ones) since I was 16. Due to my interest in the English language and computers and programming in general, I first got a BA degree in English linguistics and literature with a minor in computer science in 2017 and then went on to study communication design to give a formal background to my passion of creating well working and delightful user experiences.

At my current job as a working-student at Flavour Communication, I frequently design and build websites for clients, while developing multiple progressive web apps and other apps using web technologies in my free time—if you’re interested, feel free to check out my portfolio. I have also taught two courses on webdesign as a teacher at my current faculty—as you can tell, everything to do with the web plays a significant part in my life.

Why build another CMS?

During all this time, I was never quite satisfied with any of the existing solutions for managing content on static websites, so for my BA thesis project, I decided to finally build my own. I am very grateful to my supervisor, Prof. Matthias Edler-Golla, for allowing me to do so and supporting me in every way possible.

Now, there are hundreds, if not thousands of content management systems out there, and obviously I have not tried them all. I am sure they all have their purpose, strengths and weaknesses. Since Git-based headless CMS are more of a recent addition, though, there are fewer of those, despite being a much better fit for a certain target demographic in my opinion, as I outlined above.

Issues With Existing Solutions

From what I could gather based on my (at this point in time fairly limited) research, all of the Git-based, headless CMS suffer from one or more of the following issues:

• Requiring a specific static-site-generator (e.g. Jekyll, Hexo) or frontend framework (e.g. React)

• Being restricted to a single Git-provider (e.g. GitHub)

• Being focused on primarily long-form writing for personal blogs and such

• Requiring a separate account / giving a third party full API access to your Git-provider

• Pushing changes on every save, causing the page to be re-generated many more times than necessary while editing content if a CD / CI system is connected to the repository (which is usually the case with a Jamstack site)

• Not allowing for collaboration / multiple users working on the same site

• No or clunky support for internationalisation

• No way of easily creating internal links

• No way of precisely controlling the shape of data to eliminate potential sources of errors

• No reliable preview of the content being edited

• Providing a user interface that is too unique for content editors that are used to more traditiona CMS, or a UI that looks and feels outdated and inflexible

Admittedly, that last one is a question of taste, but I do firmly believe that a delightful UI can boost productivity significantly and that a complex task doesn’t have to feel complicated or hard if the UI is designed the right way.

Lofty Goals

With Mattrbld, I want to create a CMS that looks and feels like it belongs with a technology so forward and modern (I am aware of the irony of this statement, since static websites technically preceded dynamic ones) as the Jamstack, while also alleviating the pain-points outlined above.

I am aware that this goal is a lofty one, but I am also confident that I can reach it. I have experience with tackling projects of this scale—I’ve built a full-blown social network for a writers’ club I am a part of—and I need to see if it can be done with the technologies that are currently available. I will also admit that the idea of having a CMS that I have full control over is a big motivator.

Why Create a Website for a Project in its Infancy?

I don’t think it’s uncommon to create a website in the early stages of a project, be it only to show something on a recently purchased domain. With this website in particular, I have some more reasons for going “public” so early on in the project’s development.

Developing in the Open

I am a strong proponent of open source code and technology and a firm believer that the only software you can truly trust is software you can read the source code of. On the other hand, I am also a bit intimidated by making a project such as this one open source from the get go. I simply haven’t had enough time yet to think about how I want to license or even what to do with it once it’s done.

I do think making Mattrbld open source has the potential to really drive adoption and acceptance and would be in line with the message of independence and freedom I think this project carries—but at this time I haven’t made a final decision yet and thus the code will stay private for the time being. Despite that, I still want to be as open and transparent about the development process, my progress, as well as my successes and failures as possible.

To that end I plan on publishing regular devlogs and progress updates in a bi-weekly rhythm. This way, you can follow along with me on every step of the way if you’re interested, or check in every now and again to keep tabs on the current state of the project.

Dogfooding My Own Recipe

Another reason I created this website is that I need a testing ground for dogfooding Mattrbld—at the end of the day what good would it do me to create a product I didn’t believe in enough to use it myself? I’m planning to manage and update this website with Mattrbld as much as possible—in fact, I’m actually already writing this very post in Mattrbld’s rich-text-editor, despite the fact that I’ll have to manually copy and paste the generated mark-up into my code editor since publishing content doesn’t actually work quite yet.

Doing so gives me the chance to test the project in a real environment, validating my ideas and seeing if features that sound great in theory actually create added value for the user. Keeping in line with my point about open development above, I also think documenting Mattrbld with Mattrbld gives you a better idea of what is possible at any given stage of the development.

It Needed to be Done Anyway

Part of the final result I agreed on with my Professor was a marketing page for the project to give it a sense of professionalism, despite the fact that it might not be fully done by the time I will have to hand it in in July 2021.

Designing and coding this website definitely was one of the easier things to do for me in this project, so I wanted to get it out of the way early so I could focus more on the more complex aspects. I am at a stage now, where I have a pretty clear idea of where I want to get to and what the final product should be like, so putting all that into words and images felt like the right thing to do—so why not do it out in the open?

The Current State

I am building the user-facing part of Mattrbld with Vue 3 using a library of components I created at the end of last and the beginning of this year. These components cover most of the basics (i.e. buttons, input fields, modals, tooltips, toggles, etc.) and are ready to be combined into more complex molecules to build Mattrbld’s UI. I’m sure I will still add some more polish here and there as I actively use them, but I consider the component library pretty much in a mature state.

On the more technical side of things, I have already completed the initial onboarding flow for the application, which means it is possible to import a Git repository and set up a local user for working with it.

Basics like in-app notifications, saving and restoring user preferences, etc. are already implemented and working well. All in all, I think I have a solid base to keep working on.

What’s Next?

I’ll have a meeting with my Professor this Wednesday, where we will discuss the current state of the project, so my plans might change after that, but for now I’m planning on adding some more fundamental features such as the ability to delete local users and imported projects, as well as starting with the initial setup of a freshly imported project. This will surely take me the better part of the next two weeks, since as much as I would like to, I cannot devote more than two weekdays and the weekend to this project due to my jobs and other classes.

Until then, let me thank you for reading this far if you managed to do so, I hope that future devlogs will be shorter. Nonetheless, I really appreciate your interest in my project and hope that you’ll accompany me on this journey!

If you’d like to know when I’ll post a new devlog or other updates regarding the project, why not follow Mattrbld on Mastodon. While you’re already there, if you have any questions, feel free to reach out, I’d love to hear from you.