Review UX for inline validation of elemental blocks

[maxime-rainville]

As a content author, I want clear indication when one of my content block contains invalid data so I remedy the problem.

Context

Elemental has never had proper inline validation before. We are looking at remediating this:
#329

This does open a bunch of related questions:

• How do we flag that a block you just tried to save has problems?
• If a block already on the page is in an invalid state, how do we warn you?

Acceptance criteria

• Blocks in an invalid state are highlighted ... even if the content author has not editing them in the current session.
• If a Block is being edited to be in an invalid state, the content author is blocked from saving it and receives meaningful feedback of what they need to change

The status quo

• YouTube video illustrating how elemental validation is not great

Related

• Support validation within in-line edit context #699
• Implement validation method for inline editable form #329

[maxime-rainville]

Some very relevant question from @GuySartorelli

There are some UX considerations we need to consider before implementing this, such as:

• Do invalid blocks get expanded automatically?
• Do invalid blocks get highlighted e.g. with a red border?
• How do we display validation errors that apply for a block but aren't for a given field?
• How do we deal with validation errors in a separate tab on of the block (e.g. settings tab on the block)?
• What about validation errors for the ElementalArea field itself? Is that in scope?
  • Should those be displayed above (non-standard but means those messages are easier to see and relate to the elemental area) or below (more standard but content authors won't notice them until they scroll past the elemental area)?
• Should we display a summary of all validation errors in some central place? IIRC that's what you're meant to do for accessibility - though that should probably be for the form (or at least the current tab of the form) as a whole, not just for the elemental area?)
• Presumably when saving a block from the ... menu on the block itself, its validation error status will change independently from all other blocks (i.e. other blocks which already had visible validation errors will still have those visible validation errors)

[GuySartorelli]

If a block already on the page is in an invalid state, how do we warn you?

This should be treated the same as an invalid value in any field on any form. We shouldn't be treating this differently for elemental than for anything else. i.e. we should only show validation errors after validating, which only happens on form submission.

[maxime-rainville]

I had a catch up with Cassie to discuss the UI questions. This are some of the questions that came out.

• There's currently no distinctive UI when a FormField is required. You have to submit the form to discover that a field is required.
• Form fields look different based on whether they are rendered through React or through entwine.
• The Elemental errors are only showed if the rest of the page is valid.
• Elemental blocks need to be saved before the user can interact with them. Normally, this involves suppressing validation on creation. This means that some blocks will be "broken" on creation. We need to decide how to render those e.g. Do we mark them as broken before the user even had a chance to interact with them.

Relevant pre-existing UI

Page with validation error in a tab

Regular field and LinkField each with validation error

LinkField with invalid data

Page with bad elemental block after save

Toast notifications

We have some pre built Toast notification which could be use validation. They have multiple styles. for different context and degree of badness.

View Toast in our pattern lib