Block Directory in WP-Admin Concepts

You may have spotted during @matt‘s Summer Update at WCEU a new wp-admin section for Blocks. I wanted to share those early concepts here.

View Figma Prototype

About Blocks

Rather than jumping straight into a list of blocks, I wanted to explore what an introduction to blocks could look like as a landing page. This page could feature some links to tutorials (that could open either externally, or in a modal), some basic FAQs, and a support link.

You’ll notice the new header style, inspired by the new Health Check screen and built on some concepts from the Design Experiments plugin. This new section provides a good opportunity to expand on this pattern, and to show how it could benefit WordPress users by providing context to each screen.


Add New Blocks

This section is largely inspired by wp-admin plugin cards, and the WordPress.org plugin details screen.

I also think we should update across wp-admin as well, since the current modal feels very outdated and doesn’t present information as cleanly or as organized as the .org modals:

Inside the modal, you’d also be able to demo a block before installing. @ck3lee has figured out how to make this possible 🎉

We’d tap into the Shiny Updates framework to make installation and activation quick & easy.

The upload flow would work the way plugins do — I’ll flesh out some designs around that in future iterations.


Installed Blocks

This screen would be a list of all installed third-party blocks, so you can activate, deactivate, delete, etc. in bulk, using a traditional list table. I’ve added an “instances” link, which would show all posts and pages the third-party block is being used in.


Manage Blocks

This is the screen I’m most “meh” about, which is pretty much a duplication of the block management modal inside the editor. I think we need to have this management available within this section, but I’m not sure if this is the best approach to tackling it.


Reusable Blocks

Currently, the only way to reach the Reusable Blocks screen is through either the block library inside the editor, or a link in the settings dropdown in the editor. Putting it in a new Blocks section gives it an easier-to-find home.


Feedback

These are still early concepts, so it would be good to get some early impressions. Specifically, I’d like everyone’s thoughts on:

  • Thinking through the flow of managing blocks on your site, does it feel like any important tasks are missing from these concepts?
  • Would you expect any of these screens to be combined?
  • Can you think if any stress cases these screens will need to account for?
  • What would you like to see next for the Block Directory? Are there any other block management features you would benefit from?

#block-directory

These look great! I’m digging the large white header areas on the admin screens. I’d be curious to see if on the “Manage Blocks” screen, if there’s a way to make each block a little more visual, just so you can see something (you do have icons there currently) to clue you into which is which. Once you start adding block packs they do tend to be named similarly.
Is there ever a future need for certain blocks to be enabled/disabled in different contexts? For example, a block type that makes sense in a widget area but not in the post content. If so, could this screen have some sort of context selector (tabs, select box, etc..).

I’d be curious to see if on the “Manage Blocks” screen, if there’s a way to make each block a little more visual, just so you can see something (you do have icons there currently) to clue you into which is which. Once you start adding block packs they do tend to be named similarly.

I’m going to try @boemedia‘s tab and collapsing section suggestions, which would provide more focus on individual categories. I think with that extra focus and space, I could maybe try giving each block a card, or try more of an inserter-like appearance. If you can think of any good examples or interaction patterns that could be relevant, let me know!

Is there ever a future need for certain blocks to be enabled/disabled in different contexts? For example, a block type that makes sense in a widget area but not in the post content. If so, could this screen have some sort of context selector (tabs, select box, etc..).

I feel like that should be built in by the block creator, though there is potentially a need for conditionally disabling blocks based on user type or permissions.

Can you think of any other cases where we might want to contextually disable or enable blocks?

I’m really liking the direction here, but I have to second your “meh” on the management screen, that is a LOT of options, I worry about the cognitive stress from trying to manage that screen, especially once you take into account the mass of blocks starting to show up out there.

Yeah, it definitely won’t scale. I thought about making each category into a list table instead, but… that also feels pretty gross. 🤷‍♀️

It might be “meh,” but it’s a lot easier to deal with on its own page than in the editor itself. I don’t think there’s really a way to keep dozens of blocks from being a bit overwhelming.

Would tabs work for this section? Or even one accordion/toggle for all the sections?? To not have everything opened at once and have a better digest of the information?

@boemedia @wpfangirl Need to work through all the states, but here’s an idea for managing blocks using tabs & list tables:

Block Directory_ Manage_tabs

I like it. Especially the list of instances, because being able to know where I’ve used what blocks is helpful.

Hey Mel,
Great work overall.
However I really don’t think the tabs work. It is so overwhelming, I really think we need to start moving away from this list view that we see everywhere. I prefer the boxed view because you see everything at once, and it still feels easier, especially if the dropdown’s are hidden on landing.

> :I also think we should update across wp-admin as well, since the current modal feels very outdated and doesn’t present information as cleanly or as organized as the .org modals:

I agree, and we should also consider pulling the modal content itself from the w.org API, so as to be able to better keep these in sync for the future. Just in a general sense, I have no specific details to offer for this at present.

I really like the overall design and can’t think of any important missing task.

