Last Week @kellychoffman and I shared some concepts that explored how we might introduce some of the powerful site editing features in the Gutenberg plugin to WordPress core.
To briefly recap, the first concept brought template, style, and content editing together under a single “Editor” menu item in the Appearance section of the main navigation. The second concept kept these features separate, and leaned more on existing wp-admin views to access some of them.
In this post I am sharing a stress-test that I’ve performed on both concepts, to see how they handle complex plugins that add custom post types. For this test I used WooCommerce and focussed on it’s product post type. The aim here is to further distill each approach and hopefully find consensus around which one to pursue for 5.9.
Since styles are a feature that transcends content and template, I’ll be focussing on editing the latter. I’ll demonstrate the hypothetical flows to edit individual products, and to edit the template that is used to display those products.
For the purpose of this test we’ll assume that WooCommerce fully supports block templates and the block editor.
TLDR: Due to the “Separate” concept leaning more on existing wp-admin list views it will require less work to implement, and less effort for plugin developers to adopt. It will also be less disruptive to existing user flows when working with custom post types.
“Combined” concept
In this concept clicking “Editor” in the Appearance menu takes you to a view where you’re able to edit the homepage of your site. From here clicking the W menu will open the navigation where you will see a new “Products” section has been added. Clicking this takes you to a product list view inside the Editor:
Clicking a product will take you to the editor view for that product, where you are able to modify the product data, the product template, and elements like the site header and footer all at the same time.
To then go and edit the product template on its own, you once again open the W menu, navigate to templates and find the two new templates that WooCommerce added: “Single Product” and “Product Archive”. Clicking “Single Product” takes you to a view where you’re able to edit that template.
“Separate” concept
In this concept product management is accessed in the same way it always has been – at the top level of the wp-admin navigation. Even the list view behaves the same. However, opening a product takes you to an editor view where you’re able to toggle the visibility of the entire layout in order to visually edit other product data, or even elements of the underlying template.
Of course in an example like this – where the post type in question is so visually reliant on the template – it may make sense for WooCommerce to make the layout visible as a default for product editing. Or perhaps even force it to be permanently visible by removing the option to toggle the layout visibility. This is a detail we should consider making available to plugin authors during implementation if we choose this concept.
On that note, there’s a balance to be struck around where we draw the lines between content and template editing, so we should explore contextually locking certain blocks. For example: here it should be trivial to change the featured image source, but moving it around or changing the dimensions should be either one step removed, or alert the user that they are making a template-level change.
To explicitly edit the product template you exit the edit-product view and navigate to Appearance > Templates. Just like in the last concept, here you’d find the two new templates added by the WooCommerce plugin, and you are able to go and edit one by clicking on it. As in the current post editing experience, clicking the W button simply takes you back to the Template list.
Observations
The thing that stands out most to me is the duplication that occurs in the “Combined” concept. There are effectively two places for users to manage post types – either via the existing top level “Posts” and “Products” menus they’re familiar with, or via the new Editor menu. This increases the workload on plugin authors as they need to consider both potential workflows and it also places additional cognitive load on the end user since they will need to actively choose an interface each time they want to manage things like posts and products.
Any flows accessed from list views such as trash management and bulk editing may also end up being duplicated.
All of this will be compounded when you add more plugins/post types, and given that different plugin authors would adopt these new features at different paces, the user experience could grow increasingly inconsistent.
Another consideration is the many plugins that currently extend the existing list views. With the duplication of those views in the “Combined” approach, many of those plugins would need to be updated to support both versions. APIs can probably do much of the heavy lifting here, but ultimately this would slow down adoption of these new features as it will take plugin authors time to adapt. Users may also prefer to stick to their “tried and true” methods. Those that choose to embrace the new views could find themselves in an awkward spot if the one plugin they rely on doesn’t support them yet.
The “Separate” concept addresses each of these shortfalls by simply relying on the existing post type list views in wp-admin. The flows in which users manage all post types remain the same, and whether they get a richer block-based editing experience is solely down to whether or not the plugin has chosen to adopt these new technologies. It gives us the time to concentrate on updating the list views in isolation at a later date. Due to this, I tend to lean more towards this approach as it feels like a much smaller step with arguably equal impact, but I’m keen to hear more thoughts and feedback from y’all.
What’s next
After digesting feedback we’ll hopefully agree on how to move forwards for 5.9. From there we can open a tracking issue on github to work through the necessary outstanding issues and explore finer design details.