Re: [vibration] Preliminary thoughts on the vibrator spec

Maybe if we had a Settings or SysInfo API, the App could detect whether
vibration is on and if not make a request to change that setting to
'vibratorOn'. Also another possibility would be to do it through an intent

Thanks, best

El 16/11/11 10:55, "Robin Berjon" <robin@berjon.com> escribió:

>[Do we really need to CC public-device-status? This work is normally part
>of public-device-apis and not the TF.]
>
>On Nov 16, 2011, at 10:45 , Deepanshu gautam wrote:
>> [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.
>
>Fingerprinting is the practice of identifying a user without requiring
>cookies or other such identifier storage simply by looking at the
>properties publicly exposed by her user agent. A good demo is
>http://panopticlick.eff.org/.
>
>In general we try to avoid fingerprinting because it is a major privacy
>concern. I'm not convinced that fingerprinting is an issue in this
>specific case, however.
>
>> [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"?
>
>I understand your use case but I don't see why it would have to be
>exposed to the web application. The user agent can, of its own accord,
>notice that a page is trying to use vibration (or sound, or whatever
>else) while it is turned off, and notify the user of the issue. UAs can
>get this right across the board whereas exposing it to pages means that
>poorly written apps that could use this functionality will forget to do
>so and leave the user in the cold, and poorly written apps that shouldn't
>use this functionality will use it and annoy users.
>
>> [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 :-)
>
>If you have use cases, please be sure to send them (in a separate thread)
>as that topic is a deliverable of this group.
>
>--
>Robin Berjon - http://berjon.com/ - @robinberjon
>
>


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Wednesday, 16 November 2011 10:10:24 UTC