RE: [vibration] Preliminary thoughts on the vibrator spec

Sorry sent too early.............more below

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


> -----Original Message-----
> From: Deepanshu gautam
> Sent: Thursday, November 17, 2011 2:37 PM
> To: 'Robin Berjon'
> 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
> 
> Inline with [DG]
> 
> Deepanshu Gautam
> Service Standards, Huawei Software
> T: +86 25 5260008 M: +86 135 85147627
> 
> 
> > -----Original Message-----
> > From: Robin Berjon [mailto:robin@berjon.com]
> > Sent: Wednesday, November 16, 2011 5:56 PM
> > To: 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
> >
> > [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] Okay good. End of story :-)
> >
> > > [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] Without this exposed to webapps directly, a poor implementation which should have fixed it will not try to fix and leave the user in cold whereas a poor implementation which should not fix it will try to fix it an annoy user. Its basically same........The point is if something is poorly done we can't do much to help it but if that same thing wants to be not-poorly done then we should allow it to do so by ourselves not counting on something else.
> [DG] Without this exposed to web apps directly, a poor implementation
> will not try to fix it and leave the user in cold too. As a developer
> (who wants to write good quality apps not poorly written apps) I would
> like to have a complete API which should serve all related aspects (if
> I'm invoking vibration I want to first make sure that vibrator is ON
> [if it exists] by myself [through the same API] not depending on user
> agent who *May* do so). Further, having it exposed to pages doesn't
> preclude user agent to do what it wants to do. User agent may still
> have this functionality for those poorly written apps who forgets
> things.
[DG] My point is that this is critical (from the point of view of developer) in case of vibrations bcz (assuming, this is not supported neither by API nor by UA) in case of sound user will most probably find out and will switch it ON. But in case of vibration user may never know that the game what he/she is playing supports vibration and developer will have no way to notify user to switch it ON. I *guess* our (DAP) direct customers will be developers who will create apps using our APIs so we should try to accommodate all the identified concern related to them rather backing off form them saying that it will be handled by some other entity.
> 
> >
> > > [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.
> [DG] What deliverable you are talking about?
> >
> > --
> > Robin Berjon - http://berjon.com/ - @robinberjon
> >

Received on Thursday, 17 November 2011 06:58:53 UTC