Feature for warnings - Githubissues

ramack commented 7 years ago

It would be great, if forcastie would warn me if a configured event is upcoming. Could be "frost" - right now summer is coming but in autumn it would help me to bring my flowers into the warm garage. For sure it is not helpful to be warned the whole winter time, so a setting would be good to enable the warning only after e. g. 20 day without frost.

Or on a hike ore bicycle tour it would be good to be warned of upcoming rain, telling me "rain in 35 min" - I don't know whether this is achievable with the current OWM data, but if there is a whether station in the direction from where the wind comes it should be possible to give such warnings.

And maybe also show official warnings.

ildar commented 7 years ago

Yandex weather warns about any weather change that may be important for a man: rapid warm/cold, rain etc. No need to configure anything.

ramack commented 7 years ago

maybe, but this seems not to be free software, isn't it?

ildar commented 7 years ago

Sure it's not. Just an example of UX

FridoDeluxe commented 7 years ago

OWM has a new beta feature called Triggers or Weather Alerts: http://openweathermap.org/triggers. They don't provide predefined alerts, instead the user can define certain conditions when to be alerted by polling the API. I'm not sure if the possibilities of this trigger API are sufficient for what you have in mind for weather warnings?

ramack commented 7 years ago

Yes, this seems to be exactly what I thought about. Even though a easy but still powerful UI for setting these is probably not straight forward.

FridoDeluxe commented 7 years ago

For the beginning a few built-in general triggers (extreme high/low temperature, heavy rain, thunderstorm...) inside Forecastie should be enough, they could be selected by the user if desired. But I see potential problems with the API key: If at a later stage triggers can be user-defined they are saved into the OWM account of the API key, additionally keeping track of weather triggers means probably more frequent polling and thus more API calls. This will not work with the built-in API key, if the users don't enter their own key (see #182).

ildar commented 7 years ago

Then this feature might require the user API key

robinpaulson commented 5 years ago

@FridoDeluxe raises a good point; since we got an upgraded API key it is likely not an issue. We can try, see what happens and then if there are problems, only allow the warning feature if the user has their own key.

robinpaulson commented 5 years ago

Thinking out loud, I would suggest the two pieces of information required for an alert (other than location, which for the moment I will assume is fixed) are the weather condition the user wishes to be alerted of and the time frame. For a first cut, I suggest the time frame should be limited to "During the next n hours/days", where n is configurable. Perhaps we make that more sophisticated later on. The weather condition we can break down further into two things: a particular quality (temperature, rain amount, cloud cover, wind speed) and a limit with greater than/less than operator. So for example: "Alert me if there is more than 5mm rain per 3hr block, in the next 12 hours"; "Alert me if the temperature will be less than 2 degrees Centigrade in the next 5 days". The initial point about deviations from the norm by @ramack is useful, perhaps we add that in later.

ildar commented 5 years ago

I'd be happy with 7 a.m. notification if a rain or snow or heavy wind is expected during the day. The notification is useless after 8 a.m. then I'm outside. Simple and useful.

Currrupted commented 4 years ago

I'd be happy with 7 a.m. notification if a rain or snow or heavy wind is expected during the day. The notification is useless after 8 a.m. then I'm outside. Simple and useful.

I love your ideas so far! How do the alerts by OWM look like exactly? Because the only implementation I have seen so far is in the official weather application of the federal weather service in Germany: grafik

Of course this is only one example of displaying weather alerts. Which alerts would have to be managed locally?

Lee-Carre commented 2 years ago

From thuryn/your-local-weather#109 in which I posted a bunch of thoughts & ideas on this concept:

This is something I've seen implemented in (OS bundled) proprietary apps, and makes the notifications much more useful.

I can have the app set to poll frequently (e.g. hourly) and not receive a notification all day (because the weather is uneventful). Other days I'll receive several notifications, because there's something important I should be informed of. It's auto-magic 🙂. Of course, this is how I choose to have it configured; other (more traditional) options remain entirely possible (can have multiple selected simultaneously, each with different modes of how intensely (prominence, sound or silent, vibration or not) they notify me).