Is there any related Trac ticket of GitHub issue for some more extended feedback? I have some 🙂

For now, I’d like to point out the main H1 heading should really be the first thing within the main content area. As visual order needs to match the DOM order, that requires to review the placement of the “Add New”, “Help”, and the “More” buttons. More detailed explanation on this old Trac ticket for the Help and Screen options, see http://wayback.fauppsala.se:80/wayback/20200301163124/https://core.trac.wordpress.org/ticket/21583#comment:56

Right now I am a bit confused. The screen “Installed Blocks” looks a little too close to the plugin screen, that I can’t tell if it would list only single blocks or also block collections? The example “Block Gallery” is a actually a plugin that offers 3 different blocks in the inserter.

I keep thinking it would be really helpful to see the multi-block plugins up as well. However reading through the previous communication and screens, it seems that’s not the case. This block directory is announced to be only meant for single blocks.

In my research of blocks plugins (about 100 of them already) there are as many single block plugins as there are multi-block plugins. There are block collections with 30 or 40 additional blocks. If the goal is to streamline block operations, keeping multi-block plugins off this screen will not accomplish that goal. The disconnect will continue. The reality is that the Block Directory seems to be a solution for 1 in 40 use cases.

I anticipate there might be a method for the multi-block collections to register their individual blocks for this “Installed Blocks” screen and I would hope we can do a grouping per plugin, so those are easily identified. It would help to visualize how those blocks are handled as well.

In any case, for each individual block, I can see a need for additional link/checkbox for enable/disable the block for the inserter right from that screen, in additional to the Block manager that’s is available via the Block editor.

On the block manager screen, I really like that they are all in the same category and order as in the inserter and now all visible on one screen, without the need to handle an accordion interface… It’s so much easier to handle.

Being able to access reusable blocks from the WP-admin menu is wonderful. The number of instances is a really helpful information, as I find myself creating reusable blocks, but at the end not using them… I also might find it helpful to have a “Created on” date in the list as well as information who created it.

I would personally rather see the people who make the block collections break them up. It’s really annoying to have to install a collection of 30 blocks in order to be able to use the 1 block that isn’t in all the other collections.

But I would hope that the total list of installed blocks would include all the blocks in collections. It’s not clear from @melchoyce‘s mockups whether it’s meant to, but some of those block collections have block managers that identify the blocks in other collections, so presumably it could be done here too.

But I would hope that the total list of installed blocks would include all the blocks in collections. It’s not clear from @melchoyce‘s mockups whether it’s meant to, but some of those block collections have block managers that identify the blocks in other collections, so presumably it could be done here too.

I hadn’t thought about that, but it does make sense. Even if you can only install single blocks, we should still list collections as well, maybe with each block listed out under each collection. I’ll try out some ideas. Thanks @wpfangirl @birgitpauli 🙂

Anyone who doesn’t think this is a hard problem hasn’t tried to do it. 😉

I think that’s really great. I often use the reusable blocks and it’s extremely cumbersome to edit them. This interface would make our work easier. I’d really like that!

Great work so far, Mel! Here’s my feedback:
(1) Installed Blocks page
• the design is similar to the Plugins page, which is good for continuity. But shouldn’t there also be some visual aid to set the 2 pages apart?
• Also, I’d like to have a filter and/or search field to find things easily.
• I agree with Birgit about including block collections plugins.
(2) Manage Blocks page
• I like the functionality of what you did, yet it does feel clunky. I like Monique’s suggestions re: accordions and tabs. Maybe restrict the width to 2 columns to reduce the sense of “clutter”?
• For block collections, maybe add subsets showing what each collection includes

• the design is similar to the Plugins page, which is good for continuity. But shouldn’t there also be some visual aid to set the 2 pages apart?

Can you tell me more about your thoughts here?

Great work. In the “Add new blocks” section it would be interesting to have a search feature in a prominent position.

> I’ve added an “instances” link

I’d double check with the Gutenberg team if that’s technically possible. I doubt it is, as normal blocks are “fictional” entities that exist only while editing a post. They’re not referenced in any way in the database, there’s no way to count them or determine which posts they’re used into. They’re just part of the HTML “blob” saved as `post_content`.

Only reusable blocks can be counted, because they’re stored as a special post type.

Thanks, I wasn’t aware of those technical constraints — I’ll check with the team to see if it’s at all possible.

We should be able to make it work.

For example, to count the number of column block instances, we can perform a query like so:

SELECT COUNT(*) FROM wp_posts
WHERE post_content LIKE '%<!-- wp:columns%'

You can see that this functionality already kind of exists in WP Admin:

1. Navigate to All Posts
2. Search for `”<!– wp:columns"` (be sure to include the `"`s)
3. Observe that a list of posts which contain a columns block is shown

One problem is that we'd have to run a query like the one above for every block type which might be prohibitively slow. I’d suggest using pagination so that e.g. only 20 block types are shown at once.

