Consider displaying block errors in list view

[jameskoster]

Occasionally blocks exist on the canvas that will not render for one reason or another. It was discussed in other issues (https://github.com/WordPress/gutenberg/issues/40617) whether we should omit incompatible blocks automatically, but that is tricky because incompatible blocks can be inserted indirectly, like copy/pasting a pattern.

Currently there is no consistent way to handle erroring blocks. Blocks in core tend to throw an error in lieu of their intended rendering:

There are a couple of problems with this:

1. Blocks can occupy small spaces, and trying to fit a long error message into such a space can really mess with the layout and overall editing experience. Especially if there are many erroring blocks.
2. Depending on the theme, it's not always clear at a glance whether the error is a legitimate part of the design or not.

As an alternative we might consider highlighting errors in List View:

Here we can style rows to indicate errors (IE make them red), and have space to include a message. The button in the top bar can indicate how many errors there are at a glance.

cc @WordPress/gutenberg-design @ockham @c4rl0sbr4v0

[ockham]

Thanks @jameskoster, I quite like this! 🙌 Just to clarify, would we still indicate somehow in the canvas that there is an error with a given block (e.g. by greying them out or adding a red border or something to that effect)?

Also, would the pattern you suggest be amenable to adding buttons to resolve a given error (when possible), as discussed in https://github.com/WordPress/gutenberg/issues/40614 and explored in https://github.com/WordPress/gutenberg/pull/41603?

[jameskoster]

Just to clarify, would we still indicate somehow in the canvas that there is an error with a given block

Good question. I think anything we do on the canvas is going to be afflicted by the two points above, which makes it tricky. As an alternative could we use a Snackbar to alert the user when an incompatible block has been inserted, and include an action to open List View to investigate?

Otherwise I'm inclined to say it doesn't matter too much. It seems more important that the backend / frontend are matching, which hiding the 'broken' blocks will accomplish.

Where there any flows in particular that you had in mind?

Also, would the pattern you suggest be amenable to adding buttons to resolve a given error

In most cases I expect the resolution would be to remove the block, which is already possible within the list view UI. I suppose we'd need to figure out a list of potential actions to determine whether the design can / should accommodate them.

[ockham]

In most cases I expect the resolution would be to remove the block, which is already possible within the list view UI. I suppose we'd need to figure out a list of potential actions to determine whether the design can / should accommodate them.

So for the blocks that prompted me to file https://github.com/WordPress/gutenberg/issues/40614 and https://github.com/WordPress/gutenberg/issues/40617, the underlying problem is typically a post-specific or site-wide setting that would cause the block not to be rendered in the frontend, e.g.:

• Avatars disabled in Discussion settings (site-wide) cause the avatar block not to be rendered (https://github.com/WordPress/gutenberg/issues/41308)
• Comments disabled for a given post cause the comments form not to be rendered (https://github.com/WordPress/gutenberg/pull/41603)

In those cases, I thought it would make sense to offer the user an "easy fix" -- a button that would change the underlying setting (here: enable avatars site-wide, or enable commenting for the given post, respectively) so that the relevant block will be shown -- rather than suggesting them to remove the block altogether. (If their intent was to have the block there in the first place, it'd be otherwise more complicated to restore it -- they'd need to find the relevant setting, change it, and then come back to re-insert the block.)

[jameskoster]

Thanks for sharing the examples. Yeah I agree it seems fair to include actions like beneath the description for situations like these.

Such examples also make me wonder whether there should be a severity factor applied to the errors. These feel more like warnings as the blocks are not broken per se.

I'm also thinking we might use Snackbars as feedback upon insertion of blocks with errors / warnings.

https://user-images.githubusercontent.com/846565/174279617-16fe158e-4285-4d81-b23b-9053c5a5d858.mp4

[ockham]

Thanks James for this latest iteration -- looks good to me!

Such examples also make me wonder whether there should be a severity factor applied to the errors. These feel more like warnings as the blocks are not broken per se.

Sounds like a good idea 👍

I'm also thinking we might use Snackbars as feedback upon insertion of blocks with errors / warnings.

Also sounds good!

Some errors / warnings might occur after the fact, i.e. the block is already part of a post (or template) when a setting is changed. But maybe it's fair to display the snackbar when the user opens the editor the next time? (As long as it's not too many blocks / warnings at once, I guess.)

[jameskoster]

Ah yes good point. Disabling comments on a post when the comments form block is already present for example. I think it would be ok to utilise the snackbar there, and to combine multiple errors into a single Snackbar to avoid pollution.

It's probably something we'd have to feel out through some experimentation. The Snackbar may not even be necessary if we did something with the notification number on the list view button.

[jameskoster]

Leaving a note that this could also be a way to alert users to un-configured or empty blocks within a document.

[draganescu]

I think this is a good solution to stop showing messages in the canvas.

Users of assistive tech would still have to know they have broken or unconfigured blocks, so the blocks should still be "present" and focusable so the problems can be announced. This would make for invisible tabstops, and be a bit confusing in navigation mode as you'd move the caret in places that seem empty. How could we mitigate that visually?

Also for reasons of cognitive accessibility I think we should stick to snackbars instead of relying solely on the notification count on the list view.

[jasmussen]

Not just users of assistive technologies, anyone. List view (or document outline) come to mind, but also the pre-publish flow could have a panel that lists unconfigured blocks.

I'd use the default blueberry unread dot we use in a few other places, though, and consider having levels of error, such as "warning" (markup error, missing plugin) vs. "notice" (smaller issues like missing link or what brought us here, no pages which is harmless but good to know).

By including it in the pre-publish flow, we not only surface any issues before publishing, we surface it to folks who might not use the list view.

[jameskoster]

Agreed on Snackbars, there's a demo including them in this comment.

[karmatosed]

I think moving this out of need design and feedback, to focus just on feedback makes sense. I will adjust the labels and we can always iterate.

[Mamaduka]

@jameskoster, @jasmussen, is there a plan to move forward with this?

I'm asking because I think this placement would be more suitable for document-related warnings/errors, such as multiple main tags.

I think we can also use the core notices store with a special type for displaying errors/warnings in the List View.

Screenshot

[jasmussen]

IMO there needs to be a "linting" UI in the editor, yes. One that is accessible when you work with the doc, and one that can be resurfaced in the pre-publish flow.

It needs to be relatively low prominence most of the time, since there won't be errors, and then it needs a bit more visibility when there are, and of course extensibility so that plugins can add types of warnings or recommendations, like even SEO advice or perhaps even grammar. Where that feature lives, it's unclear. I think the List panel as outlined here is a good proposal, but it's not the only one. And I think it needs a fresh design, alas I don't have capacity to help at the moment.