Faster in Parallel

Time really flies—I can’t believe it’s been two weeks already since my last devlog. I’m glad I decided against weekly updates since writing these up and creating graphics for them takes its fair share of time. A lot has changed in the past two weeks, so let’s dive right in.

Where We Left Off

In the last devlog, I introduced you to Mattrbld, told you who I am and why I’m tackling this project and as promised, I’ll try to keep future updates such as this one a bit shorter. Two weeks ago, I had a functional set of base components, the ability to import projects and create local users; in short: a solid foundation and a bare-bones onboarding process.

My main plans were to add the ability to delete local users and projects, as well as starting to tackle the initial project set-up process, which I’m pleased to say I have managed to accomplish.

Here’s What’s New

Bulk-Deletion and Web Workers

Deleting a local project, which may have thousands of little files (Mattrbld being Git- and as such file-based), or even a user and all their local projects—which would multiply that number—was no small feat. In order to allow that, I had to implement a recursive file-deletion function that could remove a folder and any sub-folders and files it contains.

Unfortunately, the file system library I’m using for Mattrbld does not have such a function built-in. Building on my prior experience with JavaScript file management and reading the source code of some other file system libraries, I think I have found a good solution to implement myself, at least for the time being.

The problem is that while not necessarily slow, deleting so many files at once can cause the UI to lag briefly, but noticeably—something that I have already experienced during the project-import when all the remote files are being written to the disk. This is due to JavaScript’s single-threaded nature: by default, the UI, all functions and everything else is running on one thread, meaning there’s no way to truly do anything in parallel (although it might seem so at times).

The solution is to use Web Workers, a feature that has existed in Browsers for a long time, but hasn’t really gotten as much coverage as other things. I have never worked with Web Workers before, but after some brief set-up pains (and the fact that the Linter in my code editor still throws cryptic errors), I now have the ability to run file-system and Git-operations on a separate thread, meaning the UI stays buttery smooth even while creating or deleting thousands of files.

Using Workers meant that I also had to re-write much of my existing onboarding and project import process and I took the opportunity to clean up that code a little bit along the way. It took the better part of the first week, but now I feel like I have a much more robust (and smooth) onboarding and import experience, which is a plus, alongside the ability to delete local projects and users, which is obviously a very necessary feature.

Better Local Multi-User Handling

Speaking of users, I also took the time to improve the handling of multiple users using Mattrbld on the same device. This should be particularly useful for those of us who might manage content both for our employers and privately on the side. Creating a local user for both scenarios allows the dashboard to stay clean and fast and our minds focused on the task at hand—we really don’t need to be seeing those work-projects when updating our personal blogs, do we?

With this new change, local users that have access to the same projects can be switched between freely even from within a project, while those who do not can only be switched to from the project dashboard.

Better Tab-Management

Since the beginning, Mattrbld allowed users to open projects in new tabs, since that’s what we’ve come to expect in a browser-based tool. However, that implementation was rather basic. I have improved the handling of this by making sure that re-opening an already open project in a new tab will switch to that tab instead, so that feature won’t clutter up the browser too much. We already tend to have far too many tabs open at once anyway, right?

In the same vein, when navigating back to the project dashboard from a project that was opened in a new tab, the tab is simply closed if there’s already an open tab showing the dashboard.

The Sidebar Extravaganza

When opening an imported project in Mattrbld, a sidebar appears that will be familiar to anyone who has already worked with a CMS. It’s the main navigation within a project, allowing access to content, media, and settings.

Since Mattrbld is so flexible and highly configurable, only a select few of the navigation links on this sidebar are fixed—the rest need to be configured on a per-project basis. At the beginning of last week, I laid the groundwork for this, adding a very flexible sidebar component that can handle this degree of customisation.

What I probably spent too much time on were the gestures and transitions for tablet and mobile devices, when the sidebar goes from being a static part of the interface to a floating card that can be pulled in from the left side of the screen. I know that this form of UX has been on the decline since the advent of a more gesture-based navigation on our smartphones, but I believe I found a way to handle this without interfering with the gestures for going back too much.

General Project Settings

With the sidebar in place, I devoted the rest of my time to getting started with the project configuration as a whole. Again, due to Mattrbld’s high flexibilty, a single page of settings would have been far too long and cluttered to be effective, which is why I grouped related settings into multiple tabs. The first of which houses the general project settings, such as the avatar image and the project’s name.

I’ve already started working on the next of these tabs, the “Users”-tab, which will allow inviting new editors and managing the roles of existing project members.

Lots of Little Things

On top of all of the above, I’ve also refactored the code for cropping and resizing uploaded avatar images—which took me far too long, I must admit—and a myriad of smaller things that cropped up here and there to make the experience even faster and smoother.

Up Next

My plan for the next two weeks is to flesh out the “Users”-tab and then tackle one of the core features of Mattrbld: content collections, schemas, and fields. I will have to define a flexible, but simple data structure capable of being mapped to nearly any form of structured content imaginable and then proceed to build a user interface to work with it.

It’s a big task which I’m reasonably sure I will not be able to finish until the next devlog—especially with Easter coming up, but once that functionality is in, a big milestone will have been reached.

Until then, as always, feel free to reach out on Mastodon if you have any questions or comments. Thank you very much for your interest in my project and I’ll do my best to report back with any current developments in two weeks time!