Block Directory V2

The blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. directory will be a place where blocks can be perused and installed. Think of it as a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party directory limited to single blocks.

Back in December, @melchoyce proposed a prototype for a block directory. That prototype is still 100% viable for the block directory. It is likely the simplest to implement as it’s pretty close to the existing plugin directory with a few nice systematic updates to patterns used across wp-admin.

When I picked up this project, it made sense to me to try a variation of what @melchoyce created . I decided to see what a block directory might look like if it shared Gutenberg’s design language. To accomplish this, I tried using similar patterns and styles to what is seen within GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. since the block directory and Gutenberg are so closely tied together. I also have been keeping block patterns in mind when designing.

The feedback I’m looking for

This is a hopeful proposal and none of what I propose here is set in stone. I would like higher level feedback around the interactions. Do the interactions make sense? Is it clear what you’re looking at? What are the designs missing or lacking? What could be improved?

I’m not looking for detailed design feedback like hover states or border colors. Those are important for sure and that type of feedback will be needed during implementation.

The prototype

Here is a rough Figma Prototype that shows a handful of the views in the block directory. Take note of questions you have as you look through it and please share in the comments below. I hope most will be answered as I break down each of the primary design patterns and views. 

Try the prototype.

The block card

The block card is designed to be a recognizable design pattern that, even without a preview, will convey that it is a block. You can see we already have a similar card proposed for implementation in Gutenberg’s block directory search.

I tackled this in a few places. To start, I identified block cards that can convey the most important information about a block at a glance. This is where I started diverging from the existing plugin directory.

I deviated from using a plugin icon and plugin headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. for two reasons.

  1. Blocks already have an icon by nature. This icon will be one of the main identifiers when interacting with blocks. I wanted to reinforce the connection with the block icon and the block as soon as possible. Thus, I replaced the plugin icon with the block icon.
  2. Blocks and Patterns are very visual. Rather than showing a somewhat arbitrary header image, I opted to show a preview of the block.

I trimmed down the amount of information present on the card. In this mockup, I show the Block Name, the Author, Rating, and Number of Ratings. I may add an indicator of active installs. Everything else will be shown on the Block’s Details View, which a user will need to navigate to in order to install a block.

The preview is a square because the block’s example can vary widely in its aspect ratio. We will need to do some work here to figure out the scaling and overflow details of previews.

The directory header

Mel designed an iteration of the wp-admin page header that makes great use of space, order of interactions, and hierarchy. I made very minor modifications to it resulting in what you see below. Ideally, this pattern could be used across all wp-admin sections.

It’s very simple. It has a page title, a description, primary actions, and secondary actions. The page title and description are exactly what you would expect. The primary actions are below the description and, in this case, include a search bar and upload button. The secondary actions are the help and settings buttons.

The directory view

The directory view is a combination of the header and groups of block cards.

Like the current plugins directory, the blocks will be in categories with “See all” links for folks who want to peruse a specific categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging..

The CTA banners Mel designed are ace so I expect we could use them as a way to highlight any number of topical subjects. Perhaps they could be used to promote block collections if we decide to go down that road at a later date.

The block details view

The block details view shows all the information surrounding a plugin. The current details view for a plugin relies heavily on a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. Much of the sidebar information seems directed at plugin developers.

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 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. The inspector will remain visible because many blocks rely on the sidebar controls.

The Reviews section shows two reviews along with rating totals. I would like your thoughts as to which reviews should show.

There are still some remaining pieces of information I would like to incorporate including contributors, a changelog, and a support section of some sort. This is also missing the Advanced View. Perhaps some of those missing items will fit better there.

wp-admin design implications

These designs include patterns that could be used elsewhere in wp-admin. For example, we could use the directory header pattern on the other directories and perhaps on all wp-admin pages. This would be one of several steps to align the design language of wp-admin and Gutenberg.