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…

It’s always interesting to hear the usage scenarios people have for Locale!

Locale’s UI doesn’t handle your particular use case very well, as Locale’s UI was optimized for the most common usage scenario. Consider a recent study http://www.nature.com/nature/journal/v453/n7196/abs/nature06958.html where researchers followed the movements of 100,000 mobile phone users based on cellular tower positioning and discovered that people devote most of their time to just a few locations. Nearly 3/4 of the study’s subjects stayed within a 20-mile radius over a 6-month period. There was a significant degree of periodicity in these movements, such as going between home and work on a daily basis. Simply put, the majority of users are interested in a few locations that are relatively close together.

In terms of improving the Locale UI for your use-case, let’s look at the options:

a. Locale doesn’t know anything about what the user is typing in; it simply hands the query off to Android’s Geocoder and gets a coordinate back. Having Locale parse this isn’t going to be a good idea, especially once you start thinking about international addresses, etc. as we’d have to completely re-implement the Geocoder ourselves.

c. Locale uses the Android system-wide search UI facilities and these only provide a single input field. Adding multiple fields wouldn’t be possible.

I don’t think any of these adequately solve the problem, while keeping the UI design simply for the majority of users. So we’ll have to think more about how exactly this could be implemented…