Rethinking the "Current Document" display and settings

[mtias]

Since the very beginning, we have attached the permalink function to the title of the post. This had the intention of making it a bit more prominent — particularly for pages — compared to just having it in the sidebar panel.

It was also stated at the beginning that in the future the title would become a block, and thus the permalink function would need to move away. We have also discussed many times the idea of bringing features that used to exist in the document panel closer to more relevant places in the post (featured image being an obvious one).

There's also the cases where the design of a post / page template doesn't include the title for whatever reason. We don't have a clear way of showing that the title is not just visual but also important semantic data (even if a title should not be shown, we don't want users to end up with "(No title)" in their post list.

In this issue I'd like to suggest absorbing the title and permalink flow in the editor header:

This would open a dropdown containing some of the most relevant elements from the "status" panel: permalink, date, visibility, author, delete. It would also give a visible and consistent place for the document title.

In the context of full-site editing we have a "template" dropdown in the top left area showing what the current template you are editing is (single, page, archive, etc). I'd propose exploring a way to combine this so that the relationship is more clear:

And extend it to all the different types of content and templates you might have:

---

Of course, we need a better way to handle the top-toolbar option, but I'd argue that's already becoming the case with the header growing in functionality and it being able to contain any number of plugin extensions.

Thoughts? Ideas?

[ZebulanStanphill]

Just noting that the tab order should definitely match the visual order (left to right, top to bottom) whenever possible, to ensure good accessibility. If you think the document settings should be the first thing you tab into, then perhaps that's a sign that you're putting it into the wrong spot, visually, and you need to move it to the start of the toolbar, rather than the middle.

Using the document title as the label for the button is a bad idea. To follow accessibility guidelines, the button should be labeled based on what it does. It opens post/page settings, so it should be clearly labeled as such. I'd suggest "[Post] settings", where "[Post]" is the current post type, e.g. "Page settings", "Template settings", or "Product settings".

If there's a lot of controls to show, we could use a popover modal similar to the "Options" modal, rather than the currently proposed dropdown menu design. We could also potentially keep the current sidebar look, but make it act more like a modal to improve accessibility (meaning it closes automatically when your focus leaves it).

I do like that this separates the document settings from the block inspector (the latter of which probably shouldn't be accessed from the top toolbar in the first place, but rather the block toolbar... and it should also act like a modal).

It's also worth remembering that this all has to work on mobile, so keep that in mind when designing interfaces that have side-tabs.

[ghost]

That looks great. Happy to see that the focus is on structure and workflow. The Permalink is very important specially after the ping has been send to Google and other indexing services. Great design here.

[shaunandrews]

Considering the permalink has become less visible after it was removed from the title component, this is a good chance to give it a better placement.

It's also worth noting that the title in the header could become the only reference to a title on the entire page in cases that the theme design or post format won't render a title on its own, meaning editing the title should be a primary concern for these explorations.

If we step back and look at just the title and the URL, maybe something like this is a better option to start with:

showing the template structure for the site editor, including possibly the currently focused template area at the root (header, footer, etc).

I created a separate issue for exposing this structure information: https://github.com/WordPress/gutenberg/issues/25085

[dubielzyk]

If we step back and look at just the title and the URL, maybe something like this is a better option to start with:

I like this a lot! It means not moving the Document Settings, but in terms of solving the for renaming and permalink, I think it's great.

[ZebulanStanphill]

@shaunandrews That mockup, once again, shows a button that is incorrectly labeled. The button should not be labeled based on the current state, but based on what action the button performs. A proper label would be "Edit title & permalink".

[afercia]

Just noting that the tab order should definitely match the visual order (left to right, top to bottom) whenever possible

Not "whenever possible", it should match always, when it affects meaning and operability.

Once again, I totally second @ZebulanStanphill on the labelling of controls. The name of a control needs to communicate what it does, not the underlying state or selected setting.

It's also worth remembering that this all has to work on mobile, so keep that in mind when designing interfaces that have side-tabs.

Generally, a modal dialog is a better known pattern: users are familiar with it and know how to interact with it. Sidebars are not and in this project we discussed (and still discussing) at length the sidebars pattern with all their accessibility issues. From an accessibility perspective, a modal dialog or a "popover" with a modal behavior would work better than a sidebar.

[ghost]

Generally, a modal dialog is a better known pattern: users are familiar with it and know how to interact with it. Sidebars are not and in this project we discussed (and still discussing) at length the sidebars pattern with all their accessibility issues. From an accessibility perspective, a modal dialog or a "popover" with a modal behavior would work better than a sidebar.

Totally agree. The sidebar should be as a fast check but not the main focus for the document. I like the Title than Permalink below as in the image, it gives a good workflow and you can see very clearly what words are used in the main title and what words are used in the URL.

[paaljoachim]

It would be great with a summary of where this issue is at right now.

---

What if we just start with a MVP? Get the title up into the top bar and add the permalink drop down to it. It would break this issue down into smaller parts making it easier to iterate on.

EDIT: Moving the page/post title to the top bar and adding a page/post title block will give us a lot of hands on feel to how this actually functions. Based on this hands on experience we can then iterate.

[noahtallen]

Agreed! Myself, @Addison-Stavlo, and @jeyip are working on an MVP right now. We are starting by working with #25085, and have added a document area which currently includes the template name and some template part information. We are also exploring a minimal dropdown experience with a basic setting in #25386 .

Additionally, I'll highlight these smaller issues, but we're still working on the best way to break it down :)

