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

[getdave]

There has been a lot of work on the Social Icons block recently where we:

• improve the initial setup/placeholder experience
• improved the focus management
• improve the UX around adding new icons

When you combine this with improvements to the Link creation experience in WP 6.5 which allows you to acess "All blocks" directly ffrom the Link UI we see this provides a much better experience.

Screen.Capture.on.2024-11-12.at.10-32-35.mp4

I'd say that perhaps in the Nav block context the + icon in the Social Block isn't super obvious and perhaps could do with some additional visual affordance (any ideas welcomed).

I'd value your feedback about whether you feel this is an improved experience.

[jasmussen]

There was an issue discussing how to potentially decoupling the social icon (singular) from the social icons (container)— if not permanently, then at least for use individually in patterns or the navigation block. Just that one less layer would improve many things.

How would you then pick which service it was, without polluting the block inserter? The idea would be that the service would be auto-complete. There was even a PR in progress that did some of this work. Paired with a "Change" dropdown to let you choose the service, inserting links would be a matter of just that, rather than inserting first the container within a container. Do you recall where that landed? CC: @richtabor @t-hamano @Mamaduka as I think you were involved.

[getdave]

@jasmussen It is this one #59303.

We didn't pursue because the general view was that it might make the standard Social Icons block harder to use. I still think that's the case.

However, if we're considering decoupling from the social icons container block then it might be worth exploring in that context.

With recent changes I feel the block is in a much better place than it was in 6.6. A few more tweaks might get us to an even smoother experience.

[jasmussen]

Thanks for finding that!

We didn't pursue because the general view was that it might make the standard Social Icons block harder to use. I still think that's the case.

Can you elaborate on why you think this'd be harder? Having to deal with selecting the right layer, for the moment, feels like a much bigger headache for me.

[getdave]

It's primarily what I suggest here:

My primary concern would be that some people don't think about URLs like we do. Instead they think "I want to add a Facebook icon". So when they are faced with an form input they will be unsure about how to get the Facebook icon.
Moreover, they won't get the Facebook icon unless they type https://facebook.com. Any typo will result in a "Link" icon.

I think users will think "I want to add a Facebook icon" rather than "I want to type in the URL for my facebook page". Therefore we should optimise for the "Add the {some service} icon" flow rather than "type to try and match the icon to the URL" flow.