Combined error state when ALL Key Metric Widget Tiles throw an error

[jimmymadon]

Feature Description

Key Metric widget tiles are much smaller than our usual widgets and hence require new error components to be designed as per the Figma mocks.

This issue was split out from #7149 since point 2 in that issue's AC was making things quite complicated.

This issue (#7311) focuses on the rather complicated and possibly rare error "combined" error state when all widget tiles throw an error:

#7310 focuses on the simpler error state for individual Key Metric widget tiles:

---

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

Acceptance criteria

• If all the Key Metric Widget tiles are throwing an error, then a single larger component should be rendered as per this Figma mock instead of multiple smaller tile errors.
  • Clicking on the "Retry" button should behave like our existing ReportErrorActions component invalidating the resolution of the selectors that threw an error thereby attempting to resolve those selectors again.
  • Clicking on the "Get Help" link should also behave like our existing ReportErrorActions component and use the getErrorTroubleshootingLinkURL selector.
• Any Key Metric widget tiles implemented already should have this functionality added to them. Tiles implemented after this feature is executed will reuse the components created as part of this issue.

Implementation Brief

Test Coverage

QA Brief

Changelog entry

[techanvil]

Please note, as this issue needs a bit of further consideration, when discussing this from a UX perspective we should consider these points that @10upsimon raised in his comment on the original issue:

• I have some concerns around the UX/UI implications of the "all widgets erroring" scenario, it would be quite visually jarring to go form 1, 2 or maybe even 3 rows of key metrics widget components to all of a sudden having a single error component that occupies considerably less UI space, do you think this needs to be raised with UX?

With regard to the point above, It's worth noting that in fact the "multiple rows" scenario will only occur in the tablet and mobile viewports with up to two and four rows accordingly.

• Given that loading states can be resolved at differing times, this too could be a UX consideration, having multiple widgets enter into individual error states, only to then be replaced with the single one as above.

The implication here is that we won’t be able to individually load widget tiles and would have to effectively wait until all the tiles are loaded before rendering any, if we want to avoid this scenario.

cc @sigal-teller

[jimmymadon]

@bethanylang Will run this past @marrrmarrr in our AC sync before closing this out as discussed in our last stand up.

[jimmymadon]

Based on the complications and UX considerations pointed in @techanvil 's comment above, we would be sacrificing UX in more frequent use cases than in the rare edge case of all tiles failing to load. So decided to close this issue in our AC sync on 7 Aug 2023.