FSE: Finalizing the name and menu item placement

[aurooba]

As we get close to releasing FSE into core, questions have come up about what the feature will be officially called within the WordPress Dashboard.

This is also currently a blocker for the Documentation team (see more details in this post on Make). The sooner a decision is reached on the name, the sooner we can spin up proper documentation for it.

@mtias also mentioned that a discussion is needed around the placement of the menu item and how it interacts with the other items within Appearance sub menu.

Related issue: #29031

[hedgefield]

This is a good point! "Site editor" and "Full site editing" is a nice name and it's what we've been calling it for a while, but as @mtias rightfully pointed out, is it the most descriptive name for what this thing is? I've seen "Design editor" as an option, though reading about the discussion of where to place it in the menu, I'm thinking "Appearance editor" might also be a good name?

Even more interesting is how to structure the appearance menu. I assume we'd want to keep some of the current menu items for backwards compatibility? Otherwise a lot of those items would become obsolete, right. Maybe something like this:

I removed a few smaller items that were basically just links to parts of the Customizer, and renamed "Theme Editor" to "Theme files editor" so it doesn't sound as much like it might overlap in functionality with the appearance editor.

It's too bad there's no precedent for using dividers in submenus, otherwise I could also see something like this to separate new from old a bit more

[kellychoffman]

This is a great question.

@jameskoster and I have been doing some explorations around this and have a prototype to share to illustrate an idea for how a user will be exposed to the new features that have been built as part of full site editing. During development, these were all contained within a single menu item called Full Site Editing. Going forward, as @hedgefield mentioned above, we need to think about how these features will integrate seamlessly into the current navigation menu structure so that it can be intuitive for both new and existing users. Doing so will also allow for pieces of it to be turned on and off. (Theme compatibility being one example)

Instead of a top level menu item called Full Site Editing, the main features within are pulled out and placed within Appearance menu:

Try the prototype.

A 3.5 minute video walking through the prototype.

about what the feature will be officially called

Back to the original question. This proposes that we call each feature what will be most familiar to the user. So, instead of "Full site editing" we refer to each one individually. ie, Styles, Templates, Header, Navigation (to start) and more that will be added as work continues on all other aspects a user needs to do to create, edit, and manage their site.

[hedgefield]

This is excellent! Thanks for the exploration 👏

[paaljoachim]

This looks very interesting! Nice work!

NB! The above user interface is meant to be seen when a Block theme is activated!

Discussions with James on Slack starting here: https://wordpress.slack.com/archives/C02S78ZAL/p1617267435267900

Some conclusions I have reached through discussions (before I have seen the above video and tested the prototype as I want to understand the concepts before testing.)

We have these links under Appearance:
Themes - Leads to Themes screen.
Styles - Leads to Global Styles.
Header (will show up if the theme has a defined Header FSE area.)
Footer (If a Footer area has been defined a Footer link will also show up.)
Templates
(Manage templates screen. Here one can manage the full site template that is in use. I do believe we might need a common manage screen for Template parts, Reusable blocks, Patterns etc. These can/should also be managed inside Gutenberg in a modal or in an isolated view. As one is working on the site one would like to stay within the Gutenberg screen without leaving it.)
Navigation

NB! It needs to be simple for an everyday user to add back the Customizer, Widgets screens and Theme Editor (through the UI not just code.) As many users have been taught specific work flows and will not know how to handle the brand new experience. Having a simple way to add back work flow tools/screens is very important.

EDIT.
It would be helpful to be able to tie in the Gutenberg experience user interface UX etc into the Styles/Header/Template views. At the moment it feels too removed from a familier Gutenberg experience. Having familiar UX elements clearly seen will help the user feel more comfortable.

[azhiya]

Whilst the accessibility team hasn't reviewed the prototype, we agreed that this makes sense to us. We decided to review the prototype and comment if we see it being an issue.

[paaljoachim]

I am bringing up this issue during a design triage. As James and I had a discussion about this issue in the design channel. I am circling back to it. One thing that comes to mind is that the Appearance menu can contain various template areas and more.
Default to show would likely be Header and a Footer. Then based on what the user adds additional areas might show up.

Here is a ticket where @OGlekler suggests adding Reusable blocks to the Appearance menu.
https://core.trac.wordpress.org/ticket/51534

