Update design for Unsupported blocks

[iamthomasbishop]

The current iteration of the Unsupported block isn't very helpful.

Current design:

Proposed design:

• Show the block type name, rather than simply "Unsupported". This will tell the user quickly which blocks are on the canvas and they can move or delete them accordingly
• Add the block type icon as an additional visual cue
• Change styling of text to be system sans-serif and the darker shade ( #2e4453 aka $gray-dark )

(Below: an example of a focused Unsupported block)

Note: If need be, we can tackle the question mark icon separately, but here's how I would expect it to work:

• User taps the (?) icon
• Dialog or sheet opens
• Short message explains that some blocks aren't yet supported, links to more information on a webpage

[hypest]

Thanks for the iteration @iamthomasbishop!

Currently, we're using the "Unsupported" placeholder in the cases where the post has content not wrapped in Gutenberg block delimiters too. Think, text that is "orphan", not inside any block. In such cases, there is no block type/name, nor any icons to use. Do you have a proposal how to represent such cases?

On a different note, it seems that the new styling doesn't quickly convey the message that this block is actually unsupported. It looks, to me at least, as something went wrong with the rendering, perhaps a bug. User will get the proper message only after they tap on the "?" Is that two-steps approach deliberate perhaps?

[etoledom]

Do you have a proposal how to represent such cases?

Maybe it would be good to show them in a "classic editor" block using Aztec? (following the web behavior)

[koke]

Show the block type name

We can't reliably do this. We could hardcode some of the common core blocks for now, but otherwise all we know is the block's registered "name" (not title), as in core/list or jetpack/contact-form

[iamthomasbishop]

Currently, we're using the "Unsupported" placeholder in the cases where the post has content not wrapped in Gutenberg block delimiters too. Think, text that is "orphan", not inside any block. In such cases, there is no block type/name, nor any icons to use. Do you have a proposal how to represent such cases?

@hypest – In that case, is that content even considered a block? If it's considered "orphan" or "stray" content, why would we show this as an Unsupported block? Wouldn't we just show the HTML content (as accurately as possible) as Aztec does? Maybe I'm missing something 🤔

User will get the proper message only after they tap on the "?" Is that two-steps approach deliberate perhaps?

@hypest – That's the idea. The barrier to that information is one tap away – via an indicator – and doesn't clutter the UI with additional text/info.

Here's how I see the mental model:

1. I have a post with a bunch of blocks – some number of them show this sort of "placeholder" style. The placeholder style to me says this content isn't rendering in my current context, but I at least know what blocks are there and can move or remove them as I see fit.

2. If I'm not really sure what this means, there's an indicator that hints at "more info" (question mark, text label, or some other indicator – open to suggestions)

3. I tap to learn more, and quickly get an explanation. From that point on, I understand what these things are and they're out of my way but manageable.

Maybe it would be good to show them in a "classic editor" block using Aztec? (following the web behavior)

@etoledom – That's certainly an option, I'm still trying to understand all of the cases where orphan/stray content exists. If I'm understanding the situation correctly, I would prefer to attempt to display the content as Aztec would, rather than wrap it in an un-editable Classic Block.

We can't reliably do this. We could hardcode some of the common core blocks for now, but otherwise all we know is the block's registered "name" (not title), as in core/list or jetpack/contact-form

@koke Is this something we can tackle sooner than later? Obviously we'd like to avoid hard-coding these things, but the alternative of showing "Unsupported" is really unhelpful to users – especially until we have all of the core block types built – but this will become less of a problem over time as more block types are introduced.

[hypest]

@hypest – In that case, is that content even considered a block? If it's considered "orphan" or "stray" content, why would we show this as an Unsupported block? Wouldn't we just show the HTML content (as accurately as possible) as Aztec does? Maybe I'm missing something 🤔

On why would we show this as an Unsupported block?, I think we're starting now to design/has-out the various cases and see what to do about those. We currently just put everything in the "unsupported" bucket and display the placeholder. Apparently we need to specialize the cases.

On Wouldn't we just show the HTML content (as accurately as possible) as Aztec does?, that does make sense, and that's quite the purpose of this ticket #367. Thing is, we've marked it as "nice to have for the Beta", meaning that we don't plan to work on it for the Beta unless time allows.

Apparently we'll continue to put everything in the "unsupported" bucket for the Beta. That's the context of my initial comment. So, we might want to either not specialize the "Unsupported block" design for the Beta or, schedule it for after it, along with the HTML per-block work.

All in all, I think that we should probably design those features in tandem to make sure we have the cases covered.

[koke]

If it's considered "orphan" or "stray" content, why would we show this as an Unsupported block? Wouldn't we just show the HTML content (as accurately as possible) as Aztec does?

I think what we're looking at here is what the classic block does on the web, but we don't have an implementation of the classic block yet, so it is unsupported for now.

I would prefer to attempt to display the content as Aztec would, rather than wrap it in an un-editable Classic Block.

I'm not sure what's the difference here between using Aztec to display content and a potential classic block, or why it would not be editable.

Is this something we can tackle sooner than later?

I'm OK with temporarily hardcoding the core blocks, although i18n might be an issue there. We might be able to actually load enough code from them to pick up the localized title, but we'll see 🤞
For third party blocks, that information lives in the block's code, which the app doesn't have. For instance, when I use Jetpack's related posts block, all the app knows about the block is this:

<!-- wp:jetpack/related-posts /-->

[iamthomasbishop]

I'm OK with temporarily hardcoding the core blocks, although i18n might be an issue there. We might be able to actually load enough code from them to pick up the localized title, but we'll see 🤞 For third party blocks, that information lives in the block's code, which the app doesn't have.

Fair enough, can we hard-code the block titles for now? At least until we have a fair number of blocks, because obviously this won't scale. At this point, if we are unable to show the name, can we at least show the icon of that block type?

[koke]

That makes sense, we can get some data from WordPress.com on the top N most used and hardcode those. For core I'm starting to feel more optimistic that we could actually load enough code from every block to get the localized name and icon, even if we can't show the UI, but we'd have to do a spike on that to make sure.

[thehenrybyrd]

This came up in a ticket, 1954338-z, so I wanted to add their voice here.

I'd just like to know what unsupported block I'm looking at. All I'm asking for is a simple description of that block in the short term, if possible. Like "Shortcode" and nothing more. Or "List".

This would make adding content to posts created on the web much simpler - users would be able to tell what content is behind those blocks, so they can add things around it with confidence.

[koke]

Good news, it's already coming up in the next release 😁

[koke]

@iamthomasbishop I didn't close this one when I merged #643 since it doesn't implement everything that was described: the help icon, and support for non-core blocks. Can you test what was merged and decide if this is good to be closed? If there are still remaining items, it might be a good idea to move them to a new issue that's more specific.

[hypest]

Here's the current status:

I think that:

1. We should update the plain "Unsupported" message to include the block name if one can be read. "Unsupported" alone is clear but, it doesn't help the user with identifying the blocks. For example, even though the up/down controls work for unsupported blocks too, it will be hard for the user to know which one exactly they want to move. Adding a name can probably go a long way towards that.
2. Notice the "Gallery" block. It has an icon and a nice name. It's not clear though what's going on there... is the block malfunctioning? Is the user doing something wrong? Is it a network problem? I think we need to add the "Unsupported" word there too to make it more clear what happens. That's additional to the "Help" icon the current ticket proposes, which will give extra information.

[koke]

We should update the plain "Unsupported" message to include the block name if one can be read

Keep in mind that we can't read the block "title" and all we now is the name, which could be things like advads/gblock or tw/bwg. It does offer a bit more information than just unsupported, but I can also imagine it being more confusing in some scenarios.

[iamthomasbishop]

Glad we're able to loop back to this – I've often thought how critical unsupported blocks are until we have scaled up to a large set of blocks. I'll give my thoughts on the most recent comments:

We should update the plain "Unsupported" message to include the block name if one can be read. "Unsupported" alone is clear but, it doesn't help the user with identifying the blocks.

@hypest Totally agree, and if we only have access to a raw title/string like tw/bwg as @koke mentioned, this might be the next best thing to display in place of an Unsupported title.

Notice the "Gallery" block. It has an icon and a nice name. It's not clear though what's going on there... is the block malfunctioning? Is the user doing something wrong?

One thing that would help here is adding the (?) button to the corner per the original proposal. This would allow us to show some UI that explains the situation ("This block type isn't yet supported on the mobile block editor, but you can still move the block up/down" or similar).

I think the original-original design of the unsupported block had both the block title and "unsupported" as a sub-title – we could definitely bring that back if that's useful in a case like the Gallery block, where we have a readable block title but it's unsupported.

Another thing that I've been thinking about is allowing folks to edit the HTML of these blocks (or any for that matter). I know that's opening a can of worms, but perhaps we could do it in a contained way (when they select this option). I think editing inline could get pretty hairy so we might want to open a new full-screen dialog, modal, or similar.

[koke]

if we only have access to a raw title/string

I'm just thinking that we could eventually have something better, I think the plan is to have a block directory where users can install blocks directly from the inserter, and we could leverage those APIs to translate those block names into something friendlier. I don't think the APIs are there yet though

Edit: the API is already there but only works for the plugins that follow the registration API https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request%5Bwp_version%5D=5.3&request%5Bper_page%5D=3&request%5Bblock%5D=boxer%2Fboxer

WordPress/gutenberg#16524

[hypest]

One thing that would help here is adding the (?) button to the corner per the original proposal

As mentioned in point No2 in the comment, the "?" Help button can help indeed by adding additional context and explanation, but the block status should be more clearly conveyed without the need to tap a button first.

we could definitely bring that back if that's useful in a case like the Gallery block, where we have a readable block title but it's unsupported.

Cool, let's add whatever is locally available and we can iterate.

we could leverage those APIs to translate those block names into something friendlier

Good call, I consider that an additional opportunity to get a better/friendlier name, but it doesn't have to be the only means we use, especially since it won't work while offline. Let's tackle the API based in a separate ticket. Ticket opened: #1232

[hypest]

This ticket is on the Open Beta target since it is useful for the writing UX when there are more than a few unsupported blocks on the post.

Specifically, let's only implement getting the locally available block name and display it. If we can also get the icon, that'd be even better.

I'd love to have the "?" implemented as well, as it can give better context on what's going on with the block.