Difference between revisions of "FloodNotifications"

From floodzilla-wiki
Jump to navigation Jump to search
Line 1: Line 1:
== Flood Notifications ==
+
==Flood Notifications==
  
 
We intend to build a system which will allow users to sign up for notifications when a particular set of gages they're interested in has reach flood stage, and again when the waters have receded.
 
We intend to build a system which will allow users to sign up for notifications when a particular set of gages they're interested in has reach flood stage, and again when the waters have receded.
  
=== Requirements ===
+
===Requirements===
  
* A user will be able to give an email address which will receive timely notifications of flood status changes.
+
*A user will be able to give an email address or phone number which will receive timely notifications of flood status changes.
* Various kinds of events can be separately subscribed to per gage:
+
*Various kinds of events can be separately subscribed to per gage:
** Flood status begins (define a notification water level threshold per gage?)
+
**Flood status begins (define a notification water level threshold per gage?)
** Road underwater
+
**Road underwater
** Road clear
+
**Road clear
* When it becomes possible to predict flood events, each predictable event should have a separate notification
+
*When it becomes possible to predict flood events, each predictable event should have a separate notification
  
==== Possible Requirements ====
+
====Possible Requirements====
  
* Other notification channels besides email
+
*Other notification channels besides email
** Text message?
+
**Text message - Yes
** Phone calls?
+
**Phone calls - Maybe future
  
* Other notification events that are not per-gage
+
*Other notification events that are not per-gage
** Region-wide "flood event starting"?
+
**Region-wide "flood event starting" (At some point we should incorporate the NWRFC forecast alerting that OG Floodzilla does and migrate users into this new site)
  
==== Explicit Non-Requirements ====
+
====Explicit Non-Requirements====
  
