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

RE: [vibration] Preliminary thoughts on the vibrator spec

From: Deepanshu gautam <deepanshu.gautam@huawei.com>
Date: Wed, 23 Nov 2011 01:48:59 +0000
To: Deepanshu gautam <deepanshu.gautam@huawei.com>, Robin Berjon <robin@berjon.com>
Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-id: <DA22857AC9F15C469BB47FE88C0201292A92CA07@SZXEML510-MBS.china.huawei.com>
I'm wondering if I should consider this silence as agreement for my proposal in the thread below :-)

My proposal: To have function like VibStatus() returning "VibON" and "VibOFF". To let pages know whether the vibrator in ON or OFF

Regards

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:57 PM
> To: Deepanshu gautam; 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
> 
> 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 Wednesday, 23 November 2011 01:51:26 GMT

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