It's not obvious a reusable block is a reusable block

[carlhancock]

Issue Overview

When dealing with content that has a mix of standard blocks and reusable blocks it is not immediately obvious if a block is a reusable block without editing the block and giving it focus.

The current UI requires you to select each block individually to determine if it is a reusable block or not. That will be time consuming as content will consist a myriad of blocks of varying types.

The editor UI should make it more obvious that a block is a reusable block.

Current Behavior

I've put together a simple demonstration using only 2 blocks to outline the UI/UX issue.

Above is a page that shows 2 blocks. One of them is a reusable block. One is not.

Above is what you see when you hover over each of the blocks individually. You cannot distinguish a reusable block from a non reusable block.

It is only when you select a specific block and that block has focus that you can determine it is a reusable block. In this example both block types were the same but only the 2nd block on the page was a reusable block.

This was an extremely simple example. In a real world situation the page will consist of numerous blocks of varying types. Which means distinguishing reusable blocks from non-reusable blocks will be more of a pain for the user.

Possible Solution

Incorporate a visual indicator that a block is a reusable block without requiring the user to edit the block to make that determination.

This could be something as simple as incorporating the reusable block icon in the block hover UI so that it appears in some fashion the way the up/down arrows and the overflow icon do when you hover over a block.

Clicking on the visual indicator could then not only give the block focus, but also put the reusable block in edit mode so it's ready for you to make changes.

[carlhancock]

So I threw together a very quick example. But quickly ran into a UI issue that makes it look not so good.

Here is a quick mockup of simply adding a visual indicator to the hover state of the block if the block is a reusable block:

The very first issue I see is it exposes the UI issue I mentioned above. The default hover state of a Gutenberg block only shows a partial outline around the block. It only shows vertical lines on the left and right just tall enough for the up/down arrows and the overflow icons to sit next to those vertical lines.

My personal opinion, and i'm not sure if others feel the same, is it makes it look like there is some sort of CSS issue... like the border state for the hover is supposed to be there but for some reason it is not displaying properly. But I know that is not the case and it was done intentionally.

This is the opposite of behavior elsewhere in Gutenberg in a variety of places.

Here is an example of showing the same reusable block indicator on a block but shown when the block is selected and has focus:

The selected state begins to look much better than the hover state.

The partial outline of a block on hover runs counter to other areas of Gutenberg where outlines are used. They are always complete outlines.

For example when you hover over the title:

When you hover over the empty block inserter which has already been discussed in other tickets so no need to go into detail on the problems with it, but it is displayed with a full outline:

Although coincidentally when you click on said block inserter you don't get even a partial outline like the default block hover state, you get no outline at all:

Other areas of the UI use outlines around elements as an indicator for the hover state. Here are a couple more examples:

That last one actually points out another UI issue altogether. Most UI elements in Gutenberg use a rectangular outline and feature plenty of padding/spacing so they appear more visually balanced. But the icons related to the blocks are using circular outlines and the visual padding/spacing is very cramped.

Hopefully someone can chime in on the design side. I'm curious as to what the thinking is behind the current hover state behavior of blocks only showing a partial outline and why the up/down arrows and overflow icons use a circular outline and don't make use of padding/spacing to make them appear more visually balanced.

Ultimately i'd still like to see a way to visually indicate a block is a reusable block without having to click on the block to select it. But these other UI issues have been bothering me and they begin to become related when I try to mockup suggestions for the original issue so I figured I would include them here.

[noisysocks]

Thanks for exploring this in detail, @carlhancock.

Perhaps we could show the dashed outline at all times instead of just when the reusable block is selected.

cc. @jasmussen

[jasmussen]

Solid exploration, and good suggestions. Seems like it holds ingredients for improvement here.

Tagging as in need of some design feedback — it would be nice if we could find a solution that did not involve showing more side UI as that doesn't scale well to nested blocks, but definitely something that could use love.

[karmatosed]

Thanks for the exploration @carlhancock - really interesting insights.

Perhaps we could show the dashed outline at all times instead of just when the reusable block is selected.

I like that idea over the icon. My only issue with the icon is it seems confusing 'what is it'.

What about these two options:

[noisysocks]

I like the second option, @karmatosed. It's what I was trying to describe in #5225 (comment) 🙂

[carlhancock]

@karmatosed @noisysocks How would you denote if it's a locked reusable/shared block that the user doesn't have the capabilities to edit? The first option would provide the space to do so.

You could show the Edit button if the user has the role/capability to edit the reusable/shared block and if they do not have the capabilities a lock icon with a tooltip explaining why it's locked.

It would make it obvious on hover that it is a reusable/shared (sorry I haven't followed up if it has indeed been changed to shared) block AND if it is editable or not.

One thing to note. By showing the full dashed outline around these blocks it makes the lack of a solid outlined around standard blocks even more apparent. I mention this in my 2nd comment above. The partial outline on hover looks unfinished or like there is a styling issue. When there actually isn't.

[jasmussen]

The point that the dashed line may not be enough on its own is a good point. Could we explore overlaying a "reusable block" indicator as Carl has suggested? Putting it in the side-UI should probably be avoided if at all possible, as that UI is already somewhat difficult to optimize for mobile and is about to receive further refinement as we make it work better for nested elements. But an icon overlay seems like it might work?

[noisysocks]

Maybe a badge in the corner? (excuse my terrible Sketch skills)

[jasmussen]

Right, something in that vein, perhaps.

[carlhancock]

@noisysocks Don't sweat your Sketch skills, it got the idea across just fine.

@jasmussen I like the overlay concept also and something in this vein would probably work well.

Keep in mind the updates committed in #4725 related to user permissions. It would be good for the reusable block indicator to also reflect if the block is editable or not based on their role/capabilities.

Another thing related to #4725 (which has been merged so I didn't want to comment on the pull request) what does the reusable block UI look like when a user clicks on a reusable block to try and edit it but does not have the capabilities to do so? Does it show some sort of lock icon in place of the edit button that is typically displayed?

[karmatosed]

I worked some options up, I think number 3 of these is a good balance, but putting them all up incase. I think we need to make it an obvious but not 'too obvious' mark, which is what I am balancing with.

The second one I think will confuse people thinking its an action, but we can work out maybe different styling, including for placing.

[jasmussen]

Options 1 and 3 seem like good first steps to explore

2 is difficult as the side UI probably shouldn't be taller than a single paragraph as the minimum height of a block.

[karmatosed]

Cool, lets go with option 3 then @noisysocks, if that works?

[carlhancock]

@karmatosed @noisysocks The #3 option looks good in the example with the paragraph field but be sure to see how it would be applied to other block types like images, full width images, embed, etc. With a paragraph there are no problems but #1 may work better for scalability with block types, keeping in mind it needs to work good with custom blocks added by plugins, etc