Block Library: Installing Blocks from Within Gutenberg

The Design Team provides user experience, user interface, and visual design expertise for the WordPress project.

Want to get involved?

Welcome! This all-volunteer team needs designers of various kinds. See our handbook and drop into #design once signed up for volunteer opportunities.

Our vision is to be the go-to resource for design for other teams across the WordPress open source project.

With the introduction of Gutenberg and blocks comes the need for a way to install new blocks, just like plugins or themes. Step one in this project, for the design team, is installing blocks contextually within Gutenberg. Check out this thread for more details and prior explorations.

Scope

The WordPress.org API will provide an endpoint for searching for blocks by name and description, and return metadata similar to that of plugins. Gutenberg’s Inserter could use that endpoint to also show relevant block plugins that are available to install, with a button and process for seamless installation.
@tellyworth

This project is limited to installing one block at a time from within the Gutenberg editor. That might encompass:

How people discover blocks from within the Gutenberg editor
How to give users enough detail to make an informed decision about which block to install
How uninstalled blocks are previewed
What the Install process would look like
What happens if the installation fails
Removing installed blocks
How to manage installation requests by non-admin users

This scope is intentionally kept small so we can focus on shipping an iterating. A larger exploration of how to download or install blocks from within a Blocks screen in wp-admin, and WordPress.org, will take place in a future project.

Timeline

Task	Stage	Facilitator	Due	Status
Create repo	Scope	@karmatosed	April 26	✅
Create project board for design tasks in GitHub	Scope	@karmatosed	April 26	✅
Create issues in GitHub for design	Scope	@karmatosed	April 26	✅
Make/design kick off post	Scope	@melchoyce	April 26	✅
Make/meta kick off post	Scope	@tellyworth	May 3	✅
Competitive analysis	Research	@melchoyce	May 17	✅
Competitive analysis summary post	Research	@melchoyce	May 17	✅
Experimental explorations	Exploration	@melchoyce	May 24	✅
Flow diagram	Exploration	@melchoyce	May 24	✅
Iterate on experimentations	Refine	@melchoyce	May 31	✅
Make/design post of designs	Refine	@melchoyce	June 7	✅
Prototyping (click prototype/Figma)	Prototyping	@melchoyce	June 7	✅
Testing/feedback on prototype	Prototyping	@melchoyce	July 5	✅
Update GitHub issue to start development	Development	@melchoyce	July 5	✅
Prototype (technical prototype)	Development	@tellyworth	TBD
Testing/feedback on prototype	Development	TBD	TBD

See the complete timeline on Google Drive.

Where to Follow Along

There will be weekly or biweekly updates here on make/design.
There will be time during each weekly Design meeting on Slack for updates.
Design tasks will exist as issues on GitHub; you can follow along on on our project board.
Development will also be happening on GitHub.

Get Involved

Interested in joining @iviolini and I on this project? Let us know in the comments, and follow along on GitHub.

If you don’t have time to devote to working on design tasks, that’s cool — feedback is always welcome, and a great way for you to contribute.

#block-directory, #block-library

Monique Dubbelman 8:42 am on April 27, 2019

For starts, I love the project board on Github and how this is broken down into smaller tasks. It makes it way more easy for people to contribute.
- ibdz 9:12 pm on May 2, 2019
  
  I’m happy to help with design experimental / explorations 🙂
Matt Cromwell 1:28 am on May 9, 2019

With the introduction of Gutenberg and blocks comes the need for a way to install new blocks, just like plugins or themes. Step one in this project, for the design team, is installing blocks contextually within Gutenberg.

Bold emphasis mine ^^

There’s a large logical and experiential leap between “installing blocks like plugins and themes” to “installing blocks within Gutenberg”. Gutenberg is an editor (of course Phase 2 and 3 make Gutenberg MORE than a content editor, but still, this conversation seems to be around installing in the editing experience), it is not a module manager, or plugin installer. This is scope creep and I think it’s very ill-advised.

