RE: [vibration] Preliminary thoughts on the vibrator spec

Thanks Jose

It would be fine to me (any sort of API. But, since it is related with Vibration I prefer to have it is Vibration API).........As a developer i just don't like relying on UA for this.


Regards

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

> -----Original Message-----
> From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]
> Sent: Wednesday, November 16, 2011 6:10 PM
> To: Robin Berjon; Deepanshu gautam
> Cc: public-device-apis@w3.org public-device-apis@w3.org; public-device-
> status@w3.org
> Subject: 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 Friday, 18 November 2011 08:55:57 UTC