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?

[chrisvanpatten]

I really dig this! Would this be an area to edit the title too, or is that still managed within the canvas? (I think that makes the most sense especially with the move toward FSE)

[pablohoneyhoney]

Here some other iterations.

In order to avoid too many focal points in the top bar with too many arrow-down here a couple of options.

Also related to top toolbar mode: 20592

[ZebulanStanphill]

I assume that, if this were to happen, the "Top toolbar" mode would change so that the block toolbar is placed underneath the document toolbar? I'd be okay with that change, but I don't know about everyone else.

Either way, I agree that it makes sense to put the template and post title in the header, and provide a more obvious place to edit the title/permalink without the current fake block that the post editor uses.

One question I have is whether it makes sense from an accessibility perspective to put the title in the middle of a toolbar like this.

Also, with regard to chevron arrows, I thought we were moving away from those on toolbar controls with dropdowns anyway, so perhaps neither the title nor the Preview button should have a chevron.

[mtias]

I really dig this! Would this be an area to edit the title too, or is that still managed within the canvas? (I think that makes the most sense especially with the move toward FSE)

Both! I think it should be possible to rename a post / page / cpt from the header title but also form any in canvas block if it's present. It should synchronize in real time anyways.

The chevrons in the header controls are still a bit undefined (as seen in the "preview" having and not having it). I think we'll coalesce into something a bit more consistent once we get a better feeling for it.

@pablohoneyhoney I like the dot better, I think, but I'm missing some difference between the template and the post. At first glance it can misguide me to think I'm looking at a post titled "Single Musings on Philosophy".

[ZebulanStanphill]

Maybe a colon would work best, e.g. "Single post: Hello world!"

[mtias]

That seems more problematic because each needs to open a different flow. The "single" is connected to this entire template flow (in FSE): https://github.com/WordPress/gutenberg/issues/19252

While the "post title" is part of this flow (in FSE): https://github.com/WordPress/gutenberg/issues/19257

[ZebulanStanphill]

Perhaps it would be best to put the template and post dropdowns/buttons on the left, rather than the center? From an accessibility standpoint, it's a bit weird to have them in the middle of the top toolbar, isn't it?

[feastdesignco]

@ZebulanStanphill makes a valid point, but I think it doesn't go far enough.

The average user doesn't know and doesn't care what template is being edited. And they shouldn't have to.

Only developers care about this. The average user spends 1000x more time in the post editor than a developer.

This is all gibberish to 99.99% of your user base:

Would it be nice to know what template is being used? Sure, for a developer.

It doesn't need to be displayed by default though. It's simply not meaningful information to the average user.

[mtias]

To clarify, this concept is not being proposed for the regular post editor but in the new site editing views (full-site editing project), where the template is the primary source being edited.

[feastdesignco]

To clarify, this concept is not being proposed for the regular post editor but in the new site editing views (full-site editing project), where the template is the primary source being edited.

Thanks - this was not clear and is confusing to have lumped in with the block editor, which is seen as a post editor. This was all I could find on it: https://wptavern.com/gutenberg-team-explores-the-future-of-full-site-editing-with-new-prototype

Please release this as a separate project/plugin, rather than lumping it in with the post block editor. I can speak for 99% of our user base when I say that they're sick of BETA-level features with inadequate public testing being pushed on them.

The vast majority of your users (non developers) value stability and polished products over a new-way-of-doing-old-things that are constantly changing/breaking. We're all-in on the FSE, but it needs to be handled better than the post block editor was.

We created test pages with the blocks a month after the block editor was officially released, and half of the blocks were broken within 6-9 months. For users writing 2 posts per week, this is completely unacceptable. Having to go back and re-edit 12-20 posts every 6 months is a huge issue. We have thousands of users and the anxiety they have about this is palpable - you have millions.

For example, if there are settings and filters already existing in Wordpress, please integrate them better: https://github.com/WordPress/gutenberg/issues/8663

If there's anything we can do to help this, please let me know at skylar@ username dot com

[shaunandrews]

This might be too much, but what it we used the wp-admin toolbar for this Current Document information:

[pablohoneyhoney]

It is certainly too much. From a functional standpoint, it doesn't belong to that global element, pulling an editing tool out of its editing context.

[shaunandrews]

