W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

RE: [vibration] Preliminary thoughts on the vibrator spec

From: Josh Soref <jsoref@rim.com>
Date: Wed, 23 Nov 2011 17:17:34 +0000
To: Deepanshu gautam <deepanshu.gautam@huawei.com>, Anssi Kostiainen <anssi.kostiainen@nokia.com>
CC: Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <957F1ECDA90E004B8DBDE23CFC94E3A3116475CD@XMB103ECNC.rim.net>
DG wrote:
> I'm not proposing to enable Vibration automatically (without user
> consent). It is just to allow Web Apps to know whether Vibrator is OFF and
> then notify UA. Which may then ask user to switch it on (however, that part is
> out-of-scope here).

This is not the way the web works, and it's annoying.

It creates things like:

While(!vibrator.enabled) { nag_user_to_enable_vibration() }

> This will avoid UA/OS/device to keep monitoring if some
> unavailable functionality is being used and then notify user.

The device doesn't need to do any monitoring. If vibration is disabled at the device, it just ignores the request. Minimal cost. It's still cheaper than the request being processed. If the user decides to enable vibration midway through a task, it doesn't require the user to restart the app and reconfigure it to use vibration.

If vibration is disabled at the browser, then the browser silently drops the request. Minimal cost. It's even cheaper than disabling vibration at the OS/Device level, and is still cheaper than the request being processed. If the user decides to enable vibration midway through a task, it doesn't require the user to restart the app and reconfigure it to use vibration.

Anssi wrote:
> The better way
> would be for *app* to say "Hey I want to use XXX would you like to switch it
> on" and user may decide to switch it on for that particular session, forever,
> forever for that particular application etc.

Right.

> And I want to control that globally similarly to sound level, not on per web
> app basis.

DG wrote:
> User experience will be same. Whether app tell UA (that I want to user an
> unavailable function) or UA finds it by itself (before notifying user) is
> transparent to user.

No. In cases of annoying content, or the user wanting to enable/disable dynamically and consistently at a single location, having the UA / Device be able to make the switch silently and dynamically is significantly better than having the app do something annoying. Forcing users to learn how to turn on/off something in a web app, and in each and every web app that might do this, is painful, since it will be hidden in randomly different places.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 23 November 2011 17:20:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:24 GMT