* We will not support sending notifications to non-registered users (i.e. you can't just give us an email address, you have to create an account with a password)
+
*We will not support sending notifications to non-registered users (i.e. you can't just give us an email address, you have to create an account with a password)
  
=== Open Questions ===
+
===Open Questions===
  
* How frequently will notifications go out?  
+
*How frequently will notifications go out?
* Do we need to have per-user or per-gage memory of last time a notification happened for a particular gage to avoid spam? (example: water level reaches road, goes below road level, goes above, all within a short period of time)
+
*Do we need to have per-user or per-gage memory of last time a notification happened for a particular gage to avoid spam? (example: water level reaches road, goes below road level, goes above, all within a short period of time)
* Do we need to track history of notifications we sent? If so, how and where?
+
*Do we need to track history of notifications we sent? If so, how and where?
  
== Building Blocks ==
+
==Building Blocks==
  
 
This will depend on implementing LoginAndSecurity.  Also, future-flood notifications will depend on FloodForecasting.
 
This will depend on implementing LoginAndSecurity.  Also, future-flood notifications will depend on FloodForecasting.
  
=== Email Notifications ===
+
===Email Notifications===
  
 
Doing email notifications will depend on (at least) having these features:
 
Doing email notifications will depend on (at least) having these features:
  
==== Email address verification ====
+
====Email address verification====
 
Add a workflow for verifying email addresses:
 
Add a workflow for verifying email addresses:
* Remember verification status (flag already exists in database; need to verify it works and clear all existing statuses)
 
* Clear verified flag if email address changes
 
* Generate and send 'click here to verify' email
 
* Build 'click here to verify' page
 
* Subscribe UI needs to show if email address is pending (or prevent subscribing until verified)
 
** add email verify status to AuthenticateResult so UI has access
 
  
==== Subscription management ====
+
*Remember verification status (flag already exists in database; need to verify it works and clear all existing statuses)
 +
*Clear verified flag if email address changes
 +
*Generate and send 'click here to verify' email
 +
*Build 'click here to verify' page
 +
*Subscribe UI needs to show if email address is pending (or prevent subscribing until verified)
 +
**add email verify status to AuthenticateResult so UI has access
 +
 
 +
====Subscription management====
  
 
Each individual event that can be subscribed to will need a subscribe/unsubscribe UI.
 
Each individual event that can be subscribed to will need a subscribe/unsubscribe UI.
Line 56: Line 57:
 
There will also need to be a simple "Unsubscribe me from all notifications" page that the email notifications can link to.
 
There will also need to be a simple "Unsubscribe me from all notifications" page that the email notifications can link to.
  
==== Background processing ====
+
====Background processing====
  
 
A background task will run at some appropriate frequency to monitor the state of all notifiable events.
 
A background task will run at some appropriate frequency to monitor the state of all notifiable events.
 +
 +
== Phase 1 - Fall 2020 ==
 +
 +
=== Features ===
 +
 +
* Email & SMS support (SMS can be phase 1.5)
 +
* Subscribe to all status changes for a gage (can't pick and choose for phase 1)
 +
 +
=== Events ===
 +
 +
* The events for phase I are all status changes: green to yellow, yellow to red, red to green, green to red, green to offline, etc..
 +
* We will include 'offline' as a notification worthy status change
 +
* For gages with associated roads, the red status should align to the road going under and the yellow status should be 6" or so below, just before water is on the road surface.
 +
 +
=== UX ===
 +
 +
==== Gage Details ====
 +
 +
* Add a card titled 'Status Levels'
 +
 +
{| class="wikitable"
 +
|+Status Levels
 +
!Status
 +
!Conditions
 +
|-
 +
|Green
 +
|Below XX.X ft
 +
|-
 +
|Yellow
 +
|At and above XX.X ft
 +
(0.5 ft below road saddle)
 +
|-
 +
|Red
 +
|At and above YY.Y ft
 +
(road saddle level)
 +
|-
 +
| colspan="2" |<link>Get notified when status changes</link>
 +
|}
 +
 +
====== Subscription Page ======
 +
<br />

Revision as of 21:31, 16 August 2020

Flood Notifications

We intend to build a system which will allow users to sign up for notifications when a particular set of gages they're interested in has reach flood stage, and again when the waters have receded.

Requirements

  • A user will be able to give an email address or phone number which will receive timely notifications of flood status changes.
  • Various kinds of events can be separately subscribed to per gage:
    • Flood status begins (define a notification water level threshold per gage?)
    • Road underwater
    • Road clear
  • When it becomes possible to predict flood events, each predictable event should have a separate notification

Possible Requirements

  • Other notification channels besides email
    • Text message - Yes
    • Phone calls - Maybe future
  • Other notification events that are not per-gage
    • Region-wide "flood event starting" (At some point we should incorporate the NWRFC forecast alerting that OG Floodzilla does and migrate users into this new site)

Explicit Non-Requirements

  • We will not support sending notifications to non-registered users (i.e. you can't just give us an email address, you have to create an account with a password)

Open Questions

  • How frequently will notifications go out?
  • Do we need to have per-user or per-gage memory of last time a notification happened for a particular gage to avoid spam? (example: water level reaches road, goes below road level, goes above, all within a short period of time)
  • Do we need to track history of notifications we sent? If so, how and where?

Building Blocks

This will depend on implementing LoginAndSecurity. Also, future-flood notifications will depend on FloodForecasting.

Email Notifications

Doing email notifications will depend on (at least) having these features:

Email address verification

Add a workflow for verifying email addresses:

  • Remember verification status (flag already exists in database; need to verify it works and clear all existing statuses)
  • Clear verified flag if email address changes
  • Generate and send 'click here to verify' email
  • Build 'click here to verify' page
  • Subscribe UI needs to show if email address is pending (or prevent subscribing until verified)
    • add email verify status to AuthenticateResult so UI has access

Subscription management

Each individual event that can be subscribed to will need a subscribe/unsubscribe UI.

Additionally it probably makes sense to have a single "Manage my subscriptions" page.

There will also need to be a simple "Unsubscribe me from all notifications" page that the email notifications can link to.

Background processing

A background task will run at some appropriate frequency to monitor the state of all notifiable events.

Phase 1 - Fall 2020

Features

  • Email & SMS support (SMS can be phase 1.5)
  • Subscribe to all status changes for a gage (can't pick and choose for phase 1)

Events

  • The events for phase I are all status changes: green to yellow, yellow to red, red to green, green to red, green to offline, etc..
  • We will include 'offline' as a notification worthy status change
  • For gages with associated roads, the red status should align to the road going under and the yellow status should be 6" or so below, just before water is on the road surface.

UX

Gage Details

  • Add a card titled 'Status Levels'
Status Levels
Status Conditions
Green Below XX.X ft
Yellow At and above XX.X ft

(0.5 ft below road saddle)

Red At and above YY.Y ft

(road saddle level)

<link>Get notified when status changes</link>
Subscription Page