• https://github.com/WordPress/gutenberg/issues/25586
• https://github.com/WordPress/gutenberg/issues/25546

We're adding this to the site editor to avoid adding any experimental stuff in the post editor for now.

[paaljoachim]

I would really say let's take one step at a time. Get the MVP in place in the post editor and hold off with other explorations until we can explore how the MVP functions and feels. Get feedback from Gutenberg plugin users and learn from it and then iterate how to extend it into FSE. As users will need to experience that suddenly the page/post title has been added to the top bar and is not a part of the page content any longer, but that they can add a page/post title block.

The process should go something like this.

1. Move the page/post title to the top bar.
2. Add the permalink to the page/post title drop down.
3. Have a page/post title block available for the user to add back the title to their layout.

See what kind of feedback is received from various users. Iterate and improve. As the above is improved one will have gained new knowledge that can be also brought into Full Site Editing.

[noahtallen]

Have a page/post title block available for the user to add back the title to their layout.

I think this aspect is already in place, since there is a post title block already: https://github.com/WordPress/gutenberg/tree/HEAD/packages/block-library/src/post-title (you would add that block to your template). And yes, we are working on items 1/2 currently :)

[afercia]

Get the title up into the top bar and add the permalink drop down to it.

If this means using the title to label the button that opens the drop down, no please. As already mentioned several times, this is a no-go for accessibility. Buttons must not be labelled with a state or a setting. The need to be labelled with the button action.

[paaljoachim]

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

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

EDIT: The prototype I added is so that one needs to click the chevron to open the drop down for the page title and the permalink. The page title is not clickable but a static text.

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

[afercia]

@paaljoachim maybe I wasn't clear, I'll try to better explain: the text of the button must not be used to represent the selected object. A button text must identify the available action 🙂

[shaunandrews]

I've been toiling over this for a little while now (Actually, more than a little while; Probably way too long.) as I want to provide a path forward that accounts for the accessibility concerns while making progress towards full site editing.

The biggest hurdle with my previous design above is that the label of the button is representing a value rather than an understandable action. As discussed here (and elsewhere) adding an aria-label attribute could help, but introduces a different accessibility issue related to voice control.

--

After way to many design explorations, I may have found a (incredibly obvious in hindsight) solution; We separate the document title from the button. Here's a GIF that shows how that could work in the context of editing a page:

The document title becomes a normal text label with no interactions; Next to it is an arrow for the document details dropdown, which allows you to edit the document's title and permalink along with changing the document's template.

--

When editing a template directly the dropdown would adjust as needed. The biggest change is related to the editable values; Theme provided templates can't be renamed and don't have a permalink. We can use the details as a way to provide a description of the template, along with some actions like duplicating, exporting, or trashing. When selecting a template part, the document title updates to reference the template part and the document details menu goes away. Here's a GIF that shows how that could work:

[ZebulanStanphill]

If the button is only going to be an icon (which already is not ideal), it should be an icon that more clearly conveys the action. A chevron is definitely not the right one. We're already using that in too many unrelated ways:

• as an "up/down" icon (for the block movers... I think this use-case makes the most sense)
• as an "expand/collapse" icon (for the accordions)
• as a "more items" icon (for the inline formatting tools)

A pencil icon would better convey the idea of "editing". Of course, that might be a bit confusing since the Tools/Modes on the left also happen to use a pencil icon to represent the "Edit mode/tool". But I'd argue that the Tools/Modes dropdown toggle shouldn't even look the way it does right now, because right now it has the same problem that the earlier mockups of this "title editing" UI had: it's incorrectly using state as a label. So if we can fix the Tools/Modes button to use a better label, we can make this UI work better.

Also, the idea of removing the document details button when a template part is selected doesn't sound right to me. The user can access the top toolbar at anytime via a keyboard shortcut, and to have the template/document settings there sometimes but not all the time is confusing for sighted users and even more confusing for screen reader users.

[shaunandrews]

A chevron is definitely not the right one.

The chevron is used in many places as an affordance to indicate a dropdown. It seems to fit well here.

I can see an argument for the accordions using a different icon, but I don't think the movers are a problem; They are visually represented as two related shapes: up and down next to each other.

Also, the idea of removing the document details button when a template part is selected doesn't sound right to me

This is an indicator and reminder that, while editing a template part, you're not editing the root document.

[ZebulanStanphill]

The chevron is used in many places as an affordance to indicate a dropdown. It seems to fit well here.

Currently, almost every button that opens a dropdown doesn't use a chevron. The only things that do are the "More formatting tools" button and <select>s. If we're going to start using chevrons to indicate dropdowns, we ought to do it consistently. And still, those chevrons would be secondary indicators, not the primary label of the buttons.

The former seems to only use a chevron because it wants to avoid having two ellipsis icons next to each other. And that itself just speaks to the issues with using icons alone to visually label controls. (Perhaps a new icon that better describes "more formatting tools" should be introduced... perhaps an ellipsis with a fancy serif "T" in the corner?)

The latter is a common UI convention, though perhaps a pencil icon might be more appropriate? Otherwise, I think we should consider changing the mover buttons to normal (tailed) arrows so that they don't use the same icon.

A button ought to have some kind of clear visible label that is semantically attached to it. The chevron icon conveys very little info, and in fact, it may confuse the user into thinking it is a <select> and cause them to try clicking the template title next to it.

Thinking about it some more, what if we just made the "Template settings" button look/act similar to the "Document settings" button in #25353? Since the template part indicator is semantically unrelated to the "Template settings" button, why are we even showing them next to each other?

In other words, I'm suggesting to move the "Template settings" button over to the right side of the top bar, but to keep the "currently selected thing" indicator where it is right now in your mockup. How does that sound?

Also, the idea of removing the document details button when a template part is selected doesn't sound right to me

This is an indicator and reminder that, while editing a template part, you're not editing the root document.

If you alter the content of one of the template parts inside a template, then technically you are modifying the template, albeit indirectly. And in terms of showing/hiding the template controls, I think there should always be a button to access them, just like there's always button to access document settings in the post editor. (Albeit indirectly, due to it opening a sidebar that also includes unrelated block controls. But that's a separate a11y issue that I'm trying to help fix in #25353.)

The top bar generally acts like a toolbar for the entire document. Therefore, conditionally hiding controls related to the entire document/template sounds like unexpected behavior to me.