The WP plugin authors have already provided many good ideas regarding block management which are far better than building block installation into an editor. Keep Gutenberg about editing/managing content NOT about managing blocks.
- David Ryan 5:17 pm on May 9, 2019
  
  I hold similar concerns with @webdevmattcrom to including the Block Directory inside Gutenberg. This concern was raised repeatedly on the proposal and hasn’t been publicly addressed as this project has gone forward.
  
  The problem statement in @tellyworth‘s post is:
  
  Gutenberg needs to provide a way for users to discover and install new third-party blocks without ever leaving the editor.
  
  @melchoyce Have we validated this assumption? I’ve yet to see any data shared that shows this is a problem users are expressing and/or want solved in-editor.
  
  It appears the assumption and decision to include in-editor was made prior to even publishing the proposal for a Block Directory.
  
  I’d love some clarity on this and discussion of alternative ways to tie the Block Directory to the editor without directly installing from the Gutenberg interface.
  - Mike Schinkel [WPLib Box project lead] 7:42 pm on May 10, 2019
    
    Only one data point, but with my user hat on I would like to be able to “discover and install new third-party blocks without ever leaving the editor.” #jmtcw
    
    (But as a developer and admin, I would also like a separate page for managing blocks.)
    - Mel Choyce 10:16 pm on May 13, 2019
      
      I agree we should have a separate page for managing blocks — installing/activating/deleting block plugins, managing reusable blocks, maybe converting the Block Manager dialogue into a tab on this manage screen, etc.
  - Mel Choyce 10:14 pm on May 13, 2019
    
    I think we’ve likely been framing this too much as a feature, rather than a user problem; the overall user goal is to make sure no one encounters a dead-end when searching for blocks.
    
    For example, imagine a user wants to insert a “slideshow,” but gets a “no blocks found” message. In that case, it seems like a good next step to say, “but we can browse the directory for you!” the same way Siri or Alexa might say “but I can browse the web” when they don’t have an answer for you.
    
    Or, another example — a user might import content on a fresh WordPress install that relies on specific blocks. What happens when you load up such a post without the block installed? It’s broken, and currently, we don’t necessarily tell you how to fix it. You’ve hit a dead end.
    
    I also think of this project as analogous to the theme preview feature in WordPress. Before you install or activate a new theme, you generally want to preview how it looks on your site. I feel the same way about blocks. Before I install a block, I want to be able to preview how it looks on my page and what kind of options it provides. (I wish I could do this with feature-driven plugins, too!)
    
    I think previewing is the most important part of this project, but the installation process doesn’t necessarily have to happen inside the editor itself. We could, alternatively, open a dialog similar to the “plugin info” dialog we already have, or redirect people to an external block management screen. Everything’s open to discussion 🙂
    - David Ryan 1:34 pm on May 21, 2019
      
      Thanks for explaining further @melchoyce! I think there’s great value in adding helpful pointers and context within the editor.
      
      To put in a metaphor, if Gutenberg is the kitchen and the Block Directory is the grocery store, I think having some kind of “Amazon Dash button” to quickly order up missing ingredients is terrific. My concern boils down to trying to put an entire grocery store in the real estate of the kitchen pantry.
      
      The same way we offer to search the Plugin Directory for the query when searching installed plugins and none are found sounds great. I don’t mind a popup UI that loads after the user takes an action agreeing they want to discover more… The concern boils down to injecting the entire Block Directory into the Block Inserter and distracting cooks during their cooking flow.
      - Mel Choyce 3:18 pm on May 21, 2019
        
        I think that’s an apt metaphor, and these are all really valid concerns. Would you be willing to follow along with the explorations over the next two or three weeks and provide feedback with these concerns in mind?
Mike Schinkel [WPLib Box project lead] 7:50 pm on May 10, 2019

Just my two cents, but I would like to see blocks handled individually instead of the approach plugin vendors are using to add 1000+ blocks with their plugin when I only want to use one or three (I exaggerate, yes, but for emphasis about the type the problem.)

That may or may not be part of this process, but if not I hope it can be added to this process.
- Mel Choyce 3:15 pm on May 13, 2019
  
  This is the current plan!
Mel Choyce 8:28 pm on June 3, 2019

Updated the timeline to account for some upcoming travel, including WCEU.