Reflecting on the topics I’ve covered on this blog recently, I can’t help but notice that my tone has been pretty salty lately. Despite receiving a ton of positive feedback on my writing (thank you!), I’m personally disappointed that I’ve not been more constructive.
In a recent Twitter thread with Birgit Pauli-Haack (whom I really admire) I came to realise that I was just having a whinge, and not providing any productive feedback. Birgit and Mark – I apologise.
This grouchy attitude really runs contrary to how I usually think. I try to be a “if you don’t like it, fix it” kinda guy.
As an aside, I’ve evolved my thinking on the problem with Gutenberg development. The issue is not just that key decisions about the future of WordPress are facilitated through a developer tool¹ – the issue is that nobody is proactively seeking input from the WordPress users who aren’t involved in core development.
One of the things I love about the WordPress community is that there’s a culture of “we’ll hear you out”. When an irritated crazy with an axe to grind joins the Core Dev Meeting on Slack, it’s always handled with grace and care. Criticism rarely results in controversial political encounters.
I think this comes from the top. Listening, recognising, responding in a politically sensitive way – that’s one of Matt Mullenweg’s superpowers. You should see this guy deftly manoeuvre through questions from the floor during a State of the Word address. It’s impressive!
Maybe we’ve gotten too good at handling criticism? In an open source project the size of WordPress, critics are numerous and persistent. Out of necessity, we’ve become experts at hiding negative sentiment in plain sight.
For example, nobody seems to be talking about this:
It seems like simply noticing and writing about problems with the WordPress project² doesn’t really achieve much. So in the future, I’ll attempt to include a practical aspect to my writing.
For example, I might write about how it’s nearly impossible for plugin authors to have a clear picture of how (or even how many) people use their plugin, due to restrictions in the plugin guidelines. With this post, I could include a functional workaround – a loophole in the guidelines, based on examples from Jetpack and Woo.
In this manner, I hope to keep writing here, and hopefully have more of a positive impact on the ecosystem³.
1. Don’t try to convince me that GitHub isn’t a developer tool. I know discussions also happen on the Make blog and Slack, but it’s all funnelled back to GitHub for the real decision making.
2. Insularity from users; power dynamics with Automattic; plugin guideline hypocrisies (looking at you Jetpack); Envato’s enduring WordCamp ban; developer-centric decision making; the list goes on.
I remember back when Gutenberg was still in beta, we were talking a lot about what the block editor would mean for the future of WordPress.
Would blocks be distributed in themes, or in plugins? What would Gutenberg look like if it were combined with the Customiser? Should widgets be blocks (and if so, what about the header logo, or copyright colophon)?
It described something very important! The future of themes in WordPress! Unfortunately, it was published on GitHub, and to read it, you needed to view the changeset and parse the markdown. Of course, the WP community doesn’t read every new PR that comes through the Gutenberg repo – so this could have easily flew under the radar.
This Pull Request has been met with a considerable degree of concern. I wanted to take the time to write about this from the perspective of:
What does this experiment look like?
Why is there resistance to the idea?
Where do we go from here?
What does this experiment look like?
Sorry Riad! I think a large part of the problem here is that this first documentation on block based themes is actually quite difficult to understand. I spoke to a few different people who couldn’t quite wrap their head around it.
Here’s my interpretation:
Let’s start by imagining that blocks could be used as widgets. You could add, say, a Quote block to any one of your widget areas.
Now, did you know that in the latest version of Gutenberg there’s a “Navigation” block? This is what it looks like:
So, now we could easily replace the navigation in our header with a widget area, and insert the Navigation block. While we’re there, we could insert our logo as an image block, and align it to the left.
At this point, the name “Widget Area” isn’t such a great fit. Let’s call it a “Template Part” instead. We’ll have Template Parts like Header, Footer, and Sidebar.
Hey, now that we’re thinking about it, don’t forget that WordPress 5.3 introduced Group blocks. We could use these to do something pretty cool…
Start with a completely blank page. Nothing on it – no header, no sidebar, nothing. We could add a group block to the top, and make that our Header Template Part. Then below that we could add another Group Block, and expect the Post Title and Post Content to be added there. Maybe another Group Block next, and put Comments in that. Let’s finish off with a Group block for the Sidebar Template Part, and then a Footer Group.
We’ll call it “single”. It will be structured something like…
Header Template Part
“Logo” image block
Post Title block
Post Content block
Sidebar Template Part
Footer Template Part
“Copyright” paragraph block
(Notice our Template Parts are kind of like reusable block groups.)
This is called a Block Template. We could create it in some sort of Template Editor in the WP-Admin, and export it to be used as a theme.
So themes would be responsible for three things:
This includes the structure of how the Template Parts fit together visually, as well as styles for all blocks (they might even be styled differently in different Template Parts).
Not dissimilar to current theme templates, and maintaining adherence to the Template Hierarchy, these describe the overall structure of the page, in the language of blocks (especially Group blocks) and Template Parts.
The theme should probably add some default blocks: a logo and navigation to the header, and a paragraph with copyright text to the footer. Even though these blocks could be easily changed and removed by the user, the theme should include a starting point. These defaults belong in a Template Part, and the Template Part is included inside a Block Template.
Hopefully that makes things a little clearer! For those of us who have been using traditional WordPress templating for the past decade or more, this is quite a tough change to wrap your head around. 💫😵💫
Why is there resistance to the idea?
Aah… politics. Unsurprisingly, there’s some #wpdrama going down because of this proposal. Some of it is based on simple misunderstanding (a.k.a. poor communication), but there’s more to it than that.
The subtext here is that Riad works for Automattic. I won’t dive into the history of WordPress and Automattic, suffice to say that their CEO leads the WordPress project¹, and as such, there is a constant concern from the community when Automattic approaches conflict-of-interest boundaries.
So, when an Automattician makes a giant proposal on the future of theming in WordPress, which gets merged into the Gutenberg project the very next day², I think it’s very reasonable that people are concerned.
Here’s a timeline of how it went down³:
September 5: Automattician Matías Ventura publishes a Make WordPress post describing full site editing with blocks. It’s met with a lot of positivity, but doesn’t include much detail on technical implementation.
September 23: Google employee Felix Arntz created an Issue in the Gutenberg Github repo describing Matías’ post. The 15 comments on that issue (before the PR on December 4) were all made by Automattic or Google employees.
The people with power all work for Automattic and Google.
It seems fairly clear to me why there is so much resistance to the idea. I believe it’s because:
The experiment was poorly explained, and widely misunderstood.
There wasn’t any opportunity to understand the technical implementation.
There wasn’t any opportunity to discuss it either.
The whole project is being rushed through by Automattic (with some help from Google).
Feedback / concern is being brushed aside or hand-waved away, instead of properly discussed.
December 5: Hours after this PR is approved, Derek Hermann chimes in. Derek has been contributing to WordPress for years. Over that time he was a feature lead on the Customiser, worked with me to build Tide, and has been very active in Gutenberg’s development. He’s also the CTO of XWP (one of the largest WordPress VIP agencies in the world).
Derek has some real concerns, and lots of questions, which Matías tries his best to answer (although to be honest, Matías’ answers left me even more confused). Derek’s Github comments get lots of 👍 and ❤️ support. Even so, nothing changes.
You have to research what the users want, not what the team wants to build. Where is your research?
Which brings me to…
Where do we go from here?
Alright, now we start to get into the territory of my opinion. Of course, you’re entitled to agree or disagree – take it up with me on Twitter if you like.
So, in my opinion, the entire experiment should be reverted.
The perception is that Automattic is working on Block Template themes in the shadows. Why? Do they see themselves as pioneering a future that we don’t yet know we need?
The rest of us need to be looped in to the decision making process.
Reword the document in this PR as a proposal, and post it on Make WordPress for feedback. The first Make WordPress post from Matías contained very few technical details.
Allow time for discussion! Put it on the agenda for the Editor Chats that happen every week.
Help the community to understand what this looks like – because clearly nobody does right now.
Most importantly, research how Users, Agencies, and Theme Designers want to engage with themes in WordPress. Make a decision based on that research, not based on a handful developers best guesses at how a block based themes should be implemented technically.
Merely asking for feedback is just not good enough. If nobody responds, that doesn’t mean you get to decide for yourself. That’s not how research works.
Maybe a developer tool isn’t the best place to ask for feedback on the future of WordPress. We can’t expect our community to learn GitHub, and follow the discussions happening across nearly 20,000 issues.
Maybe, if we facilitate a friendly, open, and wide-reaching dialog, we might arrive at different conclusions.
Important note: Nobody involved here is being intentionally malicious or hostile. I believe we have a problem with structure and power dynamics, which is what I’m trying to call attention to (not the individual developers).
I reached out to Matías and Riad and get their feedback before publishing this article.
There’s no shadow here . This was discussed for more than a year now in different Github issues by different people and regularly on #core-editor weekly meetings (which I invite you to join to discuss the proposal and help).
In chatting with Matías, he noted that the proposal for block templates has been discussed for a really long time in multiple places — there are GitHub issues from all the way back to 2017.
2. Actually, the experiment itself was merged a while ago – what we’re talking about here is only the documentation about the experiment. To be aware that any of this was happening, you’d have to be following along on GitHub.
The reason this PR was noticed was because the part that got merged was Documentation – thankfully a bit easier to understand than trying to string together multiple conversations between PRs, issues, and code. Even as it was, though, this could have easily gone under the radar if it weren’t for Justin picking it up on the Tavern.
3. There was also a call for feedback published on the Make WordPress blog, on November 3. I didn’t include it in the timeline because block based themes are just one line item among many – easily lost on a Make post that seems to have gone mostly unnoticed.
What we’re looking at here is a brand new WordPress install after installing just 5 plugins. It’s a mess!
Now, a common Notifications API in WordPress won’t fix this entirely, but it could improve it a lot. The most interesting idea is to group notifications together in the Admin Bar.
This could produce a UI similar to the way Yoast handles notifications (see the screenshot above). It would also restrict notifications to:
A limited amount of text (280 characters, for example)
Notifications in WordPress can be grouped into a few categories:
The plugin wants the user to take an action (often required before the plugin can be fully functional). For example, adding an API Key to Akisment, or connecting Jetpack. Sometimes it’s an optional action, such as taking a survey.
The plugin wants to teach the user about a feature, and so it shows a notice (usually contextual to where the feature exists) with some help text.
The plugin has detected information about WordPress which it wants to surface to the user. For example, Yoast detecting that search engine indexing is disallowed.
The user has taken an action, and the plugin wants to notify them about the result (e.g. Post Saved, or Error Saving Post).
The plugin wants to show the user information about a paid upgrade or a current sale (please, no!).
While grouping notifications together into a single Notifications Hub would help reduce a lot of visual clutter, not all of these notification types belong in a Notifications Hub.
Onboarding notifications nearly always need to be shown in context. These are typically inserted into the UI, intentionally interrupting the user journey.
Results are a little different to other notifications in that they’re not usually persistent. They only need to be shown once, and automatically dismissed. Gutenberg’s notifications implementation does this really nicely.
Advertisementscould exist in a Notifications Hub, but probably won’t. These notifications are all about grabbing a user’s attention, and grouping with other notifications isn’t a great way of doing that.
Given that only a few types of Notifications that would make use of a Hub (and even then, only at the plugin developers discretion), is WP Notify worth pursuing?
To answer this, I installed the 20 most popular plugins and catalogued the notification types I encountered. By collecting this data, we can see what percentage of notifications would be “captured” in a Notifications Hub area.
Of all notifications that I encountered, 19 / 30 (63%) could belong in a Notifications Hub.²
One interesting side note: Due to the brief usage of each plugin, I’m sure I missed many “Results” notifications, such as notifications shown when saving settings.
Should WP Notify provide a method for developers to show this style of transient notification, separately to the “grouped” Notifications Hub?
If you’d like to be involved in making this proposal a reality, you can get involved by joining the #feature-notifications channel in the WordPress Slack.
This is a great opportunity to get involved in WordPress core development, especially for UX / UI designers who want to have a hugely positive impact toward a distributed and open web.
1. There is some concern that the admin bar might not be the best place to show notifications. It’s already crowded, hard to use on mobile, and sometimes hidden on the frontend.
2. In these tests, the average amount of notifications displayed (after only a few minutes of usage) is 1.5 notifications per plugin.
The fact that this decision took place and code was written to make this happen, speaks volumes for the management and leadership of this plugin. Unfortunately, they cannot be trusted, especially in a professional environment.
That’s six different people who all just went along with an objectively awful idea. Was there any internal conflict or discussion? We’ll never know.
I don’t think there’s any long-term repercussions here for Yoast. They made a mistake, they fixed it, they promised not to do it again. But with such a violent reaction from their users, it’s worth diving into why this hit a nerve.
Is This Allowed?
The free version of Yoast is run on 15% of the top 1 million websites. Not 15% of WordPress – 15% of the web. If the success of this ad outweighs the negative reaction, is there anything stopping Yoast from doing this again?
From the WordPress.org plugin guidelines:
Advertising within the WordPress dashboard should be avoided, as it is generally ineffective. Users normally only visit settings pages when they’re trying to solve a problem. Making it harder to use a plugin does not generally encourage a good review, and we recommend limiting any ads placed therein.
So… not recommended, but not disallowed. Yoast couldn’t be delisted from WordPress.org as a result of ads.
Yoast’s Black-Friday-Faux-Pas is an exercise in extremes. Their bright yellow and cyan full-width banner, animated like it’s 1999, was displayed on every – single – page. Freemium plugins including a small up-sell ad on their settings page don’t cause this kind of uproar.
Is there a place for ads in WordPress? Maybe there is. Certainly a sustainable plugin ecosystem is good for everyone, and the Freemium model seems to be an effective one.
Ads Done Well
Of course, the offensiveness of advertising prominence will always be subjective. Here’s a few plugins that I believe do a great job of letting their free users know about a premium option.
Advanced Custom Fields – everybody’s favourite custom meta plugin takes a very understated approach. You can’t even really call this one an ad, it’s so subtle (maybe a little too subtle?).
WP Migrate DB has a Pro ad in the sidebar. It only shows when you’re using the migration tool. Importantly, it outlines precisely how Pro improves on the Free version.
WP Migrate DB uses a formula that keeps things simple and unobtrusive: Call to Action > Value Statement > Social Proof. Mix and match to taste.
Some plugins add an item to the menu. In these cases, a sub-menu item showing the availability of Pro might be acceptable.
The advantage here is that visually there’s no “Ad” in the plugin (similarly to ACF above), but information about Pro is available for users who might be interested.
Ads Done Poorly
Contextual ads sound like a good idea in theory, but in practice can be borderline annoying. This is where you show users the features they could be using, if only they upgrade to Pro!
I imagine that it is possible for this type of advertising to be done tastefully, but it’s hard to find an example that doesn’t leave me feeling aggravated.
Yoast is famous for this brand of advertising. Who wants to use a tool that’s littered with bright yellow Calls to Action?
This is the worst. I haven’t even had a chance to try your product yet – at least let me see what it’s all about before hitting me with an upgrade prompt!
WooCommerce literally tries to have me install 7 additional plugins during the onboarding process! Some of them may be free, but all of them lead to paid services. I haven’t even seen WooCommerce yet.
This is extremely heavy-handed, and in my opinion, a textbook example of advertising gone wrong.
But even Woo is not quite as bad as WordFence, which, upon activation, creates a takeover model which requires an email address, and then promotes Pro! Again, before anyone has had a chance to use their plugin.
Advertising Guidelines for the WordPress Admin
There’s clearly a right way and a wrong way to advertise in the WordPress admin. If you, like Yoast, can’t figure out what counts as acceptable, here’s a handy guide:
1. Don’t advertise after plugin activation
Even if you’ve chosen to avoid the full-screen modal for your onboarding (👍), let your users at least interact with your product before hitting them with a Pro prompt.
2. Only advertise on pages created by your plugin
This includes post meta boxes, the Dashboard, and the Plugins list page.
3. No animations
I mean, that really should go without saying.
4. No teasers
“More features available in Pro” is fine.
Feature X is only available in Pro. Upgrade Now! Feature Y is only available in Pro. Upgrade Now! Feature Z is only available in Pro. Upgrade Now!
WordPress 5.3 “Kirk” is out! It’s the third major WordPress release this year – and it includes some interesting changes. Let’s dive in.
Despite early reluctance to the new editor, it really seems as though the WordPress community is warming up to it. This release in particular makes some changes to Gutenberg that enable some powerful content design possibilities.
If you’ve been reluctant to give Gutenberg a shot, now might be a good time to take a fresh look. Of particular note is the Group Block.
With the group block, you could try combining multiple blocks into a “wide width” group block, with a background colour.
You could also save a group as a reusable block, creating an insertable multi-block section. Imagine a “buy my eBook” breakaway, or a newsletter signup.
There are still a few bugs – Gutenberg still feels to me like a late-stage beta.
Sometimes a feeling is all we humans have to go on.
Captain James T. Kirk
But we’re getting closer. The UX of traversing through layers of nested blocks and columns has improved a lot in this release, but it’s still very clunky.
Background colour gradients didn’t make it into this release – but I think we can safely expect to see them land in 5.4.
This is the first theme since Twenty Sixteen that I can get behind. I absolutely love it (and I’m running it on this blog).
The team behind Twenty Twenty has perfectly balanced the design’s opinion and flexibility. It seems to have taken a lot of inspiration from another personal favourite of mine: Tabor.
It’s light-weight, simple, and includes a beautiful custom typeface called Inter. Shipping an open source typeface with the theme is a stroke of genius for fighting back against Google Fonts (brilliant, but very privacy invasive).
This means that aside from Gravatar (and any embeds that I put in my posts) this site loads without calling any external scripts or styles!
Short for “Accessibility”, a11y was a huge focus in this release. Many of these updates are related to navigating the block editor with a keyboard, but the most obvious change is the WP Admin colour scheme.
If you’re using the default colour scheme (you can change this from your profile page), WordPress is now much more high contrast – interactive controls and metaboxes have darker borders and lighter backgrounds.
Personally, I’m all for making WordPress more accessible. There has, however, been some criticism of the new design.
The old CSS was better. Now there are lines lines lines lines borders everywhere. It is really bad for eyes, like a table with dark lines…I think i will overwrite it with custom css.
Ouch! The Make Post announcing these changes has a lot more where that came from.
MacOS has a “high contrast” accessibility feature, which can be toggled on and off. That seems like a good compromise to me – even if the high contrast mode is enabled by default. The WordPress a11y team seems to have some strong opinions that run counter to that, though, so I can’t see this happening.
Admin Email Verification
Another sore point. The idea here is that WordPress will now periodically check that the admin email setting is correct. Slightly annoying, but I can see how that might solve some security problems for users who don’t log in very often.
There was some heat around this topic in the WP Australia community. Gal Baras brought up a good point:
WordPress is clearly not subscribing to the Unix philosophy of trusting the user to know what they’re doing. It keeps trying to control things based on the assumption the site owners need to be saved from themselves…
… being prompted every 6 months to verify my admin email on the number of sites I have is not making me happy.
I work on hundreds of sites, for each one I have a local install and a staging site (I code locally and upload to staging for review). So two thirds of the sites I work on aren’t “real” websites and a third aren’t accessible on the web.
The feature can be turned off with a filter (admin_email_check_interval), but maybe this should have been an option, instead?
Personally, I’ve not ever had a problem caused by this setting being incorrect, and I’ve run into the verification screen enough times that I automatically click through without actually reading it. So from that perspective, it’s more annoying than helpful for me.
The Core Team vs. The User Community
Admin email verification isn’t a hill I’m willing to die on. More interesting to me is the negative response from the community. Both on this issue, and accessibility. Has the core team learned nothing from the Gutenberg release?
Even the most enthusiastic Gutenberg proponents (I count myself among them) have to admit that the rollout of the new Editor was terrible. The Classic Editor plugin only came out last year and already it’s the fourth most popular plugin of all time!
Communication from the Gutenberg team was nowhere near good enough, and the user community felt dismissed and unheard.
It seems to me that the core WordPress team are becoming increasingly perceived as pretentious and aloof. The democratic and libertarian values that underpin WordPress are being twisted into an alarming refusal to listen.
Maybe it’s due to the “Benevolent Dictator for Life” model behind Matt Mullenweg’s leadership (there’s a WordPress Governance Project which doesn’t seem to be going anywhere). Maybe it’s a well intentioned effort to stand behind under-represented minorities, even in the face of overwhelming negative feedback.
I don’t pretend to have all the answers, but surely acknowledgement and empathy would be a better approach than “we think this is important, so it’s going to happen whether you like it or not”.