Amp-wp: Global Error Handling

[jauyong]

Feature description

As a user I want there to be a more holistic approach to error handling in the editor.

---

_Do not alter or remove anything below. The following sections will be managed by moderators only._

Acceptance criteria

• AC1: Review upstream error handling first and reach out to the Gutenberg UI team
• AC2: If not there, or backlogged, discover our own version of error handling.
• AC3: Error handling should account a consistent way to present errors in the editor to make it easy for users to see the errors, and action on them.
• AC4: Currently errors display in multiple places: top of page, right rail, etc. Ensure all error spaces are accounted for, and considered when updating global error handling.

This item is blocking #3303 #3304 and #3306

Implementation brief

QA testing instructions

Demo

Changelog entry

[swissspidy]

@jauyong Is this now for error handling or opacity?

[swissspidy]

For error handling, this might be useful:

https://twitter.com/rmccue/status/1173550662296190976
https://github.com/humanmade/publication-checklist/

[jauyong]

Thanks @swissspidy sorry, I thought I updated it but I guess it didn't save.

[samitron7]

UX requires @swissspidy to help provide a list of errors. Immediate UX needs are to help provide copies and create rules around error handling and to adhere to Gutenberg notification components for error messages.

Note: UX can provide designs mirroring Gutenberg error handling but I would like to revisit this topic and see if we can introduce a visual language [with the Gutenberg team] to help users quickly delineate between error types and provide a path to attend to things that can break their stories.

[westonruter]

Another error condition to consider is not providing a poster image. This error comes up less often now that the poster image is automatically extracted (usually) but it can still happen. See #3114.

[ThierryA]

Review upstream error handling first and reach out to the Gutenberg UI team

@swissspidy what is the outcome, is there any effort upstream to improve error handling overall? If not, l suggest to go with our own implementation and circle back to the Gutenberg team (opening an issue upstream or reach out to whom?).

https://twitter.com/rmccue/status/1173550662296190976

This is actually pretty cool, although it might be out of scope for this issue. Could be a great future enhancement. cc @jasti

[swissspidy]

I‘m trying to get some answers on that today. Doing our own thing would be AC2 then :-)

[jasti]

After spending some time with @samitron7, we decided to adhere to a few principles for global error handling which impact how we handle these 3 items: #3303 #3304 and #3306

1. We should never show an error when in the stories editor (there might be rare cases which result in system errors but these should be really rare and could be combined with 2, but with a different treatment).
   The manifestation of this principle is that we get rid of any ability to add custom code or edit a story in the code mode. @MackenzieHartung, @kmyram, could you please create an issue for this?
2. We need a consistent place in the editor that communicates feedback to the user.
3. At publish time, we show a warning checklist (which covers results from issues like #3303 #3304 and #3306 as FYI but never at creation time).
4. When a user taps on a FYI warning, they are taken to the block in the editor that's the cause of the error.
5. We also need to be less aggressive about showing warnings, unless we are absolutely sure that it improves a user workflow. (e.g. color contrast warnings are too aggressive right now)

@swissspidy, others, WDYT?

@ThierryA @MackenzieHartung, @kmyram can we pause on #3303 #3304 and #3306 until we've nailed down the feedback framework that @samitron7 finalizes based on these principles?

[swissspidy]

@amedina ping ^

[ThierryA]

@ThierryA @MackenzieHartung, @kmyram can we pause on #3303 #3304 and #3306 until we've nailed down the feedback framework that @samitron7 finalizes based on these principles?

Sure thing @jasti, I moved these issues in the "Revisit Later" column.

[swissspidy]

The manifestation of this principle is that we get rid of any ability to add custom code or edit a story in the code mode.

I created a new issue for it: #3496. Thanks to a rather recent enhancement in Gutenberg this should be rather _easy_ to implement, unless something has changed since then.

We also need to be less aggressive about showing warnings, unless we are absolutely sure that it improves a user workflow.

Another example we've discussed in person: when a CTA block ends up being on the first page (which is invalid), we should probably just remove the block instead of showing a warning.