Proposal for context management

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m
Line 4: Line 4:
  
 
If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required.  All profiles can of course be edited by the user and new profiles defined.  The profiles will have to be prioritised.
 
If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required.  All profiles can of course be edited by the user and new profiles defined.  The profiles will have to be prioritised.
'''
+
 
Defining Context'''
+
==
 +
Defining Context ==
 +
 
  
 
Each profile has a defined set of criteria in which it will become active.  The profile with the highest priority is activated if more than one set of criteria are matched.
 
Each profile has a defined set of criteria in which it will become active.  The profile with the highest priority is activated if more than one set of criteria are matched.
  
 
Possible criteria:
 
Possible criteria:
 +
 
Within X meters of GPS co-ordinates YY:ZZ.
 
Within X meters of GPS co-ordinates YY:ZZ.
 +
 
Gesture or position reported by accelerometers
 
Gesture or position reported by accelerometers
 +
 
Current time and/or date
 
Current time and/or date
 +
 
Power status
 
Power status
 +
 
A particular application has focus
 
A particular application has focus
 +
  
 
A profile can define:
 
A profile can define:
 +
 
Which services are active; GSM, BT, WiFi, GPS
 
Which services are active; GSM, BT, WiFi, GPS
 +
 
What events will interrupt the current application; Call, Message, Alarm
 
What events will interrupt the current application; Call, Message, Alarm
 +
 
Output settings; Volume, vibration, screen brightness
 
Output settings; Volume, vibration, screen brightness
 +
  
 
A "profile rule" can be set to override a particular aspect of the currently active profile.
 
A "profile rule" can be set to override a particular aspect of the currently active profile.
  
If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on.
+
If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on or another profile is selected.
 +
 
 +
 
 +
==
 +
Some examples of context choosing a profile:==
  
'''Some examples of context choosing a profile:'''
 
  
  
Line 48: Line 63:
  
  
Examples of profile definition
+
 
 +
== Examples of profile definition ==
 +
 
  
 
Services= GSM,BT,WiFi,GPS.
 
Services= GSM,BT,WiFi,GPS.
 +
 
Interrupts= Call, Message, Alarm.
 
Interrupts= Call, Message, Alarm.
 +
 
Outputs= Volume, Vibration and Screen Brightness.
 
Outputs= Volume, Vibration and Screen Brightness.
 +
 +
  
 
SLEEP:  All service off, call & message interupts off, volume & vibration normal, screen off
 
SLEEP:  All service off, call & message interupts off, volume & vibration normal, screen off
Line 76: Line 97:
  
 
GUIs needed:
 
GUIs needed:
 +
 
'''Profile selector''' with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.
 
'''Profile selector''' with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.
  

Revision as of 05:34, 22 May 2008

I don't know how far along the new framework is in relation to context management but I had a think about it and here is my proposal. If you are really working on the code for context management and all this seems obvious or useless please remove the link that brought you here.

The phone could contain a number of profiles that determine which services are running, the settings for outputs and what events will interrupt the current in-focus application and deliver outputs. These profiles can be overridden by individual rules selected by the user.

If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required. All profiles can of course be edited by the user and new profiles defined. The profiles will have to be prioritised.

== Defining Context ==


Each profile has a defined set of criteria in which it will become active. The profile with the highest priority is activated if more than one set of criteria are matched.

Possible criteria:

Within X meters of GPS co-ordinates YY:ZZ.

Gesture or position reported by accelerometers

Current time and/or date

Power status

A particular application has focus


A profile can define:

Which services are active; GSM, BT, WiFi, GPS

What events will interrupt the current application; Call, Message, Alarm

Output settings; Volume, vibration, screen brightness


A "profile rule" can be set to override a particular aspect of the currently active profile.

If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on or another profile is selected.


== Some examples of context choosing a profile:==


Phone face down at rest for >5 seconds -> SLEEP

Battery power below 20% -> LOW-POWER

GPS registers position as within 100m of "home" -> HOME

GPS registers position as within 500m of "work" -> WORK

Time between 1900-2330 -> PUB

Time between 2330-0500 and within 5km of "city centre" -> CLUB

No context match -> DEFAULT


"home", "work" and "city centre" all defined by GPS co-ords by user.

These profiles are in priority order so if the phone is face down battery power, GPS position and time will make no difference. If you are at home the PUB and CLUB profiles will not be engaged.


Examples of profile definition

Services= GSM,BT,WiFi,GPS.

Interrupts= Call, Message, Alarm.

Outputs= Volume, Vibration and Screen Brightness.


