Multi-entity saving with "unsaved changes" dot indicators

[critterverse]

Hi all, we’ve done a lot of exploration in #32464 around the saving flow for Reusable blocks and I'm opening this issue to discuss expanding on those ideas and potentially applying them to other blocks. This proposal is also based on the latest design for the multi-entity saving flow proposed by @javierarce in #31456, and could make a good follow up to that issue.

Here’s the save flow step-by-step as it exists in #32464:

• There’s a Save button in the Reusable block toolbar that defaults to an inactive state if all changes are saved
• If a change is made within the inner blocks, a dot indicator appears in both the Reusable block parent selector and the Update/Publish button in the top bar
• When the user clicks the parent selector to access the Reusable block toolbar, the dot indicator remains visible in that view and the Save button is now active
• If the user clicks Save from the toolbar, the button will return to an inactive state and the dot indicators will disappear from both the toolbar and (possibly) top toolbar

---

Expanding “unsaved” dot indicators beyond the toolbar

The below video shows how the unsaved dot indicators could potentially be expanded to other contexts as a way of helping explain what the dots signify. The dot could appear next to the block name in the block description, as well as within the multi-entity saving panel with a number to indicate the amount of unsaved changes:

dot-flow.mov

---

Expanding indicators to more blocks

Template parts and Reusable blocks are container blocks and post types, so it makes sense to treat these entities in a similar way. There are also Site blocks — like Site title, Site Tagline, and Site Logo — that get captured in the multi-entity saving flow.

I would propose that the container blocks get both a Save button and dot indicator in their toolbar, while the Site blocks get just the dot indicator. This should help bring visibility to the global elements within a document without adding a lot more visual clutter:

Would love to hear what others think, especially re: whether expanding the dot indicators to the sidebar and multi-entity saving panel is helping with user understanding around this fairly complex saving flow!

[jasmussen]

Some good thoughts here. I'm a fan of the dot as bringing attention to unsaved changes, the use of it feels appropriate enough.

Save buttons on reusable blocks are handy as they are so contextual. I imagine it might work for template parts as well, though that one really surfaces the toolbar-width challenge. In both of these two cases, though, the fact that the Save button goes from disabled to clear blue when you make a change inside does slightly obvioate the need for the dot. That's not to say we can't also have the dot, but just that the dot feels more important in the title/tagline/logo use cases.

I can't figure out whether the dot should expand the toolbar or sit in a place where it doesn't. If it does make it expand, we could do it with some nice animation attached, and the movement could be argued to be intentional to capture your attention. It's also likely the placement that looks the most harmonious in the block toolbar: every other overlapping design is going to be less elegant. At the same time, it might feel jarring that it resizes on typing.

Oh, and nice work!

[annezazu]

Thanks for exploring this further! I'm curious what this will look like at scale if many of these items are edited but not yet saved. Do you have an exploration of that? Because I see saving flows as being similar between template parts and reusable blocks, it's good to see the design for one applied to the other. I think that consistency will help. I do still have a lingering and light concern though that having the option to save some sections within the editor but not others might be confusing in general. Perhaps it adds good friction though and is necessary, similar to the "click to edit" overlay.

[critterverse]

Thanks for the thoughtful notes @jasmussen and @annezazu, and apologies for the slow reply! Expanding on some of these ideas based on your feedback, below.

the fact that the Save button goes from disabled to clear blue when you make a change inside does slightly obvioate the need for the dot.

Where the dot indicator really comes in handy with Reusable block and Template part toolbars is within the parent selector — this implementation brings visibility to the unsaved change as soon as you’ve edited the inner block (while the Save button within the toolbar is fully hidden at that point). We first explored a parent selector-only implementation for these blocks but it seemed to flow together better and help establish a stronger mental connection re: what the dot indicates when it remains visible after clicking over to access the toolbar. There’s a bit more context around this starting in #32464 (comment)

I can't figure out whether the dot should expand the toolbar or sit in a place where it doesn't. If it does make it expand, we could do it with some nice animation attached, and the movement could be argued to be intentional to capture your attention.

I have gone back and forth on this too, starting with originally not wanting the toolbar to expand 😅 After further exploration, I do think the expansion is a good thing because of the same considerations mentioned above — the “hanging” dot treatment seems to be the most harmonious placement, and the expansion helps catch your attention.

I love the idea of using a nice animated effect to make this motion feel more intentional — I can do some further exploration on this!

