CMSs should allow component-based page creation, but does WordPress Gutenberg get it right?
My former colleague Alice was bemoaning the lack of a way of dropping various components into a page using her current CMS. She’s right, I think; you’d expect any modern CMS to allow editors to build pages from smaller, self-contained elements, such as alerts, promo boxes, galleries and accordions.
Unless your pages follow a predictable pattern – on a blog, for example – you’re relying on the theme author to code a finite set of templates that will cover a set of requirments you need to predict when the site’s built.
This was one of the main requirements when we rebuilt the work website using Statamic last year. We ended up with a list of around 20 components we could drop into any page, ranging from simple alerts to more complex collection listings:
Some simple maths tells us we can create around 400 different page layouts based on shifting these components around. WordPress.com includes around 100 different “blocks” out of the box, giving editors even more possibilities.
Different approaches to implementing component/block UIs
Statamic and WordPress offer different ways for editors to create components. Statamic takes a more form-based approach, where the editor enters data into clearly styled fields.
The editor doesn’t have any visual relationship to what’s rendered on the actual website:
WordPress’s Gutenberg, on the other hand, attempts to make the editor look more like what will appear on the website. For example, this is the “cover” block (an image with some text over it):
This would appear to be a good idea – tying the editing process to its output saves editors from flipping between the rendered page and the CMS. But having set up several users on WordPress, and trained a couple of editors in Statamic, I think it poses a few problems.
Firstly, filling in and amending traditional forms is a familiar, predictable process. You enter some text, select an element from a dropdown or complete a file upload dialogue. If you want to the edit the text, you head back to the relevant field and just fill it in again.
In WordPress, this process varies according to the block you’re editing, and can take some figuring out. For the cover editor it’s fairly clear, but involves an element of discovery – you click on the image, which reveals a toolbar with a ‘Replace’ option:
The picture slider block works differently. When you click on the block, a different type of toolbar appears, with no ‘Replace’ option:
In my experience, less technically skilled editors find this frustrating, even when they have experience of using different CMSs, including pre-Gutenberg WordPress. In every case, I’ve ended up installing the the Classic Editor.
Secondly, editors can find it difficult to navigate around a page and add new content without a framework of clearly demarcated boxes and forms. Take this example of the verse block followed by a cover. Coming out of the verse block and starting a new paragraph involves a frustrating number of clicks:
I’m a really big fan of WordPress. It offers a free, fast way to get online and publishing to the indieweb. Half of the features I implement on this site, such as comments, come out of the box. It has a huge range of plugins, and is mature, stable software that handles updates and upgrades fantastically well.
But I think Gutenberg causes problems for editors who won’t be willing to learn how it works. There are some poor UI decisions to overcome. Perhaps more worringly, I think it may be misconceived – keeping content separate from its appearance allows users to focus on creating and editing; let the designer worry about how it ends up looking.
Of course, I could be wrong. My experience is limited to four or five people. Maybe tens of millions are happy with Gutenberg. But it’d be interesting to see how often the Classic Editor is installed.