Investigate about potential Gutenberg overlaps

[raaaahman]

As we know, the Gutenberg team is on its tracks to modernize WordPress in a lot of places.

• Do they plan to modify the admin bar?
• Can, or should, the notifications be WordPress blocks in the end?

Also, the Block Editor already implements notifications of its own.

• Should we include them in this more general notification system, or should they be separated?
• Could they serve as guidelines for this project?

[jasmussen]

Hi! I've been working on the block editor for a while, and hopefully I can provide some very high level answers. Always feel free to also ask these questions directly in the #core-editor slack channel.

One high level thing to note, about this:

As we know, the Gutenberg team is on its tracks to modernize WordPress in a lot of places.

The block editor has spawned a range of NPM components, WordPress Components, for JavaScript contexts. Any plugin developer making use of these inherit both the consistency and coherence it will bring, but also get the built in benefits of a component set that gets updated with improvements along the way. Still important to emphasize, these only work in JS/Node environments.

Do they plan to modify the admin bar?

As part of the WordPress project overall, I would love to see design improvements to the admin-bar. But I'm not aware of any plans, and given it's not in a JS context, I'd look for any conversations around this on the main WordPress project trac.

Can, or should, the notifications be WordPress blocks in the end?

Blocks, to me, make the most sense when there's an editing environment attached. I'm not sure if that's in the cards for notifications. However if the notifications project is a JS/Node project, it would make total sense to use WordPress components!

Also, the Block Editor already implements notifications of its own.

Sort of, I'd like to refer to them as "Notices", or the very popular phrase "Snackbar" aka "toasts". I think of these as intrinsically more contextual and/or transient than the notifications I imagine the WP Notify project bringing to bear. First off, notifications in the block editor are always related to the editor context, and almost always specific to the document being edited, such as:

• You're offline, we can't save your changes.
• Your post was published, click to see it.
• You copied a block.
• You copied all content.
• An older revision of this document was found.

Should we include them in this more general notification system, or should they be separated?

Because the notices/toasts in the block editor are very contextual to the editor, I'd probably just look at their component counterparts (Notice, Snackbar), but otherwise not include them.

I would also personally like to see the Notice pattern more or less retired entirely, as far as is possible, as I can't recall a single wp-admin notice that did not feel unnecessary or abusive/spammy/like an advertisement. But I trust that there's nuance here which needs to be handled smartly.

Could they serve as guidelines for this project?

I would love to see visuals from the block editor UI help inform the notification UI! Some of the principles about visual simplicity feels like it could benefit projects like these. There's also this new Figma file which so far catalogs the component work and icon efforts for WordPress and the block editor, in case it's helpful.

[folletto]

The block editor has spawned a range of NPM components, WordPress Components, for JavaScript contexts.

As far as you know, is there anyone that has already used in a good way WordPress Components outside Gutenberg? Just because if it's good, and we can reuse the same approach, it helps reaching best practices. 👍

I would also personally like to see the Notice pattern more or less retired entirely, as far as is possible, as I can't recall a single wp-admin notice that did not feel unnecessary or abusive/spammy/like an advertisement. But I trust that there's nuance here which needs to be handled smartly.

Yes exactly. I agree the snackbar is probably very contextual and — at least for now — we shouldn't include. I think that once there's an API, if later WP Admin is extended differently, we can always change the way the same API gets rendered.

As for Notices, you're right: the problem is that if we don't provide them, plugins that have a revenue stream they'll just figure out their own way to promote. If we provide a sensible way to promote, then we can provide both good promotions for authors AND a decent experience for users.

As for everything else, massive thank you.

[senadir]

is there anyone that has already used in a good way WordPress Components outside Gutenberg

WooCommrece Admin and WooCommerce Blocks uses them outside the editor

WooCommerce Blocks builds interactive react-powered blocks that use those components on the frontend of stores (Cart/Checkout/Product catalog/filters).

[erikyo]

I think talking about this now is a little bit old-fashioned :) Moreover, it was the right way!