Block directory design explorations

[MichaelArestad]

We need a place for folks to browse and install blocks in both wp-admin and on WordPress.org. I recently proposed a prototype on the Make Design blog. I will reiterate the main points here for discussion and then go over the changes.

The prototypes

Here is an updated version of the wp-admin prototype.

And here is the WordPress.org prototype.

The block directory

The directory page is where blocks can be perused or searched quickly. You can see how the page looks in both the wp-admin context and the WordPress.org context below. The design is nearly identical with the only deviation being the page header.

Page header

The page header on the WordPress.org page is the current standard so I will only be discussing the wp-admin version here as it deviates from the current header.

Here is what the current page header in wp-admin looks like:

And here is the iteration I am proposing:

The biggest changes regard the order of the content. With the new header, the order is page heading > page description > actions.

Block cards

Both directories contain the block cards that contain a block icon, block name, block author, and ratings. All other information will be seen on the block detail view. The preview is a square because the block’s example can vary widely in its aspect ratio.

The block detail view

The block details view shows all the block's plugin information. I attempted to reduce it to just the necessary information to make a decision about a block.

The most useful information for a user is at the top. It includes ratings, active installations, compatibility, the block version number, and the install button.

The demo

The Demo section is an example of the block that a user can interact with. It is important the user gets a clear idea of what they’re about to install. The editor itself will be an instance of Gutenberg with some slight customization.

In this iteration, the editor is framed and has a few more controls like the block list and a toggle for the block inspector. The frame and additional controls will be important later on when used for patterns.

Should the demo editor have a minimum height? Should it resize to fit the content? Should the height be constant?

Reviews section

This includes the ratings and two reviews. It also provides an action to encourage a user to rate the block.

Mika suggested we need to come up with a way select the two visible ratings based on:

• The current average ( try to be within 1 full point of the average)
• Recent reviews
• Number of reviews
• User ‘status’ (that is, don’t show banned/deleted/anon user reviews, even if the review stayed up, but also if the user is listed as a plugin supporter or contributor, don’t show that review)

Details section

The details section show some of the more useful information in an organized grid.

Contributors

Just like before, it shows a list of contributors. Is this section useful? Should it be moved into advanced details?

Get help

I made a point to keep this section concise. It leads the user to the forum if they have trouble. In further iterations, we could maybe add a search to let the user search for their question before leaving this page.

Advanced details

This is essentially a toggle which, when clicked, shows the user all the charts and tools available on the advanced details page.

Note: I would like the charts to be the width of the column, but I couldn't get them to do that quickly for this prototype so we'll have to user our imagination here.

I made no major changes to the content or tools here.

Changes from the previous iteration

• Examples were added from current WordPress blocks to help stress test the block card design
• The install button is now a bit more prominent
• The demo now has a frame with slight elevation along with actions for Block List, Editor Information, Preview, Inspector, and the more menu
• The demo is now as wide as it can be. This will be valuable when used with patterns and I would like this design to work for both blocks and patterns
• Reviews have a call to action and some minor tweaks to the ratings chart. I removed the "See all" action
• Tags have been given pill boxes similar to how tags appear elsewhere in WordPress and in the directories
• Contributors has been added
• Get help has been added
• Advanced view has been added
• The WordPress.org views have been worked through

What's next?

I think it's time to start implementing parts of this design and iterate on specific patterns as need.

In the immediate future I plan to work out more fully:

• The upload flow
• Advanced details as its own page again. I tried a modal and it felt off. I think the show/hide behavior also isn't quite right so I'm going to try a couple more things.

[iandunn]

I like it. The one thing that stuck out to me was that the demo doesn't have a heading like the other sections, so it feels a little unclear. It's one of those things where I can guess what it is, but would feel more comfortable if there was an explicit label.

There may also be a11y issues if there isn't a semantic label? It may also be an opportunity to let people know that it's an interactive editor, rather than a screenshot.

[MichaelArestad]

I like it.

@iandunn Thanks!

The one thing that stuck out to me was that the demo doesn't have a heading like the other sections, so it feels a little unclear. It's one of those things where I can guess what it is, but would feel more comfortable if there was an explicit label.

That's not a bad idea. I initially dropped the label as it felt a bit out of place due to the editor frame, but I'll work one back in.

[MichaelArestad]

Here are a few options. The first labels the editor in the toolbar at the top of the editor. I don't love this as it's the spot we will be using for other actions in the editor around templates.

The label works pretty well if I remove the frame. That said, the frame adds some value in that it helps identify what is editable. I could maybe try reworking the frame a bit.

Perhaps something like this that is a bit of a hybrid could work?

[iandunn]

Yeah, I like that hybrid approach 👍🏻

[MichaelArestad]

Backing up a bit, I want to take a second to show what this could look like in an actual flow (rather than a component breakdown). Here is a prototype that goes through the flow: I am on my dashboard and I want to install a block.

The flow is very similar to the flow for adding a theme.

1. Go to the Appearance menu item and then to the Blocks submenu item.
2. Click the Add Blocks button in the header.
3. Browse for a block.
4. Click Install. Note - I don't think blocks need an extra step to activate. I think they should be installed or removed.
5. The block now shows as installed in the directory list and shows up in the Installed section of the Blocks page.

Prototype changes

• I moved the Blocks menu location as I think it's closer to appearance/widgets/etc. I also reduced it to being one menu item.
• The header has changed for now to be closer to the Gutenberg toolbar.
• The installed blocks page has a couple sections including a “Default” section. The Default section will be important when it comes to managing the visibility of blocks in the block inserter.
• On the Blocks page (installed blocks), I added a three dot menu that contains visibility settings and a way to delete a block. These actions will be covered in a separate flow (though you can see them in the prototype).

Next steps

• I will look at ways to display hidden blocks on the Blocks page. These are blocks that a user has chosen to hide from the block inserter. I think they could either have their own section or the block card could have some visual treatment to indicate the block is hidden. Then, I will create a prototype just for the flow of "I want to unhide a block from my block inserter."
• I will create a prototype dedicated to searching flows starting with: "I want to find a grid block."