One hesitation I have.
The Appearance menu can end up with a lot of different Template areas, Reusable blocks, Patterns etc. Making the list fairly long. Making it hard to have a good overview.

[jameskoster]

One thing Kelly and I didn't find a solution for yet was where to place general template parts. We had one idea to reuse the "Widgets" menu label since there is some conceptual overlap there – a widget is very similar to a general template part in its purpose. Another option could be to group them with top level templates somehow.

Personally I'm not a fan of putting the Reusable Blocks item in the Appearance menu. One of the defining characteristics of a Reusable Block versus something like a Template Part (or a pattern) is that its intended use is for displaying specific content. It's already easy for folks to confuse these two (three) features... and putting them in the same menu area probably isn't going to help matters.

[jameskoster]

Distilling this down in to actionable tasks:

• Remove top level "Site Editor" menu item from the wp-admin navigation
• If a single block template part assigned to the header area exists, add a "Header" menu item under Appearance which links to the isolated editing view for this template part.
• If multiple block template parts exist that are assigned to the header area add a "Headers" menu item under Appearance which links to a filtered view of the template parts post type list that only displays Headers.
• Apply the same logic from the two previous points to footers.
• Update the "Templates" link under appearance to link to the mosaic view of templates (Mosaic View of Theme Templates #20477) when built
• Add a "Styles" link under Appearance which links to the mosaic view of templates with the global styles sidebar opened
• Add a "Widgets" link under Appearance which links to a filtered view of the template parts post type list that only displays General template parts. "Widgets" label needs design :)

Unsure if these need to be separate issues.

Overall this issue is currently blocked by #20477.

[carolinan]

I think repurposing the term widgets is a bad idea that will only cause more confusion.
If nothing else, consider how this will effect support when you are trying to describe and solve an issue.

[carolinan]

Also I feel strongly that these UX discussions should be public and not in private discussions.
So when available please provide links to Figma and public slack discussions.

I am asking this because this does affect what issues and pull requests to prioritize, as any fixes to specific areas will be short term and may just be a waste of our time.

[kellychoffman]

Also I feel strongly that these UX discussions should be public and not in private discussions.
So when available please provide links to Figma and public slack discussions.

Agree. All links to Figma and discussions are in the comments above. One missing is a conversation that was started yesterday in Slack to discuss #29630 (comment): https://wordpress.slack.com/archives/C02S78ZAL/p1617963102014400

[celloexpressions]

The features in FSE currently live together in a “site editor.” As #30496 explores, this interface is not a full replacement for the customizer yet. That issue proposes a few potential paths forward, each of which would impact the admin menu structure. A decision should likely be made on that issue before the menu approach is finalized.

There is discussion in #26012 about potentially consolidating the widgets and menus/navigation screens into the customizer. The “header” and “background” appearance sub-menus already function as deep links into the customizer (since 2014). Global styles would fit well into the customizer with its current sidebar-based UI. If template editing (the primary feature in the current site editor) also becomes accessible through the customizer (approach 2 proposed in #30496), then everything could live in a unified interface regardless of the level of theme support for blocks.

“Appearance” doesn’t seem like the right container for the site editing features. It implies styling options more than layout and template part content editing. Is there a better word? “Customize” might actually work—it implies optional and gradual editing from a default state (for both styles and templates) as a primary distinction from post and page content editing. We could end up with something like this in WP admin and in the customizer:

[aristath]

My 2c would be to leave the customizer out of it...
Personal opinion follows:

The site-editor is not a replacement for the customizer, nor is global-styles. They are just different interfaces, for different scenarios and use-cases. The fact that we have a UI in the customizer for editing some options doesn't mean that everything should be in there... not when we now have a UI that fits better with the vision of where WP is headed.
The customizer had a good run. It served its purpose for years, but it feels inconsistent with where the ecosystem is heading.
It can still be used by classic themes, but there's no reason to force it in FSE; not when we have better options. Other than force-of-habit for existing users, there is no benefit to new users.
Things should be allowed to come to an end naturally and not dragged on for years impeding progress in other areas. At this point in time with FSE, the customizer feels more like a hindrance, something we need to take into account to make sure things don't break. It doesn't feel to me like a home worth building on.

