What do you get when you put a handful of outspoken WordPress developers, agencies, product owners, and community advocates on a video call with both the Lead Architect and the Product Owner of the entire Gutenberg project? Hopefully progress.
Matt Mullenweg may have surprised a few people when he recently stated that the Gutenberg project still has years of development to go, but I doubt that anyone using it would disagree. The tentpole feature of Gutenberg’s Phase Two, the “Site Editor,” has been in core (and enabled by default for new installations) for the last two years, but the adoption of block-based themes has felt underwhelming at best, especially compared to the market share of page-building tools like Elementor.
Everyone has their opinions of the block editor, one need only browse the comments section of this very site to find them. The reality however is that WordPress is a vast and complicated project. While it’s certainly subject to the decisions of its “Benevolent Dictator”, it is also subject to the very real constraints of large-scale, distributed, open-source software development. Not to mention the work is entirely based on contributions, many of which are sponsored by large organizations with their own goals for the project.
At the center of all of this are the individual WordPress end users who can feel like they have no agency in the project, no ability to communicate their experiences or give feedback. And there may be no piece of software in more critical need of user feedback than the WordPress Site Editor.
The Outreach Experiment1
The FSE Outreach Experiment was launched three years ago as a way to bridge that gap between users experiencing the Site Editor and the core contributors building it. Last week, the team announced a simplified name and scope: Outreach. As part of this new simplified scope, any core contributor can now tag the Outreach team directly in GitHub as they develop new features when they want early feedback from the broader community. The goal is getting more two-way communication happening, and keeping the feedback where it can be most effective: the Make WordPress Slack and the Gutenberg code repository on GitHub.
Social media may feel like the easiest place to voice an opinion (something I am certainly guilty of), but it doesn’t always manifest into meaningful change. “Most of our issues are around just discoverability,” Developer Advocate and Outreach team member Justin Tadlock pointed out recently. “Just getting people to come and take all their reactions and thoughts from social media and bring it in and have some constructive conversations in an official channel.”
Automattic Product Wrangler Anne McCarthy started the original FSE Outreach experiment but has since moved on. That didn’t stop them from providing some feedback on the Site Editor in the form of a widely circulated blog post, “Overlapping problems“. It’s a breakdown of some of the most common user experience complaints, but nearly every piece of feedback links to a specific issue or pull request where work is being done to improve it. If you haven’t already, I recommend pausing now to read it.
Because the problems are “overlapping”, some feel that they speak to an underlying problem with the Site Editor itself and the Gutenberg development process more broadly. Many armchair theories were thrown out, including some from yours truly, at last week’s Hallway Hangout, hosted by the Outreach team, and attended by a wide array of folks, including Gutenberg’s Lead Architect, Matias Ventura and Product Owner, Rich Tabor.
Is the Core Team listening?
Feedback loops in a community this large and diverse are (un)surprisingly hard to get right. One clear piece of feedback, though, seems to be a general feeling that while the Site Editor’s power and feature-set continue to grow, the actual user experience needs more polish. Yet when concerns about this user experience are raised, the general response is that it’s the users who just need more education and training.
“There’s a sentiment that I kept seeing,” Mike McAlister of Ollie explained on the call, “that ‘they’re not listening to us’. And whether that’s perception or their experience or whatever, I think that is very important for us to carry that and to kind of acknowledge it.”
Part of the disconnect between the different sides of our large community is related to that imbalance of incentives amongst contributors. Unless you are employed by a hosting company or a product team like WooCommerce or Yoast, it may feel discouraging to push a feature forward or feel like no one is advocating for your use case.
WordPress is meant to democratize the ability to put content on the internet. So there’s an expectation that its interface should feel, well, easier or at least more intuitive. Nick Diego, Developer Advocate from Automattic, shared an experience of watching his non-technical parents navigate the Site Editor.
“One of the biggest issues I see in the Site Editor,” he explained, “is around how changes that you make are preserved to prevent people from making mistakes. And this seems like such a small little thing, but I watched [my dad] delete a template that had been customized and there was no way to get it back easily. I watched him click on ‘Clear Customizations’ and everything was gone. And he was like, wait, what, what’s happening?”
Nick was showcasing a great practical example of the types of gaps in the user experience that eventually erode their trust in the platform’s ability to safely manage content. He also pointed out that there are tried and true conventions for many of these interactions. “In old WordPress, when you trash the page, it goes into the trash and then you can delete it permanently, right? It goes into your trash. Oh, I made a mistake? I can bring that back. It’s a very logical flow. It’s very similar to other applications.” But the Site Editor often veers into uncharted territory when it comes to user interface.
New tools and new paradigms aren’t just hard for the non-technical users. They can present new challenges for the developers who are trying to launch new WordPress sites. Time that developers previously spent building websites is now often spent exploring new potential workflows, and we can’t rely on our previous two decades of established best practices when scoping new projects. “I think part of this too,” said Anne McCarthy, “is also how to use these tools and changing process because everything I’ve heard is it’s not only a technical change and adjusting to new technology, but it’s changing process.”
This idea of slowing down and refining the basic user experience was reiterated by Brian Gardner, Developer Advocate at WP Engine, who advocated “a call to rally around making what we have already better and consistent and easy to identify and work and document and educate.” WP Engine in particular has leaned into the developer/freelancer side of the community, with a team of educators and content creators, and products like Advanced Custom Fields and LocalWP, all focused on a segment of the market they call “Builders” and what the Core Team often refers to as “extenders”.
The Extenders2
Extenders, builders, developers, freelancers, agencies. There’s plenty of names for this side of the community, but the one thing they have in common is that they build a lot of websites, often for other, less-technical people. There’s widespread sentiment in this group that the Gutenberg project is not prioritizing their needs, driving them to the Classic Editor or page builders like Elementor, Divi, and Bricks.
Fabian Kägy is a member of the Outreach team and a sponsored contributor from the agency 10up. He’s focused on fostering more conversation between the extender community and core development, so I spoke to him about this disconnect in priorities.
“There are so many different users that have all different calls”, he told me. “And kind of the reason why I am trying to participate is to share that one side of the story and be an advocate for that particular work. And I am very much hoping that I can actually get more similar folks from other agencies to also chime in and be a part of a conversation.”
Like Fabian, I come from the agency world, where we are constantly stuck trying to balance the desire to adopt the newest technologies for our clients with the need for assurance that those new features are actually ready to be used in production. That presents a tough problem to solve. The core team needs more people using and testing these features, to help refine them. But from the outside perspective, we’re hesitant to use anything that may not be production-ready.
“At the time a feature lands in WordPress Core,” Fabian explained, “there could be four or five months since the developer had originally worked on the feature. Since they last even thought about the feature, they’ve moved on and shipped three other features. And so that feedback cycle from the agency space is incredibly slow because by the time we adopt it, that is not top of mind anymore.”
This gap between the development of a new feature and its adoption by the wider community is the main problem the Outreach team is hoping to solve.
“That is why I am hoping that this kind of outreach,” he continued, “getting more pings, getting asked the question of ‘Hey, is this the right thing?’ Being asked to provide feedback earlier in kind of the development cycle should help us be able to deliver that feedback earlier in the cycle so that we don’t end up in the situation where a year after the feature has been developed, we all of a sudden say, “Hey, but this didn’t account for these issues that we are running into.”
If airing your Gutenberg grievances on social media is unhelpful, raising them six months after a feature was originally developed and tested might even be less so. But with the huge array of features being worked on (there are over 1,000 open pull requests just in the Gutenberg repository), some on a timescale of years, WordPress needs the Outreach team’s ability to do some human curation, often in the form of “Hallway Hangouts” where new features are showcased and discussed.
We are the world, we are the contributors
Watch any meeting of the Outreach team, and you’ll quickly realize that everyone, including a number of Automattic-sponsored contributors, often appear just as “in the dark” as we do. They have many of the same struggles we have. The difference is, they are trying to build a space where we can all connect the dots together. It was a great reminder that we’re all contributors here. WordPress isn’t some people over there building a thing, it’s just a whole lot of us.
One of those people is Matias Ventura, considered by many the de facto lead of the Gutenberg project. Matias joined this most recent Hallway Hangout, listening to feedback and sharing his initial impressions. After hearing from a number of voices asking about some of the features in Gutenberg that still need polish, he was quick to clarify that there is still work to be done and conversations that need to happen.
“I think part of that,” he explained, “is also how we communicate, how we do the marketing, both internally to know the roadmap where we’re heading, but also if you have this specific use case, what are the things that you should keep in mind? Because there’s a lot of things to absorb and configure them properly and so forth.”
For many, this response hints at one of the core issues we face with the Site Editor: understanding when a problem is a lack of education or an actual lack in functionality.
Matias clarified his thoughts, “I think that depending on the use cases, I would say yeah, the Site Editor is absolutely ready for some of those. For some others, I think like, yeah, you might not have all the right tools, or you might need to reach out to other plugins in the ecosystem to fill in the gaps.”
Over a year ago, the WordPress project announced the transition from Phase 2 (Customization) to Phase 3 (Collaboration), sparking concern that the Site Editor was going to be left not fully realized. What this Hallway Hangout made clear was that the Core Team is still very dedicated to working on these overlapping issues with the Site Editor.
They’re going to need all the help they can get, and the Outreach team certainly has their work cut out for them.
“I think the easiest way to get involved,” Fabian told me, “is to raise your hand and say, ‘Hey, I want to become a part of this team on GitHub’ so that you then receive those notifications in your inbox about features that are looking for more feedback. And then from there you can, at your own leisure, at whatever amount of time you have to dedicate it to open source, take a look at just the titles of those pull requests or read through the quick description if you have at that time.”
If you’re in the weeds of building WordPress websites and implementing new Block and Site Editor features, it can be hard to find the time to give feedback. I certainly have the tendency to go straight to social media when I’m struggling with a lack of functionality or an irritating choice in the user interface. That said, I’m invested in the future of WordPress as a platform, so I’m joining the #outreach channel in Slack and trying to provide feedback whenever I can.
While we may not immediately resolve these overlapping problems in the overall experience, the fact that there are core contributors willing to talk openly about the Site Editor’s shortcomings is a sign of progress towards a goal I think we can all agree on: the continued success of the WordPress project.
︎