Wishlist/Silent mode timeout - Revision history

DolfjeBot1: Wishlist:Silent mode timeout moved to Wishlist/Silent mode timeout: Replacing 'Wishlist:' with 'Wishlist/'

2008-08-31T12:25:37Z

Wishlist:Silent mode timeout moved to Wishlist/Silent mode timeout: Replacing 'Wishlist:' with 'Wishlist/'

Kempelen: Category changes: -User, -Ideas

2008-08-30T22:06:11Z

Category changes: -User, -Ideas

Coolcat at 04:13, 27 March 2008

2008-03-27T04:13:08Z

Coolcat: /* Design Issues */

2008-03-04T06:05:44Z

‎Design Issues

Speedevil: /* Silent mode timeout */ typo

2007-07-26T20:18:39Z

‎Silent mode timeout: typo

Speedevil: /* Design Issues */ Category:Unimplemented Category:Profiles

2007-07-20T12:42:49Z

‎Design Issues: Category:Unimplemented Category:Profiles

Glenn: -cat

2007-07-17T06:39:58Z

-cat

Delta: /* Silent mode timeout */

2007-05-12T13:29:46Z

‎Silent mode timeout

Kresp0 at 00:38, 22 February 2007

2007-02-22T00:38:59Z

New page

{{Wishlist}}

== Silent mode timeout ==

With this feature, there is no need to turn the ringer back on if you previously know how long will be the film/meeting/...

Another possibility is mark and remember the movie theater or meeting room perimeter with GPS, and activate it if the moko is in the area.

== Design Issues ==

*This would be integrated with profiles?

[[Category:ideas]]

← Older revision		Revision as of 22:06, 30 August 2008
Line 26:		Line 26:
	*This would be integrated with profiles?		*This would be integrated with profiles?

−	~~[[Category:User]]~~
−	~~[[Category:Ideas\| ]]~~
	[[Category:Software ideas]]		[[Category:Software ideas]]

@@ Line 28: / Line 28: @@
 [[Category:User]]
 [[Category:Ideas| ]]
-[[Category:Sofeware ideas]]
+[[Category:Software ideas]]

@@ Line 25: / Line 25: @@
 *This would be integrated with profiles?
-[[Category:Unimplemented]]
-[[Category:Profiles]]
+[[Category:User]]

@@ Line 5: / Line 5: @@
 With this feature, there is no need to turn the ringer back on if you previously know how long will be the film/meeting/...
-Another possibility is mark and remember the movie theater or meeting room perimeter with GPS, and activate it if the moko is in the area.
+Another possibility is to mark and remember the movie theater or meeting room perimeter with GPS, and activate it if the moko is in the area.
 Or the moko could be configured to switch to certain profiles according to the Wi-Fi networks detected in the proximity.

← Older revision		Revision as of 12:42, 20 July 2007
Line 25:		Line 25:

	*This would be integrated with profiles?		*This would be integrated with profiles?
		+	[[Category:Unimplemented]]
		+	[[Category:Profiles]]

← Older revision		Revision as of 06:39, 17 July 2007
Line 25:		Line 25:

	*This would be integrated with profiles?		*This would be integrated with profiles?
−
−
−	~~[[Category:ideas]]~~

← Older revision		Revision as of 13:29, 12 May 2007
Line 6:		Line 6:

	Another possibility is mark and remember the movie theater or meeting room perimeter with GPS, and activate it if the moko is in the area.		Another possibility is mark and remember the movie theater or meeting room perimeter with GPS, and activate it if the moko is in the area.
		+
		+	Or the moko could be configured to switch to certain profiles according to the Wi-Fi networks detected in the proximity.
		+	For example when it detects the home network (by SSID and/or MAC to be sure) the silent mode gets deactivated if the user has forgot to switch it off. This could be an immensely useful and simple feature for many people, as it is quite common to forget the silent mode and become unreachable on your phone. This could also be very useful the other way around. Say, when you arrive within your university/work network, the moko activates the silent mode, etc. Wi-Fi proximity could be much more reliable compared to GPS, because GPS is not always reliable indoors or other similar conditions. Besides, defining the "profile zones" in GPS could be more complicated (coordinates, zone radius, shape, taking into account GPS errors for all these parameters while still making sure this sort of works, etc.) Wi-Fi proximity by MAC is rather basic concept.
		+
		+	Still a combination of both of these would probably give the best result as different people have different life style and requirements.
		+
		+	One of the problems with this is that the GPS, WiFi module would have to be active for this to work and that's serious battery drain.
		+
		+	A much more energy efficient way of doing this would be zoning by GSM base stations. Say when in proximity of stations (xxxx,xxxx,xxxx,xxxxx,xxxx) activate or deactivate a certain profile. This could be done very easly and would not present any extra energy consumption considerations. However the zone margins would be very vague and the zones would be rather large. Still it would serve really well most of the people who commute to work/school regularily and who do not live very close between the prospective profile zones. Since the density of GSM base stations is very high in some urban environments and many are directional, this could provide better zoning precision in some cities.
		+
		+	Another way would be to simply make a profiling schedule - since many phones support scheduling alarms in different times of different weeks days, profiles could be activated or deactivated according to a similar scheduling and could work really well for people with fixed working hours.
		+
		+	This could be also tied with the main scheduling application, to use silent mode automatically when a meeting, lecture, presentation, concert, or a similar event is scheduled.
		+
		+	All of these functions would probably require a default profile which overrides all profile zoning and scheduling in case it is needed.

	== Design Issues ==		== Design Issues ==