Gutenberg: Site Editing: Expose the template and template part names in the top bar.

[shaunandrews]

There's an ongoing discussion in https://github.com/WordPress/gutenberg/issues/20877 around moving document settings into the top bar. As it continues to progress, I think we could focus on _at least_ showing the current template's name and, if selected, the current template part's name. Here's a quick GIF showing the feature:

The current document title (in this scenario, I'm editing the page template) displays in the center of the Top Bar. As I hover over template parts their name is displayed in the Top Bar as well.

Selecting a template part or any child block within causes the template part name to display.

[olaolusoga]

not in love with label in topbar changing on hover; the label jumping positions because of re-centering feel unbalanced. Overall, do like the breadcrumb in topbar. Which leads to the question: Does the topbar label need to change during hover? Can we use something similar to navigation mode to show a border around the template part a person hovers over? And then the GIF has 3 steps: hover>select>edit, can it be reduced to hover>edit?

[ZebulanStanphill]

This looks like a sort of "status bar" type thing. And if we're going to have something like that, it does _not_ belong in the middle of a toolbar. Toolbars are for tools (or in other words, controls), not status info. Stuffing stuff in a toolbar that doesn't belong there is bad for accessibility. Perhaps such a status bar could be shown to the left, to the right, above, or below the top toolbar. But it definitely does not belong in the middle of it.

[ZebulanStanphill]

Additionally, the slash would probably be confusing to a screen reader... actually, I think it's kind of confusing in general. I think a colon would be more appropriate, e.g. "Template Part: Header".

Pinging @afercia to check this out, since he knows far more than I do about this sort of thing.

[StefanXhunga]

Thank You for your assistance!

[mapk]

Toolbars are for tools (or in other words, controls), not status info. Stuffing stuff in a toolbar that doesn't belong there is bad for accessibility.

This can be argued. 😉 @enriquesanchez pointed out in today's triage in Slack, that only the left-side controls in this bar are marked as role=toolbar. The site-icon on the far left side isn't a control or tool that affects the editor and is much like a piece informing which site one is on. AND thirdly, this particular template/template-part indicator in the middle might very well become a sort of control including the document settings (https://github.com/WordPress/gutenberg/issues/20877).

[enriquesanchez]

I don't see a problem with having this kind of info in the topbar region, and I think its placement and visual prominence improve the hierarchy model of the editor.

While we refer to it as the "top toolbar", the whole area is marked up as a region and has an aria-label="Editor top bar". It's not technically a toolbar.

Only the options to the left, called "Document tools", are marked up as role="toolbar".

The options to the right are independent and do not carry any particular toolbar semantics.

[shaunandrews]

Toolbars are for tools (or in other words, controls), not status info. Stuffing stuff in a toolbar that doesn't belong there is bad for accessibility. Perhaps such a status bar could be shown to the left, to the right, above, or below the top toolbar. But it definitely does not belong in the middle of it.

I'm not following the logic here; If it was shown on the left or the right it would be ok, but not in the middle? Here's a quick visual to explain my thinking around this logic:

--

What they said ^

[ZebulanStanphill]

Fair enough. I wasn't aware the top bar wasn't a single toolbar. It does make me wonder why it is laid out the way it is. Why are plugin sidebars all on the right side? What do the publish/save controls have to do with anything in the ellipsis menu? But I suppose that's a separate topic to discuss.

I do still think that if we're going to show the template name as a static thing, it should come before any controls. Semantically, it would make sense as an <h1>, wouldn't it? Currently, the block editor doesn't have a visible heading, which I think is an a11y regression from the classic editor that has yet to be addressed. This could be an opportunity to give the block editor a proper heading, and semantically, a heading should come before the content it refers to.

I've noticed some recent Widgets screen mockups put a "Widgets" heading to the left of the top-left toolbar. See #24937. Why not make it consistent across instances of the block editor and do the same thing here?

[shaunandrews]

I do still think that if we're going to show the template name as a static thing, it should come before any controls.

In this design, the length of the element changes based on what's selected; When you select a template part it's name appears:

If we were to put this to the left of the first toolbar it would affect the overall layout as you select different template parts; This movement would be jarring and draw unnecessary attention.

--

Semantically, it would make sense as an <h1>, wouldn't it?

I think something more like "Edit" or "Editing: About Page" might be more appropriate for an h1 — it's likely unrelated to the document and template part labels proposed in this issue.

[ZebulanStanphill]

Oh, right. Sorry, I forgot this is meant to show the title of the currently-selected template part. In that case, doesn't the breadcrumb bar already exist for similar use-cases? Why not just use that?

[noahtallen]

In that case, doesn't the breadcrumb bar already exist for similar use-cases?

I'm thinking about this as distinguishing between editing different entities vs. plain blocks. For example, when I edit a paragraph in a template part, this design would still say "Header," indicating that I am editing that specific entity. This is different than the breadcrumb, which just shows the selected block.

Another challenge with the breadcrumb is that it is not very visible (despite being visible all the time!), so (anecdotally) lots of people don't use it or know about it. 🤔

[afercia]

Additionally, the slash would probably be confusing to a screen reader... actually, I think it's kind of confusing in general. I think a colon would be more appropriate,

Thanks for the ping. Yep, generally a slash would be announced while the colon would only make a screen reader make a brief pause, which I think is better.

There are more important issues though.

This screen, like the Widgets and Navigation ones, needs a visible main H1 heading to identify _what_ it's about. The H1 needs to be the first thing in the main content area, before anything else

The template and template part names could be the H1 but yes, they change dynamically and their length varies. Also, they don't fully tell the "what": edit template: template part? view template: template part? What users can do in this page?

Technically, it is correct that only the controls on the left are an ARIA toolbar so the template / template part names can be placed in the middle of the top bar but what they would be from a semantical perspective? How can they be represented semantically? A H2 maybe? Certainly not a div.

From a layout perspective, I'd like to see how the template / template part names would look like on small screens (mobile) especially when their names may be very long. I'm not sure they would fit in the available space, which is the real reason why I have doubts the top bar is the right place for them.

this particular template/template-part indicator in the middle might very well become a sort of control including the document settings (#20877).

No, please 🙂 As said countless times, interactive controls need to be labelled with their available action: _what_ they do. Instead, the template / template part names are values (or the state of the current selected template) that need to be communicated separately from the control name.

I do still think that if we're going to show the template name as a static thing, it should come before any controls. Semantically, it would make sense as an <h1>, wouldn't it?

Maybe. It would be better than what it is now but as I said above I'm not sure that would be the ideal way to communicate _what_ this page is about and _what_ users can do in this page. To make a couple clear examples:

• in the edit user page, the H1 is: "Edit user Bob" and it's not just "Bob"
• in the Classic Editor page, the H1 is "Edit Post" and it's not "Hello World"

[ZebulanStanphill]

@noahtallen

Another challenge with the breadcrumb is that it is not very visible (despite being visible all the time!), so (anecdotally) lots of people don't use it or know about it. thinking

So why not just make the footer bar more prominent somehow? One simple change to do so would be to increase its font size. From what I've read online, 16px is generally considered a good minimum font size, but our footer bar only uses 13px.

References:

• https://accessibleweb.com/question-answer/minimum-font-size/
• https://uxtricks.design/blogs/ux-design/accessibility/

That said, I get the feeling that we're going about this problem the wrong way. Is a status bar (regardless of whether it's at the top of the bottom) really the answer here? Perhaps we ought to indicate the current template part within the content area itself. Perhaps the template part that is being edited should show its title in a way similar to how reusable blocks show their title?

@afercia Following the existing pattern, then, I guess "Edit Template" would make the most sense for an h1 on this screen.

[ZebulanStanphill]

I suppose I should also mention that removing the footer bar entirely has also been brought up a few times, since List View and Select/Navigation mode together fulfill more or less the same purposes.

[noahtallen]

Perhaps we ought to indicate the current template part within the content area itself. Perhaps the template part that is being edited should show its title in a way similar to how reusable blocks show their title?

I'm totally with you! In fact, we are going in circles here. This PR explored an explicit label on template parts: #24557. Also, see this comment: https://github.com/WordPress/gutenberg/issues/22064#issuecomment-687906510. We spent a lot of time trying other solutions to this problem, none of which have stuck so far.

I suppose I should also mention that removing the footer bar entirely has also been brought up a few times

This is another reason we are thinking about this issue as a way to help solve the problem.

[kellychoffman]

Thanks @shaunandrews for making a new issue to refocus the conversation.

@noahtallen: I think we should move forward with https://github.com/WordPress/gutenberg/issues/25085#issue-693485385 as it is intuitive and solves the original issue (and funny enough we are more or less back to the original suggested design).

[noahtallen]

Great to hear! To clarify some things about this design, what text will be shown?

1. Do we show the current page title (e.g. "about page: header"), or the template name (e.g. "singular: header")?
2. Which block names will show up in the second item? Only template part labels and post content? What about other things, like paragraph blocks or even post title blocks?

[shaunandrews]

Do we show the current page title (e.g. "about page: header"), or the template name (e.g. "singular: header")?

In the Site Edit, we can default to template name for now. This should become dependent on the context at some point.

In the Post Editor it should display the document title.

Which block names will show up in the second item? Only template part labels and post content? What about other things, like paragraph blocks or even post title blocks?

The second item should display Template Parts (maybe we expand to Post Content and others next) in the context of the Site Editor. In the Post Editor, I don't expect we need the second item.

[noahtallen]

Getting back to the dev side of things here, let's start by creating a component for showing information in the center of the editor header area. We can make it in the edit-site package for now, and get it working with the basic interactions. We probably want to avoid making the public API abstraction immediately, at least until we have a single use-case to work with.

• Start by rendering the component in the site editor with the current template.
• Figure out the hover interaction. It feels tough to pull off (we'd need to detect the currently hovered block from outside of the block-editor package). At a minimum, get the select interaction working!
• Make an initially empty drop-down which shows up when clicking the template name.

Some loose thoughts about future abstractions:

• Possibly use the "interface" package for this
• Need a way to customize what is rendered in the component in the post editor vs the site editor. (slot/fill?)
• What about the dropdown component? Should this go in interface package? What does the public API look like?

[shaunandrews]

Here's an update to the design:

The biggest change is in the arrangement of the labels; The horizontal arrangement takes up a lot of valuable horizontal space. This update uses a stacked, vertical layout which helps reduce the overall footprint, and maybe represents the relationship between the template and template part a little better.

[noahtallen]

Are we moving away from the hover interaction then?

[noahtallen]

Also, per alignment, do we want the text to stay aligned with the top/bottom of the edges of the other buttons in the header?

[shaunandrews]

Are we moving away from the hover interaction then?

Keen eye. Sorry for the confusion; I was exploring how it'd work without the hover in that gif.

I think we should still do the hover.

[shaunandrews]

When it's just the Template name, I'd expect it to be the height of a normal button (I _think_ it's 32px last I checked). When bother Template and Template Part names are shown, I expect they'd use all the available space at 50% height each.

[noahtallen]

@shaunandrews nice, thanks! The implementation in my PR (#25320) is looking very similar to this now.

After having it in person, I feel like the information in the middle isn't very clear (which I think is reiterating some earlier concerns as well!). I.e. if all that shows up in the middle of the header is "index" or "singular"... that feels really random if I'm not familiar with those terms from the template hierarchy. I think even for page titles ("about" or "contact"), it is still confusing. I feel like it could use more clarity 🤔

[shaunandrews]

if all that shows up in the middle of the header is "index" or "singular"... that feels really random if I'm not familiar with those terms from the template hierarchy.

I agree that we'll want to come up with some more _friendly_ names and descriptions for these — but also that in order to build a WordPress theme you do need to have some understanding of the template hierarchy. Here's some friendly names that @jameskoster put together:

I think even for page titles ("about" or "contact"), it is still confusing.

I'm not sure I agree here. At some point before seeing the page title you would have selected to edit that page; Within the context of a user flow, I think it should be pretty intuitive.

--

I did explore some more explicit labeling for these items, but haven't found anything that really works too well yet:

[noahtallen]

in order to build a WordPress theme

I mean, to be super clear, I'm approaching this problem from the perspective that theme builders are a very small (though of course very important!) population of the total number of people who will use FSE. I think we ought to be making the interface as clear as we can for people who _won't_ know about the theme hierarchy. (e.g. users on basic managed service providers.)

I'm not sure I agree here. At some point before seeing the page title you would have selected to edit that page; Within the context of a user flow, I think it should be pretty intuitive.

you are probably right here. I bet it would only be confusing the first time you see it, but it would be pretty easy to learn since it would change often to match the context.

I did explore some more explicit labeling for these items, but haven't found anything that really works too well yet:

I see what you mean... I like the ones with the blue "edit" button the most, but even then:

• it looks a bit out of place
• clicking the button doesn't let you edit the thing itself. you are already editing the "about page," clicking "edit" just exposes settings.

So yeah, I'm with you there 😅 It's a tough problem, to be sure.

I think we can move forward with the basic component, then, and continue thinking about this.

[afercia]

I did explore some more explicit labeling for these items

Appreciate this exploration. Worth reminding the accessibility team remarked several times that interactive controls need to be labelled with their available action. Labelling a control with the selected value / setting / state is not an option as it doesn't really tell users _what_ the control does.

[Addison-Stavlo]

interactive controls need to be labelled with their available action.

@afercia - Thanks for the info. I think if we use an aria-label labelled by the available action (something like "open template settings" ? ) we can still have the visual text just be the template name? As the aria-label should override the available text in that accessibility flow? Please correct me if I am wrong, still trying to learn more about accessibility.

[afercia]

@Addison-Stavlo sorry if my previous comment was incomplete.

Yes, the aria-label overrides a control's text. However, for that reason having a visible text that mismatch the real name of a control would be a huge barrier for some users, for example speech recognition users. For more details:

WCAG 2.1: Success Criterion 2.5.3 Label in Name
https://www.w3.org/TR/WCAG21/#label-in-name
(see the "Understanding Label in Name" linked there)

In a few words:

• sighted speech recognition user sees a control with name "template xyz"
• the user tries to voice a command to the speech recognition software to activate that control, e.g.: "click template xyz"
• nothing happens
• actually, for the software, the name of the control is (in your example): "open template settings"

[noahtallen]

@afercia thank you for this comment, I really appreciate knowing _why_ the interaction is poor for some folks! It's especially helpful as I learn more about accessibility. :)

[afercia]

Thanks @noahtallen ! It's just a matter of knowing the devices / technologies we design for. In the same way we know how a mouse works, we should have at least a basic understanding of how assistive technologies work.

[paaljoachim]

(I might have missed this in the above comments.)
What is the purpose of exposing the template name so prominently in the top bar?

For most users I would think they would just want to switch between Page content (zoomed in) <-> site content (zoomed out). Editing a template seems like a secondary action that could be added to the sidebar. As it contains a more complex interaction than just switching zoom in/out view of the site.

If we walk through a possible use case it can look like this.
User works on the content of a page. Then wants to add content to a header. They switch to a zoomed out view where they see they see a header section. If they had earlier gone to the widget screen or customizer and added content to the header widget area, the header section would contain content. If they have not done so the header section would be empty.
In the zoomed out mode they can add blocks to the header. They preview the page and see the header content and the page content.(By default the header content should be seen for all pages/posts.)

User goes to another page and wants to change the header content. They begin adjusting the content in the header and FSE gives a message if they want to save the header as a new template. Users clicks yes and saves the header template with the name they decide. In the zoomed out view the header template can now be seen as a style/pattern in the settings sidebar with the name the user gave it.

User goes to another page and decides to use the saved header template/style.

I believe the above would be a typical zoom in to page content and zoom out to see the widget areas/template areas. Then add content to these areas.

[noahtallen]

<-> site content (zoomed out). Editing a template seems like a secondary action that could be added to the sidebar

No matter what, in the site editor, you are always editing a template, since the template is the base of all site areas. (unless you were in a "zoomed in" mode.) So that's why the template name might make sense. But i also understand arguments for making it match the page name instead.

If they have not done so the header section would be empty.

another note on this one: if the user is using a 3rd party theme, it would probably reference the theme's template part file so it wouldn't be empty

[jameskoster]

The item you are editing primarily is what should be exposed in the top bar.

If you're editing a post or a page, the title of that document is displayed. There should be an affordance to edit the template that is applied to that document, and possibly a shortcut back to the document after doing so. This sounds like the zooming in / out thing.

If you're editing a template, the title of that template is displayed.

[paaljoachim]

I made the following comment here:
https://github.com/WordPress/gutenberg/issues/20877#issuecomment-698309796

I am also adding the comment below here as I do not think that adding template information by the page/post title (middle of the top bar) is a good place to add it. As it seems to more belong in the sidebar settings that is active when for instance selecting the header area. The sidebar will then be able to contain other information associated with the template. Such as selecting another template. Viewing alternative templates (as styles). Save a template and more.

---

Here is a new suggestion for the top bar.
Using page / (page title)

Clicking page (zoomed in) <-> site (zoomed out)

Purpose to only show what is needed in the top bar. Place other elements in the sidebar.
Thinking what the user really needs to see in a simple as way as possible.

Here is the figma prototype:
https://www.figma.com/proto/utLW746LHQ9dXy2oHvwttM/FSE-UX-flow?node-id=1%3A4&scaling=min-zoom

[shaunandrews]

I do not think that adding template information by the page/post title (middle of the top bar) is a good place to add it.

The template part name will only be shown when you're editing a template.

The context of the site editor could (and should) change depending on the path you took to get there; If you come from the pages list, you'll see the page title only. If you come from the templates list, you'll see the template name alongside the selected template part.

[paaljoachim]

Thanks for clearing that up for me, Shaun!
It is good to hear that there are different pathways depending on where one is coming from.

Basically my focus in the prototype is switching between page <-> site. More basic then coming from the templates list.
I do so because I really want the basic in place and go from there to the more complex stuff.

[noahtallen]

Closing this, since we have made the template and template part names visible in the top bar.