Invalid Block Type dialog UX improvements

[daledesilva]

A number of open issues discuss block validation and deprecation, and specifically the idea that the user should see the Invalid Block Type dialog as little as possible. I agree with this reasoning, however, I believe a lot can be done to mitigate the complexity of the dialog itself - and that these changes wouldn't require significant change.

Pursuing a goal of showing the dialog less in general is a good goal too, however, it is a far more complex one and involves more risk. One of the risks being that silently changing the users data creates the possibility that they will save the post with changes they didn't intend.

By prioritising simplification of the dialog, the concern over the dialog presenting itself too often becomes less of any issue - as a less complex dialog would present less decision stress for the user, and contains little risk, as the user is notified of what will be occuring.

Currently, an invalid block appears like this...

The problem with the user experience, however, is that what most of the options do is unclear. I am a plugin developer, and even I am confused.

Convert to HTML

Anyone using this interface is working with a WYSIWYG editor. It is very rare that they will want to convert a block to html. This shouldn't be the promoted option, it should be hidden in a menu.

Attempt Block Recovery

The action that this performs is likely to be the action the user wants in 99% of cases; They are a CMS user, not a coder, but even a coder is likely using a CMS for a reason and wants this option most of the time - yet it is buried in a dot menu rather than promoted as the main option.

Further to this, it is named confusingly. No matter which of these options I choose, I am attempting block recovery - it needs to be more specific.

Resolve

This is also named confusingly. All of the above options are ways of resolving this issue - In what way is this button indicating it is different? What specifically is this button indicating it will do?

After clicking on Resolve...

In the dialog that appears after clicking Resolve, we're presented with another 2 options.

Convert to HTML

Why is this presented twice? Having the preview is helpful but at first glance it's confusing as to whether the one buried in the Resolve button does something different to the one outside the Resolve button.

Convert to Blocks

This is extremely confusing. It's called "Convert to Blocks", but it presents html in the preview and when clicked it converts to html. How is this different to "Convert to HTML"? Is it behaving correctly or is it supposed to do the same thing as Attempt Block Recovery (as I would have assume from the similar name - but this would make it redundant anyway).
Since I've tested all these options thoroughly for writing this post and am a block developer myself, but still don't know what this is supposed to do, it's pretty likely somethings not working here - possibly just the name.

Suggested solution...

Without changing the possible actions of this dialog. The design and wording can be improved to greatly reduce confusion.
This is what I suggest the block should look like when marked as invalid:

This does a few things...

Uses the word "block type"

By using the word type instead of just block, it doesn't erroneously imply to the user that their block is in any way compromised, but rather, simply that the type the block is built from has updated. This is reinforced by the update button specifically mentioning that it is "to enable editing" - rather than implying that action is necessary for it to keep working.

Uses the words "...to enable editing"

As mentioned above, the user needs to be reassured that their block is fine, it's only if they need to edit it that they need to take action.

Uses the words "newer version"

You may be thinking that isn't always the case, if the block pulls in post meta or something than it may be because that data (which is external to the block) has changed. That's true. If you build blocks like this, then this dialog is going to appear very often and goes against the current design intention of blocks.
As a side note, I have need for those kinds of blocks all the time - to do this, I suggest pulling in the post meta, then saving it to an attribute in the block. That way the block still has all the info it needs but can update after loading.
This kind of need can also be mitigated by dynamic blocks or accommodated by some of the other github issues mentioned at the end of this post that seek to limit when this dialog appears.
According to current architecture of how blocks work, however, I don't believe it should be taken into account in this dialog.

You may also be thinking that as a developer, sometimes you change things and get this error, even though you haven't created a "new version" per se. That's okay, as a developer, you can read between the lines of what's happening because you have more intimate knowledge of why it's happening. The dialog shouldn't focus on the developer and instead be as useful as possible to the end user (who has no intimate knowledge of how things work).

... there may also be causes I've missed here that are worth pointing out.

Alternatively... other wording for this could be "This block contains old data" - this could still work since the button is still explicit - This wording might even be better as it's more versatile.

Upon choosing to update...

After clicking update, we should see this dialog:

This dialog is similar to the current setup but with some important differences...

Compare old and new

Note that the left side is what the block currently looks like (what the user wants to match) and the right side is what it will look like after updating (Same act as Recovering). This is the information the user wants to know - ie. Will their block look the same as it did after updating as before?

Explicitly described

Note that what each side is demonstrating is explicitly described. There should be no room for misinterpretation.

Down the bottom, the action buttons are explicit also and there is extra description that gives the user advice on why they should choose either (because even now, the user might not understand what the purpose is - hopefully, the two images are the same - so they need to be told why they need to choose).

Code is de-emphasised

Note that while the code is available to view (probably another popup that puts the code side by side), it is hidden behind a link. It needs to be available for developers or power users, but it is not what most users of a CMS want to see - even if they are developers. Hiding helps you understand what you should be considering first and foremost.

Choosing other options

If you're comfortable with what you're doing and need code or more options, these are still available - but hidden behind a deemphasised link. Clicking View other options would open another popup dialog that looks like this:

Note that descriptions and buttons are all still as explicit as possible.
Also note that the Classic Block option shows a visual preview rather than code - though perhaps this should just be a text description mentioning that the html code will be the same but buried inside a classic block.

Lastly, I haven't included Convert to blocks because I still don't know what it does and can only assume it duplicates the functionality of something above.

In summary...

The above suggestions only involve interface design changes, and thus, shouldn't be as complex as other approaches to deal with block invalidation and migration. But even so, I think they will have a huge impact on this aspect for users.

Other relevant issues:
#7604
#21703

[samuelfarrell]

This workflow definitely makes more sense to me. I agree that the current flow is incredibly confusing and often mislabeled.

[amitpatel0702]

Thanks @dmsnell for merging into this issue.

Awaiting for updates on the same.