RE: [vibration] Preliminary thoughts on the vibrator spec

Inline with [DG]

Deepanshu Gautam
Service Standards, Huawei Software
T: +86 25 5260008 M: +86 135 85147627


-----Original Message-----
From: Anssi Kostiainen [mailto:anssi.kostiainen@nokia.com] 
Sent: Wednesday, November 16, 2011 4:57 PM
To: Deepanshu gautam
Cc: ext Justin Lebar; Jonas Sicking; public-device-apis@w3.org; public-device-status@w3.org
Subject: Re: [vibration] Preliminary thoughts on the vibrator spec

On 16.11.2011, at 9.49, ext Deepanshu gautam wrote:

> Sorry for coming to it bit late...
> 
> About the added Step 9 "An implementation may abort the algorithm at this point".
> I don't think abort is the only feasible option. There is always a functionality at native layer to disable the Vibrator i.e user may switch it OFF. So in this case won't it be suitable to first know whether the Vibrator is OFF? If it is, then user may be given an option to switch it on for specific time or for particular page/application?
> To achieve this we just need a method like VibState() returning constants like "VibON" or "VibOFF". Depending on which it can be ascertained whether to continue to step 10 or abort.
> 
> Note: Vibrator may be switched OFF by default, or it may be accidently switched OFF. So, it is worth for developers to try to get it ON for better user experience.

Such a method would increase fingerprinting surface which is a privacy concern, so I'd prefer to not to include it.
[DG] I don't quite understand "fingerprinting surface" in this context but I guess you are referring to "added authorization" which may be a concern for user privacy, correct me if I'm wrong? If I'm right then I don't understand how it will increase "needed authorization" specifically when user may/must have been authorized by so many other existing ways before even start using the page/application in question here. Vibration is just a part of the page/application which user must be authorized/authenticated to use/consume.

Couldn't the web app just ask the user to turn on the vibrator via the OS if needed, similarly to the way the volume control behaves? I.e. there's no way a web app can figure out if the device is muted, and the volume control is managed by the OS. 
[DG] I'm sure there are reason for volume control to work this way. But here, if vibrator is OFF (natively) user may never know (until notified) that the page/application supports vibrations (this will degrade user experience). And, if Vibration API can handle it without depending on the OS, then why shouldn't it?? This is the model users already understand, so I think we should reuse it.
[DG] Do you think user will not understand "Switch on Vibrator?, allow, not-allow, allow-now, allow-forever"?

Do you agree?



[DG] PS: Further, I can come up with many usecases where it will be very beneficial for a web app to know if the device is muted, but that not something we should put up here :-)

-Anssi

Received on Wednesday, 16 November 2011 09:46:18 UTC