Block Library: Competitive Analysis Recap

Over in GitHub, contributors have been exploring potentially related “competitors” for inspiration we can apply to the Block Library project. I’ve pulled those out into groupings:


I’m not convinced we need a browsing interface within the Editor, but it’s important to explore how it could potentially work if we did decide to go in that direction. It’s especially important for us to look at what other people are doing within our space, like Ghost Kit and the Gutenberg Blocks Template plugin.

Outside of WordPress, discovery and browsing sections of apps provide interesting ideas for how we can tackle exploration. For example, I really like Medium’s “New from your network,” and can see something like that translating into something like “more blocks from developers you trust.”


Snapchat and Vine

I think how Snapchat and Vine combine(d) results from people you follow, along with people you don’t follow, is pretty analogous to searching for blocks in your library — and especially useful if you have no results:

The Monday app also makes use of animation when searching, which provides an extra layer of delight.

No Results

Bear and Reddit have cute No Results screens, but none of them make suggestions for what to do next, which I think is going to be the critical hook for suggesting new blocks to install. No one should ever get “stuck.” This is where I think the “Browsing” examples are key — rather than showing an empty screen if there aren’t results, we could showcase downloadable blocks instead.



Having some sort of details screen can provide opportunities to persuade people to install your block. Like plugins, we should consider letting block creators add screenshots, descriptions, and more details to help market blocks.

Path in particular took a really nice approach with their detail dialogue — it’s visually appealing, makes great use of animation, and provides plenty of space for information.


The Jetpack examples are obviously a bit more of a direct comparison. The last two mockups, especially, are a good example of using existing core patterns to preview blocks within the editor. I can easily see this extending to our use case, where “upgrade” is instead “install.”

I think it’s going to be very important for people to preview new blocks in-context — a “try before you buy,” if you will — and so we’ll want to further explore how we can make that a seamless experience.

Based on these explorations, I think it would be good to tackle our next phase, Exploration, by breaking it up into different tasks:

  • Discovering blocks through searching, or maybe browsing
  • Previewing a block in-context
  • Installing a block
  • And even what happens when loading a page with missing blocks (we already handle this, but it’s not connected to re-installing or re-activating the missing block)

Does this approach make sense?

Does anyone have any other examples that could provide inspiration?

#block-directory, #block-library

Block Library: Installing Blocks from Within Gutenberg

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.


The 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.


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, will take place in a future project.


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 TBD May 24
Flow diagram Exploration TBD May 24
Iterate on experimentations Refine TBD May 31
Make/design post of designs Refine TBD May 31
Prototyping (click prototype/Figma) Prototyping TBD June 7
Testing/feedback on prototype Prototyping TBD June 14
Update GitHub issue to start development Development TBD June 21
Prototype (technical prototype) Development TBD June 28
Testing/feedback on prototype Development TBD July 5

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

Call for design: Installing blocks from within Gutenberg

The Problem

Gutenberg needs to provide a way for users to discover and install new third-party blocks without ever leaving the editor. We are looking for a volunteer to lead the design part of this project.


Currently, new Gutenberg blocks can be provided by plugins, which often register many blocks, and which are managed from outside the editor. The Block Directory proposal outlines a new type of simple block-based plugin that is intended to be seamlessly installed from within Gutenberg itself. This is one of the 9 priorities in the 2019 roadmap.

The 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. Some early sketches of ideas have been made, such as these:

(Note that these are all merely explorations and visual ideas, not set in stone)

It will be important to give users enough information about available blocks in order to make an informed decision – which might include the author, review ratings, and so on – without overloading them with too much information.

One key feature that might help improve the user experience is to allow users to insert a preview of the block into their document first, before installing the plugin, and then use the preview to make their decision about whether or not to install it.

Decisions to be made

As of now, there are some ideas sketched out and some general requirements as outlined above. There is work already on the block management feature, which is tangentially related. But there are many decisions yet to be made. Work needs to begin soon if this is to be ready in time for the WordPress 5.3 release later this year.

Some of the main design issues that need to be resolved include:

  • How and where to show search results within the Inserter
  • How to give users enough detail to make an informed decision about which block to install
  • What the Install process would look like
  • How to display a preview placeholder
  • How to manage installation requests by non-admin users

Get Involved

We are looking for a volunteer designer who can manage this project and commit enough time to see it through to completion in time for the 5.3 release. Responsibilities would include:

  • Solving the experience and designing the interface
  • Collaborating with other designers, soliciting feedback and reviewing submissions
  • Creating issues, wireframes, posts, and designs
  • Working with Gutenberg and Meta developers
  • Organising and running user tests
  • Iterating the design based on feedback and results
  • Meeting the deadlines to include the necessary changes in the WP 5.3 release

Given the nature of the work and the time frame, we expect that this is a project that will need a minimum commitment of at least a day a week, and possibly considerably more at times.

If you think you might be the right person for the task, please make yourself known to the Design Team during the weekly meeting, Wednesday 18:00 UTC in #design. Or alternatively, leave a comment below.

#block-directory, #design, #plugins, #ux