An alternative metabox flow

[karmatosed]

We currently have the metaboxes at the bottom. This experience has a number of issues, not the least being it feels 'tacked on' as an experience. The size is limited and it feels awkward.

A possible alternative flow would keep the visual integrity and usability of the current Gutenberg experience, this is something having the metaboxes at the bottom breaks. Currently we are in danger of a halfway, lesser experience, we can do better so let's explore that.

Props to @mtias for exploring this visually and providing mockups to include in this issue.

The ellipsis menu would list available meta-boxes by title. This builds on a strong pattern we have already.

When a plugin 'has native gutenberg' support, they get a dedicated view instead of the generic metaboxes view:

[kevinwhoffman]

We still need to keep in mind that historically meta boxes have been used as primary content editors. When I updated to Gutenberg 1.5, the result was that my entire screen (which had been populated with ACF meta boxes) now appeared blank. Some of my ACF meta boxes appeared in the Extended Settings, which was collapsed by default and below the fold.

Both the Extended Settings drawer and this "dedicated view" approach would result in a similarly negative experience for users expecting to see a complete UI when they edit a post. They would both hide an interface that was otherwise immediately accessible to them.

[karmatosed]

@kevinwhoffman could we ease the issue a little with some guiding message on first load if you have metaboxes? There is a plan for a guiding nux and this could fall into that.

[kevinwhoffman]

@karmatosed It's more than a matter of discoverability. It just doesn't make sense for the default edit screen to be an empty Gutenberg block editor if it's not intended to be used.

This is the same issue I mentioned back in #952 (comment).

To reiterate, there needs to be a presentation mode that allows meta boxes to be the primary mode of editing. This has implications not just in custom themes using ACF (or similar) but more broadly with any plugin that uses meta boxes in custom post types. In these cases, there are often multiple meta boxes working together, so splitting them up into one per screen as shown in the mockup would not be helpful.

While I understand the long-term plan to convert meta boxes to blocks wherever possible, we still need a solution to present meta boxes in a way that doesn't feel like a step backwards so that the first impression is not the empty canvas that I experienced in 1.5.1.

[maddisondesigns]

I agree with what @kevinwhoffman has said above. Hiding the custom fields behind that dropdown is even worse than the Extended Settings panel that's there now. As I mentioned in #3141 for most custom sites where a developer is utilisiting something like ACF or even their own custom fields, the content shouldn't be treated as though it's just secondary to the main edit field. In most cases, its the most important content and in a lot of cases, the main TinyMCE edit field isn't even used.

Hiding custom fields behind the (hidden) Extended Settings panel or worse, behind an icon that literally means nothing, is a really horrible idea and for the average user, they will have no idea that they'd be able to access editable fields via that icon. (Very few users have any idea on what that 3 vertical dots menu is supposed to represent)

I'm creating a site at the moment where I'm using a CPT for adding a list of stores. The main TinyMCE edit field is only used for entering a short description of the store, which is only a very, very tiny part of the content that's collected. The majority of the content is collected using custom fields, including complex fields such as Repeaters and Google Maps. These custom fields NEED to be visible as soon as the user enters the edit page. Even gathering information as simple as an address, isn't as easy as adding one textarea. Each part of the address needs it's own field as schema microdata needs to be added to each part of the address to identify it, when displaying it on the front-end. Hiding any of these fields from the user would basically render the page useless.

As a reference, here's an example of the edit page that I'm talking about above...

[StaggerLeee]

I do not like it. Again this attitude Gutenberg content is more worth than content from custom fields and metaboxes.
Just becase you are coding it do not discriminate other things in post edit screen.
Third party developers should keep right to chose preview of Metaboxes under Gutenberg similar to old screen, if they want to.

Anyway if you chose to stay on bottom preview add some left-right padding od 20px instead of 12px. And differentiate in style what is metabox header and what metabox content block, or some margin-bottom between metaboxes. Difficult to know now what metabox is expanded and what collapsed.

[steveangstrom]