I worry about adding more stuff to the already overcrowded top bar, especially considering viewports less than 1,200 pixel wide. What if we added the template to the bottom bar's Breadcrumbs, and replaced the "Document" breadcrumb with the post title:

[MichaelArestad]

@shaunandrews I really like this latest mock for a few reasons:

• Keeps the top bar less busy
• Puts a set of actions that aren't super common (daily use) in the bottom bar out of the way
• Keeps current template and page always visible

I might suggest changing the actions of the Post/page title to be focused on changing the page/post. What do you think?

[jasmussen]

I do worry about adding more stuff to the top bar as well. However in this case it does feel like the right "ux" for it.

I was part of the genesis of the footer/breadcrumbs. And although I've learned to use them and find them a good way to navigate parent blocks, it does not seem like people notice the footer at all. Given how important an interface it is, we may have to accept that as a failed experiment.

[shaunandrews]

In a 1080px viewport with a slightly long post title, the top bar gets really crowded and unbalanced:

[jasmussen]

I actually think that works reasonably well especially if you elide the text slightly earlier and add some more spacing.

For context, you are stressing the area quite a bit — as you should! — by showing a screenshot of a 1080px wide image. And yes, in that case we have to elide the text — and perhaps clicking it to change the title opens a dialog rather than letting it be edited inline.

Figma leverages a similar pattern, and if we size that to the same dimensions, you quickly enter the same territory. It's fine with short titles, which are probably the case most of the time:

But it starts to fall apart with longer titles:

In this case, Figma should have elided the text way earlier.

But I think it works!

[feastdesignco]

From an SEO perspective, people should use long-tail search phrases for titles. Search engine traffic is what brings sales to ecommerce stores, and traffic to ad-supported blogs.

"Homemade Cauliflower Pizza Crust Recipe" is a 100% valid title.

"The Top 10 Places to See in Vienna in the Fall" is a 100% valid title.

Long titles are a normal thing and should be encouraged. There should be space for at minimum 50-60 characters.

[ZebulanStanphill]

@feastdesignco

Long titles are a normal thing and should be encouraged. There should be space for at minimum 50-60 characters.

Nobody's saying we should limit title length. But just because a title is 60 characters long doesn't mean we need to show all 60 characters in the UI when you're not editing the title.

@jasmussen

I was part of the genesis of the footer/breadcrumbs. And although I've learned to use them and find them a good way to navigate parent blocks, it does not seem like people notice the footer at all. Given how important an interface it is, we may have to accept that as a failed experiment.

Verging a bit off-topic here, I think part of the reason the footer goes unnoticed is because it is so small, and it only has one limited use-case: selecting a parent block. You can't even use it to select a child or sibling of the current block.

I think the next best hope for improving nested block interactions is probably the Block Navigation interface. I think that could be beefed up significantly; Divi's Layers View is a good example of what that interface could become.

[joanrho]

@MichaelArestad Do you know if we have art for the final design direction (was it a truncated version of the topbar direction)? Also, what other Issues need to land first before this can be moved forward?

[jasmussen]

@joanrho I would suggest that the mockups Matías made in the initial post, or the refinements Shaun made in https://github.com/WordPress/gutenberg/issues/20877#issuecomment-601283215 are both ready to move to a PR state. There's no better way to figure out whether perceived notions of screen width is actually a problem or not, than testing in a PR.

[MichaelArestad]

@joanrho I agree with @jasmussen. In my latest attempt at an end to end prototype, I used one of Shaun's designs. It looks like this in context:

And here's the link to the prototype to try it out.

[MichaelArestad]

A deviation from previous patterns

I took a different approach to how we have been navigating templates and pages. In previous designs, changing the page was more like swapping out content instead of navigating to that page. This, to me, feels like a way to accidentally change a template on a page.

Instead, I tried this, which, to me, feels more expected:

Try the prototype

