It’s Time to Adopt a Block-Oriented View of Website Content Management

Even the most basic webpages — ones that contain simple content elements like headlines, text, and lists — can be viewed, abstractly, as nothing more than a collection of blocks, with each block representing a particular content element. Code-wise, these blocks are represented by HTML tag pairs (<h1>, <h2>, <p>, and other similar elements) or single HTML tags (<img> and <hr> elements).

However, many webpages are more complicated than just text, and contain more detailed or interactive elements like photo galleries and videos. But even these more complicated webpages can still be broken down into a block-based structure. Consider the following photo gallery HTML:

<div class="gallery">

    <div class="gallery__item">

        <div class="gallery__photo">
            <img width="300" height="300" alt="Photo 1" src="1.jpg">
        </div>

        <div class="gallery__caption">
            Photo 1 caption goes here.
        </div>

    </div>

    <div class="gallery__item">

        <div class="gallery__photo">
            <img width="300" height="300" alt="Photo 2" src="2.jpg">
        </div>

        <div class="gallery__caption">
            Photo 2 caption goes here.
        </div>

    </div>

    <div class="gallery__item">

        <div class="gallery__photo">
            <img width="300" height="300" alt="Photo 3" src="3.jpg">
        </div>

        <div class="gallery__caption">
            Photo 3 caption goes here.
        </div>

    </div>

</div>

The gallery as a whole is contained within a block, in this case a “gallery” <div>. Each individual gallery item is represented by a block, a “gallery__item” <div>. Finally, each gallery item contains two blocks: a “gallery__photo” <div> and a “gallery__caption” <div>. So basically, we’re looking at blocks within blocks within blocks.

Unfortunately, content management systems often require users to enter all of their content as one big blob of code into a single field, often a WYSIWYG editor. (This is WordPress’s default behavior.) This will result in discrete blocks on the front-end (like the above photo gallery example). On the back-end, however, all of the blocks’ code is jumbled together.

This isn’t really a big deal… if you’re dealing primarily with text. But if you’re building something more complex and ambitious, then the “blob” approach is far from ideal. To continue with the gallery example, what do you do if you want to make some changes (e.g., add some photos, update some captions)?

Generally speaking, you have one option: sift through the blob of code to find the gallery-specific code, and then manually update the necessary HTML — and hope you don’t affect anything else.

In either case, though, you’re getting your hands “dirty” by having to work through all of that particular webpage’s code in order to make updates to just a portion of it. You might be OK with that if you’re a programmer (though you’ll probably still find it tedious and annoying). But if the site is maintained by non-programmers, then you’re asking them to take on a lot. HTML may be a pretty simple language, but it’s a chore to go through even if you happen to make your living working with it every day.

But there is a better way…

Block by Block by Block

It makes far more sense to think of a webpage as a collection of discrete, self-contained blocks of content, and edit it accordingly. The blocks come together as a unified webpage when rendered on the front-end, but in the back-end they can be individually added, edited, deleted, and reorganized without affecting or damaging any of their siblings or the overall integrity of the webpage’s content.

This, by the way, is one of the main reasons why I rebuilt Opus on Craft. Craft lets you organize and structure your content with the usual custom fieldtypes (e.g., rich text, date/time selectors, radio buttons). One of its killer features, though, is the “Matrix” fieldtype which lets you create content blocks that can each contain their own set of custom fields.

When I want to add an image to one of my posts, I don’t drop it into a WYSIWYG field along with everything else. Instead, I add an “Image” block, which looks like this in the admin area:

This block contains several custom fields that let me select the image to be used, set its alignment, specify its caption and alternate text, and even make it a link. Furthermore, since it’s a self-contained block, I can move it around amongst the post’s other blocks without affecting them or breaking anything. Meanwhile, I have complete control over the front-end HTML used to render the image block, which I like as a designer — there’s no need to work around any CMS defaults.

I’m a huge fan of this approach because it makes it much easier to create ambitious and complicated layouts that are still easy to design and manage. I think Craft’s approach to content blocks is particularly elegant, but I’ve been intrigued by how other CMSs have recently begun to adopt a similar approach, as well.

Blocks Are Becoming All the Rage

Medium has received quite a bit of acclaim for its editor, and for good reason. It’s very simple to use, and gives users enough options to create good-looking posts. When you add an image, for example, you can control its alignment and layout — you can float it to the side or make it span the window as a hero image — and you can even add a caption.

But however good Medium’s editor is — it’s inspired at least one clone — it’s fairly limited. For example, you can drag and reorder images in your article, but not videos. And of course, you can only work with the blocks it provides.

I mentioned WordPress’s “blob” approach earlier in this post, but WordPress is working on “Gutenberg,” a project to create a new text editor that’ll replace its existing TinyMCE editor. It’s currently available as a plugin but will be rolled into the WordPress core (probably as part of WordPress 5). According to WordPress developer Joen Asmussen, Gutenberg is an attempt to make advanced content management more straightforward as opposed to the current approach, which often requires “shortcodes, custom HTML, or ‘mystery meat’ embed discovery.” (If you’ve ever worked with custom WordPress themes then you know this to be true.)

Several videos of Gutenberg in action are on YouTube, and as you can see, it looks similar to Medium’s editor but with more available blocks and features.

(The popular “Advanced Custom Fields” plugin adds similar functionality to WordPress, as well. But it’s nice to see WordPress working on adding such functionality to the core.)

Last month, Ghost announced that v1.0 was finally shipping. Among its many new features and refinements, v1.0 includes a new editor titled “Koenig.” Up until now, Ghost’s editor has used Markdown (“a text-to-HTML conversion tool for web writers”) for styling and formatting. Markdown has a lot of fans and is great for power users, but it’s not exactly the most intuitive (though Ghost’s Markdown editor is one of the best I’ve seen).

With Koenig, Ghost hopes to address some of that. Similar to Gutenberg, Koenig resembles a souped-up version of Medium’s editor and allows you to build a post using a combination of content blocks, including rich text, image galleries, maps, and Markdown (with plans to allow developers to add custom blocks).

Approaching content management from a block-based view may seem like an over-complication, especially if your site is primarily text-based. But speaking for myself, I really don’t want to build webpages any other way.

The use of content blocks allows me to give more structure to my content; breaks the content management workflow into smaller, more manageable pieces; makes it easier to manage content without worrying about breaking things; and gives me complete control over how the content appears on the front-end.

I’m encouraged to see some of the biggest and most popular CMSs out there making efforts to bring block-based content management to the masses. There’s certainly a learning curve and conceptual shift to approaching pages, articles, and posts as blocks rather than blobs. But — and this naturally assumes that web developers like myself implement this functionality wisely — that’s a very small trade-off for having the power and flexibility that content blocks ultimately offer website editors.

Many thanks to Jaymee Jarvis and Tyler Fowle for peer reviewing this post.