Improve and align application of lock icon in list view

[jameskoster]

Current state of affairs

When you edit a page with template preview on, list view shows the following:

---

When you edit a partially synced pattern instance, list view shows:

---

The problem

The lock icon is not entirely helpful for a couple of reasons:

1. Visual overlap with the user-controlled locking mechanism despite subtly different behavior.
2. Suggests the block is not editable at all which isn't the case.
3. Suggests the block can be unlocked in context which isn't the case.

Is there an alternative to the lock icon?

cc @WordPress/gutenberg-design

[talldan]

I personally think the two things are completely aligned here, though I agree the lock icons are confusing.

The header, footer, site title, featured image are editable. They can be selected and interacted with in a limited sense, but they can't be moved because the layout/design is provided by the template entity.

It's the same in a pattern with overrides, the blocks that have overrides can also be interacted with in a limited sense, but the layout/design is provided by the pattern entity.

In both cases these blocks are shown in list view with a lock icon. In both cases there might also be a lot of other blocks that are completely hidden from view (e.g. groups that provide a layout, or other design elements). The only additional part in a page is that it has a completely freeform area—post content—which patterns don't have (but it could be a cool feature).

The confusing thing for me is the way the locks in list view are shown, In both cases these blocks are only partially locked.

[jasmussen]

In adjacent apps traditionally the lock has denoted completely locked: entirely unselectable. Vs. here that's not necessarily the case. An extreme example is Photoshop, which allows locking multiple different properties individually:

We should definitely avoid that. It's also indeed behaving as built — the lock icon is shown in all of the following manual locking cases:

• Disable movement
• Prevent removal
• Both

It seems valid enough, especially for manual locking, to show the lock icon when one of those properties is chosen, otherwise it might be hard to denote the difference between blocks in the list.

For me the primary headache is that traditionally, the lock icon means nested items are also locked. I.e. if a group is locked, so is everything inside. So I wonder if there's a way we can add nuance:

• Show the lock only for anything that's manually locked.
• Gray out / reduce opacity for blocks that are template locked (I.e. header/footer, TPs)
• Don't show the lock at all on blocks nested in partially synced patterns. The purple color and the sync icon on the parent should be enough to denote that these behave differently.

What do you think?

[jameskoster]

I personally think the two things are completely aligned here

You're right, I think I was testing with a simple template here, and all blocks were appearing while page editing. On further testing I see list view does strip out uneditable template blocks which is consistent with with partially synced patterns. I'll update the issue to focus on the lock icon.

[jameskoster]

For reference here are all the states list view needs to entertain:

State	Current treatment	Screenshot
Fully locked "lock":{"move":true,"remove":false}	Lock icon, ellipsis accessible
Fully locked due to context (e.g. general template blocks in page editing)	Stripped from list view	n/a
Move locked	Lock icon, ellipsis accessible
Remove locked	Lock icon, ellipsis accessible
Content only editing	Lock icon, ellipsis hidden
Selectable but only editable after action (e.g. Template parts in page editing)	Lock icon, ellipsis hidden
Fully editable (regular block)	n/a

Practically speaking content only editing is essentially the same as fully locked, so it's easy to see how we ended up with this treatment. But in the context of page editing, the lock icon appearing alongside blocks like title and featured image is a bit confusing – it suggests they aren't editable at all.

Some provocations:

• Given the wide variety of locking options, should the lock icon be more contextually placed? IE if a block is remove locked then show the lock icon next to the "Delete" action. If it's move locked do not show the grab cursor.
• Should we remove the lock icon for content only editing (I think that's part of what you're suggesting @jasmussen), in favor of the above? In the page editing context the ellipsis could be exposed but show a message on click:

[jasmussen]

Should we remove the lock icon for content only editing (I think that's part of what you're suggesting @jasmussen), in favor of the above? In the page editing context the ellipsis could be exposed but show a message on click:

One additional argument in favor of this: we can think of contentOnly editing as "editing a custom block". It's not locked from being deleted, moved, or edited. Similar to synced patterns with overrides, this is the intended way to edit that particular block.

I've argued separately that it would be interesting to explore a "flattening" of a contentOnly pattern so that it only shows up as a single block in the list view (unless you detach) — it might even be fun to allow a pattern author to choose the block icon. But that's a separate enhancement that would further diminish the need for a lock icon.

[talldan]

I'm wondering if this is now solved with the changes in #61127 (and follow-ups)

I'll close the issue, but feel free to reopen if there's anything remaining.