One of the biggest differentiators is that selecting another page takes me to that other page and applies the template already assigned to that page instead of loading that page in the currently viewed template (unless they already use the same template.

There is still the challenge selecting content/placeholder content when creating a new template from scratch, but I think that can be resolved there.

Screenshots:

Source figma file

[MichaelArestad]

A further iteration with added functionality:

Try the prototype.

Noted differences:

• Added in ability to adjust some document settings as well as some document tools.
• Link UI now requires clicking "Switch page"
• Bonus "Set as home page" link that could show up on pages that meet the criteria

Screenshot:

Source figma file

[joanrho]

As I'm looking at this @MichaelArestad I'm starting to feel like the Document and Template selectors shouldn't live side by side in the top bar like that—they appear too similar to a breadcrumb nav, but they aren't. Instead, what if template selection lived in the Document side panel?

I was a bit confused by your latest direction that brings in the Status/Visibility elements from the Document side panel into the dropdown from the page selector. Is that just an idea or the direction that the Document side panel is headed? In your exploration, the "Switch page" jump to a nested submenu that's a different size/shape felt a bit jarring. Maybe it would feel better if the submenu was the same size/shape and had a "< Back" link up top?

[MichaelArestad]

They appear too similar to a breadcrumb nav, but they aren't

@joanrho Perhaps the design could be tweaked to deviate from the feel of breadcrumb?

what if template selection lived in the Document side panel?

That's not outside the realm of possibility. First, we're trying to explore these controls without too much reliance on the optional sidebar.

I was a bit confused by your latest direction that brings in the Status/Visibility elements from the Document side panel into the dropdown from the page selector. Is that just an idea or the direction that the Document side panel is headed?

It's just an idea.

In your exploration, the "Switch page" jump to a nested submenu that's a different size/shape felt a bit jarring. Maybe it would feel better if the submenu was the same size/shape and had a "< Back" link up top?

I didn't want to modify the current link UI (the search) just yet without good reason.

[mapk]

Moving the page to the left side is the better decision here. Thanks! ❤️ I agree that users will be looking to navigate between pages here more often than wanting to select different templates, so this makes sense.

I wanted to record my feedback I shared with you earlier. This centered menu's primary purpose is to allow a way to navigate between pages within FSE. The "switch page" option made this more of a secondary action. Can you create another version that keeps navigation surfaced as the primary action?

@joanrho brings up a good point about it looking like a breadcrumb. In our efforts to simplify UI elements, sometimes we're going to far and things are starting to look like unintended other things. Adding a dropdown arrow to these could help. Figma handles it like this:

[MichaelArestad]

Can you create another version that keeps navigation surfaced as the primary action?

@mapk If I'm reading right, you're looking for this version.

Adding a dropdown arrow to these could help.

I was thinking exactly that route.

[mapk]

If I'm reading right, you're looking for this version.

Haha. Yes. That works. I thought you may have been working on another version as well? If not, no worries.

[MichaelArestad]

I thought you may have been working on another version as well? If not, no worries.

Not just yet.

[MichaelArestad]

Update

I think scaling it back to be just the page switcher reduces confusion. I also changed the design to use the dropdown arrows within a button component just like the device preview button:

Try the prototype.

Screenshot

Figma source file

@joanrho Does this address your concerns?

[mapk]

This centered menu's primary purpose is to allow a way to navigate between pages within FSE.

I wanted to note that this is not the case. So working in navigation could cause more of a problem now. Basically, for navigating pages, we have the "W" that will open up navigation (https://github.com/WordPress/gutenberg/pull/22191) and we might include the ability to navigate through pages from the Nav block similar to the Customizer.

[paaljoachim]

Edit: 28th May.

The next natural steps.

1. Get a PR going that moves the post/page title to the top center so that we can get used to having the post/page title in the new location. I think there would be some experience from this important change that would help Full Site Editing.

2. A PR for the post/page title block. Which we can then add into the layout at will.

[paaljoachim]

EDIT: I reopened the Post/Page Title: Move to top bar issue to create a direct focus on getting the title to the top bar.

EDIT 2. I decided to close the issue as I feel it might take the focus a bit away from this issue.

[dubielzyk]

I had a look at moving the rest of Document Settings (which was previously together with the Block settings) into the top bar. The goal was to gather all the relevant settings and make the hierarchy of information more obvious. It also frees up the right hand sidebar to be all about blocks and plugins. Below you can see a quick prototype:

The popover can be organized in many ways, but here's a breakdown of my thinking:

Here are a few other variations of the hierarchy:

While this is a "waterfall" navigation (clicking a label, then using back arrow to go back), we could also go for more regular accordion, though the popover get tall very quickly:

Would love to know what you all think 😃

[shaunandrews]

I wonder if we could avoid the accordions, and do something with a flyout menu? Here's a crude mockup:

Or, maybe we can expand the width of the popover:

--

I also think it's worth reconsidering the existing groupings. Asking questions like: Do Permalink and Page Attributes really deserve their own groups?

--

Are plugins able to hook into the Document sidebar and add/change UI?

[dubielzyk]

Don't mind that at all either, the reason for going for the nested (where you click and go back) is so that it could scale nicely to mobile as well. How would this layout work on mobile? Does the whole width animate as you hover the "Featured image" item?

Do Permalink and Page Attributes really deserve their own groups?

Good point. They're probably not changed frequently so maybe having them under a larger "Page settings" could make sense?

[ZebulanStanphill]

I think we need to take a step back and consider the accessibility ramifications of all this. Is a big, stuffed dropdown in the middle of the top bar really the right place to put all this stuff? Consider also it's label, or lack thereof. Does that make sense to keyboard + screen reader users?

There are already some accessibility issues with the current design, e.g. #470. Let's try to make sure whatever changes we make improve the accessibility situation rather than make it worse.

[dubielzyk]

consider the accessibility ramifications

What specifically about the design isn't accessible? I'll get to fixing it straight away :) Are there any ideas you have of things I could change to improve the accessibility further?

Thanks for the comment. Wanna make sure we're consider accessibility properly for sure.

[MichaelArestad]

@dubielzyk Very. Nice.

Like Shaun, I also would prefer to live without the accordions. What would it look like if they were all just open by default and we let the user scroll?

[ZebulanStanphill]

@dubielzyk Specifically, the way the "Visibility" and "Publish" controls are handled is confusing for screen readers... and still kinda confusing for everyone else as well, since the buttons use labels that consist of the current state (e.g. "Public" or "Immediately"), rather than what the button does.

In #470, the current half-solution being discussed is switching to something more like what the pre-publish screen has, with accordions using labels like "Visibility: Public". That's still not ideal, as pointed out here, but it's an improvement.

I'm already working on trying to half-fix that issue with #24024.

[Lewiscowles1986]

Late to the show here, but one thing I recently (a few weeks ago) found frustrating, was that Gutenberg changed from October 2018 to May 2020, so I had no reference for where to edit the slug.

I was able to find it with some searching, but it is indeed hidden. Could the permalink / slug not be moved to the side-bar / kitchen sink area?

I really liked the title being part of the page / post content. I can see why you'd pin the title to the top, but for desktop and mobile, simply updating the document title should provide a similar effect and not interfere with the toolbar right?

[afercia]

I'd like to thank @paaljoachim for the ping in the Slack accessibility channel and @ZebulanStanphill for highlighting the most obvious accessibility issues in this proposed design.

The first big issue I see is that this design is proposing again to use the pattern that we're discussing in #470 since more than three years now. That is a pattern that many designers likely learned from mobile applications but it's an anti-pattern for accessibility, and for web standards even before accessibility.

Specifically:

• buttons and any interactive control need to communicate the available action
• they must not be used to represent a value or a state
• in the design above, I see they're used to communicate the post title and other stuff instead
• this is exactly the same anti-pattern discussed in #470 and, to be frank, seeing that is proposed again here it's surprising and also a bit unfair

Complexity:

• I see many of the proposed interactions tend to be very complex
• this is a problem per se, as complexity is a barrier for everyone
• regardless, any design should take into account at least basic keyboard accessibility: for some of the proposal here I'm not sure this has been considered enough

Semantics and expected behavior:

• semantically, the toolbar is a place for interactive controls (buttons) that "do things"
• it can't contain UIs to edit values or content
• it can certainly contain buttons that open other UIs to edit values or content or that open menus
• these UIs need to be separated from the toolbar, placed in close proximity in the DOM with the control that opened them, and have a "modal" behavior
• focus needs to be managed:
  • click on button
  • additional UI opens
  • focus is moved to the additional UI
  • once users are done, they close the additional UI
  • focus is moved back to the control that opened the additional UI

[dubielzyk]

Thanks for all the wonderful feedback. I'm excited about this collaboration.

Before I dive deeper on the specific visuals and the information architecture, let me try and break up the design and discuss the individual components to address the accessibility issues:

The controls/settings As per the feedback above, I've tried to improve the controls and values you can change. Hopefully they address the accessibility concerns as discussed in #470.

To improve the Visibility and Published controls, I've decoupled the action from the the value. So clicking the whole item or the arrow (which will have aria labels) will allow you to change any of the settings. Would love to hear if any of these options address the concerns above :)

The "container" To explore how we display the the controls themselves and the mechanism for how they appear

Which do you think is the most appropriate way of displaying this information? (Also, I know some of these have a scrim/dark overlay, but that could change, so just ignore that for now)

I'm still working on more explorations by mixing and matching a few of these, but would love to get some more thoughts as I dig deeper.

Other open questions:

• How can we make the top bar Page label/button more accessible?
• What settings live in the Document Settings vs what makes sense to relocate elsewhere?
• How can we communicate that the UI has changed to new and existing users (see tooltip idea below)?
• Should we keep Document Settings as is and just use the Top bar dropdown for permalink, theme and template? Where More settings could link to Document Settings? (See mock below)

---

In terms of the semantic behavior there's a few things that helps by having the document settings in the top bar:

• Firstly, the top bar becomes "all about the document" and the right sidebar becomes about the block and plugins.
• This simplifies it and makes it easier to access Document settings at any point.
• I believe this will increase the usability as the sidebar will only reflect the selected block and users won't be confused with Document settings showing up when a Paragraph block is selected.

In terms of keyboard navigation, I'll go deeper on that to make sure that it's easy and natural to navigate for everyone.

Would love thoughts on this and whether it's addressing the goals listed in the original comment, the following feedback, and accessibility concerns :)

[MichaelArestad]

@dubielzyk again, nice work!

Which do you think is the most appropriate way of displaying this information? (Also, I know some of these have a scrim/dark overlay, but that could change, so just ignore that for now)

Good question. Based on the design of the button, I would expect to see a popover. That said, a popover might be limiting in how and what you can present. A modal might be more flexible. Those are the two options with the highest potential value.

How can we make the top bar Page label/button more accessible?

I don't have a great answer for this one as several elements in the top bar face this challenge.

What settings live in the Document Settings vs what makes sense to relocate elsewhere?

I would start with:

• Status & visibility - seems directly related to publishing
• Permalink
• Template - alternatively, changing the template could be done in the Inspector

How can we communicate that the UI has changed to new and existing users (see tooltip idea below)?

A tooltip works okay. I think it would be good to put a banner or notice of some kind where the settings used to be for folks looking for them in a familiar spot.

Should we keep Document Settings as is and just use the Top bar dropdown for permalink, theme and template? Where More settings could link to Document Settings? (See mock below)

I'm in favor of moving the document settings, but you could link to them if they don't move.

[afercia]

Thanks @dubielzyk!

The controls/settings In the mockups above I see that 2) and 3) go in the direction identified in #470, which is to use the pre-publish UI pattern. I think both can work from an accessibility perspective. They would need some technical accessibility refinement on the code side to completely separate the text of the buttons to toggle the panels from the state, for example:

