e3.v2 short term forecasts (hourly)

[janelx]

Product flow (in figma): From weather.gov

Supported user stories

• 3.3 … I want to view short and longer term weather forecasts
  • long term forecast story is here e3.v3 daily forecasts #178

Story details: As a member of the public

• I am able to understand what the basic weather will be for each hour for the next 4 hours

Design (define/discovery)

• Completed during prototype phase

Support needed

• Weather API (forecastHourly, forecastGridData)
• Weather icons
• Speech to text for summaries (need to discuss between PD, eng, and PM if part of this issue)

Acceptance criteria

Criteria outline in figma
As a member of the public I can easily understand:

• what the weather will be for each hour for the next 4 hours for a specific location
  Additional UX research/continuous discovery
• Qualitative experience of accessibility:
  • Screenreader experience of listening to the weather components
  • Experience of navigating weather data for screenreader, select, keyboard shortcuts
• Are we showing the most accurate and useful data?
  • For is it accurate/useful information to show PoP in the contents of the weather icon? API response examples.
• Is it easy to understand? Is the understanding accurate (enough to make a decision)?

---

General

• Responsive
• USWDS friendly
• Section 508 compliant

Short term forecasts >= tablet - 12 col grid

Hour title (12 PM, 1 PM, etc)

• h3
• hourly beginning with next hour. Ex. If it is 11:01 to 11:59 show for 12 PM, 1 PM, 2 PM and 3PM (four hours)
• time zone is relative to the forecast location not browser location

Conditions (icon and description)

• NOAA weather icons - max height: 64px or max width: 72px
• Icon description from Icons api
• text: 'body'

Chance of precipitation:

• Probability off precipitation as a percentage [probabilityOfPrecipitation]
• 12 px / gray-cool-50

Temperature

• temperature in Fahrenheit, [temperature], [temperatureUnit]
• font-size:32 (or nearest utility class)
• degree f font size: 12

Mobile

Review: design, function and flow:

• POs - org alignment and vision review
• Eng - feasibility review
• UX - what and how to test

Story details

• Reviewed designs (must be attached)
• Acceptance criteria define (added to this story)

[janelx]

summary/reflection from conversation on showing probability (conversation in slack and meetings):

hypothesis: it is useful for people to at-a-glance

1. understand the probability of precipitation and the type of precipitation
2. understand the probability of certain weather conditions (ex. thunderstorm, blizzard, rain, etc)

Questions:

• Can I design a uncluttered view that accurately displays both? (i will try next week)
• Are there probability data points for other weather conditions like blizzards, tropical storms, etc? Are there useful correlations with prob of precip or any other data points?

Assumptions

• We are not tackling display/indicators of intensity or associated WWAs in this story - but will in the hazard alert stories - this may slightly adjust layout
• There will likely need to be a detailed view of weather, where we can display lower priority data -> maybe future iteration

Challenge

• What is a lean design/build to begin learning from?
• Viewing/testing the diversity of data, contexts, and possible correlations

[colinmurphy01]

I think this has been through some mix of Design, Eng, and PO Review.

When the outcomes of the discussion (above) are addressed, I'm assuming this shouldn't need to go through review again? Or should go through async review? What are your thoughts @janelx? I'm trying to use this as a precedent for managing reviews in the future.

[janelx]

@colinmurphy01 it needs at least PO review when the above is sussed out.

[janelx]

Update on review status: posted options for displaying PoP vs Chance on slack for @shadkeene to review. Reviewed with design this morning, and reviewing w/engineers this afternoon.

[janelx]

Link to outline of pros/cons using PoP vs Chance

[shadkeene]

@janelx @colinmurphy01 Design a) approved from PO perspective. Had good tagup with Janel on this. Few key things we need going forward are to be able to view multiple sites at once during development for q/c in different weather situations...and to understand what numbers/words show up in API when there are 2+ precipitation types.

[janelx]

• added under ux research/continuous discovery - want to better understand the usability and accuracy of using this diplay and datapoints (Chance/PoP). This isn't a blocker - it's just to make sure we are continuing discovery on lower confidence pieces of the design. We just won't know till we are able to look at more combinations of weather types and corresponding data. Also, maybe able to get some useful insight from HazSimp researchers.

[colinmurphy01]

I think this is ready for dev for this sprint, I'm going to move this to the backlog and tag it as Eng

[greg-does-weather]

We currently don't have a convenient way to get the timezone information for a WFO grid point.

What we'll have to do for now, I think, is use the WFO grid coordinates to hit the API's /points endpoint a second time, because that does return timezone information.

[colinmurphy01]

Claire to-dos for w/o 11/06:

• Now: Stubbed Desktop and Mobile version (will have PR for that)
• Next: Design review
• Next: Design fixes
• For greg upon return: Integrating with API

[claire-skies-noaa]

Stubbed design in PR 395

A few comments:

• Depending how data comes in, consider using element instead

  for hour display

• Minimum height on table and desktop is 160px (USWDS class minh-card). Spacing is distributed equally vertically the higher the block.