It would also provide a way to change the post title when the post template does not include a post title block. Some post formats do this.

Yeah, that's a common pattern in themes in general.

It would be great to create movement in this issue.
The Site Editor uses the new method. Let's get a PR going for the Post Editor.

When the top toolbar is active it can be moved to a second row. The first row can contain the page/post title.
See this comment: #20877 (comment)

Let me know how I can help move this issue onward.
Thanks!

I agree it would be good to display the document title, and include the popover for editing the title & permalink.

But the interaction between the "Site" and "Page" buttons in the gif above isn't clear enough imo. I suggest we leave that out for now, since there will be (are already) other UI patterns for moving between template / content editing.

Here is an update of the Figma file.

Btw when the top toolbar is active it is then automatically moved to the second line. As can also be seen when the browser has a smaller width. A mockup.

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

I think we should break this down into iterations.

First version/iteration: (With a focus of atleast getting the fist iteration into WP 5.8.)
Let's begin by getting the page title into the top bar along with a drop down where one can rename the page title.

We need a developer for the above part. As it is a totally new concept for the Post Editor to have the page/post title in the top bar.

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?

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.

A couple of options.

As In automatically add a placeholder showing the Post/Page title block. User adds it there and also sees the name added to the top bar. EDIT: This way a user are also able to remove the Post title block from the layout/canvas area.

Creating a new post/page the cursor blinks in the title field in the top bar where the placeholder says "Add page title".

@jasmussen Joen could you also take a look? Thank you.

There could be a problem with this. In the Site Editor, without the post title, it becomes difficult to edit the first block / blocks.

Workaround is to switch to having the toolbar at the top.

There's also this issue for the block toolbar when it's close to the top of the screen: #29464

Having an interface in the top toolbar is something we've discussed for a while. The primary benefit is that it is the top of the hierarchy, so it clearly implies a document-level effect. The downside is that it can potentially take up a lot of valuable space.

Going back to the intent of this ticket: moving the editing of the page/post title to the top toolbar to result in a more WYSIWYG experience, we should be careful with, as the title in the canvas is a well-learned interface, any change will cause headaches for people who just blog.

But there is a flow to figure out. In the site editor, we need the top center dropdown interface to show document level metadata and attributes. It's present even in the new post-editor to template-editor switch:

Both of those are more accurate WYSIWYG than the post editor is at the moment. So it might be healthy to split the conversation into two flows:

• Is there a benefit to duplicating the post/page title in a dropdown in the top toolbar, just like we have in the site editor? For example it feels like an obvious place for metadata such as permalink, maybe others.
• To address the original intent of this ticket, is there a good flow for showing a more accurate frontend rendition of the post you're editing, in-situ? I.e. show header and footer, hide post title unless also present in the template. Is there value in this, and where should it live? In a "View" dropdown?

Those two, when both addressed one by one, could help give us insights into whether it makes sense at all to remove the post title from the post editor when it's also missing from the post template.

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?

If we focus not on removing the page/post title from the canvas, but instead creating the new dropdown interface to also edit it there, it will help surface better answers to those questions. At the moment we can only make assumptions.

To that extent, I think Jay best outlines the longer term thinking around such a top toolbar interface in his post about document attributes: it's about better surfacing key document metadata in an obvious place. More accurate WYSIWYG preview of your post could benefit from that, but needs its own flow explored.

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

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

That might work!

Even without any changes to the post title in the canvas — keep in mind, a lot of themes style it to match the template — I could see value in showing important meta attributes in the to dropdown.

Additional thoughts.
Let's say we leave it mostly as it is today. With one big difference one changes the treatment of the title to use the Post Title block.

Step by step.

1. One sees the post/page as one is used to. Inserts the title.
2. Notices that there is a block toolbar associated with the title, and is now able to move the title, style or treat the title like any other block. Even remove it.
3. User removes the block, and the post/page title is automatically added to the top bar area.
4. User adds back in the Post title block.

https://www.figma.com/file/NE9Y71AMMxVkuLEFzCtoNa/Moving-Post-title-to-top-bar?node-id=0%3A1

