Goal: UX to research and understand how other Application Services communicate critical changes to customers.

The UX deliverable is to give a recommendation for how to best do this.

UX Conclusion: 

From my investigation it appears that RHOAM doesn't have a specific mechanism to communicate critical updates. RHOSAK for the most part relies on the c.rh.c console and Pendo to surface any messages in the UI, see examples below.

For their part, the RHOSAK team has been working on a document that (in theory at least) can be used as a basis for how all managed services should notify customers of critical events: (https://docs.google.com/document/d/1V8lwOpcheJTD9fVfHfRHQSnVY_V3LcSnUYBBUdkmCT8/edit?usp=sharing) 

That doc links to a spreadsheet that outlines the specific types of messages/events and how they should be communicated. See rows 6 through 9 for my understanding of the types of messages we are trying to capture in this issue. https://docs.google.com/spreadsheets/d/16P8nBve26kG6QlKInu8xbX4L7ahVEl0qvoMMAxRXHDY/edit?usp=sharing

For the c.rh.c UI, they have a guide for how to communicate maintenance notifications. This covers mostly in-progress maintenance notifications, but upcoming maintenance also follows the same pattern. Document: https://docs.google.com/document/d/1VLs7vFczWUzyIpH6EUsTEpJugDsjeuh4a_azs6IJbC0/edit?usp=sharing

And an example of an upcoming maintenance notification:  

UX recommends to follow the same process as RHOSAK, and the same look. Given we aren't in c.rh.c and don't have access to Pendo, a dismissable (not timed) Patternfly alert is acceptable until we are fully integrated into c.rh.c and have access to the Pendo alerts.