- 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>
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 UTC