Consider rewriting the wordcount/document outline feature as an extension

[jasmussen]

The editor bar right now contains, from the left:

• Insert
• Undo
• Redo
• Document Structure (word count)
• [space]
• Save state
• Preview
• Settings
• [future extension area]
• Ellipsis overflow

The Document Structure takes up highly valuable real estate on the left, where the most important button of them all, the inserter, sits. It even has a similar roundish icon. While we could look at addressing that, instead what if we rethought the position and feature a little bit?

We would rewrite the feature to be a native editor extension (see #3330), enabled by default. You'd be able to "unpin it" just like you can unpin a sidebar, at which point you'd have to get to the feature in the ellipsis menu.

Quick and dirty mockup:

[mtias]

I like using this as an example of an extension with a popover (one of the simplest extensions you could write).

[gziolo]

Nice 👍

[youknowriad]

cc @atimmer since you're working on the sidebar plugins

[karmatosed]

Really like this idea :)

[mtias]

since you're working on the sidebar plugins

Worth noting this doesn't render on a sidebar at all.

[youknowriad]

@mtias True, but this might share pin/unpin feature with the sidebar plugins. I'm thinking registering the plugin should be similar and you just change between sidebar/popover using a "type" or something?

[gziolo]

I still think we should follow PHP part of WP and build the whole extensibility layer based on hooks API (actions and filters). I strongly believe that this is one of the key factors why WP is so customizable.

[mtias]

I'm thinking registering the plugin should be similar and you just change between sidebar/popover using a "type" or something?

My thinking was that a plugin would have a "render" method and they would use a sidebar slot or a popover.

[youknowriad]

still think we should follow PHP part of WP and build the whole extensibility layer based on hooks API (actions and filters)

We have specific APIs in the PHP side for similar use-cases (aka metaboxes :) )

My thinking was that a plugin would have a "render" method and they would use a sidebar slot or a popover.

This moves the burden of handling the "show/hide" flag to the plugin author while it can be implemented if it's just a render method returning the content of the popover/sidebar. I may be wrong though, I guess implementing this will answer these questions.

[atimmer]

I was thinking about this and considered a more abstract API. I've posted it on Slack: https://wordpress.slack.com/archives/C02QB2JS7/p1515576014000052. I'll repeat it here for posterity:

wp.editor.registerUI( {
  // (...)
  type: "sidebar", // This could be "sidebar", "popover", or "screen". And maybe others.
  render: () => { // Renders the content inside the available location.
  // (...)
} );

(Could also be called registerPluginUI, or something else)

All these different types can have the starring functionality to make it possible for users to make any plugin a first-class citizen. We could then have ‘dumb’ wrappers for registerUI called registerSidebar, registerPopover and registerScreen that make plugin code more expressive.

I think we can also have actions and filters to do the same things. I think we should also have these. That could make more advanced functionality possible if desired by a plugin author. Such as opening both a sidebar & a popover from a single button click. I don’t know why you would want this, but one part of creating a vast ecosystem is allowing things you cannot imagine yourself.

Edit:
I don't know how a popover would work if the button to get there is only in the ellipsis menu. Maybe a popover only makes sense if it is an icon in the toolbar.

[jasmussen]

☝️ this features a "pin" icon, allowing you to pin or unpin this. It's quick and dirty, would like to polish it more, but it conveys the point.

To recap the ideas for this kind of extensibility right now, they are:

• Every plugin that extends the editor gets a menu item in the more menu. Invoking this item invokes the plugins primary action.
• Plugin actions could be to open a sidebar, or to open a screen takeover, or to run an action (such as spell check) directly.
• Plugins can register a pinned extension icon next to the cog but before the more menu. These are plain svg icons that are recolored to be solid gray.
• A user can unpin any extension icon that a plugin has pinned. The user can always use an unpinned plugin because the action will always be available in the more menu.
• The way to unpin (or pin) an extension icon is currently the weakest aspect of the mockups, but right now they have you tap a star to toggle pinning, hollow for unpinned, solid for pinned.

[karmatosed]

@jasmussen this looks good to me as a starting point.

[aaronjorbin]

I've moved this to Future due to lack of recent traction.

[youknowriad]

Is this still something we want to do? Shouldn't we consolidate the block navigation and the document outline instead?

[gziolo]

I personally think that block navigation should be replaced by an improved way of using keyboard navigation to quickly switch between blocks rather than keep this separate UI element which duplicates content.

Regarding rewriting Document Outline as an extension I think it should be doable at the moment given that we have all components required ready:

• Modal - we can open a modal when opened through More Menu.
• Tooltip - we can keep the existing behavior when pinned to the header.
• PinnedPlugins - we can pin it by default next to the cog icon.
• PluginMoreMenuItem which adds an item in the More Menu which can open a modal or tooltip.

The question is if this is important enough to invest our time on it at the moment. Do you see how this could benefit other features in core? Where could we replicate the same behavior?

[afercia]

I'd agree with @gziolo: not sure investing time on this is worth it. Also, worth considering the document outline is not just about words/elements count. It contains the headings hierarchy checker, which is greatly important for a well structured post. See also the discussion during yesterday's dev chat about the headings level in the .org network.

I'd like to remind this was one of the features that received a spontaneous applause from the audience during the Gutenberg demo at the State of the Word 2017 🙂Burying it into the ellipsis menu as a "pinnable" feature doesn't seem ideal to me.

Instead, I'd greatly appreciate some focus on #10581 to put a small notice in the sidebar heading inspector and warn users when they use an incorrect heading level.

[youknowriad]

The block navigation is very important for nested blocks too.

[jasmussen]

Worth pointing out the block navigation is not the topic of this thread. In that vein,

Shouldn't we consolidate the block navigation and the document outline instead?

Yes, either the document outline gets merged into the block navigation, or it gets rewritten as an extension. The meta-point of this ticket is to simplify. There's a lot of stuff up there, and the more buttons you have, the less value each button has. So if the two buttons can become one, then as far as I'm concerned that solves this ticket for me. If there's an existing ticket to merge those two, feel free to close this one in favor of that.

[jasmussen]

Closing this in favor of efforts in #19344.