Show save button in the Reusable Block toolbar if there are changes

[critterverse]

This is part of #27890: Improvements to Reusable Blocks

Building off of an idea from @jameskoster about using dots as a way to indicate unsaved changes in the canvas (#29577, comment), this version explores using both dots and an explicit Save button in the toolbar as indicators of changes made to a Reusable block.

It would be nice to be able to save what you’ve changed within the inner blocks without having to click back over to the Reusable parent block, so I looked at including the Save button as part of the parent selector.

save-from-inner-block.mov

Saving sequence:

• A change is made to an inner child block
• Save button appears in the parent selector, green dot appears next to the Reusable blocks tab in the block inspector, white dot appears next to the Publish button in top toolbar
• When user saves changes (either directly from toolbar or from the block inspector), there would be a saving sequence in the toolbar similar to Save draft behavior in the top toolbar
• When changes are saved, the parent selector returns to its normal state and dots disappear from the top toolbar/block inspector

(Note that the Save button and “unsaved changes” notification dots are green rather than blue, building on the potential Reusable block color-coding proposed in #29337.)

You could also save changes to inner blocks while the Reusable parent block is selected, either from the toolbar or the block inspector:

save-from-rb.mov

Note that in this flow, the Save button would replace the move up/down arrows and drag handle in the Reusable block toolbar until the save action is complete.

[mtias]

Thanks for looking at this one! The main issue that comes to mind is that reusable blocks already use the space next to the icon to show the full title of the reusable block:

In that case it becomes almost indistinguishable whether "Save" represents an action or a block name. Should "Save" take more of the appearance of a regular primary button? Especially since the action is significant (it commits live changes). I could see the action showing after the "ellipsis" button in the toolbar, for example, as an appendix :)

It would be nice to be able to save what you’ve changed within the inner blocks without having to click back over to the Reusable parent block, so I looked at including the Save button as part of the parent selector.

My inclination would be that the reusable block should only be saved from the wrapper block, which is where you do the meta-operations like naming the reusable block. The parent selector having a direct action on the parent besides selecting could get a bit tricky to handle and communicate well.

[critterverse]

Thanks for these notes @mtias! I tried another version that only allows saving from the Reusable block toolbar:

save-from-rb_v2.mov

I could see the action showing after the "ellipsis" button in the toolbar

Really like this suggestion because it allows for the custom name of the Reusable block to be displayed persistently and because it results in a lot less horizontal shifting around as the Save button is shown and hidden :)

[paaljoachim]

Thank you for your explorations Channing!
I really like the save option in the toolbar, as it becomes associated directly with the Reusable block.
User makes a change they like and can save it right away.
I believe the same technique should also be used in Full Site Editing with saving template parts.

[mtias]

Nice, I think this helps a bit with the clarity. Is there other possible placement that occurs to you that might be better? Also not sure what should happen when the block is actually saved. In the above prototype you have a checkmark, but I'd imagine the checkmark would disappear if you deselect the block and select it again, so should it disappear from the start? The "is saving" state should also coincide with the one at the top from the "is busy" component state.

[jameskoster]

For the saving, I was curious how it might work if we applied a busy state to the button on click, then displayed a snackbar on success/error. That could allow us to contextualise any errors, and potentially provide an option for users to perform subsequent actions (e.g. undo/revert), if we feel that is worthwhile.

Since the save button in the toolbar can be easily missed when editing innerblocks, is it worth displaying the dot in any location where the reusable block name appears for maximum exposure? I see you have it in the Inspector which I like, should it also appear in block list view(s)?

[mtias]

A snackbar seems important to have, for sure. It's worth noting this doesn't change anything about the main saving flow in the top level "update" or "publish" button, which still would include the reusable block if it has pending changes.

[critterverse]

Thanks for the feedback, all!

Is there other possible placement that occurs to you that might be better?

@mtias I like the Save button grouped with the Options ellipses as a sort of “appendix” area but maybe they are swapped so that Save comes first? (this change is reflected below)