• "Theme" should be the only text of the button
• "Twenty Twenty" should be text outside of the button and referenced by aria-describedby

This should be implemented for all the buttons. This way it would work well for different assistive technologies e.g screen readers, speech recognition software etc. The button would be announced with all the necessary information (including the state as description). Speech recognition software users would be able to voice commands like "Click Permalink", "Click Theme", etc. and that would just work. An exception could be the i icon, which I assume is meant to be some sort of Help link? However, this is a technical detail that can be addressed during implementation.

Quick note related to the above mockup: "Published" is still a state, while "Publish" is the available action.

The "container" I'd think a modal dialog, or a "popover", or an expandable panel could work well as long as they have a modal behavior. As mentioned by @MichaelArestad a popover might be limiting though.

Open questions:

How can we make the top bar Page label/button more accessible?

I don't think this (see screenshot below) would work well for accessibility:

The text "Home" represents a state/setting. It should represent the action. In fact the design in the mockup implicitly acknowledges that and provides the missing information in the tooltip. The button itself should communicate the action. Ideally: "Edit page settings" but also "Page settings" could work. About the specific wording: I'd agree users aren't necessarily supposed to understand the term "Document" so it should be avoided. However, the term "page" could be confusing because of the difference between posts and pages in WordPress.

What settings live in the Document Settings vs what makes sense to relocate elsewhere? Should we keep Document Settings as is and just use the Top bar dropdown for permalink, theme and template?