[jameskoster]

I think repurposing the term widgets is a bad idea that will only cause more confusion.
If nothing else, consider how this will effect support when you are trying to describe and solve an issue.

That's a good point.

I'm hesitant to throw another name in to the mix since we already have so many, but it is perhaps unavoidable. Even if we combined general template parts with top level (index etc) templates, a label would still be required in order to provide any kind of filtering.

Thinking semantically, something like "Template Sections" (or just "Sections") might work?

The HTML <section> element represents a generic standalone section of a document, which doesn't have a more specific semantic element to represent it.
– developer.mozilla.org

In this case the "more specific semantic element[s]" would be Headers, Footer, Sidebars, and any other template part areas we add in the future. It helps that "Section" is a fairly user-friendly term in this context.

Other options:

• Segments 🍫
• Pieces 🧩
• Modules ⚙️
• Parts 🙈

---

“Appearance” doesn’t seem like the right container for the site editing features.

I think there may be a discussion to be had there, but probably in a separate issue once the changes here are implemented.

[carolinan]

I'd love to see different visual flow charts of how users would get from step A-Z. I think for me that would make it easier to see where we might run into problems with current and proposed flows.

[carolinan]

There are so many things to consider. There already is a header menu item that takes users to the customizer. What happens when a hybrid theme, that has support for both, is installed? Would there be two header menu items in different positions?

[aristath]

There already is a header menu item that takes users to the customizer. What happens when a hybrid theme, that has support for both, is installed? Would there be two header menu items in different positions?

I assume it would depend on what kind of hybrid theme it is... because the term hybrid can encompass lots of things.
If it is hybrid in the sense that it uses a block-based template for the header/footer as per #30345, then it would take them to the template-part editor and not the customizer

[jameskoster]

I'd love to see different visual flow charts of how users would get from step A-Z.

Which flows in particular are you thinking of? I'm happy to work on more mockups :)

[carolinan]

All of them 😆

I thought the new navigation screen was meant for classic, not block themes, but I see it in the screenshot above.

This is going to be another rant, but all I want is to understand better.

• The benefit of having isolated views of the header and footer template part is that the UI can be less overwhelming.
  Is this the main reason why header would need to be its own menu item?

• The downside to having isolated views of the header and footer template parts is that it is more difficult to see what the full page/site will look like.

Does it make sense to call these template parts at all?
If these two are handled differently, then where do other template parts go?
As a theme developer I want to use template parts to make sure I don't need to repeat code. So, any area that may be the same on different templates. Sidebar, main (query goes here), post meta (author, date, category), comment area...

I wonder if Templates need to be it's own parent menu item not under appearance, site, etc. Maybe templates is the main menu and header, footer and template parts/areas are the sub menus.

[jameskoster]

I thought the new navigation screen was meant for classic, not block themes, but I see it in the screenshot above.

I don't think that's the case? The navigation screen remains a place to manage all your navigation menus in one place. Whether those menus are block-based or not will depend on your theme etc.

Is this the main reason why header would need to be its own menu item?

That is the primary reason, yes. We're also perpetuating a historical menu item. "Appearance > Header" has always taken you to a view where you can customise your site header. So going back to your documentation point from before there would appear to be some value in keeping this.

If these two are handled differently, then where do other template parts go?

This is the discussion we had just a few comments above. "Widgets" was one option, others options are "Sections", etc. "Template Parts" is perhaps a bit too technical for the average user.

templates is the main menu and header, footer and template parts/areas are the sub menus.

This is a perfect example of the sort of thing we'll be able to do with the drill-down menu system that already exists in the site editor. Until then I would argue that templates still fit inside "Appearance".

[noisysocks]

Are we able to implement the rest of the design by Friday?

[jameskoster]

(Since this design is new and we are in a time crunch, we can fall back to the current wp-admin-style list view.)

Is it technically feasible to do this, but retain the Editor navigation? Something like:

Otherwise the UX may feel awkward as you dip in and out of wp-admin.

I opened several issues and a couple of PRs relating to this view last week:

• Use template editing mode when editing a template via Appearance > Templates #35990
• Refine the add-template flow in Appearance > Templates #35991
• Update Appearance > Templates to list all templates #35994
• Refine columns in Appearance > Templates #35995
• Remove slug and status columns from templates list in Appearance > Templates #35996
• Remove bulk actions for templates #35997