(Showing the block toolbar inside the top bar when the "Top toolbar" option is enabled is of course the exception here. But judging by the discussion in #20592, that option is likely to change in behavior to showing the block toolbar below the main top bar.)

[jameskoster]

In other words, I'm suggesting to move the "Template settings" button over to the right side of the top bar, but to keep the "currently selected thing" indicator where it is right now in your mockup. How does that sound?

With which icon? The cog and ellipsis are already in use there. Anything else feels questionable. We'd essentially be moving from something that feels fairly intuitive, to something that is less intuitive but (debatably) more semantically correct. Is that a win? Seems somewhat subjective.

For me, many of the problems you touch upon can essentially be summed up by saying the the iA of the top bar is sub-optimal, which on balance I would probably agree with. The lack of clear structure there is likely why these discussions keep occurring. But addressing those failings is way beyond the scope of this issue. So personally I would vote for getting this feature in using existing patterns (which Shaun's design achieves), and addressing the more widespread issues of the top bar separately.

[afercia]

The lack of clear structure there is likely why these discussions keep occurring. But addressing those failings is way beyond the scope of this issue. So personally I would vote for getting this feature in using existing patterns ...

I'd totally agree on the first part. Not sure I agree on the second one as I don't think text / controls in the center of the toolbar are an "existing pattern". Maybe they're proposed in other designs for other features but they do not exist yet.

That said, separating the text representing the edited object from the button is a good first step, thanks for that! However, I think there's room for further improvements.

As usual, when it comes to accessibility there's the need to make a little effort and try to not think visually. Imagine you can't see and a software is reading the page content for you. At some point, the software reads out:

About {brief pause} Page details, button.

As a user, I wouldn't be sure what that "About" is meant to indicate. Sure, in some way I navigated to this view and selected the About page but what that text means? It's just text, not a heading or whatever and doesn't seem to communicate anything relevant.

Instead, visually, that text does communicate something more relevant because it's visually prominent. T convey the same information to assistive technology users, there's the need to communicate the same importance also semantically by using better text and HTML.

First of all, as a used, I'd like to have this information available as the very first thing in the main section of the page: before any toolbar or other controls. This text communicates the object currently being edited and in a logical flow I need to know what I'm editing before any other info. I do realize this would need a design change but I'd strongly recommend to think to a better information architecture that is not only visual. A good information architecture needs to be conveyed also and foremost in the HTML. Worth noting that there's an ongoing exploration to split the editor toolbar in two separate toolbars in #20592 and I'd like to suggest to consider that same pattern here, even if it would be used for different purposes. By having two toolbars, many of the problems related to information architecture, controls grouping, available space, etc. mentioned in this thread would have more chances to be solved.

Back to our software that announces what's on the page. Looking at the last mockup, to my understanding the text and the button labels are "dynamic" depending on the edited object. So the software would announce, for example:

About {brief pause} Page details, button

or

Single post Header {brief pause} Template details, button.

This would still be confusing for non-sighted users and potentially for other users (non-tech-savvy users, users with cognitive impairments, low vision, etc.). The first part of the text still doesn't tell what it is. The button label still doesn't communicate the available action (which is "Edit"). To communicate the missing info there's the need to use more meaningful text. Imagine again you can't see and a software is reading out the content of the page. As a used, I'd like to have answers to a few questions as first thing:

• Where am I?
• Answer: you're on a page where you can edit xyz
• Oh, thanks for the info. And what can I do here?
• Answer: by pressing this button you can edit the xyz object details

To translate this "conversation" in markup, I'd place these info as first things in the page:

• Currently editing: xyz
• [button]: Edit xyz details (or simply "Edit details" as the object being edited is in the context)

As per the icon: there's a lot of space in the toolbar: why use an icon-only button in the first place? To me, the debate regarding the icon in this thread just proves one of the points the accessibility team always pointed out: icons don't have an universal meaning. Since they're also an accessibility anti-pattern, I'd recommend to just use plain text: a button with visible text "Edit details".

[ZebulanStanphill]

@jameskoster

In other words, I'm suggesting to move the "Template settings" button over to the right side of the top bar, but to keep the "currently selected thing" indicator where it is right now in your mockup. How does that sound?

With which icon? The cog and ellipsis are already in use there. Anything else feels questionable.

Oh, what's the cog being used for? I assume just the block inspector? If so, perhaps we should change the block inspector button to use a generic block icon or something like that. Using a cog to represent just the block inspector doesn't make much sense if the button is in the top bar, where controls aren't always related to blocks. (It would make more sense if it was in the block toolbar, but that's a bit of a bigger change to try and implement.)

But as @afercia just pointed out, this really just boils down to icon labels being difficult to understand, so we ought to just use a text label for the Template settings button regardless of where we put it.

[jameskoster]

I don't think text / controls in the center of the toolbar are an "existing pattern"

Just to clarify, I was referring to the dropdown-from-a-chevron pattern. It's not perfect but it does exist, so we can use it now to close this issue, then address the separate issues that particular UI pattern presents all in one go, in a subsequent issue.

As before, most of the other feedback really falls in to the territory of fixing foundational problems with the top bar iA. I am very keen to fix that as well, but not in this issue as it is a huge project. (Thanks for the link btw, I'm going to dive in to that now 🏊‍♂️).

But as @afercia just pointed out, this really just boils down to icon labels being difficult to understand, so we ought to just use a text label for the Template settings button regardless of where we put it.

What is the best way to do this in a way that elegantly scales down to mobile? It seems as though something like this would be preferred:

The challenge with this is fitting all the information into a single row on mobile. We'd probably have to eliminate the "Editing" and "page" text, just so a truncated part of the document title and the "details" link are visible:

But this doesn't account for languages in which that "Details" link might be a longer word... it's not hard to imagine a situation where the document title is hidden entirely.

We could put this information on it's own row, or put the details link elsewhere, but then we're just back at the overall iA discussion again. And we shouldn't be making decisions that effect the overall iA with just the context of this one issue, as it is a much bigger discussion with further reaching implications that affect both accessibility and design.

Is there a middle-ground interim? Perhaps adding the "Editing" prefix and keeping the chevron, but adding a better label:

[mtias]

When adding this element it'd be important indeed to group things semantically. In the current designs above we should at least be able to define three groups, with page title as the most prominent hierarchically. I think this is an example were flex-order can be employed to good effect, since it'd align the semantic hierarchy with the perceived visual hierarchy, so we can have the title control first in the DOM and centered visually. I think there's a bit more work in continuing to refine how the entire header area is presented between main W navigation, current page/post, block and editing tools, publish and plugins, but as mentioned there are already other issues focused on that.

[noahtallen]

Is there a middle-ground interim? Perhaps adding the "Editing" prefix and keeping the chevron, but adding a better label

How about just "show template details" in this case? (You know, for when the dropdown would show template details.)

That would change it to:

Single post {brief pause} Show template details, button.

Alternatively, "show details" feels very clear:

Single post {brief pause} Show details, button.

[afercia]

The challenge with this is fitting all the information into a single row on mobile.

I'd totally agree but this is a problem also with the very first mockups at the top of this thread. A single top bar doesn't provide enough space on mobile to contain all that information. Truncating text isn't a great solution because it makes the title not meaningful enough to identify the edited object. In the last mockups above, the page title "Make a reservation" becomes "Mak..." or in the best case "Make a re...", not to mention the icon-only button.

Overall, I'm afraid that whatever exploration we can try a single top bar won't ever be ideal. Also, I don't think that truncating or "squeezing" content to make it fit in a UI is the best path forward. User interfaces should be designed around the content, not the other way around. To me, this whole issue just proves that a single top bar doesn't suit our needs.

I think this is an example were flex-order can be employed to good effect, since it'd align the semantic hierarchy with the perceived visual hierarchy, so we can have the title control first in the DOM and centered visually.

I'd totally agree with @mtias that the page title should be prominent hierarchically. However, we can't use flex-order because it would affect the tab order. Worth reminding that visual order and DOM order must match, when they affect meaning or operation. See WCAG 1.3.2 and 2.4.3.

[diegohaz]

As I read and reread this issue a few times, one thing that I think is making the discussion more confusing is the fact that we're referring to the same element in different ways: "top bar", "header", "toolbar".

It's definitely not a toolbar. It's a header/region element with widgets inside, including a toolbar (Document tools). "Editor top bar" is its current accessible name.

I think this is an example were flex-order can be employed to good effect, since it'd align the semantic hierarchy with the perceived visual hierarchy, so we can have the title control first in the DOM and centered visually.

This could be tested. But I don't think it's a good idea to have the tab order different than the visual order, especially for sighted keyboard users. I would try other things first. 😊

The best way to represent hierarchical information, especially because we're talking about a "page title", is by using heading elements. This page title element should be an h1. Screen reader users would be able to reach it very easily (for example, by pressing H, Shift+H, 1 or Shift+1 on NVDA). This is a very common way to navigate the web. It's also very common to start scanning a page by navigating through the headings.

Another thing we can explore is referencing this heading in the aria-labelledby attribute on the header element, or setting aria-label to a more descriptive name if we stick with role="region" as it is today.

Screen reader users would hear something like Contact page, banner or Contact page top bar, region when they move focus into that element. They would also hear this when navigating through landmark roles (D or Shift+D on NVDA).

[diegohaz]

As per the layout, I wonder if it's worth exploring something in this direction (needs to be polished 😅):

This way we would have a clear visual hierarchy and a flexible space for toolbar items (the toolbar could also be scrollable on mobile as it is today).

[afercia]

Thanks @diegohaz for reminding that headings are still today the main tool screen reader users use to find information on a page. See latest WebAIM survey (data from September 2019): https://webaim.org/projects/screenreadersurvey8/#finding

Headings have always been used as navigational tools by screen reader users and that's the pattern the work done in core to refactor the headings hierarchy and clean up the headings content has been based on. Similarly, more headings in Gutenberg and in the new block-based pages (Widgets, Navigation, FSE) would greatly help.

[Addison-Stavlo]

we can't use flex-order because it would affect the tab order. Worth reminding that visual order and DOM order must match, when they affect meaning or operation. See WCAG 1.3.2 and 2.4.3.

Im confused why we cannot use flex order. The sequential order of these items in the header do not affect each others meaning nor their operations. They are stand alone controls.

Reading the qualifying conditions for these codes: 1.3.2 - "When the sequence in which content is presented affects its meaning" - It doesn't here. 2.4.3 - "and the navigation sequences affect meaning or operation" - neither does this.

The page/document name is the most relevant piece of information when navigating into the editor, it makes sense that it would be the first tab-navigation into the header (much more sense than the toolbar on the left). While it would be preferable to preserve visual tab order, we cannot both do that and have the title appear first hierarchically unless we actually remove the toolbar on the left. Until that is agreed upon and completed, flex order seems like a good candidate for @mtias's criteria for:

have the title control first in the DOM and centered visually

[paaljoachim]

As this issue has become very long. It would be great with a kind of status update/summary. I believe there are multiple actionable issues/PR's that have also picked up the thread from this issue.

[jameskoster]

As this issue has become very long. It would be great with a kind of status update/summary. I believe there are multiple actionable issues/PR's that have also picked up the thread from this issue.

It seems to me that we have consensus around the design of this component in isolation, and indeed those designs have now been implemented in the Site Editor 🎉

So in the interest of actually moving forwards, how about we implement that same component in the standard editor as well?

We can then close this issue, and investigate any subsequent iA problems in a separate issue. Personally I would be in favour of condensing all top-bar-related concerns in to a single issue that considers all the functionality therein. At the minute there seem to be several separate conversations around top bar + X, or top bar + Y, or top bar + Z, etc. In my opinion, to address these concerns in a scalable and sustainable way we need to consider top bar + A - Z all at once.

[MichaelArestad]

Personally I would be in favour of condensing all top-bar-related concerns in to a single issue that considers all the functionality therein. At the minute there seem to be several separate conversations around top bar + X, or top bar + Y, or top bar + Z, etc. In my opinion, to address these concerns in a scalable and sustainable way we need to consider top bar + A - Z all at once.

I am also in favor of a new issue to consider the top bar information architecture holistically instead of in pieces.

[vindl]

We can then close this issue, and investigate any subsequent iA problems in a separate issue.

Since the initial version of this has been implemented in the site editor, and based on the comment reactions so far, it seems like it should be fine to close this. Feel free to reopen the issue if I'm wrong.