Call for design: Installing blocks from within Gutenberg

The Problem

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 block-based plugin that is intended to be seamlessly installed from within Gutenberg itself. This is one of the 9 priorities in the 2019 roadmap.

The WordPress.org API 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 Meta 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.

#block-directory, #design, #plugins, #ux

Call for design: Site Health Check project

What is it?

Some of you may have heard of the Health Check plugin – It’s a very useful tool that shows people how their website is doing technically. It displays all the relevant technical information about a WordPress installation and offers tips on what to improve.

What’s the current status?

The intention is to evolve this plugin into something really awesome where (parts of) it can be merged into core. The main issue is that it needs a UX and UI overhaul. Right now the plugin mostly consists of grey pages with lots of words and numbers on them, some of which are SO long that I had to crop the screenshot by half to get it to upload:

(Click to enlarge)

What do we want to improve?

There are lots of good tools there, but we need to make sure people know how to use them, and why they should. So even before making any designs, we should think about the UX of the plugin as a whole. Questions like:

  • Does its structure make sense?
  • What should the onboarding be like?
  • How can we make it fun to interact with this thing?

What’s the plan?

The improved Site Health Check is aiming to be ready for WordPress 5.2, which is roughly estimated to come out in Q2 of 2019. That’s not loads of time, and we are a very small team at the moment (@clorith, @miss_jwo and myself), so we’re looking for any input on the above questions.

I’ve started a central issue on the plugin’s Github repo to discuss the UX, any contributions are welcome there: https://github.com/WordPress/health-check/issues/227

I’m hoping to work out new layouts and flows in the next few weeks, and then start designing the final look at the end of February at the latest. That’s around the same time 5.1 is slated to come out, and should give us enough time to implement everything.

Worth noting is that we want to try to apply the Gutenberg style to this. It would be a nice test case of what WordPress’ intended new design direction will look like outside of the editor, and it matches nicely with previous design work done around this project.

How can I help?

Like I said, feel free to drop by the Github issue to help us come up with a great user flow. We have an opportunity to reshape the UX of this thing, so I want to get as many eyes on it as are willing and able. Sketches, thoughts, reference material to look at, it’s all good. I’ll be dropping more sketches there in the coming days, any feedback is welcomed.

You can download the current stable version of the plugin to try on your own WordPress site from here: https://wordpress.org/plugins/health-check. Note that that doesn’t include the new actionable traffic-light-based site status section you can see in the screenshots above. Of course, if you know what you’re doing you can compile a build from the develop branch on the repo to see the latest progress.

There is also a section in the Handbook that describes how to use the Site Health Check Plugin: https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/

And at the link below you can find a comprehensive post about the research @miss_jwo did that led to this point, and the broader context of this plugin in the Site Health project:

I’ll try to keep you updated on our progress roughly every week here on the design blog.

#design, #plugins, #site-health-check, #ux

At the dev day in Reno Mitcho worked…

At the dev day in Reno, Mitcho worked on a patch for active/inactive states on the buttons on the WPMenus screen. Basically, it makes the button to add to menu inactive unless you’ve selected something to add. nice.

Check it out:
https://core.trac.wordpress.org/ticket/17698

#admin, #ux