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:

Browsing

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


Searching

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.


Details

Path

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.


Preview

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