WordCamp Europe 2021 Report: Get Ready for Full-Site Editing!

WordCamp Europe 2021 just happened (June 7-9) and I am here to report that it was dominated by one topic: full-site editing. This was my fifth WordCamp Europe overall (read my other reports from 2016, 2017, 2019, and 2020) and the second one I attended online.

The decision to run WCEU 2021 online again was made shortly after the successful debut last year. It turned out to be the right one. Something that was new this year was that there was a dedicated online conference space. So, while anyone could follow the event on YouTube (find all recordings here), only ticket holders got access to the conference platform, based on Hubilo.

Here, besides watching the video tracks, you also had the ability to visit virtual sponsor booths and enter chatrooms to talk to presenters after their talks. You also had the ability to chat and set up meetings with other attendees, create your own schedule, and more. What was also new were scheduled talks from sponsors who discussed how they contribute and give back to the WordPress community and that contributor day happened during the entire event.

While I attended talks on various topics, the main thread of the conference was full-site editing, which will make its debut in the upcoming WordPress 5.8 release. Because that was such a central topic and in order to stay at least somewhere close to the word count that my editor would like me to, I will mainly focus on the presentations and discussion panels dealing with this topic.

Opening Remarks

This year’s conference leaders were Lesley Molecke and Jose Ramon Padron. They welcomed attendees to WordCamp Europe 2021 and gave everyone an introduction to the conference platform.

They also explained that the new setup was done in the hope of creating more connection between attendees and went over the features, conference format, and code of conduct. After that quick introduction, we went right into the first talks.

Building Great Experiences in the New Editor

The first presentation I attended was by Fabian Kägy, a senior front-end engineer at 10up. It dealt with how to build great editorial experiences in Gutenberg. This topic is mainly aimed at agencies/developers who create custom blocks and other tools that change how clients interact with the editor.

This kind of design process should be guided by two main questions:

1. Who are you optimizing for and what do they value most?
2. What can you do to improve their experience?

A good editorial experience means different things to different people. Therefore, you have to know who your target is. Based on on that, there might be different ways to achieve your outcome.

Overall, the goal is always to let the editor step into the background and get out of the way. Ideally, people shouldn’t think about it at all and just be able to focus on doing their work. For that, designers and developers can take control of both the design and the options available to make it fit the user and their requirements.

Principles for Building Blocks

There are some main principles for block building that apply across the board. For one, the main content part of a block is the most important. Users should be able manipulate their content here directly without needing to access the sidebar. A great way to achieve that is to adhere to the guidelines on block design in the Gutenberg handbook.

Some quick tips:

• Anything that isn’t a key control can be placed in the editing sidebar. Most users should not have to open the sidebar at all.
• All blocks should define sensible defaults and then give users the ability to edit them only if it makes sense.
• When you do use the sidebar, group settings into sections and put controls that are powerful but rarely used, in the Advanced section at the bottom.

Block States

In order to deliver a content experience close to the final outcome, it helps to think of blocks in three states.

Here’s how to optimize each state:

• Initial setup — You should not need this in most cases, use it as sparingly as possible. Instead, provide sensible defaults. Exception: A block that definitely needs a choice before it can be used, such as the cover block above.
• Active — You can see the main content, all tools and the toolbar available as well as other contextual controls, like a resize handle.
• Passive — When the block is no longer selected, it should be 1-to-1 representation of what the content will look like on site.

What Roles Do Themes Play?

The final of the presentation part was about what themes can do to help optimize the editorial experience. The main part is that you should make sure themes also represent what the site will look like on the front end in the editor. For example:

• Load front en styles in editor as well
• Make sure text shows the correct fonts, line-height, color, and spacing
• Set the content max-width the same as the front end

For best-in-class examples look to core blocks and themes, e.g. the block patterns in Twenty Twenty-One. And remember, the role of the editor is to make itself invisible so that users can focus on the content they want to share. By figuring out who you are optimizing for and what they are trying to achieve, you provide yourself guidelines along which you can make that happen.

Enhancing the Accessibility of a Plugin, A Use Case

One of the next important talks was by Rian Rietveld of Level Level, who is an accessibility consultant and trainer and Morgan Kay, a software engineer at Rocket Genius. The topic was how they went about updating Gravity Forms to enable users to create accessible web forms that are up to WCAG guidelines AA standard.

Testing the Status Quo

Rietveld was hired to consult on how to make the transition. The first thing she did was thoroughly test the plugin. That means, she went through all the controls, settings, combinations, etc. with the following tools:

• Keyboard — Because everything should work with the keyboard only.
• Browser inspector — Check the generated DOM if it is correct, but also the accessibility tree to see if all technology is present and correct.
• Screen readers — Make sure users with impaired vision get all the information they need
• axe devtools — A tool that can give you an accessibility report on any webpage.
• validator.w3.org — Lets you validate HTML5 and check for errors and warnings.

Some of the results were that the plugin could use better feedback for errors and when changes happen, especially dynamic changes. From here, Rocket Genius took Rietveld’s reports, created JIRA issues, and started thinking of solutions.

Implementing the Changes

While trying to make the plugin more accessible, which required users to update it, the team ran into three main issues:

• Backwards compatibility — They didn’t want to break existing forms. One big hurdle here was the multi-select tool, which was impossible to use with just a keyboard. They first thought of getting rid of it, but in the end, added a warning label for users that this element is not accessibility friendly.
• Flexibility — Forms need to work no matter what users try to do. One issue here were validation messages that are important for accessibility but can look silly on forms with very few fields. Here, Rocket Genius opted to give an option to turn them on and off.
• Support and customer expectations — You need to make the change/update easy for users so as not to overload them or the support team. For example, it is recommended that form labels are positioned above input fields. However, Gravity Forms has always placed labels below the fields, which they left as is to adhere to user expectations.

One of the most important steps when making a change like this turned out to be user communication. Besides providing the functionality, you also need to teach users how to use it to make forms accessible.

For one, that means preparing the support team, making sure they are knowledgeable in this area and can help customers. Other tools they used were inline messages and writing a lot of online documentation. The latter included the following:

• A commitment to accessibility, aiming for forms to comply to the WCAG standard.
• Accessibility guides for different user groups, such as designers, developers, etc.
• An overview of inline accessibility warnings and what they mean.
• Accessibility checklists to help people to set up their forms right.

Lessons Learned

In the end, what did they learn through this whole process?

• Accessibility is important but it’s also important to not break things for the users.
• Accessibility implementation requires very careful thinking and planning.
• You need to get the whole team on board and motivated. An expert can provide guidance but the development team needs to know the basics to implement them.
• It definitely makes sense to get expert help or even hire someone in-house. Accessibility is a specialized field that is hard for developers to also be experts in.
• You need to help users with documentation, implement accessible defaults, train your team, and provide support.
• Also, accessibility is never done. Any new features will also need it. In addition, guidelines change over time, so it’s an ongoing process.

The whole audit and implementation took about a year and is still continuing. But, they ended up with a better product that everyone can now make accessible forms with.

Discussion Panel: Full Site Editing

As mentioned earlier, WordCamp Europe 2021 revolved a lot around full-site editing, which is part of the next phase of Gutenberg. One of the big presentations on this topic was a discussion panel in which organizers Lesley and Jose posed questions to a number of WordPress and Gutenberg contributors, namely Milana Cap, Grzegorz Ziolkowski, Danielle Zarcaro, Koen Van den Wijngaert.

You will find the cliff notes below but it’s worth watching the whole thing, which you can do here.

What is full-site editing (FSE) what problem does it solve?

First of all, it’s important to note that full-site editing is not a big monolithic heap but a collection of many features that are part of second phase of the Gutenberg roadmap. One of the main benefits is that they give the user one unique workflow to edit everything.

Right now, WordPress is using different options to edit different parts of your site. Full-site editing is trying solve having to know all these different systems and instead provide one single way to make site changes. In addition, it lets you see how these changes will look like on the front end.

The goal is to give more freedom, power, and agency to the end user. It also streamlines the editing process.

What about existing sites? Will they suffer?

WordPress always aims for backward compatibility, full-site editing included. In addition, WordPress 5.8 won’t even come with every full-site editing feature yet.

As mentioned, FSE is a collection of features that won’t be turned on all at once at update. You can go part by part in rebuilding your site and preparing it for the new editing experience.

In addition, you need a full-site editing-capable theme and not all features will be available for non-FSE themes. Finally, you will have controls to switch things on and off and opt in/opt out of features. So, existing sites should be fine.

Why put full-site editing into Core instead of a plugin to let users choose if they want it?

FSE is an expansion of Gutenberg so leaving it out of Core is a bit like going halfway. WordPress already includes the blocks and the structure. With full-site editing, it will just expand to other parts of it.

