This is an ongoing reference issue containing the various aspects of native Gutenberg plugin support.

Blocks

Blocks are the primary interface element that plugins can leverage and build upon. The Block API is currently the most fleshed out aspect of the project. It generally covers:

• Adding new blocks — and the entire API surface of their configuration.
• Adding new category of blocks.
• Disabling certain blocks.

Another aspect of block extensibility is hooking into existing blocks to change or add functionality:

• Add toolbar or inspector items to existing blocks.
• Disable specific block functionality.
• Commenting API.
• Extending writing capabilities (i.e register tokens recognizable by Editable).

Theme Support

Some general aspects of the editor can be configured through an add_theme_support call, including configuring the default color palette and enabling wide/full-width options in alignments.

See more: http://gutenberg-devdoc.surge.sh/reference/theme-support/

There are several items that'd we want to allow themes to control, including disabling certain features like custom colors tools or certain inline styles, or maybe disabling certain blocks across the board.

Meta Data

Even though Gutenberg's primary focus is on the content, there are countless uses that fall outside of it. Given the lack of a proper content block editor, several solutions have evolved around meta-boxes to provide a more purpose driven UI for editing areas of a page or post.

Blocks should directly absorb a large number of cases where meta-boxes are used for content (a hero banner, a slideshow in the homepage, attributes of entities like book-author or price, etc) as the primary interface. The existing support for meta-fields as attributes allows the creation of blocks where the UI is directly manipulated as content but the data is saved as meta, so the block is not limited to where data is allocated.

Outside the Content

Blocks cover the realm of the content, but there are multiple use cases for meta-data that doesn't belong in the content (Yoast SEO tools, Jetpack's publicize feature, and a large etc). This functionality, inherently separate from content, has other dedicated places in the UI in an effort to more clearly convey the separation to users and optimize for the purpose of the tools at hand; namely:

• Block Inspector. (meta-data related to a block)
• Post Sidebar Panels.
• Publish Menu Flow.
• Header Toolbar.
• Ellipsis Menu (the "available apps area").

These are the current regions of the Gutenberg UI that plugins would be able to target as the Block API becomes stable and we can focus on them. [Include Screenshots and Concepts]

Elements like the state tree for the block list or the post configuration would be exposed through helpers and selectors for these contexts (outside the block) to allow plugins to consume and interact with it.

Global Blocks

With the work being done around global blocks, this would also become another potential area for plugins to extend Gutenberg by providing ready-made global blocks.

Custom Post Types

Custom Post Types can vary greatly in the focus point they have—some are merely taxonomical while other configure the UI in various ways, to the point where a "the content" area doesn't make sense anymore (think WooCommerce orders). Gutenberg respects the editor support as declared by a CPT and won't load if that is not supported. It also won't load is show_in_rest is not set.

Furthermore, a CPT should be able to declare default blocks, default set of blocks (nested group), or blocks that should not be allowed in the CPT.

---

Mockups

Note, these are mockups. They are subject to change and feedback. We may find in implementation, details that don't work. Please open mockups in a new tab to see the details.

Block Comments

Plugins could extend the block-level menu to add contextual actions, such as the ability to add comments.

This interface could also be used for plugins such as spell-checkers or content analysis tools.

Collaboration

The ellipsis menu is a good place to add document-level tools and actions:

Plugin Sidebars

The post settings sidebar can be toggled off, either so that it can be invoked as a modal on mobile, or you can dismiss it if you don't use the content within. This also allows us to toggle other sidebars, including ones added by plugins. Here's what a WolframAlpha sidebar could look like:

Screen Takeover Modal

If a plugin needs a vast amount of space, for example to show configuration tools, we can let them take over the entire canvas in a modal

Pre-publish Checkup

Some information is the most useful when it is shown to you in context of the publishing act. Things like scheduling and post visibility. It's also a space where plugins can add useful last-minute checkup notices, such as an SEO or readability score, or perhaps a way to customize a publicize-to-Twitter message before publish.