Dashing Dashboard

After taking a bit of time off and letting things go slowly, I ramped up my productivity in the past two weeks and implemented two features crucial to staying in the loop: the live content preview and the project dashboard.

In the last devlog, I explained how I took some time in my “weeks off” to improve general usability and was able to implement all the remaining field types, except for the columns field. So naturally, I started off the new fortnight right there.

The Columns Field

Like its sibling the rows field, the columns field is one of the most flexible fields you can use to model your content Schemas with in Mattrbld. While the rows field is probably used on most occasions that require repeating fields of the same (or different) types that can be freely added and arranged by content editors, the columns field might make sense in certain situations where content editors would expect items to be laid out horizontally instead of vertically.

Use cases include a gallery of images displayed in a grid, or the typical pricing buckets found on most product pages. For content focusing more on typography, they could also be used to display text side-by-side in more than one column, for example.

Technologically speaking, columns fields and rows fields both work with arrays of objects when they allow content of different types, or plain arrays of a single type otherwise. Hence, their difference is mostly a visual one, except for the fact that due to the nature of their display, columns fields are always compact.

Since the two field types are so similar from a technological standpoint, I tried to re-use as much code between them as possible, which meant that I had to refactor the existing rows field to extract common functions and properties. In the end that also helped iron out some previously undiscovered bugs in that code, which is always a win.

Live Content Preview

A crucial feature of headless content management systems is the ability to preview the content being worked on. Since the presentation is decoupled from the content itself (hence why the CMS is “headless”), creating an accurate preview is a challenge.

With Mattrbld, users aren’t limited to managing content for web pages (although that’s expected to be one of the primary use-cases). Their content could be anything, from a website, to a mobile app, to a digital billboard at the side of the road. That’s why simply rendering out the edited data into an HTML-page isn’t enough—especially considering that every website is different.

So instead, Mattrbld leaves the details of how the preview is supposed to look in the hands of the developers working on that project and simply provides the current data being worked on at the moment. This approach has the advantage of leaving the developers in control, but also involves a bit more work than a generic solution.

How It Works

The technical details of how this works are better suited in the documentation article for this feature—but in a nutshell, the user has to provide a website implementing Mattrbld’s Preview Protocol in order to enable live previews for a project. After that’s done, a content editor can show a preview-pane either side-by-side with the content being edited inside Mattrbld, or in a new tab / window.

This preview-pane contains an Iframe pointing to the URL set up before and once its contents are loaded, Mattrbld will establish a connection with it via postMessage, and send the current content data through that channel in regular intervals. The loaded website is then in charge of transforming and displaying that raw content as it sees fit.

It’s important to keep in mind that Mattrbld does not transform the content it sends, meaning the preview will receive the data as-is, which might be different from the data the static site generator would provide. For example, Markdown won’t be converted to HTML and content referenced by file path, ID or another field won’t be available, just like the rest of the website (i.e. dynamic menus, related content, etc.). It’s just the content being worked on. Despite that limitation, it should still be possible to create an accurate and fast representation of what’s being worked on with a little effort, since the user is not editing the whole website at once, but rather just a specific part of it.

A Word on Images

The most challenging part of implementing this preview protocol were, as expected, images. At the moment, Mattrbld will send all currently loaded images to the preview, which will then be in charge of decoding the raw data into a form the browser is able to display. As with the rest of the content, this means the images will be untransformed—something which should be kept in mind.

Benefits of the Approach

Even though this approach has its drawbacks, it is in line with the rest of Mattrbld: it does not involve any third parties or servers and leaves the developer in control. It also works offline (once the preview URL was loaded once) and with local servers, so you can enjoy the full power of HMR while developing the preview route. It’s also extremely reliable and powerful.

For example, Mattrbld could be set up to include a Collection of employees and the preview could use the data of the employee being edited to generate their name tag, business card and more, all without having to leave the application. Freelancers could choose to manage their invoices with Mattbrld and use the preview to generate a PDF from them…the possibilities are limitless.

And as a little bonus on top, the preview also gives content editors an easy way to enable a mobile version of the content they’re editing—without having to awkwardly scale windows.

The Dashboard

With content editors now being able to see what they themselves are working on, wouldn’t it be useful if they could also see what their team members are working on? That’s where the new dashboard comes into play.

It’s the first thing a user sees when opening a project and as such is supposed to give an overview of what’s going on. The dashboard is split into four different sections, each with their own distinct purpose.

Cards Area

The first card in this section always shows if there are local changes, or whether everything has been synchronised. It’s a quick way to gauge if there are any local changes that need to be pushed to the central Git repository—and the most straightforward way to do so.

On top of that, there’s also the option to show quick links to specific Collections or content items from the side-bar here. This can be used to make frequently accessed content elements like the home page or the blog even easier to find and edit.

At the moment, adding cards to this section is done via the Sidebar Settings—since those are the entries that can be linked as cards. However, this might change in the future if users end up expecting that setting in the newly added Dashboard Settings.

News & Announcements

Right below the cards is a list of recent news and announcements that project members with access to the settings can create in the aforementioned Dashboard Settings. These articles can be used to efficiently communicate with the rest of the team, providing instructions, guidelines and more. This section is also where the Mattrbld changelog can be accessed so it’s always obvious which version is currently running and what the newest features are.

Posts in this section consist of an optional title, a summary and an optional body that (if provided) can be read in a separate modal in order to keep the list short and easily scanable.

Recent Updates

Since Mattrbld is Git-based, there’s no better way to see what’s been going on with the project than the Git-log. Every time someone changes something, be it a developer adding a new feature, Collection, Schema, or a content editor publishing a new piece of content, image, or file, it will be registered in the log. That’s also why Mattrbld asks for a description of the changes you made when synchronising them; this description is what your collaborators will see next to your name in the log.

Showing the entire log would be counterproductive—so it’s truncated to the five to ten newest changes from everybody on your team—including yourself, so you’ll always know what you synced last. 😉

Local Changes

The final section of the dashboard is an overview of all the files you have changed locally and which have not yet been synced. This information is mostly redundant, since you could see the same if you went to sync the changes—so in the future, this section might be reworked or removed. For now, it’s an easy way to see what you did since you last synchronised the changes.

Miscellaneous Updates

In other news, the lists for users and custom roles in the User Settings now have context menus for each entry, making them behave more like other item lists throughout the application.

I’ve also taken a bit of time to rework the helper for creating internal links (first discussed here). Before, every field and rich-text editor allowing the linking of internal content (i.e. content items within a Collection) had to be manually passed a template from which to create that link. Now, this is set up once (per language if the content is localised) in the Collection settings, making it much easier—although this behaviour can still be overwritten by the developer if need be.

And last, but certainly not least, it’s now possible to toggle the “draft” status of a content item while editing it as long as drafts are enabled in the settings.

More to Come!

And with that, we’re at the end of this devlog. In the next two weeks, I’m planning on adding the missing Custom Fields functionality, which would conclude all the features relating to content editing. After that, I want to finally implement the ability to join a project via the invite links which are already generated when adding new users to projects.

Especially the custom fields are going to be a bit of a challenge and I must admit that after working on this for so long, I have lost a bit of steam (or maybe it’s because summer is here and I feel like I’m being cooked alive at my desk 😅), but I’m positive that I’ll get there!

If you’re curious to see how things turn out, please check in for the next devlog in two weeks. Until then, thank you very much for reading and don’t forget that you can always reach out to me on Twitter for any questions or comments! 😊