[kevin940726]

If you open the W menu again and click on Templates, you’ll view a list of all the templates you can now edit visually. (Since this design is new and we are in a time crunch, we can fall back to the current wp-admin-style list view.)

I wonder why we want to keep the editor interface (the header with undo/redo buttons and the inspector etc) in this screen? Should this be a new path in the url, or should we implement it in a modal/popup style?

[jameskoster]

I wonder why we want to keep the editor interface (the header with undo/redo buttons and the inspector etc) in this screen?

Apologies, that is an oversight. Initially I think we should keep the top bar in this view very simple:

The "Add new" button should expose a popover, effectively behaving the same as this affordance in the current site editor navigation:

Should this be a new path in the url, or should we implement it in a modal/popup style?

Good question. Since this screen is accessed via navigation menu item, a unique url seems appropriate?

[kevin940726]

Makes sense to me! Do we have a preferred unique path for this screen yet? I feel like ideally we should make this into a semi-SPA style editor, that is, use history API to navigate between screens. However, I don't think we have enough time before the beta though 😅 .

Even if we could fallback to wp-admin-style list view, I'm not so sure how that could be implemented along side the new W menu sidebar. (Maybe I'm just not experienced with this part though, could use some helps from PHP experts?)

What would be the absolute minimal that we should definitely do before the feature freeze? Leave it as is? Or should we implement the new W menu but the links point directly to the current wp_admin templates list (/wp-admin/edit.php?post_type=wp_template)? Given the limited time, I think we should do it step-by-step so that we can improve it gradually.

One more question: what does the "Styles" menu item suppose to link to? Should it just open the Styles sidebar? What if the Styles sidebar is already opened? What should it do when the users are in the templates(-parts) list view?

[talldan]

BTW, there's a plan to add a 'Navigation Menus' menu item under Appearance in #36126.

It wouldn't be possible to edit these menus right away, but a way to manage them (rename, delete) is still valuable.

[jameskoster]

More good questions @kevin940726.

Falling back to the wp-admin templates list view feels like a poor navigational experience to me. I put a prototype together here to test it and would be interested to hear feedback on that.

Handling the Styles menu item is tricky. One option would be to have that menu item behave identically to the toggle in the top bar. Whatever we do here is going to feel sub-optimal to some extent since the interaction isn't navigational despite its position in the UI suggesting that it is. You can try this in the prototype above as well.

---

These two quirks make me wonder if an even simpler MVP would be to simply remove the navigation in the site editor altogether to begin with, and put links to Templates and Styles in the Appearance menu. I made a prototype for this one too.

[kevin940726]

These two quirks make me wonder if an even simpler MVP would be to simply remove the navigation in the site editor altogether to begin with, and put links to Templates and Styles in the Appearance menu. I made a prototype for this one too.

I personally like this more as a MVP, the UX feels more natural than the others. We can implement this first, and take our time implementing the new screen in #29630 (comment) later. Not sure if the new screen would make it to 5.9 though. WDYT?

[jameskoster]

I think that makes sense, but would like to hear @kellychoffman's input.

[kellychoffman]

My take: Let's move forward with this option.

I think it comes with some trade-offs that are inherent with the current wp-admin nav menu, but it feels like the best option that will allow us to move forward and provides a base to work from.

We can always approach introducing the W menu in future releases if it makes sense. It will give us time to rethink and rework the nav overall.

[jameskoster]

With #36064 merged I think we can close this particular issue.

There's still lots to do of course, but we've opened other issues that will execute the design outlined in #29630 (comment) (and subsequent discussion).

[kellychoffman]

@jameskoster: In light of PR #36379, and the confusing nature of the nav structure as is (see image below), I'm wondering if we should reconsider something closer to this approach: #29630 (comment). (The reason we originally removed the W menu, was because this was not possible.)

Overwhelming, confusing nav structure:

[jameskoster]

Certainly, when #36379 is merged the Styles, Templates, and Template Parts links move from the Appearance menu in wp-admin to the W menu in the editor.

This was always the North Star, but it wasn't clear whether or not we could get it done in time for 5.9.