tl;dr: The terms “full site editing” and “full site editor” (also abbreviated as FSE) were developed to easily refer to a collection of features and now that those features are integrated into our daily WordPress experience, how can we best update the wording to be more user friendly?
Not sure the difference between Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, full site editing, and other terms here? Check out this post for high level definitions.
What I know
Many years ago when we started referring to some of the work going into Gutenberg’s Customization phase (Phase 2) as “full site editing” it was meant to differentiate from the work that had come out of Phase 1. Phase 1’s work was focused on bringing blocks to posts and much of the page surrounding posts, but Phase 2 was meant to move those blocks to the rest of the site editing experience—hence “full site editing”.
There are some issues with the term “full site editing”, though.
- It was already possible to edit every part of a WordPress site using code. The term “full site editing” differentiated between phases of a project, rather than a new capability in the CMS.
- To us, “full site editing” implies the use of blocks, but for new users there’s no reason for them to expect anything else. The term isn’t descriptive of what makes it unique.
As we continue the move toward a full-featured, true WYSIWYG What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience for WordPressers of all skill levels, we should have a way to refer to it that is immediately meaningful for new users of our software, while also being an easy to reference term for all of us building and supporting the software.
What I see
There are a few existing conversations around renaming Full Site Editing (both from a UI User interface/UX User experience perspective as well as a development perspective). From what I have seen in my reading, there are two primary contexts from a big picture perspective: Users & Visitors of WordPress; Contributors & Extenders of WordPress. That leads me to think we have two primary use cases for terms as well.
- Users & Visitors of WordPress: I’ve heard a lot of people outside of the WordPress ecosystem simply referring to this as “the WordPress editor”. That seems mostly applicable to folks building with WordPress, selling on WordPress, or otherwise not creating the CMS itself.
- Contributors & Extenders of WordPress: I have primarily seen references to “the Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor” with the understanding that work toward Full Site Editing is a suite of tools from within the Block editor, a framework that originated in the Post Editor but is extending to all areas of WordPress like the Site Editor, hence most editing interfaces evolving into “the Block Editor”. This seems mostly applicable to folks working in Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., on Themes/Plugins, and by extension, also Training, Design, and Documentation.
What other contexts do you think we need to be aware of as we look toward making this more user friendly?
What I need
As with any audacious journey, one of the things that will hinder our success is not knowing what stands in our way. I would love it if you’d share your thoughts on the following questions!
- We’ve referred to it this way for a long time. How can we tackle renaming this together?
- It’s in the codebase. How will we make sure people who aren’t regular contributors see this?
- And repeating the in-line question from above: What other contexts do you think we need to be aware of as we look toward how to refer to our collective work in the future?