Not on Conditions
Ability to have NOT on conditions. This is most useful for location (e.g. leaving a location).
anonymous
shared this idea
The original request here was for a logical NOT operator, although it doesn’t make sense to create a logical NOT operator in Locale. Most of the time, NOT isn’t the right way of thinking about a Condition. For example, NOT 9 am to 5 pm could be redefined as 5pm to 9am. NOT at work would simply be the Default situation. For the other conditions built-in to Locale, thinking about the problem in a different way usually means that NOT isn’t needed. If a Condition truly needs NOT logic, then that should probably be put into the individual Condition’s UI itself rather than as part of the Edit Situation screen in Locale.
Although this request is for a NOT operator, I believe the underlying request here is a way of detecting the transition between situations. The strongest use case would be detecting when you’ve left a particular Location. While Locale can easily detect the transition between situations, providing a UI to allow the user to do something with that transition is extremely complex.
Today, Locale treats situations as a continuous event. When Locale determines that a situation is active, it applies that situation’s settings. When leaving a situation, a lower priority situation’s settings take precedence (usually the Defaults). This provides a single, consistent behavior that makes Locale easy to understand.
One suggested implementation is to have “On Enter” and “On Exit” settings within a situation. On Enter settings would work like the current settings within Locale, while On Exit would be applied when leaving a situation. But what if the On Exit settings of a situation are in conflict with the On Enter settings of a higher-priority situation? The number of arrangements that the user must think about has just doubled.
We’re still evaluating ways to solve the underlying requeste of “leaving a location”, without making the UI too complicated…
58 comments
-
george jackson
commented
Ive quickly scanned the comments regarding a 'not' operator - what would happen if you are late for an appointment. in other words you are NOT in a location at a specific time - thats what i am looking for . so you can be notified .. fire off a auto SMS etc . Is this already available ?
-
yvolk
commented
The weakest point of "Defaults" as they are in Locale is that this is SINGLE set of actions for ALL cases when we leave situations.
This is why in Defaults we have to set (to default values) _everything_ and this is why Defaults are not good in real life: we often have unnecessary changes. -
AdminCarter
(Admin, two forty four a.m.) commented
@Manmikey: That's what the Defaults are for. Just turn off Wi-Fi in the Defaults.
-
Manmikey
commented
Carter
I understand the need to keep Locale simple and intuative but and that adding a NOT operator would make the app more unwieldy...However the way I use my mobile at home and else where is significantly different....when "elsewhere" I want to conserve battery so I need the Locale to know when its not at home to tell it to powersave and turn off wifi etc etc...At home I want everything on all the while because it can be charged readily. Locale knows when its at home because I have set it up that way, how set it to tell it I am not at home without a NOT operator? A "Not at Location" option would solve most peoples needs on this post.
Thanks -
Phienyx
commented
This suggestion is listed under my "your ideas" listing. I apologize if I didn't word my original request in a more technical manner as I do not fully understand technical intricacies of the technology. However, I do understand the re-posters explaination in general.
Am I to understand that currently, when there are no "situations" in effect, the defaults are restored?
-
Steven Benders
commented
Would it be possible to have a "Coming From" condition?
If last (highest priority) Situation was "Work" and now the Situation is "Default", we can assume we left work. Do x.
If last Situation was "Default" and now Situation is "Home", we can assume we entered Home (and also left Default). Do y.
So for example, for a Car situation:
If Car situation is active and the last active situation was Home, I left Home - turn off Wifi. If Work situation is active and the last active situation was Car, I'm going to work - turn on vibrate. BUT, if Work situation is active and the last active situation was Courthouse, dim the screen. If I came to Work from any other situation, do both.Could something like that work?
-
Fyrhtu
commented
... That's not to say, however, that I wouldn't appreciate a "Leaving" condition; although it can be replicated with creative use of the Variables plugin, it would certainly be nice to have that baked in.
-
Fyrhtu
commented
@erciesielski: The situation you've given doesn't require a "not"- it's a "Plugged in" AND "Between [sunset] and [sunrise]" Condition with lower priority given to it than a second condition, "Between [Sunset] and [Sunrise] AND "Plugged in" AND "Location:home."
You could also achieve a lot more by tossing in the Locale Variables plugin- but the core is the same; you don't need "Not" for the situation you're describing, you just have to think around it and find what the situation IS. -
erciesielski
commented
The reason I want this feature is because I want to use a "not at home" condition. When "not at home" and plugged in after sunset, I want my screen to dim because I obviously would be driving at night.
-
yvolk
commented
@skylarsutton We are talking about different things: you need only "not" option for each condition with the same whole other logic. This indeed may be done easily.
I'm trying to change the logic of handling "entering situation" and "leaving situation" on the timeline in cases when we're "in" several situations simultaneousely...So in fact two different tasks are under the same "Not on Conditions" topic :-)
-
skylarsutton
commented
@yvolk - I've seen the API. Every condition responds in one of three ways:
1) i'm satisfied
2) i'm not satisfied
3) i don't know if i'm satisfiedThe "implementation description" is a drop down in the edit situation page with "when condition is met" and "when condition is not met". If it's anything more than that you have WAY overengineered it. When the "not" option is selected just inverse the conditions response:
1) i'm satisfied becomes "i'm not satisfied"
2) i'm not satisfied becomes "i'm satisfied"
3) i don't know if i'm satisfied says what it isGive me the source code and i could have this done in 10 minutes - it's not a difficult problem to solve in any way shape or form.
-
yvolk
commented
@skylarsutton Unfortunately it's not so simple :-(
I've wrote some proposals on implementation of this feature (see below) but returning to them I see that they are far from perfect.
So the task still needs good implementation description. The idea is not enough. -
skylarsutton
commented
I find Carter very confrontational in these discussion forums - and frankly not interested in listening to user feedback. If your users have a need for a not condition (myself included) just make it already and stop arguing with them.
-
yvolk
commented
@Carter “On Enter settings would work like the current settings within Locale, while On Exit would be applied when leaving a situation. But what if the On Exit settings of a situation are in conflict with the On Enter settings of a higher-priority situation?”
I’ve read Locale-Help once more and I see that in order to describe, how this may be easily understand by User and implemented by programmers, we need to enhance Locale “model” some more. Here are my suggestions:
1. Situations which “conditions” are met are called “current” (not “active”, as it was earlier!!!). There may be one or more “current” conditions at any point in time. “Defaults” situation is always “current”.
2. “Active situation” is “current” situation with highest priority. At any point in time only ONE situation is “active”.
3. When situation becomes “active”:
3.1 Previous “active” situation becomes “current” (i.e. not active) and it’s "On Exit" settings are triggered.
3.2. “On Enter” settings of new “active” situation are triggered.
4. When device leaves “active” situation it’s "On Exit" settings are triggered. After this, next by priority “current” situation becomes “active” and “On Enter” settings of that new “active” situation are triggered.
5. This way “On Enter” settings of each situation will be always followed by “On Exit” settings of the same situation.
I think that above statements (accompanied by good picture…) will make clear for the User what happens :-) -
yvolk
commented
@Carter Let me show you that "Defaults" situation is NOT working as expected at least in some cases.
You're thinking about timeline on which different "Situations" appear as "islands" on the top of the "Defaults" ocean :-). If this was always a case "Defaults" situation MAY be used for setting ALL "settings" to their default values (although IMHO this is a bad practice to set ALL possible settings so often...)But my experience shows that situations are more like a lot of different sized papers laying on a table: they overlap each other, and I often don't see the top of the table ("Defaults" situation) moving from one paper to the other. In this case "Defaults" doesn't work AT ALL, and my settings may not return to the default values for a long time producing UNPREDICTABLE behaviour of the phone.
One very common example of the "large pieace of paper that hides the table" is "At night" condition, in which (i.e. "when") I usially turn off sounds. My phone may encounter different "situations" at night, each of them may set something, but with curent version of Locale NONE of these settings will be returned back to default values, at least before night ends...
Is this case convincing? -
Alex
commented
I agree that it would be very nice to have "On condition starts" and "On condition ends", would be so flexible! And of cause some checkbox like "Go back to default" and grey out "On condition ends"
-
Mil
commented
The main reason for me voting for this is so that I can achieve changes when "leaving a specific area" e.g. when I leave work. I think it would be really good if the location condition had a setting for (entry, during or exit) so that you can specify exactly what about the location sets of the triggers.
I can see some value in also having a NOT operator as well but I think the Leaving a location is more valuable to me.
-
yvolk
commented
I've just wrote comment and my implementation proposal for the "Add new condition type of Leaving Situation" suggestion, and I think my proposal will allow to implement this suggestion ("Not on Conditions") also,
so in fact votes for both suggestions may be added :-)
Exuse me for the this crosspost, and cross voting :-)
----------------------------
I support this request,
and I think that it's implementation will make "situation" description much more intuitive for the User.
It's really simple to think in these terms:
- How do I describe situation? ("Condition" in Locale)
- What should be done on entering the situation? (currently "Settings" in Locale. I propose to rename this to "On entering the situation:")
- What should be done on leaving the situation? (new group of the same "settings" plugins. I propose to name it "On leaving the situation:")In fact, in most cases settings "On leaving the situation" will mirror (revert) settings set for "On entering the situation". And both settings will be conveniently located in one place (in one "situation"). Today we have to figure out, which settings should be put into Defaults... and this is hard... at least for me. But I'm an IT professional, after all. I guess non-tech users are often at least disappointed...
Some common "situations" that will benefit from this new Locale feature:
- I came home/I left home (work, etc. ).
- The night started/ended (same for weekend...).
- I connected to Wi-fi/disconnected from it (same for Power source, bluetooth).
- Battery level dropped below 20% and I do not charge/battery is OK or I connected to the charger. -
yvolk
commented
I support this request, and I think that it's implementation will make "situation" description much more intuitive for the User.
It's really simple to think in these terms:
- How do I describe situation? ("Condition" in Locale)
- What should be done on entering the situation? (currently "Settings" in Locale. I propose to rename this to "On entering the situation:")
- What should be done on leaving the situation? (new group of the same "settings" plugins. I propose to name it "On leaving the situation:")In fact, in most cases settings "On leaving the situation" will mirror (revert) settings set for "On entering the situation". And both settings will be conveniently located in one place (in one "situation"). Today we have to figure out, which settings should be put into Defaults... and this is hard... at least for me. But I'm an IT professional, after all. I guess non-tech users are often at least disappointed...
Some common "situations" that will benefit from this new Locale feature:
- I came home/I left home (work, etc. ).
- The night started/ended (same for weekend...).
- I connected to Wi-fi/disconnected from it (same for Power source, bluetooth).
- Battery level dropped below 20% and I do not charge/battery is OK or I connected to the charger. -
Oddur Snær commented
I actually bought this app thinking this was in there. seems such a basic feature to have.
