The Taming of the Block - Part I: Publishing on the web
This is the first of two posts accompanying the talk I gave at WordCamp Vienna 2020 about why we may want to re-calibrate the balance between features, complexity, freedom and ease of use by configuring, changing, reducing or removing features from the Gutenberg block editor.
Writing a talk: There is always more…
No matter how much I try to prevent this history from repeating preparing a talk for me inevitably turns into this 3-step process:
- I’ve got the topic, but I’ve got no clue what to actually say. How will I ever fill those 30 minutes? 😱
- I’ll just start to brainstorm and collect ideas…Oh, wow, I could ramble for hours about this. 🤔
- What a shame, I have to skip most of this to fit it into the limited time I have. 😞
So I’d like to counteract the wastefulness of this by turning all the additional thoughts I have into a blog post. Even more so since judging from the attendance at my talk I guess people are actually interested in this topic. This gives me the opportunity to go more into detail and add links and other references where relevant.
Be warned though: This will be a pretty long one.
So before we dive into the practicalities of actually taming the block editor (this will be what the second post in this series will be about) I’d like to first make a “short” detour into the (admittedly still hugely simplified) history of publishing on the internet.
I’d also like to emphasize that this is obviously my very personal and subjective view on things. The whole matter is quite complex so there is plenty of space for differing perceptions.
Publishing on the web
In the beginning, back in the ancient times of the web, the only way to author a website was by using a text editor, manually writing HTML. Even though with way less HTML features this was easier back then it still was something that was laborious, technical and basically unusable for everyday usage by everyday people.
There were multiple issues with this approach:
- need to understand HTML
- no immediate visual feedback for changes
- changes always affected design and layout as well as content
- global changes were a repetitive, manual process
- hard to maintain consistency on bigger sites
- manual file upload after each change
So soon there were multiple solutions popping up that addressed some of these:
The first WYSIWYG editors like FrontPage, GoLive and Dreamweaver started appearing. They offered a hybrid approach between being a text editor to directly edit HTML while also allowing a direct, visual editing of content. This was a first glimpse of actually seeing how your site looks while you’re editing it.
As a nice addition services like Geocities made the whole part of actually publishing your site easier. You just logged in on a website, pasted or edited stuff in a textarea and your website was live.
Content silos a.k.a. social media
Kind of as an alternative to this the first later to be called social media platforms started appearing: Maybe some of you remember uboot.com, myspace or StudiVZ. And then of course Facebook. They all offered little to no control over the looks and structure of the content, but in return simplified the publishing of content inside that boundaries. No need for HTML or FTP uploads any more.
Content management systems
Roughly at the same time another approach started to appear: CMSs like Typo3, Drupal, Joomla and of course WordPress. These approached things from a different angle: Instead of getting rid of the complexities through limiting users they separated content and layout into the editing backend and a template system. Like this the content editing became simpler for the users since the layout could be handled separately by those familiar with it. Also this abstraction made it easier to make global changes and maintain consistency across all pages of a site.
And finally, most recently, there was again a new approach: Page builders and website builder services like Squarespace, Wix or Jimdo that started from where CMS systems where. They sacrificed a lot of the separation between content and layout as well as low level control of things. But this also enabled them to remove server management responsibilities and go all-in on the end user friendly, code-free, visual editing of content.
Content editing comparison
Ignoring the somewhat special case of social media this is roughly where we’re at right now as of today:
|full control (over HTML)||◆||◆||⬖||◇|
|no HTML needed||◇||⬖||◆||◆|
Since each approach has its merits one might conclude that you should just pick whatever fits your needs and skills and be happy. Right?
Well yes, but if we’re looking at it from the perspective of WordPress…
What does it mean for WordPress?
So basically Page builders highlighted this one big issue a lot of CMS / website building tools, in particular, WordPress have always had:
Editing simple, linear content only containing basic elements works great out of the box. Editing complex content – not so much.
Sure, with some work you could do some creative styling or go in the other direction and even limit the creative styling freedoms of an editor. But out of the box WordPress always had a middle ground here: You could install and publish content without needing to touch code at all. At the same time you were always able to do so if you wanted to make deeper customizations. As such WordPress offered way more freedom than closed silos like social media platforms. But it sure as hell wasn’t easy:
- Layouting content beyond anything simple like changes of font color or size quickly hit its limits with the old pre-Gutenberg TinyMCE editor. So people reached for hacks and workarounds like column shortcodes or editing raw HTML.
- With more complex content with a distinct structure things got even more tricky. For a quick start you could just create things manually. But if you ever needed to globally change the order or formatting of things or wanted to globally remove parts of the content you’d have to go through all pages one by one and change them everywhere. If you have tens or even hundreds of pages this very quickly becomes annoying.
I guess anyone having worked with WordPress has hit those two things sooner or later in one form or the other. And you probably also had your ways of dealing with them. Let’s have a look at how the WordPress ecosystem handled those pre Gutenberg.
Structure & consistency before Gutenberg
Traditionally this has been solved by structuring such content as Custom Post Types with Custom Fields, usually using either dedicated plugins for a specific content type (think event calendars, portfolio item plugins,…) or generic Custom Field Plugins. With these tools you could create a dedicated UI storing distinct data pieces as such, e.g. as CPTs with post meta. You then build the actual page output (HTML) by combining the raw data with a separate template.
With this approach consistency could be enforced and any change to the layout only needed one change in the template to automatically update all pages based on this template.
Also inside those templates one had the full possibilities of HTML and CSS beyond the basic styling options of the TinyMCE editor.
This worked quite well for bigger projects with the availability of a developer handling changes in structure and layout. They could handle those changes and corresponding data migrations in a clean and reliable way. But there also was one downside:
The developers always were a bottleneck of the process.
Any changes that touched structure or layout needed to go through them. It also became difficult to create one-off things like a totally different layout for one specific post. Since the layout was defined in the templates editors couldn’t just open that one post and change things the way they wanted.
Page builders & website builder services
Since the dependency on a developer was a real issue in the day to day business of things obviously people saw the business opportunity here and built solutions that made it easier for non-technical people to make styling changes:
Page builder plugins were born.
Some users even left WordPress for good and instead used website builder services. Looking at the fast and constant rise of the latter the demand clearly was there.
Allowing visual editing of content while still running your own WordPress installation (with the ability to customize stuff beyond the default options when absolutely needed) was a big step forward, at least for non-technical users.
People now could often build websites on their own, inside an UI that didn’t require technical skills like knowing HTML. But as usual this also had a downside:
Since page building wasn’t a WP core feature each plugin had it’s own way of approaching this. Since we’re talking about the core experience of a CMS, editing content, this was quite severe and caused a fracturing of the WP ecosystem.
WordPress tries to keep up
In any case there was rising fear that WordPress would fall behind while website builder services where steadily growing.
Both approaches, page builders inside WP and website builder services, did prove their viability over many years. The market pressure to offer some of that in less bolted-on ways was there. The core WordPress 20%/80% principle also applies here:
[…] core should provide features that 80% or more of end users will actually appreciate and use.
All of this finally led to the realisation that WordPress Core itself needs to step up. And hence the Gutenberg project was born.
Gutenberg: Why and what?
Since the need for more complex layout and multimedia content was very widespread, but the desire for a clean and strict content structure was less so, the focus of Gutenberg was on the content editing experience. Still, Gutenberg didn’t go all in on the layouting part, at least not in the beginning. It first limited itself to the post content, placing itself somewhere in the middle between the old core editor and the full-page-editing capabilities of page builder plugins.
At the same time (to not break old content) the storage model was a bit half-assed still mushing everything together as a single blob of HTML in the database on a post-level and only separating blocks in the editor.
In any case this finally gave us an officially mandated structure for more complex post content.
How to create a mess
So, after all this theory let’s have a look at what this all means, like, in the real world. I guess most of you have already, knowingly or unknowingly, used the Gutenberg block editor. (If not you can try it here.)
Empowering content editors is the Nr.1 priority of Gutenberg.
What I want to show you now though is an, admittedly drastically exaggerated, direct result of what that can mean:
If you’re wondering what you’re looking at: This is just me going crazy with the block editors default blocks and configuration options.
Even though this might trigger warm feelings for some of you that remind you of your old Geocities sites or myspace profiles:
I guess most of us would agree that this isn’t really what we need or want the web to be in general.
Taking back control by taking away control
So as we’re approaching the end of this post I’d like to mention one of the core principles of WordPress:
Decisions, not Options
As such I have to say that I do have some issues with the currently unavoidable, unbound empowerment of content editors in WordPress.
I’m personally convinced that taking away some choices concerning layout and styling actually helps users be content editors by freeing them from this additional responsibility. This actually makes their lives simpler and makes them feel more in control even if they might not technically be.
And with this thought I’ll leave you for today.
In the next post I’ll then go into the technicalities of how we might turn this ideas of simplification into reality by configuring, restricting and locking down Gutenberg.