What do you think @jameskoster , @jasmussen and @vdwijngaert ?

Hey @paaljoachim, appreciate the work you're putting into this, turns out it's quite complex :)

Notices that there is a block toolbar associated with the title, and is now able to move the title, style or treat the title like any other block. Even remove it.

That could work. However, when a template is being used, the location and styling of the title should probably be left to the template editor. Alternatively, we could have a slimmed down post title block that can open the current template (if any) in the template editor? This could be a sidebar panel, toolbar action, etc.

But then, as @jameskoster stated, some templates don't include a post title block.

So yeah, maybe we should leave the title unharmed for now? We could make it more obvious that it might not reflect how it would look on the front end. For now, we can just focus on making the title also editable in the toolbar.

Yeah in this case the post title is always going to be tied to a template, whether that is an "old" php template, or a block template. So allowing folks to manipulate (or even remove) it while editing a post will be misleading.

For now, we can just focus on making the title also editable in the toolbar.

+1. We can address the on-canvas post title in a follow-up.

I think space between the left and right parts of the header gives identity to Gutenberg.

I have made this, what do you think?

Video: https://user-images.githubusercontent.com/64708228/116993399-abd42b00-acec-11eb-9cba-495f37256020.mp4

That looks really cool, @amir2mi Amir!
An interesting user interface. I am not sure how it fits into a more general title in the top bar UI though.

I am not sure how it fits into a more general title in the top bar UI though.

Me too, just wanted to share the idea [those buttons can be hidden as well].
Can something like this be there when there is no title block? (like what you said conditional).
Is it a pain to distinguish which post I'm editing now on switching between tabs?

Earlier today I shared a concept that explores moving template attributes to the top bar: #31076 (comment)

I decided to also explore how this pattern might be applied to posts and pages:

I'm quite excited about this concept not only because it streamlines the inline editing experience, but also because it would enable us to greatly enhance the existing quick edit interface that exists in list view:

Current	Future?

Here's how we could potentially take the concept from my previous comment and strip it back to an MVP in the context of this issue:

Figma prototype.

I'm curious why it should be a modal as opposed to a dropdown?

I'm curious why it should be a modal as opposed to a dropdown?

I was under the impression we were going to do a dropdown as well.

Modals scale better:

We're using modals for names elsewhere:

Modals are arguably more user-friendly on mobile. Popovers feel fragile since tapping outside accidentally will close the popover.

Finally, modals are portable. We can use this same interface to replace the ugly quick-edit feature in list view, as outlined in #27093 (comment).

All that said, it doesn't have to be a modal just yet. It's only a wrapper after all. The UX is virtually identical both ways. My main argument for using a modal now is that it paves the way for when we expand the interactions here to include other document attributes like template selection.

Edit: Here's the same flow, using a popover rather than a modal:

While I see the sense in putting document properties there, I'm not yet convinced we can put all of it there. And the problem with the dialog is that it loses a bit of connection to the post title, whereas the dropdown has a clear connection to the title, giving a strong connection. Since both dialog and dropdown are technically modal (they trap tab inside and close with escape), the dropdown could become fullscreen on mobile still, even if it's a dropdown on desktop breakpoints.

It's possible that we will end up needing all the space of a dialog in the future, but I think for the near future we should start smaller, also literally 😅

Pushed changes including a working panel to edit the current entity title. Functionality works, but needs clean-up and polishing. :)

Here is the link to the PR which Koen @vdwijngaert is working on. It could use some feedback/advice.
#31288

As I logged into the Make WordPress Core web site to begin creating the Core Editor Summary.
I noticed this:

I have not seen the "Add title" text button before, and I am wondering where it comes from. Then I begin wondering if this is something new that has been added, and began thinking about how we can actually make use of it for moving the title to the top bar issue.

EDIT: Riad mentioned this on Slack:
"The Add Title label is supposed to be hidden and I just made a commit into Core (this morning) that is supposed to fix that. Not sure if or when it will make it into make/core."