I am refactoring a university department WordPress website built in-house, somewhat haphazardly. We use the Enfold business theme based on Avia Layout Builder. Enfold/Avia is a typical Themeforest product, a bloated solution competing on how many features the product has. So the question for me is, what is the best professional modern solution to replace Enfold today?
Other than the general requirements for any site made in 2021. we need:
- Accessible base. As a public institution, we are legally obliged to follow a11y standards. We need a solid base to build upon and follow the standards.
- We need to achieve shorter delays with publishing content. Since the website is a mid-size portal, we need to enable a larger editorial team to manage content editing without breaking stuff. Finer control over the admin area and the editor page are thus necessary.
- An efficient way to produce new layouts as the need arises.
- We do not want to do this again soon, so we want something stable.
This list seems like a task list made for my favorite starter theme/toolkit: wprig.io. Wprig lists these as their primary focus: #Performance, #Accessibility, #Mobile-first, #Progressive enhancement. However, we often need to create new page layouts for this website. So should I choose a visual builder instead?
Some thoughts on Gutenberg
Though I recognize now that the introduction of Gutenberg in 2018. was a tectonic shift in the WordPress ecosystem, using Gutenberg did not feel that way when it appeared. It felt familiar and pretty. Specifically, to me, it looked like MailChimp block editor, and it still does to this day. I believe MailChimp is the first block editor I have encountered. The paradigm which I now see everywhere. Notion app has a block editor, so does Medium — blocks are everywhere.
If in the 2010s the buzzword was semantic: semantic HTML, semantic elements, semantic web, 2020s is all modules, components, blocks … oh and patterns. I cannot help not to think this change is a bit depressing. A move from optimistic ideals of adding meaning to the web, linking information in a semantic web, to focusing on what seems to be tactics on how to manage the complexity in web building more efficiently. From a dreamer to an overworked pragmatist. But I digress.
Gutenberg in 2021 is a bit different. The blocks have overrun the_content() and moved into the sidebar, the footer, and soon the header as well.* At the same time, it manages to promise to democratize website building for everyone and make it more difficult for many developers to follow the now much steeper learning curve React poses compared to Php. In other words, it adds layers of complexity in code to create an interface that would make it simpler for everyone to make websites. It seems to me, this is where the friction in the WordPress community comes from.
More practically though
It feels nice to work in Gutenberg. It is intuitive and light and feels like it belongs in a browser (more on that later). The experience of building with Gutenberg blocks feels both more semantic and abstracted from the DOM. Blocks are representations of common content parts. But, they also suggest appropriate relations between these content parts, both in terms of content and the layout. However suspicious one might be towards this, for sure, it is a more efficient way to put pages together.
What about the clients
What about them? 😎 Well, this is where the mess comes in for me. Though Gutenberg provides an easy way to build layouts for everyone, not everyone wants this. Hell, I would bet that in the client space, almost nobody wants this. And the Gutenberg team does not seem to care much about this either. The ways to control access to blocks, patterns, and block settings are all around the place. Gutenberg team allows this to be done by the users themselves, by toggling off certain blocks or page settings that the user doesn’t want. As if the idea that the user should be the one to make those choices weren’t bad enough, these settings are also cookie-based, so they are anything but permanent.
Now there are ways to do some of these things programmatically, but it is inconsistent, not available in all places one would want. There are multiple ways to turn some parts off and no way for others …
But Gutenberg is a native builder, and this is its very, merry big plus. So there.
Oh, and there is a 3rd party blocks mess too.
Visual development, No Code Movement, Other WordPress Builders
Around 2010 I tried to use DreamWeaver. And I ran away very fast, together with a whole generation of web authors, designers, and developers alike. So it is fair to say I am entering this space with a “healthy” dose of skepticism. One of the reasons I moved to WordPress from Joomla was because it felt more elegant to write a function to do something than to find that module and that button to have the damn thing happen. Joomla was big and complicated with a button for everything, and WordPress was lean and mean. 💔
Then I learned about the Webflow 💥🚀
Webflow is a new tool. Probably best in the category, a SaaS visual development tool that features a really well-made Designer interface. Webflow has dynamic content functionality, webshop functionality … and the rest, the server, the updates … all is handled by them. You literally just push the button, and the thing is live.
Webflow also features an Editor, which is a significantly different interface. The developer can set what the editor gets to do for any element on the website.
It has various animations, more and more integrations … the code it outputs is good. Designer UI also feels familiar the minute you see it, both because it looks like a designer’s tool and because its interface closely approximates HTML and CSS API. Things are called the same and behave pretty much the same until there is no button for some feature you have been using for years. But still, Webflow is a solid visual development tool.
But, it is a proprietary tech and still misses things like proper ways to handle multilingual sites … the pricing doesn’t fit me, and it is not WordPress. I use it in my teaching sometimes, though.
Regardless, Webflow is a benchmark against which I measure visual development tools or builders.
Back to WordPress
WordPress is a CMS first. So most builders in this space are not designed like a designer/developer tool. They are built as an administrator/editor tool rather. Most drag and drop builders in the WordPress space are specific improvements of the content editor over many iterations. They may have the ability to do anything, but they are not iterative enhancements of some designer/developers’ tool.
For example, look at this Drupal gif from 2014.
This module is called Quick Edit. It allows a logged-in user to edit content-in-place, skipping the go-around to the admin area and back.
Now, look at this BeaverBuilder promotional video from 2014 as well.
If we ignore that BeaverBuilder can build layouts while Quick Edit can only alter and create content, the shared UI paradigm is apparent. These tools were initially made to solve problems WordPress as a CMS poses. This is why these tools seem to empower the website editor/admin and not its designer/developer. Note, Webflow’s Editor interface is really pretty strict and conservative. It generally consists of fields to fill in.
Some WordPress visual builders are built with the developers/designer in mind, and I will write about the two.
Bricks and Oxygen
Bricks is a very new tool, a theme/builder, adopted by the community very rapidly. First launched in March 2021, Bricks is a very stable piece of software developed by a small dedicated team led By Thomas Ehrig, built with a user-driven development style. If you want to check out the feature priority list, visit their public Road Map. The Bricks UI design shares many Webflow paradigms, a horizontal bar on the top and two panels on the side. BricksBuilder has it all: templates, sections, helper patterns, simple elements, Html elements, custom properties, custom elements, global elements, dynamic content, global styles, and libraries. It produces clean and performant code, and the editor is quick and responsive. What I particularly like is how true-to-specs Bricks is, CSS-wise. Both the naming conventions and the behavior is consistent with the modern CSS specs, supporting things like calc(), clamp(), to name a few.
However, where Bricks fails, for now, is at the UI it does (not) provide for the client/editor/admin. The controls over that experience exist, but they are very minimal. There are options to migrate content from and to Gutenberg, so no lock-in, great. There are options to allow user groups to do anything in the Builder or just edit content, and that is it. All, nothing, or just content. In addition, “just content” is not “just content” when one can change a bunch of styling … and even some global elements and template parts. This makes BricksBuilder a tool for enthusiasts and the designers/developers to use for themselves… not for client projects. But keep an eye on BricksBuilder.
Oxygen is a bricks older sister. It shares many of the same qualities and features Bricks has. It shares the UI paradigm with Bricks and Webflow. Horizontal top bar, two sidebars, and so on. Oxygen has much more features than Bricks, and like Webflow, it has more and more integrations, extensions, etc. While its UI is much less intuitive, much, much heavier (feels like running Blender in a browser) and the learning curve much steeper, Oxygen can do significantly more than Bricks can at the moment. Most importantly, it has a pretty robust solution for editors called Client Mode, and it can build custom Gutenberg Blocks as well. So at this moment, Oxygen can be used as a tool for client projects while Bricks cannot.
However, tools like Oxygen or BricksBuilder feel off in the WordPress admin. So much so that they have to completely take over the screen (and not only the screen) to work. And this always leaves an uneasy feeling to a long-time WordPress user. From being an extension to the WordPress core or its editor, these tools have become full-blown applications that use WordPress merely as its database manager. So one has to wonder, how optimal are these solutions for web projects to be built upon? I believe, Both Bricks and Oxygen, in particular, would benefit from becoming complete web building applications, not plugins running permanently on the website. I would love to see a solution that compiles a theme/plugin bundle as the final product for the client handover. Same like starter-theme/build tools like wprig do.
Where I want the Builder
Bricks and Oxygen are both great products, but for this project, I do not need my builders to take over the entire site. After some research, at some point, I came to the conclusion that I do not need a theme builder for this project at all. Themes today handle the design globals, and I honestly do not see how can this be faster or better handled than with a bit of code. I need page-building capabilities to live IN the page content area. In order to scale the website over time, and simplify my life I want to have a simple stack as I can while having some ability to build page layouts.
In my mind this means … 🥁 … GUTENBERG. Wait! Before you even try. I have tried Beaver Builder and I do not like it — nothing is intuitive there for me. Sorry.
An article about my chosen stack follows soon, so please come by.
*If you didn’t know there is also a Gutenberg Everywhere repo on Automattic’s GitHub where they are porting Gutenberg outside WordPress entirely, even into the Desktop space even, now you know.
