Re: [Vibration] Feedback on the Vibration API

Hi Anssi,

Le 06/11/2012 10:35, Anssi Kostiainen a écrit :
> Hi David,
>
> On 6.11.2012, at 9.46, ext David Bruant wrote:
>
>> Le 06/11/2012 00:05, Marcos Caceres a écrit :
>>>> I
>>>> assume knowing when the device stopped vibrating is an important
>>>> information when you want your user to have a compelling experience.
>>> Maybe, what's the use case you were thinking of? I think it's deliberately designed to be "fire and forget".
>> I want to wait for a vibration pattern to end before starting a new one. I want the previous to end to offer a consistent experience; I don't want to randomly cut a vibration pattern because I'm starting the new one.
> In early drafts we had 'vibrationstart' and 'vibrationend' events but we dropped them from v1 as we did not have compelling use cases for them. As always, we're happy to reconsider adding something similar in v2 if we unearth new use cases. I've added a note about this to our FutureWork wiki, so we don't forget:
>
>    http://www.w3.org/2009/dap/wiki/FutureWork
Thanks,

>>>> Step 3, 5 and 7 of the processing vibration patterns algorithm mention
>>>> implementation-dependent limits and throw according to these. However,
>>>> an application has no way to know these limits, so an application can't
>>>> adapt its behavior to different implementation limits. I think it would
>>>> be nice of the implementation to provide these limits as constants.
>>>> I'm afraid that from an application author perspective, the only
>>>> alternative is try out values to figure out the limits and "try out
>>>> values" means actually vibrating or do weird hacks like:
>>>>
>>>> try{
>>>> navigator.vibrate(10000);
>>>> navigator.vibrate(0); // cancel vibration if it occured
>>> What use case did you have in mind for knowing the limits?
>> Using the API and being sure it will actually vibrate the way I intend to?
>> If, for some reason, the device can't vibrate for 2 seconds and that's I want to do, I wish I knew it before getting in a situation where I need to vibrate 2 seconds, so that I can define a fallback behavior instead, for instance.
>>
>> To authors, the spec is saying "use this function to vibrate, but it will throw for some implementation-independent values, but you have no way to know them, good luck!"
> The expectation is that implementations set the limit to a reasonable level and do that for a good reason. E.g. sometimes the user may not want the device to vibrate at all, but does not want the web app to know that due to privacy reasons.
>
> I don't think we have a high value use cases for vibrating for a very long time outside of adult industry, so in most cases you should not hit the limit anyway.
It's not that much about "a very long time", but any time at all since 
the spec provides no insight as to which value is acceptable.
You wrote "the expectation" and "reasonable level". I wish this was 
documented in the spec with numbers of what is considered to be 
"reasonable". Because right now, an implementation can do almost 
anything and is considered valid.
It doesn't make it easy for developers to write apps that will last. If 
I write an app that vibrates for 800ms and that works fine with current 
phones, what guarantees that in the next year, a new phone won't arrive 
to the market with a 750ms limitation? Why not a legislation that 
prevents new phone from vibrating more than 700ms in a row? It would 
break applications.
Also, should I read the hardware spec of every new hardware to make sure 
my app won't crash? Should I test on every phone to make sure it works well?

I don't have use cases, but I worry a lot about the longevity of code 
and the current API does not really provide a lot of information that 
will help applications to properly work in new complying environments.

The point about the OS not exposing this kind of information is 
compelling, but that should be the only reason not to expose reasons to 
throw in my opinion.

David

Received on Tuesday, 6 November 2012 10:22:19 UTC