Design Explorations: Installed results that are disabled

[melchoyce]

What if you search for something a plugin you've downloaded includes, but you've disabled it?

[melchoyce]

One idea (that would need copy help):

Or, we could reduce the opacity on the disabled result:

(The colors exported weird, but that "enable" link is regular link blue)

[kjellr]

Would it make sense to have the "Enable" link be a button here?

[melchoyce]

I was worried it'd get noisy if you have a bunch of disabled results, but I'll try mocking it up 👍

[melchoyce]

[melchoyce]

Other idea — don't show an enable button at all, and instead turn the block back on if they select one.

[kjellr]

This is reminding me a little bit of the problem we ran into over in WordPress/gutenberg#14224.

In the end, we just went with a checkbox, but here are definitely some relevant explorations in the following comments:

• Edit Post: Add block management modal gutenberg#14224 (comment)
• Edit Post: Add block management modal gutenberg#14224 (comment)
• Edit Post: Add block management modal gutenberg#14224 (comment)
• Edit Post: Add block management modal gutenberg#14224 (comment)

[melchoyce]

Related (h/t @karmatosed): WordPress/gutenberg#15121

[mapk]

@melchoyce I really like the last idea of just showing the blocks without additional links or buttons. The text at the top explains what's going on; "We did find these other disabled blocks." Of course, that might need a copy review.

Once the user selects a block, it's automatically enabled again. 👍

This keeps the Block Inserter (Library) from getting too complicated. Especially in light of the upcoming Block Directory changes, it might begin to get overwhelmed with varrying design patterns.

[melchoyce]

Alright, then we can go straight-forward:

[ck-lee]

Hi @melchoyce, I've started to implement this but I hit a road bump.
The issue is, with the way the inserter works, these disabled blocks are actually closer related to "blocks that are not installed" than "blocks that are installed".

For example:

• If listicle block is installed, but disabled.
• Typing "list", it is difficult to show listicle as a result among the enabled blocks.
• If is only when user types "listicle", and no installed (or enabled) blocks found, the block search is then triggered.
• Then it is easier for us to display the listicles as part of the block search results.

So, can we do something like this for V1?

• Display "disabled" blocks as part of block search results. (Note: the results may have a mix of disabled and enabled blocks.)
• For example:

Or I can hide disabled blocks from the results.

[melchoyce]

Let's hide disabled blocks from results for the v1.

[karmatosed]

Just checking in on the status of this so we can keep this repo synced and updated with issues. @ck-lee is this now implemented?

[StevenDufresne]

@karmatosed This doesn't appear to be implemented yet.

[StevenDufresne]

@melchoyce @karmatosed @ck-lee

Is this a problem with the block directory or custom blocks in general? If I manually install a block, then disable it, do I not follow the same path?

The reason why this distinction matters is that the problem that @ck-lee ran into is a problem with the logic in Gutenberg's 'core' library, more specific: the inserter. If that is the case, I think we should consider moving this issue over to the Gutenberg repo.

The Issue that @mapk linked above is related.

[StevenDufresne]

Disregard my previous comment 😳🙂.

I've had a few chats and I think the block directory is the better place to address this :)