I would love for us all to almost stop using the term “Full Site Editing” in 2022. That’s not to swap for “site editing” or another term, but to start calling each separate piece what it is. You see, when many say that term, they are joining functionality together that absolutely can add up to a powerful site editor, but can also work apart, independent and separate.
The features
I am aware this is my take on this, so be ready for a very personal opinion and view here as to what the features of site editing are:
- Actual site editing: typically the type you’d need a block-based theme to activate as of beta
- Block-based themes
- Global styles: the interface shown
- Theme.json: yes, I separate these from global styles because global styles are shown in site editing, although a ‘by block’ theme.json interface is exposed in the editor.
- Template-parts and templates: these typically go into block-based themes but deserve their section
- Site editing specific blocks
- Block widgets and navigation
- Design tools
Taking the slower path of adoption
Instead of treating Full Site Editing as an “all or nothing” proposition, there is an option for a more gradual path. The slow path of adoption has a lot of benefits, mainly if you work with clients, and it allows you to gradually consider each feature per project. By taking this slower path, you gain learning, discovery, and the client’s education – onboarding and knowledge are never just for you.
Anne McCarthy writes in her post about approaches to FSE adoption. She proposes a little more in-depth path than the one I am going to look at today. In it, she looks at a wide range of features scaling up to site editing.
Having a scale makes a lot of sense; however, focusing on “today” is a real issue. Some things can be used in production and others, well there might not be the budget, appetite or simply opportunity to do. You might find yourself working with a legacy code mountain, or you might find yourself in a tight corner of production costs. You even might find you have to prove the worth of this new approach to stakeholders. Whatever the reason, the ideal is typically far from reality. Some things are ready to use now and others might not be depending on the project.
The path now
There are many paths you could take with site editing. So many that it can seem overwhelming, even for someone new. Let’s start framing this away from using it all to what features you can use today and start implementing those. When reframing, it typically simmers down to two critical components of block patterns and theme.json.
Block Patterns
I’ve written previously about the power of these and how you can take patterns right now from the library in Extendify, for example. You can use this today and you don’t need to worry about compatibility issues beyond what blocks are in the patterns. Patterns are due this year to see a lot more focus across usability and make this essential feature a whole lot easier to use.
Theme.json
A tutorial for theme.json can be confusing and lengthy. In reality, you can use a color palette and font family, nothing more. Like features, use what works and don’t use what is uncomfortable now.
Consider theme.json as something to grow into. If you are adding it to your development practice, perhaps you go light at the start and lean still on SASS. As you have time between client work and confidence, lightly move over piece by piece. If you create a new theme, consider using it from the start, but gradual support also works to keep to that budget.
The gradual path of the rest
On purpose, I have not included a lot of features, from block widgets to navigation and a lot of things typically you’d find in a theme. My best advice to anyone looking to start on this journey right now is to start with patterns, move to theme.json, and from there, gradually move through whatever makes sense for you. Your path will likely change based on using a framework, base theme, and projects you are working on. That’s ok, that’s your work, so it should be the case.
Your path will probably continue after patterns and Theme.json by moving to blocks for as many use cases as possible, including widgets. As time moves on, you’ll probably grow very comfortable in the space with block styles and some custom block functionality. Site editing is moving quickly, so other features might feel more like something you can try to be ready for production later in the year. This path will be very personal, and I would strongly recommend it’s one of experimentation.
This year is for exploring
This year’s theme should be exploration. There needs to be time given to those working on site editing itself and exploring the best options there for what could be. Also, those working with clients need time to gradually explore the space outside of that work, which is why it needs at least a year to come to fruition.
The toolkit of site editing
Think of it as a toolkit when you hear the term site editing. What in that toolkit do you want to use today? What fits your purpose? What do you want to learn? What do you want to start using at what point across the coming year? If you begin framing it like that, it will make planning things a whole lot easier and discovering all the incredible tools and possibilities more accessible.