I'm curious what this will look like at scale if many of these items are edited but not yet saved

Here’s a flow to show how this might work for a Template Part block when you have another global entity as an inner block:

dot-flow.mov

• :00 Editing a Template Part block with no unsaved changes
• :06 Change is made to an inner Site Tagline block, which adds a dot indicator into the Site Tagline block toolbar and triggers the Save button in the top toolbar to become active
• :11 When checking the multi-entity Save panel, it has only captured this one change to the Site Tagline block
• :18 An inner block is selected and deleted from the Template Part
• :23 Focus is shifted to the nearest inner block and we can now see dot indicators in both the Site Tagline toolbar and the Template Part parent selector
• :28 Clicking over to the Template Part toolbar, we can see that the Save button is now active
• :34 When checking the multi-entity Save panel again, it has now captured the change to the Template Part block in addition to the previous change made to the Site Tagline
• :41 After saving, the dot indicators disappear from the Template Part toolbar and inner Site Tagline block toolbar

I do still have a lingering and light concern though that having the option to save some sections within the editor but not others might be confusing in general. Perhaps it adds good friction though and is necessary, similar to the "click to edit" overlay.

This is a helpful comparison — the “clickthrough” overlay is a really nice parallel where we treat Template Parts and Reusable blocks in a special way. As more complex container blocks that each have their own isolated editing views, it does makes sense in my mind for the saving flow to be slightly more robust than the Site element counterparts.

One more similar consideration is the question of whether to show a snack bar in the lower left corner to confirm a save for each of these entities. I think this is helpful when saving the container entities (Template Part and Reusable block) as shown in #32464. I'm less sure that you would want that confirmation to appear for every text change update to a Site Tagline for example, but there may be an opportunity to combine several "saved" messages into a single snackbar if we do want this confirmation for each type of global entity.

Note: One thing I removed in this iteration is the numbered dot in the block description area, which felt like it was introducing too much visual clutter/distraction. Maybe less is more in terms of conveying the "unsaved" message here 🤔

Thanks again for the notes! There are still some open questions, but I'm hopeful that these changes could help bring a lot more clarity to the multi-entity saving flow and help to guide users through the process better.

[critterverse]

Quick and dirty motion test!

[annezazu]

Thanks for exploring this further with such a thoughtful design and walk through. I do like the animation you made! For some reason, I am struggling still with the overall concept of having dot indicators within the block toolbar itself for unsaved changes, particularly when there are lots of changes to be had (at scale) and when dealing with things like auto-saving or scheduling changes. Further, I don't know how intuitive it'll be that some blocks will have this whereas others won't. I think that inconsistency might prove to be confusing along with the experience of clicking away from a block with a change waiting to be saved since there won't be an easy way to see at a glance within the editor what's changed (unless you open up the multi-entity saving flow or find the block itself again). Perhaps having these dots in the multi-entity flow or just the List View is a better approach rather than embedded within the block toolbar? I very well could be alone here though so take this all as my two cents :D

[mtias]

I mentioned it in the active PR, but I think we should consider not displaying the "save" button when there are no changes in the block.

[paaljoachim]

You have some awesome explorations Channing! (I browsed through quickly to get a feel for how things are going.)
I noticed the above animated image containing two dots. Two dots in the same toolbar can very quickly become confusing.

An example.
Header template has unchanged changes inside of it, and shows a dot next to the header template icon.
It happens to have a Reusable block inside of it which also has been changed. One sees a dot in the Reusable block toolbar.

Now what happens when one saves the Header template? Should everything except the Reusable block be saved?
I think so.

Clicking the Reusable block toolbar one will still see the dot as this type of block has not yet been saved.
It is an unique entity (Reusable block) inside another entity (Header template). Each should have their own unsaved changes indicator (the dot) in their own toolbar.

If one forgets to save the Reusable block then the Save button - screen should show the block that have not yet been saved changes and give the option to save or discard.

[jameskoster]

This is excellent. As an additional stress test I was curious how this pattern would work in the following scenario:

I'm editing a post, I toggle the visibility of the template (#27847), I edit the template by moving a template part.

In this case the template part remains unchanged, but the underlying template is modified. Since the template has no toolbar of its own, we'd have to rely solely on the dot on the save button alone. Is it adequate?

save.template.mp4

I think it probably is, but I'm leaving this here in case it stimulates any creative ideas.