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.

https://user-images.githubusercontent.com/77359364/111156161-cbac6580-856b-11eb-89ac-6a55f88eba93.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:

https://user-images.githubusercontent.com/77359364/111156402-14fcb500-856c-11eb-87d7-8a3616be3511.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:

https://user-images.githubusercontent.com/77359364/111211977-6f663780-85a5-11eb-8b4a-39ae017bd3bf.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:

https://user-images.githubusercontent.com/77359364/111549834-4388b480-8753-11eb-8334-395305151622.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 https://github.com/WordPress/gutenberg/issues/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.

[mtias]

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.

This is not user-serviceable, though. Until you can easily create your own patterns, the flow of detaching the blocks to get a quick start is going to remain important to consider.

[paaljoachim]

Brainstorming...

What are the primary actions of an instance of a Reusable block? To me that would be to align (left, center, right, wide or full width) and perhaps other controls that affect only the instance of the Reusable block as seen on any Gutenberg page/post.

What are the secondary actions of an instance of a Reusable block? These might be actions that affect the Reusable block in itself. Such as renaming, saving, revert changes (it is not easy to do multiple undoes and get back to the original reusable block state), covert to block etc. Some of these options might be buried inside the 3 dot drop down menu and other options might be placed into the sidebar settings.

So before the discussion continues it would be helpful to create an overview. A perspective in relation to an instance of a Reusable block and the Reusable block in itself.

[TheSimArchitect]

I also find it difficult to select the entire reusable block (which may contain multiple blocks inside) and I have to keep hovering and clicking until I click the exact "pixel" I am supposed to. Can't navigate using the keyboard either, that just takes the cursor to the block above but the reusable is never entirely selected like before.

[jameskoster]

@TheSimArchitect we're exploring a solution to that in https://github.com/WordPress/gutenberg/issues/29337 :)

[TheSimArchitect]

@TheSimArchitect we're exploring a solution to that in #29337 :)

Nice!!!

[critterverse]

What are the primary/secondary actions of an instance of a Reusable block? So before the discussion continues it would be helpful to create an overview.

These are great questions @paaljoachim — I'm also looking at the division between primary/secondary controls for the Reusable block in #30357. Attempted a breakdown/overview there!

[paaljoachim]

One thing in relation to needing to click a dot to do something. Having actions in a dot is a hidden UX. The options are not clearly seen. One has to know that to example discard an accidental adjustment to a Reusable block one needs to click the small green dot to be able to discard the adjustment. Discarding a save should be easier to openly/clearly seen. (Also what happens if there are green dots multiple places. Can all of these be clicked or can just some or one of these be clicked? That would create a lack of consistency when seeing a green dot and what kind of action a green dot holds or does not hold.)

An example. The visual seen here: https://github.com/WordPress/gutenberg/issues/29577#issuecomment-802732673 one just unchecks what one does not want to save and then should be able to move on in the Save/Publish flow. As it is pretty simple. User clicks the checkbox for what to save and unchecks for what not to save. It is easy to see and understand. As it is a familiar process we are used to from using online forms.

[paaljoachim]

EDIT Call the two versions as inspiration on alternative methods for saving, undoing and discarding changes.

Here is a suggestion for a Save procedure. Where I also incorporate an undo button. (Actually the revisions icon. The proper icon to use would be the back undo arrow icon. Which I thought about when I posted this comment.)

It starts out with just having saved.

Publish panel: One can discard a save. It then goes back to the last time it was saved.

Clicking the Save button (blue color same as the Publish button) in the Reusable block removes the dot in the toolbar and in the Publish buttons, and saves the change.

This is a recording of the prototype.

https://user-images.githubusercontent.com/5323259/114271493-ead6cf80-9a11-11eb-8130-be888d0ca73d.mp4

Test the Figma Prototype: https://www.figma.com/proto/4jP1BWklMIIS50nvo7NJa5/Reusable-blocks-Save-procedure?node-id=2%3A32&scaling=min-zoom&page-id=2%3A5

Figma file located here: https://www.figma.com/file/4jP1BWklMIIS50nvo7NJa5/Reusable-blocks-Save-procedure?node-id=2%3A5

---

Version 2. The dots create a visual noise. They capture/distract the attention in a way they should not. We really do not need the dots in the Post Editor screen to remind us of needing to save. There is a save button in the Reusable block toolbar that becomes active after having done an adjustment. Greyed out when there is nothing to save. It is just a little more subtile than using dots.

For this prototype I removed the dots and changed the revision icon for the undo icon. (The Save button also has the correct size.) I have added in the "Change alignment" toolbar icon.

Here is a screenshot: Showing these new features in the toolbar: Change Alignment, Undo and Save button. Publish panel: As the user unchecks the checkbox a discard button is seen.

Version 2 prototype here: https://www.figma.com/proto/4jP1BWklMIIS50nvo7NJa5/Reusable-blocks-Save-procedure?node-id=17%3A53&scaling=min-zoom&page-id=17%3A2

[critterverse]

Thanks so much for continuing to explore this, @paaljoachim! One thing I really like about your design (and something you touched on in your earlier comments) is the POV that there should be an easy way to Discard changes that's not hidden beneath a layer of UI.

I wonder if it would make sense to incorporate Save/Discard functionality in the inspector underneath the “Revisions” panel (which is currently being explored in issue #30357).

https://user-images.githubusercontent.com/77359364/114796945-17675000-9d60-11eb-8664-6332f2f3afe1.mov

So starting with an up-to-date Reusable block, the Save flow could be...

A change is made to the RB: • Save button in toolbar becomes active • Dot appears in Publish button in top toolbar • Notice appears underneath Revisions panel with option to Save or Discard changes

↓

Up-to-date RB: (If changes are saved from any location) • The notice disappears • The number of Revisions increases • Snackbar appears in lower left to confirm save

[critterverse]

This issue was discussed in the Making WordPress Design channel yesterday: https://wordpress.slack.com/archives/C02S78ZAL/p1618936992186300

Just wanted to note that several contributors suggested that the first version/implementation of the design might work better without the green color (which is still being explored more holistically):

^ Removing the "click-through" overlay (that's currently being explored in https://github.com/WordPress/gutenberg/pull/30156), Revisions, and Save/Discard actions from the inspector so this issue can focus on the Save button in the toolbar :)

[paaljoachim]

Thanks Channing! The main feature we have here is the Save button in the toolbar and the Save/Discard in the sidebar. I believe we can go ahead and get a developer to create a PR for this, so we can try it out. If that sounds alright. I will remove the "Need Design" and add the "Needs Dev" label. @shaunandrews and @kellychoffman any thoughts on the direction before I go ahead and change the labels?

Here is another method being explored by @jameskoster https://github.com/WordPress/gutenberg/issues/31043#issuecomment-825009466

[paaljoachim]

We do have a general improvement of the multi-entity saving method added to a new issue: https://github.com/WordPress/gutenberg/issues/31456 I have added various mockups to it. It could use additional feedback.