You don’t need edit access to use the Figma libraries, you can copy components from there into your own drafts. If you’re a contributor with the ability to grant edit access, please be mindful, and downgrade to view access once the initial need for edit has waned.
The blockBlockBlock 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 pluginPluginA 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory limited to single blocks.
Back in December, @melchoyceproposed 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 GutenbergGutenbergThe 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. https://wordpress.org/gutenberg/ 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.
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 headerHeaderThe 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.
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.
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 categoryCategoryThe '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 sidebarSidebarA 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.
Building the new BlockBlockBlock 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 in wp-admin presents us with a couple opportunities to redesign certain existing patterns, and turn them into reusable components. When we revisit future admin pages, we’ll have these components available to replace the older patterns.
Here’s some updated patterns we can turn into components for this project.
Page Headers
There are tons of pages in the WordPress admin. None of them are consistent.
I’d previously explored a consistent headerHeaderThe 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 admin pages, but it still felt subpar:
When I started working on the Block Directory, I wanted to take another stab at a header that could work across the entire admin. These were roughly based off of Material’s headers, then adjusted and improved to fit our use cases.
Page headers consist of the following elements:
The page title.
A short description of what this page is and what it’s for, ideally only a sentence or two long.
Action buttons on the left (add new, upload, etc.).
MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. buttons on the right (help, settings).
Rather that opening Help and Screen Options (now “Settings”) in tabs, we can use the modal component:
This is a more portable approach than the existing pull-down tabs, and also makes the longform help content much easier to read, since the modal constrains it to a much better line-length for readability.
Note: the modal header and panels don’t line up in the mockups due to some conflicts in the Figma files, but should in real life.
List Tables
Y’all, List Tables are as old as dirt. They’ve done a good job for the past decade and whatever, but they could use some modernization. Lists Tables would be a way to bring all of the list actions together into one single container, rather than floating above and below, disconnected from the table. I’ve kept the table items themselves the same, but made adjustments to the header, footer, and external table elements.
List Tables are composed of the following elements:
A table heading with optional bulk select checkboxes.
Rows, same as the existing list table pattern.
A table footer that instead of repeating the header, has meta information (# of pages, previous/next navigation). When items are selected, bulk actions take the place of the navigation:
This is similar to how we handle bulk deletion in the Media admin screen.
Empty States
There isn’t currently a consistent “Empty” State for admin pages (like when you don’t have any posts, pages, comments, etc.). This new component take a stab at one we can reuse for all pages in the future.
Empty States are composed of three elements:
A “not found” graphic.
Text stating there are no items.
An action, like a button, to help resolve that there are no items.
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 headerHeaderThe 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. 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 pluginPluginA 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party cards, and the WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://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:
WordPress.org
wp-admin
Inside the modal, you’d also be able to demo a blockBlockBlock 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. 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?
I’ve put together a hand-off document on Github so the development team (@tellyworth and @ck3lee) can start building it out. You can follow along and get involved with the development process there.
Call for Testing
We’re going to need some folks to get involved in testing the feature, once the initial version is built out. I’d like to start thinking about that now, so we can prepare a script and start figuring out where we should be testing sooner rather than later. If you’re interested in getting involved in testing this feature, please let me know in the comments.
This is an update to the Block Library project that’s in-progress. Feedback has been taking place on GitHub and in Figma. My thanks to all the folks who have chimed in to help improve these mockups!
Installing a blockBlockBlock 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.
Installing a third-party block from the block directory, via the block inserter
Search Results
If you search for a block, but nothing installed in your block library shows up, you’re presented with third-party blocks that show the block icon, title, author, and rating. Pressing on a block brings up more details.
Details
The Details screen is similar to the pluginPluginA 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party cards we see in the Plugin Directory. It’s an abridged version of the block information, showing icon, title, author, star rating, and description. (This would ideally use the short description that plugins provide for cards.)
“More Details” would bring you to the full details screen in the Block Directory, and “Add” inserts the block into your content.
Installation
Once the block is inserted into your content, WordPress would ideally start silently installing it in the background while you fill in placeholders and change settings. If you change your mind and decide this block doesn’t work for you, WordPress would deactivate and delete the block when you remove it from your content so you don’t end up with a junk drawer of discarded blocks in your library.
What happens if your installation fails
In some cases, the installation won’t work — for example, if your internet cuts out while trying to install the block. In these cases, WordPress needs a way to recover from that error. This flow explores when a block isn’t able to be silently installed.
Pre-Publish
If you have the pre-publish panel enabled, you’ll see another reminder that you’ve added new blocks to your site, and another Details link that’ll take you into the Block Directory, in case you want to review it again.
Next Steps
The design team will look at creating tests for this (or testing it out themselves) during the WCEU Contributor Day; look for a recap on this p2 afterwards.
Between now and then, the prototype will continue to be open for feedback and iteration. I’d like to have all feedback for round one of testing in by Wednesday, June 19th, so I have time to iterate before WCEU.
You can comment with feedback here, or directly in Figma, if you’re a part of our team account (You can ask for access in #design).
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 GutenbergGutenbergThe 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. https://wordpress.org/gutenberg/ Blocks Template pluginPluginA 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
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
Headspace
Calm
Path
Having some sort of details screen can provide opportunities to persuade people to install your blockBlockBlock 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.. 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
Jetpack
Jetpack
Jetpack
Jetpack
Khan Academy
Pacemaker
The Jetpack examples are obviously a bit more of a direct comparison. The last two mockups, especially, are a good example of using existing coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. 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?
With the introduction of GutenbergGutenbergThe 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. https://wordpress.org/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.
Scope
The WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 blockBlockBlock 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. plugins that are available to install, with a button and process for seamless installation.
@tellyworth
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 WordPress.org, will take place in a future project.
Create issues in GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ for design
There will be weekly or biweekly updates here on make/design.
There will be time during each weekly Design meeting on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. for updates.
Design tasks will exist as issues on GitHub; you can follow along on on our project board.
GutenbergGutenbergThe 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. https://wordpress.org/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.
Background
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 blockBlockBlock 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.-based pluginPluginA 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that is intended to be seamlessly installed from within Gutenberg itself. This is one of the 9 priorities in the 2019 roadmap.
The WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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.
You must be logged in to post a comment.