I'd tend to think: move as many settings as possible 🙂 I do realize it's good to explore this carefully and proceed step by step. However, I'd tend to think this reorganization proposal makes fully sense in the context of a complete removal of the "Document" sidebar. The dynamic switch between Document and Block sidebar has always been a problem and maybe it's worth considering a drastic change. Also in the context of what you said about separations of concerns, simplification, ane better usability (which I'd totally second).

I do realize moving some controls from the Document sidebar to this new location would be a bit problematic, e.g. "Move to trash" would be buried down in the UI but I guess a solution can be explored. Worth also mentioning plugins can add their own content to the Document sidebar. This should be definitely taken into consideration and an alternative should be provided.

More settings could link to Document Settings?

This would be problematic for accessibility. The "jump" to a totally different place in the UI would be unexpected for many users and certainly confusing for assistive technology users. I do know WordPress 5.5 uses this pattern for the inline inserter, but that's not that ideal, sigh 😞

Firstly, the top bar becomes "all about the document" and the right sidebar becomes about the block and plugins.

+1 🙂 also to all the other points related to simplification and usability. With the notable exception that plugins can add their own sidebar toggle button to the toolbar and provide settings or whatever that may not be strictly related to the "document".

Other considerations:

1 Worth reminding an accessibility feature that is waiting to be addressed since a while is providing optional visible inline labels in the Toolbar, see #10524. The work done in this reorganization of the toolbar should preserve the ability to provide visible labels for the so called "icon-only" controls. A good amount of work has already been done to explore visible labels, see the efforts by @nicolad in #15830 and @tellthemachines in #24304 and #24234. Worth also reminding the "icon-only" controls have been flagged as an accessibility failure in the WPCampus accessibility audit, see #15311.

2 In the responsive view many toolbar controls are removed from the UI. The available space is very limited: where this new "Page settings" control would be placed? At this point, this control would be the only way to access document-related stuff and editor settings thus it should be always available.

[dubielzyk]

Thanks for the wonderful comments @MichaelArestad and @afercia! We're getting closer 😊

I've moved into prototyping mode so I could try it out (be aware I'm no dev so don't look for the perfect end result 😅). Here's a GIF of the prototype working with a popover:

A few things going on here:

• All settings in the Document sidebar will be transferred to this popover. We could reduce this over time if we find more natural places for it.
• There's no link to further settings like suggested above
• Removed tooltip
• The individual setting/toggles are similar to what they are today (single line), but below you can see how they could also look (double-line). Sounds like the double line below might be better for a11y (as suggested by @afercia)

A few questions:

• How does this work for everyone? Does it accomplish the goals while improving the usability and accessibility?
• Visually does it look alright?
• What is the right way to access the document settings via keyboard? Before the left hand tools or like the toolbar is organized? (See order below)
• Any other concerns or ideas come to mind?

Action items:

• Look at alternative ways to "trigger" the Document Settings (i.e. if not the top bar label)
• Finish up prototype
• Produce full mobile mocks

[paaljoachim]

This is looking very interesting! Having a center area drop down below the title of the page or post for the most important options seems like a very interesting and visible way to add a kind of summary of selections done in the settings area on the right side.

It is gradually becoming a new method of quickly viewing and editing options. This can be added to the standard Gutenberg content screen, the Widgets screen https://github.com/WordPress/gutenberg/issues/24561#issuecomment-679076734 in addition to the Full Site Editing screen. Perhaps other screens as well. The drop down options will be different based on the type of screen it is used in.

I look forward to testing this out as an experiment through the Gutenberg plugin -> experiments screen.

[johnstonphilip]

I really like that @dubielzyk

[mtias]

Nice exploration @dubielzyk. My main worry about transferring all the Document sidebar options is we lose the opportunity to give some order and hierarchy to those settings. 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. As mentioned a few times already, the way the document sidebar is currently used means plugins can extend it with their own panels and it does seem like it would break down if we contain all of it in dropdown menu from the title.

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. In that sense, let's also model one of the initial concerns of the issue about showing the template structure for the site editor, including possibly the currently focused template area at the root (header, footer, etc).