In addition, there is a danger that nobody is going to use it if you make it optional. At some point you have to embrace the tool that you are using and go with the tide. This was the plan from the very beginning and WordPress has been taking steps toward that goal for a long while.

Plus, there are benefits to standardize the method of editing your site. For example, when changing themes, you never know whether the new one will have the capabilities you want, like changing the header, footer, etc. With FSE, you know that you will always have that ability. That also means WordPress will be easier to learn.

To make the transition as easy as possible, there are milestones for a gradual adoption and the teams are also making sure to have all necessary documentation in place. If all else fails, users still have ways to go back if they want to.

What will be the role of page builder plugins after FSE is introduced?

That’s a bit up to them. It’s actually page builder plugins that pushed the envelope and got WordPress to this point. By now, their makers have probably already looked into how they can integrate into the new paradigm and innovate.

The hope is that they will find other ways to extend WordPress, grow along with the changes and branch out in different directions. The question is, how they will add things on top of the new functionality.

A Walkthrough of Full Site Editing

As an extension to the above, on the second day, Herb Miller gave an overview of what full-site editing will look like and its capabilities. In case you don’t know, you can already try it out now with the Gutenberg plugin and an FSE-ready theme. We have a tutorial for that in our Twenty Twenty-One review.

For this presentation, it’s best if you just watch the video to see how it works (it will start at the correct time). It also has some resources how you can get involved with the FSE project.

What I found most impressive was how far it has already progressed and especially the template editor and query block as well as configuration options for theme defaults.

Discussion Panel: The Future of WordPress Themes

Right after the above, there was another debate with a knowledgeable panelists on how full-site editing will impact theme makers. This time, Ben Dwyer, Daisy Olsen, Imran Sayed, and Raitis Sevelis gave their input. Again, it’s best if you watch the whole thing, but I will try to summarize the most important points here.

How will the future change for theme companies?

First of all, themes can move back more towards providing design and away from providing functionality. This is a change that some companies will welcome and some will fear. However, they have a decision to make. It’s only a matter of time until customers will ask for full-site editing capabilities, so it’s only a question of when theme makers will adopt it. As mentioned earlier, it’s also possible for them to gradually adopt the new features and functionality.

One opportunity that FSE offers for theme companies is that they can create block-based themes. Furthermore, currently there are a lot of features in themes that should really be plugins. So, when themes go back to just being a design layer, companies have to rethink what they provide and how they can add value.

With FSE, the separation of design and content is more alive than ever. It also removes some of the complexity of theme switching and lowers the barrier for designers to enter the field. This might also mean that it will become easier for new theme authors to jump in. In the end, users don’t really care about themes but achieving a specific design.

Will companies try to compete with full-site editing or adopt it?

Gutenberg was first not adopted well but evolved and is now very accepted. Companies that are not yet using Gutenberg might switch when FSE comes around. It also doesn’t have to be a competitive relationship. They can take what WordPress offers and build on top. Plus, once again, full-site editing doesn’t have to be all or nothing.

One factor for the slow adoption of Gutenberg might have been that developers and extenders didn’t get enough time to try out the features before they hit the end users. The dev team is trying to do that differently for FSE and roll it in more slowly.

Overall, it would be a bit of a waste to build your own page builder when WordPress already provides this functionality. Therefore, the makers of full-site editing would rather see that people contribute to the existing model than compete with it. Again, the goal is for WordPress to lay a strong foundation that you can build on top of and improve. But, of course, you also have the freedom to build something else if you have a vision.

What will be the future of the big players in the page builder space?

Besides probably building on top of the existing infrastructure, it’s unlikely that page builders will become obsolete. They have existing users that probably won’t want to change their sites completely.

Here, it’s great that users can choose what they like. If a new product like FSE is better, existing companies will either join in and extend it or have to create something better. Same the other way around. Different products will still appeal to different user groups. Another example here is headless WordPress, which is also most appealing for certain user groups.

In short, a big change like this can also be a way to pushing things forward and a huge opportunity to find new business needs to solve.

A Conversation with Matt Mullenweg

One of the highlights of every WordCamp is talking to WordPress co-founder and CEO of Automattic, Matt Mullenweg. This year, it was split into two parts. The first was a presentation and discussion of new Gutenberg features together with Matias Ventura, Gutenberg project lead. This was followed by an interview with Brian Krogsgard, formerly of Post Status, a repeat of their conversation at WordCamp 2016.

News on Gutenberg

Matt and Matias started off with a short video of new things coming to Gutenberg in WordPress 5.8. You can see it below, including some experimental features that will come out even later.

