Scope & Features: MVP

[mtias]

Editor Feature Complete

The following is an overview of the major functionality to be introduced by the new WordPress editor, helping visualize what has been done and what remains to be done in terms of product scope.

✅ Shipped

• Block-based editing experience with 20+ blocks (in addition to several embeds).
• Writing flow that seeks to hide interface while engaged in typing and shown when editing.
• Inserter with quick search and memory of recently used blocks.
• Adaptive design that works on all devices.
• Support for static and dynamic blocks.
• Plugins and themes can register new blocks.
• Easy keyboard navigation across blocks using arrow keys.
• Quick inserter shortcut with “slash” command.
• Multi-selection with ability to move or delete a group of blocks.
• Auto-formatting text conversion to blocks (e.g. bullet points into lists, hashtags into headings, etc).
• Pasting from Word, Google Docs, Apple Pages, HTML, WordPress, and Markdown.
• Drag & Drop media uploads with single or multiple images.
• Ability to specify keywords for discovering blocks in the inserter.
• Classic block for handling unrecognized freeform-content and multiple paragraphs.
• Ability to transform a block into other block types.
• HTML editing mode per block.
• Document outline navigation with heading roles and word count.
• Ability to convert old WordPress posts into new WordPress blocks.
• Auto-embedding and auto-linking when pasting URLs.
• Formatting boundaries for links, code, strong, and italics.
• Pre and post publishing flow.
• Autosaving support.
• Ability to display toolbar controls next to the block or at the top of the editor.
• Undo / Redo functionality across blocks.
• Suggest a post format based on which blocks are used.
• Grid galleries with auto-cropping.
• Grammar parsing infrastructure with nested blocks support.
• Conflict resolution flow for externally modified blocks.
• Graceful handling of removed blocks (e.g. when a plugin is disabled).
• Keyboard shortcuts to jump focus around regions of the interface.
• Placeholder functionality for blocks.
• Custom CSS classes per block.
• HTML Anchors (id attribute) per block.
• Toggleable sidebar menu for a more focused experience.
• Support for translations within blocks.
• Support for extending core blocks.
• Support for theme customizations applied to blocks.
• Support for saving block attributes as post-meta.
• Support for Custom Post Types.
• Support for Custom Taxonomies.
• Support for Shortcodes.
• Support for current meta-boxes.
• Inline autocomplete system (used for @mentions but easy to extend with custom tokens).
• Ability to transform shortcodes into blocks during pasting or conversion.
• Templates with default blocks.
• Ability to lock blocks within templates (cannot be moved or deleted).
• Site-wide reusable blocks.
• Block versioning and migration support.
• A collection of components for building your own blocks with consistency.
• Utilities to store and access editor data.
• Multiple width positions: center, wide, full-width based on theme support.
• Configurable color palette.
• Ability to copy the entire post as HTML.
• Error handling on a per block basis.

And these are the last few big pieces of functionality to be built before we can wrap the first feature-complete version of the project.

It goes without saying that this list doesn't cover all the indispensables for merging into core (like bugs, further polish, missing REST API functionality, missing accessibility requirements, block API tuning, ongoing usability testing feedback, final front-end display tweaks, etc) and that some items in the "Shipped" list need further tweaks.

⭕️ Remaining

• Nested blocks UI. Blocks: Support block nesting (Add Columns block, InnerBlocks component) #3745
• Child Blocks API.
• Complete extensibility and hooks outside of blocks. See project.
• Block API: style variations. Create unified UI for block variants #783
• Drag & Drop functionality for moving and adding blocks. Reorder blocks via drag & drop (v2. using editor dropzones). #4115
• Handling inline images. Insert images inline #2043
• Local storage saving of post data. Store (some) data offline in parallel to posting it to the API #7367 — stable APIs.
• Block API: server registration. — stable APIs.

🦕 V2 (customization)

• Layout system that is easy to customize. Try: Editor Grid #4314

🌀 Bonus features

• Footnotes. Add Footnotes Support #1890
• Collaborative editing between two peers.
• Per-block commenting.
• Bundling block assets.
• API for async-loading capabilities for block assets.

[maddisondesigns]

Any update on the ability to change the page template or edit the Permalink?

[markkap]

Have to wonder who exactly defined this as "MVP"? I do not remember any slack discussion in any of the main developer chats, not a "make" post open for discussion. Requests for a definition of the content of the project on github went un answered.

Specifically for me an official API to turn gutenberg off, at least for the first few releases until it is stabilized and bugs and design problems are worked out is a must and should be part of any MVP.