I agree with @kevinwhoffman @maddisondesigns
Here are a couple of examples of work for clients showing the primary importance of Metaboxes as the main way to enter content. The examples are from a membership feature (adds a protected files and links facility) and a Property plugin.

In all cases of my work the metaboxes are the primary data entry areas. Clients use the content area only to add intro-texts or ad-hoc links and unformatted info.

Apologies for the Gaussian blur, and the vast image height on the Property plugin. Hopefully you can glean enough meaning from the blurry metabox layout.

[StaggerLeee]

I have one suggestion.

• Trash all this old Metaboxes design and look, and make them appear, appear, as Gutenberg blocks.
• Allways last in blocks order.
• Anything Gutenberg block wrappers can do make it for Metaboxes to.
• Some kind of "Iframe Gutenberg block", I do not know really.
• If some specific Metabox does not fit in smaller wrappers developer can make it more responsive.

Making dedicated screen for Metaboxes you just prolong conversion time from old way to Gutenberg blocks.

[viktorbijlenga]

I agree with @kevinwhoffman.

We still need to keep in mind that historically meta boxes have been used as primary content editors.

This is important to keep in mind. In a lot of use cases meta boxes has been used to make the content editing experience easier for editors. Sometimes paired with the tinymce editor and sometimes just as metaboxes.

Gutenberg is solving a lot of interesting problems related to content creation for a single output structure, where the input is outputed by the WordPress loop trough the_content().

For everything else I would argue that custom meta boxes is used to make editing of complex layouts and logic of where content is possible to edit - possible.

I would like to see a view where custom meta boxes could be selected to be the main view and Gutenberg experience is to be used as a boxed editor for the_content field.

Gutenberg would then be a way to create content, not the way to structure everything. Similar to how TinyMCE works today, but a far more competent editor for content which is suitable to be structured as one.

[SukcesStrony]

Hiding metaboxes under a dropdown? No, just no... Please ask anyone who runs a site that isn't a personal blog and absolutely needs to fill in fields such as SEO and custom-coded boxes...

[mtias]

I would like to see a view where custom meta boxes could be selected to be the main view and Gutenberg experience is to be used as a boxed editor for the_content field.

It should be possible to allow that if either there are meta-boxes registered, or a CPT/plugin opts into it; totally something on the table.

That said, the overarching plan for Gutenberg is for it to expand beyond the post, at which point those previous interfaces would grow increasingly legacy to the user.

[jnicol]

I want to echo the sentiment expressed by other commenters: The idea of hiding metaboxes on initial load is a step backwards. For anyone who uses WordPress as a CMS metaboxes need to be the focus of the editing UI, not hidden behind a dropdown menu.

I would like to see a view where custom meta boxes could be selected to be the main view and Gutenberg experience is to be used as a boxed editor for the_content field.

That is exactly what I want to see too. Custom fields need to be first class citizens in the editing UI.

@mtias It is heartening to hear that Automattic are considering an option to opt out of the Gutenberg experience when custom fields need to be the focus. That would solve backwards compatibility in the short term, but doesn't sound like an ideal long term solution if it leads to a split editor experience: #3330 (comment)

[laras126]

This issue seems to get at a fundamental divide in the types of websites we build with WordPress:

1. Developer-built, custom websites: Content and design are dictated by a developer, and clients are directed as to how to maintain the site. By design, they have little to no control over the display. These sites are successful (and expensive) because of their restrictiveness.
2. End User-built websites driven by themes and plugins: This is where Gutenberg would shine as an alternative to page builders. A plugin like Yoast needs to be present (preferably not in an iframe), but in essence, is secondary to content.

Perhaps Gutenberg, as it is currently is positioned, isn't applicable to website type 1, and doesn't need to be. These sites are designed with the intention of keeping content and display as separate as possible, while Gutenberg fundamentally meshes content and display. I would guess many developers building WordPress websites in this fashion would disable Gutenberg out of the gate. They don't need it nor want it.

That being said, in my own ACF-driven websites I sometimes have a "free-form content" area that consists of my own system of blocks using ACF's flexible content field. I've seen similar solutions from other developers, and if it were to be good for something in type 1 sites, Gutenberg could be an alternative to these free-form content blocks, but it would need to function as part of the page, not the entire page itself.

