Reconcile Full-width Alert vs. Banner

[humancompanion-usds]

Full-width Alert: https://design.va.gov/components/alert#full-width Banner: https://design.va.gov/components/banner

We're missing the Full-width Alert variation in our Sketch file and thus I was just about to add it. But I'm reading the guidance and I'm hard pressed to tell the difference between this Alert variation and the Banner. My understanding on the use cases for Banner from Dave Conlon was essentially what is under the Full-width Alert variation (i.e. a hurricane alert; government shutdown affecting VA services, etc.) They show up in different places but otherwise how does one choose between them?

Discussed with Allison who offered up this:

Per our guidance, full width...

• Full-width alerts are used only for emergency or urgent communications and should appear below the main navigation.
  • So would urgent be the blue info alert style? I assumed urgent would be the red or yellow.

And our guidance for banner is...

• When there is very important information that should exist on the top of the webpage that should be visible to all users.
  • I assumed that would be blue info or possibly yellow warning. But not red Emergency alert (full width) should appear below the main navigation and very important information (banner) at the top of the webpage.

It strikes me that there are two problems here:

1. The styles of alerts offered in both cases seem dubious.
2. Very important information vs. emergency information. The urgency of the comm is also relevant here though, again, we just decided to put the IE11 warning for those users in a Banner which will run for week or months and thus, in my mind, is not terribly urgent. Timely maybe.

In short, we need to do some investigation and make some decisions in order to provide clear guidance on when to choose. We may also decide to merge these into different variations of the same component.

[seanasewell]

@humancompanion-usds I read the documentation a few times and am still confused. I agree, it seems like it should be merged. This might be an unpopular opinion but I only see site-wide messaging as informational. Informational with two variations:

1. Informational (dismissible): Example is a Covid 19 banner message. This message warrants a site-wide banner message because it is important site-wide information to the user. It will live on the site for awhile so it should be dismissible. Why? Because the message doesn't affect if or how a user completes tasks on the site.

2. Informational (not dismissible): Example of this is a temporary governmental shutdown. This message warrants a site-wide banner message because it is important information to the user. It will be a temporary message so it shouldn't be dismissible. Why? Because the message does affect if or how a user completes tasks on the site.

It feels inconsistent to me for a site-wide banner to be in a warning or an error state. We use warning and error states to signify consequential actions. Usually seen on-page or in-line of something.

Warning state - Used to warn a user, such as when there are negative consequences, and when something has gone wrong. Error state - Used when there is a problem or something destructive is about to occur.

Site-wide banners aren't typically consequential are they? Unless we are warning the user that the site is going to blow up as a consequence of one of their actions, I don't see a use case for it. Even in the example we have in our documentation, we've represented an informational message with the styling of an error alert. This doesn't make much sense to me. The message is also being represented in a dismissible and non-dismissible state. But how does a designer know when to use one over the other?

Like I said earlier, this might be an unpopular opinion 😂

[GnatalieH]

@humancompanion-usds and @seanasewell I want to share the Homepage banner product outline that @thehastingsp shared with me this morning. She has some upcoming work that may be relevant. Just some background info for y'all.

[GnatalieH]

I also want to share this article on notifications that I came across this week. This graphic really stuck with me:

I don't want to sidetrack the conversation, but I like the idea of being strategic about system communications to the user and potentially having a hierarchy for different types of comms.

[caw310]

@seanasewell

• [ ] Identify the differences between banner and full width alert
• [ ] Make a recommendation for keeping both or keeping one and dropping the other
• [ ] Draft of the guidance based on your recommendation (put in this ticket)
• [ ] Follow up with Matt as needed to discuss

[humancompanion-usds]

@seanasewell - While I'm out on vacation here is how we can move this issue forward. Based on the conversation in DSC and looking at the audits and our existing content IA, here is what I'd like to propose:

1. Re-define our Banner component and limit it to System Maintenance

• There is only one use case for this component: System maintenance. This is already in agreement with what the Content team outlined: https://design.va.gov/content-style-guide/error-messages/system It also is in agreement with how we named the component in Storybook: https://design.va.gov/storybook/?path=/docs/components-banners-maintenancebanner--before-maintenance
• We'll have 2 banner variations: "Banner - System Maintenance" and "Banner - Promo". The former is this one and the latter is hopefully going to get deprecated. But this naming is in keeping with how we dealt with Progress bar (Progress bar - Activity and Form > Progress bar - Segmented).
• Thus the examples in va-banner go away. I leave it up to @k80bowman how we want to deal with the code. I know we were going to convert MaintenanceBanner from React to web-component but perhaps we just say va-banner, which is already converted, only exists for the Maintenance use case and for the specific messages Content has already defined. In other words, similar to Button Pair, you get to choose from the options we make available. You don't get to invent a new use (has to go through Content; we need to confirm with the Content team if they think that's reasonable).
  • Agree with you Sean that the examples in all of these are inconsistent with the guidance. We should use only real-world examples that the Content team has written which are in our system in the Content section. (Beth and Danielle do inform me that there are a few messages missing that need to be added but that should not impact this work. Just an FYI.)
  • I would like us to explore at some point down the road reconciling this with https://designsystem.digital.gov/components/site-alert/ but it is not a priority.
  • A task here is to write a draft of the guidance. It should be short, mainly taking away from what is in va-banner and pulling in Content considerations that point to the System content. It also MUST mention that the placement for a Banner is ABOVE the header. My understanding is that is where they actually appear.

2. Break full-width Alert out into a distinct new component: Announcement