SLEEP: All service off, call & message interupts off, volume & vibration normal, screen off

LOW-PWR: GSM on BT,WiFi,GPS off, all interupts on, volume & vibration normal, screen max 50%

HOME: All service on, call & message interupts on, volume & vibration normal, screen normal

WORK: All service on, call & message interupts on, volume silent, vibration normal, screen normal

PUB: All service on except BT, call & message interupts on, volume silent, vibration normal, screen normal

CLUB: GSM GPS on BT,WiFi off, call & message interupts on, volume loud, vibration normal, screen 50%

DEFAULT: All service on except BT, call & message interupts on, volume & vibration normal, screen normal

D.N.I.: All service on, call & message interupts off, volume & vibration normal, screen normal


D.N.I (do not interrupt) is an example of a non-context driven profile.

No context driven system will be fool-proof but I think in this way we can build a relatively simple system that can have quite complex behaviour and importantly can be overridden and turned off quite simply.

GUIs needed:

Profile selector with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.

Profile editor

Context editor to define events and match them to profiles


Also needed (will be needed for other apps too I think):

Method of defining and tagging gestures eg "face-down"

Method of tagging GPS co-ords to define "home" etc.


I hope that this makes some kind of sense.

Personal tools

I don't know how far along the new framework is in relation to context management but I had a think about it and here is my proposal. If you are really working on the code for context management and all this seems obvious or useless please remove the link that brought you here.

The phone could contain a number of profiles that determine which services are running, the settings for outputs and what events will interrupt the current in-focus application and deliver outputs. These profiles can be overridden by individual rules selected by the user.

If 'context sensitive profiling' is turned on the phone checks the context regularly and changes the profile in use if required. All profiles can of course be edited by the user and new profiles defined. The profiles will have to be prioritised. Defining Context

Each profile has a defined set of criteria in which it will become active. The profile with the highest priority is activated if more than one set of criteria are matched.

Possible criteria: Within X meters of GPS co-ordinates YY:ZZ. Gesture or position reported by accelerometers Current time and/or date Power status A particular application has focus

A profile can define: Which services are active; GSM, BT, WiFi, GPS What events will interrupt the current application; Call, Message, Alarm Output settings; Volume, vibration, screen brightness

A "profile rule" can be set to override a particular aspect of the currently active profile.

If no context rules are defined the profile can only be activated manually and will remain in force until context awareness turned back on.

Some examples of context choosing a profile:


Phone face down at rest for >5 seconds -> SLEEP

Battery power below 20% -> LOW-POWER

GPS registers position as within 100m of "home" -> HOME

GPS registers position as within 500m of "work" -> WORK

Time between 1900-2330 -> PUB

Time between 2330-0500 and within 5km of "city centre" -> CLUB

No context match -> DEFAULT


"home", "work" and "city centre" all defined by GPS co-ords by user.

These profiles are in priority order so if the phone is face down battery power, GPS position and time will make no difference. If you are at home the PUB and CLUB profiles will not be engaged.


Examples of profile definition

Services= GSM,BT,WiFi,GPS. Interrupts= Call, Message, Alarm. Outputs= Volume, Vibration and Screen Brightness.

SLEEP: All service off, call & message interupts off, volume & vibration normal, screen off

LOW-PWR: GSM on BT,WiFi,GPS off, all interupts on, volume & vibration normal, screen max 50%

HOME: All service on, call & message interupts on, volume & vibration normal, screen normal

WORK: All service on, call & message interupts on, volume silent, vibration normal, screen normal

PUB: All service on except BT, call & message interupts on, volume silent, vibration normal, screen normal

CLUB: GSM GPS on BT,WiFi off, call & message interupts on, volume loud, vibration normal, screen 50%

DEFAULT: All service on except BT, call & message interupts on, volume & vibration normal, screen normal

D.N.I.: All service on, call & message interupts off, volume & vibration normal, screen normal


D.N.I (do not interrupt) is an example of a non-context driven profile.

No context driven system will be fool-proof but I think in this way we can build a relatively simple system that can have quite complex behaviour and importantly can be overridden and turned off quite simply.

GUIs needed: Profile selector with "Context On" button (context awareness switched off by selecting any profile) and list of current profiles and ability to change priority of profiles and go to profile editor.

Profile editor

Context editor to define events and match them to profiles


Also needed (will be needed for other apps too I think):

Method of defining and tagging gestures eg "face-down"

Method of tagging GPS co-ords to define "home" etc.


I hope that this makes some kind of sense.