tl;dr - +1 on Yoast's solution.

[aurooba]

I build ACF-driven websites that operate on the concept of components just like @laras126 mentioned, which is why I think Gutenberg is awesome - it fits perfectly with my philosophy. Eventually, I'd love to create all my custom components as blocks available within the Gutenberg editor for my clients. But for components that are less about content and more about meta data, this is not necessarily feasible. Which is why metaboxes need to integrate with the rest of Gutenberg - not just as an alternative 'view'. They are just as important and should be treated as such.

[I've never contributed to these discussions and now I've commented on two different issues in one day..both related to metaboxes. So I guess that's one good thing out of this all, instead of a silent observer of the developments, I'm actually voicing my opinions..because this all literally affects my work and business)

[youknowriad]

But for components that are less about content and more about meta data, this is not necessarily feasible

Blocks can save to post meta and with the upcoming "template feature", you can decide to always show these blocks and "lock" (do not allow moving them) for a specific post types which I believe will address this concern.

[fklein-lu]

Making abstraction of the technical nitty gritty, i.e. in an ideal world, how would the Gutenberg user experience deal with adding data to posts that is not visual?

Like for example Open Graph meta data?

[robmaurizi]

Regarding whether Gutenberg should be the primary method of content entry, I could see an option in register_post_type() like 'use_gutenberg' that could default to true and be the default setting for pages & posts, but that developers could set to false on their own CPTs and built-in post types.

I can also see the argument for having certain meta boxes / field groups available as a block within the Gutenberg editor. In the past, I've done up ACF groups for configuration that get implemented within the content area via shortcode (e.g. a carousel or some other bit of more complicated inline content). These kinds of custom content configurators would be great candidates for blocks, so perhaps a second bit that can be set at the add_meta_box() level that could would indicate to the editor screen that a particular metabox / field group should be treated as a content block within the default Gutenberg flow or as traditional post meta that would live below the editor.

These options could mitigate the blank editor screen situation where all of the editing UI is hidden, as well as allow the option for more robust field groups that could live within Gutenberg as blocks.

[maddisondesigns]

Forcing developers to create custom Gutenberg templates, not only just for editing, but for also displaying on the front-end is really going to slow down site development. At the moment, it literally takes me about 5 minutes to create a complex set of fields for custom data collection using ACF. There's no way creating a custom Gutenberg template and all the associated blocks, is going to be that easy to create. And if it's anything like the Customizer, it's going to be an absolute nightmare to develop for.

[youknowriad]

At the moment, it literally takes me about 5 minutes to create a complex set of fields for custom data collection using ACF. There's no way creating a custom Gutenberg template and all the associated blocks, is going to be that easy to create.

The templates are the low level API, I expect ACF to adapt and use them or an alternative to ACF will come up to do the same using block templates just as easily as ACF.

[maddisondesigns]

I expect ACF to adapt and use them or an alternative to ACF will come up to do the same using block templates just as easily as ACF.

Why should ACF have to completely change to use Gutenberg templates? ACF creates Custom Fields which are part of WordPress core. Are you saying that WordPress has every intention of phasing out Custom Fields/Meta Boxes? Gutenberg needs to work with the existing core functionality. You shouldn't be forcing every other plugin to change because of how you've decided to build Gutenberg.

[youknowriad]

ACF will still work with Gutenberg (or fallback to the old editor automatically if not compatible), I'm saying longer term, Blocks will be first class and I recommend for plugins to rely on the Block API instead of MetaBoxes. By the way Blocks and Gutenberg Templates can use Custom Fields.

[youknowriad]

Metabox support is already here, open specific issues if encoutered and Gutenberg Native extensibility is discussed in #3330

Should we close this in favor of #3330

[mtias]

Going to close this as we have made a bunch of progress in both default meta-boxes and new ways to extend Gutenberg.

[coffeeneed]

What @viktorbijlenga said. Gutenberg is the_content();.