Problem

As we've been rolling out the UBE (unsupported block editing) mechanism, we have received feedback that it's not immediately obvious that you can edit any unsupported block using the UBE mechanism.

To be clear, some level of friction is intentional -- we definitely don't want to aggressively encourage users to do this unless they very much need to, because this is our first experiment at an unsupported block-editing flow, so until we are certain that this is the path worth continuing on, we have kept with a conservative approach with regards to how this feature is surfaced and promoted in the editor UI. With that said, I think there is some room to make the entry point a bit more clear without drawing too much attention.

Current

Currently, an unsupported block is displayed as a placeholder on the canvas. It contains a text label of "Unsupported" and a (?) icon-button (44px tap-target) intended to direct people to more information. When they tap this (?) icon, we display a bottom sheet with informational text and a button to edit the block in the in-app web browser. When they tap to edit, we launch the in-app browser with that specific block loaded in the web editor. Here are some screenshots of the current flow:

Selected	Informational Sheet	In-app editor

Proposal

Rather than add any new UI like a button or strong text label, let's first try increasing the tap target that launches the informational bottom sheet to cover the entire block.

With this change, I think we will want to change the logic so that you first have to select the block before the tap target becomes "active", which follows some other similar blocks like the Latest Posts block, and most importantly, the select-first interaction gives the user the other block controls such as movers and the overflow (•••) menu.

cc @maxme @hypest @etoledom @marecar3 -- if possible, can we get this one slotted into the next couple of sprints? Happy to answer questions and/or discuss other options as well!