Move post/page title to the top bar.

[scruffian]

Block themes and template editing give authors much more freedom to express how the titles of posts and pages are displayed on the frontend. They might appear inside Cover blocks, adjacent to Post Content, or in any other conceivable block configuration. There are also situations in which a template might not display a post title at all, e.g. Post Formats.

All that to say, it might be time to consider not displaying the post title within the canvas when editing a post or page, because the current implementation is increasingly unlikely to be an accurate representation of the frontend. Example:

Backend	Frontend

Clearly it must still be possible to edit the post title without engaging the template editor first. For a solution we can look to the Site Editor, where the document name appears in the Top Bar, and custom templates can be renamed:

We can probably migrate this pattern across to the post editor as well. The result would be something like this:

When the document has no title, the label can probably read something like "Untitled Document".

Original issue

I think it makes sense to move the page/post title into the top bar like we do for template names. Often we will want to add the Post title inside another block (e.g. Cover block), or in a column.

This would give users more flexibility about where the Post/Page title appears:

Originally suggested by @paaljoachim here: #20877 (comment)

[jameskoster]

It might also be good to include the template information here, and a link to view all posts.

post.title.mp4

[vdwijngaert]

I'll try and have a go at this. Progress so far looks promising:

Here's at least two things that need some working out:

• How would we go about and replace the current new post/page workflow that focuses the empty post title block?
• How should this work on a mobile viewport?

[jameskoster]

How would we go about and replace the current new post/page workflow that focuses the empty post title block?

It may be fine to leave the post title on the canvas for now. Otherwise I imagine the text would read "Untitled Page" (or similar) until you click it. Clicking should shift focus directly to the title input.

[jameskoster]

Good thoughts, I agree that splitting this in two makes sense.

Also worth noting that while seeing the title on the canvas does degrade the overall WYSIWYG experience, that degradation feels less impactful thanks to the edit template flow. We're now set up to provide a WYSIWYG of the post content in isolation, and a WYSIWYG of the post content in the context of its template where you're able to see the post title doing its thing.

A possible interim could be to leave the title on the canvas, but reduce its prominence?

Before	After

[vdwijngaert]

A possible interim could be to leave the title on the canvas, but reduce its prominence?

That might work!

[artemiomorales]

I can take this on. I'm currently working to implement a popover to update just the title so we have something working to look at. Just let me know if I should be considering anything else!

I've updated the OP to include designs that we can put into practise now.

Question for @jameskoster: To clarify, do you mean that you've updated the original post?

[jameskoster]

do you mean that you've updated the original post?

That's correct :)

[artemiomorales]

Hello all, I created a pull request for this issue: #46135

It's the most basic implementation for now. Would love to get additional eyes on it and see what you all think ✨

[alexstine]

Hello all, I just reviewed the PR and gave some technical/accessibility feedback. Keeping in mind that I can't see the screenshots, I am interested to see how close the PR got to the actual visual design. From an UX perspective, it greatly worries me that we continue to box up the editor. It is going to get harder and harder to provide context around that as we'll soon require a bunch of random/very generic button labels to convey where we've decided to hide certain functionality/options. I am not saying wide open always works better, but I am not sure the post title hidden in an accordion-like drop down was the right way to go here.

In my opinion, I think it would be nice to leave the title field where it currently is. It is a nice buffer between main document title and the start of the editing fun.

Thoughts?

Thanks.

[jameskoster]

The issue with the current placement of the title field is that it breaks the WYSIWYG. The proposed solution re-uses existing Site Editor features (updating the title of a custom template), but I assume those also suffer from the same accessibility issues?

An alternative option could be to simply move the title field into the top bar? Hopefully we could position it in the DOM so that it still acts as a buffer?

title.mp4

[alexstine]

@jameskoster Might be best to just move the field in to the top bar. I am not sure hiding it in a drop down is really necessary at this point. All my other A11Y feedback on the PR still applies. Need to figure out how to not mess up the DOM structure.

Thanks.

[jameskoster]

Assuming we can get the other a11y details right, I think it would be okay to start with that. Thanks for the detailed feedback as always.

Edit: to clarify, which of these points would remain if the input was moved into the top bar?

1. "Edit document details" button should probably not be a sub menu in the event that it simply shows the title field.
2. The title field is rendered at the bottom of the DOM just below the block breadcrumbs. The title field needs to appear in relation to the button.
3. "Edit document details" does not say anything about editing the title. My problem is, we're going to start splitting hairs until no one knows how to find anything in the editor. From a general UX perspective, hiding everything in toggles can't be helping us long term.
4. Once you are done editing the title, there is no easy way back to the button that moved focus to the title field.
5. It is not clear to me how to save the title changes once done editing.

The first, third and fourth issues should be resolved because the "Edit document details" button wouldn't be required any more.

Issue #2 should be easy to address, we can position the title input anywhere in the top bar and use css for ordering / styling.

For the fifth issue, how do you know how to save the title changes currently?

[joedolson]

I think that Alex has a good handle on the accessibility of the title interface. I'm comfortable in principle with moving the title out of the post editor; it was a separate field in the classic editor, and keeping it separate seems totally reasonable to me.

My primary concern is making sure that the title has sufficient prominence, so that it's easy to spot at a glance which document you're editing and that there's no truncation of the title, so that the entire post title is always visible.

Having the title directly editable in the top bar makes sense to me. I can also imagine that this layout could speed things up in a work flow where you're stubbing out a large number of documents to be filled out later, since you wouldn't need to enter the post editor in order to publish a stub that only had a title.

[artemiomorales]

I agree with @joedolson. As a user, I wouldn't know the title was immediately editable without some kind of indication, so having it as an input makes sense to me. I updated the pull request with that implementation so we can all see what that looks like as we keep the discussion going.

5. It is not clear to me how to save the title changes once done editing.

I believe having it as an input also addresses this fifth issue raised by @alexstine. If the title is an input, I feel that folks could intuit that one needs to save the post in order to persist edits to it.

[annezazu]

I wanted to note for tracking purposes that the PR to address this has been closed in favor of a potential future, broader fix in #44461 or #27847. Let's keep this open for now to ensure this does indeed happen as part of Phase 2 work.

[Mamaduka]

@annezazu, @ndiego, based on the discussion in PR #46135 (comment), I believe this path was deprioritized in favor of a broader solution.

I think we can remove the issue from WP 6.2 project board.

[ndiego]

Yeah, at the very least, it does not look like a solution will make it into 6.2 at this point. I'll remove it.