yeh yeh yeh I know what @pento said, but with all due respect this is a decision for the community to make, not a decision of one person.

[mtias]

@maddisondesigns changing the page template was merged in #4662. Editing the permalink was added in #3418 but reverted due to UX issues. Should come in one of the future releases as part of the merge proposal milestone.

@markkap this is just covering what we have been working on and what has been on the radar for the plugin version of Gutenberg. It doesn't cover the merge proposal or what would be shipped in 5.0 — we might remove certain features, add others, etc.

[markkap]

@mtias cool, but since we are supposedly about a month away from the merge proposal, isn't it time that there will be a discussion about what is the MVP for a merge? (rhetorical question, you do not have to answer)

[mahdiyazdani]

Looks great so far.
Any idea when the merge may happen?

[johnbillion]

@mtias A couple related questions for when you have the time.

• Has there been any further discussion within the team about the state that Gutenberg should be in before it's ready for a merge proposal? For example, how up to date do you think the Merge Proposal milestone is? (https://github.com/WordPress/gutenberg/milestone/22)
• In retrospect, the introduction of the REST API into core suffered a bit due to lack of real world usage before it was merged (as demonstrated by the discovery of missing data in the API that was surfaced by real world usage of the API in Gutenberg). How much and what type of real world usage of Gutenberg does the team expect and want before it's considered ready for a merge proposal? Related to that, Expose available blocks via an API #4116 came about due to real world usage, and I would consider it a blocker, but it's not currently in a milestone. There are probably other similar tickets.

Thanks!

[mtias]

Has there been any further discussion within the team about the state that Gutenberg should be in before it's ready for a merge proposal?

Mostly in the context of what wasn't part of the "feature complete" milestone. There are various high-level issues that had been discussed in multiple places, including REST API issues, packages and JS modules, cleaning function names, hook documentation, etc. Probably the best is to have a core dev chat once we wrap the "feature complete" milestone to discuss this and figure out the next steps.

For example, how up to date do you think the Merge Proposal milestone is? (https://github.com/WordPress/gutenberg/milestone/22)

For the most part, yes. Though it hasn't had a lot of dedicated attention, and some things might not be necessary for a merge proposal provided we add them for the betas. This is something we need to discuss. It's likely that the merge proposal itself will bring things more into the light and more people would engage, which would be very beneficial, so that's also something to keep in mind.

How much and what type of real world usage of Gutenberg does the team expect and want before it's considered ready for a merge proposal?

As much and as varied as possible, while being aware that this could also be an endless effort. There's the item, punted from 4.9, about showing a notice in wp-admin for trying out the new editor. That might be something we'd want to look at in the coming weeks for a point release once we feel comfortable with the experience. We are also likely looking at beta testing on WP.com around a similar timeframe to get more broad feedback and usability testing running in parallel.

My current thinking is along the lines of getting things ready and polished enough for merge proposal so that we can do broader testing with it. The whole process for 5.0 is very much something we should discuss more broadly and with more participation.

Related to that, #4116 came about due to real world usage, and I would consider it a blocker, but it's not currently in a milestone. There are probably other similar tickets.

Just added that to the merge proposal milestone. It would be great to get more help from core contributors during the triage sessions @jeffpaul is running on Thursdays to cover more ground.

Thanks for the questions @johnbillion !

[bobbingwide]

I have some questions and concerns.

As an outsider, how can I be assured that the product is anywhere near satisfying the functional and non-functional requirements. I don't know what's in scope, what's out of scope or how complete anything is. This is a complex project with many more risks than there have been in the past. I've been trying to get close to the project but really have no idea of the big picture.

According to "Our philosophies", Every version of WordPress should be easier and more enjoyable to use than the last. While this may be true for a new install, I see very little concern for existing sites.

I would like to know what each stage of the project will deliver with regards to the reference documentation that will be required by any user/developer who has a problem.

• Are the following included?
• If so, when will they be addressed and what's the current percentage complete.
• If not, why not.

Deliverable	Note
Blocks	Summary of blocks in scope / out of scope.
Embeds	Summary of embeds in scope / out of scope.
Meta box mapping	Visual documentation of the changes - a pre-req to merge proposal.
Block migration	Summary of limitations. Confirmation of potential loss of data.
Backward compatibility	Summary of limitations and how to resolve problems.
API	Including tooling and programming guide for plugins and themes

I'm not aware of any trackable plan. I'm not even sure if there is a plan for the plan.

[mtias]

This issue has run its course.