In the above prototype you have a checkmark, but I'd imagine the checkmark would disappear if you deselect the block and select it again, so should it disappear from the start?

I didn't communicate this very well, sorry 😂 The sequence I proposed before was:

• Save button appears when a change is made (toolbar expands)
• Save button disappears on click
• Display cloud icon (busy state)
• Display check mark (confirms save is complete)
• Toolbar returns to default state (collapses)

To your point @mtias and @jameskoster, maybe a better approach is to use the button busy state. In this scenario, I wonder if it would make sense to leave the Save button persistently visible in the RB toolbar rather than hiding and showing it:

Resting (top): Unsaved changes
Busy (middle): Saving in progress
Disabled (bottom): Up-to-date

I was curious how it might work if we ... displayed a snackbar on success/error
should it also appear in block list view(s)?

Really like both of these ideas, I’ve included here:

rb-save.mov

Here's a Figma prototype in case anyone wants to click around.

Note that the Save action in this video/prototype goes straight from the active → disabled state but imagine there's an animated busy state in between :)

[Tropicalista]

Another problem is when he reusable block contains innerblocks. There's no way at the moment to let user know is editing a reusable block. A lock state should be added before any edit/delete action is performed.

[jameskoster]

@Tropicalista we're exploring an interaction similar to what you describe over in #29337 :)

@critterverse I like the harmony of having the save button here behave the same as the one in the top bar. It helps me understand that the RB is a global element before I even edit it.

On that last point, do you think it would be overkill to have a one-time guide pop up the first time a user saves an RB in this context, to highlight the global nature of the action? Perhaps something simple like "You just saved a reusable block, any other documents that include this block have been updated to reflect this change."

[critterverse]

do you think it would be overkill to have a one-time guide pop up the first time a user saves an RB in this context, to highlight the global nature of the action?

Interesting! This is just a quick sketch but I can imagine a nice bubbly animation here in the style of the Gutenberg onboarding guides :)

I like that this could help with user understanding as well as potentially help reinforce any color coding decisions.

Perhaps the snackbar wouldn't show up on first save when you see the guide, but then always appear after that.

[pablohoneyhoney]

It'd be cool to see that flow more integrally, but contextual education can help. Perhaps even more in detail about where things are.

The material UI of the Save button could also be wider to gain more specific weight within the toolbar. It seems squeezed for the main action at that moment, no?

There's something uncanny about how the ungroup/revert/convert to regular blocks icon lives with Save. They can be understood as opposites but are treated as distant UIs.

[jameskoster]

It'd be cool to see that flow more integrally

An option with a lighter a footprint could be an action to "Learn more about Reusable blocks" on the Snackbar that appears on save.

[critterverse]

These are helpful notes, thanks @pablohoneyhoney!

The material UI of the Save button could also be wider to gain more specific weight within the toolbar. It seems squeezed for the main action at that moment, no?

I originally matched the padding for a text-based toolbar item but I've updated it to match the primary button style which feels a lot better 👍

There's something uncanny about how the ungroup/revert/convert to regular blocks icon lives with Save. They can be understood as opposites but are treated as distant UIs.

I hear what you're saying here. One revision that could help is to move the "convert to regular block" action into the ellipses menu (I realize this would be undoing a change made last summer 😅).

FWIW that's where I was expecting to find this item initially because of the flow for converting a regular block into a Reusable block — the "convert to regular block" action is sort of the reverse of that (albeit at a local, not global, level).

This would also bring the Reusable block more in line with the "detach" behavior of Template Part blocks. Curious whether it seems likely that this action will remain in the ellipses menu for Template Parts (cc @jameskoster who might have more context on this).

[jameskoster]

I realize this would be undoing a change made last summer

I think this is fair. Using a reusable block as a starting point/template (the original issue that lead to the ungroup action being added to the toolbar) is now better served by block patterns in general.

"Ungrouping" the blocks – whether that is from a template part or a reusable block – does not feel like a primary action to me. Therefore the Toolbar placement seems inappropriate.