After that, the two had a conversation about how Gutenberg developed and what it means for the WordPress ecosystem now. They also took some question from the audience.

Overall, it seems that 2020 was the time when people really started to see the initial vision of Gutenberg. With the arrival of full-site editing, it will help move WordPress to not only democratize publishing but designing as well. In Matt’s opinion, if you know Gutenberg well, this is just as valuable a skills as designing themes was a while ago.

For those who want to get fluent in it, block patterns are a great way to start tinkering and understand how everything fits together. Tip: open two screens, put a web design you like in one and try to recreate it in Gutenberg on the other.

There was also an important discussion about the accessibility of the new features and both of them stressed the ongoing commitment to improving it. Case in point, according to Matt, Gutenberg has had more accessibility work done than any other editor that is trying to do a similar thing.

For more questions, watch the video and also check the open thread on Matt’s blog for questions that they couldn’t get to for time reasons.

Interview With Brian Krogsgard

The interview went for about an hour, so I can’t include everything they talked about here. But I will try my best to summarize the important parts. Watch it for the full experience.

The Role of Open Source Products

Society at large still sees commercial commodities as better than open source products. However, commercial offers are built on economics of scarcity. Digitization and open source are based on economics of abundance, where the more people use something, the better it gets.

If the web is going to be the thing that drives humanity forward, the basis for that has to be open source because a commercial entity probably won’t do it. The greatest threat to that happening are greed and selfishness — people only acting in their own interest.

Ensuring the Longevity of WordPress

The most important factor for WordPress to continue growing is to maintain its culture. The community, working together as real people, is a huge factor in keeping it going. Getting back to in-person events is a huge factor for that but we should also try to figure out how we can open WordPress otherwise.

Growing as a community means giving back (for example, via the Five for the Future initiative), hashing out disagreements, experimenting, and learning from the past. Contributing to WordPress is like voting. You can choose what you work on and what you think is important. That way, WordPress becomes a reflection of what people most value.

A great way to achieve this would be to see more community plugins and collaboration on things that the community really wants. Plus, more commitment from the big players in the WordPress industry, for example, in the form of full-time people who work on Core. But not just engineering input is needed, other skills are also useful. For instance, it would be great to see people use their marketing expertise for WordPress as a whole.

Consolidation in the WordPress Sphere

In the past few years we have seen a lot of instances of bigger fish gobbling up smaller businesses. What does that mean for people who to be entrepreneurs in the WordPress sphere?

Here, it’s important to note that these exits are also opening up new possibilities. The alumnis from the companies that got bought up will move on to new things that can bring innovation. Plus, it also shows others that exiting from a WordPress company is a legitimate path.

However, again, this development is also a question of contribution. If you are only looking out for yourself but not the ecosystem, that’s not a long-term strategy. Competition is fine as long as there is also consideration about WordPress as a whole. Plus, contributing from the inside also makes it easier to find out where the opportunities are and capitalize on them.

There is a fear that Gutenberg and full-site editing will squeeze out middle-sized WordPress providers. However, the folks who are being squeezed out are those who don’t evolve. It’s all about leveraging the new tools and building on top of them. So, learn Gutenberg deeply. It will make you faster than building custom themes and you can produce delightful results for your customers.

Modernization of WordPress as a Whole

After the success of Gutenberg, should we overhaul the rest of the WordPress interface just like we did the editor? The answer is, probably not, at least not in the same way.

First of all, having two processes for composing vs administrating is not necessarily a bad idea. It creates a certain level of flexibility. Plus, changing your WordPress settings doesn’t have to happen in a React-powered interface. This was necessary for Gutenberg, because there was no other possibility. However, there are definitely paths for a more modern WordPress interface without necessarily changing the technology stack.

Finally, the need to administer in different places will also probably lessen when Gutenberg takes on more functionality.

Closing Remarks and Conclusion

With more than 3,200 registered users, 1,841 logged in at the same time, and attendees from 121 countries and 13 timezones, WordCamp Europe 2021 was definitely a success – despite being online only.

I also had a great time, though I am really looking forward to (hopefully) going back to an in-person convention next year. Sitting in front of a video stream is definitely not the same.

If you want to help organize next year’s event, you can do so here. If you are looking for other ways to contribute to WordPress (which is a great idea!), you can find resources here. Hope to see you at the next WordCamp Europe in Porto!

Did you attend WordCamp Europe 2021 online? What were your biggest takeaways? What are you most excited about? Share in the comments!