From a usability perspective (of which I have experience & studied), if notifications are regular (hourly, or whatever interval the user has configured) regardless of weather conditions and/or forecast, then the user is having to do the filtering with his own brain. This (unless the user wants it that way) will increase mental fatigue and will likely cause him to ignore notifications or increase the API polling interval (which is a workaround for what he really wants: keep reading). Beyond a point, if those notifications involve playing a sound and/or vibrating the device (since weather info is important), this may be disturbing what he's trying to do (think of meetings, being at work, and any activity in meat-space).

With software (optionally) doing the filtering, then notifications are (ideally) only fired when there's something significant to report (and thus warrants drawing the user's attention). This is in-keeping with POSIX philosophy re quality design. See:

The Art of Unix Programming:

Rule of Silence: When a program has nothing surprising to say, it should say nothing

Silence is Golden

The Art of Unix Usability:

Rule of Distractions: Allow your users the luxury of inattention

Rule of Silence: When a program has nothing surprising to say, it should say nothing

Rule of Automation: Never ask the user for any information that you can autodetect, copy, or deduce

Thus, with effective filtering, the user can then have the best of both; frequent polling in order to have recent weather data, but only being alerted when the weather will affect his activities that day. At the moment (with indiscriminate notifications), polling interval is a trade-off between these two concerns (being frequently pestered with irrelevant info, or out-of-date info about an important change). Conditional-notifications breaks the dilemma.

The key criteria are, I think, going to be what triggers a notification and (at least as importantly) what doesn't trigger (inhibits / suppresses) a notification.

Based on my experience (since the source code is unavailable) with proprietary implementations, it seems to be some combination of

a significant event (rain, strong wind, snow, storms, and such)

significant difference from previously, especially when the change is to less pleasant conditions (see above); this has included (for example) when fog is predicted

what's generally considered ‘good’ (though, that's highly subjective) weather (e.g. clear & sunny) tends to not be notified, unless it's very significantly different from previous weather (e.g. rain) and is predicted to last quite a while (e.g. rest of the day); seemingly as a confirmation that ‘despite the earlier [rain, or whatever], the weather will be clear from now on’

However, instead of a fixed set of guesses, this app could supply sensible defaults, but enable granular configuration of exactly what constitutes

‘good’ / desirable / uneventful weather

‘bad’ / adverse weather

significant (change of) weather

because those vary dependant upon what he'll be doing (including his mode of travel).

Further, there could also be configuration of constraints, such as over how (in)frequently notifications are triggered. Examples:

no more than N per [time span] (an average min-interval)

not before N [time units (minutes, hours, days, whatever)] have elapsed since the last notification (a min-interval)

at least N times per [time span]; deliberately without specifying when(, for an average max-interval)

not between [hours] (e.g. overnight / sleeping, or when the user will be inside (at work)) and/or only between [hours] (daytime, or whenever), ideally also with the option to set which days, too, rather than assuming the same for every day; maybe a schedule-configurator to add arbitrary sets, each with a name, similar to a reminder app

varying the behaviour based on if the system's Do Not Disturb mode is enabled. Configurable; increasing the threshold of what counts as ‘significant’ weather and/or less frequent notifications. Make the configuration expressive so that users can yield the behaviour they desire; automation is a wonderful thing. Possibly (configurably) a confirmation notification when DND mode ends (or simply causing a repoll of weather, to then determine if there's anything significant enough to warrant a notification, based on configured criteria).

[The following may well deserve separate issue(s), since it becomes further out-of-scope for this issue's feature-request.]

Thinking more creatively, now; if ambitious, could implement a feedback loop between how frequently notifications are fired, and the polling interval. When there are infrequent significant changes / events (as the user's configuration defines that) then increase the polling interval (no need to check frequently when the weather is consistent). When there's enough variability to be notifying the user often, reduce the polling interval (to ensure that data isn't stale when the weather is changing quickly).

Beyond that, could also influence the polling interval based on

is the user out & about, or at home / at the office; more frequent while out, less frequent while stationary (which might reduce the need to configure a quiet period overnight: see above)

depending how the code determines out-and-about versus is-stationary, noticing if the user is travelling; in which case fetching data for the area being entered will become important, since the data for the area-being-departed becomes irrelevant (even if still recent)