Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set alert colors based on alert level #1405

Merged
merged 12 commits into from
Jul 3, 2024
Merged

Conversation

partly-igor
Copy link
Collaborator

What does this PR do? 🛠️

This PR adds logic to apply different color styles based on the alert level as designed in #1074. On the daily overview, for days when there are multiple alerts, we find the highest alert level for that day and that level determines color of the "Multiple alerts" alert.

Close #1322

Screenshots (if appropriate): 📸

Screenshot of updated alerts with colors determined by alert level on mobile
Screenshot of updated alert colors on desktop

Copy link
Contributor

github-actions bot commented Jul 2, 2024

This PR modifies theme Javascript or CSS assets but does not update the theme libraries file. Did you mean to update the appropriate version information in the libraries file?

@partly-igor partly-igor requested review from greg-does-weather and eric-gade and removed request for greg-does-weather July 2, 2024 21:02
Copy link
Collaborator

@greg-does-weather greg-does-weather left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

I love color

I'm not doing a deep look at the a11y on this one because the only thing that should have changed is colors, and those have been vetted by USWDS to have suitable contrast.

Code Review Checklist

A checked item is either an assertion that I have tested this item or an indication that I have verified it does not apply to this pull request.

The Basics

  • Checks are passing
  • I read the code
  • I ran the code
  • (if applicable) Post deploy steps are run
  • (if applicable) I validated the change on the deployed version in

Documentation

  • changes to “how we do things” are documented in READMEs
  • all new functions and methods are commented using plain language
  • any new modules added documented in modules.md

Security

  • security false positives are documented
  • data from external sources is cleaned and clearly marked

Reliability

  • error handling exists for unusual or missing values
  • interactions with external systems are wrapped in try/except
  • functionality is tested with unit or integration tests
  • dependency updates in composer.json also got changed in composer-lock.json

Infrastructure

  • all changes are auditable and documented via a script
  • it is clear who can and should run the script
  • (if applicable) diagrams have been updated or added in PlantUML

Accessibility

  • New pages have been added to cypress-axe file so that they will be tested with our automated accessibility testing
  • Meets WCAG 2.0 AA or 2.1 AA for Section 508 compliance
    • Site is keyboard accessible. All interactions can be accessed with a keyboard
    • Site is free of keyboard traps. The keyboard focus is never trapped in a loop
    • All form inputs have explicit labels
    • Form instructions are associated with inputs
    • All relevant images use an img tag
    • All images have appropriate alt attributes
    • Multimedia is tagged. All multimedia has appropriate captioning and audio description
    • Text has sufficient color contrast. All text has a contrast ratio of 4.5:1 with the background
    • Site never loses focus. Focus is always visible when moving through the page with the keyboard
    • Tab order is logical
    • Tables are coded properly. Tables have proper headers and column attributes
    • Headings are nested properly. Heading elements are nested in a logical way
    • Language is set. The language for the page is set
    • CSS is not required to use the page. The page makes sense with or without CSS
    • Links are unique and contextual. All links can be understood taken alone, e.g., ‘Read more - about 508’
    • Page titles are descriptive

Device Matrix

  • firefox/gecko (renders correctly and user interactions work)
  • chrome/chromium/edge (renders correctly and user interactions work)
  • safari/webkit (renders correctly and user interactions work)
  • web page is readable and usable
    • at 480px (mobile)
    • at 640px (tablet)
    • at 1024px (desktop)

Comment on lines +642 to +650
/* Determine the "level" of the alert (warning, watch, advisory, etc..)
* based on the the last word in the alert event name
* */
public static function getAlertLevel($event)
{
$eventWords = explode(" ", $event);
$alertLevel = strtolower($eventWords[array_key_last($eventWords)]);
return $alertLevel;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is mostly fine, but there's an alert type for evacuation immediate and it's pretty high-priority so I'm guessing we don't want to classify it as an other. There's also civil emergency message, and both are prioritized above hurricane warning.

Let's roll with this for now, but I'm going to create a debt ticket here. I think it might make sense to have a different data structure for our list of known events and the high-level level can be associated directly to the event. But that doesn't need to be dealt with here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted in #1407

foreach ($alerts as $alert) {
if ($alert->alertLevel == "warning") {
$highestAlertLevel = "warning";
break;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I have deep-seated feelings about flow-control statements like break, but this seems like a great way to use it.

Comment on lines +5 to +19
{% if alert.alertLevel | lower == "warning" %}
{% set alertBgColor = "wx-bg-red-10v" %}
{% set alertBorderColor = "wx-border-red-40v" %}
{% set alertBodyStyle = "warning" %}
{% elseif alert.alertLevel | lower == "watch" %}
{% set alertBgColor = "wx-bg-yellow-5" %}
{% set alertBorderColor = "wx-border-yellow-50v" %}
{% set alertBodyStyle = "watch" %}
{% else %}
{% set alertBgColor = "bg-base-lightest" %}
{% set alertBorderColor = "wx-border-gray-cool-30" %}
{% set alertBodyStyle = "other" %}
{% endif %}
<div class="usa-alert usa-alert--warning usa-alert--slim margin-top-0 margin-bottom-1 padding-y-05 {{ alertBgColor }} {{ alertBorderColor }}" role="alert">
<div class="usa-alert__body wx-alert-li--{{ alertBodyStyle }}">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't do this today because our list of possible alert levels is based on another data set, but if in future we redesign that data set to include levels and we constrain the list of levels accordingly, we can make this update as well:

Suggested change
{% if alert.alertLevel | lower == "warning" %}
{% set alertBgColor = "wx-bg-red-10v" %}
{% set alertBorderColor = "wx-border-red-40v" %}
{% set alertBodyStyle = "warning" %}
{% elseif alert.alertLevel | lower == "watch" %}
{% set alertBgColor = "wx-bg-yellow-5" %}
{% set alertBorderColor = "wx-border-yellow-50v" %}
{% set alertBodyStyle = "watch" %}
{% else %}
{% set alertBgColor = "bg-base-lightest" %}
{% set alertBorderColor = "wx-border-gray-cool-30" %}
{% set alertBodyStyle = "other" %}
{% endif %}
<div class="usa-alert usa-alert--warning usa-alert--slim margin-top-0 margin-bottom-1 padding-y-05 {{ alertBgColor }} {{ alertBorderColor }}" role="alert">
<div class="usa-alert__body wx-alert-li--{{ alertBodyStyle }}">
<div class="usa-alert usa-alert--warning usa-alert--slim margin-top-0 margin-bottom-1 padding-y-05 {{ alert.level }} {{ alertBorderColor }}" role="alert">
<div class="usa-alert__body wx-alert-li--{{ alert.level }}">

@greg-does-weather greg-does-weather mentioned this pull request Jul 2, 2024
2 tasks
@partly-igor partly-igor merged commit ee60d32 into main Jul 3, 2024
14 checks passed
@partly-igor partly-igor deleted the ik/1322-alert-colors branch July 3, 2024 14:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update alert colors
2 participants