Improve experience of using social icons in the navigation block

[annezazu]

What problem does this address?

While @helen was streaming recently, she found that when adding social icons to the navigation block that the + button was quite confusing. If you clicked the + button right next to the social icons, you could only add other social icon blocks. If you clicked just outside of the social icons section though, you were then popped back into the usual experience of adding blocks to the navigation menu with more options:

Screen.Recording.2021-09-30.at.9.55.08.AM.mov

What is your proposed solution?

Not quite sure beyond clarifying what can be added and why perhaps similar to the overall work being done around explaining limitations: #30159

cc @jasmussen for thoughts :)

[jasmussen]

Yep, this is kind of a microcosm of a lot of things going on:

• The in-canvas inserter lacking context, taking up space, and shifting layout around
• The variety of containers, especially containers within containers (in this case a social icons container inside the navigation container)
• The sheer number of blocks available, and how to insert/arrange them
• Parent/child borders/indicators of hierarchy

Key, it seems, is that we look as those issues as general issues with the block UI itself, and not necessarily issues specific to either navigation or social icons. These same issues will pop up for similar blocks, so it's important to look for general solutions.

Borders: Template parts already have additional highlighting of the parent container when a child inside is selected:

That could be carefully expanded beyond template parts.

In-canvas appender: The black plus to insert, and how that shifts the layout when it appears is important to solve. This proof of concept doesn't fix it, but shows how much more convenient it is when the layout doesn't shift due to the in-canvas appender. I haven't found a great solution for it yet, but an exploration pins the plus to the block border, like so:

Containers in containers: The list view is already very helpful to show both the contents of your document as a mini-map, but also the containers present and how they nest. Still: the fewer containers are necessary, the easier. In this case, one might intuit to be able to insert social icons directly inside the navigation block, without having to insert a social icons container first.

That's a possibility, but it would need greater curation of the quick inserter, so the blocks you'd need to insert most of the time are immediately surfaced. There's a ticket somewhere for this, but here's a mockup of what that curation could be for the Navigation Block:

I wouldn't mind just letting you search for "Instagram" in that dialog, or let you page to find it. We already have precedence for ensuring the right published markup for such links, so it seems we could spare the container here.

Somewhat adjacent to that, there are some conversations about converging on a "Row" block for horizontal items like Social Links, rather than having a slew of bespoke container blocks that are similar but not the same. That would help here as well.

All of these ideas are actionable, and spread across a few tickets already. But they are not trivial. The upside is that solving them benefits all blocks, not just social icons and navigation.

[annezazu]

Thanks so much as always for the lovely context and connecting so many dots <3