• This is currently the https://design.va.gov/components/alert#full-width variation.
• I've proposed a redesign for this: https://www.sketch.com/s/0121feca-e7ce-478c-af70-2597facc7ee1
• This will be strictly and exclusively for Facility announcements (VA.gov home page will be handled by the home page redesign).
• Obviously this will require some coordination with the sitewide CMS to figure out where these messages get codified. If you reference the link Natalie shared above it seems like there is work that sitewide is doing to resolve some of the issues with OIPA posting alerts.

3. We update the Alert component to be clear that it is not for those other 2 components

• Alerts are just for in-app, in-page, not full-width Alerts/Announcements.
• Content is outlined here:
  • Alert boxes called out here: https://design.va.gov/content-style-guide/error-messages/access
  • Alert boxes called out here: https://design.va.gov/content-style-guide/error-messages/system (If we want to split this one Content page into 2 I would be for that)
  • https://design.va.gov/content-style-guide/error-messages/engagement
  • https://design.va.gov/content-style-guide/error-messages/feedback

In short, I think the Content team already did the hard part by defining the IA and which component is used when. It's just that our component documentation tries to be too generic and not point folks to those distinctions. In fact, we don't even link to the Content guidance on those components. Compounding the problem is all of the full-width alerts that really should be Facility based (which we covered in DSC) or written by the Content team and simply selected by the appropriate authors.

Tasks are to coordinate with Katy on the code for each and to start on the Sketch updates. If you get to the draft of the guidance revisions, great.

[humancompanion-usds]

I updated my previous comment based on conversation with Sean and Natalie.

[k80bowman]

@humancompanion-usds I just read through your comment. There is quite a bit of engineering work, here is how I would break down what I'm seeing:

• Update examples in Storybook for banner and alert components to use real-world text from the Content section of design.va.gov
  • I added this first because it is low-hanging fruit that we can get done quickly before we start to make some of the larger changes that will take more time.
• Re-name the current banner variations in Storybook and design.va.gov.
• Add the current maintenance banner functionality to the va-banner web component and have it be a banner option that can be selected by prop.
  • Also limit uses of this component to examples provided by the content team as we do with the progress buttons. Teams can use a prop to pick the option they need.
• Build alert-full width component and remove the full-width option from the va-alert component
  • currently no one is using the full-width option of the va-alert component, so it should not be a big deal to remove it.

Does this sound reasonable?

[humancompanion-usds]

@k80bowman - Let's meet and discuss. After the meeting with Dave and co. I think we can shorten this list.

[k80bowman]

Notes from discussion with @humancompanion-usds:

• We will update examples in Storybook for alert components first. We will also point the Banner component documentation on design.va.gov to the React MaintenanceBanner component temporarily, until we can add the date functionality to the va-banner web component.
• Next, we will break the alert-full-width component out into a new Announcement component.
  • The static content teams are currently using utility classes to create their full-width alerts, so it should not be a big deal to remove this functionality from the va-alert component, but we will want to double check and be careful. Once the new Announcement component is ready we can work with the static content teams to upgrade.
• Then we will add the date functionality from the React MaintenanceBanner component to the va-banner component and update the component and content documentation to point to it instead. This will become the only usage of the banner, so we will need to work with teams currently using this component for other types of notifications to shift to using a different component (alert?).

[humancompanion-usds]

@DanielleThierryUSDSVA and I agreed as part of this work to reclassify the "We’re working on the site" message to move from Access to System and to use the MaintenanceBanner component.

[k80bowman]

After a couple of questions and a conversation with @humancompanion-usds, I wanted to document and clarify the engineering strategy for this work. I've written it up in a Confluence doc, but to summarize what is there, here is the work I am recommending:

• Clean up alert and banner examples
  • Remove the full-width alert example from Storybook and design.va.gov
  • Update Storybook examples for the alert component to use real-world text from the Content section of design.va.gov
  • Update the banner component page on design.va.gov to point to the React MaintenanceBanner component in Storybook (until we can build the va-banner-maintenance web component)
• Create va-announcement component
• Migrate users of va-banner to va-announcement
• Delete va-banner web component and remove full-width alert option
• Create va-banner-maintenance component

[humancompanion-usds]

@k80bowman and I talked again and decided to hold off on most of the engineering work until the following is done in guidance:

• "Revise Banner to set set rules around use" is my task to do what Dave asked for and use the existing component but with additional guidance for what can go in it.
• "Remove the full-width option from the alert component" is my task to just go comment it out for now.
• "Add MaintenanceBanner as Banner - Maintenance to design.va.gov." Also my task.

Some immediate dev tasks are:

• Remove full-width Alert from Storybook.
• Update the Storybook Banner examples to use language from Content messages dictionary.
• Update the Storybook Banner examples to show more than just error.

[humancompanion-usds]

Had a fruitful discussion with @DanielleThierryUSDSVA where we decided a few things:

First, we agreed that there is a need to move away from Alerts being used to highlight information on static pages. In particular, Warning alerts don't belong outside of user feedback. We also agreed that we could use another component to sit alongside Featured Content, which is for highlighting eligibility requirements. For that I suggested we repurpose the Alert - Background-only with icon informational component for strictly this purpose. We agreed and now will determine if that's possible in Drupal. I'm going to create a new issue to track this.

Secondly, we will create a video informing editors on the proper use of alerts and banners. Danielle has done this before on building a page. We can then link to that video, which will be in the Drupal Knowledge Base, from the Design System.