UX improvement on Legacy Blocks deletion

[sunyatasattva]

For full context and history, cfr: #5166, #5176

While we are in the process of phasing out the legacy PHP blocks, an interesting UX question arises in the transition period. With the issues linked above, we have decided to revert our previous judgement to make those blocks locked and un-erasable for the user.

The reasoning was that erasing those blocks was probably not something the users wanted to do, and possibly accidental (or they didn't know the consequences thereof). The side-effect was that these blocks could not be moved either.

With #5176 we decided that disempowering the user to move the blocks just to protect them from themselves was defeating the purpose of FSE. However, legacy blocks do not appear normally on our Block Inserter (because they might not be compatible with the page the user is trying to add them to).

This means that, after an accidental deletion, the user cannot intuitively add the block back.

A workaround currently is to delete the template the user has been working on, and thus reverting to the default override. This workaround has two drawbacks:

1. It's hard to discover for the user.
2. The user will lose any other change they have done to the template prior to the accidental deletion of the legacy block.

This ticket is meant to spark a discussion on what the solutions to this problem might be.

Proposed solutions

1. Ignore the issue as it's going to go away when blocks get phased out. This is not what I would recommend, but indeed a possibility worth discussing. It is currently unclear to me what the timing of this phasing out can be, and this issue potentially can bring many headaches to users and HEs alike.
2. Check if we can feasibly identify which pages are compatible with which blocks and restrict block insertion to those pages. This is probably a longer-term/higher-effort solution.
3. Figure out if there is any way we can lock deletion but not moving.
4. Add some copy to the block preview that warns the user about the situation, and the effects of deleting the block. This is a UX pattern I see relatively often when, e.g., certain more side-effects heavy settings are hidden or grouped below a “HERE BE DRAGONS”-kind of section (GitHub, for example, does this for certain irreversible actions).

• I believe this to be the lowest hanging fruit. It's a short-term solution, and the drawback is that, if the notice is in the copy, once you delete the block you don't have access to the notice anymore (which was perhaps the place where instructions to reverse would be). But, nonetheless, I think it's something quick that would add value.

5. Add some sort of modal on deletion of the block which contains a “Are you sure?”-kind of interaction. Of course another extremely common UX pattern. Some applications even try to make sure you checked the copy by having you type something like DELETE to confirm your action (Firebase does this). This might be overkill, since in our case it is a reversible action, but it was worth mentioning. The drawbacks of this solution are:

• It's a tinsy-bit harder to implement than the notice above, without adding too much more value;
• While it's relatively easy to implement this notice when deleting the block directly, a challenge I anticipate would be to show the notice when the block is erased as a child of a target block and not directly.

All in all, the ideal solution is probably either (2.) or understanding how quickly we can phase those blocks out (so, sort of 1.), but it doesn't seem any timeline would be quick enough, IMHO.

Mockup

I took the liberty of doing a small mockup of my proposed, short-term solution (4.). We discussed a few things with @frontdevde:

1. Whether to put the notice somewhere clearly visible and marked as a warning, or whether to add it within the copy.

• @frontdevde thinks it could be a good idea to add it within the copy, as it fits the current notes (right after the part about moving it). And thinks that adding it as a warning could kind of put too much attention from the user to the fact that the product is in a sort of flux/unready state. Please @frontdevde correct me if I'm wrong or have misrepresented your view.
• I personally think that, as a user, that copy within the placeholder is almost invisible to me. I probably wouldn't read it, but I would probably take notice of something like a warning message (though nothing is full-proof). I acknowledge @frontdevde 's point about not sending the nicest of messages to the user regarding the state of our product, however, I believe that this hit is more or less balanced by averting some of the risk of a potentially very bad action from the user, who could mess up their entire shop and wouldn't have an immediately clear solution at hand.

2. How to word the notice. I included some words in the mockup, but I'm definitely not good at that.
3. Whether to provide a direct link to the Templates page where the action can be reversed, or perhaps a link to some kind of Troubleshooting FAQ page.

Conclusion

I'd appreciate any input on this conversation, even if it is that I'm overstating the danger of such interaction. Also feel free to propose different solutions, and I would probably call in @vivialice to take a look at this and chip in with her opinion.

[frontdevde]

Thank you for writing this up in such a precise and easy-to-follow way, @sunyatasattva!

With #5176 we decided that disempowering the user to move the blocks just to protect them from themselves was defeating the purpose of FSE.

Just providing the additional context that while locking the block from being removed (remove:true) did still allow the user to move the block on the top level, it prevented the user to move it into other blocks. This limitation is introduced by the block editor as otherwise the block could be removed by simply removing the new parent block (as we discovered in #5163 for example). The limitation meant that the user couldn't use creative tools such as the Columns block to structure their page to their heart's content.

Proposed solutions

1. Ignore the issue as it's going to go away when blocks get phased out.

I'd agree with your assessment that this is not preferred and that we should look into addressing the problem in some form.

2. Check if we can feasibly identify which pages are compatible with which blocks and restrict block insertion to those pages.

This would be my preferred solution. That said, I'm not certain it is possible to limit a block to only appearing in the block inserter on specific block templates. We can open another ticket for a research spike to look into this.

3. Figure out if there is any way we can lock deletion but not moving.

See my clarifying comment above. While it is possible to affect the two functions of removing and moving independently of each other, locking the deletion automatically leads to the block not being allowed to be moved inside other blocks. This is something that would need to be solved at the block editor level i.e. in Gutenberg. It's a multi-faceted problem though, as there are good reasons for the current behavior of the block locking feature.

4. Add some copy to the block preview that warns the user about the situation, and the effects of deleting the block.

👉 This is probably the most straightforward solution to the issue.

5. Add some sort of modal on deletion of the block which contains a “Are you sure?”-kind of interaction.

I agree with your assessment that this solution comes with its own set of issues.

[frontdevde]

Mockup
I took the liberty of doing a small mockup of my proposed, short-term solution (4.)

Thanks for summarising our conversation and taking a stab at visualizing a potential solution.

While I'd agree that this note is important, I still think that adding a colored background adds too much attention to a shortcoming of what in itself is the first iteration of a new feature that provides merchants with new opportunities.

We could explore removing the background and adding the note below the other copy with an empty line between the two.

This is an editor placeholder...

Please note: ...

[alexflorisca]

Great write up @sunyatasattva. I don't know much about FSE yet, but I do have some experience with UX, and putting my user hat on, I would agree with you both that there are some issues with displaying a message to a user indicating that the only way to solve their problem is to "delete this template and edit it again". As a user that would make me panic.

I would also suggest either discouraging the user from deleting their template as I don't believe it's something they would want to do. We could use words such as "This is a legacy block that is no longer supported. You can remove this block, but you will not be able to add it back". We could also say something like "As an alternative consider X block" if there is an alternative Gutenberg block.

Alternatively, if we feel like we want to tell the user to delete the template and edit again, it would be good to be more explicit about the steps and consequences of that action. To me it seems like I'm going to loose a lot of my work on the store.

Also like @frontdevde said, this is a temporary situation until the PHP blocks get phased out. It might be re-assuring to the user to know this is temporary, and that it won't be a problem in the future. I would suggest adding to the warning message words to that effect to comfort the user.

[vivialice]

Hey @sunyatasattva! I agree with you and others that #4 is probably the easiest option for now. I would like to progress from these placeholders as quickly as possible in the following stages, so I think this covers our bases. I also don't mind the modal, but I understand that it takes longer dev time and is a temporary fix.

I have noticed a lot of text in this block with the new notice, so I'd suggest editing it to make it quicker to digest and comprehend. I know I input on this copy in another issue, but it still could sound very technical to a non-expert. I would be even more explicit in its purpose and rephrase it to say something like:

"ATTN: Do not remove this block. This is a placeholder for the WooCommerce Product Archive block template. On your store, this will be displayed as a grid of your product image(s), title, price, etc."

That being said, it might be helpful to have something to refer to if the user accidentally deletes the block. But I am not sure the best place for this is in the block itself. It might be useful to have a link to reference "I removed a placeholder block, what do I do?". And also make support aware of this.

Also as @frontdevde mentioned above, I think being careful we aren't highlighting a shortcoming is key. Maybe we can link to upcoming plans for the templates? (not sure if we have that somewhere easily accessible). Or if not, we can include "This block template is in development. Keep an eye out for updates!".

[Aljullu]

Thanks for writing this up and summarizing the challenges of this issue @sunyatasattva! I agree with everything that has been said in this thread so I don't have much to add, but will leave my two cents below:

1. Ignore the issue as it's going to go away when blocks get phased out.

As some have already mentioned, realistically it will take some time until those blocks can be completely phased out, so I agree that we need to find a temporary solution until then.

This would be my preferred solution. That said, I'm not certain it is possible to limit a block to only appearing in the block inserter on specific block templates. We can open another ticket for a research spike to look into this.

That would be great and seems like a good fit for the Store Editing Templates v2 project, @frontdevde. One interim solution that might be easier to implement is to hide that block from the inserter in the Post/page editor but show it in the Site editor.

Also like @frontdevde said, this is a temporary situation until the PHP blocks get phased out. It might be re-assuring to the user to know this is temporary, and that it won't be a problem in the future. I would suggest adding to the warning message words to that effect to comfort the user.

That's a good point. I think there might be value in showcasing that those blocks are a temporary replacement for the block templates but in the future they will be deprecated in favor of smaller/more specific blocks.

[sunyatasattva]

Thanks everyone for your thoughtful answers.

I especially agree with @vivialice that the copy right now is just too long and should be shortened. I'm absolutely horrible at copywriting, so I'd ask perhaps someone else to come up with a definitive copy for the entire block? Perhaps @nielslange as I see you are marked as a communication domain expert or maybe @vivialice with your UX expertise?

I agree with what has been said that this copy should be:

• Short
• Non-technical
• Reassuring
• Pointing out the temporary nature of this hassle

Recap

So, to recap, we agree that our favorite short-term solution is to edit the current block copy, and the longer term solution would be to figure out if we can enable legacy blocks insertions only on certain templates, and the longest term solution is to phase out those blocks. Is that correct?

What should the next step be, then? Should this ticket be used to improve the copy, or should we open separate tickets for:

• Edit the copy (+ perhaps adding the FAQ mention that @vivialice proposed)
• Research + implement (?) the block insertion limitation

How does this sound? Am I missing something?

[frontdevde]

That would be great and seems like a good fit for the Store Editing Templates v2 project, @frontdevde. One interim solution that might be easier to implement is to hide that block from the inserter in the Post/page editor but show it in the Site editor.

Created a related issue for this task #5193

[frontdevde]

What should the next step be, then? Should this ticket be used to improve the copy, or should we open separate tickets for:

Edit the copy (+ perhaps adding the FAQ mention that @vivialice proposed)

@sunyatasattva Yes :) Could you please create a follow-up issue to address 4. as proposed in this issue and add it to the Store Editing Templates v2 milestone? Thank you!

Research + implement (?) the block insertion limitation

Done, see #5193

[sunyatasattva]

Closing this as we now have #5193 and #5207 to address the discussed points.