Thanks for the post @DWSimmons. This is the kind of information I need.
for both your cases, what time window does the condition look at?
what happens when you have multiple data sources? e.g., in Europe you can have up to 12 data sources of varying resolution.
what about new forecasts? e.g., HRRR releases a new forecast each hour. What happened if the temperature cycles above and below the condition? Do you remove the notification? Do you re-notify for each forecast?
I would not do push notifications since it would require a remote server, logic and maintaining a database of conditions and possibly user accounts and logins. In other words, a lot of work and maintenance.
I would save notifications on the phone and like the widget check for new forecasts and notifications every 30 minutes.
I think it was pretty dumb, i.e. check once at time of notification and spit out answer, which was totally fine for me. For the time window, that calendar day: is the event predicted to occur? If yes, when, if no ignore.
I personally didn’t care. I understand from your side that doesn’t really help. Not only does a source need to be declared, as soon as such a feature is given, some user is going to want to specify which source. How about whatever source was last used to square the circle?
I get where you were going on this. The notifications I desire are super dumb and more of a task reminder than a prediction and nowhere near a fact.
FlowX has all sorts of cool data and multiple sources which I barely touch. I use it for the UI/UX and the UV (bad letter mixing intended).
Another use case I can think of is kiteboarding. I don’t do it though I understand wind direction and speed are conditions that are essential to know. For example, 8 am check if sustained wind will be above 15 knots, if yes, add direction and button to open app for details, if no, ignore. I am guessing that kiteboarders have an obsession with the weather.
App development is funny. For some types of features, if it doesn’t exist in an app, users generally don’t care or kindly ask for the feature. As soon as the feature is added, users complain it doesn’t do A, B or F. “Give an inch, take a mile” scenario. I suspect notifications is one of those features because of it’s complexity and the range of types of notifications. This is why I worry that if I don’t get it right, then it’ll be the bane of my life.
This is why I want a canvas of types of notifications users want, then I can design dialogs to create notifications and act out what might happen. If I don’t have a broad canvas of types of notifications, it’ll become and maintenance and migration nightmare.
One approach is to limit access, e.g., to gold only, and also class the feature as super-alpha, i.e., you might lose all the notifications you setup when the app updates.
multiple data criteria:
– data type
– modifier (min, max, change in 24hour, accumulation, etc…)
– comparison operator (==, >, <, in list)
– values
check period (every 30min, 1hour, 3 hours, 6…)
day range to check
time range within a day to check
data sources to check (all or selected set)
source criteria to trigger notification (one, most, or all sources meet criteria)
refactory period (how long after a notification is shown, shown it check again)
custom notification message to show, e.g., “$place_name: $name > $value $units for sources: $sources” will result in "Auckland: temperature > 20 C for GFS and Icon.
I suspect there might be a few things missing from this list.