Except, I think, that this perception is incorrect.
What Do Users Want?
In this thought process, customers want Squarespace or Wix. They want an easy way to either create and manage their website without engaging a designer or developer, or (in the case of more sophisticated and enterprise users) they want greater flexibility in their layouts for things like one-off landing pages. This thought process is driven by the success of these two platforms. And, certainly, there is a group of users for whom these are viable options. Some turn out better than others (most sites that I see built with Wix look like a train wreck…Squarespace at least manages to maintain some aesthetic appeal, but does so be enforcing homogeny), but for a group of users who do not require nor care about any unique aesthetic, are content with generic options and require no customization, then these options would make financial sense. This is, I would argue, the lowest common denominator of users.
There has always been an interesting balancing act when developing within content management systems in attempting to determine how much control is too much control to give to the client. Ultimately, the site is the client’s, and the keys to the kingdom should be theirs. In order to maintain the design that they hired someone to build, however, a certain degree of flexibility must be removed from the user, especially the user who is not technically savvy, in order to protect them from themselves. Otherwise you end up with purple and red fonts on pages and other things that make unicorns weep.
Anecdotally, I think that this is a leap in logic. Just over the past week, I’ve had discussions with two or three users who lament this trend, who want to use dedicated fields on the backend the way they always have, because they know it works, they know what to expect, and they actually feel as though it gives them more control. Layout builders are for amateurs, they think. They want to do this the right way.
In case you’ve been on a different planet for a while, I’m certain you’ve heard about the controversy surrounding the new editor for WordPress, code-named Gutenberg, that will ship with WordPress 4.5 as the core editor. Gutenberg replaces the editing experience familiar to WordPress users for years with the concept of blocks that can be added and re-ordered on the fly, with styles in the editor matching the way the content will render on the front end. Users who have experimented with Gutenberg, or are using the beta plugin in their sites already, have extreme reactions from what I’ve seen: they love it, or they hate it. WordPress is all-in on this becoming the core editing experience, and this is a huge gamble for the core team. The thing that WordPress has done better than anyone else since forever is giving the end user an editing experience that is elegant. Moving Gutenberg blocks around is anything but elegant. I’ve found it to be a clumsy, inefficient and outright painful process in testing.
WordPress Isn’t Alone, Though
Layout is a Matter of Preference
The huge difference in how Gutenberg and Drupal’s layout builder are being introduced is ultimately an issue of choice for the end user. WordPress isn’t giving users a choice in the new editing experience. The messaging is essentially “here’s Gutenberg, and you’re welcome.” Drupal, being more abstract by nature, is preserving the choice. If you don’t want to use it, simply don’t enable the module. If you prefer to use dedicated field groups that you control tightly in the theme layer, user Paragraphs instead…an approach that I’ve used for a long time in custom WordPress themes using Advanced Custom Fields.
Interestingly, this is scheduled to a be topic of conversation at DrupalCon Nashville in a couple of weeks. I’m looking forward to attending these.
Another interesting point is that, as the web becomes more API-driven and sites and applications become more frequently progressively de-coupled, I can’t see how these layout builders can’t introduce nearly insurmountable obstacles to headless sites driven by these content management systems. This is a curious step backwards to giving developers cleaner separation in the front-end and back-end stacks, something that was desperately needed.
Shiny New Things
Ultimately, I don’t think that Gutenberg is a bad idea. I think that it should be build differently under the hood, but I’ve also felt the same about WooCommerce for some time and that hasn’t been a deal-breaker for working in it. Gutenberg can certainly move WordPress forward, and give a lot of users and developers more flexibility in the content that they can produce. I just think that a choice should be preserved. While you can fall back to the classic editor initially, the core team has been fairly clear that this only buys you a year at most before the second phase of Gutenberg ships, which promises to take over the template hierarchy as we know it. We can only imagine what that means at this point.
I think that WordPress should learn from Drupal’s philosophy here and maintain the choice. The current editing experience, while painted by the Gutenberg team to be somehow antiquated, is one of things that many WordPress users, especially bloggers, love. I think there’s a huge risk of WordPress hemorrhaging market share here, or worse, fracturing the community. It’s not difficult to imagine a future in which WordPress forks and we end up with a classic and Gutenberg version. The complexity that this would introduce to the ecosystem would be counter-productive for everyone, and would be a tragic turn for what is arguably the most popular content management system in use today that could be have been prevented by simply preserving choice.
Time will tell how this change will effect both WordPress and Drupal. I think that pressing forward with the assumption that this is what all users want is a strategy that is not going to serve WordPress well. I can’t imagine this change not ending with damage to WordPress. I hope that the damage will be minimal.