Another problem is that it’s difficult to do this for reusable blocks without making assumptions about how reusable blocks are serialised. I’d say that’s an okay assumption to make, though.

Hello @afercia, @melchoyce, @noisysocks and the wider community!

Given the doubts expressed here about the feasibility of the suggested method for counting block instances, we wanted to let you know that we had already implemented it – for Reusable Blocks specifically – in the plugin Fabrica Reusable Block Instances: http://wayback.fauppsala.se:80/wayback/20200301163124/https://wordpress.org/plugins/fabrica-reusable-block-instances/

We count instances using more or less the suggested method (checking presence of the block’s comment tag) though we add a little additional SQL trick to count multiple instances of a block within a single post.

The performance is excellent: very fast queries! So hopefully this will serve as a proof of concept and save you some time.

Awesome, thank y’all so much!

Further to that, we’d argue that it’s not really structurally consistent (or intuitive) to have Reusable Blocks as a submenu of Blocks.

Reusable Blocks are user-generated content, and therefore on a par with Posts, Pages, Media etc; whereas Blocks are the abstract containers available for creating content, which in a sense puts them closer to Themes and Plugins, as ‘components installed/available for me to build my site with’.

In FBI (the plugin mentioned above) we simply change two properties of the `wp_block` post type object as follows [...]
$args->show_in_menu = true;
$args->_builtin = false;
$args->labels->name = __('Reusable Blocks');
[...]

This exposes ‘Reusable Blocks’ as a top-level menu item alongside Posts, Pages where our users/editors can manage their Reusable Blocks content. As Birgit (@bph) notes above, this works extremely well for content creators.

The rest of the Block admin is maintenance-related and unlikely to be accessed as frequently, so arguably it would make more sense to put it in Appearance, alongside Themes / Plugins? Or Tools or Settings? Or if it’s been decided it must be a root level item, as `Blocks` but in the lower half of the menu, grouped with the other Maintenance stuff and similarly only available to users with certain permissions.

On a totally different note. In these screens I miss screens to manage block “layouts” and/or block templates. Such sets or combinations of blocks are really handy for the editors of the site. It is a nice way to make the use of blocks easier, especially when there is a massive amount of blocks.

The Atomic Blocks plugin has such a concept of “Layouts” built in (sets / groups / combinations of blocks). As an editor you can easily insert a group of blocks with this layouts feature. It would be great if managing layouts (groups of blocks) like that is added to these manage block screens too.

What do you think about this? Is this handy, feasible? Or stretching things too much?

I think this is a great idea. I’m not sure we’re there just yet — layouts in Gutenberg still feel pretty primitive in core, compared to what they could be — but as the feature evolves we’ll want to have better ways of actually managing and editing layouts. That might belong here, or might belong in a separate page under Appearance. Either way, definitely something to keep in mind.

@hanheg and @melchoyce I might have misunderstood, but since Reusable Blocks can in fact contain multiple blocks, they can already be used in this way… if you follow the Manage All Reusable Blocks link in the block inserter (or install our plugin as mentioned above to expose it in the main menu) you can do Reusable Blocks > Add New and create and save a layout of blocks which can be embedded into any Page / Post.

The question of naming is one to discuss / resolve, ie. how users will know that Reusable Blocks can in fact function as layout templates.

Reusable blocks can be used as a basis for reusing a block or set of blocks. But beware, reusable blocks is a different CONCEPT.
The idea of reusable blocks is that it’s EXACTLY the same block (or set of blocks) you are using across your site. That is with exactly the SAME CONTENT.

Of course you can insert a reusable block and than turn it into a normal block and than adjust the content. So that in fact you are reusing only the layout and not the content.
But in my opinion/experience this is pretty counter-intuitive for end-users.

That’s why I think it’s good to do something with layouts/groups of blocks in the block directory admin screens. Maybe not right from the start, but good to keep in mind so that it can easily be added later-on.

Ah yes, @hanheg, exactly – the functionality already exists but the naming / UI is not intuitive.

I’m not sure if it’s the same functionality. The current reusable blocks for reusing CONTENT is typically something you only do for a single site.

The reuse of a layout (group of blocks) can be done on a single site but the interesting thing would be that you can reuse the layout (only the layout) on other sites. Like with the Atomic Blocks plugin.

At the moment it is not possible to apply a reusable block on another site, is it?
Also, that would be strange because than you would get really strange starter content, as that would be copy from a totally different site you might not even know.

First of all great work Mel!

Here are some of my comments :))

Installed Blocks Page:

I agree with comments about this page being similar to Plugins page. I would prefer this page to feel more blocky. I feel a blocky view may be better than a list view (more like the widget sections of the WP dashboard)

Manage Blocks:

I did leave this comments already as a reply, but i thought it’s helpful to gather it in one place. 
I think that the tabs design feels really overwhelming. I really think we need to start moving away from this list view that we have in WordPress at least for blocks. I prefer the boxed view because you see everything at once, and it still feels easier, especially if the dropdown’s are hidden on landing.